Docker は従来のアプリケーションリリース管理の終焉をもたらすのでしょうか?

Docker を使用すると、従来のアプリケーション リリース管理で発生する問題が本当に改善されるのでしょうか?

2013 年のリリース以来、Docker はあらゆる運用管理者にとって新しい存在となっています。もしあなたが世界から自分を遮断していたら、まさにこれがあなたが失っていたものなのです。

Docker は、オペレーティング環境のアドレス空間内でのパーティション分割機能です。パーティションがホスト オペレーティング システムを直接使用できるようにすることで、オペレーティング システムがパーティションの外部にある場合でも (ここではパーティションをコンテナーと呼びます)、起動時間が短縮され、コンテナーの管理に必要なリソースも削減されます (z/OS に精通している場合は、この概念はおなじみです)。

財務担当者は、オペレーティング環境のライセンスを取得するコストを大幅に削減でき、理論的には、アプリケーションの一部ではないすべてのコンポーネントをコンテナーの外部に配置できるため、これを気に入るでしょう。つまり、仮想マシンごとに 1 つではなく、Windows ライセンスを 1 つだけ購入すれば済みます (Docker を使用しない場合は、このプロセスは必須です)。

コンセプトはシンプルに見えますが、どのように機能するのでしょうか?

基本的に、特別なファイル (Dockerfile と呼ばれる) には、コンテナを作成する方法に関する 1 つ以上の指示が含まれています。この Docker ファイルは、プログラムの一部として、単一のアプリケーションと関連するバイナリ コードを含むコンテナーをファイル システムに作成します。このコンテナー (ファイル システム内のサブディレクトリ) は、任意のファイルのコレクションとしてターゲット環境に配布され、コマンド ライン インターフェイスまたは API (通常は REST ベースですが、他の実装もあります) を介してアクセスできる Docker ランタイム ライブラリを使用してターゲット環境で実行を開始します。

コンテナは簡単にデプロイ (XCOPY コマンドを使用) でき、保守も簡単 (REST インターフェイスは最新のインフラストラクチャ管理プラットフォームに簡単に統合可能) なので、システム管理者はこれを気に入るはずです。

エンタープライズレベルのリリース自動化ソリューションの必要性

残念ながら、これを真のアプリケーション リリース管理の代わりとして使用しようとすると、この概念は機能しなくなります。アプリケーション リリース管理は、高校で習う 6 つの単語のうち 5 つを使って説明することもできます。

• 対象者: 組織内の全員が環境にアプリケーションを展開できるわけではありません。実際、この仕事をフルタイムで行っている人でも、それを展開するには他の人の許可が必要です。
• 内容: アジャイルビジネスコンセプトを真に導入したい組織にとって、

毎回完全なアプリケーションをデプロイすることも受け入れられません。リスクが低いと見なされるアーティファクト (コンテンツの更新など) はすぐに展開できますが、リスクが高いアーティファクトは、徹底的なテストやその他の検証作業を行った後にリリースするためにキューに入れる必要があります。 Docker は後者に属しますが、いくつか制限があり、それについては後で説明します。

• 場所: アプリケーションが開発から本番環境に移行する環境は、デプロイ先のターゲット環境とは異なることがよくあります。これらの違いは、アプリケーションのデプロイ後にアプリケーション構成を変更することで解決されます。
• 時期: リリース ウィンドウは新しい概念ではありません。非本番環境の場合でも、同じ機能または異なる機能に取り組んでいる複数のチームによって環境が共有されることが多いため (たとえば、テストと開発で同じ環境が使用される場合)、独自のリリース ウィンドウを確立する必要があります。
• 方法: アプリケーションの展開プロセスは、組織の運用機能に完全に統合するのがおそらく最も難しい部分であり、単にインストール方法や構成方法を理解する以上の作業が必要です。たとえば、IT サービス管理 (ITSM) アプリケーションと統合して、必要な変更がすべて入力され、正しい状態になっていることを確認すると、これらが展開プロセスに吸収され、運用環境の状態が常に明確に把握されます。これについては以下で詳しく説明します。

