以前
こういう記事を書いた．
あれから1年半経ち，少し変わったことがあるので記事にしておく．
続きを読むkubernetesとhelmで作る最強のオレオレheroku，yadockeri
この記事は LAPRAS Advent Calendar 2019 の18日目です．
会社でWebサービスを開発していると，検証したりレビューしたりするときに専用の環境が欲しくなる．それは開発しているブランチごとに独立した環境であって欲しいし，なんなら本番っぽいデータが入っているとなお良い． そしてエンジニアだけでなくデザイナーやPOもアクセスできて欲しい．俺のローカル環境を立ち上げればいい？最初は確かにそうなんだけれど，開発メンバーが増えてきたときに，全員がそれをやらなきゃいけないというのはコストだ．レビューのたびにそれをやるとなると，かなりのコストだ．
そいうわけで社内に検証環境を立ち上げるyadockeriというプロダクトを前職で作っていたんだけど，今の職場でも作りたくなってしまったのであった（3年ぶり2回目）．
続きを読むPleromaはいいぞ
この記事は分散SNS Advent Calendar 2019 の9日目です．
ふだんはMastodon/Pleromaのクライアントアプリケーションである，Whalebirdの話が多いけど，実は https://pleroma.io というPleromaサーバも運用しています．
なお，この記事は，分散SNSのサーバを自分で建てたい，管理したいという方に，Pleromaをおすすめする記事です． 利用者として登録するサーバとしてPleromaを強く薦めているわけではありません．もちろんPleromaサーバ管理者としては，Pleromaに登録してくれたら嬉しいけれども．
続きを読むkube2iamをIAM Role for Service Accountに載せ替えた
この記事は LAPRAS Advent Calendar 2019 の4日目です．
AWS上にkubernetesクラスタを構築していると，Pod内のコンテナから，AWSのAPIを叩きたいことがある． そのためにはもちろんAWSの認証を通す必要があり，AWSのAccess Tokenとか，IAM Roleを使って認証を通すことになる．
一般的に，productionで運用するEC2の中に，IAM UserのAccess Tokenを置くことは推奨されず，大抵の場合はIAM Roleで解決すると思う．もちろん，kubernetesクラスタであっても，ノードはただのEC2なのでInstance Profileを使えばIAM Roleでの認証は可能になる． しかし，kubernetesはクラスタだ．もちろんノードはいっぱいあり，その上で様々なPodが動いている．ということは，ノードのインスタンスからIAM Roleでの認証をする場合，そのRoleは，クラスタ内で動くすべてのPodが要求する権限を保有する必要がある．これはかなり強大な権限を持つRoleになってしまう． おまけに，この状態だと，実はセキュリティ的にAWSへのアクセスを許可しないPodであっても，容易にAWSへの認証を通ってしまうことになる．
こういう状態を避けるために，kube2iamやkiamといったOSSが開発されてきた．
で，このkube2iamに結構なバグがあったため，kopsで構築していたkubernetesクラスタに関しては，kiamに載せ替えたことがあった．
しかし，kiamはmasterノードにPodを配置する必要があり，masterノードに手を入れられないEKSでは，kiamを使うことができなかった．
これを完全に解決する方法として，今年9月にIAM Role for Service Accountが発表された．
というわけで，EKS運用しているクラスタのIAM認証を，このIRSAに載せ替えた．
IRSAの仕組みについては，上記記事を参照してほしい．ここでは詳しい動作原理については説明しない．
続きを読むHost-based routingしたALBにRoute53 Health Checkをかける
タイトルの件について結論から言っておくと，スマートな解決策は今のところない． 一応回避することはなんとなくできるのだが，全然スマートではない．今後のアップデートに期待したい．
続きを読む