ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

現場感とマネジメント

マネジメントの技術の1つとして、現場にいなくてもマネジメントをする方法があることを知った。 この記事で言いたい"マネジメント”と指すものを具体的に言うとメンバーの状況把握や評価の情報集め、チームの状態を把握する、問題を把握する、みたいなところを指す。

こういったものを知るには、自分が直接「現場」(=チームのミーティングや作業に立ち会うなど)に行って直接収集する方法と、他者を通じて収集する方法がある。 後者は、メンバー1人ずつと 1on1 で話すことでもいいし、別のマネージャから見えているものをヒアリングする、別のメンバーから聞く、などの方法がある。

マネージャはなんらかの意思決定者・責任者であることが多く、放っておいても多方面から話がきやすい構造になっているのでミーティングが増えやすいというものがある。 そういう状況を考慮すると、チームを前に進めるために常に自分がいなければいない状況をなるべく少なくするほうが利口だと思うだろう。

1on1 では驚くほど多くのことを知ることができるな、というのが今複数チームをマネジメントをしていて思ったことだった。 ましてや僕は今片方のチームでは"落下傘マネージャ" = そのチームにメンバーとしての期間を経ずにいきなりマネージャになった身であり、現場の情報を把握する数少ない、確かな情報源の1つであった。

でも、ここで、1on1 でわかるから十分だな、と一瞬なりそうになったのだが、やっぱりそれでは良くないな、と思い直すことになった。

1つは、1on1 の時間の使い方について。 このような使い方だと「マネージャの情報収集のため」が第1目的になる。さらに現場にいないのであれば報告する情報量も増え、メンバーにとっては下手すると「業務報告」の場になりかねない。 別にそういうマネジメントスタイルが良くないわけではない。1on1 を頻度高くやっているのであればそれでもいいのかもしれない。 僕の場合は複数チームのマネージャをやっていることでミーティングの時間が物理限界になっていることもあり、1on1 は直属のメンバーでも基本的には隔週としている。 隔週の1on1で業務報告で終わるのはイマイチだと僕は思う。1on1 はメンバーのための時間である。

マネジメントや 1on1 への期待値を話した時、あるメンバーから「業務の共有よりは技術の深い話をしたい」ということを言ってもらった。 1on1 への期待値は人によって違って良いのだが、業務報告よりは〜という需要はあるのだな、と思い、1on1 に情報収集を頼りすぎてはダメだ、と思った。

もう1つは、必ずしも全ての人が 1on1 で正しい情報を届けられるとは限らないということ。 「業務報告」スタイルを取っていたとして、その情報が過不足ないかどうかはわからない。 戦略策定や組織課題の把握、人事評価のインプットに足りうる情報が揃うのかどうか、それを正しく言語化できるのかどうか、そもそも伝えてくれるかどうか、というのは人による。

現場にいるからこそできる 1on1 での会話というものもある。 実際僕はチームのスクラムセレモニーだったり、チームミーティングのほとんどに出るようにしている。(細かい技術的な会話はもちろんメンバーに任せているが) そこで見えるもの、あった出来事をもとに会話を深めて行けるように思う。

現場に出るにも、頻度高く1on1するのも、どちらも同じ「時間の割り当て」 = マネジメントであるから、どの選択をするかそれ自体からマネージャの仕事であり技術である。 今のところ僕はそれをどちらかに極端に振らず、出るミーティング、出ないミーティングの期待値を合わせながら、1on1 を適切な間隔で行うことで、1ヶ月と少し経った今なんとかやっていけていると思う。

いよいよ残るは「技術」である。エンジニアリングマネージャなのだから、ピープルマネジメントは上記のようにできたとして、エンジニアリングをマネジメントするには技術に習熟する必要がある。 期初のマネジメント(9月〜プロダクトの背景、組織の状況把握 / 10月〜戦略策定、メンバーとの関係構築 / 11月〜 ミッション策定)を経て、ようやくソースコードを読み始めることができてきた。 技術課題を正しく理解し、正しく解決できるようにするには伸びしろしかない。別の分野を深く知ることは今回チャレンジしたかったことの1つなので、今すごく前向きな気持ちでいる。

