Docker による動的ツール: 見落とされがちなベストプラクティス

[[252870]]

コンテナは、大企業から小企業まで、急速に一般的な導入ツールになりつつあります。 Docker は、さまざまなバージョンを簡単に展開するために開発者によって自然に使用されます。

コンテナを使用した展開は、確かに昔（ベアメタルと仮想マシン（VM）の世界）からの歓迎すべき移行でした。なぜなら、フットプリントが小さい（サイズと起動時間の両方）ため、組織にとって展開が以前よりも容易になったからです。リリース展開時間を短縮することは、実装後すぐに新機能が顧客に提供されることを保証するため、あらゆる組織が達成したい目標です。

残念ながら、VM から Docker イメージへのこの急速な移行により、めったに言及されないコンテナのもう 1 つの大きな利点、つまり、動的ツールの形で継続的インテグレーション (CI) プロセスでコンテナを使用する場合の開発者への運用上の利点が影に隠れてしまいました。これはコンテナの画期的な機能であり、デプロイメント アーティファクトよりも重要であると言えます。

CI/CD (継続的インテグレーション/継続的デプロイメント) プロセスでコンテナを使用する場合、「Docker の採用」は本番環境へのデプロイメントとほぼ同義ですが、必ずしもそうとは限りません。この記事では、Docker ベースのツールを活用することが、完全な Docker 導入プロセスにおいて重要かつ独立した部分である理由を説明します。

1. Dockerを使用して動的にノードを構築する

従来の CI 環境では、コンパイルを実行するすべてのコンピューターに、開発者が必要とする可能性のあるツールのスーパーセットが備わっています。各ノードには、会社が使用するバージョン、テスト、および構成ツールがプリインストールされています。

同じツールの複数のバージョンを持つことは大きな課題であり、さまざまなチームが複数のテクノロジーを使用する大規模な組織では、コンパイル ノードを維持するために必要な作業がすぐに手に負えなくなる可能性があります。

コンテナ（Docker 形式）の登場により、より直感的で簡素化された別のアプローチ、つまり動的ツールが登場しました。動的 Docker ツールを使用して、コンパイル ノードは Docker のインストールから始まります。

動的 Docker ベースのツールは、従来の静的ビルド ツールに慣れている開発者にとって、生まれ変わりのようなものです。

ビルド時には、Docker コンテナを使用して、現在のビルド ジョブに必要な特定のツールのみを起動します。コンパイルが完了すると、コンパイル ノードは元の状態 (つまり、ツールが完全に空の状態) に復元されます。

このアプローチはシンプルでありながら強力であり、開発者とオペレーターの両方に利点があり、次のセクションで詳しく説明します。

2. 静的コンパイルツールの暗黒時代 - 開発者の視点

完全な CD ではなく CI プロセスにのみ Docker を採用する方法を見てきましたが、次に Docker ベースのツールの利点について説明する必要があります。これを行う最も簡単な方法は、従来の静的コンパイル手法の欠点を説明することです。

静的ツール プラットフォームでは、コンパイル ノードは長時間実行され、コンパイル ツールの一部しかロードできません。これにより、開発者にとって多くの問題 (およびフラストレーション) が発生します。

新しいツールは、まず操作リクエストを通じてアップグレードする必要があり、その結果、アップグレード サイクルが非常に遅くなります。

開発者は、ビルド ノードで利用可能なものに基づいて独自のワークステーションを構成する必要があります。

新しいフレームワークとツールを使用してまったく新しいプロジェクトを作成するには、それに対応するためにすべてのコンパイル ノードをアップグレードする必要があるため、多大な労力が必要です。

開発者はコンパイル ノードの機能を追跡し、コンパイル ジョブが実際にすべての要件を満たすノードに送信されるようにする必要があります。

コンパイル ノードで同じツールの複数のバージョンを使用することは、常に大きな課題です。極端なケースでは、コンパイル ノードのバージョンがアップグレード/ダウングレードされたという理由だけで、開発者はプロジェクト ライブラリを変更せざるを得なくなります。

クラウドベースのアーキテクチャを採用すると、単一の組織が複数のプラットフォームに同時に展開できるようになり、そのすべてが外部で制御されるため、この問題はさらに悪化します。

開発者は、コンパイル プラットフォームが自分たちに影響を与えていると感じたため、最終結果に満足していませんでした。コンパイル ツールの使いやすさに関しては、開発者とオペレーターの間で常に緊張が存在します。

