F5 제품 및 서비스와 함께 Docker 컨테이너 기술 사용

IT의 변화하는 요구 사항과 민첩한 개발 및 배포 전략의 등장으로 인해 전체 머신 가상화에 대한 대안인 "컨테이너화"가 등장했습니다. 여기서 애플리케이션은 자체 운영 환경이 있는 컨테이너에 캡슐화됩니다. 컨테이너화는 개발자가 더 빠르게 반복 작업을 수행할 수 있게 해주는 매력적인 솔루션입니다. 또한 가상 머신과 관련된 오버헤드를 해결하는 추가적인 이점을 제공하여 소프트웨어 정의 데이터 센터(SDDC)에서 리소스를 더 많이 활용할 수 있습니다.

컨테이너화는 새로운 개념이 아니지만 Docker, Inc. 에서 개발한 Docker는 광범위한 업계 지원, 표준화, 포괄적인 기능 범위로 인해 최선의 구현체로 널리 인용되었습니다. 회사 측에 따르면 Docker는 "분산형 애플리케이션을 빌드, 배송, 실행하기 위한 개방형 플랫폼"입니다. 프로그래머, 개발팀, 운영 엔지니어에게 현대적 애플리케이션의 분산되고 네트워크화된 특성을 활용하는 데 필요한 공통적인 도구 상자를 제공합니다." 따라서 Docker는 개발에서 배포까지 애플리케이션 수명 주기 관리를 간소화하고 애플리케이션 이동성을 지원합니다. 퍼블릭 클라우드나 프라이빗 클라우드 인프라에서 애플리케이션을 호스팅하는 옵션이 여러 개 있다는 점을 고려할 때, 이러한 단순화는 기업에 매우 중요합니다.

이 논문에서는 F5 기술 내에서 컨테이너를 사용하고 애플리케이션 제공 및 보안을 위해 Docker를 지원하는 방법에 대한 F5의 방향을 설명합니다. 이러한 전략을 논의하기 전에 데이터 센터의 문제점을 파악하고 이러한 기술이 차세대 엔터프라이즈 애플리케이션 제공에 왜 중요한지 알아보는 것이 중요합니다.

메모: 이 문서는 IT 의사결정권자, 설계자, 개발자를 대상으로 합니다. 독자는 가상화 기술, 소프트웨어 개발 및 릴리스 수명 주기 프로세스에 대한 사전 지식이 있다고 가정합니다.

데이터 센터 인프라의 문제점에 대한 최근의 여러 연구에서 데이터 센터를 발전시키기 위한 일관된 요구 사항이 확인되었습니다.

• 더 빠른 애플리케이션 배포 방법
• 개선된 워크플로 관리 프로세스
• 컴퓨팅 리소스의 가용성 및 활용도 향상
• 필요에 따라 작업 부하를 이동할 수 있는 민첩성 향상

애플리케이션 개발에 새로운 트렌드가 등장함에 따라 기업 고객은 애플리케이션 수명 주기 관리 모델에 대한 관점을 다음과 같이 전환하고 있습니다.

• 차세대 애플리케이션은 점점 더 "클라우드 우선"으로 구축되고 있습니다.
• Linux는 클라우드 개발을 위한 사실상의 운영 체제(OS)가 되었습니다.
• 차세대 클라우드 애플리케이션:
  • 상태 비저장 방식으로 설계되었으며 느슨하게 결합된 마이크로 서비스 아키텍처를 활용합니다.
  • 소프트웨어 버전이나 서비스 종속성 없이 서비스를 독립적으로 구축할 수 있는 프레임워크를 활용합니다.
• 기업들은 구성 관리 도구(Puppet, Chef, Ansible 등)와 DevOps 오케스트레이션을 사용하여 자동화를 점점 더 많이 도입하고 있으며, 이를 통해 소프트웨어 출시의 민첩성을 높이고 있습니다.
• 기업이 새로운 애플리케이션을 개발하고 기존 애플리케이션을 퍼블릭 클라우드로 마이그레이션함에 따라 공급업체에 대한 종속성을 피하려면 이식성이 중요합니다. 가상 머신(VM) 기술은 일정 수준의 추상화를 제공하지만, 각 하이퍼바이저는 환경을 다르게 구현하기 때문에 완벽한 이식성은 없습니다.

