F5 애플리케이션 서비스 자동화: 실용 가이드

소개

애플리케이션 제공 및 보안 장치의 배포와 구성 관리를 자동화하는 것은 거의 필수적인 관행이 되었습니다. 2017년 IDG FutureScape 보고서에서는 자동화와 멀티 클라우드 관리가 2021년까지 기업에 영향을 미칠 핵심 이니셔티브 중 일부로 선정되었습니다.1 자동화는 애플리케이션에 필요한 필수적인 보안, 최적화 및 가용성 서비스를 배포하는 데 확장성, 안정성 및 통합을 제공하며, 이러한 서비스의 제공을 주요 애플리케이션 배포 모델로 부상하고 있는 조율된 빌드, 테스트 및 배포 워크플로의 일부로 만듭니다.

새로운 가상 서버나 풀 멤버를 추가하는 것과 같은 기본 작업만 간단하게 자동화해도 운영진은 애플리케이션 소유자나 다른 자동화 시스템에 셀프 서비스 기능을 제공할 수 있으며, 이를 통해 차세대 자동화 도구 구축과 같은 보다 생산적인 작업에 시간을 할애할 수 있습니다.

조직이 IT 서비스를 제공하기 위해 여러 클라우드 플랫폼을 도입하기 시작하면 자동화의 필요성이 더욱 커집니다. 다양한 플랫폼 특성을 가진 여러 위치에 서비스를 배포하려고 할 때 자동화는 운영 오버헤드 증가의 영향을 줄이고 새로운 플랫폼에 대한 익숙함 없이 발생하는 오류를 줄이는 데 도움이 될 수 있습니다.

하지만 무엇을, 어떻게 자동화해야 할까? 자동화 소프트웨어는 다양한 운영 모델, 인터페이스, 언어를 통해 단일 장치 계층에서 작동할 수도 있고, 더 복잡한 다중 시스템 도구로 작동할 수도 있습니다. IaaS(Infrastructure-as-a-Service) 클라우드 플랫폼은 가상 인프라와 서비스를 배포하기 위한 자체 기본 도구를 제공합니다. 또한 F5는 다양한 인터페이스와 오케스트레이션 옵션을 제공합니다. 이처럼 다양한 도구와 옵션을 통해 조직에 가장 적합한 방식으로 자동화를 구현할 수 있지만, 적절한 도구를 선택하는 것은 어려운 작업일 수 있으며, 복잡성과 도구 확산의 위험도 현실적입니다.

이 논문에서는 F5 BIG-IP 어플라이언스(물리적 및 가상)의 배포, 관리 및 구성을 자동화하는 방법에 대한 개요를 제공하고, 귀사의 비즈니스에 적합한 경로를 선택하는 방법에 대한 몇 가지 조언을 제공합니다.

자동화 라이프사이클

애플리케이션 서비스를 제공하는 수명 주기에는 여러 가지 주요 자동화 지점이 있습니다. 인프라 모델과 애플리케이션 배포 방법에 따라 모든 애플리케이션을 개발해야 할 수도 있고, 일부만 개발해야 할 수도 있습니다.

고용량, 멀티 테넌트 물리적 또는 가상 BIG-IP에 서비스를 배포하는 경우 부트스트래핑 및 온보딩 활동은 지원하는 수백 또는 수천 개의 애플리케이션에 대한 애플리케이션 서비스 구성을 배포, 모니터링 및 업데이트하는 것에 비해 높은 우선 순위가 아닙니다.

테스트 및 QA를 위해 주문형으로 생성된 잠재적으로 일시적인 인스턴스를 포함하여 여러 환경에서 모든 애플리케이션에 전용 BIG-IP 인스턴스가 있는 배포 모델을 살펴보고 있다면 부트스트래핑 및 온보딩 프로세스를 자동화하는 것이 앱 서비스 자체를 배포하는 것만큼 중요한 경로의 일부입니다. 

그림 1. 자동화 라이프사이클의 다양한 요소는 조직의 인프라 모델과 애플리케이션 배포 방법에 따라 우선순위가 더 높거나 낮을 수 있습니다.

사용자의 환경이 어떠하든, 자동화해야 할 프로세스가 아무리 많아도 고려해야 할 핵심 주제가 몇 가지 있습니다.

자동화: 몇 가지 주요 고려 사항
자동화 성숙도 스펙트럼

자동화에는 다양한 활동이 포함됩니다. 스펙트럼의 한쪽 끝에는 Bash, TMSH, Python 또는 기타 언어로 작성된 간단한 스크립트를 개발하여 로컬에서 실행하여 수동 구성 작업의 속도를 높이는 것이 있습니다. 스펙트럼의 다른 쪽 끝에는 소스 코드 관리, 워크플로 오케스트레이터 및 (잠재적으로) 여러 자동화 도구를 결합하여 인프라 구성이 저장소에 포함된 텍스트 파일에 의해 정의되고 변경되는 시스템을 만드는 전체 "인프라 코드" 시스템이 있습니다. 이 두 가지 극단적인 상황 사이에는 BIG-IP 플랫폼의 배포와 구성을 관리하는 데 도움이 되는 다양한 옵션이 있습니다.

그림 2. 다양한 수준의 자동화에는 간단한 스크립트부터 여러 자동화 워크플로의 복잡한 통합에 이르기까지 다양한 활동이 포함됩니다.
가변 vs. 불변

현재 대부분의 BIG-IP 배포는 변경 가능 하다고 볼 수 있는데, 이는 시간이 지남에 따라 구성이 변경될 수 있음을 의미합니다. 이는 BIG-IP 플랫폼이 주로 여러 애플리케이션에 서비스를 제공하는 멀티 테넌트 장치로 구축되기 때문입니다. 새로운 애플리케이션이 배포되거나 기존 애플리케이션이 확장되거나 추가 서비스가 필요하면 BIG-IP 구성도 이에 맞춰 업데이트됩니다. 이 배포 방법을 사용하면 인프라 팀이 공통 플랫폼에서 애플리케이션에 서비스를 제공하는 일련의 중앙 집중화된 인프라를 관리할 수 있습니다.

그러나 때로는 BIG-IP 플랫폼이 개별 애플리케이션 스택의 일부로 배포되는 경우도 있는데, 이 경우 특정 BIG-IP의 서비스가 특정 애플리케이션이나 서비스에 연결됩니다. 이런 상황에서는 BIG-IP 구성을 변경 불가능한 것으로 처리할 수 있습니다. 즉, 구성은 부팅 시 또는 소프트웨어 이미지의 일부로 설치되며 BIG-IP 인스턴스의 수명 주기 동안 변경되지 않습니다. 구성 변경은 소프트웨어 이미지나 시작 에이전트 스크립트 내용을 변경한 다음 다시 배포하는 방식으로 이루어집니다. 이 모델은 종종 "핵과 포장"이라고 불립니다. 전반적으로는 덜 일반적이지만 앱별 인스턴스를 지원하는 새로운 BIG-IP 라이선싱 모델, 향상된 라이선싱 도구, F5 클라우드 라이브러리 (클라우드에서 BIG-IP를 온보딩하는 데 도움이 되도록 설계된 Node.js 스크립트 및 라이브러리 세트)와 같은 도구가 등장하면서 이 배포 모델은 코드와 인프라가 엄격하게 결합되고 격리된 스택을 갖는 애플리케이션이 필요한 조직에 실행 가능한 옵션이 되고 있습니다.

그림 3. 변경 불가능한 BIG-IP 인스턴스는 수명 주기 동안 수정되지 않습니다. 대신, 새롭고 업데이트된 인스턴스가 배포되고 이전 인스턴스는 삭제됩니다. 대조적으로, 가변 BIG-IP 인스턴스는 수명 주기 동안 구성 변경의 대상이 될 수 있습니다.
명령형 vs. 선언형

자동화 인터페이스가 소비자에게 노출되는 방식에는 두 가지 개념적 모델이 있습니다. 가장 흔한 "첫 번째 물결" 자동화 스키마는 필수 모델로 향하는 경향이 있습니다. 명령형 자동화 모델에서 자동화 소비자는 일반적으로 달성하고자 하는 목표와 이를 달성하기 위한 명시적 단계(일반적으로 API 호출)를 모두 알아야 합니다. 이로 인해 고급 서비스의 구성 세부 정보를 이해해야 하는 부담이 소비자에게 전가되는 경우가 많고, 자동화 도구와 서비스를 통합하기 위한 추가적인 복잡성과 노력이 발생하기도 합니다. 이는 샌드위치를 만드는 사람이 샌드위치를 만드는 데 필요한 작업(및 작업 순서)을 알고 있을 것이라는 기대를 가지고 샌드위치를 요청하는 것이 아니라, 샌드위치를 만드는 데 필요한 모든 작업을 일일이 지정해서 요청하는 것과 비슷합니다.

