Cloud Foundry は先月、Kubernetes および BOSH (Kubo) プロジェクトを更新して Container Runtime (CFCR) に改名したことを発表し、このプロジェクトによりユーザーに幅広い「選択肢」が提供されると述べました。
CFCR は、6 月に Pivotal Software と Google によって Cloud Foundry Foundation に寄贈された Kubo を使用してコンテナをデプロイするための Cloud Foundry の推奨方法になりました。
しかし、Cloud Foundry FoundationのCTOであるチップ・チャイルダーズ氏によると、これは単にKuboの名称変更ではないという。「このプロジェクトは技術面で様々な形で進歩を続けており、新たな貢献者も迎え入れ、Kubernetesをエンタープライズグレードで提供するための明確な手段として前進しています」とチャイルダーズ氏は述べた。
これらの新しい貢献者たちは、CFCRに数多くの新機能リリースを追加するのに貢献してくれたと彼は付け加えた。変更点には、様々なIaaSプロバイダー向けの永続ボリュームのサポート、Istioサービスメッシュプロジェクトとの互換性テスト、クラスターの自己修復、Kubernetesバージョンの1.8.1へのアップデート、そしてBOSH DNSおよびCredHubプロジェクトのデプロイ環境への統合などが含まれる。
しかしチルダーズ氏は、新サービスの普及を後押ししたのは技術的な変化だけではないと述べた。最大の変化は、Cloud Foundryコミュニティからのサポートの強化だった。
心の交流
彼は、新しい名称は単なる見た目の変更ではなく、その重要性を示すものだと述べました。「現在、Cloud Foundry Application Runtimeは会員基盤の40%以上、そしてFortune 500企業の半数以上が利用しています。Container Runtimeを同等にすることで、Application Runtimeと組み合わせることで、Kubernetesが企業に浸透する速度が向上します。」
目標は、Google が開発し Cloud Native Computing Foundation (CNCF) が管理する Kubernetes を使用したクラスタを、オンプレミスでもパブリックでも確実にデプロイできるようにすることです。CFCR を使用して、Kubernetes または Foundry のアプリケーション ランタイムをデプロイできるようになりました。
BOSHは2010年に初めてリリースされたオープンソースのDevOpsツールで、元々はVMwareが開発し、現在はCloud Foundryで提供されています。仮想ワークロードのデプロイ、制御、管理に使用できるため、重要なツールです。特に、Kubernetesに欠けている監視機能の提供に優れています。
コンテナランタイム...仕組み [出典: Cloud Foundry Foundation]
では、なぜ私たちは突然この選択という概念に興味を持つようになったのでしょうか？なぜCloud Foundryは別のグループのコアテクノロジーを使っているのでしょうか？普及率を見てください。
業界ではコンテナが話題になっているものの、財団の調査によると、コンテナが本番環境に導入されている企業はわずか 25% 程度で、昨年のわずか 3% から増加しています。
一方、組織は技術的な変化、つまりあえて言えば「デジタル化」の過程にあります。
チルダーズ氏はThe Regに次のように語った。「膨大な数の顧客は、この変革プロセスを進めている大企業であり、SUSEが自社製品をリリースし、SAPクラウドプラットフォームが市場に投入されるにつれて、その数はさらに増えるだろう。」
これは、パブリック クラウドという一般に受け入れられている概念の外側でもコンテナ テクノロジを使いやすくすることで、コンテナ テクノロジの普及を促進することを目的としています。
同団体は、さらなる導入に対する障壁を取り除きたいと考えている。
「これは単なるコンテナの問題ではありません。根本的な考え方の転換です」とチルダーズ氏は述べた。「組織を一つの有機体として捉えれば、その全体像を変える必要はないのです。」
作れば、彼らは来る
チルダーズ氏によると、焦点は「プラットフォームを作成できる一連のツールを作成することではなく、実際のプラットフォームを作成すること」にあります。
では、CFCR は具体的にどのようにして真の選択肢を提供するのでしょうか? 独立系ソフトウェアベンダー (ISV) をターゲットとします。
「コンテナをデプロイし、Kubernetesコミュニティが構築した抽象化の一部を利用したいケースが数多くあることは承知しています。私が目にしたユースケースの中には、ソフトウェアをOCIイメージやDockerイメージとして配布したいISVも含まれています」とチルダーズ氏は述べた。
これらは、Cloud Foundry 内にデプロイされるシステムとは異なるタイプのシステムです。これらのテクノロジーは、コンテナとしてパッケージ化されて出荷され、アプリケーションの全体的なアーキテクチャに組み込むのが最適な場合が多いのです。
「私たちが進化していると考えている開発者エクスペリエンスとは、これら 2 つの抽象化タイプ間で統合された ID を持ち、うまく連携して動作し、カスタム コードから使用したい多くのバックエンド サービスと連携できるように Kubernetes をホストできるエクスペリエンスです。」
実際には、古いモノリシックアプリケーションをLinuxコンテナとしてラップしたい場合を考えてみましょう。アプリケーションランタイムでは問題なく動作するかもしれませんが、その特性によってはうまく動作しないこともあります。「アプリケーションランタイムの12要素すべてに従う必要はありません。多くのアプリがこれらの12要素を満たしていないことは承知しています。そのため、同じ環境にデプロイするために、コンテナでラップしてからコンテナランタイムにデプロイするという判断をすることもあります。ユーザーに選択肢を与えているのです」とチルダーズ氏は述べています。
Cloud Foundry Foundationは、コンテナをよりアクセスしやすく、より管理しやすいものにする必要があると認識しています。CNCFとの連携には希望があるようです。®