キャリアを考える

妻の意向で FP さんに相談する過程で、今の会社にいつまでいますか、とか、年収のピークはどのぐらいですか、と問われることで、あらためて自分のキャリアが自分あるいは家庭のライフプランの大きな変数なんだな、ということがわかった。

 

先のことはわからない、の一辺倒ではダメで、そこそこの不確実性の低減をした上でローンとかいうリスクを取る、ということをしなければならんのだなぁ、と。

 

で、今のキャリアを考えるに、エンジニアリングマネージャー、所属組織でいうところのミドルマネージャーというか、その次、となるとさらに上のマネジメントをやるか、プレイヤーに戻るか、が大きな2択としてある。

 

エンジニアリングの世界に身を置くなら、どこかのタイミングでプレイヤーに戻ることはあると思うし、そうしたいと思う。

 

今のところマネジメントという新しい領域を学ぶのが楽しいので、しばらくは続けたいし、マネージャーオブマネージャーだとか VPoE だとか CTO だとかのポジションはそもそも機会を得られる人が少ないのでやれるならやってみたいと思っている。

 

ソフトウェアエンジニアリングを出発点に持ちつつ、いつかは経営やってみたいなと思っている。なぜなら一番潰しが効くから…。それに、経営がうまくいかないとエンジニアリングをやることもできないから。

 

こういうのは多分発信した方がうまくいく。マネジメントをはじめてまだ1年。最低2年はやると決めた。そしていま新たに Web Dev のほうも兼務した。寿命がさらに1年伸びた。1年で、どういう世界なのかだいたいわかった。そこそこやれる術も手に入れた。そろそろその次を見据えて行動したり、その上での仕事をデザインしたい。

 

次の1on1で上司に、次のポジションに対する自分の能力/Capabilityのdiffはなにか、それを埋めるためには何をすればいいかの話をしようと思う。自分でもだいたいわかっている。

 

---

 

嵐のような毎日を送っている。最初はとても不安だったが、この1ヶ月なんとかやれている(と思う)。やってやれないことはない、そうやってチャレンジしてみて、それをみんなが受け入れてくれたことに感謝している。

 

次へ、もなにも今の半年走り切れるかどうかもあやしい。知らないことばかり、やること、やらないといけないこと、山ほどある。だけれど、与えられた責務はバッチリ果たしながら、次への種も蒔いていきたい。ようやくそう思えたので、元気です。あとやっぱり生き急いでるな。

 

やらないことを決めて発信する

ここ最近ずっとやらないことについて考えている。

期待値調整といえばそれまでだが、やらないことに向き合ったことにより、やることにフォーカスできた、というのとはちょっと違う感想を持った。

自分がやらないことは、誰かがやることである可能性が高い。もちろん、自分もやらないし、誰もやらないということもあろうが、やらない"コト"に対して、じゃああなたがやらないならそれはどうするの?ということに向き合ったというか。

そして、やることとやらないことを発信するだけでもまだダメで、「なぜそう思うのか」まで付加しないと納得感は得られない。資料を準備して、話してみて、個別にフィードバックをもらって、なるほどそう思うのか、そう伝わるのか、ということがわかって、さらにブラッシュアップして文字通りの"期待値調整"が完了する。

「やること」を言うだけではダメで、それってどういうふうに、どの範囲で、何のためにやるんですか?の説明が足りてないと混乱を招く。 「やらないこと」を言うだけではダメだ、そのやらないことは誰にどういう形で期待するのかを明確にしないと不信感をもたらす。

「暗黙のやらない」よりはマシだが、やらない宣言に加えて、やらないことをどう「Manage(なんとかする)」しようとしているんですか、というところまで期待値を説明しないといけないんだなということがわかった。

Web Application 開発の EM を兼務することになった

なった。10月から。

