새 RHEL 8/9 시스템용 Salt 인프라를 생성하고 준비한 후에는 다음 마이그레이션 단계를 수행하여 RHEL 8/9로의 업그레이드를 완료할 수 있습니다.

마이그레이션 준비 및 수행

  1. RHEL 7 및 RHEL 8/9 시스템 모두에서 RaaS 서비스를 중지합니다.
  2. 이전 서버에서 새 서버로 gz 백업 파일을 복사합니다. gz 파일은 ownership=postgres:postgres로 /var/lib/pgsql 디렉토리에 저장해야 합니다.
  3. postgres 사용자에서 다음 명령을 실행하여 데이터베이스 디렉토리를 제거합니다.
    su - postgres
psql -U postgres
drop database raas_43cab1f4de604ab185b51d883c5c5d09
  4. 빈 데이터베이스를 생성하고 사용자를 확인합니다.
    create database raas_43cab1f4de604ab185b51d883c5c5d09
\du – should display users for postgres and salteapi
  5. /etc/raas/pki/.raas.key 및 /etc/raas/pki/.instance_id 파일을 이전 RaaS 서버에서 새 RaaS 서버로 복사합니다.
  6. 새 Postgresql 데이터베이스에 대한 업그레이드 명령을 실행합니다.
    su – raas
raas -l debug upgrade
이제 새 rhel9-raas 서버에서 raas 서비스를 시작할 수 있습니다. 브라우저에서 Automation Config UI에 액세스할 수도 있습니다. 다음으로 새 RHEL 8/9 Salt 마스터에서 마스터 플러그인을 구성해야 합니다.

새 Salt 마스터에서 마스터 플러그인 구성

새 rhel9-master 노드에서 다음 단계를 수행합니다.
  1. Salt 마스터에 로그인하고 /etc/salt/master.d 디렉토리가 있는지 확인하거나 생성합니다.
  2. 마스터 구성 설정을 생성합니다.
    경고: 설치를 업그레이드할 때 설정을 유지하려면 이 단계를 실행하기 전에 기존 마스터 플러그인 구성 파일의 백업을 생성합니다. 그런 다음 관련 설정을 기존 구성에서 새로 생성된 파일로 복사합니다. 
    sudo sseapi-config --all > /etc/salt/master.d/raas.conf

    이 명령을 실행하여 오류가 발생하면 Salt를 처음 설치할 때 사용한 방법과 관련이 있을 수 있습니다. Automation Config 설치 관리자를 통해 Salt를 설치한 경우에는 특별한 업그레이드 지침이 필요한 Salt Crystal이라는 오프라인 패키지가 설치에 포함되어 있을 수 있습니다. 자세한 내용은 문제 해결 페이지를 참조하십시오.

  3. 생성된 raas.conf 파일을 편집하고 다음과 같이 값을 업데이트하여 API(RaaS)가 사용하는 인증서의 유효성을 검사하고 IP 주소를 설정합니다.
    값 설명

    sseapi_ssl_validate_cert

    API(RaaS)가 사용하는 인증서의 유효성을 검사합니다. 기본값은 True입니다.

    자체 CA에서 발급한 인증서를 사용하는 경우 이 값을 True로 설정하고 sseapi_ssl_ca, sseapi_ssl_cert 및 sseapi_ssl_cert: 설정을 구성합니다.

    그렇지 않으면 False로 설정하여 인증서의 유효성을 검사하지 않습니다.

    sseapi_ssl_validate_cert:False

    sseapi_server

    RaaS 노드의 HTTP IP 주소입니다(예: http://example.com 또는 SSL이 사용되도록 설정된 경우 https://example.com).

    sseapi_command_age_limit

    시간(초 단위)이 얼마나 경과하면 오래된(잠재적으로 부실한) 작업을 건너뛸지 설정합니다. 예를 들어 하루보다 오래된 작업을 건너뛰려면 다음과 같이 설정합니다.

    sseapi_command_age_limit:86400

    건너뛴 작업은 데이터베이스에 계속 존재하며 Automation Config 사용자 인터페이스에 Completed 상태로 표시됩니다.

    일부 환경에서는 Salt 마스터가 오랫동안 오프라인 상태였다가, Salt 마스터가 다시 온라인 상태가 되면 대기열에 있는 작업을 실행해야 할 수도 있습니다. 이런 경우가 적용되는 환경에서는 경과 시간 제한(age limit)을 0으로 설정합니다.
    sseapi_windows_minion_deploy_delay 모든 필수 Windows 서비스가 활성화될 수 있도록 지연 시간을 설정합니다. 기본값은 180초입니다.
    sseapi_linux_minion_deploy_delay 모든 필수 Linux 서비스가 활성화될 수 있도록 지연 시간을 설정합니다. 기본값은 90초입니다.
    sseapi_local_cache 특정 데이터가 각 Salt 마스터에 로컬로 캐시되는 기간을 설정합니다. 기본값은 300초(5분)입니다.
  4. 선택 사항: 이 단계는 수동 설치에만 필요합니다. 마스터 플러그인을 연결하기 전에 SSL에 연결할 수 있는지 확인하려면 생성된 raas.conf 파일을 편집하여 다음 값을 업데이트합니다. 해당 값을 업데이트하지 않으면 마스터 플러그인은 기본적으로 생성된 인증서를 사용합니다.
    값 설명
    sseapi_ssl_ca CA 파일의 경로입니다.
    sseapi_ssl_cert 인증서의 경로입니다. 기본값은 /etc/pki/raas/certs/localhost.crt입니다.
    sseapi_ssl_key 인증서의 개인 키에 대한 경로입니다. 기본값은 /etc/pki/raas/certs/localhost.key입니다.
    id 시작 부분에 #을 추가하여 이 줄을 주석 처리하십시오. 필요하지 않습니다.
  5. 선택 사항: 성능 관련 설정을 업데이트합니다. 대규모 또는 바쁜 환경의 경우 다음 설정을 조정하여 Salt 마스터와 Automation Config 간의 통신 성능을 향상시킬 수 있습니다.
    • eventqueue 및 rpcqueue 엔진을 구성합니다.

      이러한 엔진은 Automation Config와의 일부 통신을 성능에 중요한 경로에서 전용 프로세스로 오프로드합니다. 엔진이 Automation Config와 통신하기 위해 대기하는 동안 페이로드는 Salt 마스터의 로컬 파일 시스템에 저장되며, 따라서 Salt 마스터를 다시 시작해도 데이터가 지속될 수 있습니다.

      이 엔진을 사용하도록 설정하려면 Salt 마스터 플러그인 구성 파일에서(raas.conf)에서 다음 설정의 주석 처리를 제거합니다.

      engines:
  - sseapi: {}
  - eventqueue: {}
  - rpcqueue: {}
  - jobcompletion: {}
  - keyauth: {}

      eventqueue 엔진을 구성하려면 다음 설정의 주석 처리를 제거하고 업데이트합니다.

      sseapi_event_queue:
  name: sseapi-events
  strategy: always
  push_interval: 5
  batch_limit: 2000
  age_limit: 86400
  size_limit: 35000000
  vacuum_interval: 86400
  vacuum_limit: 350000
  forward: []

      대기열 매개 변수는 함께 작동하는 방식을 고려하여 조정할 수 있습니다. 예를 들어 Salt 이벤트 버스에서 초당 이벤트가 평균 400개라고 가정하고, 위에 표시된 설정을 사용하면 약 24시간 동안 대기 중인 이벤트 트래픽을 Salt 마스터에서 수집할 수 있으며 이 시간이 지나면 크기 또는 경과 시간(age) 제한으로 인해 가장 오래된 이벤트가 삭제됩니다.

      rpcqueue 엔진을 구성하려면 다음 설정의 주석 처리를 제거하고 업데이트합니다.

      sseapi_rpc_queue:
    name: sseapi-rpc
    strategy: always
    push_interval: 5
    batch_limit: 500
    age_limit: 3600
    size_limit: 360000
    vacuum_interval: 86400
    vacuum_limit: 100000
    • 로드 캐싱을 사용하도록 설정합니다.
      sseapi_local_cache:
    load:3600
      참고: rpcqueue 엔진을 사용하도록 설정한 경우 로드 캐싱도 사용하도록 설정해야 Salt 마스터가 작업을 올바르게 처리할 수 있습니다.
    • 미니언 입자 페이로드 크기를 제한합니다.
      sseapi_max_minion_grains_payload:2000
    • 정의된 시간(초)보다 오래된 작업의 건너뛰기가 가능하도록 설정합니다. 예를 들어, 하루보다 오래된 작업을 건너뛰도록 설정하려면 86400을 사용합니다. 0으로 설정하면 이 기능을 사용하지 않도록 설정됩니다.
      sseapi_command_age_limit:0
      참고:

      이 기능은 업그레이드 중에 데이터베이스에 저장된 이전 명령이 예기치 않게 실행되는 것을 방지하는 데 유용합니다.

    Salt의 이벤트 대기열과 Salt 마스터 플러그인의 대기열 엔진, 로드 캐싱, 입자 페이로드 크기 제한, 명령 경과 시간(age) 제한은 모두 함께 성능에 가장 민감한 코드 경로에서 처리량을 늘려주고 Salt 마스터와 Automation Config 간의 통신 지연을 줄여줍니다.

  6. 마스터 서비스를 다시 시작합니다.
    sudo systemctl restart salt-master
  7. 선택 사항: 마스터 플러그인이 마스터 노드와 RaaS 노드 간의 통신을 활성화하는지 확인하기 위해 테스트 작업을 실행할 수 있습니다.
    salt -v '*' test.ping
이제 RHEL 8/9 마스터가 마스터 키 페이지에 나타납니다.
경고: 이 시점에서 마스터 키를 수락하지 마십시오.

미니언 에이전트 구성

다음 단계에 따라 rhel9-master 노드의 미니언 에이전트가 자신을 가리키도록 구성합니다.
  1. SSH를 통해 rhel9-master 노드에 연결하고 /etc/salt/minion.d 디렉토리로 이동합니다.
  2. minion.conf 파일을 편집하고 마스터 설정을 master:localhost로 변경합니다.
  3. /etc/salt/pki/minion 디렉토리로 이동하여 minion_master.pub 파일을 삭제합니다.
  4. 다음을 사용하여 salt-minion 서비스를 다시 시작합니다.
    systemctl restart salt-minion
  5. 다음을 실행하여 rhel9-master에서 미니언 키를 보고 수락합니다. 
    salt-key
salt-key -A
  6. Automation Config에서 관리 > 마스터 키 로 이동한 후 마스터 키를 수락합니다.

    이제 RHEL8/9 마스터가 대상 페이지에 나타납니다.

  7. SSH를 통해 RHEL7 마스터에 연결하고 rhel9-master 미니언에 대한 키를 삭제합니다.

Salt-Minion 시스템 마이그레이션

관리되는 시스템을 마이그레이션하는 방법에는 여러 가지가 있습니다. 프로세스가 이미 설정되어 있는 경우 해당 프로세스를 따르십시오. 그렇지 않은 경우 다음 지침을 사용하여 salt-minion을 이전 Salt 마스터에서 새 Salt 마스터로 마이그레이션합니다.
참고: 이 단계는 다중 마스터 시스템에는 적용되지 않습니다.
  1. 오케스트레이션 파일을 생성합니다. 예를 들어, 
    # Orchestration to move Minions from one master to another
# file: /srv/salt/switch_masters/init.sls
{% import_yaml 'switch_masters/map.yaml' as mm %}
{% set minions = mm['minionids'] %}

{% if minions %}
{% for minion in minions %}
move_minions_{{ minion }}:
  salt.state:
    - tgt: {{ minion }}
    - sls:
      - switch_masters.move_minions_map

{% endfor %}    
{% else %}
no_minions:
  test.configurable_test_state:
    - name: No minions to move
    - result: True 
    - changes: False 
    - comment: No minions to move
{% endif %}

remove_minions:
  salt.runner:
    - name: manage.down
    - removekeys: True 

# map file for moving minions
# file: /srv/salt/switch_masters/map.yaml
newsaltmaster: <new_ip_address>
oldsaltmaster: <old_ip_address>
minionids:
  - minion01
  - minion02
  - minion03
state to switch minions from one master to another
# file: /srv/salt/swith_masters/move_minions_map.sls
{% set minion = salt['grains.get']('os') %}
# name old master and set new master ip address
{% import_yaml 'switch_masters/map.yaml' as mm %}
{% set oldmaster = mm['oldsaltmaster'] %}
{% set newmaster = mm['newsaltmaster'] %}

# remove minion_master.pub key
{% if minion == 'Windows' %}
remove_master_key:
  file.absent:
    - name: c:\ProgramData\Salt Project\Salt\conf\pki\minion\minion_master.pub

change_master_assignment:
  file.replace:
    - name: c:\ProgramData\Salt Project\Salt\conf\minion.d\minion.conf 
    - pattern: 'master: {{oldmaster}}'
    - repl: 'master: {{newmaster}}'
    - require:
      - remove_master_key
{% else %}
remove_master_key:
  file.absent:
    - name: /etc/salt/pki/minion/minion_master.pub

# modify minion config file
change_master_assignment:
  file.replace:
    - name: /etc/salt/minion.d/minion.conf 
    - pattern: 'master: {{oldmaster}}'
    - repl: 'master: {{newmaster}}'
    - require:
      - remove_master_key
{% endif %}
# restart salt-minion
restart_salt_minion:
  service.running:
    - name: salt-minion 
    - require:
      - change_master_assignment
    - watch:
      - change_master_assignment
  2. 다음을 포함하는 map.yaml 파일을 생성합니다(위 코드 예 참조).
    1. <old salt master> IP 주소/FQDN
    2. <new salt master> IP 주소/FQDN
    3. 이동할 saltminionID 목록
  3. 마이그레이션을 처리할 상태 파일(위 코드 예 참조)을 생성합니다. 예: move_minions_map.sls.
  4. 이러한 파일을 디렉토리(예: RHEL7 Salt 마스터의 /srv/salt/switch_masters)에 추가합니다.
  5. RHEL7 Salt 마스터에서 오케스트레이션 파일을 실행합니다. 이로 인해 오류가 발생합니다. Salt 미니언 서비스가 다시 시작되고 RHEL7 Salt 마스터에 대해 온라인 상태가 되지 않기 때문입니다.
  6. Automation Config에서 진행 상황을 모니터링합니다. Salt 미니언 ID가 UI에 채워지면 Salt 미니언 ID 마이그레이션을 수락합니다.
  7. 모든 시스템이 마이그레이션된 후 시스템에 대해 test.ping 작업을 실행하여 모든 시스템이 제대로 통신하고 있는지 확인합니다.

기존 파일 마이그레이션

이 프로세스는 조직이 상태 및 구성 파일을 생성, 저장 및 관리하는 방식에 전적으로 의존합니다. 가장 일반적인 사용 사례가 참조용으로 아래에 설명되어 있습니다.

사용 사례 1: Automation Config 파일 서버

이 사용 사례에서는 Automation Config 파일이 Postgres 데이터베이스에 저장되고 Automation Config UI에 나타납니다.

Postgres 데이터베이스 복원 중에 이러한 파일이 복구 및 마이그레이션됩니다. 이러한 파일을 RHEL8/9 환경으로 마이그레이션하기 위해 수행해야 하는 추가 단계는 없습니다.

사용 사례 2: Github/Gitlab 파일 서버

이 사용 사례에서는 Automation Config 상태 및 구성 파일이 Github/Gitlab/Bitbucket 또는 다른 코드 버전 제어 시스템에 저장됩니다.

이러한 파일은 타사 도구에 저장되므로 저장소 시스템에 연결하려면 새 RHEL8/9 마스터를 구성해야 합니다. 이 구성은 RHEL7 저장소 구성을 미러링합니다.

사용 사례 3: Salt 마스터의 로컬 파일 루트

이 사용 사례에서는 Automation Config가 Salt 마스터의 로컬 파일 서버 디렉토리에 저장됩니다.

이러한 파일을 RHEL8/9 마스터로 마이그레이션하려면 RHEL7 마스터에서 RHEL8/9 마스터로 적절한 디렉토리를 복사합니다.
  1. 파일은 상태 파일 및 pillar 파일에 대해 각각 /srv/salt 및 /srv/pillar에 저장됩니다.
  2. winscp 또는 명령줄과 같은 보안 복사 도구를 사용하여 RHEL7 마스터에서 RHEL8/9 마스터로 이러한 디렉토리의 보안 복사를 수행합니다.
  3. Salt \* saltutil.refresh_pillar를 사용하여 pillar 날짜를 새로 고칩니다.