이와 대조적으로 선언적 인터페이스는 소비자(인간이나 기계)가 원하는 것을 요청하여 서비스를 만들 수 있도록 합니다. 자동화 대상에는 필요한 결과에 따라 구성을 생성할 수 있는 사전 구성된 워크플로나 서비스 템플릿이 있으므로, 필요한 모든 단계에 대한 자세한 지식은 필요하지 않습니다. 선언적 인터페이스는 초기 설정이 약간 더 복잡하지만, 적절한 서비스 템플릿이 구축되면 작업이 간단해져 복잡성은 상쇄됩니다. 따라서 이는 일반적으로 자동화 시스템을 구축하는 데 선호되는 메커니즘입니다.

직접 또는 관리 도구를 통해

고려해야 할 또 다른 결정은 자동화 API 호출을 변경해야 하는 장치에 타사 도구에서 직접 수행해야 하는지, 아니면 추가 관리 도구를 통해 수행해야 하는지입니다. 관리 도구는 운영을 추상화하고 단순화할 수 있으며, 관리 대상 엔터티에 직접 연결하는 것보다 더 많은 제어 및 로깅 계층을 제공할 수 있습니다. 그러나 빠르게 변경하는 기능이 중요한 상황에서는 관리 계층의 가용성이 매우 높아야 합니다.

그림 4: 관리 도구는 자동화 호출 및 로깅을 간소화할 수 있지만, 관리되는 엔터티에 직접 호출하는 것과 비교했을 때 관리 세분성과 가용성 측면에서 균형을 이룹니다.
API, 스타트업 에이전트, 아니면 CLI?

BIG-IP 장치는 대개 REST API를 통해 자동화되며, 이는 문서화된 스키마를 통해 대부분의 BIG-IP 기능을 제공합니다. Ansible과 같은 자동화 도구를 위한 F5 제공 모듈은 REST API를 광범위하게 사용합니다. iControl LX 기능을 추가하면 단일 API 호출에서 여러 단계 작업을 수행할 수 있는 사용자 정의 API 엔드포인트를 생성할 수도 있습니다.

BIG-IP 구성을 자동화하는 또 다른 일반적인 방법은 시작 에이전트를 사용하는 것입니다. 시작 에이전트는 시작 시 실행되어 BIG-IP 플랫폼을 구성하기 위한 외부 정보를 가져올 수 있습니다. 시작 에이전트는 종종 장치를 "온보딩"하기 위한 초기 구성을 수행하는 데 사용되며 GitHub 또는 자체 저장소와 같은 타사 사이트에서 추가 스크립트 및 구성 파일을 가져올 수 있습니다. 스타트업 에이전트는 특히 고정된 애플리케이션별 구성을 선택한 경우 BIG-IP 플랫폼을 완전히 구성하는 데에도 사용할 수 있습니다.

가장 일반적인 시작 구성은 cloud-init 으로, 모든 BIG-IP VE 이미지(Microsoft Azure 제외)에서 활성화되어 있지만 AWS 및 OpenStack 배포에 가장 적합합니다. F5는 cloud-init과 함께 부팅 시 BIG-IP를 구성하는 데 도움이 되는 일련의 클라우드 시작 라이브러리를 제공합니다.

부팅 후 플랫폼을 구성하기 위해 시작 에이전트를 사용하기로 선택한 경우 오류 관리에 주의하세요. 특히 외부 소스를 사용하는 경우, 특히 인스턴스가 확장 이벤트의 일부로 시작될 수 있는 경우 이것이 중요합니다. 외부 리소스를 사용할 수 없다면 시스템은 어떻게 작동할까요? 수요를 충족하기 위해 추가적인 "좀비" 장치가 만들어질까요?

어떤 경우에는 자동화 시스템이 사용자처럼 동작하고 CLI 명령을 실행할 수 있습니다. 이 방법으로 API 호출이 완료되지 않은 일부 문제를 해결할 수 있는 경우가 있지만 일반적으로 지원이 어렵고 솔루션이 취약하기 때문에 이 방법은 마지막 수단으로 사용됩니다.

템플릿 및 플레이북

템플릿과 플레이북을 사용하면 자동화된 배포를 만들고 일정 수준의 표준화가 이루어진 인프라를 구축할 수 있습니다. 적절한 수준의 표준화는 인프라를 보다 강력하고 지원 가능하게 만들어줍니다. 잘 만들어진 템플릿은 선언적 인터페이스를 제공하는데, 요청하는 엔티티(사용자 또는 컴퓨터)는 구현 세부 사항이 아니라 필요한 속성만 알면 됩니다. 템플릿을 사용하여 엄격하게 배포하고 템플릿을 수정하여만 문제를 해결하면 일반적으로 문제는 한 번만 해결하면 되므로 서비스 품질이 더 높아질 수 있습니다. 새 템플릿을 사용하여 서비스를 다시 배포하고, 템플릿을 업데이트하면 동일한 문제가 두 번째로 발생하는 것을 방지할 수 있습니다.

