F5 제품 및 서비스에서 Docker 컨테이너 기술 사용
요약
IT 요구 사항의 변화와 애자일 개발 및 배포 전략의 등장으로 인해, 애플리케이션을 자체 운영 환경을 갖춘 컨테이너에 캡슐화하는 완전한 머신 가상화의 대안인 "컨테이너화"가 부상했습니다. 컨테이너화는 개발자가 더 빠르게 반복 개발할 수 있도록 지원하는 매력적인 솔루션입니다. 또한 가상 머신과 관련된 오버헤드를 줄여 소프트웨어 정의 데이터 센터(SDDC)의 리소스 활용도를 높이는 추가적인 이점도 제공합니다.
컨테이너화는 새로운 개념이 아니지만, Docker, Inc.에서 개발한 Docker는 폭넓은 업계 지원, 표준화, 포괄적인 기능을 바탕으로 가장 선호되는 구현 방식으로 널리 알려져 있습니다. Docker는 자사의 표현에 따르면 "분산 애플리케이션을 구축하고 배포하며 실행하기 위한 개방형 플랫폼입니다. 프로그래머, 개발 팀, 운영 엔지니어가 최신 애플리케이션의 분산 및 네트워크 특성을 활용하는 데 필요한 공통 도구 모음을 제공합니다." 따라서 Docker는 개발부터 배포까지 애플리케이션 수명 주기 관리를 간소화하고 애플리케이션 이식성을 지원합니다. 애플리케이션을 퍼블릭 클라우드 또는 프라이빗 클라우드 인프라에 호스팅할 수 있는 다양한 옵션이 있다는 점을 고려하면, 이러한 간소화는 기업에 매우 중요합니다.
이 백서에서는 F5 기술 내에서 컨테이너를 활용하고 애플리케이션 전송 및 보안을 위해 Docker를 지원하는 것과 관련된 F5의 방향성을 설명합니다. 이 전략을 논의하기에 앞서, 데이터 센터의 문제점을 파악하고 이러한 기술이 차세대 엔터프라이즈 애플리케이션 전송에 중요한 이유를 이해해야 합니다.
참고: 이 문서는 IT 의사 결정권자, 아키텍트 및 개발자를 대상으로 합니다. 독자는 가상화 기술, 소프트웨어 개발 및 릴리스 수명 주기 프로세스에 대한 사전 지식이 있다고 가정합니다.
데이터 센터 인프라의 과제
최근 데이터 센터 인프라의 주요 문제점을 다룬 여러 연구에서는 데이터 센터의 발전을 위해 공통적으로 필요한 사항들을 다음과 같이 제시했습니다:
- 더 빠른 애플리케이션 배포 방식
- 개선된 워크플로 관리 프로세스
- 컴퓨팅 리소스의 가용성 및 활용도 향상
- 필요에 따라 워크로드를 이동할 수 있는 민첩성 향상
애플리케이션 개발 분야에서 새로운 트렌드가 등장함에 따라, 기업 고객은 애플리케이션 수명 주기 관리 모델을 다음과 같은 관점으로 바라보기 시작했습니다:
- 차세대 애플리케이션은 점점 더 "클라우드 우선" 방식으로 구축되고 있습니다.
- Linux는 클라우드 개발을 위한 사실상의 운영 체제(OS)로 자리 잡았습니다.
- 차세대 클라우드 애플리케이션:
- 상태 비저장 방식으로 설계되며 느슨하게 결합된 마이크로서비스 아키텍처를 활용합니다.
- 소프트웨어 버전이나 서비스 간 종속성 없이 각 서비스를 독립적으로 구축할 수 있는 프레임워크를 활용합니다.
- 기업들은 소프트웨어 릴리스의 민첩성을 높이기 위해 구성 관리 도구(예: Puppet, Chef, Ansible)와 DevOps 오케스트레이션을 활용하여 자동화를 점점 더 많이 도입하고 있습니다.
- 기업이 새로운 애플리케이션을 개발하고 기존 애플리케이션을 퍼블릭 클라우드로 마이그레이션함에 따라, 공급업체 종속을 방지하려면 이식성이 매우 중요합니다. 가상 머신(VM) 기술은 일정 수준의 추상화를 제공하지만, 각 하이퍼바이저가 환경을 서로 다르게 구현하므로 완전한 이식성을 보장하지는 못합니다.
Docker는 이러한 과제를 해결하고자 하며, 그 결과 인프라 가상화를 위한 선도적이면서도 매력적인 기술로 부상했습니다.
Docker 개요
컨테이너는 각 애플리케이션을 OS 프로세스로 격리하여 운영 체제 수준의 가상화를 지원합니다. 이 개념은 BSD의 Jails, Oracle Solaris의 Zones, 그리고 최근에는 Linux의 LXC 등 운영 체제에서 다양한 형태로 사용되어 왔습니다. Docker는 LXC를 기반으로 하며, 개발자가 하이퍼바이저 없이도 클라우드 인프라 전반에서 애플리케이션을 빌드하고 패키징하고 배포할 수 있도록 간편한 기능을 추가했습니다.
다음과 같은 기능은 Docker를 다른 컨테이너 기술과 차별화합니다:
- 애플리케이션 간의 격리와 네트워킹을 관리하기 위해 운영 체제 위에서 작동하는 경량 추상화 계층(Docker 엔진).
- Linux 기반 애플리케이션을 더 간편하게 배포할 수 있도록 문서화된 애플리케이션 프로그래밍 인터페이스(API).
- 다른 사용자 및 개발자와 애플리케이션을 공유하기 위한 Docker Registry.
- 물리적 호스트, 가상 호스트 또는 클라우드 호스팅 호스트 등 Docker를 지원하는 호스트 간의 애플리케이션 이식성.
- 모든 Docker 컨테이너에 공통 파일 시스템을 제공하는 유니온 파일 시스템.
- 부가 가치 서비스와 소프트웨어를 제공하는 파트너 기업 생태계를 통해 Docker를 다양한 개발 방식에 원활하게 통합할 수 있습니다.
유니온 파일 시스템이란 무엇인가요?
유니온 파일 시스템을 사용하면 기본 경로와 파일 이름이 하위 파일 시스템의 파일과 충돌하더라도 각 컨테이너가 해당 컨테이너에 필요한 고유한 서비스를 제공할 수 있습니다. 예를 들어 한 컨테이너에는 Python 라이브러리 버전 2.6이 필요하고 다른 컨테이너에는 그보다 최신 버전이 필요할 수 있습니다. 하위 파일 시스템에서 버전 2.6을 제공한다면 한 컨테이너의 요구 사항은 충족됩니다. 반면 최신 버전이 필요한 컨테이너는 해당 버전을 컨테이너 이미지의 일부로 제공할 수 있습니다. 따라서 컨테이너 이미지에는 실행에 반드시 필요한 항목만 포함하면 되므로 이미지의 용량을 줄일 수 있습니다.
Docker 컨테이너화 및 가상 머신 기술 요약
그림 1의 다이어그램은 VM 및 Docker 애플리케이션 배포에 사용되는 구성 요소를 보여 줍니다. 이 예에서 VM 방식은 두 개의 애플리케이션을 지원하기 위해 두 개의 게스트 운영 체제를 사용합니다. 반면 Docker는 동일한 애플리케이션 집적도를 구현하는 데 하나의 호스트 OS만 필요하므로 오버헤드가 더 적습니다.
다음 표는 VM과 Docker의 기능을 비교한 것입니다.
가상 머신에서 Docker 사용
앞서 언급했듯이 Docker의 주된 목표는 애플리케이션 수명 주기 관리를 간소화하는 것입니다. 베어 메탈에서 Docker를 실행하는 것도 분명 매력적인 선택이지만, 하이퍼바이저에서 Docker를 실행하면 여러 이점이 있습니다. 여기에는 스냅샷을 생성하고 전체 게스트를 라이브 마이그레이션할 수 있는 기능이 포함되며, 두 기능 모두 진행 중인 상태를 잃지 않고 재해 복구를 수행하기 위한 핵심 요구 사항일 수 있습니다.
VMware vRealize Suite, OpenStack과 같은 선도적인 인프라 관리 및 오케스트레이션 솔루션과 AWS, Azure 같은 퍼블릭 클라우드는 모두 특정 유형의 하이퍼바이저에서 Docker를 지원하는 동시에 Docker 컨테이너에 공통 환경을 제공하므로, 환경에 관계없이 애플리케이션의 이식성을 확보할 수 있습니다. 이러한 유형의 이기종 배포 모델을 사용하면 고객은 기본 인프라를 변경하지 않고도 Docker를 도입하여 더 빠르게 반복 개선할 수 있는 이점을 누릴 수 있습니다.
호스트당 단일 VM과 OS를 사용하는 방식으로 전환하면 VM 간에 리소스를 두고 경합할 필요가 없어 고객은 리소스 활용 측면에서도 이점을 얻을 수 있습니다. 메모리와 로컬 디스크를 해당 단일 OS에 할당할 수 있고 하이퍼바이저가 더 이상 여러 운영 체제 간의 리소스를 조정할 필요가 없으므로 효율성이 향상됩니다.
Docker 네트워킹 기술 개요
네트워킹을 사용하면 여러 호스트에 걸쳐 있는 가상 네트워크를 Docker Engine에서 생성할 수 있습니다. 컨테이너는 위치에 관계없이 이러한 네트워크에 연결할 수 있으므로 네트워크 토폴로지와 각 컨테이너가 통신할 수 있는 다른 네트워크 요소를 완벽하게 제어할 수 있습니다. 또한 네트워크를 구동하는 시스템을 플러그인으로 교체할 수 있어 애플리케이션을 수정하지 않고도 원하는 네트워킹 시스템과 통합할 수 있습니다.
특정 호스트에서 많은 수의 컨테이너를 수용하려면 각 컨테이너가 네트워크에 연결되는 방식을 이해하는 것이 중요합니다. Docker는 기본적으로 각 컨테이너에 동일한 호스트에 있는 다른 컨테이너에서만 직접 접근할 수 있는 사설 주소를 제공합니다.
다른 호스트의 서비스가 컨테이너에 접근하려면 Docker의 iptables 기반 네트워크 주소 변환(NAT) 기능을 통해 트래픽을 라우팅해야 합니다. 그림 2에 예시가 나와 있습니다.
호스트 인터페이스(Eth0)는 별도의 주소(이 경우 또 다른 RFC1918 주소인 192.168.10.10)를 사용하여 외부에 노출됩니다. 각 Docker 컨테이너에는 시작 시 172.x.x/16 대역의 주소가 자동으로 할당됩니다. 컨테이너가 호스트 외부의 엔터티와 양방향으로 통신하려면 iptables를 통해 명시적인 규칙 집합을 할당해야 합니다.
그림 2의 예에서는 컨테이너가 IP 및 포트 매핑을 통해 통신할 수 있도록 규칙이 구성되어 있으며, 컨테이너 A는 192.168.10.10/포트 80으로, 컨테이너 B는 192.168.10.10/포트 81로 노출됩니다. 그러나 컨테이너 C는 172.17.0.x 주소 체계를 사용해야만 다른 두 컨테이너와 통신할 수 있습니다.
Docker는 IPv6도 지원하며 완전히 라우팅 가능한 주소를 사용할 수 있습니다. 따라서 주소 매핑 없이도 컨테이너가 서로 다른 호스트의 다른 컨테이너와 통신할 수 있습니다. 하지만 이는 IPv6에서만 작동하므로 일부 환경에서는 활용이 제한적일 수 있습니다.
SDN과 Docker
많은 소프트웨어 정의 데이터 센터에서는 게스트를 유연하게 배포하기 위해 소프트웨어 정의 네트워킹(SDN) 개념을 사용합니다. SDN을 사용하면 동일한 물리적 하드웨어에서 서로 독립된 테넌트별로 격리된 네트워크 터널을 구성할 수 있습니다. 또한 원래라면 완전히 라우팅되는 클라우드 데이터 센터 내부에 터널링된 계층 2 네트워크를 제공하는 데에도 유용합니다. Docker 네트워킹은 Docker Bridge 개념을 기반으로 하며, 이를 Open vSwitch에 연결하여 VXLAN 또는 GRE와 같은 기술과의 상호 운용성을 지원할 수 있습니다.
이러한 방식으로 Open vSwitch를 사용하면 멀티테넌시를 위해 계층 2 네트워크를 분리할 수 있을 뿐만 아니라 다른 가상화 환경에 연결할 수도 있습니다. 예를 들어 Docker를 활용하는 데이터 센터에서도 전용 리소스를 확보해야 하는 핵심 서비스에는 여전히 가상 머신을 사용할 가능성이 높습니다. 여기에는 애플리케이션 전송 서비스나 데이터베이스 및 처리 노드와 같은 고성능 리소스가 포함될 수 있습니다. 이러한 리소스는 VXLAN 또는 GRE와 같은 기술을 통해 네트워크에 연결하여 한 테넌트의 트래픽이 다른 테넌트에 노출되지 않도록 할 수 있습니다.
이러한 유형의 환경에서 애플리케이션을 확장하려면 터널링 프로토콜을 기본적으로 지원하는 ADC 서비스가 필요합니다. F5는 멀티테넌트 VXLAN 및 GRE 기능을 제공하므로 로드 밸런싱, SSL 오프로딩, 방화벽, 애플리케이션 보안, NAT, DNS 등의 서비스를 터널을 통해 네트워크의 클라이언트에 제공할 수 있습니다. 또한 F5는 802.1Q VLAN을 비롯한 다양한 터널 캡슐화 유형 간의 상호 운용성을 제공합니다.
그림 3의 예시에서 데이터베이스와 같은 핵심 애플리케이션 계층은 Docker 인스턴스를 호스팅하는 데 사용되는 리소스와 데이터 센터 내 서로 다른 위치에 있을 수 있습니다. 이 경우 테넌트 네트워크는 GRE 또는 VXLAN을 사용하여 물리적으로 분리된 두 서브넷을 격리하면서 연결할 수 있습니다.
BIG-IP 인스턴스에 VXLAN 터널 엔드포인트(VTEP)를 생성하면 BIG-IP 솔루션을 테넌트 수준에서 네트워크에 원활하게 통합할 수 있습니다. 그러면 이 솔루션은 Docker 및 가상 머신 인스턴스에 연결할 수 있는 테넌트 네트워크의 일부가 됩니다.
Docker는 버전 1.7부터 기본 Docker 네트워킹 기능을 SDN 개념으로 확장하는 몇 가지 실험적 기능을 제공하기 시작했습니다. 플러그인 아키텍처는 애플리케이션을 인식하는 컨테이너를 활용한 차세대 방화벽, 컨테이너 흐름 분석 및 정책 적용, 흐름별 트래픽 관리 등 다양한 새로운 사용 사례에 F5 네트워크 및 애플리케이션 전송 서비스를 도입할 수 있는 획기적인 기회를 제공합니다.
Docker 컨테이너화에 대한 F5의 방향
F5는 가상화를 지원하는 다양한 제품을 제공합니다. 업계에서 가장 광범위한 L4–L7 애플리케이션 전송 및 보안 서비스 포트폴리오를 보유한 ADC 시장의 선두 주자로서, F5는 혁신적인 기술을 지속적으로 모색하고 있습니다. 또한 모든 BIG-IP 플랫폼이 공통 기반 프레임워크를 공유하므로 이러한 기술을 플랫폼 전반으로 확장하고 있습니다. 그림 4는 맞춤형 하드웨어부터 L4-L7 서비스를 위한 완전한 클라우드 기반 서비스형 제품에 이르기까지 F5의 다양한 제품군을 보여 줍니다. BIG-IP 플랫폼은 Docker 컨테이너에서 실행되는 애플리케이션을 지원하는 데 매우 적합합니다.
Docker를 통한 F5 플랫폼의 진화
앞서 언급했듯이 F5는 다양한 사용 사례에서 Docker가 제공하는 이점을 잘 알고 있습니다. 그러나 컨테이너화된 인프라에서의 배포는 아직 초기 단계이며, 서비스 검색(예: Consul, etcd, Mesos-DNS), 오케스트레이션, 컨테이너 서비스의 수명 주기 관리(예: Mesos, OpenStack, Kubernetes, Docker, Cloud Foundry)를 위한 여러 옵션이 존재합니다. 네트워킹 서비스는 이 생태계의 핵심 요소이지만, 원활한 배포를 보장하려면 오케스트레이션 환경과 긴밀하게 통합하는 것이 중요합니다. 이러한 통합은 컨테이너화된 인프라에서 마이크로서비스 기반 애플리케이션을 배포하는 사용자가 L4-L7 서비스를 투명하게 이용할 수 있도록 하는 데에도 필수적입니다. F5의 접근 방식은 베어 메탈, 가상화 또는 컨테이너화된 배포 환경 전반에서 일관된 서비스 경험과 시각화 기능을 제공하는 데 중점을 둡니다.
문제 해결의 첫 단계는 남북(N-S) 트래픽(즉, “클라이언트 측에 노출되는 마이크로서비스”의 트래픽)에 네트워킹 서비스를 제공하는 것입니다. 대부분의 주요 오케스트레이션 플랫폼은 컨테이너화된 서비스의 배포 및 확장과 외부 연결 공개를 처리합니다. F5는 주요 컨테이너 오케스트레이션 플랫폼과 긴밀하게 통합함으로써 BIG-IP 시스템이 N-S 마이크로서비스를 자동으로 검색하고 해당 서비스의 트래픽을 관리할 수 있도록 합니다. 예를 들어 Mesosphere Marathon과 Kubernetes는 서비스에 “레이블”을 지정하는 옵션을 제공합니다. 이러한 레이블을 사용하면 생성, 제거 또는 확장된 클라이언트 측 노출 서비스를 검색하여 BIG-IP 시스템에 풀 멤버로 자동 추가할 수 있습니다.
BIG-IP 하드웨어 또는 가상 에디션(VE)에 위의 접근 방식을 적용하면 다음과 같은 하드웨어 가속 기반의 핵심 기능을 중앙 집중화할 수 있습니다:
- 중앙 집중식 인증서 관리를 통한 SSL 오프로딩.
- 압축, TCP 최적화, SPDY/HTTP2 등의 가속 기능.
- DoS 보호 기능을 갖춘 고급 방화벽.
- 애플리케이션 계층 공격을 차단하는 애플리케이션 인식 기능.
- 모든 인바운드 및 아웃바운드 네트워크 연결에 대한 가시성.
- 지능형 로깅 및 이상 탐지를 통해 디버깅 기능이 크게 향상됩니다.
F5 및 DNS 지원을 통한 IPv4-IPv6 변환
F5 솔루션은 컨테이너화된 애플리케이션을 확장하고 Docker 인프라와 외부 네트워크 간에 IPv4-IPv6 변환 및 DNS 변환을 수행할 수 있도록 지원합니다. 완전한 라우팅이 가능한 Docker 컨테이너 인프라를 활용하려면 효율적인 IPv4-IPv6 네트워크 기능뿐만 아니라 DNS 요청 변환 지원도 필요합니다. Docker 컨테이너 인프라는 IPv4와 완전히 분리된 순수 IPv6 환경에서 운영하면서도 IPv4 연결로 이어지는 원활한 경로를 유지할 수 있습니다.
그림 5에 표시된 예에서는 NAT64 및 DNS64 서비스가 프로비저닝되어 있습니다(마찬가지로 물리적 또는 가상 형태 모두 가능). Docker 컨테이너는 www.example.com에 연결을 시도하지만, 이 예에서는 해당 도메인에 대한 IPv6 주소가 없습니다.
BIG-IP 시스템은 Docker 플랫폼 설치 환경의 DNS 확인자로 구성됩니다. DNS 확인자 자체의 IPv6 주소와 IPv4에서 IPv6로 변환하기 위한 특수 IPv6 접두사 주소(빨간색으로 표시됨)도 구성됩니다.
BIG-IP 장치는 IPv6 DNS 쿼리를 수신하면 먼저 재귀 조회를 수행하여 IPv6 주소를 사용할 수 있는지 확인합니다. 그러나 이 예에서는 www.example.com의 권한 있는 DNS 서버가 AAAA 요청에 대해 빈 레코드로 응답합니다. 그러면 BIG-IP 장치는 IPv4 쿼리를 수행하여 DNS A 레코드를 수신합니다. 그런 다음 IPv4 주소 앞에 특수 접두사 주소를 추가하여 Docker 클라이언트로 다시 전송합니다.
이제 Docker 클라이언트의 주소 확인이 완료되어 TCP 연결을 시작합니다. Docker가 특수 접두사를 사용하고 있으므로 NAT64 기능은 IPv6에서 IPv4로의 변환이 필요하다는 것을 인식합니다.
NAT64 기능은 Docker IPv6 주소, 이 IPv4 서버에 대해 특수 접두사가 붙은 NAT64 주소, 그리고 IPv4 서버 간의 연결을 위한 바인딩을 생성합니다. 연결 요청은 IPv4 서버로 전송됩니다. IPv4를 통해 응답하는 해당 서버의 모든 응답은 Docker 컨테이너와 IPv4 서버 간의 연결을 위해 NAT64 기능에 의해 변환됩니다.
F5 및 동서 트래픽 흐름
긴밀한 통합을 구현하기 위한 다음 핵심 단계는 ADC 서비스가 필요한 마이크로서비스 간에 전달되는 데이터, 즉 동서(E-W) 트래픽에 서비스를 제공하는 것입니다. 수초 내에 서비스를 가동해야 한다는 점과 마이크로서비스의 일시적인 특성을 고려하여, F5는 경량 ADC를 활성화하는 방식을 채택합니다. (인증이나 L7 애플리케이션 수준 보호와 같은 고급 서비스의 경우, 트래픽은 남북(N-S) 경계의 BIG-IP 인스턴스로 리디렉션됩니다.)
마이크로서비스 아키텍처에서는 컨테이너화된 서비스의 수가 기존 아키텍처보다 훨씬 많고, 마이크로서비스 간 통신 경로도 다양합니다. 이러한 아키텍처는 복잡성을 높여 성능 문제를 해결하기 어렵게 만들 수 있습니다. 예를 들어 애플리케이션의 성능이 저하된 경우, N-S 에지에서부터 여러 서비스 전반에 이르는 엔드투엔드 가시성을 확보하는 것이 중요합니다. 따라서 문제 해결을 위해서는 N-S 도메인의 BIG-IP 시스템과 E-W 도메인의 경량 ADC 간 트래픽 패턴을 연계하여 파악할 수 있는 중앙 집중식 시각화 방식이 매우 중요합니다.
F5 BIG-IP 솔루션 인스턴스를 애플리케이션 사이에 배치하여 부하 분산 또는 보안 서비스를 제공함으로써 E-W 트래픽에 대한 보안 문제를 해결할 수도 있습니다. 예를 들어 한 컨테이너에서 전송되는 트래픽이 다른 컨테이너로 들어가기 전에 분석을 위해 BIG-IP 시스템을 통과하도록 Docker 호스트를 구성할 수 있습니다. 이 작업은 애플리케이션을 인식하고 해당 컨테이너가 취약점 악용과 같은 공격을 받고 있는지 탐지할 수 있는 BIG-IP Application Security Manager™(ASM)를 사용하여 수행할 수 있습니다.
Docker 서비스 제공을 위한 F5의 단계적 접근 방식
현재 F5 고객이 성공적으로 구축한 많은 환경에서는 컨테이너화를 대규모로 활용하고 있습니다. 이러한 조직은 금융, 통신, SaaS 제공업체를 비롯한 다양한 산업 분야에 걸쳐 있습니다. 현재 이러한 환경에서 F5 솔루션은 애플리케이션의 빠른 속도와 보안, 가용성을 보장하기 위해 ADC 서비스를 제공합니다. 이러한 서비스는 애플리케이션 소유자 또는 DevOps가 셀프서비스 방식으로 이용할 수 있도록 통합하거나, 컨테이너 관리 시스템을 통해 오케스트레이션할 수 있습니다.
F5는 서비스 검색, 동서(E-W) 트래픽 관리 및 보안을 지원하기 위해 이러한 서비스를 컨테이너화된 인프라 자체로 확장할 계획입니다. 또한 F5는 물리적 플랫폼에서 컨테이너 기술을 활용하고, 컨테이너에서 소프트웨어 서비스를 제공하며, F5 Silverline® 클라우드 기반 서비스 플랫폼에 컨테이너화된 아키텍처를 적용하는 등 제품군 전반에서 컨테이너화를 활용할 계획입니다.
아래 표에서는 F5가 검토 중이거나 적극적으로 개발하고 있는 방향을 간략히 살펴볼 수 있습니다:
결론
Docker는 물리적 데이터 센터와 클라우드 기반 데이터 센터 모두에서 효율성을 높일 수 있는 확실한 기회를 제공합니다. 동시에 Docker를 도입한 기업은 애플리케이션을 새로운 환경으로 원활하게 이전할 수 있다는 확신을 가질 수 있습니다. 특히 Docker를 활용하면 애플리케이션 개발자가 민첩성을 높이고 애플리케이션을 더 빠르게 시장에 출시할 수 있습니다. 고객은 DevOps를 Docker 모델로 전환하면서 개발자가 애플리케이션을 배포할 수 있는 소규모 표준화 서비스를 기반으로 새로운 셀프서비스 워크플로를 도입하는 경우가 많습니다.
Docker는 경량 컨테이너 인스턴스화를 통해 애플리케이션을 빠르게 확장할 수 있도록 지원하며, F5 애플리케이션 전송 제품은 이러한 환경을 완벽하게 지원합니다. 고객은 F5 BIG-IP 솔루션을 사용하여 애플리케이션의 전체 수명 주기를 오케스트레이션할 수 있습니다. VIP 생성 및 유지 관리, 중앙 집중식 SSL/인증서 관리, 방화벽 서비스, 멀티테넌트 아키텍처에서 고가용성을 갖춘 애플리케이션 보안과 같은 핵심 작업을 위한 포괄적인 REST API를 통해 이를 수행할 수 있습니다.
Docker는 퍼블릭 및 프라이빗 클라우드 배포를 비롯한 다양한 모델에서 활용할 수 있습니다. F5는 이러한 환경을 위한 상호 운용성과 지원을 제공하는 데 앞장서고 있으며, OpenStack, VMware 및 Amazon AWS, Microsoft Azure와 같은 주요 클라우드 공급자를 위해 특별히 설계된 핵심 기능을 제공합니다.
Docker가 주요 구성 요소인 진화된 DevOps 모델로 전환하는 고객은 잠재적인 운영 개선 효과를 실현하려면 확장성과 보안성, 고가용성을 갖추고 새로운 워크플로가 요구하는 수준의 민첩성을 제공하는 플랫폼이 필요하다는 점을 잘 알고 있습니다. F5 제품과 서비스는 업계에서 가장 폭넓은 기술 및 기술 파트너와 연동하여 Docker 비전의 실현을 지원하도록 설계되었습니다. Docker에 대한 F5의 확고한 의지는 탄탄한 로드맵 투자와 지속적인 제품 개선으로 뒷받침되며, 이를 통해 소프트웨어 정의 데이터 센터의 주요 배포 모델 중 하나로 자리 잡을 Docker의 성공을 보장합니다.
2016년 6월 20일 게시