GitOps
Operations by Pull Request
GitをSingle Source of Truthとして扱い、ほぼすべての操作をGitを介して行う。
- 宣言的なリソースプロビジョニングとデプロイ
- システム全体が単一のGitリポジトリで管理される
- 運用上の変更はPull Requestを介して行う
- diffツールで差異を検知しアラートを通知。syncツールで収束することが可能
- ロールバックや監査ログもGit経由で行う
What exactly is GitOps? By using Git as our source of truth, we can operate almost everything. For example, version control, history, peer review, and rollback happen through Git without needing to poke around with tools like kubectl.
- Our provisioning of AWS resources and deployment of k8s is declarative
- Our entire system state is under version control and described in a single Git repository
- Operational changes are made by pull request (plus build & release pipelines)
- Diff tools detect any divergence and notify us via Slack alerts; and sync tools enable convergence
- Rollback and audit logs are also provided via Git
Continuous Delivery and GitOps Workflows
開発者はGitを扱える前提のPull Requestベースのソフトウェアデリバリーフローになっている。
- 新機能のレビューのためPull RequestがGitHubにPushされる
- Pull Requestはレビューと承認の後、GitにMergeされる
- GitのMergeをトリガーにCIとBuild Pipelineが実行され、コンテナイメージがレジストリにPushされる
- ‘Deployment Automator’ がコンテナイメージレジストリの変更を検知し、構成リポジトリのマニフェストファイルを更新
- ‘Deployment Synchronizer’ がクラスター(稼働中のクラスター)が古いことを検知し、変更されたマニフェストファイルを構成リポジトリから取得し、クラスターにデプロイする
- A pull request for a new feature is pushed to GitHub for review.
- The code is reviewed and approved by a colleague. After the code is revised, and re-approved it is merged to Git.
- The Git merge triggers the CI and build pipeline, runs a series of tests and then eventually builds a new image and deposits to the new image to a registry.
- The Weave Cloud ‘Deployment Automator’ watches the image registry, notices the image, pulls the new image from the registry and updates its YAML in the config repo.
- The Weave Cloud ‘Deployment Synchronizer’ (installed to the cluster), detects that the cluster is out of date. It pulls the changed manifests from the config repo and deploys the new feature to production.
Pull pipeline & Push pipleline
一般的なCI/CDツールはPushベースのモデルで、CIをトリガーにデプロイまで行う。このモデルの問題点は本番クラスターの外部に認証情報を公開する必要があるということ。一方、GitOpsではPullベースのモデルで、クラスターが変更を検知して自動的に同期するため、外部に認証情報を持つ必要がない。
（ここはWeaveWorksの宣伝ポイント）
Most CI/CD tools available today use a push-based model. A push-based pipeline means that code starts with the CI system and may continue its path through a series of encoded scripts or uses ‘kubectl’ by hand to push any changes to the Kubernetes cluster.
The reason you don’t want to use your CI system as the deployment impetus or do it manually on the command line is because of the potential to expose credentials outside of your cluster. While it is possible to secure both your CI/CD scripts and the command line, you are working outside the trust domain of your cluster. This is generally not good practice and is why CI systems can be known as attack vectors for production.
