情報更新

last update 11/13 01:36

ツイート検索

 

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

Twilog

 

@mumoshu

Yusuke KUOKA@mumoshu

Stats Twitter歴
4,170日(2008/06/14より)
ツイート数
74,282(17.8件/日)

ツイートの並び順 :

表示するツイート :

2019年11月12日(火)15 tweetssource

17時間前

@mumoshu

Yusuke KUOKA@mumoshu

@_inductor_ そんなに大層なものじゃないので、もう検討されてると思うのですが、こういう感じでいけないですかね・・?

gist.github.com/mumoshu/c82167

この上で、例えばノードのローリングアップデート失敗時のロールバックを作り込むと大変そうですが、それはCFNでやっても大変そうな(CFNだとcfn-signalでがんばる?

posted at 15:57:58

18時間前

@mumoshu

Yusuke KUOKA@mumoshu

@_inductor_ 宣言的に管理するためのドライバになるスクリプトをちょろっとかけばeksctlで宣言的に管理はできるので、宣言的かどうかというより、既に宣言的に管理するためのインフラが揃ってることが重要なのかな?と思った次第でした。

posted at 15:02:30

18時間前

@mumoshu

Yusuke KUOKA@mumoshu

@_inductor_ なるほど・・・。いやまあわかります。terraformやcfnなどの既にCIパイプラインが確立している(ということだと理解しました)ものに寄せられればメリットありそうですよね。

posted at 14:06:07

19時間前

@mumoshu

Yusuke KUOKA@mumoshu

@_inductor_ eksctl get cluster, eksctl create cluster, eksctl update, eksctl utilsあたりに色々と必要なものは用意してあるので、それを要件にあわせてちょっとしたシェルスクリプトで繋げばいける、というスタンスでした・・

posted at 13:59:10

19時間前

@mumoshu

Yusuke KUOKA@mumoshu

@_inductor_ eksctlで生成したstack templateの内容は気にしない(eksctlで生成されたくない、こだわりがあるIAM Role、VPC、etcは全部cluster.yamlにはIDだけを書いておきeksctlに作らせない方法で使っている)という方法をとっていたので、その発想がなかったです・・

posted at 13:49:07

19時間前

@mumoshu

Yusuke KUOKA@mumoshu

@_inductor_ なるほど〜・・完全に想定外で、そういう場合はCDKや生のCFNが使われるものだと思ってました・・。

公式化してreliableだと思われるから、そういうCFNライブラリ的な使い方をされようと思った感じなんですかね?

posted at 13:45:57

19時間前

@mumoshu

Yusuke KUOKA@mumoshu

@_inductor_ あー、再利用可能なスタックテンプレート再生ツールとしてeksctlを利用したいということですか?Stackパラメータで自在に必要な設定がスタック作成時にできるような。

posted at 13:34:01

19時間前

@mumoshu

Yusuke KUOKA@mumoshu

@_inductor_ むむ?それはなんのために…です?

(ノードグループ間で共有する、ということだとすると、ノードグループごとにuserdataを変えるのが難しくなるような気がして

posted at 13:16:39

2019年11月11日(月)12 tweetssource

11月11日

@mumoshu

Yusuke KUOKA@mumoshu

@k_kinzal おお、こんなまとめが!

見た感じ、唯一NotificationになってるUtilizationは閾値厳しめにして、他は(閾値という概念もなさそうなので)Recordのままでいいかも?って思いました

posted at 23:13:39

11月11日

@mumoshu

Yusuke KUOKA@mumoshu

@k_kinzal 閾値を厳しめにする(サービス影響が出るより前にアラートが上がるようにする)じゃだめですかね?(そもそもLimitに到達してはだめなのだとすれば

posted at 23:05:40

11月11日

@mumoshu

Yusuke KUOKA@mumoshu

@_inductor_ ざんねん…そこは現状システムか人間にAssumeRoleさせてごまかすくらいしかないように思います(結局クラスタ作成時にはAssumeRoleしないといけないので根本的にはEKSの機能追加待ちですけど、なんもしないよりマシかなと

posted at 22:33:10

11月11日

@mumoshu

Yusuke KUOKA@mumoshu

@_inductor_ admin userってIAM User的な意味です?

であれば、VPCやIAM周りだけ、別の強い権限持ってるCIか人間さんに作ってもらったら、クラスタの作成にはそんなに強い権限はいらないような気がしてます。

先の「クラスタ作成したIAM User/Roleがcluster-admin」という件については如何ともし難いですが…

posted at 22:27:38

11月11日

@mumoshu

Yusuke KUOKA@mumoshu

@toricls かわりに強いロールは人間に極力渡さないようにしたり、マルチテナントクラスタを避けてセキュリティ確保しよう、となると、なんも考えずにというのは無理ですが…

posted at 22:21:28

11月11日

@mumoshu

Yusuke KUOKA@mumoshu

@toricls EKS自体ではなく、IAM関連でハマるような気はしてます。

なんも考えずに強いロールでクラスタ作ったり、ノードのロールをPodから使わせたりしてる分には何も起きないはず…?

posted at 22:18:29

11月11日

@mumoshu

Yusuke KUOKA@mumoshu

@_inductor_ IAMまわりですかね?(興味本位

CFN、EKSのControl-Plane、ノード、Cluster AutoscalerなどのPod、それぞれ渡す権限を細かく設定しようとすると大変そう

posted at 22:03:26

11月11日

@mumoshu

Yusuke KUOKA@mumoshu

@renjikari これは結構分かりみがありまして…先を行き過ぎて他社事例がまだ少ないんですよね。(比較対象がシェルスクリプトでがんばるとか、terraformでがんばるとか、抽象化/helm諦めるとかなので、絶対数が少ないのは否めず。

社内独自ツールを避けるためのOSSのはずが、いつのまにか逆転してしまった感。

posted at 21:02:37

2019年11月08日(金)1 tweetsource

2019年11月06日(水)1 tweetsource

2019年11月05日(火)3 tweetssource

11月5日

@mumoshu

Yusuke KUOKA@mumoshu

@stefanprodan @EnvoyProxy @awscloud Thanks! That makes sense.

So it does serve Ingress Routing, but specialized for deployment on K8s and management via K8s API.

I think this can be the best option for anyone who wants an Envoy-based ingress gateway for K8s with a (mostly) AWS-managed controlplane 💯

posted at 09:31:34

2019年11月03日(日)2 tweetssource

11月3日

@mumoshu

Yusuke KUOKA@mumoshu

@budougumi0617 そのメールには11月13日にGA予定と書いてありましたね。料金はリンク先のPricingを見てね、というようなことが書いてあったような。
// 僕もGA楽しみにしてます!Self-Hosted Runnerも早く来てほしい。

posted at 20:58:12

2019年10月28日(月)3 tweetssource

10月28日

@mumoshu

Yusuke KUOKA@mumoshu

@_inductor_ @toricls どうなんでしょ…?とりあえず雑に2人ともメンションしてみるとか?(コントリビュート関連や特定機能の経緯、設計思想なんかは僕の方が答えられるかもですが、使い分けとかAWS的なサポート関連だと @toricls さんのがより適任・フェアに答えられるような気がするので

posted at 10:48:08

2019年10月23日(水)1 tweetsource

10月23日

@mumoshu

Yusuke KUOKA@mumoshu

@k_kinzal WorkflowがトリガされるたびにCheck Suiteが、そのWorkflow内のJobが実行されるたびにCheck Runが作成されるみたいです。Check RunとStatus、どちらも更新はないみたいです。

posted at 03:42:27

2019年10月18日(金)17 tweetssource

10月18日

@mumoshu

Yusuke KUOKA@mumoshu

GitHub ActionsのトークンでStatus APIたたけるので、それ使ったほうが簡単かもしれない。少しならDescriptionも載せられるし、Workflowが複数あってもややこしいことにならないし。 pic.twitter.com/R3Y8W82FXU

posted at 02:00:08

10月18日

@mumoshu

Yusuke KUOKA@mumoshu

誰得情報。

Workflowにon: check_suiteやらon: check_runを書くとChecks関連のイベントからWorkflowをトリガできるとドキュメントには書いてある。しかし、GitHub Actions自身がつくったSuite/Runには反応しなかった。親切だけど、最初戸惑った。

posted at 01:06:46

10月18日

@mumoshu

Yusuke KUOKA@mumoshu

すぐ下の「Checks APIをたたいて同じCheck Suiteに無理やりぶらさげたCheck Run」のほうは、(当然だろうけど)ビルドログではなくこれまで通りCheck Runの結果ビューになってる。面白い。 pic.twitter.com/T3slAva0Ny

posted at 01:02:52

10月18日

@mumoshu

Yusuke KUOKA@mumoshu

CI的な用途で使うなら、PRオープン時とPush時だけビルドするようにして、リオープン時にはビルドしないようにしないといけないかな?(リオープンでビルドするようにすると、前述の通り同じコミットに対してWorkflowが重複実行されるので・・・

posted at 00:58:59

10月18日

@mumoshu

Yusuke KUOKA@mumoshu

GitHub Actionsは下記の仕様になってる模様

- Workflow = Check Suite
- WorkflowをPRに対して2つ以上トリガすることができる
- 同じコミットに対してWorkflowを再トリガする(例えばPRのreopenやlabelイベントはHEADを変えずにWorkflowをトリガできる)と、Check Suiteを使い回すのではなく新規作成

posted at 00:56:30

10月18日

@mumoshu

Yusuke KUOKA@mumoshu

Check Run作成のAPIには紐付け先のCheck Suiteを指定するパラメータはないんだけど、本来Check Suiteは1コミットに対して1つしか作成できないのでそれで問題なかった。Check Suite IDがなくても紐付け先のSuiteはコミットIDだけで特定できるから。

posted at 00:52:09

10月18日

@mumoshu

Yusuke KUOKA@mumoshu

普通はPRされたブランチの1コミットに対してCheck Suiteはたかだか一つしか作成できず、2つ以上作成しようとすると422になるはず。しかし、ActionsがWorkflowを2つ以上トリガした状態でCheckSuiteのリストを取ってみると、トリガされたWorkflowの数だけある(これは事実)

posted at 00:50:27

10月18日

@mumoshu

Yusuke KUOKA@mumoshu

ここからは想像ですけど、GitHub ActionsはChecks APIベースと言いつつ、Actions自身がcheck_suite・check_runイベントをトリガしたときの挙動が普通のChecksと違う。

posted at 00:49:11

10月18日

@mumoshu

Yusuke KUOKA@mumoshu

先程の「PRによってトリガされるWorkflowは一つに制限する」というワークアラウンドは今のところうまくいってる。

Check Runを失敗させるとRequired Check未達の状態から始めて(続く pic.twitter.com/WH2OO5tgvf

posted at 00:44:14

10月18日

@mumoshu

Yusuke KUOKA@mumoshu

脱線: PRのステータスだとworkflow名 / job名が表示されるけど、Branch Protection > Required Status Checksだとjob名(=check run name)のみの表示なのでちょっと迷う

posted at 00:42:21

10月18日

@mumoshu

Yusuke KUOKA@mumoshu

一番簡単だと思われるワークアラウンドは、PRに対してトリガされるWorkflowを一つだけに絞ること。

具体的には、on: pull_requestがついているworkflowが.github/workflows/*.ymlにたかだか一つに制限する。

Check Runの作成元・先となるSuiteが結果的に一致するので、前述の問題は発生しないはず。

posted at 00:24:49

10月18日

@mumoshu

Yusuke KUOKA@mumoshu

と思ったけど、言い換えると「PRに対して走るWorkflowが複数ある場合は、期待と違うCheck SuiteにCheck Runが紐付いてしまうことがある」という感じなので、きびしい。

このキャプチャだとdev workflowからChecks APIでつくったCheck Runが別のworkflow(dump-event)に紐付いてしまった。 pic.twitter.com/Gk2y5HCjmJ

posted at 00:21:14

10月18日

@mumoshu

Yusuke KUOKA@mumoshu

それで、先のキャプチャの通り、Check RunをGitHub API経由でつくった場合、Check RunがWorkflow=Check Suiteのいずれかに紐付く(どれに紐づくかは不定)ものの、Statusはなぜか重複しないので、Branch Protection/Required Status Checkにも使えなくはなさそう

posted at 00:18:14

このページの先頭へ