Rancher 2.6はEnterprise向けの機能が多数追加されると聞いていて気になっていました。特に気になっていたのはContinuous Delivery機能です。
Rancher 2.6以前もRancherを通じて「コンテナでDevOps」のようなことをする方法は用意されていました。Rancher 2.6ではより大規模、遠隔、エッジコンピューティングなどを想定した設計に刷新されたともあって、先日、時間があったので触ってみることにしました。
Rancher Serverのインストール
基本的にいつものようにドキュメントをみながらインストールするだけでした。DockerやKubernetesベースで動かします。
インストール後ログインすると、デザインが大幅に変わったホーム画面が表示されました。
Rancherにノードを追加
まずいつもの様にノードを追加します。今回はオンプレベースで動かすことにしたため、LinuxをセットアップしてDockerをインストールすることにしました。
Linuxはいつもの様にMAASを使ったため、Ubuntu Server 18.04をデプロイした後、Installing Dockerのドキュメントのスクリプトを使ってDockerをセットアップしました。
準備ができたらRancherのホームに戻り、左上のハンバーガーメニュー（三本線）をクリックして、Cluster Managementを選び、Cluster Createをします。
いつもの様にCustomクラスターを追加します。Customクラスターの設定は、クラスター名とKubernetesのバージョン、CNI、Ingressの設定などを行います。終わったら「Next」ボタンを押します。
Cluster Options画面ではいつものようにetcd、Control Plane、Workerを展開するノード上で指示されたコマンドを実行します。今回は4つのノードを用意して、次のように構成しました。
- node1 = etcd, Control Plane
- node2 = Worker
- node3 = Worker
- node4 = Worker
しばらく待つと、RancherのRKEによって、Kubernetesクラスターが作成されます。 同じ要領でサーバーを別に4つ用意して、同様にKubernetesクラスターを作成しました。
KubernetesにストレージLonghornを導入
Kubernetesでは、コンテナーアプリケーションに対して永続ストレージを提供するにはいくつかの方法がありますが、Rancherでサクッと永続ストレージを使うにはLonghornが便利です。
Rancherで管理しているKubernetesにストレージLonghornを導入するのはすごく簡単です。RancherのカタログからLonghornを選んでデプロイするだけです。デフォルトの設定のままでも問題なく利用可能でした。
RancherでCDを試す
RancherでCDを試すには、「Continuous Delivery」の画面にある機能(Fleetという技術が使われています)を利用します。この機能はRancher 2.5でも利用できましたが、2.6では画面デザインが統一されています。
使い方はこの動画で説明してくれているので、この機能をざっくりと説明するとFleetは、「最大100万クラスターの管理、GitOpsを実現」するためのツールです。
（Fleetのアーキテクチャ。Fleetの公式サイトより引用）
一番簡単な使い方としては、Kubernetesクラスターをクラスターグループにします。クラスターグループにタグを設定します。こうすることでGitOpsを利用するときにそのタグを指定することにより、同じグループに属したクラスターに対してコンテナアプリケーションのクラスターグループへの一括デプロイが可能になります。
Rancher CD設定例
次の様な設定を行っています。
- Name: gitops2 (GitOps名)
- Description: (説明の入力が必要であれば何か書く)
- Git Authentication: None (認証が必要であれば)
- Helm Authentication: None (認証が必要であれば)
- TLS Certificate Verification: Require a valid certificate
- Repogitry URL: https://github.com/ytooyama/fleet-example2.git
- Branch Name: (TagやコミットIDを指定する方法もある)
- Paths: simple (Gitソースのフォルダ)
- Deploy To
- Target: tokyo-shibuya1-cluster (コンテナクラスタを指定)
- Service Account Name: (オプション)
- Target Namespace: (オプション)
- Labels: None
- Annotations: None
Rancher CDにCIを追加するには
DevOpsってCI/CDをセットにするのが一般的かと思います。一方RancherのContinuous Delivery機能はCDのみなので、別途CI側のロジックを考えないといけません。
ただそこは使っているGit Server側が対応するところなので、例えばGitHubをソースコード管理に使っているなら、GitHubに対応するCIツールを連携させれば良いことになります。代表的なのは、Circle CIとかTravis CIとかJenkinsとか、GitHubを使っているならGitHub Actionsなどでも。
いずれかのCIツールで「コードのPush→CIが実行→(成功したら)コードを別のブランチにコミット」のようなフローを設定すれば、テストが通ったソースコードのブランチの新しいコミットを定期的に監視しているRancher CDが新しいコミットを認識して、うまくGitベースによる継続的デプロイをおこなってくれます。
ただ、Git Server側のソースとCIの設定に注意する必要があります。例えばソースコード管理にGitHubを利用し、CIにGitHub Actionを使う環境で次のようなYAMLファイルを作ってCIを回そうとすると、「GitHubにコードがコミット→CIが回る」となってしまい、失敗するか成功するかわからないコードを使ってRancher CDが回ってしまいます。
name: Validate container image
on:
- push
jobs:
validate-data-Docker:
permissions:
contents: read
runs-on: ubuntu-latest
container:
image: gcr.io/google-samples/gb-frontend:v4
steps:
- name: Validate workflows
run: |
cat controllers.js
cat index.html
php guestbook.php
working-directory: /var/www/html
そこで、次のActionsを利用して...
次の様に設定してみました。これによりコードのコミットはmainに行ない、CIが通ったコードはstableブランチにコミットされます。
あとはRancher CDで監視するブランチをmainではなくstableにすれば、テストが通ったコードを使ってコンテナアプリケーションの継続的デプロイが実現できそうです。
以下サンプルはファイルの表示のような単純なことしか行っていませんが、イメージの脆弱性チェックをおこなったりYAMLの構文チェックをおこなったり、ソースコードを色々なツールを使ってコード解析をおこなったりすると、より本格的になると思います。
name: Validate container image
on:
- push
jobs:
validate-data-Docker:
permissions:
contents: read
runs-on: ubuntu-latest
container:
image: gcr.io/google-samples/gb-frontend:v4
steps:
- name: Validate workflows
run: |
cat controllers.js
cat index.html
php guestbook.php
working-directory: /var/www/html
- name: Check the Container image
uses: stefanzweifel/git-auto-commit-action@v4
with:
commit_message: Automated Change
branch: stable
GitHub ActionsでCIが成功するとブランチstableにコミットされます。Fleetが設定したGitソースを定期的に監視しており、新しいコミットがされると新しいコードベースで継続的デプロイが実現できます。
コマンドラインツールを使って、アプリケーションを確認してみます。
[ytooyama@m1macmini] ~ % rancher kubectl get deployment INFO[0000] Saving config to /Users/ytooyama/.rancher/cli2.json NAME READY UP-TO-DATE AVAILABLE AGE frontend 2/2 2 2 21h redis-master 1/1 1 1 21h redis-slave 2/2 2 2 21h [ytooyama@m1macmini] ~ % rancher kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend NodePort 10.43.125.80 <none> 80:31750/TCP 21h kubernetes ClusterIP 10.43.0.1 <none> 443/TCP 2d1h redis-master ClusterIP 10.43.110.195 <none> 6379/TCP 21h [ytooyama@m1macmini] ~ % rancher context switch NUMBER CLUSTER NAME PROJECT ID PROJECT NAME PROJECT DESCRIPTION 1 testcluster4 c-2hhp6:p-qp8v8 System System project created for the cluster 2 testcluster4 c-2hhp6:p-spcw6 Default Default project created for the cluster 3 testcluster3 c-wj9ll:p-dfxwq System System project created for the cluster 4 testcluster3 c-wj9ll:p-xmx62 Default Default project created for the cluster 5 local local:p-hchcd System System project created for the cluster 6 local local:p-sl9tj Default Default project created for the cluster Select a Project:4 INFO[0023] Setting new context to project Default INFO[0023] Saving config to /Users/ytooyama/.rancher/cli2.json [ytooyama@m1macmini] ~ % rancher kubectl get deployment NAME READY UP-TO-DATE AVAILABLE AGE frontend 2/2 2 2 21h redis-master 1/1 1 1 21h redis-slave 2/2 2 2 21h [ytooyama@m1macmini] ~ % rancher kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend NodePort 10.43.55.148 <none> 80:31363/TCP 21h kubernetes ClusterIP 10.43.0.1 <none> 443/TCP 2d2h redis-master ClusterIP 10.43.65.117 <none> 6379/TCP 21h redis-slave ClusterIP 10.43.98.133 <none> 6379/TCP 21h
まとめ
Kubernetes環境はRancherにより短時間で簡単に構築できます。GitOps環境もKubernetesオブジェクトを構成するためのYAMLファイルなどをGitによってソースコード管理すれば、あとはそのGitに対応するCIツールを関連づけることでコンテナアプリケーションの継続的インテグレーション（CI）と継続的デプロイ（CD）が可能であることがわかりました。
Rancher 2.6は、なかなか良いですね。
