Zenn
Open43

読者コミュニティ｜ecspresso handbook

sogaohsogaoh

質問

（自己解決済み）

Chapter 07 Terraform tfstate を読み込む で、 ↓のような
https://github.com/sogaoh/sso-redirect-examples/tree/develop/infrastructures
module を利用している場合の参照例があるとありがたい気がしたのですが、基本的には
"${resource_type}.${name}.(リソース項目)"
になるでしょうか？

sogaohsogaoh

x "${resource_type}.${name}.(リソース項目)"
o "module.${module名}.${resource_type}.${name}.(リソース項目)"

で参照できそうです。（参照以外の問題で、 verify FAILED となりました）

sogaohsogaoh

tfstate の項目で言うと、 "${module}.${type}.${name}.(リソース項目)"

sogaohsogaoh

要望

Chapter 07 Terraform tfstate を読み込む に関してもう１点

https://github.com/kayac/ecspresso#tfstate を見ると s3 の URL で tfstate を指定できる感じだったので
v1.2.1 で verify してみたところ
Could not load config file ecs/auth-client/config.yaml tfstate plugin requires path for tfstate file as string となりましたが
v1.3.1 では verify できました。

書籍にも可能なタイミングで反映してほしいと思いました。

fujiwarafujiwara

ありがとうございます。READMEはその時点の最新の状態になるため、旧バージョンでは使用できない機能が記載されている場合があります。ハンドブックも順次改訂予定ですのでしばしお待ち下さい。

sogaohsogaoh

@fujiwara typo を見つけました

04 基本的な使い方 の２番めのセクションです

x sacle
o scale

sogaohsogaoh

まだ試していないのですが、 ecspresso で１サービスに複数タスクを登録することは可能でしょうか？
可能な場合、同じサービス定義に別のタスク定義を config.yaml に書いて register する感じでしょうか？

以下のような構成を今のところ考えています

  • artisan (ディレクトリ。Laravel の artisan コマンドを実行するタスクを複数置く想定)
    • migration
      • config.yml
      • ecs-service-def.json [内容A]
      • ecs-task-def.json
    • batch-XXX
      • config.yml
      • ecs-service-def.json [内容A]
      • ecs-task-def.json

あるいは

  • artisan
    • ecs-service-def.json [内容A]
    • config_migration.yml
    • ecs-task-def_migration.json
    • config_batch.yml
    • ecs-task-def_batch.json
sogaohsogaoh

複数タスクを登録する必要がなくなったので、却下しておきます。すみません。

sogaohsogaoh

--debug Flag の使い方

現在、とある task の run にうまくいってなくて、そのときに
run FAILED. container is not found in task definition
という終わり方をしています。

--debug をつけて単純に（特に修正なく）再実行してみたのですが、コンソール出力に特に変化がなく、何かファイルが出ているわけでもありませんでした。

https://github.com/kayac/ecspresso/blob/v1/run.go

のどこで return になった、というあたりのことを把握する術はなにかあったりするでしょうか。

fujiwarafujiwara

(徹底できていない可能性はありますが) err は ecspresso 内のどこかで一度は wrap してから最終的に main.go に返るように書いているはずなので、エラーメッセージの文字列で検索すれば ecspresso のコード内で引っかかるかと思います。--debug にしたら stacktrace を出したほうがいいかもしれません。

sogaohsogaoh

ありがとうございます！
目に見えないのですが、 container is not found in task definition の container と is の間には空白があって、
コレ何だろう、って思ってました。 is not found からのメッセージを検索してたら見つけられたのかもしれません。

sogaohsogaoh

--watch-container を確認してみます！

-> 元々指定してなかったのですが、指定してみても同様の「container ない」のエラーになりました。
タスク定義がおかしいように思うので、見直してみます。

sogaohsogaoh

解消できていないのですが、推測になりますが ecspresso で run するには ALB からの通信がタスクを動かしたい container まで届いていないとできない、という感じの制限があったりするでしょうか？
そうであれば、AWS CLI でのタスク単独(?)実行に考え方を切り替えようかと思っています。

sogaohsogaoh

--dry-run を付けていると、「container ない」になるのだとわかりました。。
それがわかるメッセージだとありがたいかな、とふと思いました。

fujiwarafujiwara

run --dry-runのその挙動は想定してないものなので直します。ありがとうございます！

sogaohsogaoh

コマンドリファレンスに init がほしいと思いました。。

profile 指定するときは事前に export AWS_PROFILE=profile_name してね があると良さそう

sogaohsogaoh

ECSサービス検出の機能を利用したいので、 ecs-service-def.json に以下のような定義を投入して
ecspresso --config=config.yaml create をしてみました。

  "serviceRegistries": [
    {
      "registry_arn": "arn:aws:servicediscovery:${region}:${account_id}:service/srv-XXXXXXXXXXXXXXX"
    }
  ]

結果、 create FAILED. failed to create service: InvalidParameterException: registry arn cannot be blank で失敗してしまいます。
こういった issue が上がったことはあるでしょうか。

メッセージでソースを検索した感じでは、CreateServiceWithContext API を使用しているようだということと、
https://github.com/aws-cloudformation/cfn-python-lint/issues/350 が見つかって何かパラメータが足りないのかなと思ったりしています。

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service_definition_parameters.html
から serviceRegistries で検索した周辺のドキュメントは見回しているつもりです。

前進するのになにが足りていないのでしょうか。。（issue に上げたほうがよければお知らせください）