ちょうど1年前、元々所属していた SRE Team の EM になった。1年間、SRE Team のマネジメントをしつつ、SRE Team が活躍できる機会を提供し続けられるように、どちらかというとユーザーでもある開発チーム、あるいは開発部全体のことに目を向けていた。開発チームがチャレンジングなことをしようとすればするほど、SRE Team もよりチャレンジングな課題に挑戦できるはず。現状と未来、両方を見つめてやれることをやってきた。

SRE Team は開発チームが作るシステムが安定稼働できるよう、開発チーム自体のシステムの Controlability を高めることや、それに関連する開発者生産性を高めることをミッションにしている。

つまり、ユーザは開発者である。Platform もプロダクトとして考えると、ユーザのことをよく知る必要があるし、ユーザーからフィードバックを得る必要がある。今その Capability をチームとして得られるよう、サーベイやペアプロなどあらゆる方法を試し、獲得しつつある。

僕自身、所属組織の開発者の立場になったことがない、ということがずっと引っかかっていた。一時期は開発チームへ留学をしたいと言ったこともあった(結果的に自身の決断で当時はそれを選択しなかった)。ユーザの立場になったことがない状態でユーザが望むものが本当に作れるのか。目隠し状態で挑んでいるような、そんな気持ちに定期的になっていた。

だから、実際に自分が飛び込んでしまう、という方法を、兼務という形で取ることにした。自分で希望した。たまたまポジションが同じタイミングで空いた。


...というストーリーに SRE Team の立場から言うことはできるが、実際はもっとパーソナルなところから出発した。自分のキャリアをこの1年考えていた。

僕はいつも次どこにいくか、しか考えないようにしている。10年後どうする、20年後どうする、と言ってもうまく描けないし、そうやって間を埋めて計画的に動けるならいいけれど、明確な次があってそのために必要なことにフォーカスする、あとはどういう選択肢が出てくるかはわからんし、その時考えればいい、という考えだ。

SRE Team のメンバーだった時は、所属会社のキャリアパス的にも Engineering Manager か Senior Software Engineer の2択で、どちらもなれたらいいなと思いつつ、興味があったのは EM のほうだった。3年半やって、EM になった。はて、その次は。

そういった中、たまたま所属会社で「キャリア申告/キャリア面談」という制度があることを知った。案内のメールが来て、軽い気持ちで書いてみて、軽い気持ちで「面談を希望する」というチェックボックスにチェックをした。その後設定された面談が僕の今回のキャリアを決めた。

この面談は意図的に直属の上長ではない、斜めの関係の方がアサインされる。まったく別の領域の、上長相当の方だった。その方はかつての同僚から良い評判として名前を聞いたことある方だった。

1時間の面談。事前に相談内容をドキュメントにまとめておいたのが功を奏して、事前に読み込んできてくれていて、短い時間ながらも単刀直入に結論をアドバイスしてくれた。「プロダクト開発の EM を経験したほうがいい」ということだった。

次のキャリアといっても行き先はいろいろある。マネジメント方向で部長・開発部門責任者(Director, VPoE)の方向、THE ENGINEER/MANAGER PENDULUM にあるように、振り子のようにメンバーに戻る方向。あるいは身を置く場所・領域を変えるという方向。

僕個人の立場に立った視点と、所属会社における立ち位置という視点の両方でアドバイスをくださり、それはとても納得感のあるものだった。

SRE や Security といった横断領域に比べて、世の中には圧倒的に事業会社が多い。事業に(より今より直接的に)貢献するという経験があるかないかは大きい。

そして僕自身、ずっとやりたかったことは ビジネスにエンジニアリングで貢献する ことだった。もちろん SRE だって貢献している。しかし、そこの感覚の遠さというのがずっと僕自身の引っ掛かりだった。それを得ることは、SRE だろうとプロダクト開発だろうと、企業組織で生きる中で大きな経験になると思った。

blog.chaspy.me

...ということで"他人のアドバイスは全部実践する"で生きてる僕としては「はい!やります!」となり、金曜にした面談の翌週火曜に直属の上長にキャリア面談を申し込み、内容の共有と、そういうポジションはないか、と相談したら、10月から空くかも、となり、その領域のマネージャと相談し、やることになった。

