AWSバッチでルートボリュームサイズを定義する方法
AWS Batchを使用していますが、ルートボリュームのサイズがタスクには小さすぎることがわかりました。
新しいコンピューティング環境/ジョブキューを作成してみましたが、ボリュームサイズを設定するオプションがありません。 ここ から起動設定を変更してみましたが、新しい起動設定や自動スケーリンググループがAWS Batchで考慮されません。私はおそらく dm.basesize を変更する必要がありますが、これをどこで行うべきかは不明です。
そこで、500 GBのストレージを備えたAmazon 2 LinuxからカスタムAMIをセットアップし、--storage-optとdm.basesize=400GB示されているように ここ ですが、インスタンスは生成されますが、ジョブは無期限にRUNNABLE状態のままです。定義されているように考えられる原因を調べました ここ ですが、i）[パブリックIPv4アドレスの自動割り当てを有効にする]がオンになっています。ii）画像は良好である必要があります（環境を作成するときに検証済みであり、生成される）、iii）このようなインスタンスタイプのインスタンス数は5に制限されています（ただし、1）でも実行できません。iv）自分の役割のアクセス許可は問題ないはずです-デフォルトのamazonlinuxイメージで同じ役割を正常に使用しました、v ）リソース不足（インスタンスが生成されるため、これは問題ではないと思います）、vi）接続性-自動スケーリンググループが正常な状態を表示するため、機能しているはずです。
1つの可能な解決策は、実行時に特定のAWSボリュームをアタッチすることですが、並列実行のためにいくつかのボリュームを管理する必要があるため、制限があり、自動解決策を見つけたいと思います。
また、s3バケットから入力をパイプし、データを分析し、出力を2番目のs3バケットにパイプして、タスクを実行しようとしましたが、毎回 ピアによる接続リセット エラーが発生しました。長い（私は--cli-read-timeout to 0ですが、まったく修正されません）。
AWS Batchのジョブのルートボリュームサイズを構成する方法はありますか？
推奨されるソリューションは、管理されていないコンピューティング環境を使用することです。残念ながら、独自の管理されていないコンピューティング環境を作成することは困難で難解であるだけでなく、AWSバッチの目的全体を打ち負かすだけでなく、はるかに優れた（そしてはるかに単純な）ソリューションがあるため、これは不十分なアドバイスになりました。
この問題の解決策は、AWS Batchが使用するデフォルトのAMIから派生したAmazon Machine Imageを作成することです。 AMIを使用すると、ライブラリのインストール、起動スクリプトの変更、構成ファイルのカスタマイズ、そして最も重要な目的であるデータボリュームの論理パーティションとマウントポイントの定義によって、オペレーティングシステムを希望どおりに構成できます。
1。開始するベースAMIを選択し、インスタンスを構成します
私たちが基盤とするAMIは、ECSに最適化された公式のAMIです。 このページを少し見てください 実行しているAWSリージョンに応じて、必要なAMIを検索します。
AMIを特定したら、右側の列にある[インスタンスを起動]リンクをクリックします。このページが表示されます：
T2.microインスタンスタイプを選択します。
Next: Configuration Detailsを選択します。
必要に応じて、インスタンスに適切なIAMロールを付与します。 「適切」を構成するものはあなたの裁量にあります。残りのデフォルトオプションはそのままにします。 Next: Add Storageをクリックします。
ここで、AMIでデータボリュームがどのように見えるかを構成できます。この手順では、AMIの最終的なボリューム構成も定義しませんが、これを必要に応じて構成すると役立つと思います。 AMIを作成する前に、後でこれを変更する機会があります。完了したら、Next: Add Tagsをクリックします。
必要なタグを追加します（オプション）。 Next: Configure Security Groupをクリックします。
SSHのTypeを選択し、ソースをAnywhereに設定するか、私よりも責任がある場合は、特定のIP範囲のセットを設定します。インスタンスへの接続に使用します。 Review and Launchをクリックします。
このページでは、設定したオプションを確認できます。すべて問題なければ、Launchです。キーペアを求められたら、作成した既存のキーペアを選択するか、新しいキーペアを作成します。この手順を実行しないと、インスタンスに接続できなくなります。
2。ソフトウェア環境を構成します
「起動」をクリックした後、EC2ダッシュボードに移動して、実行中のインスタンスを確認します。
インスタンスが起動するのを待ち、右クリックします。 Connectをクリックし、サンプルのsshコマンドをssh対応端末にコピーアンドペーストします。 -i "keyname.pem"は実際には.pemファイルへのパスであるため、cdを~/.sshディレクトリに変更するか、フラグの値を、ファイルを保存したパスに変更してくださいプライベートSSHキー。 「root」を「ec2-user」に変更する必要がある場合もあります。
ログイン後、VMを構成できますが、必要なパッケージ、ライブラリ、および構成をインストールすることにより、必要なVMが必要です。 AWS提供のECS最適化AMIを使用した場合、AMIはすでにECS AMIの基本要件を満たしています。何らかの（奇妙な）理由でECS最適化AMIを使用しないことを選択した場合は、次のパッケージをインストールして構成する必要があります：
- Amazon ECSコンテナーエージェントの最新バージョン
- Ecs-initエージェントの最新バージョン
- ECSコンテナーエージェントのバージョンに推奨されるDockerのバージョン。
また、ルートボリュームとは別のボリュームをアタッチする場合は、/etc/fstabファイルを変更して、インスタンスの起動時に新しいボリュームがマウントされるようにする必要があることにも注意してください。これを行う方法について、Googleを紹介します。
3。 AMIを保存します
ソフトウェアの構成とインストールがすべて完了したら、EC2ダッシュボードに戻り、実行中のインスタンスを表示します。
作成したインスタンスを右クリックします。 Imageにカーソルを合わせ、Create Imageを選択します。
これには、手順1で選択したボリューム構成が表示されます。ボリュームをデフォルト設定から変更しなかったため、上のスクリーンショットで、ECS最適化AMIのデフォルトボリュームが実際には8GBであることを確認できます/dev/xvda/（ルート）、および/dev/xvdc/には22GB（dockerイメージなど）。インスタンスの終了後にBatchコンピューティング環境がボリュームを削除できるように、Delete on Terminationオプションが選択されていることを確認してください。そうしないと、無制限の数のEBSボリュームが作成されるリスクがあります（非常に高価なので、言われています）。ルートストレージが111 GBのみになるようにAMIを構成します。 Dockerに別のボリュームが必要になるとは限りません。
画像に名前と説明を付け、Create Imageを選択します。
インスタンスが再起動されます。インスタンスがオフになると、AWSはインスタンスのイメージを作成し、インスタンスをオンに戻します。
EC2コンソールで、左側のImages, AMIsに移動します。数分後、新しく作成したAMIがリストに表示されます。
4。新しいAMIを使用するようにAWS Batchを設定します
AWSダッシュボードに戻り、AWS Batchページに移動します。左側の[Compute environments]を選択します。 Create environmentを選択します。
コンテナー（サービスロール）とEC2インスタンス（インスタンスロール）の両方に適切なIAMロール、プロビジョニングモデル、ネットワーク、タグを選択して、環境を構成します。
Option Value
Compute environment type Managed
Compute environment name AMI_test
Service role AWSBatchServiceRole
Instance role ecsInstanceRole
EC2 key pair landonkey.pem (use name of your private key)
Provisioning model On-Demand (choose spot for significantly cheaper provisioning)
Allowed instance types Optimal
Minimum vCPUs 0
Desired vCPUs 0
Maximum vCPUs 256
Enable user-specified AMI ID True
AMI ID [ID of AMI you generated]
VPC id [default value]
Subnets [select all options]
Security groups default
このための重要なステップは、Enable user-specified AMI IDを選択し、前のステップで生成したAMI IDを指定することです。
すべてのオプションを構成したら、Createを選択します。
5。ジョブキューとジョブ定義を作成する
コンピューティング環境が実際に機能することをテストするために、いくつかの簡単なキューとジョブ定義を作成してみましょう。
左側のJob queuesを選択し、次のオプションを入力します。
Option Value
Queue name AMI_test_queue
Priority 1
Enable Job queue True
Select a compute environment AMI_test
Createを選択します。新しいキューのステータスがVALIDになるまで待ちます。
Job definitionsに移動し、Createを選択します。次の値を入力します。
Option Value
Job definition name AMI_test_job_def
Job role ECS_Administrator
Container image amazonlinux
Command df -h
vCPUs 1
Memory (MiB) 1000
Job attempts 1
Execution timeout 100
Parameters [leave blank]
Environment variables [leave blank]
Volumes [leave blank]
Mount points [leave blank]
Create job definitionを選択します。
最後に、左側のJobsに移動し、Submit jobを選択します。ジョブに名前を付け、ジョブ定義にAMI_test_job_def:1を選択します。残りのデフォルト値はそのままにして、Submit jobを選択します。
すべてがうまくいけば、ジョブがPendingまたはRunnable状態に入ったことを確認できます。ジョブが実際に実行されるまでに10分以上かかる場合があることに注意してください。 EC2インスタンスのインスタンス化には通常5〜10分かかり、ステータスチェックに合格するにはさらに数分かかります。インスタンスが作成され、すべてのステータスチェックに合格した後も、ジョブがRunnable状態のままである場合。何かがおかしい。
起動テンプレートも使用できるようになりました。起動テンプレートで、ルートボリュームのサイズを増やします。次に、ジョブ定義から、/ mntなどのローカルファイルシステムをdockerにマウントします。