コンテナ101:Dockerの基礎

Dockerは、単一アプリケーションのLinuxコンテナーを構築するために、元々dotcloudという名前のオープンソースプロジェクトとして2012年に開始されました。それ以来、Dockerは非常に人気のある開発ツールになり、ランタイム環境としてますます使用されるようになりました。Dockerほど早く開発者に受け入れられたテクノロジーはほとんどありません。

Dockerが非常に人気がある理由の1つは、「一度開発すれば、どこでも実行できる」という約束を実現できることです。Dockerは、アプリケーションとそのランタイム依存関係を単一のコンテナーにパッケージ化する簡単な方法を提供します。また、コンテナをLinuxカーネルのさまざまなバージョンで実行できるようにするランタイム抽象化も提供します。

開発者はDockerを使用して、自分のワークステーションでコンテナー化されたアプリケーションを作成し、コンテナーをDocker対応サーバーに簡単にデプロイできます。クラウド内であろうとオンプレミス内であろうと、サーバー環境用にコンテナーを再テストまたは再調整する必要はありません。

さらに、Dockerは、開発者と運用チームがコンテナーのコンテンツを簡単に共有および再利用できるようにするソフトウェア共有および配布メカニズムを提供します。この配布メカニズムは、マシン間の移植性と相まって、運用チームや開発者の間でのDockerの人気を説明するのに役立ちます。  

Dockerコンポーネント

Dockerは、開発ツールであると同時にランタイム環境でもあります。Dockerを理解するには、まずDockerコンテナーイメージの概念を理解する必要があります。コンテナは常にイメージで始まり、そのイメージのインスタンス化と見なされます。イメージは、コンテナー内のアプリケーションコードや実行時の構成設定など、実行時にコンテナーがどのようになるかを静的に指定したものです。Dockerイメージには読み取り専用レイヤーが含まれています。つまり、イメージが作成されると、変更されることはありません。

図1に、コンテナーイメージの例を示します。このイメージは、ApacheがインストールされたUbuntuイメージを示しています。このイメージは、3つの基本Ubuntuレイヤーと更新レイヤーで構成されており、その上にApacheレイヤーとカスタムファイルレイヤーがあります。

実行中のDockerコンテナーは、イメージのインスタンス化です。同じイメージから派生したコンテナは、アプリケーションコードと実行時の依存関係の点で互いに同一です。ただし、読み取り専用のイメージとは異なり、実行中のコンテナーには、読み取り専用コンテンツの上に書き込み可能なレイヤー(コンテナーレイヤー)が含まれます。データとファイルへの書き込みと更新を含むランタイムの変更は、コンテナーレイヤーに保存されます。したがって、同じ基になるイメージを共有する複数の同時実行コンテナーには、大幅に異なるコンテナーレイヤーが含まれる場合があります。

実行中のコンテナーが削除されると、書き込み可能なコンテナーレイヤーも削除され、保持されなくなります。変更を永続化する唯一の方法はdocker commit、コンテナを削除する前に明示的なコマンドを実行することです。を実行するdocker commitと、書き込み可能なレイヤーを含む実行中のコンテナーコンテンツが新しいコンテナーイメージに書き込まれ、ディスクに保存されます。これは、コンテナがインスタンス化されたイメージとは異なる新しいイメージになります。

この明示的なdocker commitコマンドを使用すると、それぞれが前のイメージの上に構築された、連続した個別のDockerイメージのセットを作成できます。さらに、Dockerはコピーオンライト戦略を使用して、同じ基本コンポーネントを共有するコンテナーとイメージのストレージフットプリントを最小限に抑えます。これにより、ストレージスペースが最適化され、コンテナの開始時間が最小限に抑えられます。

図2は、イメージと実行中のコンテナーの違いを示しています。実行中の各コンテナーは、異なる書き込み可能なレイヤーを持つことができることに注意してください。

イメージの概念を超えて、Dockerには従来のLinuxコンテナーのものとは異なるいくつかの特定のコンポーネントがあります。

  • Dockerデーモン。Docker Engineとも呼ばれるDockerデーモンは、コンテナーとLinuxカーネルの間の薄い層です。Dockerデーモンは、アプリケーションコンテナを管理する永続的なランタイム環境です。すべてのDockerコンテナは、基盤となるオペレーティングシステムに関係なく、Dockerデーモンが有効になっているすべてのサーバーで実行できます。
  • Dockerfile。開発者はDockerfilesを使用してコンテナイメージを構築し、それがコンテナの実行の基礎になります。Dockerfileは、コンテナイメージをアセンブルするために必要なすべての構成情報とコマンドを含むテキストドキュメントです。Dockerfileを使用すると、Dockerデーモンはコンテナイメージを自動的に構築できます。このプロセスにより、コンテナ作成の手順が大幅に簡素化されます。

具体的には、Dockerfileで、最初にビルドプロセスを開始するベースイメージを指定します。次に、一連のコマンドを指定します。その後、新しいコンテナイメージを作成できます。

  • Dockerコマンドラインインターフェースツール。Dockerは、イメージベースのコンテナーのライフサイクルを管理するための一連のCLIコマンドを提供します。Dockerコマンドは、ビルド、エクスポート、タグ付けなどの開発機能だけでなく、コンテナーの実行、削除、開始、停止などのランタイム機能にも及びます。

特定のDockerデーモンまたはレジストリに対してDockerコマンドを実行できます。たとえば、docker -psコマンドを実行すると、Dockerはデーモンで実行されているコンテナのリストを返します。

Dockerによるコンテンツ配信

Dockerは、ランタイム環境とコンテナー形式に加えて、コンテナーコンテンツの検出と配布を容易にする、一般にレジストリと呼ばれるソフトウェア配布メカニズムを提供します。

