問題タブ [amazon-ecs]

私はドッカーが初めてです。Docker イメージの保存に ECR プライベート リポジトリを使用したいと考えています。そのため、docker イメージをビルドし、ローカルで実行しました。CLIを使用しています。次に、イメージのプッシュ/プルに対する完全なアクセス制御を使用して、ECR に artle/repo などのリポジトリを作成しました。次に、aws アカウントにログインし、イメージをローカルから artle/repo にプッシュしようとすると、小さなファイルはプッシュされますが、大きなファイル (349Mb など) はプッシュ中に動かなくなります。エラーは発生しません。「[=====> ] 42.MB/349MB を押しています」と連続して表示されます。イメージにエラーがあるのではないかと考えて、いくつかのオープン ソース イメージをプッシュしようとしましたが、同じ結果が得られました。

どんな助けでも大歓迎です。ありがとう。

コンテナのスケジューリングに AWS-ECS を使用しています。ECS で最も差し迫った問題は、「リソースの断片化」です。

それぞれのリソース要件を持つ次のタスク定義/ポッドがあるとします。

(簡単にするために CPU 要件のみを保持します)

使用可能な CPU=2048 の VM を考慮すると、上記のサービスを実行するには少なくとも 3 つの VM が必要です。

さらに言えば、Blue Green デプロイを実行するには、理論的には2048 CPU ユニットを備えたVM がもう 1 つ必要です。

ただし、時間の経過とともにデプロイが行われると、コンテナーは利用可能なすべての VM に分散されます。これにより、リソースが利用できないため、Blue Green の展開に時間がかかりすぎます (または失敗することさえあります)。

そのため、Blue Green の展開が予想どおりに機能するには、クラスター内にさらに多くの追加の VM (より多くの $$$)が必要になります。

Kubernetes がポッドを統合してリソースの断片化を最小限に抑える機能を提供しているかどうかを知りたいです。

一部のワークロードを Amazon ECS Container Service に移行中ですが、移行を妨げているブロッカーを見つけました。

理想的には、ECS で実行されるコンテナー化されたアプリはステートレスで、任意のクラスター インスタンスで実行してスケールアウトできるようにする必要があります。しかし実際には、EBS データ ボリュームに依存するアプリがいくつかあります。私が知る限り、これらのボリュームは特定のクラスター インスタンスに手動で接続する必要があり、データにアクセスできるようにするには ECS アプリをそのインスタンスに配置する必要があるため、これらのボリュームがどこで実行されるかを制御する方法が必要です。

例として、Amazon ECS によって管理される 3 つの EC2 インスタンスのクラスターがあるとします。

• インスタンス1
• インスタンス 2
• インスタンス3

次に、2 つのコンテナー化されたアプリがあります。

• ステートレスな app1
• EBS ボリュームに依存するapp2

app1 はクラスターの任意のインスタンスで実行できますが、問題ありません。

app2 の場合、EBS ボリュームをインスタンス 2 にアタッチしてマウントするとします。

さて、問題は、app2 を定義または起動するときに、EBS ボリュームにアクセスできるように、app2 を instance2 だけに配置するように制限することはできますか?

よろしくお願いします！

編集:

私はもう少し読んで、Amazonのドキュメントでそれを行う方法を見つけました. ドキュメント「<a href="http://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_data_volumes.html" rel="noreferrer">タスクでのデータ ボリュームの使用」には、次のようなメモがあります。

重要

Amazon ECS は、コンテナ インスタンス間でデータ ボリュームを同期しません。永続的なデータ ボリュームを使用するタスクは、使用可能な容量があるクラスター内の任意のコンテナー インスタンスに配置できます。タスクの停止と再起動後に永続的なデータ ボリュームが必要な場合は、AWS CLI の start-task コマンドを使用して、タスクの起動時に常に同じコンテナ インスタンスを指定する必要があります。

したがって、 CLI でstart-taskコマンドを見ると、まさに私が探していたものであることがわかりました。

開始タスク

指定されたコンテナー インスタンスで、指定されたタスク定義から新しいタスクを開始します。デフォルトの Amazon ECS スケジューラを使用してタスクを配置するには、代わりに run-task を使用します。

これには、起動するタスク定義と、タスクを実行するコンテナー インスタンスID (最大 10)の 2 つの必須パラメーターがあります。

