TOC

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

[。注意]＃＃

ウェビナーシリーズ

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

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

[.warning]＃Warning:このチュートリアルの手順は、デモンストレーションのみを目的としています。 その結果、本番環境に対応した導入に必要なベストプラクティスとセキュリティ対策に準拠していません。
＃

前書き

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

Hasuraによって開発されたGitkube、Weaveworksによって開発されたFlux、およびJenkins Xを含む、Kubernetes上のDevOpsプロセスのフォーカルポイントとしてGitを使用する多くのツールがあります。 second webinar in this series。 このチュートリアルでは、独自のクラウドベースのGitOps CI / CDシステムをセットアップするために使用できる2つの追加ツールのデモンストレーションを実行します。継続的インテグレーションツールCircleCIとArgo CD、宣言型継続的デリバリーツール。

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

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

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

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

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

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

前提条件

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

  • 16 GB以上のRAMを搭載したUbuntu 16.04サーバー。 このチュートリアルはデモンストレーションのみを目的としているため、コマンドはrootアカウントから実行されます。 Note that the unrestrained privileges of this account do not adhere to production-ready best practices and could affect your system.このため、仮想マシンやDigitalOcean Dropletなどのテスト環境でこれらの手順を実行することをお勧めします。

  • Docker Hub Account。 Docker Hubの使用開始の概要については、these instructionsを参照してください。

  • GitHubアカウントとGitHubの基本的な知識。 GitHubの使用方法の入門書については、How To Create a Pull Request on GitHubチュートリアルをご覧ください。

  • Kubernetesの概念に精通している。 詳細については、記事An Introduction to Kubernetesを参照してください。

  • kubectlコマンドラインツールを使用したKubernetesクラスター。 このチュートリアルは、Minikubeを使用してローカル環境でセットアップされたシミュレートされたKubernetesクラスターでテストされています。このプログラムを使用すると、真のKubernetesクラスターをセットアップしなくても自分のマシンでKubernetesツールを試すことができます。 Minikubeクラスターを作成するには、このシリーズの2番目のウェビナーのステップ1であるKubernetes Package Management with Helm and CI/CD with Jenkins Xに従います。

[[step-1 -—- setting-up-your-circleci-workflow]] ==ステップ1—CircleCIワークフローの設定

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

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

CircleCI Landing Page

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

Sign In to GitHub CircleCI Page

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

これらの権限を確認したら、GitHubの認証情報を入力し、Sign Inをクリックします。 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の設定を練習するには、このファイルを削除して独自のファイルを作成してください。

この構成ファイルを作成するには、Create new fileボタンをクリックして、.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

. . .

テストの手順は、- checkoutで始まり、steps:の後にリストされます。これにより、プロジェクトのソースコードがチェックアウトされ、ジョブのスペースにコピーされます。 次に、- run: name: install dependenciesステップは、リストされたコマンドを実行して、テストに必要な依存関係をインストールします。 この場合、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ジョブは結果のイメージを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ボタンをクリックします。

Create Context Screen for CircleCI

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

Add Environment Variable Screen for CircleCI

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

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

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

これで、Set Up Projectページが表示されます。

Set Up Project Screen for CircleCI

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

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

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

CircleCI Project Workflow Page

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

[[step-2 -—- installing-and-configuring-argo-cd-on-your-kubernetes-cluster]] ==ステップ2—KubernetesクラスターへのArgoCDのインストールと構成

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

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

kubectl create namespace argocd

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

次に、Argoの公式GitHubリポジトリからArgo CD manifestをダウンロードします。 

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           80/TCP,443/TCP   8m

次に、Argo CD APIサーバーにアクセスします。 このサーバーには自動的に外部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に移動します。 Argo CDのランディングページが表示されます。

Sign In Page for ArgoCD

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

[[step-3 -—- connecting-argo-cd-to-github]] ==ステップ3— ArgoCDを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-b686c584b-6ktwf

次のコマンドを入力して、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   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は、Argo CDアプリケーションページに移動します。

Argo CD Applications Screen

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

Argo CD Connect Git Repo Page

Repository URLのフィールドにhttps://github.com/your_GitHub_username/rsvpapp-webinar4と入力し、GitHubのユーザー名とパスワードを入力します。 認証情報を入力したら、画面上部のCONNECTボタンをクリックします。

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

Argo CD Review application parameters Page

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

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

Argo CD APPLICATIONS Page with rsvpapp

Status:の後、アプリケーションがGitHubリポジトリでOutOfSyncであることがわかります。 アプリケーションをGitHubにそのままデプロイするには、ACTIONSをクリックして、Syncを選択します。 しばらくすると、アプリケーションのステータスが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               443/TCP        2h
mongodb      ClusterIP   10.102.150.54           27017/TCP      25m
rsvp         NodePort    10.106.91.108           80:31350/TCP   25m

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

RSVP Application

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

[[step-4 -—- testing-your-continuous-deployment-setup]] ==ステップ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イメージを使用してアプリケーションをビルドするようになりました。

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

アプリケーションを手動で同期するには、画面の右上にある青い円をクリックし、Syncをクリックします。 新しいメニューが表示され、新しいリビジョンに名前を付けるフィールドと、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とArgo CDを使用したGitOps CI / CDシステムのデモを完了しました。

結論

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

Gitについて詳しく知りたい場合は、An Introduction to Open Sourceシリーズのチュートリアルをご覧ください。 Gitリポジトリと統合するその他のDevOpsツールについては、How To Install and Configure GitLab on Ubuntu 18.04をご覧ください。

Related