面談したのは7月後半。8月の前半にはやる方向で固まり、8月後半には体制面含めマネージャたちと相談しながら準備し、9月に社内の関連メンバーに内示をした。

トントン拍子だね、とも見える。自分でももう少し批判的な意見があるかと思ったが、上長、マネージャ、メンバーみんな(懸念が0ではもちろんないにせよ)基本スタンスとしては応援してくれた。


「兼務」という言葉にポジティブ成分とネガティブ成分、どちらが強いかというと、どちらかというとネガティブを感じる人が多いんではないか。僕もそう思う。というのも、時間は有限、身体は1つ、コンテキストスイッチに人類は弱い、となると兼務するとパフォーマンスは落ちそうだ、と考えるのは自然だ。

そんなことはわかってる、何度も自問した。ただ、やってできないこともなさそう、ぐらいには勝機もあった。というのも、もともと担当チームのことはチームに任せるマネジメントスタイルで、僕自身は別のことをやっていたので、身体の予算的には賄えるのはでないか、と。

これは半分正解で、半分間違いだった。1つのチームを見て、自分が他のことをやっている状態と、複数のチームをみる状態というのは違う。明確にマネジメントのスタイルを変えないといけないことに9月終わりにギリギリ気づいた。エンジニアのマネジメントキャリアパスでいうところの 5章 チームの管理 から 6章 複数チームの管理 にステージが変わる。

www.oreilly.co.jp

今まで以上に「何をやらないか」の期待値調整をすることが求められる。幸い、新しく担当するチーム含め、チームの運営自体はマネージャがいなくても回るようになっているし、メンバー皆優秀で信頼できる人たちばかりだ。そういう状況で、EM として何をやって、何をやらないか、その戦略をこれまで以上に考えるいい機会になった。

SRE Team については一部の業務やミーティングなどを Team Lead を立ててお任せする方針を立てて、可処分時間が少ない中、自分がボトルネックにならないように調整した。 新しいチームも近いスタンスで関わる期待値を言語化、すり合わせをしていく予定だ。

この話を別のマネージャと話した時、「純粋なマネジメントというスキルを学ぶ機会になりそう」というコメントをもらってなるほどなと思った。もちろん会話可能・評価可能にするためには Web 開発のスキルも一通り抑えるつもりではあるものの、そのスキルを発揮しにいくわけではない。まさに今考えているようなことを考えざるを得ない状況になったわけだ。


なぜだかマネージャというロールに暗黙の期待値の高さみたいなものがあるような気がする。僕自身も自分の上長に対してあると思う。マネージャはロールである、といいつつも、実際は評価者被評価者という利害関係がある。そして責任者でもあるわけなので、それはそれなりに期待値があるよな、というのもわかる。

ただ、実際にその立場になってみると、頭では理解しながらも不安がある。しかし不安など言っても責任もある。そんなことは言ってられない。やってやろうという気概もある。ここで何食わぬ顔で一見普通に取り組んでしまうと、マネージャはやはり超人なのである、到底やれる気がしない、などと思われるのも不本意でもあり、表現に悩ましい。

一見わかりづらいマネージャの仕事、酸いも甘いも発信していくしかないのだ。


ポジティブな話で締めよう。

SRE Team の状況はとても Exciting である。人数自体を一定に保ったまま、環境の変化に対応し、「Team としての Capability」を確実に向上できていると考えている。これはチームのパフォーマンスが上がり続けていることに他ならない。「個人の実力」を最大限に活かし、イノベーションを起こしてもらいながら、チームとして発揮する価値の総体を大きくしていく、そういったマネジメントの醍醐味みたいなことがどんどんできていくのがとても楽しいし、嬉しく思う。

新しく入るチームは元々担当 EM がいなかったこともあり、自律的に動けており、こちらも個々人のプロフェッショナルな部分を発揮しつつ、全員がチームへのリーダーシップ・フォロワーシップを発揮する、ということができていて、(チーム内のことについては)本当に何もすることがないな、という状況で驚いている。

