Rancher Fleetはかなり多くのKubernetesクラスタの統合管理とGitOpsを実現するためのソフトウェアです。 Kubernetesクラスタの管理については100万クラスターの管理も可能としています。
Rancher FleetにはGitOpsの機能も実装されています。Rancher 2.6以降のバージョンをインストールしている場合はすでにインストール済みになっているため、Rancher Fleetを使ってGitOpsをすぐ始められます。
では早速、GitOpsスタイルでアプリケーションの集中管理を行なってみましょう。なお、Rancherとノード周りはセットアップ済みであることを前提としており、その手順については本記事では言及していません。これについては以前の記事にまとめましたので、そちらをご参照ください。
また、GitOpsについてはこれまた以前の記事で紹介していますので、そちらがお役に立つと幸いです。
Rancher FleetでGitOpsを試す
まずはRancherにログインします。RancherのDashboardにWebブラウザーでアクセスします。
Rancherにログインしたら、Continuous Delivery 画面を呼び出します。これがRancher Fleetの管理画面になります。
あとは右上のCreateボタンを押して、GitOpsのための設定をするだけです。設定方法は他のGitOpsツール（例えばArgo CD）と同じような感じで、Gitソースやブランチもしくはリビジョン、パス、デプロイ先などを指定していきます。
Git Repoが登録されると、あとは自動的に指定したクラスターに対してコンテナアプリケーションが展開され、Gitソースのコミットなどをトリガーとしてソースが更新されると自動的に最新のコードベースでアプリケーションがデプロイされます。
Rancher Fleetを単独で利用する
これまでの流れでは、Rancher 2.6でインストール済みのRancher Fleetを使ってきましたが、Rancher Fleet自体の利用にはRancherは必須ではありません。なんらかのKubernetes Clusterがすでにある場合は、そのクラスターでRancher Fleetを動かすことが可能です。
この場合、Helmを使ってクラスターにRancher Fleetをセットアップします。 執筆日時点で最新のv0.3.9をセットアップするには次のように実行します。
helm -n fleet-system install --create-namespace --wait \
fleet-crd https://github.com/rancher/fleet/releases/download/v0.3.9/fleet-crd-0.3.3.tgz
helm -n fleet-system install --create-namespace --wait \
fleet https://github.com/rancher/fleet/releases/download/v0.3.9/fleet-0.3.3.tgz
このあとはGit Repoの定義マニフェストを作って、適用することでRancher Fleetを使ったGitOps実行環境のセットアップは完了です。Git Repoが登録されると、あとは自動的に指定したクラスターに対してコンテナアプリケーションが展開されます。Gitソースのコミットなどをトリガーとして、ソースが更新されると自動的に最新のコードベースでアプリケーションがデプロイされます。
cat > example.yaml << "EOF" apiVersion: fleet.cattle.io/v1alpha1 kind: GitRepo metadata: name: sample # This namespace is special and auto-wired to deploy to the local cluster namespace: fleet-local spec: # Everything from this repo will be ran in this cluster. You trust me right? repo: "https://github.com/rancher/fleet-examples" paths: - simple EOF kubectl apply -f example.yaml
このマニフェストの書き方についての詳細は、公式ドキュメントの「Registering」をご覧ください。
GitOpsのメリット
GitOpsはGitを基点としてコンテナアプリケーションを実行するのに最適な手段です。CIツールをベースとした「CI Ops」では、一般的にコンテナアプリケーションの実行環境の用意からアプリケーションの開発、テスト、アプリケーションのデプロイまでを一貫して行います。
これに対し、GitOpsという手法はCIとCDのプロセスを分離するという考え方を取っており、コンテナアプリケーションの開発者はKubernetesのことを考える必要がなく、アプリケーション開発とテストだけに集中できます。
一方、インフラ管理者はKubernetesクラスターとGitOpsツールの管理だけに集中できます。環境によってはコンテナイメージのレジストリーやCI/CDで利用するコンテナイメージのベースイメージの管理や脆弱性スキャンも役割を分離するのも良いかもしれません。
CI/CDの1から10まで全てをできたらそれは格好良いですが、実際やってみると非常に手間暇がかかりますし、作業者のコストが大きいです。
例えばインフラ管理、構築に関するノウハウは日進月歩なので、時の流れによって古い方法が使えなくなり、定期的な試行錯誤が必要になります。 それに加えて、アプリケーションのテストに関するノウハウも新しいソリューションが生まれては消えを繰り返しています。 これを一貫して効率よく行うのは至難の業です。
GitOpsのように役割を分担することによって、各担当者はCIとCDの整備に集中できると思います。その結果、アプリケーションの品質の向上につながる可能性があるわけです。
