OpenShift LocalでGitOpsを体感する
はじめに
Red Hat OpenShift Administration III: Scaling Kubernetes Deployments in the Enterprise (DO380) のトレーニングではOpenShift GitOpsを扱います。インストラクターとしてGitOpsを教えていて思うことは、GitOpsを使いこなすためにはツールへ慣れが必要ですし、理解の定着には練習が大事だということです。
この記事では、OpenShift LocalにOpenShift GitOpsをインストールし、GitOpsの機能を試してみたいと思います。 OpenShift Local上で繰り返しデプロイを試す中でツールの癖や特性を理解できるようになります。OpenShift Localのインストール方法と基本操作方法については以下の記事を参照してください。
GitOpsを使う上で、アプリケーション開発者とGitOps管理者は、それぞれOpenShiftユーザーが異なる場合があります。この記事ではOpenShiftのアカウントを使ってGitOpsにログインする方法を示します。こうすることで、ログインユーザーの権限によってGitOps関連のリソース操作を制御できるようになります。
OpenShfit GitOpsとは
OpenShift GitOpsは、Gitサーバーに上にマニフェストを格納しておくと、それをOpenShiftに自動的に反映してくれる自動化の仕組みです。
管理者がCLIコマンドを使って直接リソースを編集すると、いつ・どこで、誰が、該当リソースを修正したのかトラッキングが難しいです。オペミス等でいつのまにか既存のリソースを意図せずに変更してしまい、その結果、動作がおかしくなってしまったということもあると思います。
GitOpsを使ってマニフェストをGit上の一元管理することで、マニフェストの変更履歴管理が可能になります。さらに、Gitに登録されたマニフェストと実際のリソースの内容に違いが生じる(これをドリフトと言います)と、自動的にGitの情報に基づいてOpenShift上のリソースを修正してくれます。
OpenShift GitOpsは、Argo CDをベースにしたGitOpsのツールで、Operatorを使ってOpenShiftに簡単にインストールすることができます。
OpenShiftクラスター管理者の準備
クラスター管理者アカウントの作成
OpenShift GitOpsでは、Argo CDダッシュボードというWebコンソール上でリソースの監視や操作をおこないます。この記事ではArgo CDダッシュボード画面にOpenShiftのアカウントでログインする方法を紹介します。
OpenShift Localでは、kubeadminという管理者アカウントが用意されていますが、この記事では kubeadmin は使いません。OpenShift LocalにkubeadminでログインしてもArgo CDのリソース作成に失敗するからです。
kubeadminを使う代わりに、OpenShift Localにadminという名前のクラスター管理者用のOpenShiftアカウントを使用して、Argo CDの管理者権限の設定を行います。この記事で書いた方法はOpenShift Local向けではなく、OpenShift一般に適用できる方法です。OpenShiftに新規ユーザーを登録する手順は以下の記事にまとめてあります。
OpenShift GitOpsのインストール
OpenShift GitOps Operatorのインストール
OpenShift LocalのWebコンソールを開きます。Administratorパースペクティブにおいて、ナビゲーションメニューから [Oprators] > [Operator Hub] を開いて、OpenShift GitOpsという文字列を入力してOperatorを検索します。
Red Hat OpenShift GitOpsをクリックし、デフォルトの設定のまま [Install] ボタンを押します。
Install Operatorの画面でもデフォルト値のまま [Install] ボタンを押してインストールします。
インストールが開始したら、下のイメージのように Installed operator: ready for Useの表示が出るまで待ちます。
インストールが完了したら [View Operator] ボタンを押して Operator detailsの画面を表示します。
しばらくすると、画面右上に Web console update is available という警告が表示されるので、Refresh web consoleのリンクを押して、画面をリフレッシュしてください。
Operator detailsの画面において、Argo CDのタブを選択すると、openshift-gitopsというNamespaceにopenshift-gitopsという名前のArgo CDのリソースが作成されていることが確認できます。
Argo CDへのログイン
Argo CDカスタムリソースの確認
Operator detailsの画面において、Argo CDのタブのopenshift-gitopsという名前のArgo CDのリソースをYAMLエディタで開き、spec.rbac.policyの内容を確認します。
このspec.rbac.policyの部分を取り出すと以下のようになります。以下の定義が意味するのは、OpenShiftのsystem:cluster-adminsグループまたはcluster-adminsグループのメンバーは、Argo CDの管理者としてArgo CDのリソースを操作できるということです。
rbac:
defaultPolicy: ''
policy: |
g, system:cluster-admins, role:admin
g, cluster-admins, role:admin
scopes: '[groups]'
Argo CD組み込みロール role:readonly を使えば、developerとしてArgo CDダッシュボードにログインして、Argo CDダッシュボードのリソースをreadonlyで閲覧する、といった設定も可能です。Argo CDのRBACの詳細は以下を参照してください。
Argo CDの管理者を設定する
上のポリシーの定義を変更せずに、OpenShiftのcluster-adminsグループにadminアカウントを登録することによって、adminをArgo CDの管理者として設定します。ocコマンドを使ってcluster-adminsグループを作成し、adminをそのグループに登録します。グループ作成操作にはクラスター管理者の権限が必要ですので、adminでログインします。
$ oc login -u admin -p redhat https://api.crc.testing:6443
<略>
$ oc get groups cluster-admins
Error from server (NotFound): groups.user.openshift.io "cluster-admin" not found
$ oc adm groups new cluster-admins
group.user.openshift.io/cluster-admins created
$ oc adm groups add-users cluster-admins admin
group.user.openshift.io/cluster-admins added: "admin"
$ oc get groups cluster-admins
NAME USERS
cluster-admins admin
Argo CDダッシュボードを開く
アカウントの準備ができたので、Argo CDダッシュボードを開きましょう。Webコンソール右上のアプリケーションメニューから [Cluster Argo CD] を選択してください。
Argo CDのログイン画面が表示されたら、[LOG IN VIA OPENSHIFT] のボタンを押して、OpenShiftアカウントの admin でログインしてください。
OpenShift Localのログイン画面が表示されたら、2段目の htpasswd のボタンを押して、admin でログインします。
Authorize Accessの画面が表示されたらデフォルト設定のままで [Allow selected permissions] ボタンを押します。
以下がArgo CDのダッシュボード画面です。ここにArgo CDで管理する対象リソースを定義するArgo CDアプリケーションを作成します。
Argo CDアプリケーションの作成
GitHubリポジトリ
今回の記事用にGitHubにリポジトリを用意しました。Apache HTTP Serverをデプロイするだけのとてもシンプルなアプリケーションです。
プロジェクトの作成
アプリケーションをデプロイするためにはプロジェクトが必要です。OpenShift Localに developer でログインして note-demo という名前のプロジェクトを作成します。このプロジェクトを作成すると note-demo という名前のNamespaceも一緒に作られます。
$ oc login -u developer -p developer https://api.crc.testing:6443
<略>
$ oc new-project note-demo
Now using project "note-demo" on server "https://api.crc.testing:6443".
<略>
$ oc get namespace note-demo
NAME STATUS AGE
note-demo Active 9s
Namespaceへのラベル設定
GitOpsの関連リソースはopenshift-gitopsというプロジェクトに存在します。openshift-gitops NamespaceにいるGitOpsからnote-demo Namespaceのリソースを管理できるようにするためには、note-demo Namespaceにargocd.argoproj.io/managed-by=openshift-gitopsというラベルを設定する必要があります。Namespaceへのラベル設定にはクラスター管理者の権限が必要なのでadminでログインし直します。
$ oc login -u admin -p redhat https://api.crc.testing:6443
<略>
$ oc label namespace note-demo argocd.argoproj.io/managed-by=openshift-gitops
Argo CDアプリケーションの作成
Argo CDアプリケーションを作成するためにArgo CDダッシューボード画面の真ん中あたりの [CREATE APPLICATION] ボタンを押します。
Argo CDアプリケーションの作成画面で、以下の項目を入力します。
Application Name: note-demo
Project Name: default
SYNC POLICY: Automatic
SELF HEALにチェックを入れる
Repository URL: https://github.com/fminamot/note-demo
Revision: HEAD
Path: app
Cluster URL: https://kubernetes.default.svc
Namespace: note-demo
入力が終わったら画面左上の [CREATE] ボタンを押します。その後、note-demoという名前の四角のカードが表示されます。これはArgo CDアプリケーションを表します。
note-demoアプリケーションをクリックすると、note-demoが木構造で表示されます。これは、GitHubから読み出されたマニフェストがOpenShift内にリソースとして作成されていることを表しています。右端に色がついているノードが4つ縦に並んでいますが、これがPodになります。
note-demoの木構造の直下にhttpd Deploymentを表すノードがありますので、クリックしてください。以下のようにDeploymentリソースの詳細情報が表示ます。画面の下の方のLIVE MANIFESTの内容をスクロールして見るとreplicas: 4となっている箇所を確認できるはずです。
ここまでの手順で、note-demoプロジェクトにApache HTTP Serverがインストールされていますので、Webコンソールで確認してみましょう。WebコンソールをDeveloperパーステクティブに切り替えて、ナビゲーションメニューから [Topology] を選択します。プロジェクトメニューで note-demo を選択すると以下の図のような画面が表示され、4つのPodが存在することが確認できます。
httpd Deploymentリソースで指定したreplicasは4なので、4つのPodがRunning状態で存在しています。これは、GitHub上のマニフェストと実際にリソースの状態が同期している状態です。
GitOpsを試す!
構成ドリフトを作り出す
GitHubに登録されたマニフェストと、実際のサーバーの設定が一致していないことを構成ドリフト (Configuration Drift) と言います。ここで、OpenShiftのリソースの状態を無理やり変更して、GitHubと同期していない構成ドリフトの状態を作り出してみます。試しに、Webコンソール上の操作でhttpd DeploymentリソースのPodの数を4から2に減らしてみましょう。
Argo CDダッシュボードを見ると、OutOfSyncと警告が表示されています。Argo CDが構成ドリフトを検出したことを示しています。
ここで http Deploymentノードをクリックして [Diff] のタブを選択すると、以下のようにLIVE MANIFESTとDESIRED MANIFESTとの間の差分が表示されます。
自己修復の効果確認
しばらくするとダッシュボードのOutOfSyncの表示が自動的にSynchedに切り替わります。
再びWebコンソールで、httpd Deploymentリソースのreplicasの数を確認すると、手動で2に減らしたにも関わらず4に復活しています。これがGitOpsが提供するセルフヒーリング(自己修復)の機能です。
おわりに
OpenShift LocalにOpenShift GitOpsをインストールして、OpenShiftアカウントでログインための設定方法を紹介しました。OpenShift Localという小さな環境でもArgo CDダッシュボードを使ってGitOpsのリソース管理の練習ができることを理解していただけたと思います。
Argo CDの認証の設定が間違っていると、Argo CDアプリケーション作成時にPermission Errorになります。なぜエラーになったかわからずに試行錯誤を繰り返すことも多いと思います。OpenShift Localを使えば時間を気にせずに好きなだけいろいろな設定を試すことができるのがいいですね。
Gitに登録したマニフェストの内容に構文エラーがあったとしてもGitへのコミット&プッシュは成功します。Argo CDのダッシュボードの中で初めてエラーが検出されますので、開発者もエラー内容を確認するためにダッシュボードにアクセスしたいはずです。
今回は、OpenShiftのクラスター管理者アカウントadminでArgo CDダッシュボードにログインしてみましたが、Argo CDリソースのRBAC設定を変更すれば、開発者アカウントdeveloperで、Argo CDダッシュボードのリソースを閲覧させることも可能です。ぜひ試してみてください。