新しく入る開発領域は、内部で3チームに分かれていて、そのうちの1チームを担当することになる。EM としてはこの3チーム全体のことを考える必要がある。また、ビジネスの状況としても新規開発に対する投資も今後予定されており、それに対して既存の課題をどう解決しながら前に進んでいくのか、まさにビジネスに対してのエンジニアリングの貢献を考えざるを得ない状況にある。もう1名の EM とは得意不得意がいい感じにバラけており(多分)協力しながらより良い世界を作っていきたい。


というわけでマネージャ2年生、まだまだやれることがあるので頑張ります。飲みに誘ってください。

入社してから4年

前回

blog.chaspy.me

今回は1年あかなかったね。

2022年6月20日で Quipper に入社してから4年が経ちました。

Blog

5本。ぼちぼち。

blog.studysapuri.jp

blog.studysapuri.jp

blog.studysapuri.jp

blog.studysapuri.jp

blog.studysapuri.jp

登壇

4本。がんばった。

何をしていたのか

2021年10月から SRE Team の Engineering Manager を務めている。現在10ヶ月経過した。

基本的にはマネジメントに徹していて、ハンズオンはほとんどやらず、優秀なメンバーたちに任せている。

ミッションマネジメントを通じてチームで課題になっている部分を改善し、Platform は大きく改善されている。

SRE が扱う領域以外だと、ICT 環境の改善、プロダクト開発部の組織開発・改善、プロダクト開発部の技術戦略と外にも手を伸ばした期間だった。

Product Security Engineering のポジションをオープンし、1名採用できたのは(運が良かったのが大きいが)大きな成果だった。

brand.studysapuri.jp

前回"今後やること"に書いてあった以下の3つだが、

  • Product Security Engineering Team の立ち上げ
  • プロダクト開発組織をより Sustainable にする
  • ビジネスにエンジニアリングで貢献する

1つ目はできた。2つ目も組織課題を実際に解決したり、それを扱うという一定の方法みたいなものは切り開けたかと思う。

去年も掲げていたけど、できていなかったというか、助走期間だった。

プロダクト開発部がいくら SLO を定めてみても、それにより機能開発と非機能開発の優先度が「数値」によって、異なる職種を通じて話し合い、変更されうる状態になっていない。

そこを変えに行く。

そのために、技術戦略グループのマネジメント/リードをして、技術的負債をコントロール化に置く活動を支援したり、自己診断能力を開発できるようにして現状把握できるようにしたりして、機能開発 - ビジネス開発と同じだけ、非機能開発や技術的負債解消活動にも説明責任が果たせるようにしていく。同じものを見て、異なるストーリーを持つ人々と、1つの目的を達成できるようにする。そのために組織も技術も両方見て世界を変えていく。

今のところは、これが無理だと諦めた時に転職を考えるのかなと思ってます。これをやれると思ってるうちはがんばります。

3つ目についてはできていないというか、方向を変えた。

長らくやってきた SRE という活動において、最も重要なことは、問題を発見し、改善し続けられる文化を作ることだと気づいた。SLI/SLO がバックエンドの指標になっているから E2E で見ないとねとか、Four Keys のリードタイムやデプロイ頻度を伸ばすとか、いろいろ細かいことは考えたけど、細かいことはどうでもいいなと思った。

技術戦略という活動、SRE という活動を通して、数値はもちろん大事だが、フィードバックを得て、改善し続けるということが本質だと気づいた。SRE Team としては開発チームから Feedback を得る、Feedback Cycle を回す、ということを重点テーマとして今期は活動している。

そして"ビジネスにエンジニアリングで貢献する"という点は、まだまだ道半ばだ。していないことはない。前には進んでいる。諦めてもいない。

次の半年は別のチャレンジをして、引き続き取り組んでいく。

今後やること

大きくは変わらない。

  • 開発者生産性を大きく改善するための Platform と文化を作る
  • Product Security の実践
  • ビジネスにエンジニアリングで貢献する

おわりに

楽しくやりましょう。次はいよいよマネジメント3(半)期目です。

今後もよろしくお願いします。

ArgoCD における secret management

argo-cd.readthedocs.io

これを読んだメモ。

