Auto DevOpsを使用して、アプリケーションをGoogle Kubernetes Engineにデプロイします

プラン: Free、Premium、Ultimate
提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

このチュートリアルでは、アプリケーションをGoogle Kubernetes Engine (GKE) にデプロイする方法の例を通して、Auto DevOpsの概要を説明します。

ここではKubernetesのインテグレーションをネイティブに使用しているため、Google Cloud Platformコンソールを使用してKubernetesクラスタを手動で作成する必要はありません。GitLabテンプレートから作成するアプリケーションを作成し、デプロイします。

これらの手順は、GitLabセルフマネージド版にも適用されます。ご自身のRunnerが構成されていることと、Google OAuthが有効になっていることを確認してください。

プロジェクトをGoogle Kubernetes Engineにデプロイするには、以下の手順に従ってください。:

Googleアカウントを設定する

Kubernetesクラスタを作成してGitLabプロジェクトに接続する前に、Google Cloud Platformアカウントが必要です。GmailやGoogleドライブへのアクセスに使用しているGoogleアカウントなどの既存のGoogleアカウントでサインインするか、新しいアカウントを作成してください。

必要なAPIと関連サービスを有効にするには、Kubernetes Engineのドキュメントの「始める前に」セクションに記載されている手順に従ってください。
Google Cloud Platformで課金アカウントを作成済みであることを確認してください。

すべての新しいGoogle Cloud Platform (GCP) アカウントは300ドルのクレジットを受け取り、Googleとの提携により、GitLabは、Google Kubernetes EngineとのGitLabインテグレーションを開始するために、新しいGCPアカウントに追加で200ドルを提供することができます。このリンクをたどってクレジットを申請してください。

Kubernetesクラスタを作成する

このガイドでは、GKEクラスタを作成し、Kubernetes向けGitLabエージェントをインストールするために、Terraformを使用する新しいプロジェクトを作成する必要があります。このプロジェクトは、Kubernetes向けGitLabエージェントの設定が格納されている場所です。

テンプレートからアプリケーションプロジェクトを作成する

GitLabプロジェクトのテンプレートを使用して開始します。名前が示すように、これらのプロジェクトは、よく知られたフレームワーク上に構築された、むき出しのアプリケーションを提供します。

クラスタ管理用のプロジェクトと同じレベルまたはそれ以下のグループ階層にアプリケーションプロジェクトを作成します。そうしないと、エージェントのアクセス権を承認することができません。

左側のサイドバーの上部で、新規作成（）を選択し、新規プロジェクト/リポジトリを選択します。
テンプレートから作成を選択します。
Ruby on Railsテンプレートを選択します。
プロジェクトに名前を付け、必要に応じて説明を追加し、GitLab Ultimateプランで利用できる機能を活用できるように公開します。
プロジェクトを作成を選択します。

これで、GKEクラスタにデプロイするアプリケーションプロジェクトができました。

GitLabエージェントを設定します

ここで、アプリケーションプロジェクトをデプロイするために使用できるように、Kubernetes向けGitLabエージェントを構成する必要があります。

クラスタの管理用に作成したプロジェクトに移動します。
エージェント設定ファイル (.gitlab/agents/<agent-name>/config.yaml)に移動して編集します。
ci_access:projects属性を構成します。アプリケーションのプロジェクトパスをidとして使用します:

ci_access:
  projects:
    - id: path/to/application-project

Ingressをインストールする

クラスタが実行されたら、インターネットからアプリケーションにトラフィックをルーティングするために、ロードバランサーとしてNGINX Ingressコントローラーをインストールする必要があります。GitLabのクラスタ管理プロジェクトのテンプレートを使用するか、Google Cloud Shellで手動で、NGINX Ingressコントローラーをインストールします。:

クラスタの詳細ページに移動し、高度な設定タブを選択します。
Google Kubernetes Engineへのリンクを選択して、Google Cloud Consoleでクラスタにアクセスします。
GKEクラスタページで、接続を選択し、Run in Cloud Shell（Cloud Shellで実行）を選択します。

Cloud Shellが起動したら、次のコマンドを実行してNGINX Ingressコントローラーをインストールします。:

helm upgrade --install ingress-nginx ingress-nginx \
--repo https://kubernetes.github.io/ingress-nginx \
--namespace gitlab-managed-apps --create-namespace

# Check that the ingress controller is installed successfully
kubectl get service ingress-nginx-controller -n gitlab-managed-apps

