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 つで十分です。 ただし、新しいバージョンを必要とするコンテナは、コンテナ イメージの一部としてこれを提供できます。 これにより、コンテナ イメージには実行に厳密に必要なものだけが含まれるようになるため、コンテナ イメージのフットプリントが小さくなります。

図 1 の図は、VM および Docker アプリケーションのデプロイメントで使用されるコンポーネントを示しています。 この例では、VM アプローチには 2 つのアプリケーションをサポートするために 2 つのゲスト オペレーティング システムがあることに注意してください。 比較すると、Docker では同じアプリケーション密度を実現するために 1 つのホスト 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 アドレスを使用して他の 2 つのコンテナとのみ通信できます。

Docker は IPv6 もサポートしており、完全にルーティング可能なアドレスの使用を許可します。 これにより、コンテナはアドレス マッピングを必要とせずに、異なるホスト上の他のコンテナと通信できるようになります。 ただし、これは IPv6 でのみ機能するため、一部の環境では適用範囲が制限される可能性があります。

多くのソフトウェア定義データセンターでは、ソフトウェア定義ネットワーク (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 を使用して、物理的に異なる 2 つのサブネットを分離および結合することがあります。

BIG-IP インスタンス上に VXLAN トンネル エンドポイント (VTEP) を作成することにより、BIG-IP ソリューションをテナント レベルでネットワークにシームレスに挿入できます。 その後、Docker および仮想マシン インスタンスへの接続を備えたテナント ネットワークの一部になります。

バージョン 1.7 以降、Docker は SDN コンセプトを使用して基本的な Docker ネットワーク機能を拡張するいくつかの実験的な機能を提供し始めました。 プラグイン アーキテクチャにより、アプリケーション対応コンテナを使用した次世代ファイアウォール、コンテナ フロー分析とポリシー適用、フローごとのトラフィック管理など、さまざまな新しいユース ケースに F5 ネットワークおよびアプリケーション配信サービスを挿入できる素晴らしい機会が提供されます。

F5 は仮想化を可能にするさまざまな製品を提供しています。 F5 は、業界で最も幅広い L4～L7 アプリケーション配信およびセキュリティ サービスのポートフォリオを備えた ADC 市場のリーダーとして、常に革新的なテクノロジーを探求し、共通の基盤フレームワークを共有する BIG-IP プラットフォーム全体にこれらのテクノロジーを拡張しています。 図 4 は、カスタム ハードウェアから L4-L7 サービス向けの完全なクラウドベースのサービスとしての製品まで、F5 の製品ラインナップを示しています。 BIG-IP プラットフォームは、Docker コンテナ上で実行されるアプリケーションをサポートするのに最適です。

前述のように、F5 はさまざまなユースケースにおける Docker の利点を認識しています。 ただし、コンテナ化されたインフラストラクチャへの展開はまだ初期段階であり、サービス検出 (Consul、etcd、Mesos-DNS など)、オーケストレーション、コンテナ サービスのライフサイクル管理 (Mesos、OpenStack、Kubernetes、Docker、Cloud Foundry など) には複数のオプションが存在します。 ネットワーク サービスはこのエコシステムの重要な側面ですが、シームレスな展開を保証するにはオーケストレーション環境との緊密な統合が重要です。 このような統合は、コンテナ化されたインフラストラクチャにマイクロサービスベースのアプリケーションを展開するユーザーが L4-L7 サービスを利用でき、透過的に利用できるようにするためにも不可欠です。 F5 のアプローチは、ベアメタル、仮想化、またはコンテナ化された展開全体にわたって、サービスと視覚化の一貫性のあるエクスペリエンスを提供することを目的としています。

問題を解決するための最初の部分は、North-South (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 コンテナ インフラストラクチャは、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 機能によって変換されます。

緊密な統合を実現するための次の重要なステップは、東西 (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 ビジョンの実現を実現するように設計されています。 F5 の Docker への取り組みは、堅実なロードマップへの投資と継続的な製品改善によって支えられており、ソフトウェア定義データセンターの主要な導入モデルの 1 つとなる Docker の成功を確実にします。