レジストリの概念は、コンテナコンテンツをパック、出荷、保存、検出、および再利用するための一連のユーティリティを提供するため、Dockerの成功にとって重要です。同社のDockerは、DockerHubと呼ばれる無料のパブリックレジストリを実行しています。

  • レジストリ。Dockerレジストリは、コンテナイメージが公開および保存される場所です。レジストリは、リモートまたはオンプレミスにすることができます。パブリックにすることもできるので、組織またはユーザーのセットに限定して、誰でも使用することもプライベートにすることもできます。Dockerレジストリには、ユーザーがコンテナイメージを構築、公開、検索、ダウンロード、管理できるようにする一連の一般的なAPIが付属しています。
  • Dockerハブ。Docker Hubは、Dockerによって管理されるパブリックなクラウドベースのコンテナレジストリです。Docker Hubは、イメージの検出、配布、およびコラボレーションワークフローのサポートを提供します。さらに、Docker Hubには、Dockerによって認定された一連の公式イメージがあります。これらは、Canonical、Red Hat、MongoDBなどの既知のソフトウェア発行元からの画像です。これらの公式画像を、独自の画像またはアプリケーションを構築するための基礎として使用できます。

図3は、ユーザーがイメージを作成してレジストリにアップロードするワークフローを示しています。他のユーザーは、レジストリからイメージをプルして本番コンテナーを作成し、どこにいてもDockerホストにデプロイできます。

Dockerコンテナの不変性

Dockerコンテナの最も興味深いプロパティの1つは、コンテナの不変性とその結果としてのステートレス性です。

前のセクションで説明したように、Dockerイメージは、一度作成されると変更されません。イメージから派生した実行中のコンテナーには、実行時の変更を一時的に保存できる書き込み可能なレイヤーがあります。で削除する前にコンテナがコミットされている場合、docker commit書き込み可能なレイヤーでの変更は、前のイメージとは異なる新しいイメージに保存されます。

なぜ不変性が良いのですか?不変のイメージとコンテナーは不変のインフラストラクチャにつながり、不変のインフラストラクチャには、従来のシステムでは達成できない多くの興味深い利点があります。これらの利点は次のとおりです。

  • バージョン管理。Dockerは、新しいイメージを生成する明示的なコミットを要求することにより、バージョン管理を強制します。画像の連続するバージョンを追跡できます。前のイメージは保持され、変更されないため、前のイメージ(したがって前のシステムコンポーネント)にロールバックすることは完全に可能です。
  • よりクリーンな更新とより管理しやすい状態変更。不変のインフラストラクチャを使用すると、サーバーインフラストラクチャをアップグレードする必要がなくなります。つまり、構成ファイルを変更したり、ソフトウェアを更新したり、オペレーティングシステムをアップグレードしたりする必要がありません。変更が必要な場合は、新しいコンテナを作成し、それらを押し出して古いコンテナを置き換えるだけです。これは、状態を変更するためのはるかに離散的で管理しやすい方法です。
  • ドリフトを最小限に抑えます。ドリフトを回避するために、システム内のすべてのコンポーネントを定期的かつプロアクティブに更新して、それらが最新バージョンであることを確認できます。この方法は、従来のかさばるソフトウェアよりも、システムの小さなコンポーネントをカプセル化するコンテナの方がはるかに簡単です。

Dockerの違い

Dockerのイメージ形式、コンテナー管理用の広範なAPI、革新的なソフトウェア配布メカニズムにより、Dockerは開発チームと運用チームの両方に人気のあるプラットフォームになっています。Dockerは、これらの注目すべき利点を組織にもたらします。

  • 最小限の宣言型システム。Dockerコンテナーは、小さな単一目的のアプリケーションである場合に最適です。これにより、最小サイズのコンテナーが作成され、迅速なデリバリー、継続的インテグレーション、および継続的デプロイメントがサポートされます。
  • 予測可能な操作。システム運用の最大の頭痛の種は、常にインフラストラクチャまたはアプリケーションの一見ランダムな動作でした。Dockerは、より小さく、より管理しやすい更新を強制し、システムドリフトを最小限に抑えるメカニズムを提供することで、より予測可能なシステムの構築を支援します。ドリフトが解消されると、ソフトウェアを何度展開しても、ソフトウェアが常に同じように動作することが保証されます。
  • 広範なソフトウェアの再利用。Dockerコンテナーは、他のイメージのレイヤーを再利用します。これにより、ソフトウェアの再利用が自然に促進されます。レジストリを介したDockerイメージの共有は、大規模なコンポーネントの再利用のもう1つの優れた例です。
  • 真のマルチクラウド移植性。Dockerは、コンテナーが異なるクラウドプラットフォーム、オンプレミスインフラストラクチャ、および開発ワークステーション間で自由に移行できるようにすることで、真のプラットフォームの独立性を実現します。

Dockerは、組織がシステムを構築してサービスを提供する方法をすでに変えています。それは、ソフトウェア設計とソフトウェア配信の経済学についての私たちの考え方を変え始めています。これらの変更が実際に定着する前に、組織はDocker環境のセキュリティとポリシーを管理する方法をよりよく理解する必要があります。しかし、それは別の記事のトピックです。

Chenxi Wangは、コンテナセキュリティ会社Twistlockの最高戦略責任者です。

New Tech Forumは、前例のない深さと幅で新しいエンタープライズテクノロジーを探索して議論する場を提供します。選択は主観的であり、読者にとって重要で最も興味深いと思われるテクノロジーの選択に基づいています。出版用のマーケティング資料を受け入れず、寄稿されたすべてのコンテンツを編集する権利を留保します。すべてのお問い合わせは[email protected]までお送りください。