Auto DevOpsを設定する

これらの手順に従って、Auto DevOpsに必要なベースドメインおよびその他の設定を構成します。

NGINXをインストールしてから数分後、ロードバランサーがIPアドレスを取得し、次のコマンドで外部IPアドレスを取得できます。:
```
kubectl get service ingress-nginx-controller -n gitlab-managed-apps -ojson | jq -r '.status.loadBalancer.ingress[].ip'
```
gitlab-managed-appsを上書きした場合は、ネームスペースを置き換えてください。
次の手順で必要になるため、このIPアドレスをコピーします。
アプリケーションプロジェクトに戻ります。
左側のサイドバーで、設定 > CI/CDを選択し、変数を展開します。
- アプリケーションデプロイドメインを値として、KUBE_INGRESS_BASE_DOMAINというキーを追加します。この例では、<IP address>.nip.ioドメインを使用します。
- デプロイのターゲットとなるKubernetesのネームスペースの値を指定して、KUBE_NAMESPACEというキーを追加します。環境ごとに異なるネームスペースを使用できます。環境を構成し、環境スコープを使用します。
- 値<path/to/agent/project>:<agent-name>を持つKUBE_CONTEXTというキーを追加します。任意の環境スコープを選択します。
- 変更を保存を選択します。

Auto DevOpsを有効にしてパイプラインを実行する

Auto DevOpsはデフォルトで有効になっていますが、Auto DevOpsは、インスタンス (GitLabセルフマネージドインスタンスの場合) とグループの両方で無効にすることができます。Auto DevOpsが無効になっている場合は、次の手順を実行してAuto DevOpsを有効にします。:

左側のサイドバーで、検索または移動先を選択して、アプリケーションプロジェクトを見つけます。
設定 > CI/CDを選択します。
Auto DevOpsを展開します。
デフォルトのAuto DevOpsパイプラインを選択すると、より多くのオプションが表示されます。
デプロイ戦略で、デフォルトのブランチでパイプラインが正常に実行された後、アプリケーションを本番環境にデプロイするために、目的の継続的デプロイ戦略を選択します。
変更を保存を選択します。
Auto DevOpsテンプレートを含めるように.gitlab-ci.ymlファイルを編集し、変更をmasterブランチにコミットします。:
```
include:
- template: Auto-DevOps.gitlab-ci.yml
```

このコミットにより、パイプラインがトリガーされるはずです。次のセクションでは、パイプライン内の各ジョブの機能について説明します。

アプリケーションをデプロイする

パイプラインが実行されているとき、何をしているのですか？

パイプライン内のジョブを表示するには、パイプラインのステータスバッジを選択します。パイプラインのジョブが実行されているときはアイコンが表示され、ジョブが完了すると、ページを更新せずに (成功の場合) または (失敗の場合) に更新されます。

ジョブはステージに分けられています。:

ビルド - アプリケーションは、Dockerイメージをビルドし、プロジェクトのコンテナレジストリにアップロードします(自動ビルド)。
テスト - GitLabはアプリケーションに対してさまざまなチェックを実行しますが、testを除くすべてのジョブは、テストステージで失敗してもかまいません。:
- testジョブは、言語とフレームワークを検出することにより、ユニットテストとインテグレーションテストを実行します (自動テスト)
- code_qualityジョブはCode Qualityをチェックし、失敗してもかまいません (自動Code Quality)
- container_scanningジョブは、Dockerコンテナに脆弱性があるかどうかをチェックし、失敗してもかまいません (自動コンテナスキャン)
- dependency_scanningジョブは、アプリケーションに脆弱性の影響を受けやすい依存があるかどうかをチェックし、失敗してもかまいません (自動依存関係スキャン)
- -sastで終わるジョブは、現在のコードに対して静的な解析を実行して、潜在的なセキュリティ上の問題をチェックし、失敗してもかまいません (自動SAST)
- secret-detectionジョブは、流出したシークレットをチェックし、失敗してもかまいません (自動シークレット検出)
Review - デフォルトのブランチのパイプラインには、dast_environment_deployジョブを含むこのステージが含まれています。詳細については、動的アプリケーションセキュリティテスト（DAST）を参照してください。
Production（本番） - テストとチェックが終了すると、アプリケーションはKubernetesにデプロイされます (自動デプロイ)。
パフォーマンス - デプロイされたアプリケーションでパフォーマンステストが実行されます (自動ブラウザパフォーマンステスト)。
Cleanup（クリーンアップ） - デフォルトのブランチのパイプラインには、stop_dast_environmentジョブを含むこのステージが含まれています。

