KUOKA@mumoshuhelmfileみたいに宣言的にデプロイを順序立てる方法はFluxやArgoCDには無いものと思ってたけど、ArgoCDにはあった。Waveの使いどころは、複数のマイクロサービスを特定の順序でデプロイしたい、というような場合。waitを順番にやればいいけど、ArgoCDではどうするか。Wavesって機能でapply順を制御できるらしい。IP保持のためだけにexternalTrafficPolicy=Localを使う必要はなくなるのか。KUOKA@mumoshuアプリケーション自体のデプロイメントと、設定のデプロイメントを同時にやろうと思えばやれちゃう点も一緒かな。アプリケーションの修正に対してはCodeDeploy、設定の修正に対してはAppConfigデプロイをトリガするようなデプロイパイプラインを組んでおくとよさそう〜。KUOKA@mumoshu「CodeDeployとかぶってるやん」と思ったけど、設定値のデプロイにはAppConfig、コードの配布にはCodeDeployというふうに使い分けるといいのかなぁ。K8sでいうConfigMapボリューム感ある。ポーリングではなくsubscribe的な感じではありますね。encodingを使ってるようで、goだとこんな感じでsubscribeするような使用イメージになります。あったら便利そうですね〜!WatchというAPIがあって、それ使うとDeploymentなどに対して発生したイベントをkubectlやclient-goで受けることはできます。KUOKA@mumoshu「Stagingを社内ユーザからのみアクセス可能なA/BテストのCanary」のように使ってると。Alarm起因しかできない(だろうなとは思っていたけど)のは前提として。alarm)にもちゃんと対応してるぽい。Flaggerと同じことができるという理解でいいか。3以降はhelmコマンドを呼ぶ形にしちゃいました・・。2にしても3にしても、あまりgoライブラリとして使いやすいインタフェースではないように思うんですよね。あと、helmのバージョンが上がるたびにgo.mod更新とかもしんどいですし・・。あ〜prereleaseいいですね!semtagはprerelease対応してないです。binaryとして配布されているほうが利用しやすいというのもあります。(https://github.com/b4b4r07/git-bump)、最高に便利。使ってたけど、移行しよう。terratestはどうですかね。ndjsonでログとれるようになるぽい。Gitレポジトリにいれてるappspec.ymlをそのまま使いたい、ということならBuildArtifactを指定して、ファイル名は省略する、ってことでいいんじゃないかと。ECSでいいんじゃないかと。providerは用事がないような気がする。Secrets、alb-ingress-controllerを使う前提なのと思ったけど、選べるものが多すぎて難しく考えすぎちゃう、ECSと同じ要件を満たすためにK8sで色々頑張りすぎる余地があるのが相対的に問題になるケースもあるのではって意図なら、わからんでもない。手順をなぞっててCertificatesページにアクセスしたときに気づいた。!ぼくのCrossoverなんかだとTrafficSplitしか対応してませんが、対応してる実装であればそういった機能をサポートするために使えます。Flaggerは元々Istioとしか連携できなかったのですが、Linkerd2のためにSMIに対応しました。Flagger以外だと僕も事例は知らないですね。Gatewayやサービスメッシュとは比較的簡単に連携できます。Flaggerのようなサービスメッシュの利用側からみて、SMIにさえ対応できれば様々な実装に対応できる、というのがメリットの一つかなと思ってます。「サービスメッシュの共通API」をCRDの形でいくつか独自に定義したものです。TrafficSplitというAPIはこんなCR(D)になってます。https://github.com/deislabs/smi-spec/blob/master/traffic-split.md#workflow...API(CRD)しか定義してないので、それ単体では何もできなくて、実装は各自つくりましょうという感じです。KUOKA@mumoshuアプリChartのSubchartとしてIstio設定Chartを呼んで、Values経由でアプリ側にいじってほしい設定だけをいじれるようになってる。Meshそのものを採用しないとか、そういう話ありきな気はした。Environmentsを提供するような社内向けWebサービスでIstioを使ってる、ということかな。K8sに移行するとしても、それがEnvoyベースな限り、ここまで作り込んで得た知識や経験は無駄にならなさそう。KUOKA@mumoshu自分でつくったほうが逆に工数が読みやすいとか、自分で作る過程で運用に対する自信が持てる、みたいなケースはありそう。Envoyでやって成功だった、といえるような気もする。KUOKA@mumoshuダミーEndpointが必要な件は、ヘルスチェックをConsulがやってるのと相性が悪いって話なのかな?いまいちわかってない。Cacheにして、Consulからのヘルスチェックはしないように、とかできないんですかね。ConsulにEnvoyでクライアントサイドLBを足す構成、無駄がなくて美しいな、って思う。envoy.yaml」から初めて、「xDS(gRPCじゃなくて設定ファイルのほう)」でDRYにしていく流れ、めっちゃわかりやすかった。頭ではわかってたつもりだけど、実際手を動かしてやったことはなかったので、デモ見れてよかった。