序章

多くの場合、アプリケーションを開発サイクルから最終的に本番環境に簡単に移行する際の障害となる多くの障害があります。 各環境で適切に応答するようにアプリケーションを開発する実際の作業に加えて、依存関係の追跡、アプリケーションのスケーリング、およびアプリケーション全体に影響を与えずに個々のコンポーネントを更新する際の問題に直面する場合もあります。

Dockerのコンテナー化とサービス指向設計は、これらの問題の多くを解決しようとします。 アプリケーションは、管理しやすい機能的なコンポーネントに分割し、すべての依存関係とともに個別にパッケージ化して、不規則なアーキテクチャに簡単にデプロイできます。 コンポーネントのスケーリングと更新も簡素化されます。

このガイドでは、コンテナ化のメリットと、Dockerが上記の問題の多くを解決するのにどのように役立つかについて説明します。 Dockerは、分散コンテナーデプロイメントのコアコンポーネントであり、スケーラビリティと管理が容易です。

Linuxコンテナ化の簡単な歴史

コンテナ化と分離は、コンピューティングの世界では新しい概念ではありません。 一部のUnixライクなオペレーティングシステムは、10年以上にわたって成熟したコンテナ化テクノロジーを活用してきました。

Linux、LXCでは、後のコンテナ化テクノロジーの基盤を形成するビルディングブロックが2008年にカーネルに追加されました。 LXCは、カーネルcgroup(リソース使用率の分離と追跡を可能にする)と名前空間(グループを分離して相互に「認識」できないようにする)の使用を組み合わせて、軽量プロセス分離を実装しました。

その後、コンテナーの作成と管理に必要なツールを簡素化する方法としてDockerが導入されました。 当初はデフォルトの実行ドライバーとしてLXCを使用していました(その後、この目的のためにlibcontainerというライブラリーを開発しました)。 Dockerは、多くの新しいアイデアを導入することはありませんが、プロセスを簡素化し、インターフェイスを標準化することで、平均的な開発者やシステム管理者がそれらにアクセスできるようにしました。 それは、開発者の間でLinuxの世界におけるコンテナ化への新たな関心に拍車をかけました。

この記事で説明するトピックのいくつかはより一般的ですが、その圧倒的な人気と標準的な採用により、主にDockerコンテナー化に焦点を当てます。

コンテナ化がもたらすもの

コンテナーには、開発者とシステム管理者/運用チームの両方にとって非常に魅力的な多くの利点があります。

最もメリットのあるものを以下に示します。

コンテナ化されたアプリケーションから離れたホストシステムの抽象化

コンテナは完全に標準化されることを目的としています。 これは、コンテナーが、定義されたインターフェースを使用して、ホストおよびコンテナーの外部にあるものに接続することを意味します。 コンテナ化されたアプリケーションは、基盤となるホストのリソースやアーキテクチャに関する詳細に依存したり、関係したりしてはなりません。 これにより、運用環境に関する開発の前提が簡素化されます。 同様に、ホストにとって、すべてのコンテナはブラックボックスです。 内部のアプリケーションの詳細は気にしません。

簡単なスケーラビリティ

ホストシステムとコンテナー間の抽象化の利点の1つは、適切なアプリケーション設計があれば、スケーリングが単純で簡単になることです。 コンテナ化されたアプリケーションと組み合わせたサービス指向設計(後で説明)は、スケーラビリティーを容易にするための基礎を提供します。

開発者はワークステーションでいくつかのコンテナーを実行できますが、このシステムはステージングまたはテスト領域で水平方向にスケーリングできます。 コンテナが本番環境に入ると、再びスケールアウトできます。

単純な依存関係管理とアプリケーションのバージョン管理

コンテナを使用すると、開発者はアプリケーションまたはアプリケーションコンポーネントを、そのすべての依存関係とともに1つの単位としてバンドルできます。 ホストシステムは、特定のアプリケーションを実行するために必要な依存関係を考慮する必要はありません。 Dockerを実行できる限り、すべてのDockerコンテナーを実行できるはずです。

これにより、依存関係の管理が容易になり、アプリケーションのバージョン管理も簡素化されます。 ホストシステムと運用チームは、関連するコンテナーへの依存は別として、すべてコンテナー自体に含まれている必要があるため、アプリケーションの依存関係のニーズを管理する責任を負いません。

非常に軽量で分離された実行環境

コンテナーは仮想化テクノロジーと同じレベルの分離とリソース管理を提供しませんが、トレードオフから得られるのは非常に軽量な実行環境です。 コンテナはプロセスレベルで分離され、ホストのカーネルを共有します。 これは、コンテナ自体に完全なオペレーティングシステムが含まれておらず、起動時間がほぼ瞬時になることを意味します。 開発者は、ワークステーションから何百ものコンテナを問題なく簡単に実行できます。

共有レイヤリング

コンテナは、「レイヤー」でコミットされるという点で、別の意味で軽量です。 複数のコンテナが同じレイヤーに基づいている場合、それらは重複することなく基盤となるレイヤーを共有できるため、後のイメージのディスクスペース使用率を最小限に抑えることができます。

構成可能性と予測可能性

