はじめに
2019年7月25日に開催されたKubernetes Meetup Tokyo #21 - Cloud Native CI/CDにブログ枠で参加してきました.
4月頃からArgo CDを使ってGitOpsを(オンプレで)試したりしていたのでどうしてもこの回に参加したく,最初はLT枠で申し込もうかと思ったのですが,悩んでいる一瞬でLT枠が埋まってしまったためブログ枠で申し込みました.
ということで,ここではGitOpsとArgo CDに関する話題を中心に参加メモを残しておきます.
発表内容
1. Argoプロジェクト最新動向
谷脇 大輔氏(@dtaniwaki,Preferred Networks, Inc.)
発表資料
概要
Argoプロジェクト全体の紹介と,Argo CD,Argo Rolloutsのライブデモでした(残念ながらライブデモはエラーに終わっていましたが.
なぜArgoプロジェクトのメンバになったか?
PFNは巨大なGPUクラスタをオンプレKubernetesで構築していることで有名ですが(参考: https://www.slideshare.net/pfi/kubernetes-125013757 ),そこでArgo Workflowを使いたかったけどもPFNの要件では使えなかったので,自分でコントリビュートしていったというのが理由.
Argoプロジェクト
以下の4つ
- Argo Workflows
- Kubernetes Nativeなワークフローエンジン,Kubeflowの文脈でよく見かけますね
- Argo CD
- Kubernetes NativeなCDツール,この話を聞きに来た
- Argo Rollouts
- Blue-GreenやCanaryなどの戦略をdeploymentで使えるようになる,
- Argo Events
- Kubernetes用のイベントベースの依存管理ツール,CloudEvents準拠
Argo CD
Gitで管理されたManifestをKubernetesにデプロイすることに特化していて,まずGitリポジトリを登録しないとデプロイができません.
CDの設定などはすべてKubernetesのCRDとして管理され,Argo CD自体はほぼステートレスなサービスとして動作します.
PFNでも導入を計画中とのこと.
Argo CDの特長は以下の通り
- GitOps
- Replica数の一時的な変更といったパッチを当てることもできる
- GUI
- Kubernetesに特化しており,Init containerやSide carなどの状態まで確認できる
- GUIからリソースの管理や操作ができる
- 私がGitOpsツールにArgo CDを選んだのはこの辺りが理由です
- 利便性
- Helm,jsonnet,ksonnet,kustomizeなどのツールをサポート
- 拡張性
- Kubernetes manifestsによるフック
- PreSync,Sync,Skip,PostSync,SyncFail
- Kubernetes manifestsによるフック
感想
PreSyncやPostSync,そしてv1.1から入ったSync Wavesなどはまだ試せていないので,もうちょっと色々触ってみたいです.
GitOps用のツールとしてJenkin XやWeave Fluxなどもあると思うのですが,今回のMeetupでは特に触れられている方はいなかったですね.
2. GitOpsでも秘匿情報をバッチリ扱う⽅法、SealedSecretとは?
伊藤 ⻯⼀氏(@amaya382,さくらインターネット株式会社 技術本部)
発表資料
概要
GitOpsの際に秘匿情報を暗号化してGitリポジトリで管理するためのSealedSecretというツールの基本的な動作と,他の類似ツールの紹介(類似ツールの紹介が非常に充実していました.
会場アンケート
- Kubernetesを触ったことがほとんどない:ほぼゼロ
- Kubernetesは触っているがGitOpsはあまり:けっこう多い
- GitOpsを試している:まぁまぁいる(私もここ
- GitOpsをがっつり使っている:数名
GitOps
GitリポジトリをSingle Source of Truth(SSoT)としてそこに現在のManifestなどのサービスの稼働状態をコード化したものを配置しておき,サービスの状態変更やサービス追加などを行う際はGitリポジトリ上のManifest等へのPRが承認されたことを契機にCDツールが自動的にKubernetesへ変更内容をデプロイする仕組み.
GitOpsにおける秘匿情報の扱い
GitOpsではすべての情報をGitリポジトリ上で管理することが望ましいですが,パスワードやSSH keyなどの秘匿情報をそのまま置くわけにはいかないですね.
そこでSealedSeacretです.
SealedSeacret (bitnami-labs/sealed-secrets)
SealedSeacretはManifestファイルのうち,Secretを暗号化してGitリポジトリで管理します.
動作はかなりシンプルです.
- インストール時にPublic keyとPrivate keyが自動的にKubernetesクラスタ内で生成される
- ユーザはCommitする前にkubesealというツールを使って手動でSecretsを暗号化(このとき,kubesealはクラスタ内のPublic keyを取得して暗号化に用いる
- ユーザは暗号化されたSecrets(SealedSecret)をGitリポジトリにCommit
- SSoTとなるGitリポジトリに変更内容をPush(PR)
- CDツールがSSoTの変更を検知してSealedSecretをKubernetesクラスタにデプロイしようとする
- このとき,sealed-secrets-controllerがPrivate keyを使ってSealedSecretをSecretに復号してからデプロイ
- あとは通常通りPodからSecretにアクセスできます
Kubernetesクラスタ上では平文のSecretが存在するため,RBACでの制限が必要なのと,Secretの実体が存在するetcdもデフォルトでは平文なので,EncryptionConfiguration等が必要です.
SealedSeacret × テンプレートエンジンのつらい話
ここでいうテンプレートエンジンは,KubernetesにおけるHelmやKustomizeを指しています.
これらのテンプレートエンジンでは,秘匿情報は環境別の設定ファイルに保持しますが,SealedSeacretではSecret全体を暗号化するため,相性が悪いです.
対処方法はいくつか考えられますが,Issueとして上がっているそうなので,待つのも1つの手ですかね…
類似ツール
- kamus
- SealedSecret+αくらいの機能なので,こちらを先に知っていればこっちを紹介したかも,とのこと
- kubesec
- GitOpsよりもCIOps向き
- HelmSecrets (sops)
- Helmプラグイン,ArgoCDが一応対応可能
- Kustomize Secret Generator Plugins
- Kustomizeプラグイン,CDツールが未対応
- Hashicorp Vault
- GitOpsとの相性が良いが秘匿情報はVaultサーバで管理
- git-crypt
- ArgoCDが一応対応可能
感想
今組んでいる環境での秘匿情報の管理方法は未検討なので,一度SealedSecretかkamusを触ってみたいところです.
実際に組むとすると,Vaultの方が使い勝手は良さそうなので,GitOpsでVaultがうまく使えないかも検討してみた方が良さそうですね.
3. コロプラが実践しているSpinnakerを用いたデプロイ戦略
磯 賢太氏(@go_vargo,COLOPL, Inc.)
発表資料
後日公開予定
概要
Spinnakerの紹介と,コロプラ社の中でどのように利用しているかの紹介でした.
コロプラ社ではGKE×Spinnakerの環境で利用しており,一番大きなゲームタイトルでは27のPipelineが存在,gitのbranchを切るだけで新たな環境が構築される,など,Spinnakerをがっつり利用している感じでした.
ただ,Spinnakerの挙動が不安定,ということをしきりに仰っていたところが辛そうなところですね…
今後はTelepresenceの代替になるツール探しと自動カナリアリリースをやっていきたいとのことでした.
LT1. Argo CD 実践ガイド
黒澤 大氏(@ponde_m,Classmethod, Inc.)
発表資料
概要
Argo CDのCRDとSync戦略についての解説でした.
Argo CDのCRD
前述したようにArgo CDの設定はKubernetesのCRDとして管理されますが,そのCRDは以下の2種類あります.
- Application
- デプロイの設定(デプロイ対象とするGitリポジトリ,Revision,Path,デプロイ先のクラスタやNamespace)
- Application of Applications(複数のApplicationをApplicationとして管理)
- AppProject
- Argo CDにおけるプロジェクトの設定(Argo CDのプロジェクト=Applicationの論理的なグループ)
Argo CDのSync
大きく分けて以下の3つのフェーズが存在します.
- PreSync
- manifestの適用前に実行される
- Sync
- manifestの適用に関連して実行される
- PostSync
- manifestの適用後に実行される
また,v1.1から追加されたSync Wavesという機能があります.
これは,上記の3つのフェーズ内でのmanifestの適用順序を制御するための機能です.
感想
フェーズとSync Wavesの関係をきちんと理解していなかったので,大変ためになりました.
GUI上ではこういった細かい設定項目はなかった気がしているのですが,見落としているかもしれないので確認してみようと思います.
おわりに
GitOpsのSSoTの考え方が非常に好きで,今後もGitOpsに寄せていきたいと思っているのですが,今回のMeetupで話題になった秘匿情報の管理や,そもそもKubernetesクラスタの管理をどうすべきか(Kubernetesクラスタ自体もGitOpsでうまく構築できないか)など,まだまだ考えるべきところが残っています.
今回のMeetupに参加でき,今後考えていく中で使えそうなヒントやアイデアをいくつも得られたのは大きな収穫でした.