플랫폼 통합

플랫폼 통합 도구는 BIG-IP 서비스 구성을 프라이빗 클라우드나 컨테이너 관리 시스템과 같은 플랫폼에 연결합니다. 이러한 메커니즘은 플랫폼과 구현에 따라 다르지만 일반적으로 다음 세 가지 모델로 구분됩니다.

  • 기존 플랫폼 구조에 F5 서비스 대체
    이 모델에서는 F5 서비스가 기존 플랫폼 구조를 사용하여 삽입됩니다. 예를 들어, F5를 OpenShift 컨테이너 플랫폼 라우터 로 사용하거나 F5를 OpenStack Load Balancing as a Service(LBaaS) 시스템과 함께 사용합니다. 이러한 메커니즘을 사용하면 플랫폼 기반 인터페이스를 사용하여 서비스를 구성하고, 제공된 드라이버와 기타 소프트웨어가 플랫폼 구성 지침을 F5 구성으로 원활하게 변환하기 때문에 운영 절차를 거의 변경할 필요가 없습니다. 하지만 플랫폼 기반 인터페이스를 통해서만 사용 가능한 기능만 쉽게 배포할 수 있다는 점을 기억하세요.
  • 플랫폼 이벤트 구독하기
    또 다른 일반적인 통합 방법은 소프트웨어 모듈(예: Kubernetes 및 Mesos용 Container Connector )이 플랫폼 내의 이벤트를 구독한 다음 이벤트에 따라 구성을 수정하는 것입니다. 서비스가 필요한 애플리케이션에 태그를 지정하거나 레이블을 지정하여 배포할 이벤트와 서비스를 선택하고, 필요한 태그가 있는 이벤트를 모니터링하도록 커넥터 소프트웨어를 구성할 수 있습니다.
  • 플랫폼 관리 도구와의 통합
    많은 프라이빗 클라우드 플랫폼에는 자동화를 위해 설계된 관리 시스템이 있습니다. 예를 들어 VMware에는 여러 관리 및 통합 도구가 있으며, 그 중에는 BIG-IP 구성을 위한 타사 플러그인이 있는 vRealize Orchestrator(vRO)가 있습니다. 다른 예로는 OpenStack HEAT 템플릿 시스템용 플러그인이 있습니다.
서비스 발견

서비스 검색은 완전한 자동화 솔루션은 아니지만 BIG-IP 구성을 환경 변화에 맞게 통합하는 간단하면서도 강력한 방법입니다. 서비스 검색은 API를 통해 클라우드 시스템을 주기적으로 폴링하여 리소스 목록을 검색하고 이에 따라 BIG-IP 구성을 수정하는 방식으로 작동합니다. 이 기능은 리소스가 자동 크기 조정 그룹으로 구성된 환경에서 특히 유용합니다. 백엔드 컴퓨팅 리소스를 확장하려면 로드 밸런서가 새 리소스를 인식해야 하기 때문입니다. 서비스 검색 구성 요소는 AWSAzure 용 F5 클라우드 자동 확장 솔루션과 함께 제공됩니다.

그렇다면 F5가 권장하는 자동화 계획이 있습니까? 예, 아니오. 고려해야 할 변수가 너무 많아서 완전히 처방적인 조언은 도움이 되지 않습니다. 그러나 우리는 귀하에게 필요하다고 생각되는 핵심 구성 요소를 조정된 제품군으로 모았습니다.  

F5 자동화 툴체인

F5 자동화 툴체인 제품군은 CI/CD 툴체인과 같은 일반적인 자동화 패턴에 F5 BIG-IP 플랫폼을 통합할 수 있도록 하는 기본 자동화 및 오케스트레이션 빌딩 블록으로 구성됩니다.  

F5 자동화 툴체인에는 다음과 같은 주요 구성 요소가 포함되어 있습니다.

  • 애플리케이션 서비스 3 확장(AS3) – 선언적 L4-L7 BIG-IP 애플리케이션 서비스
  • 선언적 온보딩 확장(DO) – 선언적 L1-L3 BIG-IP 온보딩
  • 원격 측정 스트리밍 확장(TS) - 분석 시스템에 대한 자동화된 BIG-IP 원격 측정 스트리밍
  • API 서비스 게이트웨이(ASG) – 사용자 정의 iControl LX 확장을 위한 컨테이너 런타임

