tail -f /dev/null

If you haven't had any obstacles lately, you're not challenging. be the worst.

トップ > aws > GitLab server のリプレイスと GitLab Runner, AWS CodeDeploy を利用したデプロイの自動化を行う

GitLab server のリプレイスと GitLab Runner, AWS CodeDeploy を利用したデプロイの自動化を行う

aws

Precondition

  • 現在運用している GitLab server がある.
    • version 13 で稼働している.
  • Application が稼働している AWS account A と GitLab server が稼働している account B がある.
  • Account B で CodeDeploy の環境は既にある.

Overview

  • Account A
    • VPC と関連 resource を作成する.
      • Systems Manager の VPC endpoint を作成する.
      • NAT Gateway を作成する.
    • Private subnet に EC2 instance (GitLab server) を構築する.
      • SSM Agent を install, start する.
        • 今回は SSM Agent が pre-install されている Amazon Linux2 AMI を利用する.
    • EC2 instance に AmazonSSMManagedInstanceCore の IAM Policy が attach された Role を関連付ける.
    • GitLab runner を導入する.
    • 現行から新 GitLab server へデータを移行する.
  • Account B
    • Artifact upload 用の S3 bucket を作成する.
    • S3 に artifact が upload されたら CodeDeploy を trigger する Lambda を作成する.
    • GitLab への push を trigger に CodeDeploy 経由で Blue-Green Deployment を行う,

AWS SSM Session Manager 経由でしか接続できない private な GitLab server を構築する

AWS account B で以下の AWS resource を作成する.

作成した AWS resources

EC2 Instance

Subnet と Security Group は以下に作成した resource を指定する.

Elastic IP

NAT Gateway allocate 用途

NAT Gateway

GitLab server が internet へリクエストし GitLab 関連の package を download するため NAT Gateway を作成する (Systems Manager の endpoint 経由では internet へ到達できないため).

作成した NAT Gateway を Subnet の route へ追加する.

Subnet

Private な subnet を作成する.

  • gitlab (192.168.11.0/28)
    • GitLab server が存在する private subnet 用途
  • public (192.168.12.0/24)
    • NAT Gateway が所属する public subnet 用途
Destination Target
192.168.0.0/16 local
0.0.0.0/0 <作成した NAT GW ID>
pl-xxx <作成した VPC Endpoint ID>

Security Group

次の要件を満たすため、新規に security group を作成した. Name tag は gitlab とする.

  • GitLab server へ SSM Session Manager 経由で接続できる.
  • LB から TCP 80 で EC2 へ health check が通る.

Inbound を一部許可し, Outbound は特に制限しない.

Protocol Port IP Range
TCP 80 192.168.0.0/16
TCP 443 (GitLab server の所属 subnet range) 192.168.11.0/28

VPC Endpoint

Session Manage 経由で EC2 へ接続するため, 以下4つの endpoint を作成した.

Endpoint Subnet Security Group Route Table
com.amazonaws.ap-northeast-1a.ssm gitlab gitlab ー
com.amazonaws.ap-northeast-1a.ec2messages gitlab gitlab ー
com.amazonaws.ap-northeast-1a.ssmmessages gitlab gitlab ー
com.amazonaws.ap-northeast-1a.s3 ー ー private

Application Load Balancer

internet-facing な ALB を作成する.

ALB を SSL の終端とし, ALB と Target Group は 80 port での通信とする.

LB Health Check は 80 port で行う.

今回は GitLab server を想定しているため, /users/sign_in を Health Check PATH とする.

GitLab server へ Session Manager 経由で接続できることを確認する.

GitLab Upgrade

v13 のままデータ移行後, 新 server で version up を行う.

Upgrade は公式の通り, 順を沿って行う必要がある.

13.10.2-> 13.12.15-> 14.0.12-> 14.3.6=>14.6.2
14.6.2-> 14.9.5-> 14.10.5-> 15.0.2->15.1.0

GitLab Upgrade PATH を利用して手順を確認する。

yum install  gitlab-ce-13.12.15
yum install  gitlab-ce-14.0.12
yum install  gitlab-ce-14.3.6
yum install  gitlab-ce-14.9.5
yum install  gitlab-ce-14.10.5
yum install  gitlab-ce-15.0.5
yum install  gitlab-ce-15.4.2

手順がうまくいかない場合は、適宜公式サイトを参照する。

Artifact upload 用の S3 bucket を作成する

Account: A の GitLab server から Account: B の S3 bucket へ artifact を upload できるようにする.

A の VPC Endpoint から B へ S3 upload がリクエストできるよう, B の S3 bucket policy を定義する.

{
    "Version": "2008-10-17",
    "Id": "UploadFromGitLab",
    "Statement": [
        {
            "Sid": "UploadFromVPCE",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:PutObject",
                "s3:GetObject"
            ],
            "Resource": "arn:aws:s3:::hoge-deploy-staging/*",
            "Condition": {
                "StringEquals": {
                    "aws:sourceVpce": "vpce-xxx"
                }
            }
        }
    ]
}

現行→新 server へ GitLab データを移行する

現行 GitLab データの backup を取得し S3 へ upload する.

# 現行 server
gitlab-rake gitlab:backup:create
aws s3 cp --recursive /var/opt/gitlab/backups/<timestamp>_gitlab_backup.tar s3://hoge-infrastructure/gitlab/

新サーバーでデータを restore する.

# 新 server
aws s3 cp --recursive s3://hoge-infrastructure/gitlab/<timestamp>_gitlab_backup.tar /var/opt/gitlab/backups/
gitlab-rake gitlab:backup:restore <timestamp>_gitlab_backup.tar
gitlab-ctl restart
gitlab-rake gitlab:check SANITIZE=true

GitLab Runner の install

以下を install する.

  • Docker
  • GitLab runner

GitLab Runner token の初期化

データの restore 時に registration token の reset が別途必要.

公式 を参考に token の reset を行う.

S3 へ GitLab Runner 経由で artifact を upload する

gitlab-runner register 経由で GitLab の token を登録する (参考).

.gitlab-ci.yml を作成し GitLab runner の job を実行するための pipeline 定義を行う (参考).

S3 に artifact を upload するための shell スクリプトを作成する (参考).

upload する際に gzip artifact で gzip 形式に artifact を圧縮する.

S3 へ upload する際に metadata を付与する.

aws s3api put-object \
--bucket hoge-deploy-staging \
--body artifact.gz \
--key artifacts/artifact.gz \
--metadata x-amz-meta-application-name=hoge-web \
--metadata x-amz-meta-deploymentgroup-name=hoge-web

Lambda の作成

hoge-deploy の S3 bucket に x-amz-meta-application-name: hoge-web, x-amz-meta-deploymentgroup-name: hoge-web の metadata が付与された artifact が upload されたら, CodeDeploy Blue-Green Deployment を実行する Lambda を作成する.

参考

Test

S3 に artifact.gz が upload されたら Lambda が trigger され, CodeDeploy Blue-Green Deployment が実行されることを確認する.