sogaohsogaoh

"registry_arn": の値に、最初は tfstate の参照で
"{{ tfstate module.ecs-fargate.aws_service_discovery_service.sd_service_XXXX_module.arn }}" のような指定をしてました。参照で取れてなさそうだったので
"arn:aws:servicediscovery:${region}:${account_id}:service/srv-XXXXXXXXXXXXXXX"
のような値を入れてみた次第です。（FAILEDになりましたが。。）

fujiwarafujiwara

JSON のキー名は registry_arn ではなく registryArn ではないでしょうか?

ecspresso create --dry-run をすると作成しようとしている service の内容を dump しますので、その内容を確認してみてください。キー名が正しくないと parse できないので、おそらく以下のような出力になっていて、結果 registry arn cannot be blank と言われているかと思われます。

"serviceRegistries": [
    {}
]
sogaohsogaoh

即答ありがとうございます。

verify で ALL OK だったので、よーしやってみるか、ってなってました。
dry-run の結果、たしかに serviceRegistries になにもない結果になってました。

dry-run できるものはやっておいたほうがいい、ということを掴みました。
今後は自力で乗り越えられるように勘を維持したいと思います。

fujiwarafujiwara

--deregister-task-definition オプションは作用しない（ロールバック前のタスク定義が登録されたまま）

こちらは v1.5.4 時点での仕様となります。

ecspresso は CodeDeploy でのデプロイを作成して開始すると、プロセスを終了します。その後の CodeDeploy 上での進行状況を知ることができないため、タスク定義の登録をいつ解除できるのか判断できないためです。

ハンドブックには記述を追記しました。

sogaohsogaoh

昨日まで問題なく行えていた ecspresso verify で ContainerDefinition[dd-agent] [NG] verify Image[datadog/agent:latest] failed: 404 Not Found となった のですが、
https://hub.docker.com/layers/datadog/agent/latest/images/sha256-f213ef02e547036d03559d67c5ad048b9bc97aaa3f326d30cd7a2fd85303e934?context=explore は存在していました。
404 Not Found は AWS CLI ? からのレスポンスなのでしょうか？

ここ数週間連続でデプロイ時にトラブルが起きており、何がどういけないのか、を掴みたいと考えているための質問です。

（安定的にならないと、デプロイを人に引き渡していけないため。。）

sogaohsogaoh

エラー発生したときのコンソール出力（末尾）


❯ ecspresso --config config.yaml verify
・・・
    ContainerDefinition[dd-agent]
      Image[datadog/agent:latest]
      --> Image[datadog/agent:latest] [NG] 404 Not Found
    --> ContainerDefinition[dd-agent] [NG] verify Image[datadog/agent:latest] failed: 404 Not Found
  --> TaskDefinition [NG] verify ContainerDefinition[dd-agent] failed: verify Image[datadog/agent:latest] failed: 404 Not Found
sogaohsogaoh

応急処置的な対応としては、ECR に FROM datadog/agent:latest のみの Dockerfile を build して
ECR へ push して使うようにして回避しています

fujiwarafujiwara

DockerHub側の変更で、imageの存在確認APIのエンドポイントが変わっていたので修正した v1.5.7 をリリースしました。
ただし ECS で使うイメージを DockerHub から直接取得すると API limit に掛かる可能性もあるので、一般的には ECR にミラーする等をお勧めします。

maaaatomaaaato

Chapter04のscaleの説明のコマンドにtypoがありましたのでご報告です。

サブコマンドscaleを2つ入力していました。結果ecspresso: error: unexpected scale, try --helpが発生することを確認しました。
バージョンは以下の通りです。

ecspresso version
ecspresso v1.6.2
su8su8

丁寧で分かりやすいガイド本ありがとうございます。
読み進めるなかで 2点 気になった箇所があったため、質問いたします。

対象は v2対応版です。
https://zenn.dev/fujiwara/books/ecspresso-handbook-v2

1. 文章の途切れ
08 テンプレート記法/YAMLやJSONとしてなるべく壊れないように記述する
上記セクションにおいて、文章が途中で切れているように見受けられる箇所がありました。

該当箇所を下記に引用します。

ecspressoで利用する場合は「テンプレートのレンダリング」→「YAML/JSONとしてのパース」の順で処理されるので問題はありませんが、ファイルをエディタで編集する場合などは整形に支障が出ることがあります。また、yamlfmt

yamlfmt に続く文章が本来は存在していたのかな？と気になりました。

2. 環境変数名の揺れ
15 バージョン固定/設定ファイルをYAMLで記述する場合
上記セクションにおいて、環境変数名ECSPRESSO_VERSION, REQUIRED_VERSIONの揺れがある気がしました。

具体的には下記で示されている例を

export REQUIRED_VERSION="v$(cat .ecspresso-version)"

以下にリライトすることで環境変数名の揺れがなくなるかな？と思います（たぶん）。

export ECSPRESSO_VERSION="v$(cat .ecspresso-version)"

以上が質問事項です。

ecspresso というツールの使い勝手もさることながら、ガイド本もとてもよかったです。
お手数ですが、ご確認宜しくお願いいたします 🐰

fujiwarafujiwara

ありがとうございます！2点、ご指摘の通りでしたので、修正して書籍を更新済です。

su8su8

確認いたしました。
ありがとうございます 🐰

（ちょっと漢字に自信ないのですが「成形」ではなく「整形」のほうが適しているかもしれません）