Docker는 이러한 과제를 해결하고자 시도했으며, 그 결과 인프라 가상화를 위한 선도적이고 매력적인 기술로 떠올랐습니다.

컨테이너는 각 애플리케이션을 OS 프로세스로 격리하여 OS 수준에서 가상화를 가능하게 합니다. 이 개념은 BSD와 Jails, Oracle Solaris와 Zones, 그리고 가장 최근에는 Linux와 LXC와 같은 운영 체제에서 여러 형태로 존재해 왔습니다. Docker는 LXC를 기반으로 빌드되었으며, 개발자가 하이퍼바이저 없이도 클라우드 인프라에서 애플리케이션을 빌드, 패키징, 배포할 수 있도록 "이지 버튼"을 추가했습니다.

Docker는 다음과 같은 특징으로 다른 컨테이너 기술과 차별화됩니다.

• 애플리케이션 간의 격리 및 네트워킹을 관리하기 위해 OS 위에 있는 가벼운 추상화 계층(Docker 엔진)입니다.
• Linux 기반 애플리케이션 배포를 보다 간편하게 만들어 주는 문서화된 애플리케이션 프로그래밍 인터페이스(API)입니다.
• 다른 사용자 및 개발자와 애플리케이션을 공유하기 위한 Docker 레지스트리.
• 물리적, 가상 또는 클라우드 호스팅 여부에 관계없이 Docker 지원 호스트 간의 애플리케이션 이동성.
• 모든 Docker 컨테이너에 공통 파일 시스템을 노출하는 유니언 파일 시스템입니다.
• Docker가 다양한 개발 작업 스타일에 잘 통합될 수 있도록 하는 부가가치 서비스와 소프트웨어를 제공하는 파트너 회사로 구성된 생태계입니다.

유니언 파일 시스템을 사용하면 기본 경로와 파일 이름이 기본 파일과 충돌하는 경우에도 각 컨테이너가 해당 컨테이너에 맞는 고유한 서비스를 제공할 수 있습니다. 예를 들어, 한 컨테이너에는 Python 라이브러리 버전 2.6이 필요한 반면, 다른 컨테이너에는 이후 버전이 필요할 수 있습니다. 기본 파일 시스템이 버전 2.6을 제공하는 경우 하나의 컨테이너가 충족됩니다. 그러나 이후 버전을 필요로 하는 컨테이너는 컨테이너 이미지의 일부로 이를 제공할 수 있습니다. 컨테이너 이미지는 실행하는 데 꼭 필요한 내용만 포함하므로 컨테이너 이미지의 풋프린트가 줄어듭니다.

그림 1의 다이어그램은 VM 및 Docker 애플리케이션 배포에 사용되는 구성 요소를 보여줍니다. 이 예에서 VM 접근 방식에는 두 개의 애플리케이션을 지원하기 위해 두 개의 게스트 운영 체제가 있다는 점에 유의하세요. 비교해 보면 Docker는 동일한 애플리케이션 밀도를 달성하는 데 호스트 OS가 하나만 필요하지만 당연히 오버헤드가 더 낮습니다.

다음 표는 VM과 Docker의 기능을 비교한 것입니다.

앞서 언급했듯이 Docker의 주요 목적은 애플리케이션 수명 주기 관리를 단순화하는 것입니다. 베어 메탈 기반 Docker가 매력적인 옵션이긴 하지만, 하이퍼바이저에서 Docker를 실행하는 데에도 이점이 있습니다. 여기에는 전체 게스트의 스냅샷을 찍고 라이브 마이그레이션을 허용하는 기능이 포함됩니다. 둘 다 비행 상태를 잃지 않고 재해 복구를 위한 핵심 요구 사항일 수 있습니다.

VMware vRealize Suite, OpenStack과 AWS, Azure와 같은 퍼블릭 클라우드와 같은 선도적인 인프라 관리 및 오케스트레이션 솔루션은 모두 특정 하이퍼바이저에서 Docker를 지원하지만 Docker 컨테이너에 공통적인 환경을 노출하여 환경에 관계없이 애플리케이션 이동성을 제공합니다. 이러한 유형의 이기종 배포 모델을 통해 고객은 Docker를 사용하여 기본 인프라를 변경하지 않고도 더욱 신속하게 반복 작업을 수행할 수 있는 이점을 얻을 수 있습니다.

