ウェビナーシリーズ:CircleCIおよびArgo CDを使用したKubernetesでのGitOpsツールセット

前書き

Kubernetesを使用してアプリケーションをデプロイすると、柔軟なスケーリング、分散コンポーネントの管理、アプリケーションのさまざまなバージョンの制御など、インフラストラクチャに大きな利点をもたらすことができます。 ただし、制御の強化に伴い、複雑なコード開発、バージョン管理、変更ログ、自動展開およびロールバックのCI / CDシステムを手動で管理するのが特に難しくなる可能性があります。 これらの困難を考慮して、DevOpsエンジニアは、_GitOps_と呼ばれるツールのシステムやベストプラクティスを含むKubernetes CI / CD自動化のいくつかの方法を開発しました。 GitOpsは、https://www.weave.works/blog/gitops-operations-by-pull-request [2017ブログ投稿]でhttps://www.weave.works/[Weaveworks]によって提案されているように、httpsを使用します。 //git-scm.com/[Git]をCI / CDプロセスの「単一の真実のソース」として、プロジェクトごとに単一の共有リポジトリにコード変更を統合し、プルリクエストを使用してインフラストラクチャと展開を管理します。

Hasura、https://によって開発されたhttps://github.com/hasura/gitkube[Gitkube]を含む、Kubernetes上のDevOpsプロセスのフォーカルポイントとしてGitを使用する多くのツールがあります。 github.com/weaveworks/flux[Flux] by Weaveworks、およびhttps://jenkins.io/projects/jenkins-x/[Jenkins X]、https://www.digitalocean.com/community/tutorialsのトピック/ webinar-series-kubernetes-package-management-with-helm-and-ci-cd-with-jenkins-x [このシリーズの2番目のウェビナー]。 このチュートリアルでは、クラウドベースのGitOps CI / CDシステムをセットアップするために使用できる2つの追加ツールのデモを実行します。継続的統合ツールhttps://circleci.com/[CircleCI]およびhttps: //argoproj.github.io/argo-cd[Argo CD]、宣言型継続的デリバリーツール。

CircleCIはhttps://github.com/[GitHub]またはhttps://bitbucket.org/[Bitbucket]リポジトリを使用して、アプリケーション開発を整理し、Kubernetesでのビルドとテストを自動化します。 Gitリポジトリと統合することにより、CircleCIプロジェクトは、アプリケーションコードに変更が加えられたことを検出して自動的にテストし、変更の通知とテスト結果を電子メールまたはhttps://slack.com/などの他のコミュニケーションツールで送信できます。 [スラック]。 CircleCIは、これらすべての変更とテスト結果のログを保持します。ブラウザーベースのインターフェイスにより、ユーザーはテストをリアルタイムで監視できるため、チームは常にプロジェクトのステータスを把握できます。

KubernetesのArgoワークフロー管理エンジンのサブプロジェクトとして、Argo CDはGitHubリポジトリに変更が加えられるたびにアプリケーションを自動的に同期およびデプロイする継続的配信ツールを提供します。 アプリケーションの展開とライフサイクルを管理することにより、Kubernetes環境でのバージョン管理、構成、アプリケーション定義のソリューションを提供し、わかりやすいユーザーインターフェイスで複雑なデータを整理します。 ksonnetアプリケーション、https://kustomize.io/ [Kustomize]アプリケーション、https://helm.sh/ [Helm]チャートなど、いくつかのタイプのKubernetesマニフェストを処理できます。 YAML / jsonファイル。GitHub、GitLab、およびBitbucketからのWebhook通知をサポートします。

*CI/CD with Kubernetes *シリーズの最後の記事では、これらのGitOpsツールを試してみます。 :

  • CircleCIおよびGitHubを使用したアプリケーションテストを自動化するためのパイプライントリガーのセットアップ。

  • Argo CDを使用してGitHubリポジトリからアプリケーションを同期およびデプロイします。

このチュートリアルの終わりまでに、GitOpsツールセットを使用してKubernetes上にCI / CDパイプラインを構築する方法の基本を理解できます。

前提条件