パイプラインを実行した後、デプロイされたWebサイトを表示し、そのモニタリング方法を学ぶ必要があります。

プロジェクトをモニタリングする

アプリケーションのデプロイが成功すると、環境ページでWebサイトを表示し、その健全性を確認できます。操作 > 環境に移動します。このページには、デプロイされたアプリケーションに関する詳細が表示され、右側の列には、一般的な環境タスクにリンクするアイコンが表示されます。:

ライブ環境を開く ( ) - 本番環境にデプロイされたアプリケーションのURLを開きます
モニタリング ( ) - PrometheusがKubernetesクラスタに関するデータと、メモリ使用量、CPU使用率、レイテンシーの点でアプリケーションがそれにどのように影響するかに関するデータを収集するメトリクスページを開きます
デプロイ先 ( ) - デプロイできる環境のリストを表示します
ターミナル ( ) - アプリケーションが実行されているコンテナ内で、Web端末セッションを開きます
環境に再デプロイ ( ) - 詳細については、再試行とロールバックを参照してください
環境を停止 ( ) - 詳細については、環境の停止を参照してください

GitLabは、環境情報の下にデプロイボードを表示します。四角はKubernetesクラスタ内のポッドを表し、色分けによってそのステータスを示します。[デプロイボード]の正方形にカーソルを合わせると、デプロイの状態が表示され、正方形を選択すると、ポッドのログページに移動します。

この例では、現時点でアプリケーションをホストしているポッドは1つだけですが、REPLICAS CI/CD変数を設定 > CI/CD > 変数で定義すると、ポッドをさらに追加できます。

ブランチを操作する

次に、フィーチャーブランチを作成して、コンテンツをアプリケーションに追加します。:

プロジェクトのリポジトリで、次のファイルに移動します:app/views/welcome/index.html.erb。このファイルには、段落<p>You're on Rails!</p>のみが含まれている必要があります。
GitLab Web IDEを開き、変更を加えます。
ファイルに次の内容が含まれるように編集します。:
```
<p>You're on Rails! Powered by GitLab Auto DevOps.</p>
```
ファイルをステージングします。コミットメッセージを追加し、コミットを選択して新しいブランチとマージリクエストを作成します。
コミット

マージリクエストを送信すると、GitLabはパイプラインとその中のすべてのジョブを、前に説明したように実行します。さらに、デフォルトのブランチ以外のブランチでのみ実行されるジョブもいくつかあります。

数分後、テストが失敗します。これは、変更によってテストが「破損」したことを意味します。失敗したtestジョブを選択して、詳細情報を表示します。

Failure:
WelcomeControllerTest#test_should_get_index [/app/test/controllers/welcome_controller_test.rb:7]:
<You're on Rails!> expected but was
<You're on Rails! Powered by GitLab Auto DevOps.>..
Expected 0 to be >= 1.

bin/rails test test/controllers/welcome_controller_test.rb:4

破損したテストを修正するには、次のようにします。:

マージリクエストに戻ります。
右上隅で、コードを選択し、Web IDEで開くを選択します。
左側のファイルのディレクトリで、test/controllers/welcome_controller_test.rbファイルを見つけて選択し、開きます。
7行目をYou're on Rails! Powered by GitLab Auto DevOps.と言うように変更します
左側のサイドバーで、Source Control（ソース管理）（）を選択します。
コミットメッセージを記述し、コミットを選択します。

マージリクエストの概要ページに戻ると、テストに合格するだけでなく、アプリケーションがレビューアプリケーションとしてデプロイされていることもわかります。アプリを表示 ボタンを選択してアクセスし、変更がデプロイされていることを確認できます。

マージリクエストをマージした後、GitLabはデフォルトのブランチでパイプラインを実行し、アプリケーションを本番環境にデプロイします。

まとめ

このプロジェクトを実装すると、Auto DevOpsの基本をしっかりと理解できるようになります。GitLabでのアプリケーションのビルドとテストから、デプロイとモニタリングまでを開始しました。自動的な性質にもかかわらず、Auto DevOpsは、ワークフローに合わせて構成およびカスタマイズすることもできます。以下は、さらに詳しく学習するための役立つリソースです。: