Overview
인프라의 규모가 수백 대에서 수만 대 단위로 확장될수록 서버 설정 관리와 원격 제어의 속도 및 신뢰성은 전체 서비스 안정성을 좌우하는 핵심 요소가 된다. 기존의 많은 엔지니어링 조직이 SSH 기반의 에이전트리스 도구인 Ansible을 활용해 왔으나, 대규모 동시 명령 실행 시 발생하는 SSH 연결 오버헤드와 순차 실행에 따른 지연 문제는 지속적인 운영 병목으로 지적되었다. 이러한 문제를 근본적으로 해결하기 위해 설계된 도구가 바로 고성능 비동기 메시징 버스인 ZeroMQ를 기반으로 동작하는 SaltStack(Salt)이다.
SaltStack은 이벤트 기반 아키텍처(Event-Driven Architecture)를 중심으로 중앙 Master와 노드 Minion 간의 양방향 통신을 지원하여 대규모 분산 노드에 초당 수천 개의 명령을 즉각적으로 전달하고 결과를 수집한다. 또한 인프라의 상태를 정의하는 State 시스템뿐만 아니라 실시간 원격 제어, 시스템 메타데이터 수집을 위한 Grains, 안전한 보안 파라미터 분리를 위한 Pillar를 유기적으로 결합하여 강력한 인프라 관리 플랫폼을 제공한다.
이 글에서는 SaltStack 2편 시리즈의 첫 번째 파트로서, SaltStack과 Ansible·Terraform·Puppet 등 주요 IaC 도구의 기술적 차이점을 심층 비교한다. 이어서 ZeroMQ 기반의 Master-Minion 통신 메커니즘과 포트 구조, Ubuntu 환경에서의 공식 패키지 기반 클러스터 구축 절차를 상세히 살펴본다. 나아가 `salt` CLI를 통한 복합 타겟팅 원격 실행 기법과 Grains 및 Pillar의 설계 원칙까지 실무 관점에서 완벽하게 정리한다.
1. 현대 구성 관리(Configuration Management)와 SaltStack 개요
IaC 도구 생태계 비교: SaltStack vs Ansible vs Terraform vs Puppet
인프라 자동화 생태계는 크게 클라우드 리소스를 프로비저닝하는 영역과 프로비저닝된 인스턴스 내부의 OS 설정 및 애플리케이션 수명주기를 관리하는 구성 관리(Configuration Management) 영역으로 나뉜다. Terraform이 클라우드 인프라의 뼈대를 생성하는 도구라면, SaltStack과 Ansible, Puppet은 생성된 서버의 상태를 일관되게 유지하는 역할을 담당한다.
| 비교 항목 | SaltStack | Ansible | Terraform | Puppet |
| 주요 목적 | 구성 관리 & 고속 원격 실행 | 구성 관리 & 배포 자동화 | 클라우드 인프라 프로비저닝 | 선언적 구성 관리 |
| 아키텍처 | Master-Minion (Masterless 지원) | Agentless (SSH/WinRM 기반) | Agentless (Cloud API 호출) | Master-Agent (Pull 모델 중심) |
| 통신 프로토콜 | ZeroMQ (비동기 이벤트 버스) | SSH (동기식 세션 연결) | HTTPS (클라우드 제공자 API) | HTTPS (정기적 Catalog Pull) |
| 실행 속도 | 초고속 (비동기 병렬 브로드캐스트) | 보통 (SSH 핸드셰이크 오버헤드) | API 레이턴시에 종속 | 주기적 실행 (30분 기본 폴링) |
| 이벤트 기반 제어 | 지원 (Beacons & Reactor 내장) | 제한적 (Event-Driven Ansible 별도) | 미지원 (상태 비교 위주) | 지원 (외부 이벤트 연동 필요) |
| 언어 및 문법 | Python / YAML + Jinja2 | Python / YAML + Jinja2 | HCL (HashiCorp Config Lang) | Ruby / Puppet DSL |
Ansible은 별도의 에이전트 설치 없이 SSH 키만으로 즉시 구성을 적용할 수 있어 진입 장벽이 낮고 초기 구축이 용이하다. 그러나 노드 수가 수천 대 규모로 증가하면 SSH 연결 생성과 Python 인터프리터 업로드 과정에서 막대한 CPU 및 네트워크 지연이 발생한다. 반면 SaltStack은 상주형 데몬(Minion)이 Master와 영구적인 ZeroMQ 소켓을 유지하므로 커넥션 오버헤드가 사실상 전무하며, 초당 수천 대의 서버에 즉각적인 명령 디스패치가 가능하다.
SaltStack의 핵심 강점: 왜 대규모 환경에서 SaltStack인가?
SaltStack의 최대 강점은 속도와 이벤트 주도형 오케스트레이션(Event-Driven Orchestration)이다. Master는 발행-구독(Publish-Subscribe) 패턴을 통해 대상 노드 전체에 명령을 한 번에 뿌리고, Minion은 로컬 백그라운드에서 작업을 처리한 뒤 결과만을 비동기로 Master에 반환한다.
또한 SaltStack은 단순한 단방향 배포 도구를 넘어선다. Minion 내부에 탑재된 Beacon 엔진이 특정 프로세스의 중단, 디스크 용량 초과, 중요 설정 파일의 변경 등의 이벤트를 감지하면 이를 Master의 이벤트 버스로 즉시 발송한다. Master의 Reactor 시스템은 수신된 이벤트를 트리거로 삼아 자동으로 치유 작업을 수행하는 자가 치유(Self-Healing) 인프라를 손쉽게 구축할 수 있다.
2. SaltStack 아키텍처와 ZeroMQ 통신 메커니즘
Master-Minion 구조와 포트 바인딩 (TCP 4505 & TCP 4506)
SaltStack 클러스터의 중앙에는 `salt-master` 서비스가 위치하며, 관리 대상 서버들에는 `salt-minion` 서비스가 상주한다. 이들 간의 통신은 오직 Master의 두 개 인바운드 포트를 통해서만 이루어지므로, Minion 측에서는 어떠한 인바운드 포트도 개방할 필요가 없다.
+------------------------------------------------------------------------+
| Salt Master |
| |
| +-----------------------------+ +--------------------------+ |
| | ZeroMQ PUB (TCP 4505) | | ZeroMQ ROUTER (TCP 4506)| |
| | (Publisher: 명령 브로드캐스트) | | (Request/Reply: 결과/파일) | |
| +--------------+--------------+ +------------^-------------+ |
+-------------------|---------------------------------|------------------+
| |
AES 암호화 이벤트 전달 작업 결과 반환 및 파일 요청
| |
+-------------------|---------------------------------|------------------+
| v | |
| +-----------------------------+ +------------+-------------+ |
| | ZeroMQ SUB (Subscriber) | | ZeroMQ REQ (Requester) | |
| +-----------------------------+ +--------------------------+ |
| |
| Salt Minion |
+------------------------------------------------------------------------+
두 포트의 기술적 역할과 동작 방식은 다음과 같다.
- TCP 4505 (Publisher Port): Master가 발행하는 모든 명령과 이벤트가 송출되는 ZeroMQ PUB 소켓 포트이다. 클러스터 내의 모든 Minion은 시작과 동시에 Master의 4505 포트에 SUB 소켓으로 연결하여 대기한다. Master가 명령을 전송하면 ZeroMQ 버스를 통해 전체 Minion에 병렬로 복제 전송된다.
- TCP 4506 (Request-Reply Port): Minion이 Master에게 특정 데이터를 요청하거나 작업 실행 결과를 보고할 때 사용하는 ZeroMQ ROUTER 소켓 포트이다. Minion의 초기 인증 키 교환, Pillar 보안 데이터 조회, 파일 서버의 템플릿 다운로드, 명령 실행 완료 후 반환값 전송이 이 포트를 통해 처리된다.
이러한 단방향 아웃바운드 구조 덕분에 방화벽이나 NAT(Network Address Translation) 환경 뒤에 위치한 서버라도 Master의 4505 및 4506 포트로의 아웃바운드 트래픽만 허용되어 있다면 원활하게 제어할 수 있다.
공개키(AES/RSA) 기반 상호 인증과 보안 키 교환 라이프사이클
SaltStack은 신뢰할 수 없는 네트워크 환경에서도 완벽한 보안을 유지하기 위해 비대칭키(RSA)와 대칭키(AES)를 혼합한 정교한 키 교환 시스템을 사용한다.
- 키 생성 및 제출: Minion 서비스가 최초 실행될 때 자체적인 4096비트 RSA 키 쌍(`/etc/salt/pki/minion/minion.pem`, `minion.pub`)을 생성한다. 이후 Master의 4506 포트로 접속하여 자신의 공개키(`minion.pub`)를 전송한다.
- Master 키 검증 및 승인: Master는 수신한 공개키를 `/etc/salt/pki/master/minions_pre/` 디렉터리에 보관하고 대기 상태(Unaccepted)로 둔다. 관리자가 `salt-key` 명령어로 키의 핑거프린트를 검증하고 승인하면 해당 키는 `/etc/salt/pki/master/minions/` 디렉터리로 이동한다.
- 세션 암호화 키 배포: 키가 승인되면 Master는 자신이 주기적으로 순환시키는 AES 세션 키를 Minion의 RSA 공개키로 암호화하여 전달한다.
- 암호화 통신: 이후 4505 포트를 통해 브로드캐스트되는 모든 명령 페이로드는 AES 세션 키로 암호화되며, 승인된 Minion만이 이를 복호화하여 실행할 수 있다.
3. SaltStack 환경 구축 실전: Master 및 Minion 설치와 클러스터 연동
공식 Salt 리포지토리 설정 (Ubuntu 24.04/22.04 LTS)
SaltStack 공식 패키지는 과거 saltstack.com 저장소에서 Broadcom 인수 이후 새로운 공식 CDN 저장소(`packages.broadcom.com`)로 이전되었다. 최신 보안 패치가 적용된 버전을 사용하기 위해 공식 GPG 키링과 APT 저장소를 등록한다.
Master 노드와 Minion 노드 모두에서 아래 명령을 실행하여 패키지 저장소를 설정한다.
# 1. 필수 도구 설치 및 키링 디렉터리 생성
sudo apt-get update && sudo apt-get install -y curl gnupg lsb-release
sudo mkdir -p /etc/apt/keyrings
# 2. Salt Project 공식 GPG 서명 키 다운로드 및 변환
curl -fsSL https://packages.broadcom.com/artifactory/api/security/keypair/SaltProjectKey/public | sudo gpg --dearmor -o /etc/apt/keyrings/salt-archive-keyring.gpg
# 3. APT 저장소 소스 리스트 등록
echo "deb [signed-by=/etc/apt/keyrings/salt-archive-keyring.gpg arch=amd64] https://packages.broadcom.com/artifactory/saltproject-deb/ stable main" | sudo tee /etc/apt/sources.list.d/salt.list
# 4. 패키지 인덱스 갱신
sudo apt-get update
Salt Master 설치 및 마스터 구성 (`/etc/salt/master`)
마스터 역할을 수행할 서버에서 `salt-master` 패키지를 설치하고 설정을 구성한다.
sudo apt-get install -y salt-master salt-minion
`/etc/salt/master` 설정 파일에서 핵심 파라미터를 정의한다. 대규모 인프라 운영 시 워커 스레드와 파일 서빙 디렉터리 지정이 필수적이다.
# /etc/salt/master 설정 예시
interface: 0.0.0.0
publish_port: 4505
ret_port: 4506
# 동시 처리 워커 스레드 수 (CPU 코어 수에 비례하여 설정)
worker_threads: 8
# State 및 파일 서빙을 위한 기본 루트 경로
file_roots:
base:
- /srv/salt
# Pillar 보안 데이터 루트 경로
pillar_roots:
base:
- /srv/pillar
# 자동 키 승인 비활성화 (보안상 수동 승인 권장)
auto_accept: False
설정 완료 후 서비스를 활성화하고 시작한다.
sudo systemctl enable --now salt-master
sudo systemctl status salt-master --no-pager
Salt Minion 설치 및 마스터 연동 (`/etc/salt/minion`)
관리 대상 서버(Minion)에는 `salt-minion` 패키지만 설치한다.
sudo apt-get install -y salt-minion
`/etc/salt/minion` 파일에서 Master 서버의 IP 주소와 고유 Minion ID를 지정한다.
# /etc/salt/minion 설정 예시
# Master 서버의 도메인 또는 IP 지정 (예시 IP: 198.51.100.10)
master: 198.51.100.10
# 해당 미니언의 고유 식별자 (지정하지 않을 경우 FQDN 사용)
id: web-node-01.example.com
# 재연결 및 타임아웃 튜닝
recon_default: 1000
recon_max: 5000
서비스를 시작하면 Minion이 Master로 접속하여 자신의 공개키를 등록 요청한다.
sudo systemctl enable --now salt-minion
`salt-key`를 활용한 클러스터 노드 인증 및 관리
Master 서버에서 `salt-key` 유틸리티를 사용하여 접속을 요청한 Minion 노드들의 공개키 상태를 확인하고 승인한다.
# 1. 키 목록 조회
sudo salt-key -L
출력 결과:
Accepted Keys:
Denied Keys:
Unaccepted Keys:
web-node-01.example.com
web-node-02.example.com
Rejected Keys:
키 핑거프린트를 대조한 후 특정 Minion 또는 전체 노드를 승인한다.
# 특정 Minion 키 승인
sudo salt-key -a web-node-01.example.com -y
# 또는 대기 중인 모든 키 일괄 승인
sudo salt-key -A -y
승인이 완료되면 `test.ping` 모듈을 실행하여 클러스터 연결 상태를 즉각 검증한다.
sudo salt '*' test.ping
출력 결과:
web-node-01.example.com:
True
web-node-02.example.com:
True
4. Salt Execution Modules: 실시간 원격 명령 실행 및 타겟팅 실전
타겟팅(Targeting) 기법: Globbing, 정규표현식, 그리고 복합 매처(Compound Matcher)
SaltStack은 관리 대상 노드를 세밀하게 필터링할 수 있는 강력한 타겟팅 문법을 제공한다. 호스트명뿐만 아니라 OS 종류, CPU 아키텍처, 네트워크 서브넷, 커스텀 태그를 조합하여 명령을 전송할 수 있다.
| 타겟팅 유형 | 플래그 | 명령어 예시 | 설명 | |
| Globbing (기본) | 기본 | `salt 'web*.example.com' test.ping` | 쉘 스타일 와일드카드 매칭 | |
| 정규식 (PCRE) | `-E` | `salt -E 'web-(01\ | 02)\..*' test.ping` | 정규표현식 기반 호스트명 매칭 |
| 목록 (List) | `-L` | `salt -L 'node-01,node-02' test.ping` | 쉼표로 구분된 특정 노드 리스트 | |
| Grains 매칭 | `-G` | `salt -G 'os:Ubuntu' test.ping` | 미니언의 Grains 속성 기반 타겟팅 | |
| Pillar 매칭 | `-I` | `salt -I 'role:database' test.ping` | 미니언에 할당된 Pillar 데이터 매칭 | |
| 서브넷 (CIDR) | `-S` | `salt -S '192.0.2.0/24' test.ping` | IP 서브넷 대역 기준 타겟팅 | |
| 복합 매처 (Compound) | `-C` | `salt -C 'G@os:Ubuntu and not web-01*' test.ping` | 여러 조건을 AND/OR/NOT으로 결합 |
특히 복합 매처(`-C`)는 엔터프라이즈 환경에서 매우 유용하다. `G@`는 Grains, `I@`는 Pillar, `L@`는 List, `S@`는 서브넷을 의미하며 이를 논리 연산자로 결합할 수 있다.
# Ubuntu 운영체제이면서 198.51.100.0/24 대역에 속한 web 서버군에만 명령 실행
sudo salt -C 'G@os:Ubuntu and S@198.51.100.0/24 and web*' test.ping
실무 핵심 실행 모듈(Execution Modules) 활용
SaltStack은 시스템 제어를 위해 수백 개의 내장 Execution Module을 제공한다. 에이전트 내부에서 Python API를 통해 직접 실행되므로 쉘 스크립트 실행보다 훨씬 높은 성능과 일관성을 보장한다.
# 1. 원격 명령어 실행 (cmd.run)
sudo salt 'web*' cmd.run 'uptime'
# 2. 패키지 설치 및 버전 조회 (pkg 모듈)
sudo salt 'web*' pkg.install nginx
sudo salt 'web*' pkg.version nginx
# 3. 서비스 상태 점검 및 재시작 (service 모듈)
sudo salt 'web*' service.status nginx
sudo salt 'web*' service.restart nginx
# 4. 네트워크 정보 및 IP 조회 (network 모듈)
sudo salt 'web*' network.ip_addrs
# 5. 디스크 및 시스템 리소스 현황 (disk, status 모듈)
sudo salt 'web*' disk.usage
sudo salt 'web*' status.loadavg
비동기 작업(Job) 관리와 캐시 구조 (`salt-run jobs`)
대규모 노드에서 시간이 오래 걸리는 작업(예: 대용량 패키지 업그레이드, 커널 업데이트)을 실행할 때는 터미널 연결을 유지하지 않고 비동기(`--async`)로 디스패치해야 한다.
# 비동기 실행 시 즉시 고유한 Job ID (JID)를 반환한다
sudo salt 'web*' --async pkg.upgrade
출력 결과:
Executed command with job ID: 20270608123045123456
발행된 작업의 상태와 실행 결과는 JID를 통해 실시간으로 추적하거나 나중에 조회할 수 있다.
# 현재 실행 중인 활성 작업 목록 확인
sudo salt-run jobs.active
# 특정 JID의 실행 결과 조회
sudo salt-run jobs.lookup_jid 20270608123045123456
# 최근 24시간 동안 실행된 작업 이력 요약
sudo salt-run jobs.list_jobs
5. Grains와 Pillar: 정적 인벤토리와 보안 데이터의 분리
SaltStack 데이터 아키텍처의 핵심은 시스템 자체의 물리적 특성을 나타내는 Grains와 사용자가 중앙에서 통제하는 비즈니스/보안 데이터인 Pillar를 명확히 분리하는 데 있다.
+-------------------------------------------------------------------------+
| Salt Master |
| |
| +-----------------------------------------------------------------+ |
| | Pillar 데이터 저장소 | |
| | - 데이터 소유: Master가 보유 | |
| | - 보안성: 대상 Minion에게만 암호화 전송 | |
| | - 용도: DB 암호, API 토큰, SSL 인증서, 역할별 환경 변수 | |
| +--------------------------------+--------------------------------+ |
+------------------------------------|------------------------------------+
| Minion별 맞춤 암호화 전송
+------------------------------------|------------------------------------+
| v |
| +-----------------------------------------------------------------+ |
| | Grains 데이터 수집기 | |
| | - 데이터 소유: Minion 로컬에서 수집 | |
| | - 특성: OS, CPU, IP, 하드웨어 아키텍처 등 정적 인벤토리 | |
| | - 용도: 타겟팅 필터링, 하드웨어 기반 조건 분기 | |
| +-----------------------------------------------------------------+ |
| |
| Salt Minion |
+-------------------------------------------------------------------------+
Grains: 미니언 정적 시스템 속성 수집 및 커스텀 Grains 정의
Grains는 Minion이 시작될 때 로컬 시스템에서 직접 수집하는 정적 메타데이터이다. CPU 코어 수, 메모리 용량, OS 릴리스, IP 주소 등이 자동으로 포함된다.
# 미니언의 전체 Grains 항목 조회
sudo salt 'web-node-01*' grains.items
# 특정 Grains 값 단일 조회
sudo salt 'web-node-01*' grains.item os osrelease cpu_model
시스템 기본 정보 외에 비즈니스적인 태그(예: 서버 역할, 배포 환경)를 부여하고자 할 경우 Minion 설정 파일이나 `/etc/salt/grains` 파일에 직접 정의할 수 있다.
# Minion 노드의 /etc/salt/grains 파일 작성 예시
roles:
- webserver
- frontend
deployment_zone: ap-northeast-2a
environment: production
설정 후 Master에서 즉시 커스텀 Grains를 재동기화하여 필터링 조건으로 사용한다.
# Grains 정보 새로고침
sudo salt 'web*' saltutil.sync_grains
# 커스텀 Grains 기반 타겟팅 검증
sudo salt -G 'roles:webserver' test.ping
Pillar: 마스터 중심의 보안 변수 및 중앙 집중식 데이터 관리
Grains가 Minion이 자신의 정보를 Master에게 알리는 상향식 데이터라면, Pillar는 Master가 특정 Minion에게만 인가된 비밀 정보와 설정값을 내려주는 하향식 보안 데이터 저장소이다. 다른 Minion은 절대로 타 노드의 Pillar 데이터를 볼 수 없다.
Pillar를 구성하기 위해 Master의 `/srv/pillar` 디렉터리에 최상위 매핑 파일(`top.sls`)과 변수 파일을 생성한다.
sudo mkdir -p /srv/pillar/web
먼저 웹 서버군에 적용할 변수 파일 `/srv/pillar/web/init.sls`를 정의한다.
# /srv/pillar/web/init.sls
web_config:
http_port: 80
server_name: service.example.com
database:
host: 198.51.100.50
user: web_app_user
password: SuperSecretPassword123!
이 데이터를 어떤 Minion에게 매핑할지 결정하는 `/srv/pillar/top.sls` 파일을 작성한다.
# /srv/pillar/top.sls
base:
'web*':
- web
Pillar 데이터를 Minion에 배포하고 검증한다.
# 1. 모든 Minion의 Pillar 캐시 동기화
sudo salt '*' saltutil.refresh_pillar
# 2. 특정 Minion에 할당된 Pillar 데이터 확인
sudo salt 'web-node-01*' pillar.items
Grains vs Pillar 핵심 비교 및 실무 설계 원칙
두 데이터 저장소의 핵심 차이를 이해하는 것은 SaltStack 아키텍처 설계의 첫걸음이다.
| 구분 | Grains | Pillar |
| 생성 및 수집 주체 | Minion (로컬에서 자체 수집) | Master (중앙에서 작성 및 관리) |
| 데이터 저장 위치 | Minion 메모리 및 캐시 | Master 디렉터리 (`/srv/pillar`) |
| 갱신 주기 | Minion 재시작 시 또는 sync 호출 시 | `saltutil.refresh_pillar` 호출 시 즉시 반영 |
| 보안 수준 | 평문 노출 (누구나 로컬에서 조회 가능) | 고보안 (대상 Minion만 암호화 수신) |
| 주 사용 목적 | 시스템 사양 기반 타겟팅, 하드웨어 분기 | 패스워드, API 키, 인증서, 인프라 환경 변수 |
실무 설계 시 Grains에는 절대로 패스워드나 인증 키와 같은 민감 데이터를 저장해서는 안 된다. 시스템의 스펙이나 고유 역할을 명시할 때만 Grains를 사용하고, 계정 정보와 포트 번호, 환경별 구성값은 반드시 Pillar를 통해 엄격히 통제해야 한다.
6. 실무 운영 및 성능 튜닝 모범 사례
ZeroMQ 소켓 버퍼 및 Keepalive 네트워크 튜닝
수천 대의 Minion이 동시에 연결되는 대규모 환경에서는 네트워크 유실과 좀비 소켓을 방지하기 위해 `/etc/salt/master`와 `/etc/salt/minion`의 ZeroMQ 네트워크 파라미터를 최적화해야 한다.
# /etc/salt/master 네트워크 최적화 예시
# TCP Keepalive 활성화로 끊어진 세션 조기 감지
tcp_keepalive: True
tcp_keepalive_idle: 300
tcp_keepalive_cnt: 3
tcp_keepalive_intvl: 15
# 소켓 버퍼 크기 증가
pub_hwm: 50000
max_event_backlog: 50000
대규모 노드 환경 배치(Batch) 실행 전략 (`salt --batch-size`)
수천 대의 서버에 동시에 패키지 설치나 재시작 명령을 전송하면 중앙 리포지토리나 내부 네트워크 스위치에 순간적인 트래픽 급증(Thundering Herd 문제)이 발생할 수 있다. 이때 `--batch-size` 옵션을 활용하여 롤링 업데이트 방식으로 명령을 분할 실행한다.
# 10대씩 순차적으로 실행
sudo salt 'web*' --batch-size 10 pkg.upgrade
# 전체 대상 노드의 20% 단위로 단계적 실행
sudo salt 'web*' --batch-size 20% service.restart nginx
마스터리스(Masterless) 모드와 `salt-call` 활용법
중앙 Master 서버를 두지 않고 단일 서버 내부에서 로컬 파일 시스템의 State와 Pillar만을 참조하여 독립적으로 설정을 프로비저닝할 수도 있다. 이는 Packer를 활용한 골든 이미지(AMI) 빌드 과정이나 CI/CD 컨테이너 생성 단계에서 매우 유용하다.
# Minion에서 로컬 마스터리스 모드로 파일 실행 (/etc/salt/minion: file_client: local 설정)
sudo salt-call --local test.ping
sudo salt-call --local grains.items
마무리
SaltStack은 ZeroMQ 기반의 비동기 메시징 버스를 채택하여 기존 SSH 기반 에이전트리스 도구가 지닌 성능적 한계를 뛰어넘은 차세대 인프라 자동화 플랫폼이다. TCP 4505와 4506이라는 단 두 개의 아웃바운드 포트만으로 수만 대의 노드를 실시간으로 통제할 수 있는 아키텍처는 대규모 엔터프라이즈 환경에서 독보적인 경쟁력을 발휘한다.
이번 Part 1에서는 Ansible 등 기존 IaC 도구와의 구조적 차이점을 짚어보고, Master-Minion 클러스터의 설치와 암호화 키 교환, 복합 타겟팅 원격 실행 기법, 그리고 Grains와 Pillar의 분리 설계 원칙을 실전 예제와 함께 정리하였다.
이어지는 Part 2에서는 이번에 구축한 Master-Minion 환경을 바탕으로, SLS 파일을 활용한 선언적 State 시스템과 Requisites 의존성 제어, Jinja2 템플릿 결합 실무 배포 파이프라인, 그리고 Beacons와 Reactor를 결합한 실시간 자가 치유(Self-Healing) 자동화 아키텍처를 심도 있게 다룰 예정이다.
Reference
'IaC > Configuration Management' 카테고리의 다른 글
| Git Stash로 Pull 충돌 해결하기 (0) | 2026.08.13 |
|---|---|
| Git에서 2개의 계정(SSH Key) 사용하기 (2) | 2024.06.13 |
| Git Rebase vs Merge (0) | 2024.06.03 |
| Ansible 활용 - ansible-galaxy에 Role/Collection 업로드 (0) | 2023.12.25 |
| Ansible 개념과 설치 / 사용법(CentOS 7.9) (0) | 2022.02.07 |