Docker は上記の 5 つの質問のうち 1 つしか解決せず、最も効果的な方法を使用していません。有名なヨーロッパの銀行を例に挙げてみましょう。現在では毎月1000点以上の製品をリリースしています。これは、リリースされるすべての製品が高リスクでない場合にのみ達成できます。この例では、これらのアーティファクトはすべて低リスク タイプであることを意味します。したがって、これらのタイプの成果物のリリースは迅速に行うことができ、銀行の顧客が必要な資産を確実に保有できるようになります。

ただし、Docker を使用している場合は、これらのタイプの成果物が本番環境で承認されているかどうかに関係なく、アプリケーション全体を再構築する必要があります。ほとんどの企業にとって、ライセンスのないバイナリを直接本番環境に出荷するリスクは受け入れられません。これは上記の 5 つの項目のうちの 1 つにすぎません。Docker では他の 4 つを解決することはできません。

アプリケーションリリース管理は単なるアプリケーション管理にとどまりません

アプリケーション リリース管理をアプリケーションの観点からのみ考え、ビジネスの観点からはアプリケーションが全体像の一部であることを忘れてしまうのは興味深いことです。上記の「方法」セクションでは ITSM について説明しましたが、リリース プロセスに統合する必要があるテクノロジは ITSM だけではありません。実際、特定のニーズに合わせて選択できるさまざまなソリューションを備えた SDLC ツール チェーンがあります。継続的インテグレーションには Hudson と Jenkins があります。ソースコード管理用の Git と Subversion。アーティファクト管理用の Nexus および Artifactory。構成管理用の Chef と Puppet など。

さらに、アプリケーションのライフサイクル中に、アプリケーションをリリースするプロセスには通常、そのプロセスのガバナンスが含まれますが、これはプロセスの一部ではありません。ただし、アプリケーション構築のこれらの段階は、高頻度でのリリースのリスクを最小限に抑えるために必要であり、これにはライセンス、検証、およびその他の種類のアクティビティが含まれます。

自動化はすべての鍵

これまで述べたことはすべてアプリのリリースにとって重要ですが、その原因は何でしょうか?エンドユーザーには新しい機能が必要です。アプリケーション開発チームが新しい機能を開発し、最終的にそれをエンドユーザーに提供する速度によって、新しい機能がどれだけ早く追加収益につながるかが決まります。

さらに、プロセスの再現性により、アプリケーション リリースの成功率が高まります。逆に、導入に失敗すると会社にコストがかかり、診断と修正が行われている間に開発されるアプリケーションの数は減少します。過去 3 年間にアナリスト企業が実施した 2 つの調査によると、Fortune 1000 企業の場合、変更、構成、またはその他のアプリケーション関連の問題によるアプリケーションのダウンタイムのコストは 1 時間あたり 20 万ドルから 40 万ドルです。

上記のセクションの各ツールは、アプリケーションの開発および展開プロセスのごく一部にのみ関連しています。同様に、Docker はアプリケーションのリリースに関連する成果物の管理を解決し、それらの成果物の展開を簡素化します。他のソリューションとのこれらの調整機能は、統合ソリューションを通じて管理する必要があり、これがアプリケーション リリース自動化の目標です。

要約する

全体として、Docker は、アプリケーション リリース ライフサイクル全体に存在する単なる別のメカニズムとして捉えるべき、魅力的なテクノロジーです。しかし、それは「何を」だけでなく「誰が」「どこで」「いつ」「どのように」をも含む明確に定義された方法論の代わりとして考えるべきではありません。

エンタープライズ レベルの自動化ソリューションに投資してミッション クリティカルなアプリケーションのリリースを自動化すると、アプリケーションの展開速度が向上するだけでなく、企業のデジタル変革の度合いも向上します。自動化によってアプリケーションのリリースが完了するにつれて、企業にさらに多くの利益がもたらされます。