（この記事は、CloudBees社 Blog 「Containers and Software Delivery: Packaging Up Innovation」2017年4月28日 Kohsuke Kawaguchiの翻訳記事です。）
今回はCloudBees社CTOの川口耕介さんの記事の翻訳をご紹介します。
これまでも、IT業界は何度も革新の波に洗われました。これまでの革新は、インフラストラクチャ（メインフレームから仮想ディストリビューションへ）、アプリケーション・アーキテクチャ（モノリシックなクライアント・サーバーからn層ウェブへ）、プロセス/方法論の分野で別々に行われるのが当たり前でした。しかしよく周りを見れば、私たちは今、個別の分野の新しい波ではなく、同時に複数の領域を横断する劇的な変化の真っ只中にいることがわかります。インフラストラクチャの領域は、軽量コンテナ技術（現時点での代表格はDockerです）によって完全に覆されようとしています。アプリケーションアーキテクチャが分散型マイクロサービスモデルに移行し、付加価値の高いビジネスロジックを迅速に追加または変更できるようになり、エンドユーザーに役立つようになりました。さらに、我々がソフトウェアを提供する方法は、数年前には考えられなかった「運用環境でのA/Bテスト」や「機能フラグ」などの技術が重視されるとともに、急速に変化しています。本当に興味深いのは、これらの3つの波が相互に作用し、ITにおける究極の効果、つまりビジネス/消費者/ユーザーにさらに大きな価値を提供できる能力を高めていることです。
コンテナと継続的デリバリー（CD）が一緒になって、マイクロサービスベースのアプリケーションで起こり得る革新を加速しています。このような IT革命とプロセスの根本的な変化は、互いに影響し合って、全体としては、それぞれを合わせたよりも大きな影響を私たちに与える可能性があります。コンテナとCDの組み合わせは、過去5年ほどの間にわれわれがコンシューマーアプリケーションやモバイルアプリケーションで見てきたのと同様の、革新の指数関数的な成長をエンタープライズITで見せてくれます。
Docker現象に関する最も興味深い点の1つは、Dockerによって抽象度をアプリケーションバイナリからコンテナレベルに変更することで、開発チームと運用チームの連携がより促進されるだろということです。
一面的な見方では、Dockerは、これまでアプリケーションがRPMやその他のメカニズムにパッケージングされたのと同じように、単に改良されたパッケージ化の方法の一つというだけにすぎません。もしパッケージングメカニズムとしてのDockerだけに焦点を当てた場合、この影響はアプリケーションをどのように運用環境にプッシュするかというソフトウェア開発の最後段階に限定されると考えてしまうかもしれません。しかし、Dockerはアプリケーションのパッケージ化、保守、テスト、ステージング、およびデプロイの方法を根本的に改善するものです。これにより、アプリケーションの実行環境は、CDパイプラインの最後の方で出来上がってIT 運用チームに託されるものなどではなくなります。それどころか、ランタイム環境は、最初からアプリケーションソースコードに密接に関連しています。すべてのCDパイプラインの開始時に、コードリポジトリだけでなくバイナリリポジトリがあり、必要なさまざまな環境（オペレーティングシステム、アプリケーションサーバー、データベース、ロード バランサーなど）に対応するためにIT 運用チームが認可した多数のDockerイメージが用意されているでしょう。
Dockerは、アプリケーションとアプリケーションの環境またはインフラストラクチャ構成の両方をカプセル化するため、いくつかの重要な利点があります。
- まず、Dockerを使用すると、デプロイ対象そのものをテストすることが容易になります。 開発者は、アプリケーションを組み込んだDockerコンテナを提供します。 IT運用チームは、これらのコンテナをデプロイします。受け渡しまたは再アセンブルの過程で失敗する可能性は減少または排除されます。Dockerコンテナは、継続的デリバリーの中心的な教訓を奨励します―つまり、パイプラインの各ステップで同じバイナリを再利用し、ビルドプロセス自体にエラーが導入されないようにします。
- 第2に、Dockerコンテナは不変インフラストラクチャの基礎を提供します。コンテナでは他に影響を与えることなく簡単にアプリケーションの追加、削除、クローン、および/またはその構成要素の変更を行うことができます。デプロイの失敗がどんな被害を引き起こしたとしても、影響範囲はコンテナ内に制限されます。削除と追加が非常に簡単になり、実行中のアプリケーションの状態をどのように更新するかについて考えないで済むようになります。さらに、インフラストラクチャ上で動作するアプリケーションとは無関係に、インフラストラクチャの変更が発生する場合 （必ず変更は発生するものです）――従来、アプリケーションとインフラストラクチャは、それぞれ開発と運用の担当であり、この間には一線がありました――問題は避けられません。この場合も、コンテナの抽象化は、問題の発生するリスクを低減または排除します。これは、企業が従来の仮想化からプライベートまたはパブリッククラウドインフラストラクチャに移行する際に特に重要になります。Dockerの使用によってもたらされるこれらの利点のどれも、見かけは華々しくありません。依然として、ソフトウェアとインフラストラクチャは、作成し、他のソフトウェアと統合し、構成し、更新し、および管理する必要があります。ただ、Dockerはこれらを行うより良い手段を提供します。
- 第3に、環境自体の更新が大幅に形式化され、単純化されます。 典型的なソフトウェアデリバリープロセスでは、新しいCDパイプラインの主なトリガーは、アプリケーションのソースコードの変更です。これにより、様々なテスト、統合、承認などが開始され、これらはまとめてソフトウェアパイプラインを構成します。しかし、オペレーティングシステムのパッチを当てるなど、環境自体を更新する場合は、アプリケーションビルドプロセスとは別に実行されるため、パイプラインが再度実行されたときにはじめて、更新された環境が使用されます。場合によってはパイプライン実行の途中で環境の変更が発生し、結果としてアプリケーションは新しい環境ですべてのテストを通過しない可能性もあります。Dockerを使用すると、コード変更によってCDパイプラインの実行が開始されるだけでなく、新しいDockerベースイメージ（オペレーティングシステムなど）をアップロードしたときも、このイメージを利用しているCDパイプラインの実行のトリガーとすることができます。複数のDockerイメージが相互に依存している場合もありますが、その場合、オペレーティングシステムにパッチを適用するとデータベースとアプリケーションサーバーのイメージが自動的に更新され、それらのデータベース/アプリケーションサーバーイメージを使用するパイプラインの実行が開始されます。CDパイプラインは、もはや開発者とそのソースコードだけのものではありません。開発者とIT運用チームは、すべての変更に対して同じパイプラインを共有するようになりました。これにより、IT組織の安全性とセキュリティが大幅に向上する可能性があります。たとえば、Heartbleedバグなどの重要かつ広く存在するセキュリティ上の問題に直面した場合、IT 運用チームは、すべてのマシンにパッチが当てられていることを確認するのに苦労するケースが多々あります。サーバーの漏れがないことをどうやって確認すればよいでしょうか？DockerベースのCDパイプラインでは、CDパイプラインの一部として明示的/宣言的に環境依存関係が記述されています。
アプリケーションがDockerとは何の関係もなく、それ自体がDockerイメージとしてデリバリーされない場合でも、コンテナ内で構築およびテストを行うことには利点があります。テストを実行する際も、実際にはセルに閉じ込められているという事実を意識することなく、コンピュータ全体を占有しているかのように動作します。Dockerイメージは、効率的に作成でき、1日に100回でも廃棄できる一過性の実行エンティティになります。各ジョブは、並行して実行されるビルドからは参照もアクセスもできない完全な仮想化環境で実行され、ビルドの最後に利用した環境を破棄できます（または、必要であれば、後のビルドで再利用できます）。
コンテナ内でビルドとテストを行うことのもう1つの利点は、ビルド環境を管理し、きれいに保つという、面倒でもIT環境の円滑な運用には必須のタスクをIT運用者が担当する必要がなくなることです。IT運用チームは汎用的な通常環境を提供する一方で、開発者とDevOpsチームはカスタマイズされたイメージを構築して維持することができます。Dockerイメージへの移行は、お手軽で混乱はほとんどありませんが、多くの利点をもたらします。
Dockerベースのアプリケーションの経験が増えるにつれて、業界はマイクロコンテナベースのアーキテクチャ内で単一のコンテナがアプリケーションまたはサービスを提供する場所に急速に進化します。このマイクロサービスの世界では、Docker Swarm + Compose、Mesos、Kubernetesのような統括的な管理ツールは、Dockerコンテナを部品として使用し、複雑なアプリケーションをデリバリーします。このような洗練されたレベルに進展するにつれて、コンテナのセットを構築、テスト、出荷する必要性は喫緊のものになります。
川口耕介
CloudBees
最高技術責任者