GitOps環境におけるremote_clusterでの開発

1. GitOps環境におけるremote clusterでの開発 大平 譲 / Ohira Yuzuru joe (@joe_yuzupi) bellface株式会社
2. Agenda ・GitOpsの導入 ・remote開発環境(feature環境と呼びます) ・telepresenceを用いたremote開発
3. dev prod CIOps
4. prod dev GitOps
5. feature環境 feature-hoge docker build ~~ docker push ~~.ecr.~~ kubectl create namespace ~~~~ ~~~~ ~~~~ feature-hoge feature-huga feature-test deploy-a deploy-b deploy-b deploy-b deploy-a deploy-a feature−hoge.bellface.~~
6. ・開発者がローカルに環境を用意することなく remoteのclusterで動作検証できる ・それぞれブランチ毎の環境なので他の開発者の変更を気にする必要がない ・PRの際にレビュワーもそのまま見れるので便利 メリット
7. ・pushの度に全てのアプリのimageがECRに積み上がるのでそれをなるべく防ぎたかった - 変更のないものも新しくimageを作成していた ・モノレポのCIOpsからGitOpsにしてリポジトリも分けた - 今までのような環境作成・検証はできない 問題・課題
8. ・リモートのクラスタにローカルから接続できる ・クラスタのDeploymentとローカルのdocker imageを置き換えることができる - 自分のローカルでの変更の確認を remoteのクラスタで行える ・置き換えの際に環境変数や Secretなどをクラスタに設定してあるものを使える 参照 telepresence.io Telepresence

9. 環境の作成は今まで通りにcircleciに任せる。 circleciのマジックコメントで環境を作成できるようにする git commit -m “[depoy] ~~” circleci上でmanifestをclone kustomizeで構成管理しているのでkustomize editでnamespaceの書き換えしてdeploy 作成した環境に対してtelepresenceを使用してデバックしていく telepresence --namespace feature-hoge --swap-deployment fuga-deployment How to
10. feature-hoge kubectl create namespace ~~~~ ~~~~ ~~~~ kustomize ~~ | kubectl ~~ feature-hoge feature-huga feature-test service-a service-b service-b service-b service-a service-a feature−hoge.bellface.~~ telepresence --swap-deployment
11. よかった点 ・pushしないと変更内容を検証できない点が telepresenceで容易にデバックできるようになった → バグなどの検証にも役にたった ・ECRにimageをpushしなくなったので管理するレジストリが減った。 ・telepresence自体の起動コマンドが冗長だったがメンバーの協力でスクリプト化でコマンド１発で ローカルのdocker buildからtelepresenceの実行まで行えたので楽になった
12. つまづいたところや課題点 ・EKS on Fargateを使用していたがfargate-profileの制約との相性が悪かった managed node groupで作成する方向に切り替えた ・本来のnamespaceの使い方ではない+microserviceに進んでてこのままだと 　きついので他の方法に切り替えたい microserviceではないけどkubernetes運用しているチームにはおすすめ ・kubernetes自体の経験がないと抵抗でtelepresence自体を使ってもらえていないので使って もらえるような活動をしたい
13. ありがとうございました。