Automation Toolchain 제품군은 플랫폼 배포(클라우드 템플릿을 통해)부터 온보딩, 서비스 구성, 고급 원격 측정 및 로깅까지 애플리케이션 서비스의 제공 수명 주기를 관리하도록 설계되어 애플리케이션 성능 보장을 실현합니다.

그림 5. Automation Toolchain 제품군은 애플리케이션의 전체 수명 주기를 관리하기 위한 도구를 제공합니다.

지원되는 도구의 이러한 확장되는 제품군은 F5 애플리케이션 서비스를 자동화하는 미래 방향을 나타냅니다. 그러나 이는 다른 통합이 존재하지 않거나 지원되지 않는다는 것을 의미하지는 않습니다. 이 문서의 "기타 자동화 도구" 섹션을 참조하세요.

애플리케이션 서비스 3 확장

F5 애플리케이션 서비스 3 확장(AS3)은 선언적 REST API를 통해 BIG-IP 플랫폼에서 계층 4-7 애플리케이션 서비스 배포를 자동화하는 간단하고 일관된 방법을 제공합니다. AS3는 JSON 문서로 표현되는 잘 정의된 개체 모델을 사용합니다.  선언적 인터페이스 덕분에 F5 애플리케이션 서비스 배포를 쉽고 안정적으로 관리할 수 있습니다.

그림 6: F5 애플리케이션 서비스 3 확장(AS3)은 선언적 REST API를 통해 BIG-IP 플랫폼에서 레이어 4-7 애플리케이션 서비스 배포를 자동화하는 간단하고 일관된 방법을 제공합니다. AS3는 JSON 문서로 표현된 잘 정의된 개체 모델을 사용합니다. 선언적 인터페이스는 F5 애플리케이션 서비스 배포를 쉽고 안정적으로 관리할 수 있게 해줍니다.

다이어그램: AS3 아키텍처

AS3 확장 기능은 선언을 수집하고 분석하며 적절한 iControl API 호출을 수행하여 대상 BIG-IP에서 원하는 최종 상태를 생성합니다. 확장 기능은 BIG-IP 인스턴스에서 실행하거나 AS3 컨테이너(AS3 확장 기능을 실행한 다음 BIG-IP에 외부 API 호출을 하는 별도의 컨테이너/VM)를 통해 실행할 수 있습니다. 

그림 7: AS3 확장 기능은 선언을 수집하고 분석하며 적절한 iControl API 호출을 수행하여 대상 BIG-IP에서 원하는 최종 상태를 생성합니다. 확장 기능은 BIG-IP 인스턴스에서 실행하거나 AS3 컨테이너를 통해 실행할 수 있습니다. AS3 컨테이너는 AS3 확장 기능을 실행한 다음 BIG-IP에 외부 API 호출을 하는 별도의 컨테이너/VM입니다.

AS3 통화는 BIG-IP 플랫폼에 대한 라이선싱, 관리, 시각화 및 액세스 제어를 제공하고 강력한 분석과 결합된 BIG-IP의 온디맨드 앱 인스턴스를 제공하는 F5 Cloud Edition을 지원하는 BIG-IQ를 통해서도 이루어질 수 있습니다.

그림 8: AS3 호출은 BIG-IQ를 통해서도 가능합니다.
선언적 온보딩 확장

선언적 온보딩 확장 기능은 F5 BIG-IP 플랫폼을 초기 부팅 직후부터 애플리케이션에 대한 보안 및 트래픽 관리를 배포할 준비가 될 때까지 사용할 수 있는 간단한 인터페이스를 제공합니다.  여기에는 라이센싱 및 프로비저닝과 같은 시스템 설정, VLAN 및 셀프 IP와 같은 네트워크 설정, 두 개 이상의 BIG-IP 시스템을 사용하는 경우 클러스터링 설정이 포함됩니다.

온보딩 프로세스가 완료되면 선택한 자동화(또는 수동) 프로세스를 사용하여 애플리케이션 서비스를 배포할 수 있습니다.

선언적 온보딩은 AS3 스키마와 일치하는 JSON 스키마를 사용하며 유사한 아키텍처를 가지고 있습니다.  선언적 온보딩은 온보딩 단계의 첫 번째 단계에서 새로 부팅된 BIG-IP에 설치되는 TMOS 독립 RPM으로 제공됩니다.