Dockerファイルを使用すると、ユーザーは新しいコンテナーイメージを作成するために必要な正確なアクションを定義できます。 これにより、実行環境をコードであるかのように記述し、必要に応じてバージョン管理に保存できます。 同じ環境でビルドされた同じDockerファイルは、常に同じコンテナイメージを生成します。

繰り返し可能で一貫性のあるビルドのためのDockerfilesの使用

インタラクティブなプロセスを使用してコンテナイメージを作成することは可能ですが、必要なステップがわかったら、Dockerfile内に構成ステップを配置する方がよい場合がよくあります。 Dockerfileは、既知の開始点からコンテナイメージを作成する方法を記述した単純なビルドファイルです。

Dockerfileは非常に便利で、習得がかなり簡単です。 それらが提供する利点のいくつかは次のとおりです。

  • 簡単なバージョン管理:Dockerfile自体をバージョン管理にコミットして、変更を追跡し、間違いを元に戻すことができます
  • 予測可能性:Dockerfileからイメージを構築すると、イメージ作成プロセスから人為的エラーを取り除くのに役立ちます。
  • 説明責任:イメージの共有を計画している場合は、他のユーザーがプロセスを監査する方法として、イメージを作成したDockerfileを提供することをお勧めします。 基本的に、イメージを作成するために実行された手順のコマンド履歴を提供します。
  • 柔軟性:Dockerfileからイメージを作成すると、インタラクティブビルドで指定されているデフォルトをオーバーライドできます。 これは、イメージを意図したとおりに機能させるために、実行時オプションを多く提供する必要がないことを意味します。

Dockerfileは、コンテナイメージの構築を自動化して、繰り返し可能なプロセスを確立するための優れたツールです。

コンテナ化されたアプリケーションのアーキテクチャ

コンテナー内にデプロイされるアプリケーションを設計する場合、最初に懸念される領域の1つは、アプリケーションの実際のアーキテクチャーです。 一般に、コンテナー化されたアプリケーションは、サービス指向設計を実装する場合に最適に機能します。

サービス指向アプリケーションは、システムの機能を、明確に定義されたインターフェースを介して相互に通信する個別のコンポーネントに分割します。 コンテナテクノロジー自体が、各コンポーネントを個別にスケールアウトまたはアップグレードできるため、このタイプの設計を促進します。

このタイプの設計を実装するアプリケーションには、次の品質が必要です。

  • ホストシステムの詳細を気にしたり、依存したりするべきではありません
  • 各コンポーネントは、消費者がサービスにアクセスするために使用できる一貫したAPIを提供する必要があります
  • 各サービスは、初期構成時に環境変数から手がかりを取得する必要があります
  • アプリケーションデータは、コンテナの外部のマウントされたボリュームまたはデータコンテナに保存する必要があります

これらの戦略により、APIが維持されている限り、各コンポーネントを個別にスワップアウトまたはアップグレードできます。 また、経験しているボトルネックに応じて各コンポーネントをスケーリングできるため、焦点を絞った水平方向のスケーラビリティにも役立ちます。

通常、各コンポーネントは特定の値をハードコーディングするのではなく、適切なデフォルトを定義できます。 コンポーネントはこれらをフォールバック値として使用できますが、環境から収集できる値を優先する必要があります。 これは多くの場合、コンポーネントが起動手順中に照会できるサービス検出ツールを使用して実行されます。

実際のコンテナーから構成を取り出して環境に配置すると、コンテナーイメージを再構築しなくても、アプリケーションの動作を簡単に変更できます。 また、単一の設定でコンポーネントの複数のインスタンスに影響を与えることもできます。 一般に、サービス指向設計は、環境構成戦略とうまく組み合わされます。どちらも、より柔軟な展開とより直接的なスケーリングを可能にするためです。

コンテナ管理のためのDockerレジストリの使用

アプリケーションが機能コンポーネントに分割され、環境内の他のコンテナーと構成フラグに適切に応答するように構成されたら、次のステップは通常、コンテナーイメージをレジストリーから利用できるようにすることです。 コンテナイメージをレジストリにアップロードすると、Dockerホストは、イメージ名を知っているだけで、イメージをプルダウンしてコンテナインスタンスを起動できます。

この目的で利用できるさまざまなDockerレジストリがあります。 一部のレジストリは、コミットされた画像を誰でも表示および使用できるパブリックレジストリですが、他のレジストリはプライベートです。 画像にタグを付けると、ダウンロードや更新の対象になりやすくなります。

結論

Dockerは、分散コンテナーのデプロイに必要な基本的なビルディングブロックを提供します。 アプリケーションコンポーネントを独自のコンテナーにパッケージ化することにより、水平スケーリングは、各コンポーネントの複数のインスタンスをスピンアップまたはシャットダウンする単純なプロセスになります。 Dockerは、コンテナーを構築するだけでなく、コンテナーを管理して新しいユーザーやホストと共有するために必要なツールを提供します。

コンテナ化されたアプリケーションは、展開を支援するために必要なプロセスの分離とパッケージ化を提供しますが、ホストの分散クラスター上でコンテナーを適切に管理およびスケーリングするために必要な他の多くのコンポーネントがあります。 次のガイドでは、サービス検出とグローバルに分散された構成ストアがクラスター化されたコンテナーのデプロイメントにどのように寄与するかについて説明します。