3. 開発者にとっての動的Dockerツールの利点

動的 Docker ツールを使用すると、開発者とオペレーター間のコミュニケーションが非常に簡単になります。コンパイル ノードには、Docker 自体という 1 つのハード要件のみがあります。

ビルド ノードに Docker がインストールされると、どの開発者もその特定のプロジェクトに必要な特定のツールを使用して Docker イメージを起動できるようになります。オペレーターは、新しいフレームワークやライブラリを採用する際の障壁ではなくなりました。

このアプローチの動的な性質は、Docker コンテナが一時的であるという事実から生まれます。それらは必要なときにのみ存在します。これは、ビルドノードにツールを事前にインストールするという従来の方法と比べて大きな違いです。

開発者が幸せになる（そして生産性が向上する）理由は次のとおりです。

• フレームワークの任意のバージョンを使用できます。

• 新しいアーキテクチャを使用する新しいプロジェクトを作成するのは非常に簡単です。

• すべてのビルド ノードは同一であるため、どのノードにもタスクを送信できます。また、ツールのバージョンが一致しないことをオペレーターが事前に知っている場合は、このようなことは実行されません。

• 同じツールの複数のバージョンを簡単に使用できます (同じプロジェクト内でも)。

• ライブラリのバージョンをアップグレードするように強制されることはありません。レガシー プロジェクトでは、グリーンフィールド プロジェクトとはまったく異なるバージョンのツールが使用される場合があります。

• ビルド ノードは「セルフクリーニング」なので、バージョン ツールの競合を心配する必要がありません。

• オペレータとのコミュニケーションが非常に簡単になります。議論される唯一のトピックは、ビルド ノード内の Docker デーモンのバージョンです。

動的 Docker ベースのツールは、従来の静的ビルド ツール アプローチの制約に慣れている開発者にとって、生まれ変わったような感覚をもたらす可能性があります。

次に、オペレーターが CI の動的インストルメンテーションからどのようなメリットを得られるかを見てみましょう。

4. 静的ビルドツールの暗黒時代 – オペレーターの視点

従来、オペレーター (つまり、システム管理者) は、静的ビルド ノードを管理するために多大な労力を費やす必要がありました。彼らの責任は、多数のツールを維持し、開発者がそれらを使用できるようにすることです。

このアプローチの複雑さは、特にさまざまなツールやテクノロジーを使用する組織では、すぐに摩擦を引き起こす可能性があります。

複数のビルド ツールとバージョンの複雑さに対処するために、オペレーターは通常、次の 2 つのアプローチのいずれかに従います。

• すべてのビルド ノードは同一であり、各ノードには開発者が作業しているプロジェクトに必要なビルド ツールが含まれています。

• ビルド ノードごとにビルド ツールのセットが異なります。ノードには、その機能を示す特別な「ラベル」が割り当てられます。

どちらのアプローチにも利点と欠点があります。ビルド サーバー内のすべてのノードがまったく同じである場合は、同じツールの複数のバージョンを処理するための特別なメカニズムが必要です。さらに、各ビルド ノードはすぐに過負荷になる可能性があります。一方、開発者はビルド用のノードを選択できるため、開発者の作業が楽になります。

異なるツールに異なるノードを使用すると、各ノードが同じツールで異なるバージョンを持つことができるため、ビルド ツールのバージョン競合が解決されます。ただし、この場合、オペレーターはどのツールがどのノードにインストールされているかを厳密に追跡し、新しいバージョンがリリースされたときにすべてのノードがアップグレードされるようにする必要があります。

開発者は、ビルド ジョブが正しいノードに送信されるようにする必要があるため、後者のアプローチにも注意する必要があります。たとえば、Python 開発者はジョブに「python」ラベルの付いたノードが必要であることを指定する必要がありますが、JavaScript 開発者は「javascript/npm」ラベルの付いたノードが必要であるなどです。

つまり、静的にノードを構築すると、オペレーターに膨大な時間がかかります。実際、ノード構築と保守にフルタイムの業務を割いている企業もあります。

5. オペレーターにとっての動的Dockerツールの利点

動的 Docker ツールを使用すると、操作が非常に簡単になります。

すべてのノードは簡単にセットアップおよび保守できます。特に、既存の Kubernetes クラスターをビルドに使用する場合は、すぐに一般的な方法になります。前述したように、各ビルド ノードには Docker のみがインストールされている必要があり、それ以外は何もインストールする必要はありません。他のノードはまったく同じです (定義により)。

