自動DevOpsを使用して、アプリケーションをAmazon Elastic Kubernetes Service（EKS）にデプロイする
このチュートリアルでは、アプリケーションをAmazon Elastic Kubernetes Service（EKS）にデプロイする方法の例を通して、Auto DevOpsの開始方法を説明します。
このチュートリアルでは、GitLabネイティブのKubernetesインテグレーションを使用しているため、AWSコンソールを使用してKubernetesクラスタリングを手動で作成する必要はありません。
このチュートリアルは、GitLab Self-Managedインスタンスでも実行できます。独自のRunnerが構成されていることを確認してください。
プロジェクトをEKSにデプロイするには:
- Amazonアカウントを構成する
- Kubernetesクラスタリングを作成してエージェントをデプロイする
- テンプレートから新しいプロジェクトを作成する
- エージェントを設定する
- Ingressをインストールする
- Auto DevOpsを設定する
- Auto DevOpsを有効にしてパイプラインを実行する
- アプリケーションをデプロイする
Amazonアカウントを構成する
KubernetesクラスタリングをGitLabプロジェクトに作成して接続する前に、Amazon Web Servicesアカウントが必要です。既存のAmazonアカウントでサインインするか、新しいアカウントを作成してください。
Kubernetesクラスタリングを作成する
Amazon EKSに新しいクラスタリングを作成するには:
- Amazon EKSクラスタリングの作成の手順に従ってください。
必要に応じて、eksctlを使用して手動でクラスタリングを作成することもできます。
テンプレートからアプリケーションプロジェクトを作成する
GitLabプロジェクトテンプレートを使用して開始します。名前が示すように、これらのプロジェクトは、定評のあるフレームワーク上に構築された、必要最小限のアプリケーションを提供します。
クラスタ管理用のプロジェクトと同じレベルまたは下のグループ階層にアプリケーションプロジェクトを作成します。そうしないと、エージェントを承認できません。
- 左側のサイドバーの上部で、新規作成（ ）を選択し、新規プロジェクト/リポジトリを選択します。
- テンプレートから作成を選択します。
- Ruby on Railsテンプレートを選択します。
- プロジェクトに名前を付け、必要に応じて説明を追加し、GitLab Ultimateプランで利用可能な機能を活用できるように、公開します。
- プロジェクトを作成を選択します。
これで、EKSクラスタリングにデプロイするアプリケーションプロジェクトができました。
エージェントを設定する
次に、Kubernetes用のGitLabエージェントを構成して、アプリケーションプロジェクトのデプロイに使用できるようにします。
- クラスタリングを管理するために作成したプロジェクトに移動します。
- エージェント構成ファイル（
.gitlab/agents/eks-agent/config.yaml）に移動し、編集します。 ci_access:projects属性を構成します。アプリケーションプロジェクトのパスをidとして使用します:
ci_access:
projects:
- id: path/to/application-projectIngressをインストールする
クラスタリングの実行後、インターネットからアプリケーションにトラフィックをルーティングするために、ロードバランサーとしてNGINX Ingressコントローラーをインストールする必要があります。GitLabのクラスタリング管理プロジェクトテンプレート、またはコマンドラインから手動で、NGINX Ingressコントローラーをインストールします:
マシンに
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を設定する
次の手順に従って、自動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を無効にすることができます。Auto DevOpsが無効になっている場合は、次の手順に従ってAuto DevOpsを有効にします:
左側のサイドバーで、検索または移動先を選択して、アプリケーションプロジェクトを見つけます。
設定 > CI/CDを選択します。
Auto DevOpsを展開します。
デフォルトのAuto DevOpsパイプラインを選択して、その他のオプションを表示します。
デプロイ戦略で、デフォルトブランチでパイプラインが正常に実行された後、アプリケーションを本番環境にデプロイするための、目的の継続的デプロイ戦略を選択します。
変更を保存を選択します。
.gitlab-ci.ymlファイルを編集してAuto DevOpsテンプレートを含め、変更をデフォルトブランチにコミットします: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（Review） - テストとチェックが終了すると、アプリケーションはKubernetesにデプロイされます（自動デプロイ）。
パフォーマンス - パフォーマンステストは、デプロイされたアプリケーション（自動ブラウザパフォーマンステスト）で実行されます。
Cleanup（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を構成およびカスタマイズすることもできます。参考になるリソースを以下に示します: