NGINX 컨트롤러를 통한 보다 안전한 구성 관리

지난 1년 동안 고객과 대화하면서 우리는 NGINX Controller 와 같은 오케스트레이션 제품을 평가하도록 동기를 부여하는 몇 가지 반복적인 주제를 발견했습니다.

• 복잡성 – 다양한 소스에서 수집된 대량의 개별 구성 객체를 관리, 유지, 검증하고 적용하는 일은 쉽지 않습니다.
• 취약성 – 확장은 종종 사건에 대한 대응으로 빠르게 발생할 수 있습니다. 때로는 전략적이기도 하지만, 다른 운영 부서에서 흔히 그렇듯 계획되지 않고 자연스럽게 진행되는 경우가 많습니다.
• 안전성 – 프로덕션에 배포하기 전에 오류를 방지하고 문제를 포착하는 것은 애자일 방법론의 초석입니다. 또한 복잡성과 취약성을 완화하는 데 도움이 됩니다.

이는 고객이 애플리케이션을 처음 배포할 때 일반적으로 직면하는 문제가 아닙니다. 오히려 시간이 지나고 응용 프로그램이 성공적이 되어 확장해야 할 때 이런 문제가 발생합니다. 우리는 확장, 또는 더 정확히 말해서 계획되지 않은 확장이 위에 나열된 우려 사항의 일반적인 근본 원인이라는 것을 발견했습니다.

다행히도 NGINX 컨트롤러 구성 개체 모델은 세 가지 문제를 모두 해결합니다.

• NGINX Plus 인스턴스의 특정 세트에 영향을 줄 수 있는 모든 구성 구성 요소를 단일 위치에 수집하여 배포 복잡성을 줄여줍니다.
• 팀이 프로덕션에 적용하기 전에 구성을 검증하고 테스트할 수 있도록 하여 취약성을 줄이고, 빠르게 실패할 가능성을 줄이며 프로덕션 사용자 트래픽이 계속 흐르도록 보장합니다.
• 매우 유연하기 때문에 안전성이 향상됩니다. 모델에 맞게 프로세스를 조정하도록 강요하는 대신, 구성 개체 모델은 비즈니스 워크플로 및 책임 구분에 맞춰 설계되므로 필요에 따라 다양한 사업부에 구성 요소에 대한 적절한 소유권을 부여할 수 있습니다.

컨트롤러 구성 객체

Controller 모델이 어떻게 작동하는지 더 잘 이해할 수 있도록 몇 가지 주요 구성 객체를 조금 더 자세히 살펴보겠습니다.

환경

대부분의 조직에서 소프트웨어는 출시 전에 개발, 사용자 승인, 사전 생산, 생산 및 기타 품질 검사 단계 등 여러 단계를 거칩니다. 이러한 단계는 환경이라고 하는 NGINX 컨트롤러 객체에 해당합니다.

환경은 컨트롤러 내의 구성 요소에 대한 격리 영역입니다. 일반적으로 이는 역할 기반 액세스 제어(RBAC)가 정의되는 수준입니다. 환경은 대상 서버, 데이터 센터 및 환경 간에 일반적으로 차이가 있는 기타 인프라 객체와 같은 사항에 대해 최소한의 변경 사항을 대체하면서 다양한 단계에서 동일한 구성 아티팩트를 전달할 수 있습니다.

게이트웨이

게이트웨이는 환경 내의 구성 객체로, 종종 호스트 이름, 프로토콜, TLS/SSL 동작과 같은 설정을 정의하여 애플리케이션이 고객에게 제공되는 방식을 정의하는 최상위 수준으로 사용됩니다. 그러나 이러한 설정은 하위 수준에서도 이루어질 수 있습니다. 실제로, 엣지 네트워크 어플라이언스나 DMZ를 관리하는 네트워크 운영(NetOps) 팀이 가장 일반적으로 Gateway 객체를 소유합니다. 게이트웨이는 또한 "배치"라는 개념을 사용합니다. 이는 구성을 수신하고 실제 작업을 수행하는 Controller와 NGINX Plus 인스턴스를 연결하는 방법입니다.

앱

그 다음 레벨은 앱 구성 객체로, 여기서 애플리케이션과 그룹 트래픽 형성 동작을 모델링하기 시작합니다. 조직의 요구 사항에 맞춰 필요한 만큼 많은 앱을 사용할 수 있습니다. 유일한 요구 사항은 앱이 환경 내에서 고유해야 한다는 것입니다.

구성 요소

앱 내에서 구성 요소는 앱에 대한 원하는 트래픽 셰이핑 동작을 설명합니다. 가장 간단한 경우, 주어진 경로 이름에 대한 모든 트래픽이 동일한 서버 그룹으로 전송됩니다. 하지만 구성 요소는 헤더 조작, URL 재작성, 백엔드 부하 분산 동작, 쿠키 처리 및 기타 설정과 같은 보다 고급 셰이핑도 제어합니다. 호스트 이름과 TLS/SSL 동작도 이 수준에서 정의할 수 있습니다.

그것을 함께 묶다

구성 객체 간의 관계를 시각적으로 표현한 것은 다음과 같습니다.