호스트당 단일 VM과 OS로 전환하면 VM이 리소스를 놓고 경쟁할 필요가 없으므로 고객은 리소스 이점도 얻을 수 있습니다. 이러한 효율성의 향상은 하이퍼바이저가 더 이상 여러 운영 체제 사이를 중재할 필요가 없고 메모리와 로컬 디스크를 단일 OS에 할당할 수 있다는 사실에 기인합니다.

네트워킹을 사용하면 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) 개념을 사용하여 게스트를 유연하게 배포합니다. SDN을 사용하면 동일한 물리적 하드웨어에 있는 독립적인 테넌트에 대해 격리된 네트워크 터널을 구성할 수 있습니다. 그렇지 않으면 완전히 라우팅될 수 있는 클라우드 데이터 센터 내부에 터널링된 레이어 2를 제공하는 것도 유용할 수 있습니다. Docker 네트워킹은 Docker Bridge라는 개념을 중심으로 구축되었으며, 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 버전부터 SDN 개념을 통해 기본 Docker 네트워킹 기능을 확장하는 몇 가지 실험적 기능을 제공하기 시작했습니다. 플러그인 아키텍처는 F5 네트워크 및 애플리케이션 전송 서비스를 다양한 새로운 사용 사례에 삽입할 수 있는 흥미로운 기회를 제공합니다. 여기에는 애플리케이션에 유연한 컨테이너를 통한 차세대 방화벽, 컨테이너 흐름 분석 및 정책 시행, 흐름별 트래픽 관리가 포함됩니다.

F5는 가상화를 구현하기 위한 다양한 제품을 제공합니다. 업계에서 가장 광범위한 L4-L7 애플리케이션 전송 및 보안 서비스 포트폴리오를 갖춘 ADC 시장 리더인 F5는 모든 기술이 공통적인 기본 프레임워크를 공유하기 때문에 끊임없이 혁신적인 기술을 탐색하고 이러한 기술을 BIG-IP 플랫폼 전반으로 확장하고 있습니다. 그림 4는 L4-L7 서비스를 위한 맞춤형 하드웨어부터 완전한 클라우드 기반 서비스형 솔루션까지 F5가 제공하는 다양한 제품을 보여줍니다. BIG-IP 플랫폼은 Docker 컨테이너에서 실행되는 애플리케이션을 지원할 수 있는 좋은 위치에 있습니다.

위에서 언급했듯이 F5는 다양한 사용 사례에서 Docker의 이점을 인식하고 있습니다. 그러나 컨테이너화된 인프라에 대한 배포는 아직 초기 단계이며 서비스 검색(Consul, etcd, Mesos-DNS 등), 오케스트레이션, 컨테이너 서비스(Mesos, OpenStack, Kubernetes, Docker, Cloud Foundry 포함)의 수명 주기 관리를 위한 여러 옵션이 존재합니다. 네트워킹 서비스는 이 생태계의 중요한 측면이지만 원활한 배포를 보장하려면 오케스트레이션 환경과 긴밀하게 통합하는 것이 중요합니다. 이러한 통합은 컨테이너화된 인프라에서 마이크로서비스 기반 애플리케이션을 배포하는 사용자에게 L4-L7 서비스를 제공하고 투명하게 공개하는 데도 필수적입니다. F5 접근 방식은 베어 메탈, 가상화 또는 컨테이너화된 배포 전반에서 일관된 서비스 및 시각화 경험을 제공하는 데 중점을 두고 있습니다.

문제를 해결하는 첫 번째 단계는 남북(N-S) 트래픽(즉, "클라이언트 측 마이크로서비스"에 대한 트래픽)에 대한 네트워킹 서비스를 제공하는 것입니다. 대부분의 주요 오케스트레이션 플랫폼은 컨테이너화된 서비스에서 외부 세계로의 연결 배포, 확장 및 노출을 처리합니다. F5는 주요 컨테이너 오케스트레이션 플랫폼과의 긴밀한 통합을 가능하게 함으로써 N-S 마이크로서비스가 BIG-IP 시스템에서 자동으로 발견될 수 있도록 보장하고, 이를 통해 해당 서비스의 트래픽을 관리할 수 있습니다. 예를 들어, Mesosphere Marathon과 Kubernetes는 서비스에 "레이블"을 지정하는 옵션을 제공합니다. 이러한 라벨은 클라이언트 측 서비스(스핀업, 해체 또는 확장)를 검색하는 데 사용할 수 있으며 BIG-IP 시스템의 풀 멤버로 자동으로 추가될 수 있습니다.

