NGINX 및 NGINX Plus 로 자동화하는 3가지 방법

이 포스트에서는 NGINX 및 NGINX Plus 를 사용하여 일반적인 Workflow를 자동화하는 3가지 방법을 다룹니다.

오늘날 많은 조직에서 수동 프로세스로 인해 애플리케이션 배포 및 관리 프로세스가 느려지고 있습니다. 수동 프로세스는 개발자와 운영팀에 추가 작업을 발생시키고 불필요한 지연을 유발하며 새로운 기능과 중요한 버그 및 보안 수정 사항을 고객에게 제공하는 데 걸리는 시간을 증가시킵니다. 도구, 스크립트 및 기타 기술을 사용하여 일반적인 작업을 자동화하는 것은 운영 효율성을 개선하고 새로운 기능과 애플리케이션의 출시를 가속화하는 좋은 방법입니다.

자동화를 통한 생산성 향상의 잠재적 개선 효과는 놀랍습니다. 적절한 구성 요소를 갖춘 일부 기업에서는 하루에 50회 이상 새로운 코드를 Production 환경에 배포하여 보다 안정적인 애플리케이션을 만들고 고객 만족도를 높일 수 있었습니다.

우수한 DevOps팀은 개발자가 거의 수동 개입 없이 새로운 기능, 보안 패치, 버그 수정 및 완전히 새로운 애플리케이션을 Production에 손쉽게 배포하는 데 사용하는 완전 자동화된 셀프 서비스 Pipeline을 구축하기 위해 NGINX Open Source 및 NGINX Plus를 사용합니다.

목차

1. 방법 1 – Production 환경에 새 애플리케이션 버전 배포하기
1-1. NGINX Plus API 사용
2. 방법 2 – 자동화된 Service Discovery
3. 방법 3 – 오케스트레이션 및 관리
4. 보너스 방법 – Jenkins를 사용한 Push-Button 배포
5. 결론

1. 방법 1 – Production 환경에 새 애플리케이션 버전 배포하기

새 버전을 출시하는 것은 모든 소프트웨어 애플리케이션의 수명 주기에서 가장 흔하게 발생하는 일 중 하나입니다. 업데이트의 일반적인 이유는 새로운 기능을 도입하거나 기존 기능의 버그를 수정하기 위해서입니다. 업데이트가 자동화되면 모든 서버에서 동시에 동일한 프로세스가 진행되도록 할 수 있고 Rollback 절차 또는 Fallback 코드를 정의할 수 있으므로 업데이트가 훨씬 간단해지고 시간도 단축됩니다.

자동화를 용이하게 하기 위해 NGINX Plus API를 사용하면 Upstream 서버 그룹을 동적으로 구성할 수 있습니다. API를 사용하면 배포 스크립트의 일부로 인스턴스를 추가하거나 제거하여 Upstream 서버 그룹을 수정할 수 있습니다. 변경 사항은 NGINX Plus에 즉시 반영되므로 배포 스크립트의 마지막 단계로 NGINX Load Balancer에 curl 요청을 하는 줄을 추가하기만 하면 서버가 자동으로 업데이트됩니다.

NGINX Plus API를 사용하려면 가상 서버의 구성 블록에 별도의 location 블록을 생성하고 api 지시문을 포함하세요. 이 location에는 기존 이름인 /api를 사용합니다. 인터페이스 사용을 로컬 LAN의 관리자로 제한하고 싶기 때문에 allow 및 deny 지시문도 포함합니다.

server {
    listen 8080;          # Listen on a local port, which can be protected by a firewall

    location /api {
        api write=on;
        allow 10.0.0.0/8; # Allow access only from LAN
        deny all;         # Deny everyone else
    }
}

API는 서버의 Upstream 그룹에 대한 정보를 저장하기 위해 공유 메모리 Zone이 필요하므로, 이 예제에서와 같이 구성에 zone 지시문을 포함시킵니다(예: backend).

upstream backend {
    zone backend 64k;
    server 10.2.2.90:8000;
    server 10.2.2.91:8000;
    server 10.2.2.92:8000;
}

1-1. NGINX Plus API 사용

업데이트된 버전의 애플리케이션을 호스팅하기 위해 IP 주소 10.2.2.93의 새 서버를 생성하고 이를 backend Upstream 그룹에 추가한다고 가정해 보겠습니다. POST 메서드로 curl을 실행하면 이 작업을 수행할 수 있습니다. (버전은 API 모듈의 참조 문서에 나와 있는 NGINX Plus API의 현재 버전으로 대체할 수 있습니다.)

# curl -X POST -d '{"server":"10.2.2.93:8000"}' http://localhost:8080/api/version/http/upstreams/backend/servers

그런 다음 이전 애플리케이션 버전을 실행하는 서버를 서비스에서 제거하려고 합니다. 해당 서버에 대한 모든 연결을 갑자기 종료하면 사용자 환경이 나빠질 수 있으므로 먼저 서버의 세션을 drain해야 합니다. 어떤 서버를 삭제할지 식별하려면 해당 서버의 내부 ID를 알아야 합니다. 각 서버의 호스트명 또는 주소와 ID만 필터링하기 위해 curl 출력을 jq 유틸리티로 Pipe합니다.

# curl -s http://localhost:8080/api/version/http/upstreams/backend | jq -c '.peers[] | {server, id}'
{"server":"10.2.2.90:8000","id":0}
{"server":"10.2.2.91:8000","id":1}
{"server":"10.2.2.92:8000","id":2}
{"server":"10.2.2.93:8000","id":3}

이전 애플리케이션 버전을 사용하는 서버의 IP 주소가 10.2.2.92이고 출력에 ID가 2라는 것을 알 수 있습니다. 서버를 drain 상태로 전환하는 명령에서 해당 ID로 서버를 식별합니다.

# curl -X PATCH -d '{"drain":true}' localhost:8080/api/version/http/upstreams/backend/servers/2

서버에 대한 Active 연결은 NGINX Plus API의 upstreams.peers.id.active JSON 응답 객체를 사용하여 추적할 수 있으며, 여기서 id는 위에서 검색한 서버의 ID 번호와 동일합니다. 서버에 대한 연결이 더 이상 없으면 이 curl 명령을 실행하여 Upstream 그룹에서 서버를 완전히 제거합니다.

# curl -X DELETE localhost:8080/api/version/http/upstreams/backend/servers/2

이는 API로 수행할 수 있는 작업의 샘플일 뿐이며, API를 사용하여 릴리스 프로세스를 완전히 자동화하는 Workflow를 스크립팅할 수 있습니다.

2. 방법 2 – 자동화된 Service Discovery

현대의 Microservice 기반 애플리케이션에는 하루에 여러 번 업데이트 및 배포되는 여러 인스턴스가 있는 수십 또는 수백 개의 서비스가 포함될 수 있습니다. 많은 수의 서비스를 배포하면 새 버전을 배포할 때마다 각 서비스를 수동으로 구성 및 재구성하거나 변동하는 트래픽 부하를 처리하기 위해 확장 및 축소하는 것이 어려워집니다.

서비스 검색(Service Discovery)을 사용하면 구성의 부담을 애플리케이션 인프라로 이전하여 전체 프로세스가 훨씬 쉬워집니다. NGINX와 NGINX Plus는 서비스 인스턴스 집합을 자동으로 업데이트하기 위한 여러 가지 서비스 검색(Service Discvoery) 방법을 지원합니다.

NGINX Plus는 익숙한 DNS 인터페이스를 사용하여 새로운 서비스 인스턴스를 자동으로 검색하고 오래된 인스턴스를 주기적으로 교체할 수 있습니다. 이 시나리오에서 NGINX Plus는 DNS SRV 레코드를 요청하여 서비스 레지스트리에서 사용 가능한 서비스의 최종 목록을 가져옵니다. DNS SRV 레코드에는 일반적으로 Microservice 아키텍처에서 동적으로 할당되는 서비스의 포트 번호가 포함되어 있습니다. 서비스 레지스트리는 Consul, SkyDNS/etcd 또는 ZooKeeper와 같은 여러 서비스 등록 도구 중 하나 일 수 있습니다.

다음 예제에서는 server 지시문의 service=http 매개변수를 통해 my_service Upstream 그룹에 있는 서버에 대한 DNS SRV 레코드를 요청하도록 NGINX Plus를 구성합니다. 그 결과, my_service를 백업하는 애플리케이션 인스턴스가 자동으로 검색됩니다.

http {
    resolver dns-server-ip;

    upstream my_service {
        zone backend 64k;
        server hostname-for-my_service service=http resolve;
    }
   server {
       # ...
       location /my_service {
            # ...
            proxy_pass http://my_service;
        }
    }
}

NGINX Open Source를 사용하면 consul-template와 같은 일반 구성 템플릿 도구를 사용할 수 있습니다. 새 서비스 인스턴스가 감지되면 새 서비스 인스턴스로 새 NGINX 구성이 생성되고 NGINX가 정상적으로 다시 로드됩니다.

3. 방법 3 – 오케스트레이션 및 관리

대기업에서는 애플리케이션 트래픽의 Load Balancing을 위해 Production 환경에 여러 개의 NGINX 또는 NGINX Plus 인스턴스를 배포할 수 있습니다. 이 경우 각각의 구성을 개별적으로 관리하기가 어려워지므로 Ansible, Chef, Puppet과 같은 구성 및 관리를 위한 DevOps 도구가 필요합니다. 이러한 도구를 사용하면 중앙 위치에서 구성을 관리하고 업데이트할 수 있으며, 여기서 변경 사항이 관리되는 모든 노드에 자동으로 적용됩니다.

NGINX Plus에는 프로세스를 자동화하고 인프라 및 애플리케이션 관리를 용이하게 하는 몇 가지 통합 지점이 있습니다.

  • Ansible – Ansible은 “Agent가 필요 없는” 프로비저닝 도구로, 표준 SSH를 사용하여 관리되는 서버에 직접 연결하기 때문에 가장 인기 있는 프로비저닝 도구 중 하나가 되었습니다(대상 서버에 작동하는 Python이 설치되어 있어야 합니다). 반면, Chef와 Puppet은 관리하려는 모든 서버에 소프트웨어 Agent를 설치해야 합니다.
  • Chef – Chef를 사용하여 NGINX를 설치하고 고가용성(HA) NGINX Plus 클러스터를 설정하는 튜토리얼을 게시했습니다. NGINX용 Chef Cookbook에는 NGINX를 관리하기 위한 여러 가지 방법이 나와 있습니다.
  • Puppet – Puppet으로 NGINX 및 NGINX Plus를 설치하는 방법에 대한 튜토리얼이 있습니다. Puppet에는 다양한 용도의 NGINX 모듈이 포함된 잘 관리된 GitHub Repository도 있습니다.

4. 보너스 방법 – Jenkins를 사용한 Push-Button 배포

Jenkins는 인기 있는 Open Source CI/CD 도구로, NGINX 및 NGINX Plus와 결합하면 더욱 강력해집니다. DevOps팀은 원하는 NGINX 구성 변경 사항을 GitHub에서 간단히 확인할 수 있으며, Jenkins는 이를 Production 서버로 배포합니다.

최근 Bluestem Brands 사례 연구에는 이 조합이 실제로 작동하는 좋은 예가 포함되어 있습니다. Bluestem Brands는 Jenkins를 사용하여 배포의 모든 측면을 자동화하고 동기화 상태를 유지합니다. 개발자가 코드를 업데이트하면 GitHub에서 Jenkins 빌드를 시작합니다. 코드 업데이트가 Upstream 애플리케이션 인스턴스에 배포된 후에는 간단한 API 호출만으로 깨끗한 캐시와 최신 코드를 갖춘 새 인스턴스가 요청을 처리하고 있는지 확인할 수 있습니다.

5. NGINX Plus 자동화 결론

대규모 배포를 유지 관리하는 것은 항상 어려운 일이지만 프로세스를 자동화하면 어려움을 어느 정도 완화할 수 있습니다. 자동화를 사용하면 테스트 가능한 절차를 만들고 중요한 프로세스를 코딩하여 DevOps팀의 모든 사람이 동일한 정보를 공유할 수 있습니다. 수많은 NGINX 사용자가 서비스 검색 자동화를 통해 복잡성을 줄이고, 수동 프로세스로 인한 버그를 제거하며, 새로운 기능을 Production에 더 쉽게 배포할 수 있었다고 이야기합니다.

NGINX Plus와 NGINX Open Source는 모두 첫 번째 인스턴스를 시작하든 수백 개의 인스턴스를 관리하든 관계없이 DevOps Workflow를 업데이트하고 아키텍처를 자동화하기 위한 다양한 통합 기능을 제공합니다.

NGINX Plus를 직접 사용해 보거나 테스트해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.