21

コンテナー テクノロジを理解しようとしていますが、やや混乱しています。特定のテクノロジーがスタックのさまざまな部分に重なっており、DevOps チームが適切と考えるように、さまざまなテクノロジーのさまざまな部分を使用できるようです (たとえば、Docker コンテナーを使用できますが、Docker エンジンを使用する必要はなく、クラウド プロバイダーのエンジンを使用できます)。代わりは）。私の混乱は、「コンテナー スタック」の各レイヤーが提供するものと、各ソリューションの主要なプロバイダーが誰であるかを理解することにあります。

これが私の素人の理解です。私の理解の穴に関する修正とフィードバックをいただければ幸いです

  1. コンテナー: アプリケーション、ランタイム環境、システム ライブラリなどを含む自己完結型パッケージ。アプリケーションを備えたミニOSのように
    • Docker が事実上の標準になっているようです。他に有名で広く使われているものはありますか?
  2. コンテナ クラスタ: リソースを共有するコンテナのグループ
  3. Container Engine: コンテナをクラスタにグループ化し、リソースを管理します
  4. Orchestrator: これはコンテナ エンジンと何か違いがありますか? どのように？
    • Docker Engine、rkt、Kubernetes、Google Container Engine、AWS Container Service などは 2 から 4 のどこに該当しますか?
4

2 に答える 2

8

質問に具体的に答えるには：

  1. Docker エンジン: Docker コンテナーと Docker イメージのライフサイクルを管理するためのツール。Docker コンテナを作成、再起動、削除します。Docker イメージの作成、名前変更、削除。

  2. rkt: docker エンジンに似ていますが、実装が異なります

  3. Kubernetes: コンテナーを使用する分散アプリケーションのライフサイクルを管理するためのツールのコレクション。コンテナー、コンテナーのグループ、コンテナーの構成、コンテナーのオーケストレーション、実際のインスタンスでのそれらのスケジュールを管理するためのツール、開発者がコンテナーを処理する他のサービス/ツールを作成および維持するのに役立つツールが含まれています。

  4. Google Container Engine: VM を取得する代わりに、それらに「docker-engine」をインストールし、それらに kubernetes をインストールして、インフラストラクチャへの適切なアクセス許可などですべてが機能するようにします。マシンの種類と、これらすべてが機能しているクラスターのサイズ。プロジェクト固有の docker リポジトリ (Google コンテナー レジストリ) からイメージをプルしたり、永続的なボリュームを要求したり、ロード バランサーをプロビジョニングしたりすることは、サービス アカウントや権限などを気にすることなく機能します。

  5. ECS: GKE (4) に似ていますが、Kubernetes はありません。

あなたの理解の要点に対処するには、あなたは物事について大まかに正しいです（私が思うコンテナエンジンを除く）。理解しておくべき唯一の重要なことは、コンテナーとは何かということを理解することが重要です。残りは単なるマーケティング/製品名です。また、今日のコンテナーの理解は、Docker コンテナーとは何か、Docker および Docker に関するツールによって強制される多くの意見によって大きく歪められていることを理解することも重要です。コンテナは昔からあります。

したがって、(docker) コンテナーとは何かを理解すれば、コンテナー エンジンはコンテナーを管理するためのツールにすぎず、コンテナー クラスターはコンテナーのグループにすぎず、オーケストレーターはいくつかのパラメーターに基づいてコンテナーが実行される場所を管理するためのツールにすぎません。私見ですが、コンテナに関するしっかりしたメンタル モデルを理解して構築すれば、残りのツールについてあまり心配する必要はありません。残りは自動的に収まります。

このすべてを理解するための最良の方法は？Docker を使用してかなり複雑なアプリケーションをビルドしてデプロイし (データを保持し、アプリでデータベースを使用する)、すべてが理にかなっています。

于 2016-10-20T21:48:30.087 に答える