2019.05.28

「コンテナプラットフォーム」とは何か？何が必要で何をもたらしてくれるのか？ #docker #kubernetes #k8s

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

DockerConとDocker Enterprise 3.0というエンド・トゥ・エンドの開発からクラウドへのコンテナプラットフォームの発表の直後、私達が「完全なコンテナプラットフォーム」と言うときそれが何を意味しているかについての考えを共有したいと思います。

選択と柔軟性

完全なソリューションは、あらゆる種類のアプリケーションやユーザのニーズに応えなければいけません。すなわちクラウドネイティブなプロジェクトだけでなく、レガシーでブラウンフィールド(訳注:既に使用している)アプリケーションをLinuxとWindowsの両方で動かすことも含みます。高いレベルでは、組織がコンテナプラットフォームを採用する主な理由であるモダナイズの目標の一つは、技術的負債を取り除くことです。組織は「正しい」スタックに基いたアプリを作成し、「正しい」場所で実行する自由を欲しています。さらに、「正しい」とはアプリによって異なるのです。よって、これらのアプリケーションを実行するコンテナプラットフォームとは、アプリケーションを単一OSや仮想化・クラウドモデルに厳格に結び付けるよりも、これらのニーズを満たすために柔軟性がありオープンであるべきです。

高速なイノベーション

高速なイノベーションを開発者にもたらすことは、コンテナプラットフォームの主要な構成要素です。つまり、コンテナプラットフォームは開発者の環境まで広がっていきます。よって、開発者は本番環境で使うことになるものと同じAPIで開発・テストを行います。

あなたが選択したプラットフォームは、あなたの開発者が好むワークフローに統合する機能を持っているべきです。新しいさまざまな機能や、特定のデプロイパターンのみで動作する完全に新しいワークフローを強制することは避けましょう。開発者はコードによって問題を解決するクリエイティブな能力のために雇用されているのです。よって、採用するプラットフォームがある特定の手段でのみ動作する機能を強制し、チームの直感や以前の知識を無視することを強いるなら、イノベーションを遅滞させるだけでなく、開発者が仕事を終わらせるために承認されていないプロセスを行うリスクも増加させてしまいます。

運用チームも、アプリケーションのデプロイをより高速に行えるプラットフォームを実行することを欲しています。つまり、時間をかけてスキルを成長させることができながら、プラットフォームが期待通りの動作を行う保証があり、初日から複雑なタスクをより簡単にしたいということを意味しています。真のKubernetesエキスパートの数は比較的少ないので、もし初日からKubernetesの知識がある管理者と運用者を必要とするプラットフォームを選択したら、コンテナプラットフォームが「実際の」ワークロードを動かす準備ができる前に、コンテナプラットフォームの内外に関する学習に加えて、トレーニング、サービスのPoCのトライアンドエラーに12か月以上は容易にかかるでしょう。

なお、Kubernetesは信頼性のあるオーケストレータで、CNCFの卒業プロジェクトであるcontainerdで作成されているDocker Engineは信頼され広く用いられているコンテナランタイムです。コンテナプラットフォームはこれらの基本的なコンポーネントで構築すべきです。なぜなら、将来的に最も拡張性が高くなるからです。Docker Enterpriseと主要なパブリッククラウドは、オープンで成熟しているKubernetesとDocker Engine (まれにcontainerd)を使っています。コンテナプラットフォームのベンダーがKubernetesやDocker Engineと「ほとんど互換性がある」独自プロジェクトで構築していると言っている場合は、注意しないといけないかもしれません。

運用チームも安定性には関心を持っています。コンテナプラットフォームは頻繁にアップデートしますが、これは2年ごとにコンテナプラットフォームに加えて、これまで運用チームがプラットフォームに合わせて作り上げてきたすべてのスキル、スクリプト、他のツールなどを撤去して置き換えなければいけないというわけではありません。私達がDocker Enterprise 2.0にKubernetesを追加したとき、これはメジャーアップグレードでしたが、Docker Swarmの提供と開発が続けられるように同梱して、可能な限り簡単にアップグレードできるようにしました。コンテナプラットフォームを評価するときは、その歴史に注目しましょう。これは比較的新しい市場です。主な手順のすべてを強制的に移行するような主要なプラットフォームアーキテクチャの再設計が3回あったことを見つけたなら、将来的に不安定な状況に陥るかもしれません。

固有のセキュリティ

最後に、絶対ではありませんが、セキュリティはプラットフォームの全レイヤーに組み込まれていなければいけません。より頻繁でより高速なソフトウェアリリースの推進のために、セキュリティは開発者側と運用者側の両方の体験の一部でなければいけません。ただしセキュリティは、誰もそのプラットフォームを使いたくないと思うような、制限的・妨害的なものであってはいけません。開発者が既知のよく考えられた基礎から素早く開始できる手助けとなる補助を持っているべきです。後になって何かが壊れたと気がつくよりも、セキュリティプロセスでもシフトレフトを行っておきましょう。プラットフォームは出荷したすべてのアプリケーションに対して可視化機能があるべきです。WindowsかLinuxか、エッジコンピューティングかデータセンターかに囚われません。セキュリティはコンテナプラットフォームの基本的な構成要素です。そして実行するアプリケーション用のセキュリティも含んでいなければいけません。

まとめ

フォレスター・ニューウェイブ：2018年第4四半期におけるエンタープライズコンテナプラットフォームソフトウェアにおいて、Dockerが旗手と評価されたことを誇りに思います。Docker Enterprise 3.0は互換性を保ったままよりよい機能を追加しただけでなく、コンテナベースのアプリケーションの構築・共有・実行(build, share, run)用の唯一のエンド・トゥ・エンドプラットフォームです。開発者のデスクトップからクラウドに至るまで、特定のOSバージョン、仮想化プラットフォーム、パブリッククラウドスタックに基く依存関係を持たずにアプリケーション全体のライフサイクルのすべての段階を管理することができます。

もっと知りたい方は

原文: What’s in a Container Platform?