こんにちは、AWSチームの大澤です。
今回は、8/8 (火)に行われた、JAWS-UG コンテナ支部 #24 ecspresso MeetUp に参加してきましたので、
そちらのレポートをしたいと思います。
イベント概要
日時: 2023/08/08(火) 18:30 〜 21:00
場所: AWS Japan 目黒オフィス 目黒セントラルスクエア
テーマ
ecspresso MeetUp
ecspresso作成者のfujiwaraさんから基調講演を頂き、 LT枠としてecspressoの活用事例や、 ecspressoを活用したことによる感謝の気持ちを述べていくぅ！
な趣旨で開催いたします！
Speaker
- fujiwaraさん (fujiwara (@fujiwara) / Twitter）
- 松木 雅幸 さん（songmu (@songmu) / Twitter）
- 土屋 陽輝 さん（つち (@hrktcy) / Twitter）
- 香西 俊幸 さん（𝕋𝕠𝕔𝕪𝕦𝕜𝕚 𝕏 (@Tocyuki) / Twitter）
- 山原 崇史 さん（T. Yamahara (@shonansurvivors) / Twitter）
- laughk さん（Kei IWASAKI (@laugh_k) / Twitter）
- こはる さん（こはる (@cohalz) / Twitter）
- 石川 湧馬さん（Yuma Ishikawa (@yuma_katameoome) / Twitter）
- onigra さん（𝘽𝙤𝙣𝙟𝙤𝙪𝙧 (@onigra_) / Twitter）
アーカイブ
Youtube上にて、アーカイブ動画をご覧いただくことができます。
レポート
基調講演 隙間家具職人が考えること
- トピック
- 隙間家具OSSについて
- 名前について
- 設定について
- 作って使ってメンテする
- 隙間家具OSSについて
- AWS dev day 2019 でも発表
- マネージドサービス、コンポーネントの隙間を埋めて便利にするもの
- マネージドサービスが時間と共に成長して不要になったら取り外す
- 隙間家具とGlue
- 複数のコンポーネントの間を繋ぐもの
- 隙間家具=隙間に入れて便利になるもの
- クラウドと単体ソフトウェアの進化
- クラウドのマネージドサービスはより周辺と繋がる方向に進化しがち
- ex) MySQLとAmazon RDS for MySQL
- 例えばログの取り扱い
- MySQLのログ=ファイルに書き出す
- RDSのログ=mySQLのログを取り出すAPI
- 今はCloudWatch Logsに送れるように進化
- 例えばログの取り扱い
- クラウドのコンポーネントの進化
- 需要があるものは実装される
- 進化する
- 隙間が減る
- 隙間を密に繋いでしまうと取り外しに苦労する
- 取り外しできるパーツを入れておいて、必要なくなったら外す
- Glueではなく隙間家具にする理由
- Glueなコードはプロジェクト固有の事情に密結合しがち
- あるプロジェクトのリポジトリの中に置かれる
- コードの責任分界点が曖昧
- ex) APNs Push通知送信サーバ
- カヤックでの昔話
- 単体ソフトウェア/ライブラリとしてOSSにする
- 各プロジェクトに依存するコードは入れない
- ecspressoは隙間家具なのか
- Amazon ECS用デプロイツール
- ecspresso → ECSという一方的な関係
- Terraform、CFn、CDKでコマ割りが効かない部分を埋めるツール
- Amazon ECS用デプロイツール
- 名前の話
- 最初に名前を考える
- 名前がないと書き始められない
- 良い名前をつけるのは難しい
- 良い名前の条件
- 名が体を表していること
- 関連するコンポーネントを連想しやすいこと
- 覚えやすいこと、typeしやすいこと
- 既存のソフトと被らないこと
- 名前の考え方
- だいたい連想ゲーム
- ソフトウェアの責務から考えたり
- deployツール → deployの関連後
- 英語ならシソーラスを使うと便利
- 具体例
- デプロイツール fujiwara/stretcher
- pull型deploy (s3からtar.gzを取得して展開みたいなのを実現する)
- 具体例2
- lambroll
- Lambdaデプロイツール
- Lambdaを入れたらわかりやすい？
- Lambに何かくっつける？
- Lambdaデプロイツール
- lambroll
- 気をつけること
- 名前被り
- GitHubで検索してみる
- 有名なやつと被っていないかを確認する
- 変な意味がないか
- Googleで画像検索してみる
- 画像の方がパッと見てわかりやすい
- そのままの名前をつけることも
- kinesis-talif
- tfstate-lookup
- これはわかりやすい名前かと….
- ちなみにecspresso
- ECSをもじった
- espressoはいっぱいある
- ecspressoはなかった
- 連想しやすい、覚えやすい
- 呼びやすい、タイプしやすい
- 最初に名前を考える
- 設定について
- 理想=ゼロコンフィグ
- 何らかの値を渡す必要がある
- 設定ファイル vs Flsg vs Env
- コマンドライン引数だけで済むか、設定ファイルがいるのか
- 設定項目が単純、少数がflagかenvで良い
- ある値を設定したい場合
- 設定ファイルの値
- CLI Flagの値
- 環境変数の値
- 設定の指針
- 設定ファイルを実行時に変更したくならない値にする
- 小規模なうちは問題ならない
- 規模・ユースケースが増えると混乱しがち
- 設定ファイルのフォーマット
- 色々ある
- 好みでも良いが、PlainなJSONを扱えると良いのでは？
- 人間が描くには辛い
- yamlなどで管理 → jsonに変換
- この経路があると工夫しやすい
- 設定ファイルは必要悪
- 何も書かないのが理想
- デフォルトがいい感じ、変えたいところだけ変えれば良い
- 自動生成を検討する
- ecspresso init
- 指定したクラスタのサービスを参照して、設定ファイルを自動生成する
- 生成しただけの状態で、ecspresso deployは完全に動作する
- 変えたいところだけ変えてみる、テンプレート化してみる
- 作って使ってメンテしていくこと
- コードはできるだけ書かない方が良い
- 書いたものは資産にも負債にもなる
- 適切な道具を適切に使う。必要なら道具を自分で作るのがプロフェッショナル
- コードはできるだけ書かない方が良い
- 自分で設計したシステムをメンテする経験
- システムをシンプルに作ってシンプルに保つ力は経験で得るしかない
ecspressoがもたらしたものとエスプレスタック
- ecspresso
- ECS向けデプロイツール
- 絶妙な責任分界点が素晴らしい
- 2019年に導入してみた
- fujiwaraさんとはカヤックの同僚でISUCON仲間
- fujiwaraさんはインフラより、松木さんはアプリケーション寄り
- fujiwaraさんの作るものは信用している
- 思想がマッチしている
- 強調しやすい
- ユースケースがあっているし、コメントも通りやすい
- fujiwaraさんは最強のSREイネイブラー
- SREを強力にイネーブル面としていた
- SREを簡単にする
- レールを敷く
- アプリ開発者がSREingをリードする
- SREを強力にイネーブル面としていた
- SREのチームトポロジー
- ストリームアラインドとしてのSRE
- イネーブルメントとしてのSRE
- プラットフォームとしてのSRE
- 個人的には少しSREとは違うと思っている
- IaCとアプリケーションの責任分界点
- Terraform/CDK管理リポジトリ
- アプリケーション管理リポジトリ
- アプリ動作に関する設定をアプリケーション側で管理するのが困難
- ecs-deployを2019年は使っていたが、コンテナイメージをすげかえることしかしない
- コンテナイメージをビルドするだけでは、運用に関する設定が行えない
- 自分で作ったものを動作させて運用するということ
- 理想は間違いなくそうで目指したい
- ecspressoが見事だった点
- タスク定義、サービスの管理をIaCから分離してアプリケーション側に移譲
- tfstate参照機能が間を埋めるものとしてうまく機能している
- ここに責任分界点を切ったところが絶妙で、類似のツールが出てこないところが体現している
- ecscheduleとエスプレスタック
- yamlでscheduled taskを一元管理、yamlはecschedule dumpコマンドでダンプ可能
- ECSchdule tsskで動かしているバッチ系のタスクをアプリ管理したい
- エスプレスタック=ecspresso + ecscheduleの構成をトリさんが命名された
- 課題
- ルール名をキーにしたことによる制約
- メンテナンス体制
- 今別のクラウドを使っている…
LT1: ecspressoを活用したCI/CDパイプラインをアジャイル開発現場に導入してみたら
- チーム構成・開発の進め方
- マトリクス組織
- 開発手法
- アジャイル
- インフラ
- ECSを採用することが多い
- 開発手法
- ドライバーとナビゲータに分かれて開発する
- エラーや問題を早期発見できる
- 個人で開発するより生産性は下がる
- devopsをアジャイルに取り入れる
- ローンチに向けての生産性向上
- マトリクス組織
- ブランチ戦略
- 各環境に反映されているソースコードの可視性が高い
- シンプルである
- 高速かつ信頼性の高いデリバリーを実現する
- タスク定義・サービスのみを一元管理
- アプリケーションリポジトリに設定ファイルを配置可能
- ecspressoを活用したCI\CDの構築
- アジャイル開発現場にもたらした恩恵
- アプリ開発に集中できる管理が整った
- 開発者のインフラに対する気嫌いを減らしてくれた
- まとめ
- ecspressoを活用したDevOpsの取り組みにより更なる成長を遂げることができた
LT2: ecspresso愛を語る
- 愛とは？
- ecspresso愛=fujiwara愛だ！
- 自己紹介
- としゆきさん
- イオンスマートテクノロジー株式会社
- CTO室 SREチーム
- イオンスマートテクノロジー株式会社
- としゆきさん
- わたしとecspresso
- タスクとサービスはecspressoでやるのが良さそうな気がしてきた
- 前職でCloudNative Daysで発表した
- いい話だった (fujiwaraさん)
- lambrollも使っている
- 初手エスプレスタック
- ecspressoについて
- ecspresso handbookに全て書いてある
- ぜひみてください！
- 読者コミュニティ完備！
- ecspresso handbookに全て書いてある
- ecspressoのここが好き
- 絶妙な管理スコープ
- 各種IaCツールと連携できる
- Terraform,CFn,CDKなど連携可能
- Terraform tfstate内の値を参照できる
- Terraform,CFn,CDKなど連携可能
- 豊富なサブコマンド
- diff
- verify
- render
- rollback
- tasks
- exec
- 隙間家具OSSという概念
- まとめ
- まずはhandbookを読もう
- ecspresso,ecstackを利用しよう
LT3: CodeBuildで動かすecspresso
- ecspressoと私
- 実務のほか、過去の登壇、ブログなどのアウトプットでも取り扱っている
- codebuild上でecspressoを動かしている理由
- CDをCodepipelineで動かしていた
- beanstalkからECSに移行することになりecspressoを利用したかった
- 関連AWSリソースの取得
- ECSの定義ファイルには以下の指定が必要
- ターゲットグループのARN
- サブネットID
- セキュリティグループID
- 可読性が落ちる可能性がある
- ecspressoのtfstateの読み込み機能を使ってARNやIDを取得
- codebuild上のAWSCLIを実行してNameタグなどを元に取得
- ビルドプロジェクトの環境変数経由で取得する
- ビルドプロジェクトの環境変数に他リソースの属性をセットし、ECS定義ファイルでセットする
- ECSの定義ファイルには以下の指定が必要
- ecsoresso rollback用のCodeBuild
- 当初
- 実行する用のbuildspecのファイルを用意しておく
- 実行は手動を想定
- 実行する用のbuildspecのファイルを用意しておく
- 懸念
- 運用になった時に、処理の詳細を知らない人は、ソースバージジョンの指定に困るかもしれない
- mainブランチ指定して大丈夫なのか？
- 運用になった時に、処理の詳細を知らない人は、ソースバージジョンの指定に困るかもしれない
- 解決
- buildspecをファイルではなくコマンドにする
- ソースバージョンを指定するフォームが非表示となり、CodeBuild実行に際し、迷う要素はなくなる
- buildspecをファイルではなくコマンドにする
- 当初
- まとめ
- codebuildでもecspressoは動かせる
LT4: ECSサービスだけじゃない！ecschedule 管理されているECSタスク定義管理における ecspresso の使いどころ
LT5: ecspressoへのコントリビュートを振り返る
- ecspressoの利用
- 2021/3ごろから本格利用
- ecspresso関連の貢献の紹介
- 2021/3から本体へのPRは9件
- v.1.5.0から
- その他に本体以外の貢献もあり
- verifyコマンドでのIAM権限の修正
- タスク実行ロールに不要な権限が必要だった
- ecspresso initでタグが含まれるように
- desiredCountがdiffに出るように
- CodeDeployでrollbackが可能に
- tfstateの値参照がTerraform Cloudに対応
- diffでunified形式が使えるように
- git diffのようなdiffが出せるように
- v2の準備が始まった際にいくつか機能要望
- ecspressoのバージョン管理問題
- Github Actionsでlatestをして
- 手元で使いたい時のバージョン管理
- 解決するために
- .ecspresso-versionというファイルを導入
- asdfでも使える
- Actionsにversion-fileオプションを追加
- .ecspresso-versionというファイルを導入
- asdf-ecspressoで読めるように
- asdf install ecspresso
- asdf install ecspressoできるように
- 2021/3から本体へのPRは9件
- OSS貢献のススメ
- きっかけ
- CI/CD改善がOSS活動になっていた
- 楽しんで追加する
- PRだけでなくIssueでも
- Issueに機能要望を書くだけでも
- 意見を表明することも大事
- Issueに機能要望を書くだけでも
- それ以外
- 使うだけでも貢献だけど
- SNSなど本人に見える場所で貢献するとなおよし
- 使うだけでも貢献だけど
- きっかけ
- まとめ
- 追加した機能の歴史を紹介しました
- これからも長く利用しましょう
LT6: ispecのエスプレスタックのご紹介！
- 初期のスタック
- terraform
- アプリの開発がさわれなかった
- 運用を考慮した設計ができていなかった
- TerraformとCIでリビジョンの違いが発生
- terraform
- ecspressoと出会う
- 運用上のボトルネックは解消
- ecscheduleともである
- ecspressoと同一の設定ファイルを読みたい
- 最終形態
- aquaでバイナリをインストール
- これからやりたいこと
- AutoScalingの設定が面倒
- Null_resourceの活用を検討
- lookup用のstateをなくしたい
- コントリビュートするしかない
- lookup用のstateをなくしたい
- Null_resourceの活用を検討
- AutoScalingの設定が面倒
LT7: ecspressoのおかげで弊社のECS移行が加速してデプロイ頻度も上がりインフラに興味を持つ若者が増えて最高でした
- 痒い所に他が届く
- 落とし所に共感することが多い
- 実績から得られた知見からなのが良い
- 落とし所に共感することが多い
- OSSに対する姿勢
- fujiwaraさんはecspressoに関してエゴサしていて、SNSの反応が早いw
- ECSに移行するきっかけ
- セキュリティインシデントとアクセス障害だった
- デプロイすると落ちてしまうという状態だった
- 移行をきっかけにインフラに興味を持つ若者が増えた
- プログラマもインフラ、運用、監視も行うことが当然の雰囲気になった
- きっかけはネガティブだったが、サービスの信頼性とインフラ、運用水準のレベルは確実に上がった
- そのプロセスに、ecspressoは不可欠となった
- ツールから文化が変わった
まとめ
今回のテーマとして、ecspressoということで、私自身がコンテナ・ECS初学者ということもあって、100%理解できていない部分もありましたが、ecspressoを通して技術的な改善のみならず、アプリ開発の方がインフラに興味を持ち、文化が変わったという部分が今回最も個人的に素晴らしいなと思った点でした。 今後も注目していきたいと考えています。