Bitnami Sealed Secrets

SealedSecret という CRD に encrypt value を書いて、これを git にホストする。 kubeseal という components がこれをもとに decrypt して k8s secret を生成する。

アーキテクチャはシンプルで、かなり汎用的に使える Kubernetes の secret management tool のようだ。

GoDaddy Kubernetes External Secrets

Deprecated This project has been deprecated. Please take a look at ESO (External Secrets Operator) instead https://github.com/external-secrets/external-secrets

PR 出した。

github.com

External Secrets Operator

github.com

外部のサービスに保存されている Secret を API で取得して kubernetes secret を inject する。

external-secrets.io

resource model に high-level architecture がのっていてわかりやすい。

external-secrets.io

secretStore というリソースが Provider になっている。

汎用的なので複数の Secret Provider を使うなら良い選択肢だろう。

Hashicorp Vault

www.vaultproject.io

kuberentes はこっち。

www.vaultproject.io

正直よくわからなかった。

learn.hashicorp.com

を見るに、http server として vault server が立って、そこに secret を問い合わせる雰囲気があったが、それであれば application に手を入れないといけなくなるのでよくわからない。

Banzai Cloud Bank-Vaults

github.com

Hasicorp vault を使ってなんとかする、ぐらいしか読み取れなかった。

Helm Secrets

github.com

README 眺めて結局何ができるのかよくわからず。

Kustomize secret generator plugins

github.com

これもよくわからず。kustomize の secret generator を go の plugin で使う例を書いてるっぽいが...

aws-secret-operator

github.com

AWS secrets manager から値をとりに行って、AWSSecret という CRD を通じて実際の k8s secret を生成してくれる。

AWS にしか secret がないなら良い選択肢。

KSOPS

github.com

kustomize plugin.

SOPS というのは暗号化のためのツール: Secrets OPerationS

github.com

あんまりよく掴めてないけど、ArgoCD にアドオンして、kustomize を紐解くときの処理に secret を作れるようにするってことかな...

argocd-vault-plugin

github.com

document

argocd-vault-plugin.readthedocs.io

ArgoCD が secret を apply するときに、 を書き換える。

proivider は AWS secret manager を指定することもでき、ArgoCD のプラグインとして動作する。

operator を稼働させなくて良い点がメリットか。

argocd-vault-replacer

github.com

こちらも vault-plugin と似ているように見える。

暗号化に hasicorp vault を使い、かつ external provider をサポートしてない点が違うかな?

まとめ

AWS Secrets Manager に Credential が格納されている場合、External Secrets Operator か aws-secret-operator か argocd-vault-plugin が選択肢になる。

別の External Secrets Provider を使いたいなら External Secrets Operator、AWS だけでいいなら aws-secret-operator。operator の管理をしたくないなら argocd-vault-plugin が良さそうである。

PipeCD で ECS を Deploy する

Deploy するアプリケーション

8080 で listen して、http request があったら hello を出力する Go のアプリを ECR に push する。

github.com

環境変数 "VERSION" を読み取って、それを出力している。

make docker で build し、make push で ECR に push する。今回はこのアプリケーションを v9 から v10 に更新する Deploy を PipeCD で行う。

PipeCD Application

simple の example を参考にした。

github.com

実際に設定したファイルはこんな感じ。

  • app.pipecd.yaml
apiVersion: pipecd.dev/v1beta1
kind: ECSApp
spec:
  name: simple
  labels:
    piped: chaspy-local
    owner: chaspy
  input:
    serviceDefinitionFile: servicedef.yaml
    taskDefinitionFile: taskdef.yaml
    targetGroups:
      primary:
        targetGroupArn: arn:aws:elasticloadbalancing:ap-northeast-1:655123516369:targetgroup/hello8/71d4c3025713a1ee
        containerName: hello
        containerPort: 8080
  description: |
    chaspy test
  • servicedef.yaml
cluster: arn:aws:ecs:ap-northeast-1:655123516369:cluster/pipecd-dev3
serviceName: hello
desiredCount: 2
deploymentConfiguration:
  maximumPercent: 200
  minimumHealthyPercent: 0
