前書き
多くの場合、開発サイクルを経て最終的に本番環境へとアプリケーションを簡単に移行することを妨げる多くの障害があります。 各環境で適切に応答するようにアプリケーションを開発する実際の作業に加えて、依存関係の追跡、アプリケーションのスケーリング、およびアプリケーション全体に影響を与えない個々のコンポーネントの更新に関する問題に直面する可能性もあります。
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内に構成手順を配置する方がよい場合があります。 Dockerfilesは、既知の開始点からコンテナーイメージを作成する方法を記述する単純なビルドファイルです。
Dockerfileは信じられないほど便利で、マスターするのはかなり簡単です。 彼らが提供する利点のいくつかは次のとおりです。
-
Easy versioning：Dockerfiles自体をバージョン管理にコミットして、変更を追跡し、間違いを元に戻すことができます
-
Predicatability：Dockerfileからイメージを構築すると、イメージ作成プロセスから人為的エラーを取り除くのに役立ちます。
-
Accountability：イメージの共有を計画している場合は、他のユーザーがプロセスを監査する方法として、イメージを作成したDockerfileを提供することをお勧めします。 基本的に、イメージを作成するために実行した手順のコマンド履歴を提供します。
-
Flexibility：Dockerfileからイメージを作成すると、インタラクティブビルドで指定されているデフォルトをオーバーライドできます。 これは、イメージを意図したとおりに機能させるために、多くのランタイムオプションを提供する必要がないことを意味します。
Dockerfilesは、コンテナーイメージの構築を自動化して繰り返し可能なプロセスを確立するための優れたツールです。
コンテナ化されたアプリケーションのアーキテクチャ
コンテナ内にデプロイされるアプリケーションを設計する場合、最初の懸念事項の1つは、アプリケーションの実際のアーキテクチャです。 一般に、コンテナ化されたアプリケーションは、サービス指向の設計を実装する場合に最適に機能します。
サービス指向アプリケーションは、システムの機能を、明確に定義されたインターフェースを介して互いに通信する個別のコンポーネントに分割します。 コンテナテクノロジー自体は、各コンポーネントを個別にスケールアウトまたはアップグレードできるため、このタイプの設計を推奨しています。
このタイプの設計を実装するアプリケーションには、次の品質が必要です。
-
ホストシステムの詳細を気にしたり、依存したりしないでください。
-
各コンポーネントは、消費者がサービスへのアクセスに使用できる一貫したAPIを提供する必要があります
-
各サービスは、初期構成中に環境変数からキューを取得する必要があります
-
アプリケーションデータは、マウントされたボリューム上のコンテナの外部またはデータコンテナに保存する必要があります
これらの戦略により、APIが維持されている限り、各コンポーネントを個別に交換またはアップグレードできます。 また、発生しているボトルネックに応じて各コンポーネントをスケーリングできるため、集中的な水平スケーラビリティにも役立ちます。
特定の値をハードコーディングするのではなく、各コンポーネントは通常、適切なデフォルトを定義できます。 コンポーネントはこれらをフォールバック値として使用できますが、環境から収集できる値を優先する必要があります。 多くの場合、これは、コンポーネントが起動手順中に照会できるサービス検出ツールを使用して実現されます。
実際のコンテナから構成を取り出して環境に配置すると、コンテナイメージを再構築せずにアプリケーションの動作を簡単に変更できます。 また、1つの設定でコンポーネントの複数のインスタンスに影響を与えることができます。 一般に、サービス指向の設計は、より柔軟な展開とより簡単なスケーリングを可能にするため、環境構成戦略とうまく組み合わされます。
コンテナ管理にDockerレジストリを使用する
アプリケーションが機能コンポーネントに分割され、環境内の他のコンテナーと構成フラグに適切に応答するように構成されたら、次のステップは通常、コンテナーイメージをレジストリから利用できるようにすることです。 コンテナーイメージをレジストリにアップロードすると、Dockerホストはイメージ名を知るだけでイメージをプルダウンし、コンテナーインスタンスをスピンアップできます。
この目的のために利用可能なさまざまなDockerレジストリがあります。 いくつかは、誰でもコミットされた画像を表示して使用できる公開レジストリですが、他のレジストリはプライベートです。 ダウンロードや更新の対象になりやすいように、画像にタグを付けることができます。
結論
Dockerは、分散コンテナーの展開に必要な基本的な構成要素を提供します。 アプリケーションコンポーネントを独自のコンテナにパッケージ化することにより、水平スケーリングは、各コンポーネントの複数のインスタンスをスピンアップまたはシャットダウンする単純なプロセスになります。 Dockerは、コンテナを構築するだけでなく、それらを管理し、新しいユーザーまたはホストと共有するために必要なツールを提供します。
コンテナ化されたアプリケーションは、展開を支援するために必要なプロセスの分離とパッケージ化を提供しますが、ホストの分散クラスター上でコンテナを適切に管理およびスケーリングするために必要な他の多くのコンポーネントがあります。 next guideでは、サービス検出とグローバルに分散された構成ストアがクラスター化されたコンテナーの展開にどのように寄与するかについて説明します。