Controller와 상호 작용하는 그룹이 두 개뿐이라는 점에 유의하세요. 이 경우에는 Referral 과 Transfers라는 두 개의 개발팀입니다. 실제로 애플리케이션 제공 및 보안에 참여하는 사람의 수는 네트워킹 및 보안(플랫폼 운영), DevOps, 앱 개발 등 훨씬 더 많을 것으로 예상됩니다. 가장 많은 지식을 보유한 팀은 조직의 동부 및 서부 데이터 센터 위치에 걸쳐 있는 "Dev" 환경 내에서 앱, 구성 요소 및 게이트웨이를 사용하는 팀에 대한 보호책을 제공하고 모범 사례에 맞춰 정책을 설정하고 셀프 서비스 워크플로를 구축할 수 있습니다.

이 문제를 조금 다른 방식, 더 나아가 사업부(LOB) 관점에서 살펴보겠습니다. LOB 소유자는 점점 더 최신 앱에 대한 적용 결정을 내리고 있습니다.

다음 다이어그램은 다양한 LOB 팀과 모든 인증서 갱신을 관리하는 숀을 포함한 훨씬 더 큰 사용자 풀이 포함된 보다 실제에 가까운 시나리오를 보여줍니다.

이제는 결과적인 데이터 흐름에 영향을 미치는 개별 행위자와 파이프라인이 더 많아졌습니다.

각 개별 파이프라인이 소스 제어(예: GitHub)에서 컨트롤러로 다양한 개체 변경 사항을 거치면서 구성 개체는 컨트롤러 측에서 검증된 후, 변경 사항이 NGINX Plus 인스턴스로 푸시되기 전에 모든 관련 개체와 결합됩니다.

Controller는 최신 변경 사항이 이전 설정 및 다른 애플리케이션과 LOB 소유자의 설정과 호환되는지 확인하여 구성 관리를 보다 안전하게 만드는 데 도움을 줍니다.

실제로는 단일 NGINX Plus 인스턴스에 적용되는 모든 구성이 가능해야 하지만 설정이 서로 충돌하거나 겹치거나 충돌해서는 안 된다는 점을 알고 있습니다. 그리고 갈등을 미리 포착하고 각 개별 구성 요소의 구성을 제공하는 사람들에게 알리는 것이 중요합니다.

위의 예에서 Referral 구성 요소가 Transfers 구성 요소가 이미 구현한 것과 동일한 정규식 패턴을 사용하려고 하면 경로 충돌이 바로 포착되고 Referral 팀은 이 구성을 프로덕션에 배포하기 훨씬 전에 알림을 받을 수 있습니다. 즉, 잘못된 구성과 관련된 많은 골치 아픈 일을 피할 수 있습니다.

인증서와 관련하여 Shawn은 Controller의 RBAC 기능을 통해 인증서 변경 사항을 즉시 구현할 수 있습니다. 게이트웨이와 구성 요소의 유지 관리자는 올바른 인증서만 참조하면 숀이 자신의 라이프사이클에서 자신감을 가지고 이를 관리할 수 있습니다. Shawn이 Controller에서 인증서를 업데이트하면 인증서 만료와 관련된 패닉 없이 올바른 인스턴스로 인증서가 푸시됩니다.

이제 NGINX 컨트롤러에 모든 구성 객체와 하나 이상의 NGINX Plus 인스턴스에 대한 배치 연결이 있으므로 마지막 단계인 구성을 적용하는 작업을 수행할 수 있습니다.

실제에서의 안전

결국, Controller를 사용한 구성 관리의 목표는 올바른 위치에서 올바른 NGINX Plus 인스턴스에 올바른 구성을 적용하는 것입니다. 즉, 앱, 구성 요소, 게이트웨이, 모든 관련 인증서와 인스턴스가 올바르게 구성되면 더 안전하고 확장 가능한 배포가 이루어집니다.

이 최종 검증은 Controller가 구성 관리 프로세스를 더 쉽고 안전하게 만드는 마지막 단계입니다. NGINX Plus 인스턴스에 프록시로 배포된 NGINX Plus의 웹 워크로드 그룹에서 세션 지속성과 같은 연관된 개체 변경 사항이 있을 때 전체 구성을 검증하여 인스턴스가 원하는 구성과 호환되는지 확인합니다. 해당 조건이 충족되면 구성이 적용됩니다. 마지막 안전성을 위해 구성을 적용하는 동안 오류가 발생하면 컨트롤러는 이전 구성으로 돌아갑니다.

구성이 검증을 통과하는 것 외에도 Controller는 새로운 구성이 적용될 때 세션 드레이닝과 같은 고급 NGINX 기능을 활용하여 사이트가 변경 중에도 가용성과 성능을 유지하도록 보장할 수 있습니다.

운영 팀의 경우 위에 설명된 개념과 워크플로 설계는 NGINX 컨트롤러가 구성 관리에 제공하는 안전성에 기여합니다. 이러한 보호 장치는 현대적 앱을 사용하는 다양한 팀과 워크플로를 조정하는 데 도움이 되며, 동시에 비즈니스 요구 사항도 지원합니다.

NGINX Controller를 사용해보려면 오늘 무료 30일 체험판을 시작하거나 저희에게 연락해 사용 사례에 대해 논의해 보세요 .