schedulingStrategy: REPLICA
# CAUTION: To enable PipeCD controls the deployment
# DeploymentController of type EXTERNAL is required.
deploymentController:
  type: EXTERNAL
enableECSManagedTags: true
propagateTags: SERVICE
launchType: FARGATE
networkConfiguration:
  awsvpcConfiguration:
    assignPublicIp: ENABLED
    securityGroups:
      - sg-eee24b8b
    subnets:
      - subnet-fb7f36d3
      - subnet-5118f008
      - subnet-1803d46f
  • taskdef.yaml
family: hello
executionRoleArn: arn:aws:iam::655123516369:role/ecsTaskExecutionRole
containerDefinitions:
  - command: null
    cpu: 100
    image: 655123516369.dkr.ecr.ap-northeast-1.amazonaws.com/hello:v9
    memory: 100
    mountPoints: []
    name: hello
    portMappings:
      - containerPort: 8080
    environment:
      - name: VERSION
        value: "9"
compatibilities:
  - FARGATE
requiresCompatibilities:
  - FARGATE
networkMode: awsvpc
memory: 512
cpu: 256
pidMode: ""
volumes: []

Taskdef や Servicedef は AWS でのそれぞれの json に対応している。

pipecd.dev

docs.aws.amazon.com

docs.aws.amazon.com

最初わかりづらかったので Document に PR を送った。

github.com

Control Plane 側 Application を登録する。

これは quick sync を一度したあとの状態。

f:id:take_she12:20220410230525p:plain

piped

なお piped には lambda と同様、credential file を読ませる必要がある。

apiVersion: pipecd.dev/v1beta1
kind: Piped
spec:
(skip)

  cloudProviders:
    - name: ecs-dev
      type: ECS
      config:
        region: ap-northeast-1
        profile: default
        credentialsFile: /etc/piped-secret/ecs-cred

(skip)

helm で deploy する。

#!/bin/bash
set -x
helm repo add pipecd https://charts.pipecd.dev
helm install piped pipecd/piped -n pipecd
helm upgrade -i piped pipecd/piped \
    --version=v0.27.2 \
    --namespace=pipecd \
    --set-file config.data=piped.yaml \
    --set-file secret.data.ecs-cred=ecs/credential.txt

なお credential file はこういう形式である必要がある。

[default] aws_access_key_id = your-access-key-id aws_secret_access_key = your-secret-access-key

Deploy

Image tag を更新する PR を作成

f:id:take_she12:20220411063040p:plain

Merge すると Deploy が完了。

f:id:take_she12:20220411062738p:plain

Task Definition が更新された。

その他の Deploy 方法

今回は単純な "simple" のケースを試したが、PipeCD の Pipeline の機能を使って、Wait Approval - 承認を挟んでからのデプロイや、Canary Release もできる。

Target Group を複数用意することで Weight を変更して実現している。

pipecd.dev

PipeCD 以外の ECS Application の Deploy 方法

手を動かしていない前提で、いくつか選択肢をあげてみる。

AWS CLI

task definition で新しい revision を作成し、service からの参照を変えれば良い。

docs.aws.amazon.com

docs.aws.amazon.com

code deploy を組み合わせることもできるようだ。

docs.aws.amazon.com

AWS Code Deploy

aws.amazon.com

canary release をサポートしているが、割合は用意されたもののみのようだ。

GitHub Actions

CI/CD に組み込むことを考えると GitHub Actions は有効な選択肢の1つ。便利な Action が既にある。

github.com

ecspresso

github.com

基本的には AWS SDK の薄いラッパーだが verify や diff など便利なサブコマンドが提供されている。

Terraform

taskdef と servicedef を更新すれば良いので Terraform でも可能。

registry.terraform.io

まとめ

PipeCD で ECS Application を simple にデプロイする方法を試した。

Piped と controll plane の準備が必要な点は他のデプロイツールにより手間がかかるが、デプロイパイプラインを柔軟に組み立てられる点、特に Canary Release を宣言的に行える点は他のツールにはない差別化ポイントである。