この簡単なアプローチにより、オペレーターは事前にツールをインストールしなくても、承認済みツールのリストを維持できます。

• 開発者が使用するツールの正確なバージョンを気にしない。

• ツールのアップグレードの責任がなくなりました（開発者が自分でアップグレードできるため）。

• 同じツールの複数のバージョンによる問題はなくなります。

• 同種の機械で作業できる

• ノードのラベルを管理したり、どのノードにどのツールがあるかを追跡したりする必要はありません。

開発者とのコミュニケーションは非常に簡単で、話し合う必要があるのはノードの Docker バージョンだけです。

図に示されていないもう 1 つの利点は、Docker コンテナの速度とフットプリントから生まれます。従来の静的ビルド手法では、開発者がジョブのビルドを必要としない場合でも、オペレーターは常にビルド ノードを準備してジョブに使用できるようにしておく必要があります。

Docker ベースのツールを使用すると、開発者は数秒でオンデマンドでツールを起動できます。ノードを使用している開発者がいない場合は、そのノードをまったく異なるテクノロジーを使用している別の開発チームに簡単に再割り当てできます。

つまり、Docker ベースのツールはオペレーターの手を解放し、日々の負担を軽減することができます。

6. 完全に直交する2つのDockerアプローチ

この記事の焦点は、Docker 自体を実際に本番環境のデプロイメントに使用せずに、今日の実際の本番環境アプリケーションにおけるベスト プラクティスである Docker を使用した動的ビルド ツールを紹介することです。

Docker デプロイメント アーティファクトまたはビルド ツールのアプローチは完全に独立しており、組織に応じてこれらのツールを簡単かつ効果的に組み合わせることができます。

基本的に、企業内でのコンテナ導入には 4 つの段階があります。

• VM ベースのツール、VM 上にデプロイ (古いアプローチ)。

• コンテナ上にデプロイされる VM ベースのツール (ほとんどの人が使い慣れているアプローチ)。

• VM にデプロイできる Docker ベースのツール (コンテナーのメリットを享受する優れた方法)。

• コンテナにデプロイされた Docker ベースのツール (完全な Docker 採用)。

Docker 関連のニュースのほとんどは、Docker ベースのビルド ツールではなく Docker ベースのデプロイメントに焦点を当てているため、多くの組織が後者の利点に気づいていません。

上の図から、Docker ベースのツールはスタンドアロンで使用できることがわかります (デプロイメントでは引き続き VM/ベアメタルをターゲットにすることができます)。多くの組織は、これが唯一のアプローチではないことを理解せずに、盲目的に Docker を本番環境で使用しようとすることで、コンテナの流行に乗ろうとします。

実際、前のセクションで説明したように、Docker ベースのツールは開発者が直面する多くの一般的な生産性の問題を解決するため、CI/CD プロセスにさらに多くのメリットをもたらすことができます。

長時間のプロビジョニング承認を待つのではなく、オンデマンドでビルド環境を作成できる機能は、開発者や運用スタッフが頻繁に直面する問題点の 1 つです。

Codefresh では、このアプローチを CI/CD パイプラインに実装しました。各ステップは独自のコンテナーです。 Node を実行してみませんか?そのための Docker イメージがあります。 Maven を実行したいですか?そのための Docker イメージがあります。 Canary ロールアウトを実行しますか?それにはイメージがあります。必要ですか？ Terraform が必要ですか?基本的に、Docker イメージとして提供されるものはすべてビルド ステップとして使用できます。

Codefresh を使用して従来のターゲット (VM やベアメタルなど) にデプロイすることもできますが、ビルド プラットフォームの中核は、ツールを活用してコンテナーや Docker イメージを操作することです。

開発者は、必要なツールを含む Docker イメージのコンテキストで各ビルド ステップが実行されるパイプラインを作成できます。バージョンの競合、ツールのアップグレード、異なるバージョンでのノードの構築などの問題は過去のものになりました。

私たちは、動的 Docker ビルド ツールを開発者とオペレーターの業務を変革する新しい方法と捉えており、企業や組織内でさらに受け入れられることを期待しています。

翻訳者紹介:

Liu Zhihong、IT業界で17年の経験。 NTTデータ、オラクル、中国紙幣鋳造グループ、中国電信クラウドコンピューティング支社に勤務し、クラウドコンピューティングおよびその他の関連するIT研究開発業務に従事。 1 つのソフトウェア著作権を独立して所有しています。現在、電子業界の出版社に勤務。