このチュートリアルを実行するには、次のものが必要です。

  • 16 GB以上のRAMを搭載したUbuntu 16.04サーバー。 このチュートリアルはデモンストレーションのみを目的としているため、コマンドは* root *アカウントから実行されます。 *このアカウントの制限されていない権限は、本番環境向けのベストプラクティスに準拠しておらず、システムに影響する可能性があります。*このため、仮想マシンやhttps:/などのテスト環境でこれらの手順に従うことをお勧めします。 /www.digitalocean.com/products/droplets/[DigitalOcean Droplet]。

  • https://hub.docker.com [Docker Hubアカウント]。 Docker Hubの使用開始の概要については、https://docs.docker.com/docker-hub/ [これらの手順]を参照してください。

  • https://github.com [GitHub]アカウントとGitHubの基本的な知識。 GitHubの使用方法の入門書については、https://www.digitalocean.com/community/tutorials/how-to-create-a-pull-request-on-github [GitHubでプルリクエストを作成する方法]をご覧ください。 ]チュートリアル。

  • Kubernetesの概念に精通している。 詳細については、記事https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes[Kubernetesの概要]を参照してください。

  • kubectlコマンドラインツールを使用したKubernetesクラスター。 このチュートリアルは、ローカル環境でhttps://github.com/kubernetes/minikube[Minikube]を使用して設定されたシミュレーションKubernetesクラスターでテストされています。真のKubernetesクラスターをセットアップします。 Minikubeクラスターを作成するには、このシリーズの2番目のウェビナーのステップ1、https://www.digitalocean.com/community/tutorials/webinar-series-kubernetes-package-management-with-helm-and-ci-cdに従ってください-with-jenkins-x [Helmを使用したKubernetesパッケージ管理およびJenkins Xを使用したCI / CD]。

ステップ1-CircleCIワークフローのセットアップ

この手順では、コードのテスト、イメージの構築、およびそのイメージのDocker Hubへのプッシュという3つのジョブを含む標準CircleCIワークフローを作成します。 テスト段階では、CircleCIはhttps://docs.pytest.org/en/latest/[pytest]を使用して、サンプルRSVPアプリケーションのコードをテストします。 次に、アプリケーションコードのイメージをビルドし、そのイメージをDockerHubにプッシュします。

まず、CircleCIにGitHubアカウントへのアクセス権を付与します。 これを行うには、お気に入りのWebブラウザーでhttps://circleci.com/ [+ https:// circleci.com / +]に移動します。

image:https://assets.digitalocean.com/articles/cart_64920/CircleCI_Main_Site.png [CircleCI Landing Page]

ページの右上に*サインアップ*ボタンがあります。 このボタンをクリックしてから、次のページで* GitHubでサインアップ*をクリックします。 CircleCI Webサイトでは、GitHub資格情報の入力を求められます。

image:https://assets.digitalocean.com/articles/cart_64920/CircleCI_GitHub_Sign_In.png [GitHub CircleCIページにサインイン]

ここにユーザー名とパスワードを入力すると、CircleCIにGitHubメールアドレスの読み取り、キーのデプロイ、リポジトリへのサービスフックの追加、リポジトリのリストの作成、GitHubアカウントへのSSHキーの追加が許可されます。 これらの権限は、CircleCIがGitリポジトリの変更を監視して対応するために必要です。 CircleCIにアカウント情報を提供する前に、要求された権限について詳しく知りたい場合は、https://circleci.com/docs/2.0/gh-bb-integration/#permissions-overview [CircleCI documentation]を参照してください。

これらの権限を確認したら、GitHubの資格情報を入力して、[サインイン]をクリックします。 CircleCIはその後、GitHubアカウントと統合し、ブラウザをCircleCIウェルカムページにリダイレクトします。

image:https://assets.digitalocean.com/articles/cart_64920/CircleCI_Welcome_Page.png [CircleCIのようこそページ]

CircleCIダッシュボードにアクセスできるようになったので、別のブラウザーウィンドウを開き、このウェビナーのGitHubリポジトリhttps://github.com/do-community/rsvpapp-webinar4[`+https://github.comに移動します/ do-community / rsvpapp-webinar4 + `]。 GitHubへのサインインを求められたら、ユーザー名とパスワードを入力します。 このリポジトリには、https://cloudyuga.guru/explore [CloudYuga]チームによって作成されたサンプルRSVPアプリケーションがあります。 このチュートリアルでは、このアプリケーションを使用してGitOpsワークフローを示します。 画面の右上にある[フォーク]ボタンをクリックして、このリポジトリをGitHubアカウントにフォークします。

リポジトリをフォークすると、GitHubは `+ https:// github.com // rsvpapp-webinar4 +`にリダイレクトします。 画面の左側に、* Branch:master ボタンが表示されます。 このボタンをクリックして、このプロジェクトのブランチのリストを表示します。 ここで、 master ブランチは、アプリケーションの現在の公式バージョンを指します。 一方、 dev ブランチは開発サンドボックスであり、 master *ブランチで公式バージョンに変更を昇格する前に変更をテストできます。 * dev *ブランチを選択します。

このデモンストレーションリポジトリの開発セクションにいるので、パイプラインのセットアップを開始できます。 CircleCIでは、アプリケーションをテストするために必要な手順を記述するYAML構成ファイルがリポジトリに必要です。 フォークしたリポジトリには、すでにこのファイルが `+ .circleci / config.yml +`にあります。 CircleCIのセットアップを練習するには、このファイルを削除して独自のファイルを作成してください。

この設定ファイルを作成するには、* Create new file *ボタンをクリックして、 `+ .circleci / config.yml +`という名前のファイルを作成します。

image:https://assets.digitalocean.com/articles/cart_64920/GitHub_Repo_CircleCI_Config.png [GitHub新しいファイルの作成ページ]

このファイルをGitHubで開いたら、CircleCIのワークフローを構成できます。 このファイルの内容について学習するには、セクションを1つずつ追加します。 まず、次を追加します。

circleci/config.yml
version: 2
jobs:
 test:
   machine:
     image: circleci/classic:201808-01
     docker_layer_caching: true
   working_directory: ~/repo

. . .

上記のコードでは、「+ version 」は使用するCircleCIのバージョンを指します。 ` jobs:test:`は、アプリケーションのテストを設定していることを意味し、 ` machine:image:`は、CircleCIがテストを行う場所を示します。この場合、 ` circleci / classic:201808-01 + `画像。

次に、テスト中にCircleCIが実行するステップを追加します。

circleci/config.yml
. . .
   steps:
     - checkout
     - run:
         name: install dependencies
         command: |
           sudo rm /var/lib/dpkg/lock
           sudo dpkg --configure -a
           sudo apt-get install software-properties-common
           sudo add-apt-repository ppa:fkrull/deadsnakes
           sudo apt-get update
           sleep 5
           sudo rm /var/lib/dpkg/lock
           sudo dpkg --configure -a
           sudo apt-get install python3.5
           sleep 5
           python -m pip install -r requirements.txt

     # run tests!
     # this example uses Django's built-in test-runner
     # other common Python testing frameworks include pytest and nose
     # https://pytest.org
     # https://nose.readthedocs.io

     - run:
         name: run tests
         command: |
           python -m pytest tests/test_rsvpapp.py

. . .

テストのステップは、「+ steps:」の後にリストされ、「-checkout 」で始まります。これにより、プロジェクトのソースコードがチェックアウトされ、ジョブのスペースにコピーされます。 次に、 `-run:name:install dependencies `ステップは、リストされたコマンドを実行して、テストに必要な依存関係をインストールします。 この場合、https://www.djangoproject.com/ [Django Web framework’s]組み込みのテストランナーとテストツール ` pytest `を使用します。 CircleCIがこれらの依存関係をダウンロードした後、 ` -run:name:run tests +`ステップは、CircleCIにアプリケーションでテストを実行するよう指示します。

+ test`ジョブが完了したら、次の内容を追加して + build`ジョブを説明します。

circleci/config.yml
. . .
 build:

   machine:
     image: circleci/classic:201808-01
     docker_layer_caching: true
   working_directory: ~/repo

   steps:
     - checkout
     - run:
         name: build image
         command: |
           docker build -t $DOCKERHUB_USERNAME/rsvpapp:$CIRCLE_SHA1 .

 push:
   machine:
     image: circleci/classic:201808-01
     docker_layer_caching: true
   working_directory: ~/repo
   steps:
     - checkout
     - run:
         name: Push image
         command: |
           docker build -t $DOCKERHUB_USERNAME/rsvpapp:$CIRCLE_SHA1 .
           echo $DOCKERHUB_PASSWORD | docker login --username $DOCKERHUB_USERNAME --password-stdin
           docker push $DOCKERHUB_USERNAME/rsvpapp:$CIRCLE_SHA1

. . .

前と同じように、 + machine:image:+`は、CircleCIが指定されたイメージに基づいて仮想マシンでアプリケーションを構築することを意味します。 `+ steps:+`の下に、再び `+-checkout`があり、その後に -run:name:build image`があります。 これは、CircleCiがDocker Hubリポジトリの ` rsvpapp `イメージからDockerコンテナを構築することを意味します。 CircleCIインターフェースで環境変数 ` $ DOCKERHUB_USERNAME +`を設定します。このYAMLファイルの完成後にチュートリアルで説明します。

`+ build `ジョブが完了すると、 ` push +`ジョブは結果のイメージをDocker Hubアカウントにプッシュします。

最後に、次の行を追加して、前に定義したジョブを調整する `+ workflows +`を決定します。

circleci/config.yml
. . .
workflows:
 version: 2
 build-deploy:
   jobs:
     - test:
         context: DOCKERHUB
         filters:
           branches:
             only: dev
     - build:
         context: DOCKERHUB
         requires:
           - test
         filters:
           branches:
             only: dev
     - push:
         context: DOCKERHUB
         requires:
           - build
         filters:
           branches:
             only: dev

これらの行は、CircleCIが「+ test」、「+ build」、および「+ push」ジョブを正しい順序で実行することを保証します。 `+ context:DOCKERHUB `は、テストが行​​われるコンテキストを指します。 このYAMLファイルを完成させた後、このコンテキストを作成します。 ` only:dev +`行は、リポジトリの* dev ブランチに変更がある場合にのみトリガーされるようにワークフローを制限し、CircleCIが dev *からコードをビルドおよびテストすることを保証します。

`+ .circleci / config.yml +`ファイルのすべてのコードを追加したので、その内容は次のようになります。

circleci/config.yml
version: 2
jobs:
 test:
   machine:
     image: circleci/classic:201808-01
     docker_layer_caching: true
   working_directory: ~/repo

   steps:
     - checkout
     - run:
         name: install dependencies
         command: |
           sudo rm /var/lib/dpkg/lock
           sudo dpkg --configure -a
           sudo apt-get install software-properties-common
           sudo add-apt-repository ppa:fkrull/deadsnakes
           sudo apt-get update
           sleep 5
           sudo rm /var/lib/dpkg/lock
           sudo dpkg --configure -a
           sudo apt-get install python3.5
           sleep 5
           python -m pip install -r requirements.txt

     # run tests!
     # this example uses Django's built-in test-runner
     # other common Python testing frameworks include pytest and nose
     # https://pytest.org
     # https://nose.readthedocs.io

     - run:
         name: run tests
         command: |
           python -m pytest tests/test_rsvpapp.py

 build:

   machine:
     image: circleci/classic:201808-01
     docker_layer_caching: true
   working_directory: ~/repo

   steps:
     - checkout
     - run:
         name: build image
         command: |
           docker build -t $DOCKERHUB_USERNAME/rsvpapp:$CIRCLE_SHA1 .

 push:
   machine:
     image: circleci/classic:201808-01
     docker_layer_caching: true
   working_directory: ~/repo
   steps:
     - checkout
     - run:
         name: Push image
         command: |
           docker build -t $DOCKERHUB_USERNAME/rsvpapp:$CIRCLE_SHA1 .
           echo $DOCKERHUB_PASSWORD | docker login --username $DOCKERHUB_USERNAME --password-stdin
           docker push $DOCKERHUB_USERNAME/rsvpapp:$CIRCLE_SHA1

workflows:
 version: 2
 build-deploy:
   jobs:
     - test:
         context: DOCKERHUB
         filters:
           branches:
             only: dev
     - build:
         context: DOCKERHUB
         requires:
           - test
         filters:
           branches:
             only: dev
     - push:
         context: DOCKERHUB
         requires:
           - build
         filters:
           branches:
             only: dev

このファイルをリポジトリの* dev *ブランチに追加したら、CircleCIダッシュボードに戻ります。

次に、前のYAMLファイルで概説したワークフローに必要な環境変数を格納するCircleCIコンテキストを作成します。 画面の左側に、* SETTINGS *ボタンがあります。 これをクリックし、「組織」の見出しの下にある「コンテキスト」を選択します。 最後に、画面の右側にある[コンテキストの作成]ボタンをクリックします。

image:https://assets.digitalocean.com/articles/cart_64920/CircleCI_Create_Context_Screen.png [CircleCIのコンテキスト画面の作成]

CircleCIは、このコンテキストの名前を尋ねます。 「+ DOCKERHUB 」と入力し、[作成]をクリックします。 コンテキストを作成したら、* DOCKERHUB *コンテキストを選択し、*環境変数の追加*ボタンをクリックします。 最初に、名前「 DOCKERHUB_USERNAME +」を入力し、*値*にDocker Hubユーザー名を入力します。

image:https://assets.digitalocean.com/articles/cart_64920/Git_Hub_Docker_Username.png [CircleCIの環境変数の追加画面]

次に、別の環境変数を追加しますが、今回は「+ DOCKERHUB_PASSWORD +」という名前を付けて、*値*フィールドにDocker Hubのパスワードを入力します。

  • DOCKERHUB コンテキスト用に2つの環境変数を作成したら、テストRSVPアプリケーション用のCircleCIプロジェクトを作成します。 これを行うには、左側のメニューから[プロジェクトの追加]ボタンを選択します。 これにより、アカウントに関連付けられたGitHubプロジェクトのリストが生成されます。 リストから rsvpapp-webinar4 を選択し、 Set Up Project *ボタンをクリックします。

これで、*プロジェクトの設定*ページにいることがわかります。

image:https://assets.digitalocean.com/articles/cart_64920/CircleCI_Set_Up_Project_Screen.png [CircleCIのプロジェクト画面の設定]

画面の上部で、CircleCIは `+ config.yml +`ファイルを作成するよう指示します。 すでにこれを行っているので、ページの右側にある[ビルドの開始]ボタンを見つけるために下にスクロールします。 これを選択すると、CircleCIにアプリケーションの変更の監視を開始するように指示します。

[ビルドの開始]ボタンをクリックします。 CircleCIは、ビルドの進行状況/ステータスページにリダイレクトしますが、まだビルドはありません。

パイプライントリガーをテストするには、 `+ https:// github.com // rsvpapp-webinar4 `で最近分岐したリポジトリに移動し、 ` dev `ブランチのみで変更を加えます。 ブランチフィルター ` only:dev `を ` .circleci / config +`ファイルに追加したため、* dev *ブランチに変更がある場合にのみCIがビルドされます。 * dev *ブランチコードを変更すると、CircleCIがユーザーインターフェイスで新しいワークフローをトリガーしたことがわかります。 実行中のワークフローをクリックすると、CircleCIの実行内容の詳細が表示されます。

image:https://assets.digitalocean.com/articles/cart_64920/CircleCI_Running_Workflow.png [CircleCIプロジェクトワークフローページ]

CircleCIワークフローがGitOps CI / CDシステムの継続的統合の側面を処理することで、Kubernetesクラスター上にArgo CDをインストールして構成し、継続的展開に対応できます。

手順2-KubernetesクラスターでのArgo CDのインストールと構成

CircleCIがGitHubを使用してソースコードの変更の自動テストをトリガーするように、Argo CDはKubernetesクラスターをGitHubリポジトリに接続して、変更をリッスンし、更新されたアプリケーションを自動的にデプロイします。 これを設定するには、最初にArgo CDをクラスターにインストールする必要があります。

最初に、 `+ argocd +`という名前のhttps://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/[namespace]を作成します。

kubectl create namespace argocd

このネームスペース内で、Argo CDは継続展開ワークフローの作成に必要なすべてのサービスとリソースを実行します。

次に、Argoの公式GitHubリポジトリからhttps://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml[Argo CD manifest]をダウンロードします。

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd//manifests/install.yaml

このコマンドでは、「-n +」フラグは「 kubectl 」にマニフェストを名前空間「 argocd 」に適用するよう指示し、「-f +」は適用するマニフェストのファイル名を指定します。この場合は1つはArgoリポジトリからダウンロードしました。

+ kubectl get`コマンドを使用すると、 + argocd`名前空間で実行中のポッドを見つけることができます。

kubectl get pod -n argocd

このコマンドを使用すると、次のような出力が生成されます。

NAME                                      READY     STATUS    RESTARTS   AGE
application-controller-6d68475cd4-j4jtj   1/1       Running   0          1m
argocd-repo-server-78f556f55b-tmkvj       1/1       Running   0          1m
argocd-server-78f47bf789-trrbw            1/1       Running   0          1m
dex-server-74dc6c5ff4-fbr5g               1/1       Running   0          1m

Argo CDがクラスターで実行されているので、コマンドラインからプログラムを制御できるように、Argo CD CLIツールをダウンロードします。

curl -sSL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/download//argocd-linux-amd64

ファイルをダウンロードしたら、 `+ chmod +`を使用して実行可能にします。

chmod +x /usr/local/bin/argocd

Argo CDサービスを見つけるには、ネームスペース `+ argocd `で ` kubectl get +`コマンドを実行します。

kubectl get svc -n argocd argocd-server

次のような出力が得られます。

OutputNAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
argocd-server   ClusterIP   10.109.189.243   <none>        80/TCP,443/TCP   8m

次に、Argo CD APIサーバーにアクセスします。 このサーバーには自動的に外部IPがないため、ローカルワークステーションのブラウザーからアクセスできるように、まずAPIを公開する必要があります。 これを行うには、 + kubectl port-forward +`を使用して、ローカルワークステーションのポート `+ 8080 +`を上記の出力の `+ argocd-server +`サービスの `+ 80 + TCPポートに転送します。

kubectl port-forward svc/argocd-server -n argocd 8080:80

出力は次のようになります。

OutputForwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080

`+ port-forward +`コマンドを実行すると、コマンドプロンプトが端末から消えます。 Kubernetesクラスターにさらにコマンドを入力するには、新しいターミナルウィンドウを開き、リモートサーバーにログオンします。

接続を完了するには、 + ssh +`を使用して、ローカルマシンから `+ 8080 +`ポートを転送します。 最初に、追加のターミナルウィンドウを開き、ローカルワークステーションから次のコマンドを入力します。++ `はKubernetesクラスターを実行しているリモートサーバーのIPアドレスに置き換えます。

ssh -L 8080:localhost:8080 [email protected]

Argo CDサーバーがローカルワークステーションに公開されていることを確認するには、ブラウザーを開き、URL「+ localhost:8080+」に移動します。 Argo CDのランディングページが表示されます。

image:https://assets.digitalocean.com/articles/cart_64920/Argo_CD_Sign_In_Page.png [ArgoCDのサインインページ]

Argo CDをインストールし、そのサーバーをローカルワークステーションに公開したので、次のステップに進み、GitHubをArgo CDサービスに接続します。

ステップ3-Argo CDをGitHubに接続する

Argo CDがGitHubをリッスンし、展開をリポジトリに同期できるようにするには、まずArgo CDをGitHubに接続する必要があります。 これを行うには、Argoにログインします。

デフォルトでは、Argo CDアカウントのパスワードはArgo CD APIサーバーのポッドの名前です。 リモートサーバーにログインしているが、ポート転送を処理していないターミナルウィンドウに戻ります。 次のコマンドでパスワードを取得します。

kubectl get pods -n argocd -l app=argocd-server -o name | cut -d'/' -f 2

Argo APIサーバーを実行しているポッドの名前を取得します。

Outputargocd-server-

次のコマンドを入力して、CLIからログインします。

argocd login localhost:8080

次のプロンプトが表示されます。

OutputWARNING: server certificate had error: x509: certificate signed by unknown authority. Proceed insecurely (y/n)?

このデモンストレーションの目的で、「+ y 」と入力して安全な接続なしで続行します。 Argo CDは、ユーザー名とパスワードの入力を求めます。 ユーザー名に* admin *を入力し、パスワードに完全な ` argocd-server +`ポッド名を入力します。 資格情報を入力すると、次のメッセージが表示されます。

Output'admin' logged in successfully
Context 'localhost:8080' updated

ログインしたので、次のコマンドを使用してパスワードを変更します。

argocd account update-password

Argo CDは、現在のパスワードと、変更したいパスワードを尋ねてきます。 安全なパスワードを選択し、プロンプトで入力します。 これが完了したら、新しいパスワードを使用して再ログインします。

argocd relogin

もう一度パスワードを入力すると、以下が得られます。

OutputContext 'localhost:8080' updated

Argo CDクラスターの外部のクラスターにアプリケーションをデプロイする場合は、アプリケーションクラスターの資格情報をArgo CDに登録する必要があります。 このチュートリアルのように、Argo CDとアプリケーションが同じクラスター上にある場合、Argo CDをアプリケーションに接続するときにKubernetes APIサーバーとして `+ https:// kubernetes.default.svc +`を使用します。

外部クラスターを登録する方法を示すには、まずKubernetesコンテキストのリストを取得します。

kubectl config get-contexts

次のものが得られます。

OutputCURRENT   NAME       CLUSTER    AUTHINFO   NAMESPACE
*            minikube   minikube

クラスターを追加するには、強調表示された名前の代わりにクラスターの名前を指定して、次のコマンドを入力します。

argocd cluster add

この場合、前述のコマンドは次のようになります。

OutputINFO[0000] ServiceAccount "argocd-manager" created
INFO[0000] ClusterRole "argocd-manager-role" created
INFO[0000] ClusterRoleBinding "argocd-manager-role-binding" created, bound "argocd-manager" to "argocd-manager-role"
Cluster 'minikube' added

Argo CDのログイン資格情報をセットアップし、外部クラスターを追加する方法をテストしたので、Argo CDのランディングページに移動して、ローカルワークステーションからログインします。 Argo CDは、Argo CDアプリケーションページに移動します。

image:https://assets.digitalocean.com/articles/cart_64920/Argo_CD_Applications_PAge.png [Argo CDアプリケーション画面]

ここから、左側のツールバーから*設定*アイコンをクリックし、リポジトリ*をクリックしてから、 CONNECT REPO *をクリックします。 Argo CDには、GitHub情報の3つのフィールドが表示されます。

image:https://assets.digitalocean.com/articles/cart_64920/Argo_CD_Connect_Git_Repo_Page.png [Argo CD Connect Gitリポジトリページ]

*リポジトリURL *のフィールドに「+ https://github.com//rsvpapp-webinar4+」と入力し、GitHubのユーザー名とパスワードを入力します。 資格情報を入力したら、画面の上部にある[接続]ボタンをクリックします。

デモRSVPアプリを含むリポジトリをArgo CDに接続したら、左側のツールバーから*アプリ*アイコンを選択し、画面の右上隅にある* + *ボタンをクリックして、*新しいアプリケーションを選択します。 *。 [*リポジトリの選択]ページで、RSVPアプリのGitHubリポジトリを選択し、[次へ]をクリックします。 次に、[ディレクトリからアプリを作成]を選択して、アプリケーションパラメータの確認を求めるページに移動します。

image:https://assets.digitalocean.com/articles/cart_64920/Argo_CD_Review_Application_Page.png [Argo CD Reviewアプリケーションパラメーターページ]

  • Path フィールドは、アプリケーションのYAMLファイルがGitHubリポジトリ内のどこにあるかを指定します。 このプロジェクトでは、「+ k8s 」と入力します。 *アプリケーション名*には、「 rsvpapp 」と入力し、*クラスターURL *には、ドロップダウンメニューから「 https://kubernetes.default.svc+」を選択します。ArgoCDとアプリケーションは同じKubernetesクラスターにあるためです。 最後に、 Namespace *に `+ default +`を入力します。

アプリケーションパラメータを入力したら、画面上部の[作成]をクリックします。 アプリケーションを表すボックスが表示されます。

image:https://assets.digitalocean.com/articles/cart_64920/Argo_CD_3.png [rsvpappを備えたArgo CDアプリケーションページ]

  • Status:の後に、アプリケーションがGitHubリポジトリで OutOfSync であることがわかります。 アプリケーションをGitHubにそのまま展開するには、 ACTIONS をクリックして、 Sync を選択します。 しばらくすると、アプリケーションのステータスが Synced *に変わります。これは、Argo CDがアプリケーションをデプロイしたことを意味します。

アプリケーションがデプロイされたら、アプリケーションボックスをクリックして、アプリケーションの詳細図を見つけます。

image:https://assets.digitalocean.com/articles/cart_64920/Argo_CD_Application_Details.png [rsvpappのArgo CDアプリケーション詳細ページ]

Kubernetesクラスタでこの展開を見つけるには、リモートサーバーのターミナルウィンドウに戻り、次のように入力します。

kubectl get pod

アプリを実行しているポッドで出力を受け取ります:

OutputNAME                      READY     STATUS    RESTARTS   AGE
rsvp-755d87f66b-hgfb5     1/1       Running   0          12m
rsvp-755d87f66b-p2bsh     1/1       Running   0          12m
rsvp-db-54996bf89-gljjz   1/1       Running   0          12m

次に、サービスを確認します。

kubectl get svc

RSVPアプリとMongoDBデータベースのサービスに加えて、アプリを実行しているポートの番号があり、以下で強調表示されます。

NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP        2h
mongodb      ClusterIP   10.102.150.54   <none>        27017/TCP      25m
rsvp         NodePort    10.106.91.108   <none>        80:/TCP   25m

ブラウザで「:」に移動し、上記の強調表示された番号を使用して、展開されたRSVPアプリを見つけることができます。

image:https://assets.digitalocean.com/articles/cart_64920/RSVP_App.png [RSVPアプリケーション]

Argo CDを使用してアプリケーションをデプロイしたので、Continuous Deploymentシステムをテストし、GitHubと自動的に同期するように調整できます。

手順4-継続的な展開設定のテスト

Argo CDをセットアップしたら、プロジェクトに変更を加えてアプリケーションの新しいビルドをトリガーすることにより、継続的展開システムをテストします。

ブラウザで、 `+ https:// github.com // rsvpapp-webinar4 `に移動し、* master *ブランチをクリックし、ビルドされたイメージを使用してアプリをデプロイするために ` k8s / rsvp.yaml `ファイルを更新しますCircleCIをベースとして。 次のように、「 image:nkhare / rsvpapp:」の後に「 dev +」を追加します。

rsvpapp-webinar2 / k8s / rsvp.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
 name: rsvp
spec:
 replicas: 2
 selector:
   matchLabels:
     app: rsvp
 template:
   metadata:
     labels:
       app: rsvp
   spec:
     containers:
     - name: rsvp-app
       image: nkhare/rsvpapp:
       imagePullPolicy: Always
       livenessProbe:
         httpGet:
           path: /
           port: 5000
         periodSeconds: 30
         timeoutSeconds: 1
         initialDelaySeconds: 50
       env:
       - name: MONGODB_HOST
         value: mongodb
       ports:
       - containerPort: 5000
         name: web-port
. . .

Docker Hubから元のイメージをプルする代わりに、Argo CDは継続的インテグレーションシステムで作成された* dev *イメージを使用してアプリケーションをビルドします。

変更をコミットしてから、ArgoCD UIに戻ります。 まだ何も変わっていないことに気付くでしょう。これは、自動同期を有効にしておらず、アプリケーションを手動で同期する必要があるためです。

アプリケーションを手動で同期するには、画面右上の青い丸をクリックして、同期*をクリックします。 新しいメニューが表示され、新しいリビジョンに名前を付けるフィールドと、 PRUNE *というラベルの付いたチェックボックスが表示されます。

image:https://assets.digitalocean.com/articles/cart_64920/Argo_CD_Sync_Page.png [Argo CDの同期ページ]

このチェックボックスをクリックすると、Argo CDが新しいアプリケーションを起動すると、古いバージョンが破壊されます。 * PRUNE ボックスをクリックしてから、画面上部の SYNCHRONIZE *をクリックします。 アプリケーションの古い要素がスピンダウンし、新しい要素がCircleCIで作成されたイメージと共にスピンアップします。 新しいイメージに変更が含まれている場合、これらの新しい変更は、URL `:`でアプリケーションに反映されます。

前述のように、Argo CDには自動同期オプションもあり、変更を加えるとアプリケーションに変更が組み込まれます。 これを有効にするには、リモートサーバーのターミナルを開き、次のコマンドを使用します。

argocd app set  --sync-policy automated

リビジョンが誤って削除されないようにするために、自動同期のデフォルトではプルーンがオフになっています。 自動プルーニングをオンにするには、前のコマンドの最後に `+-auto-prune +`フラグを追加するだけです。

Kubernetesクラスターに継続的展開機能を追加したので、CircleCIとArgo CDを使用したGitOps CI / CDシステムのデモを完了しました。

結論

このチュートリアルでは、GitHubリポジトリのコードを変更したときにテストをトリガーし、更新されたイメージを構築するCircleCIを使用してパイプラインを作成しました。 また、Argo CDを使用してアプリケーションをデプロイし、CircleCIによって統合された変更を自動的に組み込みました。 これらのツールを使用して、Gitを整理テーマとして使用する独自のGitOps CI / CDシステムを作成できるようになりました。

Gitについて詳しく知りたい場合は、https://www.digitalocean.com/community/tutorial_series/an-introduction-to-open-source [An Introduction to Open Source]シリーズのチュートリアルをご覧ください。 Gitリポジトリーと統合する他のDevOpsツールを調べるには、https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-gitlab-on-ubuntu-18-04 [How Ubuntu 18.04にGitLabをインストールして設定するには]。

Related