この記事は、 2021/5/13 に行われた WESEEK Tech Conference の内容です。
ArgoCDを使用したGitOpsについてお話ししました。実際のArgoCDの設定例などを紹介しながら、デモ形式でのGitOps構築までの道のりを紹介しました。
目次
GitOpsとは
DevOps のベストプラクティスを多く取り入れ、さらにインフラのコードの自動反映、バージョンコントロールもGitリポジトリの変更を起点にして行おう!というのがGitOpsという新しい開発・運用のフレームワークです。
GitOpsを導入していない場合の課題
まずGitOps を導入していない場合に起こり得る問題として以下のようなものがあります。
権限問題
CIにクラスターへの反映権限を持たせなければいけないので、最小権限管理ができない(乗っ取られたらやばい)
マニュアル作業によるオペレーションミス
kubectl describe deploy hogehoge を入力しようとしたら、kubectl delete deploy hogehoge を入力してしまい、一時的にサービスが落ちてしまった
リポジトリにマニフェストはあるが反映されていない
リポジトリに含まれている、本来クラスターに反映されているはずのリソースが、反映されていないせいで他の作業者がタスクで詰まってしまう(あるはずのリソースがないから)
ArgoCDでGitOpsをしてみた理由
今回ArgoCDを選択してGitOpsをしてみた理由には以下のようなものがありました。
感情的動機
- 新しい技術に触れてみたい
- 自動化大好き
ちょっと真面目な理由
かなり見やすいですよね!
GitOps を実現できるツール
今回はKubernetesをインフラの環境としてGitOpsをしたので、Kubernetes ネイティブに設定できるものをいくつかピックアップしました。
-
- 視認性に優れたUI
- プルーン機能による不要リソースの削除 や、セルフヒーリング機能などの提供
- SSO のビルトインサポート、RBACが可能
-
- GitOps toolkit の提供をしているので、他のCDツールと組み合わせて使うことが可能
- Container Image Registry を監視することで image tag の自動更新(Live manifet and Gitリポジトリのマニフェスト)
- UIがない...
-
- 視認性に優れたUI
- Kubernetes 以外の運用環境も対応(Terraform, Cloud Run, AWS Lambda)
- カナリーリリース・シークレットマネジメントのビルトインサポート
ArgoCD のアーキテクチャ
ArgoCD を構成するコンポーネントとして主にクラスターへの反映に関わるコンポーネントは三つあります。
三つのコアコンポーネント
ArgoCD の主なCRD
CRD とはKubernetes デフォルトではないCR(カスタムリソース)をクラスターに反映するために定義し反映するリソースです。
ArgoCD では Application/AppProject CRD をインストール時に反映しCRとしてそのリソースを反映し実際にアプリケーションマニフェストを自動でデプロイします。
Application
- Application CRD は ArgoCDをインストールした際、一緒にインストールされている
- Application は必ずいずれかのAppProjectに結びついている必要がある
-
主に定義すること
- どのGitリポジトリからマニフェストを取得するか
- どのクラスターにアプリケーションをデプロイするか
- どのネームスペースにアプリケーションをデプロイするか
- 自動同期を有効にするか
AppProject
- Application CRD は ArgoCDをインストールした際、一緒にインストールされている
- Application は必ずいずれかのAppProjectに結びついている必要がある
-
主に定義すること
- 自分に所属する Application が
- どのGitリポジトリからならマニフェストをプルして良いか
- どのクラスターにならマニフェストを反映して良いか
- どの種類のマニフェストなら反映して良いか
SSO での RBAC
ArgoCDへのアクセスコントロールをGitHub のオーガニゼーション・チームベースやGitLabのグループベースで行いたくないですか?
ArgoCDではそんなアクセスコントロールを簡単に実現することができます。
サポート方式
主に二つの方式があります。
- ArgoCD に組み込まれている OSS の Dex を使用
-
既存OIDCプロバイダーを使用する
- Okta, OneLogin, Auth0, Microsoft, Keycloak, Google(G Suite)
ArgoCD における Dex の役割
-
外部認証プロバイダーに認証を委任する
- OIDC, SMAL, LDAP, GitHub
-
外部認証プロバイダーからユーザー情報を取得し、その情報を元にIDTokenを作成し提供する
設定例(helm values)
ロールの作成・割り当て
ただSSOで認証を行うだけでは、ロールが割り当てられていないので、ログインしても何も行えません。
なので、認証されたユーザーに対してロールを結びつける必要があります。
-
ビルトインロール
- role:readonly
- 全てのリソースに対してリード操作のみが可能
- role:admin
- 全てのリソースに対して全ての操作が可能
-
カスタムロール
- argocd-rbac-cm に csv形式でロールの作成・割り当てが可能
- argocd-rbac-cm に csv形式でロールの作成・割り当てが可能
サポートしているマニフェスト定義ツール
ArgoCD で自動デプロイする際に、サポートしているマニフェストの定義方式のようなものを紹介します。
4つの標準ツール
- Jsonnet
- Ksonnet
- Kustomize
- Helm
サポートされていないマニフェスト定義ツールを使用したい場合
サポートされていないマニフェスト定義ツールでも下記拡張機能を使用することで、使用できるようになります。
-
- Repository Server に内包されていないツールや、特定バージョンのツールなどを利用するためのArgoCDの拡張機能
-
- Custom Tools で追加したツールを、ユーザー定義のプラグインとしてArgoCDに追加することで、そのツールを用いk8sマニフェストを作成することが可能になる
マニフェストの依存関係の考慮
なぜ依存関係を考慮する必要があるのか
複雑なクラスター構成になればなるほど、リソース同士の依存関係も複雑になります。
例えば、CalicoのNetworkPolicyリソースは反映順序を間違えるとクラスター外への通信が全て拒否されるようなネットワーク構成になってしまうといった事も起こり得ます。
ArgoCD の Sync にはいくつかのフェーズがあり依存関係の考慮ができる
上記に書いたような課題の解決するためリソースの反映順序を考慮する機能をArgoCDでは提供しています。
-
Resource hooks・Waveといった概念が存在する
- Resource hooks は五つのフェーズ
- ex. PostSync というフェーズはSync後に実行されるフェーズなので、Slack通知のJobマニフェストの反映などに適している
- Wave は 数値による反映順序の優先付
-
両方ともアノテーションから設定する
metadata:
annotations:
argocd.argoproj.io/hook: PostSync
argocd.argoproj.io/sync-wave: “5”
Resource Hooks
下記のフェーズが上から順番に実行されていきます。
-
PreSync
- DBのmigrationなどのJob実行
-
Sync
- アプリケーションのデプロイ
-
Skip
- 同期をスキップしたいマニフェスト
-
PostSync
- デプロイが完了した際にJob実行(Slack に通知など)
-
SyncFail
- デプロイが失敗した際のクリーンアップ
Waves
- デフォルトは全て0
- 負の値も設定可能
- 低い数字のものから反映されていく
まとめ
ArgoCD
-
ドキュメントが整備されているので簡単な設定であれば困ることはない
-
費用対効果は高い
- ArgoCDに費やす必要のある学習時間は少ない
- How の部分は隠蔽してくれてくれている
- マニフェストは直感的で、設定項目もそんなに多くない
- 得られる恩恵は大きい
- UI、自動化、 SSOによるRBAC...
-
ArgoCDだけでは、いい感じに構成できない機能もある
- Slack通知など
実務に取り入れるための課題
-
複雑なオペレーションを安全に自動化できるか
- ex. リソースAを削除した後に、リソースBを反映し、リソースCはその後に消す
-
マルチクラスターを一つのArgoCDで管理するのか否か
- ArgoCDに全てのクラスターの権限を持たせる必要がある
- 権限管理的にどうなの?
-
動的なマニフェスト変更
- HPA などによる Deployment replicas の変更
- OutOfSync になってしまい、セルフヒーリングを有効にしていた場合リバートされてしまう
- ↑を防ぐために Diffing customization などの機構もある
著者プロフィール
株式会社WESEEK / バックエンドエンジニア
2020年6月より長期インターンシップに参画中の文系大学生。
主な担当業務は、大手IX企業様のポータルサイトの構築・保守、インフラ基盤の構築・運用を行っています。
株式会社WESEEKについて
株式会社WESEEKは、システム開発のプロフェッショナル集団です。
【現在の主な事業】
- 通信大手企業の業務フロー自動化プロジェクト
- ソーシャルゲームの受託開発
- 自社発オープンソースプロダクト「GROWI」「GROWI.cloud」の開発
GROWI
GROWIは、Markdown記法でページを記述できるオープンソースのWikiシステムです。
【主な特徴】
- テキストも図表もどんどん書ける、強力な編集機能
- チーム拡大に迅速に対応できる管理者向け機能を提供
- 充実した機能・サポートでエンタープライズにも対応
GROWI.cloud
GROWI.cloudはOSSのGROWIを専門的知識がなくても簡単に運用・管理できる、法人・個人向けの商用サービスです。
大手Sier・ISPから中小企業・大学などの教育機関まで幅広くご利用いただき、さらに個人や大学サークルでもご利用いただいています。
【導入事例記事】
インターネットマルチフィード株式会社様
https://growi.cloud/interviews/mfeed/?utm_source=connpass-top&utm_medium=web-site&utm_campaign=mf
株式会社HIKKY(VR法人HIKKY)様
https://growi.cloud/interviews/hikky
WESEEK Tech Conference
WESEEK Tech Conferenceは、株式会社WESEEKが主催するエンジニア向けの勉強会です。
月に2回ほど、WESEEKに所属するエンジニアが様々なテーマで発表を行う予定です。
次回は、5/27(木) 19:00~20:00に開催予定です。
SaaS運用での大障害の対策の共有を、システムエンジニアの佐藤がお話します。
現在、connpassやTECH PLAYで参加受付中です。皆様のご参加をお待ちしております!
https://weseek.connpass.com/event/211844
TECH PLAYはこちらから
一緒に働く仲間を募集しています
東京の高田馬場オフィス、大分にある別府サテライトオフィスにてエンジニアを募集しております。
中途採用だけではなく、インターンシップも積極的に受け入れています!
詳しい募集要項は、弊社HPの採用ページからご確認ください。