F5 애플리케이션 서비스 자동화: 실무 가이드
소개
애플리케이션 전송 및 보안 장비의 배포와 구성 관리를 자동화하는 것은 이제 거의 필수적인 관행이 되었습니다. 2017년 IDG FutureScape 보고서에서는 자동화와 멀티 클라우드 관리가 2021년까지 기업에 영향을 미칠 주요 이니셔티브로 꼽혔습니다.1 자동화는 애플리케이션에 필요한 핵심 보안, 최적화 및 가용성 서비스를 배포할 때 확장성, 안정성 및 통합성을 제공하며, 이러한 서비스의 제공을 애플리케이션 배포의 지배적인 모델로 자리 잡고 있는 오케스트레이션된 빌드, 테스트 및 배포 워크플로의 일부로 만듭니다.
새 가상 서버나 풀 멤버를 추가하는 것과 같은 기본 작업을 단순히 자동화하는 것만으로도 운영팀은 애플리케이션 소유자나 다른 자동화 시스템에 셀프서비스 기능을 제공할 수 있으며, 차세대 자동화 도구 개발과 같이 생산성이 더 높은 업무에 집중할 시간을 확보할 수 있습니다.
조직이 IT 서비스를 제공하기 위해 여러 클라우드 플랫폼을 도입하기 시작하면 자동화의 필요성은 더욱 커집니다. 서로 다른 플랫폼 특성을 지닌 여러 위치에 서비스를 배포할 때 자동화를 활용하면 운영 오버헤드 증가로 인한 영향을 줄이고 새로운 플랫폼에 익숙하지 않아 발생하는 오류를 줄일 수 있습니다.
하지만 무엇을 어떻게 자동화해야 할까요? 운영 모델, 인터페이스, 언어가 서로 다른 환경에서 자동화 소프트웨어는 단일 디바이스 계층에서 작동할 수도 있고, 여러 시스템을 아우르는 보다 복잡한 도구로 활용될 수도 있습니다. 서비스형 인프라(IaaS) 클라우드 플랫폼은 가상 인프라와 서비스를 배포하기 위한 자체 네이티브 도구를 제공합니다. 또한 F5는 다양한 인터페이스와 오케스트레이션 옵션을 제공합니다. 이처럼 폭넓은 도구와 옵션을 활용하면 조직에 가장 적합한 방식으로 자동화할 수 있지만, 적절한 도구를 선택하는 일은 쉽지 않을 수 있으며 복잡성이 증가하고 도구가 난립할 위험도 분명히 존재합니다.
이 백서에서는 F5 BIG-IP 어플라이언스(물리 및 가상)의 배포, 관리, 구성을 자동화할 수 있는 방법을 개괄적으로 살펴보고, 비즈니스에 적합한 방식을 선택하는 데 도움이 되는 몇 가지 조언을 제공합니다.
자동화 수명 주기
애플리케이션 서비스를 제공하는 수명 주기에는 몇 가지 핵심 자동화 지점이 있습니다. 인프라 모델과 애플리케이션 배포 방식에 따라 이러한 자동화를 모두 개발해야 할 수도 있고, 일부만 개발하면 될 수도 있습니다.
고용량 멀티테넌트 물리적 또는 가상 BIG-IP에 서비스를 배포하는 경우, 해당 BIG-IP가 지원하는 수백 또는 수천 개 애플리케이션의 애플리케이션 서비스 구성을 배포, 모니터링 및 업데이트하는 작업에 비해 부트스트래핑 및 온보딩 활동의 우선순위는 높지 않습니다.
모든 애플리케이션이 여러 환경에서 전용 BIG-IP 인스턴스를 사용하는 배포 모델(테스트 및 QA를 위해 필요할 때 생성되는 임시 인스턴스 포함)을 고려하고 있다면, 부트스트래핑 및 온보딩 프로세스 자동화는 애플리케이션 서비스 자체를 배포하는 것만큼이나 핵심 경로에서 중요한 부분입니다.
환경이 어떠하든, 자동화해야 할 프로세스가 얼마나 많든, 반드시 고려해야 할 몇 가지 핵심 주제가 있습니다.
자동화: 몇 가지 주요 고려 사항
자동화 성숙도 스펙트럼
자동화는 다양한 활동을 포괄합니다. 스펙트럼의 한쪽 끝에는 수동 구성 작업의 속도를 높이기 위해 로컬에서 실행할 수 있는 Bash, TMSH, Python 또는 기타 언어로 작성된 간단한 스크립트 개발이 있습니다. 반대쪽 끝에는 소스 코드 관리, 워크플로 오케스트레이터 및 여러 자동화 도구를 결합하여 리포지토리에 저장된 텍스트 파일로 인프라 구성을 정의하고 변경하는 완전한 ‘코드형 인프라(infrastructure-as-code)’ 시스템이 있습니다. 이 두 극단 사이에는 BIG-IP 플랫폼의 배포 및 구성을 관리하는 데 도움이 되는 다양한 옵션이 있습니다.
변경 가능 vs. 변경 불가능
현재 대부분의 BIG-IP 배포는 가변적이라고 볼 수 있습니다. 즉, 시간이 지남에 따라 구성이 변경될 수 있습니다. 이는 BIG-IP 플랫폼이 주로 여러 애플리케이션에 서비스를 제공하는 멀티테넌트 장치로 배포되기 때문입니다. 새로운 애플리케이션이 배포되거나 기존 애플리케이션이 확장되거나 추가 서비스를 필요로 하면 그에 맞게 BIG-IP 구성이 업데이트됩니다. 이러한 배포 방식을 통해 인프라 팀은 공통 플랫폼에서 애플리케이션에 서비스를 제공하는 중앙 집중식 인프라를 관리할 수 있습니다.
그러나 경우에 따라 BIG-IP 플랫폼은 독립적인 애플리케이션 스택의 일부로 배포되며, 특정 BIG-IP의 서비스가 특정 애플리케이션이나 서비스에 종속됩니다. 이 경우 BIG-IP 구성을 불변으로 취급할 수 있습니다. 즉, 구성은 부팅 시 또는 소프트웨어 이미지의 일부로 설치되며 BIG-IP 인스턴스의 수명 주기 동안 변경되지 않습니다. 구성을 변경하려면 소프트웨어 이미지나 시작 에이전트 스크립트의 내용을 수정한 후 다시 배포합니다. 이 모델은 흔히 “완전히 제거한 후 새로 구축하기(nuke and pave)”라고 합니다. 전반적으로는 덜 일반적이지만, 애플리케이션별 인스턴스를 지원하는 새로운 BIG-IP 라이선스 모델, 향상된 라이선스 도구, 그리고 클라우드에서 BIG-IP를 온보딩하는 데 도움이 되도록 설계된 Node.js 스크립트 및 라이브러리 모음인 F5 cloud libs(https://github.com/F5Networks/f5-cloud-libs) 같은 도구가 등장하면서, 코드와 인프라가 긴밀하게 결합된 격리형 스택을 애플리케이션에 제공해야 하는 조직에서도 이 배포 모델을 실용적인 선택지로 활용할 수 있게 되었습니다.
명령형과 선언형
자동화 인터페이스를 소비자에게 제공하는 방식에는 두 가지 개념적 모델이 있습니다. 가장 일반적인 ‘1세대’ 자동화 스키마는 명령형 모델을 따르는 경향이 있습니다. 명령형 자동화 모델에서는 일반적으로 자동화 소비자가 달성하려는 목표뿐 아니라 이를 달성하기 위한 구체적인 단계(대개 API 호출)까지 알아야 합니다. 이로 인해 고급 서비스의 구성 세부 정보를 이해해야 하는 부담은 물론, 해당 서비스를 자동화 도구와 통합하는 데 따르는 추가적인 복잡성과 수고까지 소비자가 떠안게 되는 경우가 많습니다. 이는 샌드위치를 주문할 때 샌드위치 제조자가 만드는 데 필요한 작업과 그 순서를 알고 있을 것이라 기대하며 단순히 샌드위치를 요청하는 대신, 샌드위치를 만드는 데 필요한 모든 작업을 하나하나 지정하는 것과 같습니다.
반면, 선언형 인터페이스에서는 소비자(사람 또는 기계)가 원하는 결과를 요청하는 방식으로 서비스를 생성할 수 있습니다. 자동화 대상에 요구되는 결과를 바탕으로 구성을 생성할 수 있는 사전 구성된 워크플로 또는 서비스 템플릿이 있으므로, 필요한 모든 단계를 상세히 알 필요는 없습니다. 선언형 인터페이스는 초기 설정이 다소 복잡하지만, 적절한 서비스 템플릿을 구축하고 나면 운영이 간편해져 이러한 복잡성이 상쇄됩니다. 따라서 일반적으로 자동화 시스템을 구축할 때 선호되는 방식입니다.
직접 또는 관리 도구를 통해
또 한 가지 고려해야 할 사항은 자동화 API 호출을 타사 도구에서 변경 대상 장치로 직접 보낼지, 아니면 별도의 관리 도구를 통해 보낼지입니다. 관리 도구를 사용하면 작업을 추상화하고 간소화할 수 있으며, 관리 대상 엔터티에 직접 연결하는 방식보다 강화된 제어 및 로깅 기능을 제공할 수도 있습니다. 다만 신속한 변경이 매우 중요한 상황에 대비해 관리 계층의 고가용성을 보장해야 합니다.
API, 시작 에이전트 또는 CLI?
BIG-IP 디바이스는 대부분의 BIG-IP 기능을 문서화된 스키마를 통해 제공하는 REST API를 사용하여 자동화하는 것이 가장 일반적입니다. 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를 OpenShift 컨테이너 플랫폼 라우터로 사용하거나 F5를 OpenStack 서비스형 로드 밸런싱(LBaaS) 시스템과 함께 사용하는 등 기존 플랫폼 구성 요소를 활용하여 F5 서비스를 적용합니다. 플랫폼 네이티브 인터페이스를 사용하여 서비스를 구성하고, 제공된 드라이버와 기타 소프트웨어가 플랫폼 구성 지시문을 F5 구성으로 원활하게 변환하므로 이러한 메커니즘을 사용할 때 운영 절차를 거의 변경할 필요가 없습니다. 단, 플랫폼 네이티브 인터페이스를 통해 제공되는 기능만 손쉽게 배포할 수 있다는 점에 유의하십시오. - 플랫폼 이벤트 구독
또 다른 일반적인 통합 방법은 소프트웨어 모듈(예: Kubernetes 및 Mesos용 Container Connector)이 플랫폼 내의 이벤트를 구독한 다음 해당 이벤트에 따라 구성을 수정하도록 하는 것입니다. 서비스를 제공해야 하는 애플리케이션에 태그나 레이블을 지정하고, 필요한 태그가 있는 이벤트를 모니터링하도록 커넥터 소프트웨어를 구성하여 배포할 이벤트와 서비스를 선택할 수 있습니다. - 플랫폼 관리 도구와의 통합
많은 프라이빗 클라우드 플랫폼에는 자동화를 위해 설계된 관리 시스템이 있습니다. 예를 들어 VMware에는 vRealize Orchestrator(vRO)를 비롯한 여러 관리 및 통합 도구가 있으며, vRO에는 BIG-IP 구성을 위한 타사 플러그인이 있습니다. 또 다른 예로는 OpenStack HEAT 템플릿 시스템용 플러그인이 있습니다.
서비스 검색
서비스 검색은 완전한 자동화 솔루션은 아니지만, 환경 변화에 맞춰 BIG-IP 구성을 통합할 수 있는 간단하면서도 강력한 방법입니다. 서비스 검색은 API를 통해 클라우드 시스템을 주기적으로 폴링하여 리소스 목록을 가져오고 그에 따라 BIG-IP 구성을 수정하는 방식으로 작동합니다. 특히 리소스가 자동 확장 그룹으로 구성된 환경에서 유용합니다. 백엔드 컴퓨팅 리소스가 확장되면 로드 밸런서가 새 리소스를 인식해야 하기 때문입니다. 서비스 검색 구성 요소는 다음을 위한 F5 클라우드 자동 확장 솔루션과 함께 제공됩니다. AWS 및 Azure.
그렇다면 F5에서 권장하는 자동화 체계가 있을까요? 그렇기도 하고 아니기도 합니다. 고려해야 할 변수가 너무 많기 때문에 완전히 규범적인 조언은 도움이 되지 않습니다. 하지만 필요할 것으로 판단되는 핵심 구성 요소를 하나의 유기적인 제품군으로 통합했습니다.
F5 자동화 툴체인
F5 Automation Toolchain 제품군은 F5 BIG-IP 플랫폼을 CI/CD 도구 체인과 같은 일반적인 자동화 패턴에 통합할 수 있도록 지원하는 기본적인 자동화 및 오케스트레이션 구성 요소로 이루어져 있습니다.
F5 Automation Toolchain에는 다음과 같은 주요 구성 요소가 포함되어 있습니다.
- Application Services 3 Extension(AS3) – 선언적 L4-L7 BIG-IP 애플리케이션 서비스
- Declarative Onboarding Extension(DO) – 선언적 L1-L3 BIG-IP 온보딩
- Telemetry Streaming Extension(TS) – 분석 시스템으로 BIG-IP 텔레메트리를 자동 스트리밍
- API Services Gateway(ASG) – 사용자 지정 iControl LX 확장을 위한 컨테이너 런타임
Automation Toolchain 제품군은 플랫폼 배포(클라우드 템플릿 사용)부터 온보딩, 서비스 구성, 고급 원격 측정 및 로깅에 이르기까지 애플리케이션 서비스의 제공 수명 주기를 관리하여 운영 중인 애플리케이션의 성능을 보장하도록 설계되었습니다.
지원되는 도구로 구성된 이 확장 중인 제품군은 F5 애플리케이션 서비스 자동화가 나아갈 미래 방향을 제시합니다. 하지만 이것이 다른 통합 기능이 존재하지 않거나 지원되지 않는다는 의미는 아닙니다. 이 문서의 “기타 자동화 도구” 섹션을 참조하십시오.
Application Services 3 확장
F5 Application Services 3 Extension(AS3)은 선언적 REST API를 통해 BIG-IP 플랫폼에서 계층 4~7 애플리케이션 서비스 배포를 자동화하는 간단하고 일관된 방법을 제공합니다. AS3은 JSON 문서로 표현되는 명확하게 정의된 객체 모델을 사용합니다. 선언적 인터페이스를 통해 F5 애플리케이션 서비스 배포를 쉽고 안정적으로 관리할 수 있습니다.
다이어그램: AS3 아키텍처
AS3 확장은 선언을 수집하고 분석한 후, 대상 BIG-IP에 원하는 최종 상태를 생성하기 위해 적절한 iControl API를 호출합니다. 이 확장은 BIG-IP 인스턴스에서 실행하거나, AS3 확장을 실행한 다음 BIG-IP에 외부 API를 호출하는 별도의 컨테이너/VM인 AS3 Container를 통해 실행할 수 있습니다.
AS3 호출은 BIG-IQ를 통해서도 수행할 수 있습니다. BIG-IQ는 BIG-IP 플랫폼을 위한 라이선싱, 관리, 시각화 및 액세스 제어 기능을 제공하며, F5 Cloud Edition을 지원합니다. F5 Cloud Edition은 강력한 분석 기능과 결합된 애플리케이션별 BIG-IP 인스턴스를 온디맨드 방식으로 제공합니다.
선언적 온보딩 확장
The Declarative Onboarding 확장 기능은 초기 부팅 직후의 F5 BIG-IP 플랫폼을 애플리케이션용 보안 및 트래픽 관리를 배포할 수 있는 상태로 전환하는 간단한 인터페이스를 제공합니다. 여기에는 라이선스 및 프로비저닝과 같은 시스템 설정, VLAN 및 Self IP와 같은 네트워크 설정, 그리고 둘 이상의 BIG-IP 시스템을 사용하는 경우의 클러스터링 설정이 포함됩니다.
온보딩 프로세스가 완료되면 선택한 자동화(또는 수동) 프로세스를 사용하여 애플리케이션 서비스를 배포할 수 있습니다.
Declarative Onboarding은 AS3 스키마와 일관된 JSON 스키마를 사용하며 유사한 아키텍처를 갖추고 있습니다. Declarative Onboarding은 TMOS와 독립적인 RPM으로 제공되며, 온보딩 단계의 첫 번째 과정에서 새로 부팅된 BIG-IP에 설치됩니다.
텔레메트리 스트리밍 확장
BIG-IP은 애플리케이션, 보안 및 네트워크 원격 분석 데이터를 생성하는 강력한 도구입니다. Telemetry Streaming 확장 기능은 다음과 같은 타사 소비자에게 통계 및 이벤트를 스트리밍하도록 구성할 수 있는 선언적 인터페이스를 제공합니다:
- Splunk
- Azure Log Analytics
- AWS CloudWatch
- AWS S3
- Graphite
Automation Toolchain 제품군의 다른 구성 요소와 마찬가지로, 구성은 간단하고 일관된 JSON 스키마를 사용하는 선언적 인터페이스를 통해 관리됩니다.
API 서비스 게이트웨이
The API 서비스 게이트웨이는 사용자 지정 iControl LX 확장 기능을 TMOS 독립 플랫폼에서 실행할 수 있게 해 주는 Docker 컨테이너 이미지입니다. 개별 BIG-IP 플랫폼에서 관리 작업을 추상화하여 F5 배포를 확장하고 관리하는 데 도움이 됩니다.
클라우드 템플릿 – 솔루션의 일부이지만 (아직은) 제품군에 포함되지 않음
클라우드 템플릿은 퍼블릭 및 프라이빗 클라우드의 배포 자동화 기능을 사용하여 BIG-IP 가상 어플라이언스를 프로비저닝하고 부팅합니다.
F5는 현재 다음 클라우드용 템플릿을 지원합니다:
- AWS – CloudFormation 템플릿
- Azure – Azure Resource Manager 템플릿
- Google – Google Deployment Manager 템플릿
- VMware - vCenter 템플릿
- OpenStack – Heat 오케스트레이션 템플릿
F5는 더 다양한 배포 시나리오를 지원할 수 있도록 클라우드 템플릿을 적극적으로 개발하고 있습니다. 관련 github 리포지토리를 통해 이슈 또는 풀 리퀘스트를 제출해 주세요.
오케스트레이션 및 워크플로 도구와 지속적 제공/배포
애플리케이션 서비스는 정상적으로 작동하는 애플리케이션을 구성하는 기술 스택의 한 계층일 뿐입니다. 애플리케이션을 코드 커밋 단계에서 실제 운영 환경에 배포하고 모니터링하기까지 모든 구성 요소를 통합, 빌드 및 배포하려면 상호 의존적인 수많은 단계를 올바른 순서로 실행해야 합니다. 이러한 작업을 자동화하는 것이 오케스트레이션 도구의 역할이며, 이 도구는 서로 연계된 작업과 도구로 구성된 워크플로 파이프라인을 생성합니다.
대부분의 파이프라인은 애플리케이션 코드, 테스트 코드 및 인프라 구성을 보관하는 소스 코드 리포지토리에서 시작됩니다.
AS3, 클라우드 템플릿, Declarative Onboarding과 같은 도구를 사용하면 애플리케이션 서비스를 구축하고 구성하는 데 필요한 모든 구성 정보를 배포 파이프라인의 일부로 저장할 수 있습니다.
다중 테넌트 방식의 장기 운영 BIG-IP 하드웨어 또는 소프트웨어 플랫폼을 사용하는 아키텍처에서는 애플리케이션 코드 리포지토리의 일부로 AS3 구성만 관리하면 됩니다. 반면 배포 프로세스의 일부로 전용 인스턴스를 온디맨드로 시작하려는 경우에는 템플릿과 Declarative Onboarding 선언도 애플리케이션 리포지토리에서 관리해야 합니다.
기타 자동화 도구: 리소스 가이드
가능한 모든 자동화 또는 오케스트레이션 도구를 다룰 수는 없지만, 아래에는 F5 고객이 가장 많이 사용하는 도구와 사용 사례 및 기능을 정리했습니다.
---------------
언어 통합
언어
상태
예시 및 출처
Python
F5 기여
https://github.com/F5Networks/f5-common-python
Go
사용자 제공
https://github.com/f5devcentral/go-bigip
PowerShell
F5 지원
https://devcentral.f5.com/wiki/icontrol.powershell.ashx
구성 관리 및 인프라 자동화 도구
도구
상태
예시 및 출처
Ansible
F5 제공
https://github.com/F5Networks/f5-ansible
Terraform
F5 기여
https://github.com/f5devcentral/terraform-provider-bigip
Puppet
F5 기여
https://github.com/f5devcentral/f5-puppet
Chef
사용자 제공
https://github.com/target/f5-bigip-cookbook
SaltStack
서드 파티
https://docs.saltstack.com/en/latest/ref/runners/all/salt.runners.f5.html
인프라 템플릿 시스템
플랫폼
상태
예시 및 출처
AWS
F5 지원
https://github.com/F5Networks/f5-aws-cloudformation
Azure
F5 지원
https://github.com/F5Networks/f5-azure-arm-templates
F5 지원
https://github.com/F5Networks/f5-google-gdm-templates
OpenStack
F5 지원
https://github.com/F5Networks/f5-openstack-hot
------------------
시작 에이전트 및 클라우드 스크립트
Cloud-init
클라우드 라이브러리
https://github.com/F5Networks/f5-cloud-libs
--------------------
플랫폼 통합
컨테이너 관리 플랫폼
플랫폼
상태
예시 및 출처
쿠버네티스
F5 지원
https://github.com/F5Networks/k8s-bigip-ctlr
Pivotal Cloud Foundry
F5 지원
https://github.com/F5Networks/cf-bigip-ctlr
마라톤
F5 지원
https://github.com/F5Networks/marathon-bigip-ctlr
Red Hat OpenShift
F5 지원
https://hub.docker.com/r/f5networks/k8s-bigip-ctlr (https://hub.docker.com/r/f5networks/k8s-bigip-ctlr) 또는
https://access.redhat.com/containers/?tab=tags#/registry.connect.redhat.com/f5networks/k8s-bigip-ctlr (https://access.redhat.com/containers/?tab=tags#/registry.connect.redhat.com/f5networks/k8s-bigip-ctlr)
프라이빗 클라우드 플랫폼
플랫폼
상태
예시 및 출처
OpenStack (LBaaS)
F5 지원
https://github.com/F5Networks/f5-openstack-lbaasv2-driver
OpenStack(Heat)
F5 지원
https://github.com/F5Networks/f5-openstack-hot
VMware (vRO)
타사
https://bluemedora.com/products/f5/big-ip-for-vrealize-operations/
-----------------------
오케스트레이션 및 워크플로 도구에 관한 참고 사항
위의 도구와 통합 기능은 애플리케이션 가용성, 보안 및 확장 서비스를 제공하도록 BIG-IP 플랫폼을 자동으로 배포하고 구성하는 방법입니다. 이러한 서비스는 필수적이지만 전체 스택 애플리케이션 배포의 일부일 뿐입니다. 서버, 데이터, 컴파일된 애플리케이션 코드 및 인프라를 조율되고 검증된 방식으로 구성하여 전체 애플리케이션 스택을 구축하려면 단순한 자동화 도구 이상의 것이 필요합니다.
여러 자동화 시스템과 연계된 워크플로 및 통합 기능을 갖춘 상위 수준의 오케스트레이션 도구가 필요합니다. 이러한 도구는 지속적 통합/지속적 제공(CI/CD) 업무 방식에서 가장 일반적으로 사용되며, 실제로 구현하려면 자동화가 필수적입니다. 다양한 오케스트레이션 도구가 있지만 Jenkins가 가장 널리 사용되며, Jenkins, F5 및 Ansible을 사용하여 F5의 코드형 인프라 기능을 CI/CD 워크플로에 통합하는 방법을 보여 주는 워크플로 예시가 제공됩니다. 하지만 일반적으로 오케스트레이션 도구는 구성 자동화 도구 중 하나를 통해 실제 변경 작업을 수행하고 서비스를 배포합니다.
라이선스
BIG-IP 플랫폼이 작동하려면 라이선스가 필요하므로 자동화의 핵심 경로에 라이선스 부여를 포함하는 것이 좋습니다. BIG-IP 가상 디바이스를 신속하게 확장 또는 축소하거나 테스트 및 개발 목적으로 생성해야 할 수 있는 매우 동적인 환경에서는 라이선스 모델을 신중하게 고려해야 합니다.
퍼블릭 클라우드에서는 클라우드 마켓플레이스를 통해 제공되는 BIG-IP의 사용량 기반 과금 버전을 사용할 수 있습니다. 사용량 기반 과금 인스턴스는 라이선스를 자동으로 활성화하며, 비용은 사용량 또는 약정 기간에 따라 클라우드 공급자를 통해 청구됩니다.
또 다른 옵션은 구독 방식(또는 영구 라이선스)으로 구매한 재사용 가능한 라이선스 풀을 F5 BIG-IQ License Manager와 함께 사용하는 것입니다. 이를 통해 풀에서 라이선스를 할당하고 회수할 수 있습니다.
시작 에이전트와 API 호출을 통해 라이선스 부여 단계를 자동화할 수 있으며, 이 경우 F5 라이선스 서버에 대한 아웃바운드 인터넷 액세스가 필요합니다(클라우드 플랫폼의 유틸리티 라이선스도 해당).
언제 무엇을 사용해야 하나요?
조직의 상황에 따라 적합한 자동화 및 오케스트레이션 도구를 선택하는 일은 매우 쉬울 수도 있고 어려운 과제가 될 수도 있습니다. 다른 구성 요소에 사용할 도구나 방법론을 이미 도입했으며 BIG-IP를 해당 시스템에 통합하기만 하면 되는 경우에는 간단합니다. 특정 도구와 통합하지 않더라도 풍부한 iControl REST API를 iControl LX 기능 및 cloud-init과 함께 활용하면 BIG-IP를 기존 자동화 도구에 비교적 쉽게 통합할 수 있습니다. 특히 단 한 번의 API 호출로 복잡한 구성도 생성할 수 있는 iApp 템플릿과 함께 사용하면 더욱 간편합니다.
하지만 처음부터 시작하는 경우에는 상황이 더 복잡할 수 있습니다. 다른 솔루션을 선택할 때와 마찬가지로 먼저 요구 사항을 파악해야 합니다. 이 문서에서 요구 사항 목록을 대신 작성해 드릴 수는 없지만, 평가에 도움이 되는 몇 가지 질문과 권장 사항을 제시합니다.
자동화 모델: 선언적 모델은 오케스트레이션 사용자가 훨씬 더 간편하게 상호 작용할 수 있도록 해줍니다. 사용자는 목표를 달성하기 위한 모든 절차적 단계를 알 필요 없이 원하는 것이 무엇인지만 알면 됩니다. 앞으로 신규 구축 사이트에서는 F5 Automation Toolchain 제품군이 ‘모델’ 배포 방식을 대표하게 될 것입니다.
잠재적 플랫폼 및 환경: 컨테이너와 다양한 클라우드 플랫폼이 애플리케이션 인프라의 핵심 요소가 되는 것은 불가피하므로 이에 맞게 계획을 수립해야 합니다.
기술 역량: 기반 기술 중 일부에 대해 이미 보유한 역량이 있나요? 이러한 역량은 소속 부서 밖이라도 회사 전체에는 존재할 수 있다는 점을 염두에 두세요. 그렇다면 조직에서 이미 도입한 언어를 사용하는 도구를 선택하는 것이 합리적일 수 있습니다.
지원 가능성: 지원할 수 있는 시스템만 구축하세요. 당연한 말처럼 들릴 수 있지만, 성공의 핵심은 조직 내에서 감당할 수 있는 수준의 복잡성을 선택하여 과도한 운영 부담을 초래하지 않으면서 자동화의 이점을 극대화하는 것입니다.
결론
IT 시스템의 자동화 확대는 피할 수 없는 흐름입니다. 핵심 애플리케이션 전송 및 보안 서비스에 전략적으로 접근하면 조직에서 배포하는 애플리케이션의 보안과 가용성을 유지할 수 있습니다. 또한 자동화는 특히 여러 플랫폼과 퍼블릭 클라우드에서 작업할 때 운영 부담을 줄이는 데 도움이 됩니다.
적합한 자동화 시스템을 선택하는 일은 쉽지 않을 수 있으며, 보유한 기술 역량과 구축할 시스템을 지원할 수 있는 능력을 고려하여 협업을 통해 종합적으로 결정하는 것이 바람직합니다. 어떤 솔루션을 선택하든 BIG-IP 플랫폼과 F5의 전문성을 활용하여 애플리케이션이 어디에 배포되든 애플리케이션에 필요한 엔터프라이즈급 서비스를 제공할 수 있습니다.
F5 지원에 관한 참고 사항입니다. F5는 여러 템플릿과 도구를 지원하지만, 모든 템플릿과 도구를 지원하는 것은 아닙니다. GitHub에서 제공되는 소프트웨어의 경우, 지원되는 코드는 F5 리포지토리의 “supported” 폴더에 있는 코드로만 한정됩니다. 그 밖의 소프트웨어에 대한 지원 정책은 해당 readme 파일에 명시되어 있습니다.
2019년 5월 13일 게시