読者コミュニティ｜ecspresso handbook

fujiwara

本の感想や質問をお気軽にコメントしてください。

sogaoh

Handbook URL

sogaoh

質問

（自己解決済み）

Chapter 07 Terraform tfstate を読み込むで、 ↓のような

module を利用している場合の参照例があるとありがたい気がしたのですが、基本的には
"${resource_type}.${name}.(リソース項目)"
になるでしょうか？

sogaoh

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

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

sogaoh

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

sogaoh

要望

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 できました。

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

fujiwara

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

fujiwara

handbook も v1.3 対応を行いました。

sogaoh

@fujiwara typo を見つけました

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

x sacle
o scale

fujiwara

修正しました。ありがとうございます!

sogaoh

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

sogaoh

まだ試していないのですが、 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

sogaoh

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

sogaoh

--debug Flag の使い方

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

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

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

fujiwara

そのエラーは(コードを文字列で検索すると) ここででています。 https://github.com/kayac/ecspresso/blob/37f1c527fe8229b455b0182907f36c8d9cbf3f7f/run.go#L96

run のオプションで --watch-container を指定していますか? 指定したコンテナ名が、タスク定義のcontainerDefinitions[].name にどれとも一致していないとそのエラーになりそうです。

fujiwara

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

sogaoh

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

sogaoh

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

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

sogaoh

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

sogaoh

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

fujiwara

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

sogaoh

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

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

sogaoh

コマンドリファレンス deploy のところか、Chapter 03 or 04 に、
DAEMON のとき desiredCount を変えても効かないことが書いてあると助かる（躓く前に思いとどまる）かと思いました。

refs

sogaoh

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 が見つかって何かパラメータが足りないのかなと思ったりしています。

から serviceRegistries で検索した周辺のドキュメントは見回しているつもりです。

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

sogaoh

"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になりましたが。。）

fujiwara

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

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

"serviceRegistries": [
    {}
]

sogaoh

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

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

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

sogaoh

ecspresso [create|run] の ECS Exec 対応はいつごろを想定されているでしょうか？

fujiwara

https://github.com/kayac/ecspresso/pull/259 こちらの動作確認ができたのでmergeしました。
service definition に "enableExecuteCommand": true を追加して create / deploy / run ができるはずです。
Nightly build で確認できます。https://github.com/kayac/ecspresso/releases/tag/v20210326-6c547af

sogaoh

v1.5 系の対応が handbook に反映されるのはいつ頃でしょうか？

sogaoh

2021/5/15

sogaoh

CodeDeploy 利用時の ecspresso rollback 挙動メモ

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

fujiwara

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

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

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

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

sogaoh

昨日まで問題なく行えていた 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 ? からのレスポンスなのでしょうか？

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

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

sogaoh

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


❯ 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

sogaoh

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

fujiwara

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

maaaato

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

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

ecspresso version
ecspresso v1.6.2

fujiwara

報告ありがとうございます。修正しました！

maaaato

ご対応ありがとうございました！

su8

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

対象は 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 というツールの使い勝手もさることながら、ガイド本もとてもよかったです。
お手数ですが、ご確認宜しくお願いいたします 🐰

fujiwara

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

su8

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

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