気づいていないかもしれませんが、コンテナは驚くべきスピードで勢いを増し続けています。 クラウドでさえ、このような熱心な導入を誇ることはできません。 コンテナを本番環境にデプロイするということは、すべてがコンテナに移行することを意味するわけではないことを覚えておくことが重要です。 少なくともまだだ。 多くの新興テクノロジーと同様に、企業は組織や環境に固有の問題を解決するために、アプリケーションごとに導入を開始します。
それでも、成長率は驚異的であり、近いうちに減速する可能性は低いでしょう。 使用頻度が増すほど、ベストプラクティスとアーキテクチャが進化し、移行されるアプリも増えます。 その点では、クラウド、クライアント サーバー、モバイルなど、他の多くのテクノロジやモデルに従います。 歩く前に這わなければならず、その後すぐに走れるようになります。
パブリック クラウド、プライベート クラウド、データ センター内の独自の環境など、あらゆる場所での実稼働環境への道を急速に進むコンテナ エコシステムの一員になれることを、私たちは嬉しく思っています。
今年の春に F5 Container Connector を最後にリリースしたとき、 Kubernetes のサポートを発表しました。 同時に、マイクロサービス ベースの API がコンテナ化されたアプリケーションのかなりの割合を占める傾向にあることを考えると、コンテナ環境ではイングレス制御がより緊急のニーズになりました。 ご存知のとおり、イングレス コントローラーは、API やその他のコンテナー化されたアプリに必要なアプリ ルーティング (レイヤー 7) を提供します。 BIG-IP などのほとんどのアプリ プロキシは、この機能を完璧に提供できますが (結局のところ、URI と HTTP ヘッダーに基づくルーティングについて話しているわけですが)、何かが欠けていました。 コンテナ エコシステムで適切に機能するには、コンポーネントがプロビジョニングと構成の宣言型モデルをサポートできる必要があります。 つまり、リソース ファイルを自動的に読み取り、それを実装する構成に変換します。
その良い例がKubernetesです。Kubernetes は、アノテーションを使用して、コンポーネントをコンテナ エコシステムに統合するために必要なメタデータを添付します。 Kubernetes へのイングレス制御を提供するために必要なことは、Container Connector が適切なイベントをサブスクライブできるようにし、提供された情報に基づいて適切なルーティングを実装する方法を BIG-IP に指示することだけでした。
私たちはそうしました。
しかし、Kubernetes は唯一の選択肢ではありません (ただし、Kubernetes はおそらく主要な選択肢の 1 つです)。多くのお客様が、プラットフォームとしてRed Hat OpenShift OriginまたはCloud Foundry を採用しています。 また、Container Connector の最新リリースでそれらをサポートできることを嬉しく思います。
F5 Container Connector は無料で、 Docker リポジトリからこれらの環境 (およびMarathonも) のいずれかまたはすべて用にダウンロードできます。 インストールや統合など、すべてのコンテナ統合に関する詳細情報は、こちらに記載されています。