Amazon Linux 2023上にGitLabを構築し、GitLab Pagesを有効化する
以前にAmazon Linux 2023 へ GitLab をインストールするというメモを書きました。今回はGitLab Pagesを有効化したGitLabを構築する手順をメモします。
検証環境¶
| 対象 | バージョン |
|---|---|
| Amazon Linux | 2023.8.20250808 (Amazon Linux) |
| GitLab | v18.2.1-ee |
ワイルドカード証明書の取得はGitLabの証明書取得機能を利用しない¶
GitLab Pages Let’s Encrypt certificatesには以下の記載があります。
The GitLab Pages integration with Let’s Encrypt (LE) allows you to use LE certificates for your Pages website with custom domains without the hassle of having to issue and update them yourself; GitLab does it for you, out-of-the-box.
同時に下記の記載もあります。
This feature covers only certificates for custom domains, not the wildcard certificate required to run Pages daemon (GitLab Self-Managed, Free, Premium, and Ultimate only). Wildcard certificate generation is tracked in this issue.
この部分を読む限り、「GitLabとLet's Encryptは連携出来るが、Pagesでの公開用に使うワイルドカード証明書の取得はサポートしていない」と読めます。その為、今回はLet's Encryptでワイルドカード証明書を取得しますが、GitLab統合の機能は利用せず、別途証明書を取得します。
| レコード | 証明書の取得方針 |
|---|---|
gitlab.example.com |
GitLabのLet's Encrypt連携機能で取得 |
pages.example.comと*.pages.example.com |
legoを使って取得 |
AWS EC2インスタンスの新規作成¶
AWS EC2上に作成する仮想マシンのスペックはGitLab installation requirementsを参考に、以下としました。
| 項目 | 値 |
|---|---|
| AMI | Amazon Linux 2023 kernel-6.1 |
| アーキテクチャ | 64ビット (arm) |
| インスタンスタイプ | t4g.large |
| vCPU | 2 |
| メモリ | 8GiB |
| ストレージ | 50GiB |
GitLabへのSSHアクセスにTCP/22を利用する為、OSへのSSHアクセスにはTCP/40022を利用します。その為、セキュリティグループのインバウンドルールでは以下を許可します。
| プロトコル | ポート | ソース |
|---|---|---|
| TCP | 22 | 0.0.0.0/0 |
| TCP | 80 | 0.0.0.0/0 |
| TCP | 443 | 0.0.0.0/0 |
| TCP | 40022 | (メンテナンスする端末のアドレス) |
インスタンスを作成したらElastic IPを割り当てます。
IAMロールの割り当て¶
GitLabはインストール時、Let's Encryptで証明書を取得することが出来ます。今回の検証環境ではDNSのゾーンをRoute53でホストしていますので、そのゾーンに対して適切な権限を持ったIAMロールをEC2インスタンスへ設定しておきます。詳しくはAmazonLinux2 で lego を使い Route53 認証でサーバ証明書を取得するを参照します。
ホスト名とタイムゾーンの設定¶
ホスト名とタイムゾーンを設定します。
hostnamectl set-hostname gitlab.example.com
timedatectl set-timezone Asia/Tokyo
OSへSSHするポートを変更する¶
OSへSShアクセスする為のTCPポートを22→40022へ変更します。
sed -i -e "s/#Port 22/Port 40022/g" /etc/ssh/sshd_config
DNSレコードの登録¶
DNSサーバへ以下のレコードを設定します。
| レコード | タイプ | 値 | 用途 |
|---|---|---|---|
gitlab.example.com |
A | (EC2インスタンスに割り当てたEIP) | GitLab自体へのアクセス |
pages.example.com |
CNAME | gitlab.example.com |
GitLab Pagesへのアクセス |
*.pages.example.com |
CNAME | gitlab.example.com |
GitLab Pagesへのアクセス |
awscli用設定ファイルの準備¶
GitLabのインストール時にはLet's Encryptでサーバ証明書を自動取得する機能があります。しかし、~/.aws/configが無いとエラーになってしまうようですので、予めこのファイルを作成しておきます。まず、ディレクトリを作成します。
mkdir /root/.aws/
次にconfigファイルを作成します。
cat << 'EOF' > /root/.aws/config
[default]
region = ap-northeast-1
output = json
EOF
LegoでGitLag Pages用のワイルドカード証明書を取得する¶
GitLab Pages用ドメインの証明書はGitLabで取得できないようです(試してみたのですが、自動取得させる方法が分かりませんでした)。そこでLegoを使ってLet's Encryptで証明書を取得します。まず、Legoをインストールします。今回の環境にあわせてarm64のバイナリを取得します。
mkdir ~/tmp
cd ~/tmp
curl -LO https://github.com/go-acme/lego/releases/download/v4.25.2/lego_v4.25.2_linux_arm64.tar.gz
tar zxvf lego_v4.25.2_linux_arm64.tar.gz
mv lego /usr/local/bin/
chmod 755 /usr/local/bin/lego
chown root:root /usr/local/bin/lego
Legoのインストールが完了したらサーバ証明書を取得します。DNSのゾーンに登録したレコード設計に合わせてSubjectを指定します。
lego --accept-tos \
--path=/etc/letsencrypt \
--email="foobar@example.com" \
--dns="route53" \
--domains="pages.example.com" \
--domains="*.pages.example.com" \
run
正常にサーバ証明書が取得できた場合、/etc/letsencrypt/ディレクトリ配下は以下のような構造になります。
# tree /etc/letsencrypt/
/etc/letsencrypt/
├── accounts
│ └── acme-v02.api.letsencrypt.org
│ └── foobar@example.com
│ ├── account.json
│ └── keys
│ └── foobar@example.com.key
└── certificates
├── pages.example.com.crt
├── pages.example.com.issuer.crt
├── pages.example.com.json
└── pages.example.com.key
GitLabのインストール¶
GitLabをインストールします。以下の条件をすべて満たしている場合、自動的にLet's Encryptで証明書が取得されます。
- セキュリティグループでTCP/80が許可されていること
- インストール時に環境変数「
EXTERNAL_URL」が指定されていること - 環境変数「
EXTERNAL_URL」内のプロトコルハンドラがhttpsであること
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh | sudo bash &&
sudo EXTERNAL_URL="https://gitalb.example.com" dnf install -y gitlab-ee
インストールが完了すると/etc/gitlab/は以下の構造になっていました。Let's Encryptで取得された証明書と鍵のペアはsslディレクトリ配下に保存されます。
# tree /etc/gitlab/
/etc/gitlab/
├── gitlab-secrets.json
├── gitlab.rb
├── initial_root_password
├── ssl
│ ├── gitalb.example.com.crt
│ └── gitalb.example.com.key
└── trusted-certs
opensslコマンドでcrtファイルを確認し、Subjectが意図したものになっていることを確認します。
# openssl x509 -text -noout -in /etc/gitlab/ssl/gitalb.example.com.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=gitalb.example.com
Validity
Not Before: Aug 9 11:48:56 2025 GMT
Not After : Sep 8 11:48:56 2025 GMT
Subject: CN=gitalb.example.com
・
・
・
また、GitLabを構成する各プロセスの状態はgitlab-ctl statusで確認することができます。正常であればすべてrun表示になります。異常があり、起動しなかった・停止したプロセスはDownなどの表示になります。
# gitlab-ctl status
run: alertmanager: (pid 4198) 106s; run: log: (pid 3983) 156s
run: crond: (pid 4160) 109s; run: log: (pid 3397) 247s
run: gitaly: (pid 4142) 110s; run: log: (pid 2978) 362s
run: gitlab-exporter: (pid 4173) 108s; run: log: (pid 3806) 175s
run: gitlab-kas: (pid 3237) 346s; run: log: (pid 3254) 343s
run: gitlab-workhorse: (pid 4116) 111s; run: log: (pid 3512) 229s
run: logrotate: (pid 2865) 375s; run: log: (pid 2873) 374s
run: nginx: (pid 4129) 111s; run: log: (pid 3543) 224s
run: node-exporter: (pid 4168) 108s; run: log: (pid 3770) 182s
run: postgres-exporter: (pid 4207) 105s; run: log: (pid 4032) 150s
run: postgresql: (pid 3045) 352s; run: log: (pid 3065) 351s
run: prometheus: (pid 4183) 107s; run: log: (pid 3941) 162s
run: puma: (pid 3400) 244s; run: log: (pid 3408) 241s
run: redis: (pid 2911) 369s; run: log: (pid 2921) 368s
run: redis-exporter: (pid 4175) 108s; run: log: (pid 3844) 170s
run: registry: (pid 4135) 111s; run: log: (pid 3686) 208s
run: sidekiq: (pid 3427) 238s; run: log: (pid 3448) 235s
rootパスワードの確認¶
rootユーザの初期パスワードは/etc/gitlab/initial_root_passwordに記載されていますので、これを確認してGitLabへログインします。
# grep ^Password /etc/gitlab/initial_root_password
Password: 1234567890123456789012345678901234567890123=
GitLab Pagesの有効化¶
GitLabの設定ファイルである/etc/gitlab/gitlab.rbを修正し、GitLab Pagesを有効化します。
gitlab_rails['time_zone'] = 'Asia/Tokyo'
external_url 'https://gitlab.example.com'
pages_external_url "https://pages.example.com/"
gitlab_pages['enable'] = true
gitlab_pages['access_control'] = true
gitlab_pages['custom_domain_mode'] = 'https'
pages_nginx['redirect_http_to_https'] = true
pages_nginx['ssl_certificate'] = "/etc/letsencrypt/certificates/pages.example.com.crt"
pages_nginx['ssl_certificate_key'] = "/etc/letsencrypt/certificates/pages.example.com.key"
設定ファイルを修正したらGitLabを再起動します。
gitlab-ctl reconfigure
これでGitLab Pagesが有効化されました。Admin Area→Dashboardを確認するとGitLab Pagesが有効化されていることが分かります。
Pagesへのアクセス制限設定¶
デフォルトではPagesで公開したページは「GitLabにアカウントが無くても、誰でもアクセス可能」になっているようです。これを禁止し、「GitLabにアカウントを持っているユーザのみ、Pagesへのアクセスを許可する」場合はAdmin Area→Preferences→PagesからDisable public access to Pages sitesにチェックを入れ、Save changesをクリックします。
これでGitLab本体設定は完了です。
Docker インストール¶
CI/CDする際、クライアント側でのRunnerにDockerが必要であればインストールしておきます。もしAmazon Linux2023へインストールする場合は以下を実行します。
dnf update &&
dnf install -y docker &&
usermod -aG docker $USER &&
systemctl start docker &&
systemctl enable docker
GitLab RunnerのインストールとRunnerの登録¶
以下のメモを参考にGitLab Runnerをインストールします。リポジトリを利用せず、バイナリをインストールしてしまうと自らバージョン管理を行う必要があります。パッケージマネージャでバージョン管理したい場合はリポジトリからインストールします。
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | bash &&
dnf install -y gitlab-runner
Runner自身のインストールが完了したらCI/CDしたいプロジェクトで利用できるよう、Runnerを登録します。
CI/CDを実行し、ビルド結果を静的Webサイトとして公開する¶
あとはプロジェクトでCI/CDを実行すると、ビルド結果が静的Webサイトとして公開されます。GitLab Pagesで公開されたWebサイトは各プロジェクトの画面右側にある「GitLab Pages」部分からアクセスできます。
