Auto DevOpsを使用して、Amazon Elastic Kubernetes Serviceにアプリケーションをデプロイします。(EKS)

このチュートリアルでは、Amazon Elastic Kubernetes Service(EKS)にアプリケーションをデプロイする方法の例を通して、AutoDevOpsを使い始める手助けをします。

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

セルフマネージドインスタンスでこのチュートリアルに従うこともできます。自分のRunnerが設定されていることを確認してください。

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

  1. Amazonアカウントの設定
  2. Kubernetesクラスターを作成し、エージェントをデプロイします。
  3. テンプレートから新しいプロジェクトを作成します。
  4. エージェントの設定
  5. Ingressのインストール
  6. Auto DevOpsの設定
  7. Auto DevOpsを有効にしてパイプラインを実行
  8. アプリケーションのデプロイ

Amazon アカウントの設定

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

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

Amazon EKS上に新しいクラスターを作成します：

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

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

GitLab プロジェクトのテンプレートを使って始めましょう。その名前が示すように、これらのプロジェクトは有名なフレームワークで作られた骨組みのないアプリケーションを提供します。

caution
クラスター管理用のプロジェクトと同じレベルかそれ以下のグループ階層にアプリケーションプロジェクトを作成します。そうしないと、エージェントの作成者が失敗します。
  1. 左サイドバーの上部にある「新規作成({plus})」と「新規プロジェクト/リポジトリ」を選択します。
  2. テンプレートから作成」を選択します。
  3. Ruby on Railsテンプレートを選択します。
  4. GitLab Ultimate プランで利用できる機能を利用できるように、プロジェクト名を付け、オプションで説明を付けて公開します。
  5. Create projectを選択します。

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

エージェントの設定

次に、Kubernetes用のGitLabエージェントを設定して、アプリケーションプロジェクトのデプロイに使えるようにします。

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

Ingressのインストール

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

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

  4. 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に必要なベースドメインとその他の設定を構成します。

  1. 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アドレスをコピーしてください。

  2. アプリケーション・プロジェクトに戻ります。
  3. 左サイドバーで、Settings > CI/CDを選択し、Variablesを展開します。
    • アプリケーションデプロイメントドメインを値として、KUBE_INGRESS_BASE_DOMAIN というキーを追加します。この例では、ドメイン<IP address>.nip.io を使用します。
    • KUBE_NAMESPACE というキーに、デプロイの対象となるKubernetesネームスペースの値を追加します。環境ごとに異なる名前空間を使用できます。環境を設定し、環境スコープを使用します。
    • path/to/agent/project:eks-agent のような値でKUBE_CONTEXT というキーを追加します。環境スコープを選択します。
    • 変更を保存を選択します。

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

Auto DevOpsはデフォルトで有効になっていますが、Auto DevOpsはインスタンスレベル(セルフマネージドインスタンスの場合)とグループレベルの両方で無効にすることができます。Auto DevOpsが無効になっている場合は、以下の手順で有効にしてください：

  1. 左側のサイドバーで、[Search]を選択するか、または[Go to]を選択してアプリケーションプロジェクトを見つけます。
  2. Settings > CI/CDを選択します。
  3. Auto DevOpsを展開します。
  4. Default to Auto DevOps pipelineを選択すると、さらに多くのオプションが表示されます。
  5. デプロイ戦略では、パイプラインがデフォルトブランチで正常に実行された後、アプリケーションを本番環境にデプロイするための継続的デプロイ戦略を選択します。
  6. 変更を保存を選択します。

  7. .gitlab-ci.yml ファイルを編集して Auto DevOps テンプレートを追加し、変更をデフォルトブランチにコミットします：

    include:
- template: Auto-DevOps.gitlab-ci.yml

コミットによってパイプラインが起動するはずです。次のセクションでは、パイプラインで各ジョブが何を行うのかを説明します。

アプリケーションのデプロイ

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

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

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