したがって、コマンドの呼び出しは次のようになります。

私はそれを試してみましたが、完全に機能しました。

AWS Web UI には、タスクの起動時にコンテナ インスタンスを指定するフィールドが用意されていないため、現時点ではこれが唯一の方法のようです。

誰かの役に立てば幸いです。

コンテナーを実行する AutoScaling グループがあります (ECS を使用)。ASG で EC2 インスタンスを追加または置換すると、必要な Docker イメージがありません。そのため、cloud-init を使用していくつかのdocker pullコマンドを実行し、起動時にイメージをフェッチします。

ただし、ASG は新しいインスタンスの準備ができていると見なし、古いインスタンスを終了します。しかし実際には、すべての Docker イメージがプルされるまで、この新しいインスタンスの準備はできていません。

たとえば、ASG の希望数が 5 で、cloud-init を使用して 5 つのコンテナーをプルする必要があるとします。ここで、ASG 内のすべての EC2 インスタンスを置き換えたいと考えています。

新しいインスタンスが起動し始めると、ASG は古いインスタンスを終了します。ただし、docker pullラグが原因で、デプロイ中に実際の有効なインスタンスが 3 または 2 未満になる時間があります。

cloud-init が終了したときにのみ「インスタンスを準備完了としてマーク」するにはどうすればよいですか?

注: Cloudformation は、CFN-Bootstrap を使用してこの通信ギャップを埋めることができると思います。しかし、私は Cloudformation を使用していません。

私は Amazon ECS に比較的慣れていないので、気になる質問があります。

最小限の実行可能なクラスターをテストする過程で、動的なサイズのサービスを作成できないことに気づきました。コンソール、CLI、または CloudFormation を介してサービスのパラメーターを変更するタスクの数を指定する選択肢は 1 つだけです。言い換えれば、タスクの数は静的に定義されます。そして、それは必要に応じて動的にスケーリングされるため、自動スケーリング グループの性質と矛盾します。

では、ECS タスクを動的にスケーリングするにはどうすればよいでしょうか。

ECS Auto Scaling クラスターを作成するためのテラフォーム スクリプトを作成しています。クラスターを作成し、そこに ec2 コンテナー インスタンスを追加しました。私のタスク定義ファイルには、プライベート Docker リポジトリからのイメージが含まれています。AWS の公式ドキュメントに目を通し、プライベート レジストリ認証のページを見つけて、 両方の方法を試しました。そこに記載されているとおりです。

1. dockercfg の使用
2. ドッカーの方法

ecs.config ファイルを S3 バケットに置き、インスタンスの起動時にユーザー データを次のように渡しました。

2 番目のアプローチでは、使用したデータを次のように渡しました。

コンテナ インスタンスにログインすると /etc/ecs/ecs.config にデータが見つかりますが、イメージを手動でプルしようとすると、イメージが見つからないというエラーが表示されます。

次に、そこで docker login コマンドを試し、資格情報を手動で入力して、そのイメージを再度プルしようとすると、最終的に成功しました。

ユーザーデータによって自動的に最適化されたecsイメージでプライベートdockerレジストリ認証を実現する方法があるかどうか、または何か間違っているかどうかはわかりません。

これで私を助けてください。

Ec2 Container Engine クラスタが作成されると、Compute Engine マネージド インスタンス グループが作成され、作成されたインスタンスが管理されます。これらのインスタンスは Ec2 サービスからのものです。つまり、それらは仮想マシンです。

しかし、コンテナーは、重量があり移植性がない VM のようなハードウェア仮想化ではなく、オペレーティング システム レベルの仮想化に基づいてコンテナーをデプロイする新しい方法であることはわかっていますが、矛盾していませんか? 私が間違っている場合は修正してください。

VM と比較して (起動時間またはタスク実行のいずれかで) 非常に高速であり、多くのスペース ストレージを節約できるため、コンテナーを使用します。したがって、最大 4 つのコンテナーをサポートできるノード (vm) が 1 つある場合、クライアントは 4 つのコンテナーを迅速に起動できますが、この数を超えると、Ec2 オートスケーラーは今後のコンテナーをサポートするために新しいノード (vm) を起動する必要があり、いくつかのタスクが発生します。遅れ。

物理マシン上でコンテナを起動することは不可能ですか?

また、重要な時間の実行タスクを実行するために何をお勧めしますか?