情報更新

last update 02/22 11:01

ツイート検索

 

@mumoshu
サイトメニュー
Twilogユーザー検索

Twilog

 

@mumoshu

Yusuke KUOKA@mumoshu

Stats Twitter歴
4,271日(2008/06/14より)
ツイート数
74,707(17.4件/日)

ツイートの並び順 :

表示するツイート :

2020年02月21日(金)1 tweetsource

2020年02月20日(木)5 tweetssource

2月20日

@mumoshu

Yusuke KUOKA@mumoshu

helmfileみたいに宣言的にデプロイを順序立てる方法はFluxやArgoCDには無いものと思ってたけど、ArgoCDにはあった。

helmfile内の順序からArgoCDのsync-wave値を計算してエクスポートするような機能つけようかな

posted at 09:33:00

2月20日

@mumoshu

Yusuke KUOKA@mumoshu

Sync Waveの使いどころは、複数のマイクロサービスを特定の順序でデプロイしたい、というような場合。CIからデプロイするときはkubectl apply && waitを順番にやればいいけど、ArgoCDではどうするか。「sync-wave: 数値」で優先順位づけすれば、数値の小さい順にapply & waitしてくれる。

posted at 09:30:58

2020年02月19日(水)4 tweetssource

2月19日

@mumoshu

Yusuke KUOKA@mumoshu

アプリケーション自体のデプロイメントと、設定のデプロイメントを同時にやろうと思えばやれちゃう点も一緒かな。

アプリケーションの修正に対してはCodeDeploy、設定の修正に対してはAppConfigデプロイをトリガするようなデプロイパイプラインを組んでおくとよさそう〜。

posted at 09:44:52

2月19日

@mumoshu

Yusuke KUOKA@mumoshu

「CodeDeployとかぶってるやん」と思ったけど、設定値のデプロイにはAppConfig、コードの配布にはCodeDeployというふうに使い分けるといいのかなぁ。K8sでいうConfigMapボリューム感ある。

posted at 09:43:37

2020年02月13日(木)1 tweetsource

2020年02月10日(月)4 tweetssource

2月10日

@mumoshu

Yusuke KUOKA@mumoshu

@kompiro あったら便利そうですね〜!

WatchというAPIがあって、それ使うとDeploymentなどに対して発生したイベントをkubectlやclient-goで受けることはできます。それがここでいうLifecycle Hookみたいなものかな〜と思いました

posted at 15:57:20

2020年02月07日(金)2 tweetssource

2月7日

@mumoshu

Yusuke KUOKA@mumoshu

前段がALB限定なので、HTTP/2のワークロードには使えないし、ロールバックはCloudWatch Alarm起因しかできない(だろうなとは思っていたけど)のは前提として。

posted at 10:07:10

2月7日

@mumoshu

Yusuke KUOKA@mumoshu

ECSのCanary Deployment、Canaryにトラフィックを流す前のテスト(lifecycle hook)と、流したあとのテスト(cloudwatch alarm)にもちゃんと対応してるぽい。だいたいEKS + Flaggerと同じことができるという理解でいいか。

posted at 10:05:45

2020年02月05日(水)2 tweetssource

2月5日

@mumoshu

Yusuke KUOKA@mumoshu

@go_vargo 文脈わかってないですが、helm 2にしても3にしても、あまりgoライブラリとして使いやすいインタフェースではないように思うんですよね。あと、helmのバージョンが上がるたびにgo.mod更新とかもしんどいですし・・。

posted at 21:19:24

2020年02月04日(火)2 tweetssource

2月4日

@mumoshu

Yusuke KUOKA@mumoshu

@b4b4r07 あ〜prereleaseいいですね!

semtagはprerelease対応してないです。

あと、semtagはシェルスクリプトで、バージョン番号も振られてないので、やっぱりgit-bumpのようにgithub release + binaryとして配布されているほうが利用しやすいというのもあります。

posted at 14:41:44

2020年01月30日(木)1 tweetsource

2020年01月24日(金)1 tweetsource

2020年01月21日(火)11 tweetssource

1月21日

@mumoshu

Yusuke KUOKA@mumoshu

@nyasba @toricls @kohidave あってると思います!

なので、今回は、Blue/GreenしたいならAmazon ECS(Blue/Green)、そうでないならAmazon ECSでいいんじゃないかと。

もしBlueGreenしたいけど、appspecを置き換えたいわけじゃないという話なら、Blue/Greenのほうのappspecは省略可能っぽいので、省略すればよさそう?

posted at 10:37:05

1月21日

@mumoshu

Yusuke KUOKA@mumoshu

@nyasba ECS/Fargate使う場合、Amazon ECSとAmazon ECS(Blue/Green)=CodeDeployのどちらかを要件によって使い分ければよくて、CodeDeploy providerは用事がないような気がする。