Pipeline stages

  • ビルド- アプリケーションはDockerイメージをビルドし、プロジェクトのコンテナレジストリにアップロードします（Auto Build）。

  • Test- GitLabはアプリケーションに対して様々なチェックを実行しますが、test を除く全てのジョブはテストステージで失敗しても構いません：

    • test ジョブは言語とフレームワークを検知してユニットテストとインテグレーションテストを実行します(Auto Test)。
    • code_quality ジョブはコードの品質をチェックし、失敗することを許可します(Auto Code Quality)。
    • container_scanning ジョブは、Docker コンテナに脆弱性があるかどうかをチェックし、失敗することを許可します(Auto Container Scanning)。
    • dependency_scanning ジョブはアプリケーションに脆弱性の影響を受けやすい依存関係があるかどうかをチェックし、失敗することを許可します(Auto Dependency Scanning)。
    • -sast をサフィックスとするジョブは、現在のコードの静的解析を実行し、潜在的なセキュリティ問題をチェックします。
    • secret-detection のジョブは漏えいしたシークレットをチェックし、失敗してもかまいません(Auto Secret Detection)。
    • license_scanning ジョブは非推奨であり、何の結果も出しません。失敗してもかまいません(Auto License Compliance)。

  • レビュー- デフォルトブランチのパイプラインには、dast_environment_deploy ジョブとともにこのステージが含まれます。詳細については、動的アプリケーションセキュリティテスト(DAST) を参照してください。

  • 本番- テストとチェックが終わると、アプリケーションはKubernetesにデプロイされます（Auto Deploy）。

  • パフォーマンス- デプロイされたアプリケーションでパフォーマンステストが実行されます（Auto Browser Performance Testing）。

  • クリーンアップ- デフォルトブランチのパイプラインには、このステージとstop_dast_environment ジョブが含まれます。

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

プロジェクトの監視

アプリケーションのデプロイに成功したら、[Operate (オペレーション)] > [Environments (環境)] に移動して、[Environments (環境)]ページでそのウェブサイトを表示し、健全性を確認できます。このページにはデプロイされたアプリケーションの詳細が表示され、右側の列には一般的な環境タスクにリンクするアイコンが表示されます：

Environments

  • ライブ環境を開く({external-link}) - 本番環境にデプロイされたアプリケーションの URL を開きます。
  • Monitoring({chart}) - PrometheusがKubernetesクラスターに関するデータを収集するメトリクスページを開き、メモリ使用量、CPU使用量、レイテンシに関してアプリケーションがクラスターにどのような影響を与えるかを表示します。
  • Deploy to({play} ) - デプロイできる環境のリストを表示します。
  • Terminal({terminal}) - アプリケーションが動作しているコンテナ内でウェブターミナルセッションを開きます。
  • 環境への再デプロイ({repeat}) - 詳細は、再試行とロールバックを参照してください。
  • 環境の停止({stop}) - 詳しくは環境の停止をご覧ください。

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

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

ブランチでの作業

次に、アプリケーションにコンテンツを追加するための機能ブランチを作成します：

  1. プロジェクトのリポジトリで、次のファイルにアクセスしてください:app/views/welcome/index.html.erb 。このファイルには段落のみを記述します：<p>You're on Rails!</p>.
  2. GitLabWeb IDEを開いて変更を行います。

  3. ファイルを編集します：

    <p>You're on Rails! Powered by GitLab Auto DevOps.</p>

  4. ファイルをステージします。コミットメッセージを追加し、コミットを選択して新しいブランチとマージリクエストを作成します。

    Web IDE commit

マージリクエストを送信すると、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

壊れたテストを修正するには

  1. マージリクエストに戻ります。
  2. 右上の「Code」を選択し、「Open in Gitpod」を選択します。
  3. 左側のファイルディレクトリでtest/controllers/welcome_controller_test.rb ファイルを探し、それを選択して開きます。
  4. 7行目をYou're on Rails! Powered by GitLab Auto DevOps.
  5. コミットを選択します。
  6. 左側の列のUnstaged changes で、チェックマークアイコン({stage-all}) を選択して変更をステージします。
  7. コミットメッセージを書き、コミットを選択します。

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

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

結論

このプロジェクトを実施した後は、Auto DevOps の基本をしっかりと理解しているはずです。アプリケーションのビルドとテストからデプロイと監視まで、すべてGitLabで行うようになりました。Auto DevOpsはその自動的な性質にもかかわらず、あなたのワークフローに合わせて設定やカスタマイズを行うこともできます。さらに読むのに役立つリソースをいくつか紹介します：

  1. Auto DevOps
  2. 複数のKubernetesクラスター
  3. 本番環境へのインクリメンタルなロールアウト
  4. CI/CD変数で不要なジョブを無効化
  5. 独自のビルドパックを使用してアプリケーションを構築