Auto DevOpsを使用して、アプリケーションをAmazon Elastic Kubernetes Service（EKS）にデプロイする

このチュートリアルでは、アプリケーションをAmazon Elastic Kubernetes Service（EKS）にデプロイする方法の例を使用して、Auto DevOpsの使用を開始します。

このチュートリアルでは、GitLabネイティブのKubernetesインテグレーションを使用するため、AWSコンソールを使用してKubernetesクラスターを手動で作成する必要はありません。

GitLab Self-Managedインスタンスでもこのチュートリアルを実行できます。独自のRunnerが設定されていることを確認してください。

EKSにプロジェクトをデプロイするには:

Amazonアカウントの設定

Kubernetesクラスターを作成してGitLabプロジェクトに接続する前に、AWSアカウントが必要です。既存のAmazonアカウントでサインインするか、新しいアカウントを作成してください。

Kubernetesクラスターを作成します

Amazon EKSで新しいクラスターを作成するには:

Amazon EKSクラスターを作成するの手順に従ってください。

必要に応じて、eksctlを使用してクラスターを手動で作成することもできます。

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

GitLabプロジェクトテンプレートを使用して開始します。名前が示すとおり、これらのプロジェクトは、いくつかのよく知られたフレームワーク上に構築された必要最低限のアプリケーションを提供します。

クラスター管理のプロジェクトと同じレベルかそれ以下のグループ階層にアプリケーションプロジェクトを作成してください。そうしないと、エージェントの承認に失敗します。

右上隅で、新規作成（）と新規プロジェクト/リポジトリを選択します。
テンプレートから作成を選択します。
Ruby on Railsテンプレートを選択します。
プロジェクトに名前を付け、オプションで説明を追加し、Ultimateプランで利用できる機能を活用できるように、公開設定にしてください。
プロジェクトを作成を選択します。

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

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

次に、アプリケーションプロジェクトをデプロイできるように、Kubernetes向けGitLabエージェントサーバーを設定します。

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

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

Ingressをインストールします

クラスターの稼働後、インターネットからアプリケーションへのトラフィックをルーティングするロードバランサーとしてNGINX Ingress Controllerをインストールする必要があります。GitLabのクラスター管理プロジェクトテンプレートを介して、またはコマンドラインを使用してNGINX Ingress Controllerを手動でインストールします:

お使いのマシンにkubectlとHelmがインストールされていることを確認してください。
クラスターにアクセスするためのIAMロールを作成します。
クラスターにアクセスするためのアクセストークンを作成します。

kubectlを使用してクラスターに接続します:

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 all -n gitlab-managed-apps --selector app.kubernetes.io/instance=ingress-nginx
```
ネームスペースを上書きした場合は、gitlab-managed-appsを置き換えてください。
次に、次のコマンドでクラスターの実際の外部IPアドレスを見つけてください:
```
nslookup [External IP]
```
ここで、[External IP]は前のコマンドで見つかったホスト名です。
IPアドレスは、応答のNon-authoritative answer:セクションにリストされている場合があります。
このIPアドレスは次のステップで必要になるため、コピーしてください。
アプリケーションプロジェクトに戻ります。
左サイドバーで、設定 > CI/CDを選択し、変数を展開します。
- アプリケーションのデプロイドメインを値として、KUBE_INGRESS_BASE_DOMAINというキーを追加します。この例では、<IP address>.nip.ioドメインを使用します。
- KUBE_NAMESPACEというキーを追加し、デプロイのターゲットとなるKubernetesネームスペースの値を設定します。環境ごとに異なるネームスペースを使用できます。環境を設定し、環境スコープを使用します。
- KUBE_CONTEXTというキーにpath/to/agent/project:eks-agentのような値を設定します。任意の環境スコープを選択します。
- 変更を保存を選択します。

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

Auto DevOpsはデフォルトで有効になっていますが、（GitLab Self-Managedインスタンスの場合）インスタンス全体、または個々のグループで無効にすることができます。Auto DevOpsが無効になっている場合は、以下の手順を実行して有効にしてください:

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

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

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

パイプラインが実行されると、何が起こるのでしょうか？

パイプラインのジョブを表示するには、パイプラインのステータスバッジを選択します。パイプラインジョブの実行中はアイコンが表示され、ジョブが完了するとページを更新することなく（成功の場合）または（失敗の場合）に更新されます。

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

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

パイプラインを実行した後、デプロイされたウェブサイトを表示し、それを監視する方法を学ぶ必要があります。

プロジェクトを監視します

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

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

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

この例では、現時点では1つのポッドだけがアプリケーションをホストしていますが、設定 > CI/CD > 変数でREPLICAS 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はワークフローに合わせて設定およびカスタマイズすることもできます。以下に、さらに学習するための役立つリソースを示します: