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

投稿日: 2019-11-08 2022-04-20
タグ: CI/CD, deployment, git, Kubernetes, Ubuntu 16.04

ウェビナーシリーズ

この記事は、Kubernetesを使用したCI/CDの実行に関するウェビナーシリーズを補足するものです。このシリーズでは、リリース管理、クラウドネイティブツール、サービスメッシュ、Kubernetesで使用できるCI / CDツールについて説明し、アプリケーションの構築、テスト、デプロイにクラウドネイティブアプローチを採用する方法について説明します。これは、CI/CDのベストプラクティスとKubernetesをワークフローに統合することに関心のある開発者や企業を支援するように設計されています。

このチュートリアルには、シリーズの最後のセッションであるCircleCIとArgoCDを使用したKubernetesのGitOpsツールセットの概念とコマンドが含まれています。

警告：このチュートリアルの手順は、デモンストレーションのみを目的としています。その結果、本番環境での展開に必要なベストプラクティスとセキュリティ対策に準拠していません。

<br /> <a href="https://www.youtube.com/watch?v=ZxE1psdIpyY" target="_blank" rel="noopener">YouTubeビデオを見る</a><br />

序章

Kubernetesを使用してアプリケーションをデプロイすると、柔軟なスケーリング、分散コンポーネントの管理、アプリケーションのさまざまなバージョンの制御など、インフラストラクチャ上で大きなメリットが得られます。ただし、制御が強化されると複雑さが増し、協調的なコード開発、バージョン管理、変更ログ、自動展開およびロールバックのCI/CDシステムを手動で管理することが特に困難になる可能性があります。これらの問題を説明するために、DevOpsエンジニアは、 GitOps と呼ばれるツールのシステムやベストプラクティスなど、Kubernetes CI/CD自動化のいくつかの方法を開発しました。 GitOpsは、2017ブログ投稿でWeaveworks によって提案されているように、 GitをCI/CDプロセスの「信頼できる唯一の情報源」として使用し、コードの変更を統合します。プロジェクトごとに単一の共有リポジトリを使用し、プルリクエストを使用してインフラストラクチャとデプロイを管理します。

Hasuraによって開発されたGitkube、Weaveworksによる Flux 、 Jenkinsなど、Kubernetes上のDevOpsプロセスのフォーカルポイントとしてGitを使用するツールは多数あります。 X 、このシリーズの2番目のウェビナーのトピック。このチュートリアルでは、独自のクラウドベースのGitOps CI/CDシステムをセットアップするために使用できる2つの追加ツールのデモンストレーションを実行します。継続的インテグレーションツールCircleCIとArgoCD[ X213X]、宣言型の継続的デリバリーツール。

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

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

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

CircleCIとGitHubを使用してアプリケーションテストを自動化するためのパイプライントリガーの設定。
GitHubリポジトリからのアプリケーションをArgoCDと同期してデプロイします。

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

前提条件

このチュートリアルに従うには、次のものが必要です。

16GB以上のRAMを搭載したUbuntu16.04サーバー。このチュートリアルはデモンストレーションのみを目的としているため、コマンドはrootアカウントから実行されます。このアカウントの制限のない特権は、本番環境に対応したベストプラクティスに準拠しておらず、システムに影響を与える可能性があることに注意してください。このため、仮想マシンやDigitalOceanドロップレット。
DockerHubアカウント。 Docker Hubの使用を開始するための概要については、これらの手順を参照してください。
GitHubアカウントとGitHubの基本的な知識。 GitHubの使用方法の入門書については、GitHubでプルリクエストを作成する方法のチュートリアルをご覧ください。
Kubernetesの概念に精通していること。詳細については、記事Kubernetesの概要を参照してください。
kubectlコマンドラインツールを使用したKubernetesクラスター。このチュートリアルは、 Minikube を使用してローカル環境でセットアップされた、シミュレートされたKubernetesクラスターでテストされています。このプログラムを使用すると、真のKubernetesクラスターをセットアップしなくても自分のマシンでKubernetesツールを試すことができます。 Minikubeクラスターを作成するには、このシリーズの2番目のウェビナーのステップ1、Kubernetesパッケージ管理とHelmおよびCI/CDとJenkinsXに従ってください。

ステップ1—CircleCIワークフローの設定

このステップでは、コードのテスト、イメージのビルド、およびそのイメージのDockerHubへのプッシュという3つのジョブを含む標準のCircleCIワークフローをまとめます。テストフェーズでは、CircleCIは pytest を使用して、サンプルRSVPアプリケーションのコードをテストします。次に、アプリケーションコードのイメージをビルドし、そのイメージをDockerHubにプッシュします。

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

CircleCI Landing Page

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

ここにユーザー名とパスワードを入力すると、CircleCIは、GitHubメールアドレスの読み取り、キーのデプロイとリポジトリへのサービスフックの追加、リポジトリのリストの作成、GitHubアカウントへのSSHキーの追加を行うことができます。これらの権限は、CircleCIがGitリポジトリの変更を監視して対応するために必要です。 CircleCIにアカウント情報を提供する前に、要求された権限について詳しく知りたい場合は、CircleCIのドキュメントを参照してください。

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

Welcome page for CircleCI

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

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

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

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

GitHub Create a new file Page

このファイルを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ステップは、リストされたコマンドを実行して、テストに必要な依存関係をインストールします。この場合、DjangoWebフレームワークの組み込みテストランナーとテストツール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がDockerHubリポジトリのrsvpappイメージからDockerコンテナを構築することを意味します。 CircleCIインターフェースで$DOCKERHUB_USERNAME環境変数を設定します。これについては、このYAMLファイルの完了後にチュートリアルで説明します。

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

最後に、次の行を追加して、前に定義したジョブを調整する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ボタンがあります。これをクリックし、ORGANIZATION見出しの下にあるContextsを選択します。最後に、画面の右側にあるコンテキストの作成ボタンをクリックします。

Create Context Screen for CircleCI

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

Add Environment Variable Screen for CircleCI

次に、別の環境変数を追加しますが、今回はDOCKERHUB_PASSWORDという名前を付け、ValueフィールドにDockerHubのパスワードを入力します。

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

注： rsvpapp-webinar4 がリストに表示されない場合は、CircleCIページをリロードしてください。 GitHubプロジェクトがCircleCIインターフェースに表示されるまでに時間がかかる場合があります。

これで、プロジェクトのセットアップページが表示されます。

Set Up Project Screen for CircleCI

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

ビルド開始ボタンをクリックします。 CircleCIは、まだビルドされていないビルドの進行状況/ステータスページにリダイレクトします。

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

CircleCI Project Workflow Page

CircleCIワークフローがGitOpsCI/ CDシステムの継続的インテグレーションの側面を処理することで、継続的デプロイに対応するためにKubernetesクラスターの上にArgoCDをインストールして構成できます。

ステップ2—KubernetesクラスターへのArgoCDのインストールと設定

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

まず、argocdという名前の名前空間を作成します。

kubectl create namespace argocd

この名前空間内で、ArgoCDは継続的デプロイワークフローを作成するために必要なすべてのサービスとリソースを実行します。

次に、Argoの公式GitHubリポジトリからArgoCDマニフェストをダウンロードします。

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

このコマンドでは、-nフラグがkubectlにマニフェストを名前空間argocdに適用するように指示し、-fはマニフェストのファイル名を指定します。この場合、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/v0.9.2/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

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

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ポートを転送します。まず、追加のターミナルウィンドウを開き、ローカルワークステーションから次のコマンドを入力します。remote_server_IP_addressは、Kubernetesクラスターを実行しているリモートサーバーのIPアドレスに置き換えられます。

ssh -L 8080:localhost:8080 root@remote_server_IP_address

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

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

ステップ3—ArgoCDをGitHubに接続する

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

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

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

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

Output
argocd-server-b686c584b-6ktwf

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

argocd login localhost:8080

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

[secondary_label Output]
WARNING: server certificate had error: x509: certificate signed by unknown authority. Proceed insecurely (y/n)?

このデモでは、yと入力して、安全な接続なしで続行します。次に、ArgoCDはユーザー名とパスワードの入力を求めます。ユーザー名には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クラスターの外部のクラスターにアプリケーションをデプロイする場合は、アプリケーションクラスターのクレデンシャルをArgoCDに登録する必要があります。このチュートリアルの場合のように、Argo CDとアプリケーションが同じクラスター上にある場合は、ArgoCDをアプリケーションに接続するときにKubernetesAPIサーバーとしてhttps://kubernetes.default.svcを使用します。

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

kubectl config get-contexts

あなたが得るでしょう：

OutputCURRENT   NAME       CLUSTER    AUTHINFO   NAMESPACE
*         minikube   minikube   minikube

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

argocd cluster add minikube

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

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は、ArgoCDアプリケーションページに移動します。

Argo CD Applications Screen

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

Argo CD Connect Git Repo Page

リポジトリURLのフィールドに、https://github.com/your_GitHub_username/rsvpapp-webinar4と入力し、GitHubのユーザー名とパスワードを入力します。クレデンシャルを入力したら、画面上部のCONNECTボタンをクリックします。

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

Argo CD Review application parameters Page

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

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

Argo CD APPLICATIONS Page with rsvpapp

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

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

Argo CD Application Details Page for rsvpapp

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:31350/TCP   25m

app_port_number の前に強調表示された番号を使用して、ブラウザーでyour_remote_server_IP_address:app_port_numberに移動すると、デプロイされたRSVPアプリを見つけることができます。

RSVP Application

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

ステップ4—継続的展開のセットアップをテストする

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

ブラウザでhttps://github.com/your_GitHub_username/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: dev
        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
. . .

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

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

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

Synchronization Page for Argo CD

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

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

argocd app set rsvpapp --sync-policy automated

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

Kubernetesクラスターに継続的デプロイ機能を追加したので、CircleCIとArgoCDを使用したGitOpsCI/CDシステムのデモが完了しました。

結論

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

Gitについて詳しく知りたい場合は、オープンソース入門シリーズのチュートリアルをご覧ください。 Gitリポジトリと統合するその他のDevOpsツールについては、 Ubuntu18.04にGitLabをインストールして構成する方法をご覧ください。

getdocs

13036