[。注意]##
ウェビナーシリーズ
この記事は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/
に移動します。
ページの右上に、Sign Upボタンがあります。 このボタンをクリックしてから、次のページのSign Up with GitHubをクリックします。 CircleCI Webサイトでは、GitHub資格情報の入力を求められます。
ここにユーザー名とパスワードを入力すると、CircleCIにGitHubメールアドレスの読み取り、キーのデプロイ、リポジトリへのサービスフックの追加、リポジトリのリストの作成、GitHubアカウントへのSSHキーの追加が許可されます。 これらの権限は、CircleCIがGitリポジトリの変更を監視して対応するために必要です。 CircleCIにアカウント情報を提供する前に、要求された権限について詳しく知りたい場合は、CircleCI documentationを参照してください。
これらの権限を確認したら、GitHubの認証情報を入力し、Sign Inをクリックします。 CircleCIはその後、GitHubアカウントと統合し、ブラウザを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で開いたら、CircleCIのワークフローを構成できます。 このファイルの内容について学習するには、セクションを1つずつ追加します。 まず、次を追加します。
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が実行するステップを追加します。
. . .
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
ジョブを説明します。
. . .
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
を決定します。
. . .
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
ファイルのすべてのコードを追加したので、その内容は次のようになります。
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ボタンをクリックします。
CircleCIは、このコンテキストの名前を尋ねます。 DOCKERHUB
と入力し、Createをクリックします。 コンテキストを作成したら、DOCKERHUBコンテキストを選択し、Add Environment Variableボタンをクリックします。 最初に、名前DOCKERHUB_USERNAME
を入力し、ValueにDockerHubのユーザー名を入力します。
次に、別の環境変数を追加しますが、今回は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ページが表示されます。
画面上部の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ワークフローが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
サービスの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
ポートを転送します。 まず、追加のターミナルウィンドウを開き、ローカルワークステーションから次のコマンドを入力します。remote_server_IP_address
は、Kubernetesクラスターを実行しているリモートサーバーのIPアドレスに置き換えられます。
ssh -L 8080:localhost:8080 [email protected]_server_IP_address
Argo CDサーバーがローカルワークステーションに公開されていることを確認するには、ブラウザーを開いてURLlocalhost:8080
に移動します。 Argo CDのランディングページが表示されます。
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アプリケーションページに移動します。
ここから、左側のツールバーのSettingsアイコンをクリックし、Repositoriesをクリックしてから、CONNECT REPOをクリックします。 Argo CDには、GitHub情報の3つのフィールドが表示されます。
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を選択して、アプリケーションパラメータの確認を求めるページに移動します。
Pathフィールドは、アプリケーションのYAMLファイルがGitHubリポジトリのどこにあるかを指定します。 このプロジェクトでは、k8s
と入力します。 Argo CDとアプリケーションは同じKubernetesクラスター上にあるため、Application Nameにはrsvpapp
と入力し、Cluster URLにはドロップダウンメニューからhttps://kubernetes.default.svc
を選択します。 最後に、Namespaceにdefault
と入力します。
アプリケーションパラメータを入力したら、画面上部のCREATEをクリックします。 アプリケーションを表すボックスが表示されます。
Status:の後、アプリケーションがGitHubリポジトリでOutOfSyncであることがわかります。 アプリケーションをGitHubにそのままデプロイするには、ACTIONSをクリックして、Syncを選択します。 しばらくすると、アプリケーションのステータスがSyncedに変わります。これは、ArgoCDがアプリケーションを展開したことを意味します。
アプリケーションがデプロイされたら、アプリケーションボックスをクリックして、アプリケーションの詳細図を見つけます。
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
の強調表示された番号を使用します。
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というラベルの付いたチェックボックスが表示されます。
このチェックボックスをクリックすると、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をご覧ください。