위의 접근 방식을 BIG-IP 하드웨어 또는 가상 에디션(VE)에 사용하면 다음과 같은 하드웨어 가속을 통해 중요 기능을 중앙 집중화할 수 있습니다.

• 중앙 집중식 인증서 관리를 통한 SSL 오프로드.
• 압축, TCP 최적화, SPDY/HTTP2와 같은 가속화.
• DoS 보호 기능을 갖춘 정교한 방화벽.
• 애플리케이션 계층 공격을 막기 위한 애플리케이션 유창성.
• 모든 수신 및 발신 네트워크 연결에 대한 가시성.
• 지능형 로깅 및 이상 감지를 통해 디버깅이 크게 향상되었습니다.

F5 솔루션은 컨테이너화된 애플리케이션을 확장하는 기능은 물론 Docker 인프라와 외부 네트워크 간의 IPv4에서 IPv6로의 변환과 DNS 변환을 수행하는 기능을 제공합니다. 완벽하게 라우팅 가능한 Docker 컨테이너 인프라를 활용하려면 조직에서 효율적인 IPv4에서 IPv6로의 네트워크 기능뿐 아니라 DNS 요청 변환 지원도 필요합니다. Docker 컨테이너 인프라는 IPv6에서만 작동하고 IPv4에서 완전히 분리되며, 동시에 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 기능에 의해 변환됩니다.

긴밀한 통합을 구축하기 위한 다음 중요한 단계는 동서(E-W) 트래픽에 대한 서비스를 제공하는 것입니다. 즉, ADC 서비스가 필요한 마이크로 서비스 간의 데이터 전달입니다. 몇 초 이내에 서비스를 시작해야 하는 필요성과 마이크로서비스의 일시적인 특성을 고려하여 F5 접근 방식은 가벼운 ADC를 활성화하는 것입니다. (인증이나 L7, 애플리케이션 수준 보호와 같은 고급 서비스의 경우 트래픽은 N-S 에지의 BIG-IP 인스턴스로 리디렉션됩니다.)

마이크로서비스 아키텍처에서 컨테이너화된 서비스의 수는 기존 아키텍처보다 훨씬 많으며, 마이크로서비스 간에는 여러 가지 통신 경로가 있습니다. 이러한 아키텍처는 복잡성을 초래하여 성능 문제를 해결하기 어렵게 만드는 부작용이 있을 수 있습니다. 예를 들어, 애플리케이션의 성능이 저하되는 경우 N-S 에지에서부터 다양한 서비스 전반에 대한 종단 간 가시성을 확보하는 것이 중요합니다. 따라서 N-S 도메인의 BIG-IP 시스템과 E-W 도메인의 경량 ADC 간의 트래픽 패턴을 연관시킬 수 있는 중앙 집중식 시각화 접근 방식은 문제 해결에 매우 중요합니다.

F5 BIG-IP 솔루션 인스턴스를 애플리케이션 사이에 삽입하여 부하 분산이나 보안 서비스를 제공하고, E-W 트래픽의 보안 문제를 해결할 수도 있습니다. 예를 들어, Docker 호스트는 트래픽이 다른 컨테이너에 들어가기 전에 분석을 위해 BIG-IP 시스템을 통과하도록 한 컨테이너의 트래픽을 유도하도록 구성될 수 있습니다. 이 작업은 BIG-IP Application Security Manager™(ASM)를 사용하여 수행할 수 있는데, 이는 애플리케이션에 유연하게 대응하고 해당 컨테이너가 취약점 악용 등의 공격을 받고 있는지 감지할 수 있습니다.

오늘날 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의 성공을 보장하기 위한 견고한 로드맵 투자와 지속적인 제품 개선으로 뒷받침됩니다.