원격 측정 스트리밍 확장

BIG-IP는 강력한 애플리케이션, 보안 및 네트워크 원격 측정 생성기입니다.  Telemetry Streaming 확장 기능은 다음과 같은 제3자 소비자에게 통계 및 이벤트 스트리밍을 구성하기 위한 선언적 인터페이스를 제공합니다.

  • 스플렁크
  • Azure 로그 분석
  • AWS 클라우드 워치
  • AWS S3
  • 석묵

Automation Toolchain 제품군의 다른 제품과 마찬가지로, 구성은 간단하고 일관된 JSON 스키마를 사용하는 선언적 인터페이스를 통해 관리됩니다.

API 서비스 게이트웨이

API 서비스 게이트웨이는 사용자 정의 iControl LX 확장 프로그램을 TMOS 독립 플랫폼에서 실행할 수 있게 해주는 Docker 컨테이너 이미지입니다.  이를 통해 개별 BIG-IP 플랫폼에서 관리 작업을 추상화하여 F5 배포를 확장하고 관리하는 데 도움이 될 수 있습니다.

클라우드 템플릿 – 솔루션의 일부이지만 아직은 제품군의 일부가 아님

클라우드 템플릿은 퍼블릭 및 프라이빗 클라우드의 배포 자동화 기능을 사용하여 BIG-IP 가상 어플라이언스를 프로비저닝하고 부팅합니다.

F5는 현재 다음 클라우드에 대해 지원되는 템플릿을 제공합니다.

F5는 더 광범위한 배포 시나리오를 포괄하기 위해 클라우드 템플릿을 적극적으로 개발하고 있습니다. 관련 Github 저장소를 통해 문제나 풀 리퀘스트를 제출해 주세요.

오케스트레이션 및 워크플로 도구 및 지속적인 딜리버리/배포

애플리케이션 서비스는 기능하는 애플리케이션을 만드는 기술 스택의 한 계층일 뿐입니다. 코드 커밋에서 운영 배포 및 모니터링까지 애플리케이션을 구축하기 위해 모든 구성 요소를 통합, 빌드, 배포하려면 많은 종속 단계가 필요하며 이러한 단계는 올바른 순서로 실행되어야 합니다. 이 작업을 자동화하는 것은 조정된 작업 및 도구의 워크플로 파이프라인을 생성하는 오케스트레이션 도구의 역할입니다.  

대부분의 파이프라인은 애플리케이션, 테스트 및 인프라 구성을 위한 코드를 보관하는 소스 코드 저장소로 시작됩니다.

AS3, 클라우드 템플릿, 선언적 온보딩과 같은 도구를 사용하면 배포 파이프라인의 일부로 애플리케이션 서비스를 빌드하고 구성하는 데 필요한 모든 구성 정보를 저장할 수 있습니다.

멀티 테넌트 장수 BIG-IP 하드웨어 또는 소프트웨어 플랫폼을 사용하는 아키텍처에서는 애플리케이션 코드 저장소의 일부로 관리되는 AS3 구성만 필요합니다. 반면, 배포 프로세스의 일부로 전용 인스턴스를 필요에 따라 시작하려는 시나리오에서는 템플릿과 선언적 온보딩 선언을 관리하는 것이 애플리케이션 저장소에 포함되어야 합니다.

기타 자동화 도구: 리소스 가이드

상상할 수 있는 모든 자동화 또는 오케스트레이션 도구를 다룰 수는 없지만 F5 고객이 사용하는 가장 일반적인 도구, 사용 사례 및 기능 목록은 아래와 같습니다.

언어 통합

언어

상태

예 및 소스

파이썬 F5 기여 https://github.com/F5Networks/f5-common-python
가다

사용자 기여

https://github.com/f5devcentral/go-bigip

파워셸

F5 지원됨

https://devcentral.f5.com/wiki/icontrol.powershell.ashx

구성 관리 및 인프라 자동화 도구

도구

상태

예 및 소스

앤서블

F5 기여

https://github.com/F5Networks/f5-ansible

테라폼

F5 기여

https://github.com/f5devcentral/terraform-provider-bigip

인형

F5 기여

https://github.com/f5devcentral/f5-puppet

요리사

사용자 기여

https://github.com/target/f5-bigip-cookbook

솔트스택

제3자

https://docs.saltstack.com/en/latest/ref/runners/all/salt.runners.f5.html

인프라 템플릿 시스템

플랫폼

상태

예 및 소스

한국어: AWS

F5 지원됨

https://github.com/F5Networks/f5-aws-cloudformation

하늘빛

F5 지원됨

https://github.com/F5Networks/f5-azure-arm-templates

Google

F5 지원됨

https://github.com/F5Networks/f5-google-gdm-templates

오픈스택

F5 지원됨

https://github.com/F5Networks/f5-openstack-hot

스타트업 에이전트 및 클라우드 스크립트

클라우드 초기화

https://devcentral.f5.com/articles/f5-in-aws-part-5-cloud-init-single-nic-and-scale-out-of-big-ip-in-v12-21476

클라우드 라이브러리

https://github.com/F5Networks/f5-cloud-libs

플랫폼 통합

컨테이너 관리 플랫폼

플랫폼

상태

예 및 소스

쿠버네티스

F5 지원됨

https://github.com/F5Networks/k8s-bigip-ctlr

피보탈 클라우드 파운드리

F5 지원됨

https://github.com/F5Networks/cf-bigip-ctlr

마라톤

F5 지원됨

https://github.com/F5Networks/marathon-bigip-ctlr

레드햇 오픈시프트

F5 지원됨

https://hub.docker.com/r/f5networks/k8s-bigip-ctlr 또는

https://access.redhat.com/containers/?tab=tags#/registry.connect.redhat.com/f5networks/k8s-bigip-ctlr

프라이빗 클라우드 플랫폼

플랫폼

상태

예 및 소스

오픈스택(LBaaS)

F5 지원됨

https://github.com/F5Networks/f5-openstack-lbaasv2-driver

오픈스택(Heat)

F5 지원됨

https://github.com/F5Networks/f5-openstack-hot

VM웨어(vRO)

제3자

https://bluemedora.com/products/f5/big-ip-for-vrealize-Operations/

오케스트레이션 및 워크플로 도구에 대한 참고 사항

위의 도구와 통합은 BIG-IP 플랫폼을 배포하고 구성하여 애플리케이션 가용성, 보안, 확장 서비스를 제공하는 자동화된 방법을 나타냅니다. 이러한 서비스는 필수적이기는 하지만 풀스택 애플리케이션 배포의 일부에 불과합니다. 서버, 데이터, 컴파일된 애플리케이션 코드, 인프라를 조율되고 테스트된 방식으로 갖춘 전체 애플리케이션 스택을 만들려면 간단한 자동화 도구 그 이상이 필요합니다.

여러 자동화 시스템과의 통합 및 관련 워크플로를 갖춘 더 높은 수준의 오케스트레이션 도구가 필요합니다. 이러한 도구는 일반적으로 CI/CD(지속적인 통합/지속적인 배포) 작업 관행에서 가장 많이 사용되며, 모든 실제 구현에서 자동화가 필요합니다. 여러 오케스트레이션 도구가 있지만 Jenkins가 가장 일반적이며 CI/CD 워크플로에 F5 인프라스트럭처 코드 기능을 통합하는 방법을 보여주는 예제 워크플로도 있습니다. 그러나 일반적으로 오케스트레이션 도구는 구성 자동화 도구 중 하나를 통해 실제로 변경 사항을 적용하고 서비스를 배포합니다.

라이센스

BIG-IP 플랫폼은 작동하려면 라이선스가 필요하므로 자동화의 중요 경로에 라이선스를 포함하는 것이 좋습니다. BIG-IP 가상 장치를 신속하게 확장하거나 축소해야 하거나 테스트 및 개발 목적으로 생성해야 하는 매우 역동적인 환경에서는 라이선싱 모델을 신중하게 고려해야 합니다.

퍼블릭 클라우드에서 한 가지 방법은 BIG-IP의 유틸리티 청구 버전을 사용하는 것입니다(클라우드 마켓플레이스를 통해 이용 가능). 공공 서비스 요금 청구 인스턴스는 자체 라이선스가 적용되며, 비용은 클라우드 공급자를 통해 사용량에 따른 요금 또는 시간 약정 기준으로 청구됩니다.

또 다른 옵션은 F5 BIG-IQ License Manager 와 함께 구독(또는 영구)을 통해 구매한 재사용 가능 라이선스 풀을 사용하는 것입니다. 이를 통해 풀에서 라이선스를 할당하고 취소할 수 있습니다.

스타트업 에이전트와 API 호출을 통해 라이선싱 단계를 자동화할 수 있으며, 이를 위해서는 F5 라이선스 서버에 대한 아웃바운드 인터넷 액세스가 필요합니다(클라우드 플랫폼의 유틸리티 라이선스의 경우에도 마찬가지입니다).

언제 무엇을 사용해야 하나요?

조직에 따라 적합한 자동화 및 오케스트레이션 도구를 선택하는 것은 매우 쉽거나 어려운 작업이 될 수 있습니다. 다른 구성 요소에 대한 도구나 방법론을 이미 채택했고 BIG-IP를 시스템에 통합하기만 하면 되는 경우에는 쉽습니다. 특정 도구에 통합하지 않아도 iControl LX 기능과 cloud-init을 결합한 풍부한 iControl REST API를 통해 기존 자동화 도구에 BIG-IP를 통합하는 작업이 비교적 간단해집니다(특히, 단일 API 호출로 복잡한 구성도 생성하는 데 사용할 수 있는 iApp 템플릿과 결합하는 경우 더욱 그렇습니다).

그러나 처음부터 시작한다면 상황이 더 복잡해질 수 있습니다. 다른 솔루션을 선택하는 것과 마찬가지로, 먼저 요구 사항을 이해하는 것이 중요합니다. 이 논문에서는 귀하의 요구 사항 목록을 작성할 수 없지만 귀하의 평가를 돕기 위한 질문과 권장 사항 세트는 다음과 같습니다.

자동화 모델: 선언적 모델을 사용하면 오케스트레이션 소비자가 상호 작용하기가 훨씬 간단해집니다. 소비자는 원하는 것이 무엇인지 알아야 할 뿐, 원하는 것이 무엇인지 알기 위해 거쳐야 할 절차적 단계를 알 필요는 없습니다. F5 Automation Toolchain 제품군은 향후 그린필드 사이트를 위한 '모델' 배포를 대표할 것입니다.

잠재적인 플랫폼 및 환경: 컨테이너와 다양한 클라우드 플랫폼이 애플리케이션 인프라의 핵심 부분이 될 것은 불가피합니다. 이에 대한 계획을 세우세요.

기술: 이미 기반 기술 중 일부에 대한 기술을 보유하고 있나요? 이런 기술은 부서 밖에서는 존재할 수 있지만, 회사 전체에서는 존재할 수 있다는 점을 명심하세요. 그렇다면 귀하의 조직에서 이미 채택한 언어를 사용하는 도구를 선택하는 것이 좋을 수 있습니다.

지원 가능성: 지원할 수 있는 시스템만 구축하세요. 이는 당연한 것처럼 보일 수 있지만 성공의 핵심은 조직 내에서 제공할 수 있는 복잡성 수준을 선택하는 것입니다. 이를 통해 과도한 운영 오버헤드를 발생시키지 않으면서도 자동화의 이점을 극대화할 수 있습니다.

결론

IT 시스템의 자동화 증가는 불가피합니다. 주요 애플리케이션 제공 및 보안 서비스에 대한 전략적 접근 방식을 취하면 조직에서 배포하는 애플리케이션의 보안과 가용성이 유지됩니다. 자동화는 특히 여러 플랫폼과 퍼블릭 클라우드에서 작업하는 경우 운영 오버헤드를 줄이는 데 도움이 될 수도 있습니다.

올바른 자동화 시스템을 선택하는 일은 쉽지 않지만 이상적으로는 귀하가 보유한 기술 세트와 귀하가 구축한 시스템을 지원할 수 있는 능력을 고려하여 협력적이고 전체적인 노력으로 선택하는 것이 좋습니다. 어떤 솔루션을 선택하든 BIG-IP 플랫폼과 F5 전문성을 활용하여 애플리케이션이 어디에 구축되어 있든 필요한 엔터프라이즈급 서비스를 제공할 수 있다는 확신을 가질 수 있습니다.

F5 지원에 대한 참고 사항 F5는 여러 가지 템플릿과 도구를 지원하지만, 모든 템플릿과 도구를 지원하는 것은 아닙니다. Github에서 소프트웨어를 사용할 수 있는 경우, 지원되는 코드는 F5 저장소의 "지원되는" 폴더에서만 찾을 수 있습니다. 다른 소프트웨어의 경우 해당 readme 파일에 정의된 지원 정책이 있습니다. 

2019년 5월 13일 게시
  • 페이스북에 공유하기
  • X에 공유
  • Linkedin에 공유하기
  • 이메일로 공유하기
  • AddThis를 통해 공유

F5에 연결

F5 Labs

최신 애플리케이션 위협 인텔리전스입니다.

DevCentral

토론 포럼과 전문가 기사를 제공하는 F5 커뮤니티입니다.

F5 뉴스룸

뉴스, F5 블로그 등.