ArgoCDによるGitOps導入 / ArgoCD GitOps

ArgoCDによる  GitOps導入 

自己紹介  名前と所属  • Chikahisa Mikata（Twitter: @melpo_mel）  • Rakusという会社に所属しています    普段の業務 
• SREチームのマネージャーをしています  • Kubernetesはまだまだ学習中、  社内導入もこれからで四苦八苦しています 

本日のアジェンダ  • GitOpsとArgoCD  • ArgoCDのチーム利用  • Applicationの管理方法  • Helm Chartの管理方法 
• まとめ 

• Weaveworks社による造語  • DevOpsの手法をインフラに適用した運用モデル  • Gitを軸としたCI/CDの手法  • ソフトウェア開発に使用するツールやプロセスを使ってインフラを管理できる  GitOps 

GitOpsの流れ  ①マージ  （機能開発ブランチ）   ②CI発火  ③プッシュ  ③PR作成  ④マージ  （マニフェストブランチ）  
⑤差分検知  ポーリング  ⑥イメージ取得  ⑦デプロイ  ・テスト  ・イメージビルド 

ArgoCD  • Kubernetes環境でのGitOpsを実現するためのCD ツールでCNCFのGAプロジェクト  • Gitリポジトリ上のKubernetesマニフェストを監視し、 Kubernetesクラスタに適用  • GitリポジトリとKubernetesクラスタの状態が常に一致（Single
Source of Truth）

GitOpsの流れ  ①マージ  （機能開発ブランチ）   ②CI発火  ③プッシュ  ③PR作成  ④マージ  （マニフェストブランチ）  
⑤差分検知  ポーリング  ⑥イメージ取得  ⑦デプロイ  ・テスト  ・イメージビルド 

ArgoCDの利点  • GUIがあり、クラスタの状態が分かりやすい  • Kuberenetesクラスタ上に構築可能  • 複数のマニフェスト管理ツールに対応  ◦ Helm ◦
Kustomize ◦ Ksonnet ◦ Jsonnet

• まとめ 

AppProject  • アプリケーションの論理的なグループを提供する  • 複数チームでのArgoCDの利用をサポート  ◦ 利用可能なGitリポジトリの制限  ◦ デプロイ先のclusterとnamespaceを制限  ◦
Applicationの配置先のnamespaceを制限  ◦ Project単位でのRBACのコントロール

AppProject  apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: ehozon-project namespace: argo-cd
spec: description : Ehozon Project sourceRepos : - 'https://github.com/rakus-dev/zabuton-ehozon-apps.git' destinations : - namespace: ehozon-applications server: https://kubernetes.default.svc - namespace: ehozon-backend server: https://172.18.20.112:6443 sourceNamespaces : - 'ehozon-applications' roles: - name: developer description : developer role policies: - p, proj:ehozon-:developer, applications, get, ehozon-project/*, allow 接続先のGitを指定   デプロイ先のclusterとnamespaceを指定   Application配置先のnamespaceを指定   ユーザのRoleを指定  

Hoge Project  Fuga Project  Hoge  Fuga  Hoge  Fuga  Hoge  Fuga 
Argo Cluster  Hoge Cluster  Fuga Cluster  Hoge Team  Fuga Team  Hoge App  Fuga App 

• まとめ 

Application  • デプロイされたリソースを管理するためのCRD  • Projectに紐づいていており、許可されたnamespace に配置することで特定のclusterにリソースをデプロイする  • チームごとにApplicationを定義することで必要なリソースを管理する

Application  apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: ehozon-applications namespace: ehozon-applications
spec: project: ehozon-project source: repoURL: 'https://github.com/rakus-dev/zabuton-ehozon-apps.git' path: apps targetRevision: main destination: server: 'https://kubernetes.default.svc' namespace: ehozon-applications syncPolicy: automated: prune: true selfHeal: true AppProjectで許可されたnamespace   AppProjectで許可されたGitリポジトリ   AppProjectで許可されたnamespace  

ApplicationSet  • 複数のApplicationを束ねて管理するCRD  • GeneratorとTemplateによってApplicationを管理する。List Generator, Cluster Generator, Git Generatorなど複数のGeneratorが適用されており、
用途に合わせて選択可能  • 自社ではDevelop, Staging, Productなど複数のcluster向けにApplicationを配置する目的で、Cluster Generatorを利用している  • Applicationと同様にProjectの設定で配置するnamespaceを制限することが可能（ArgoCDのver2.8以降）

ApplicationSet  apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: ehozon-backend-applicationset namespace: ehozon-applications
spec: generators: - clusters: selector: matchLabels: type: cluster project: ehozon template: metadata: name: 'ehozon-backend' spec: project: ehozon-project source: repoURL: 'https://github.com/rakus-dev/zabuton-ehozon-apps.git' path: manifests/ehozon-backend targetRevision: '{{metadata.labels.targetRevision}}' helm: releaseName: 'ehozon-backend' destination: server: '{{server}}' namespace: ehozon-backend AppProjectで許可されたnamespace   Cluster Generatorを利用   ArgoCDに登録されたCluster情報を取得   取得したCluster分だけApplicationを作成   namespaceはApplicationSetと同様になる  

App Of Apps  • ArgoCDで複数のApplicationをインストールする際に利用される構成パターン  • 親となるApplicationの下に複数のApplicationがぶら下がる  • 親となるApplicationを登録するだけで複数のApplicationのインストー
ル可能  • Applicationが増えた場合もArgoCD側での操作不要でGitに ApplicationのManifestを追加するだけで対応可能

App Of Apps  /sre-zabuton-ehozon-apps ├── apps │ ├── ehozon-backend.yaml │
└── ehozon-frontend.yaml ├── argocd │ └── ehozon-applications.yaml └── manifests ├── ehozon-backend │ ├── Chart.yaml │ ├── templates │ │ ├── _helpers.tpl │ │ ├── deployment.yaml │ │ ├── ingress.yaml │ │ └── service.yaml │ └── values.yaml └── ehozon-frontend ├── Chart.yaml ├── templates │ ├── _helpers.tpl │ ├── deployment.yaml │ ├── ingress.yaml │ └── service.yaml └── values.yaml 子Application郡   親Application  デプロイ用のhelmチャート   ディレクトリ内のApplicationを全て適用   Applicationを追加する場合はapps内にyamlを追加     ※ラクスではApplicationSetを配置している   子Applicationから参照されるHelmチャート     デプロイ時はvalues.yamlを更新する  

App Of Apps 

• まとめ 

Helm  • Kubernetesのマニフェストを管理するためのパッケージマネージャー  • Helmチャートと言われるファイル郡を作成して管理する  ◦ Chart.yaml：名前、バージョン、依存関係などを定義する  ◦ Values.yaml：チャート内の変数で利用する値を定義する  ◦
templates/：マニフェストの雛形を格納する  　Values.yamlの値を適用してマニフェストを作成する  ◦ charts/：依存関係のあるHelmチャートのダウンロード先

Helm Chart  /argo-cd ├── Chart.yaml ├── templates │ ├── clusterrole.yaml
│ ├── clusterrolebinding.yaml │ ├── ingress.yaml │ ├── serviceaccount.yaml │ └── vaultstaticsecret.yaml └── values.yaml apiVersion: v2 name: argo-cd description: A Helm chart for argo-cd type: application version: 1.0.0 dependencies: - name: argo-cd version: "5.53.8" repository: "https://argoproj.github.io/argo-helm" dependency buildを利用してArgoCDをインストール   その後にtemplates/配下のマニフェストを適用     1つのApplicationとしてArgoCDに関連するリソースも管理している 

Helm Chart  templates/ingress.yamlで作成したリソース  

• まとめ 

まとめ  GitOpsの取り組み事例を紹介しましたが最初は今とは違う形で検討が進んでいました。  その時々の課題に合わせて構成を変更しているので今後もサービスの増加に合わせて変化していくと思います。  各社の方が様々な方法で運用をしていますので、それらを参考にしつつ継続的に改善していきたいと思います。 

株式会社ラクス    設立 2000年11月1日設立  従業員数連結：2,197名単体：1,253名（2023年3月31日現在）  
関連子会社 Rakus Vietnam Co.,Ltd.(ベトナム子会社)  株式会社ラクスパートナーズ（国内子会社）  株式会社ラクスライトクラウド（国内子会社）  　　　株式会社ラクスHRテック（国内子会社）  株式会社ラクスみらい（国内子会社）  事業所東京・大阪・名古屋・福岡・札幌・広島  上場証券取引所東証プライム(3923) 

バックオフィス  営業・経理部門  人事部門  フロントオフィス  カスタマーサポート部門  営業・マーケティング部門    その他  IT技術で企業の成長と働く方々を幸せにするために、  業務効率化に貢献するクラウドサービス（SaaS）を複数展開しています。 

技術/デザイン情報のご案内  エンジニア・デザイナー  組織の紹介サイト  ※ＱＲコードはデンソーウェーブの登録商標です

ご清聴ありがとうございました 

ArgoCDによるGitOps導入 / ArgoCD GitOps

ArgoCDによるGitOps導入 / ArgoCD GitOps

mekka

More Decks by mekka

Featured

Transcript