
클러스터에서 NGINX 구성 동기화하기
NGINX Plus 인스턴스 클러스터 전체에서 구성을 동기화합니다. 고가용성 배포를 위해 설계되었지만 이 솔루션은 모든 클러스터에서 작동합니다.
목차
1. 개요
2. 지침
2-1. Primary 머신에 nginx-sync를 설치합니다.
2-2. Peer에 대한 root SSH 액세스 구성하기
2-3. Primary 노드에서 nginx-sync.conf 구성 파일을 생성합니다.
2-4. 구성 테스트
3. 자주 묻는 질문
3-1. root에 SSH 액세스 권한을 부여해야 하는 이유
3-2. 기본 구성이 실패하면 어떻게 동기화하나요?
3-3. Peer 노드에 장애가 발생하면 어떻게 되나요?
1. 개요
NGINX Plus 는 두 대 이상의 장치로 구성된 고가용성(HA) 클러스터에 배포되는 경우가 많습니다. 구성 공유 기능을 사용하면 클러스터의 Primary 머신 한 대에서 Peer 머신으로 구성을 Push할 수 있습니다.

이 기능을 구성하려면 다음을 수행합니다.
1. Primary 머신에 nginx-sync 패키지를 설치합니다.
2. Primary 머신에 Peer 머신에 root
로 ssh 액세스 권한을 부여합니다.
3. Primary 머신에서 구성 파일 /etc/nginx-sync.conf를 생성합니다.
NODES="node2.example.com node3.example.com node4.example.com"
CONFPATHS="/etc/nginx/nginx.conf /etc/nginx/conf.d"
EXCLUDE="default.conf"
4. Primary에서 nginx-sync.sh
명령을 실행하여 CONFPATHS
에 있는 구성 파일 이름을 지정된 NODES
로 푸시하고 EXCLUDE
에 있는 구성 파일은 생략합니다.
nginx-sync.sh
에는 여러 가지 안전 검사 기능이 포함되어 있습니다.
- 진행하기 전에 시스템 사전 요구 사항을 확인합니다.
- 로컬(Primary) 구성의 유효성을 검사하고(
nginx -t
) 실패하면 종료합니다. - 각 Peer에 구성의 원격 백업을 생성합니다.
rsync
를 사용하여 기본 구성을 Peer로 Push하고, Peer에서 구성의 유효성을 검사하고(nginx -t
), 성공하면 Peer에서 NGINX Plus 를 Reload합니다(service nginx reload
).- 단계가 실패하면 Peer에 있는 백업으로 Rollback합니다.
2. 지침
2-1. Primary 머신에 nginx-sync를 설치합니다.
RHEL 또는 CentOS의 경우:
$ sudo yum install nginx-sync
Ubuntu 또는 Debian의 경우:
$ sudo apt-get install nginx-sync
2-2. Peer에 대한 root SSH 액세스 구성하기
이 절차를 통해 Primary 노드의 root
사용자는 각 Peer의 root
계정으로 ssh할 수 있으며, 이는 Peer에 파일을 rsync
하고 Peer에서 명령을 실행하여 구성의 유효성을 검사하고 NGINX Plus 를 Reload하는 등의 작업을 수행하는 데 필요합니다.
1. Primary 노드에서 root
에 대한 SSH 인증 키 쌍을 생성하고 키의 공개 부분을 확인합니다.
$ sudo ssh-keygen -t rsa -b 2048
$ sudo cat /root/.ssh/id_rsa.pub
ssh-rsa AAAAB3Nz4rFgt...vgaD root@node1
2. Primary 노드의 IP 주소를 가져옵니다(다음 예제에서는 192.168.1.2
).
$ ip addr
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:34:6c:35 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe34:6c35/64 scope link
valid_lft forever preferred_lft forever
3. 각 Peer 노드에서 root
의 authorized_keys 파일에 Public Key를 추가합니다. from=192.168.1.2
접두사는 Primary 노드의 IP 주소로만 액세스를 제한합니다.
$ sudo mkdir /root/.ssh
$ sudo echo ‘from=”192.168.1.2" ssh-rsa AAAAB3Nz4rFgt...vgaD root@node1' >> /root/.ssh/authorized_keys
4. etc/ssh/sshd_config에 다음 줄을 추가합니다.
PermitRootLogin without-password
5. 각 Peer( Primary는 제외)에서 sshd
를 Reload하여 SSH Key 인증을 허용합니다.
RHEL 또는 CentOS의 경우:
$ sudo service sshd reload
Ubuntu 또는 Debian의 경우:
$ sudo service ssh reload
6. root
사용자가 비밀번호를 제공하지 않고도 다른 각 노드에 ssh
할 수 있는지 확인합니다.
$ sudo ssh root@node2.example.com <hostname>
2-3. Primary 노드에서 nginx-sync.conf 구성 파일을 생성합니다.
Primary 노드에서 다음과 같은 내용으로 /etc/nginx-sync.conf 파일을 생성합니다.
NODES="node2.example.com node3.example.com node4.example.com"
CONFPATHS="/etc/nginx/nginx.conf /etc/nginx/conf.d"
EXCLUDE="default.conf"
공통 매개변수
공백 또는 개행 문자를 사용하여 각 목록의 항목을 구분합니다.
NODES
– 기본 설정에서 구성을 수신하는 Peer 목록CONFPATHS
– Primary에서 Peer로 배포할 파일 및 디렉터리 목록EXCLUDE
– (선택 사항) Peer에게 배포하지 않을 Primary 구성 파일 목록
고급 매개변수
BACKUPDIR
-각 Peer에서 백업 위치(기본값 /var/lib/nginx-sync)DIFF
– diff Binary 위치(기본값 /usr/bin/diff)LOCKFILE
– 한 번에 하나의nginx-sync
작업만 실행되도록 하는 데 사용되는 잠금 파일의 위치(기본값 /tmp/nginx-sync.lock)NGINX
– nginx-plus Binary 위치(기본값 /usr/sbin/nginx)POSTSYNC
– 각 원격 노드에서 수행할 파일 치환의 공백으로 구분된 목록으로,'<filename>|<sed-expression>'
형식입니다. 치환이 적용됩니다.
sed -i'' <sed-expression> <filename>
예를 들어, 이 명령은 keepalived.conf에서 node2.example.com의 IP 주소(192.168.2.2)를 node1.example.com의 IP 주소(192.168.2.1)로 대체합니다.
POSTSYNC="/etc/keepalived/keepalived.conf|'s/192\.168\.2\.1/192.168.2.2/'"
RSYNC
–rsync
Binary 위치(기본값 /usr/bin/rsync)SSH
–ssh
Binary 위치(기본값 /usr/bin/ssh)
2-4. 구성 테스트
테스트하기 전에 구성을 백업하세요.
- 구성 동기화 및 Peer에서 NGINX Plus Reload –
nginx-sync.sh
- 사용량 정보 표시 –
nginx-sync.sh -h
- Primary 구성과 Peer 간의 구성 비교 –
nginx-sync.sh -c
- Primary 구성과 모든 Peer 구성 비교 –
nginx-sync.sh -C
3. 자주 묻는 질문
3-1. root
에 SSH 액세스 권한을 부여해야 하는 이유
Primary 노드는 root
사용자로서 Peer에서 원격으로 명령을 실행할 수 있어야 하며(예: service nginx reload
), root
가 소유한 구성 파일(예: /etc/nginx/에 있음)을 업데이트할 수 있어야 합니다.
root
에 SSH 액세스 권한을 부여하는 것은 너무 많은 권한을 부여하는 것처럼 보일 수 있지만, 원격 NGINX Plus 구성을 작성하고 원격 NGINX Plus 프로세스를 Reload할 수 있는 모든 프로세스가 이 프로세스를 무력화하여 서버에 대한 원격 root
액세스 권한을 얻을 수 있다는 점을 기억하는 것이 중요합니다.
따라서 Primary 노드에서 root
액세스 권한을 얻은 사용자는 Peer 노드에서도 root
액세스 권한을 가진다고 가정합니다.
3-2. Primary 구성이 실패하면 어떻게 동기화하나요?
Primary 계정에서 장애가 발생하여 곧 서비스를 재개할 수 없는 경우에는 설치의 안내에 따라 Peer를 Primary 계정으로 승격시켜야 합니다. 여기에는 다음이 포함됩니다.
여러 대의 머신이 Primary 노드로 작동하도록 사전 구성할 수 있지만, 주어진 시간에 실제로 하나의 노드만 Primary 노드로 실행되도록 해야 합니다.
3-3. Peer 노드에 장애가 발생하면 어떻게 되나요?
Peer 노드가 실패하면 더 이상 구성 업데이트를 받지 못합니다. nginx-sync.sh
스크립트는 오류를 반환하지만 나머지 Peer에 구성을 계속 배포합니다.
노드가 복구되면 구성이 오래된 것입니다. nginx-sync.sh -c <recovered-peer-node> -d
를 실행하여 구성 차이를 표시할 수 있습니다.
$ nginx-sync.sh -c node2.example.com -d
명령의 출력입니다.
diff -ru /tmp/localconf.1XrIqP7f/etc/nginx/conf.d/responder.conf /tmp/remoteconf.Xq5LWGKU/etc/nginx/conf.d/responder.conf
--- /tmp/localconf.1XrIqP7f/etc/nginx/conf.d/responder.conf 2020-09-25 10:29:36.988064021 -0800
+++ /tmp/remoteconf.Xq5LWGKU/etc/nginx/conf.d/responder.conf 2020-09-25 10:28:39.764066539 -0800
@@ -4,6 +4,6 @@
listen 80;
location / {
- return 200 "Received request on $server_addr on host $hostname blue\n";
+ return 200 "Received request on $server_addr on host $hostname red\n";
}
}
* Synchronization ended at Fri Sep 25 18:30:49 UTC 2020
다음으로 nginx-sync.sh
를 실행하면 노드가 현재 Primary 구성으로 업데이트됩니다.