posted at 10:20:44

1月21日

@mumoshu

Yusuke KUOKA@mumoshu

@nyasba Deployment stageのDeploy provider別に、Amazon ECSがタスク定義変えない(イメージの名前とタグのみ変えてデプロイする)、Amazon ECS(Blue/Green)がCodeDeploy使ってBlue/Greenする(タスク定義も変えられる)、そして「CodeDeploy」がEC2向けっぽい?

posted at 10:19:08

2020年01月20日(月)3 tweetssource

1月20日

@mumoshu

Yusuke KUOKA@mumoshu

なぜArgo CDやExternal Secrets、alb-ingress-controllerを使う前提なのと思ったけど、選べるものが多すぎて難しく考えすぎちゃう、ECSと同じ要件を満たすためにK8sで色々頑張りすぎる余地があるのが相対的に問題になるケースもあるのではって意図なら、わからんでもない。K8sに非はないけどな!

posted at 10:23:34

2020年01月14日(火)2 tweetssource

2020年01月09日(木)1 tweetsource

1月9日

@mumoshu

Yusuke KUOKA@mumoshu

@ido_kara_deru そうですね!ぼくのCrossoverなんかだとTrafficSplitしか対応してませんが、対応してる実装であればそういった機能をサポートするために使えます。
Flaggerは元々Istioとしか連携できなかったのですが、Linkerd2のためにSMIに対応しました。Flagger以外だと僕も事例は知らないですね。

posted at 12:24:35

2020年01月08日(水)15 tweetssource

1月8日

@mumoshu

Yusuke KUOKA@mumoshu

@ido_kara_deru 例えばFlaggerはSMIを話せるので、SMIに対応したIngress Gatewayやサービスメッシュとは比較的簡単に連携できます。Flaggerのようなサービスメッシュの利用側からみて、SMIにさえ対応できれば様々な実装に対応できる、というのがメリットの一つかなと思ってます。

posted at 23:52:10

1月8日

@mumoshu

Yusuke KUOKA@mumoshu

Istio v1.0直後に問題になってたようなメモリ消費の問題はSidecarリソースが追加されたあたりまでで大体解決した認識なんですけど、甘いですかね? #envoytokyo

posted at 20:30:01

1月8日

@mumoshu

Yusuke KUOKA@mumoshu

アプリChartのSubchartとしてIstio設定Chartを呼んで、Values経由でアプリ側にいじってほしい設定だけをいじれるようになってる。いいすね。 #envoytokyo

posted at 20:28:18

1月8日

@mumoshu

Yusuke KUOKA@mumoshu

内容は完全同意ですけど、Istioじゃなくて自作したとしても同じ種類の運用負荷がかかりそうなので、結局マネージドサービスがあれば使うか、そもそもユースケースがない、ペイしないような場合はService Meshそのものを採用しないとか、そういう話ありきな気はした。 #envoytokyo

posted at 20:22:15

1月8日

@mumoshu

Yusuke KUOKA@mumoshu

仮に後でSomething on K8sに移行するとしても、それがEnvoyベースな限り、ここまで作り込んで得た知識や経験は無駄にならなさそう。

posted at 20:06:39

1月8日

@mumoshu

Yusuke KUOKA@mumoshu

自分でつくったほうが逆に工数が読みやすいとか、自分で作る過程で運用に対する自信が持てる、みたいなケースはありそう。あと、ここまで作り込んで納期通り追えられるのであれば、あえてKubernetesを避けてNomad + Consul + Envoyでやって成功だった、といえるような気もする。 #envoytokyo

posted at 20:05:06

1月8日

@mumoshu

Yusuke KUOKA@mumoshu

ダミーEndpointが必要な件は、ヘルスチェックをConsulがやってるのと相性が悪いって話なのかな?いまいちわかってない。

Envoy側でNo passthrough + Envoyからヘルスチェックするか、Passthrough + Cacheにして、Consulからのヘルスチェックはしないように、とかできないんですかね。

#envoytokyo

posted at 19:59:52

1月8日

@mumoshu

Yusuke KUOKA@mumoshu

Nomad + ConsulにEnvoyでクライアントサイドLBを足す構成、無駄がなくて美しいな、って思う。Service Mesh on K8sだとちょっとK8sの機能とかぶるんですよね(Rejekts 2019の"We've Made Quite a Mesh" 参照) #envoytokyo

posted at 19:40:17

1月8日

@mumoshu

Yusuke KUOKA@mumoshu

lizanさんの「最小 envoy.yaml」から初めて、「xDS(gRPCじゃなくて設定ファイルのほう)」でDRYにしていく流れ、めっちゃわかりやすかった。頭ではわかってたつもりだけど、実際手を動かしてやったことはなかったので、デモ見れてよかった。 #envoytokyo

posted at 19:35:22

このページの先頭へ