GitOps環境が欲しい時にインターネット上のGitHubが使えれば問題ないが、社外に会社のリソースを出すな等言われる場合もあり、独自に立てたGitLabを使った方が望ましい場合がある。
そういう時用にGitLabを立てた時の構築手順メモ。
ゴールは以下。
- GitLabが使えるようになっている
- GitLab Runnerが使えるようになっている
- 通信はTLS化
- Runnerの動作確認が出来る
前提
構築開始時に以下があるものとする。
- Kubernetes
- Helmコマンド
- 検証用ドメイン
ドメインについてはGitLabのURLにドメインを使っており、Let's Encryptを使ってTLS化する際、cert-managerがHTTP-01チャレンジによってドメインを検証する。
なのでHTTP-01チャレンジに対応したドメインを利用する必要がある（nip.ioとかだと多分不可）
GitLab＆Runner構築
GitLab構築時にcert-managerやGitLab Runnerも合わせて導入できるが、cert-managerは既に入っていることが多く、GitLab RunnerはGitLab起動後のTokenを必要とするので分けて構築した。
まずcert-managerをインストールする。
helm repo add jetstack https://charts.jetstack.io --force-update
helm repo update
helm install \
cert-manager jetstack/cert-manager \
--namespace cert-manager \
--create-namespace \
--set installCRDs=true
GitLabをインストールする。
MAIL=xxxx@gmail.com
MYDOMAIN='eks.xxxx.com'
helm upgrade -i gitlab gitlab/gitlab -n gitlab --create-namespace \
--set certmanager.install=false \
--set certmanager-issuer.email=$MAIL \
--set global.hosts.domain=$MYDOMAIN \
--set global.ingress.annotations."kubernetes\.io/tls-acme"=true \
--set prometheus.install=false \
--set gitlab-runner.install=false
MAIL、MYDOMAINは自身のものを設定する。
オプションに関しては、インストールの際にcert-manager経由でがHTTP-01チャレンジを行うためのIngressのAnnotationを指定している。
prometheus.install=falseに関してはPrometheusは別で立てることが多いのでここではインストール対象から除外した。
GitLab起動後、初期パスワードを取得する。
kubectl get secret -n gitlab gitlab-gitlab-initial-root-password -o jsonpath={.data.password} | base64 -d
アクセス先を取得する。Ingressのgitlab-webservice-defaultがWebUIのアクセス先となる。
$ kubectl get ing -n gitlab
NAME CLASS HOSTS ADDRESS PORTS AGE
gitlab-kas gitlab-nginx kas.eks.xxxx.com xxxx.us-east-1.elb.amazonaws.com 80, 443 11d
gitlab-minio gitlab-nginx minio.eks.xxxx.com xxxx.us-east-1.elb.amazonaws.com 80, 443 11d
gitlab-registry gitlab-nginx registry.eks.xxxx.com xxxx.us-east-1.elb.amazonaws.com 80, 443 11d
gitlab-webservice-default gitlab-nginx gitlab.eks.xxxx.com xxxx.us-east-1.elb.amazonaws.com 80, 443 11d
上記のHOSTSをブラウザで開き、IDをroot、取得したパスワードでログインできる。
ブラウザからTLSを確認すると、問題なく利用できていることも確認できる。
次にGitLab Runnerを構築する。
なお、Runnerには3つのタイプが存在する。（参考：Manage runners）
- Instance Runner（旧Shared Runner）：全プロジェクトで使えるRunner
- Group Runner：グループ内で自由に使えるRunner
- Project Runner：特定のProjectのみ使えるRunner
ここではInstance Runnerで作成する。
GitLabのUIにアクセスし、Admin Areaから左サイドバーのCI/CD->Runnersを選択し、右上のNew instance runnerをクリックする。
PlatformはLinux、Tagsは好きなタグ（ここではsharedとした）を入力してCreate runnerでGitLab側にRunnerを作成する。
次の画面でrunner authentication tokenが表示されるのでこれを控えておく。
Kubernetes側にGitLab Runnerを展開する。
GITLAB="https://gitlab.$MYDOMAIN"
RUNNER_TOKEN="glrt-xxxxx"
helm upgrade -i gitlab-runner gitlab/gitlab-runner -n gitlab \
--set gitlabUrl=$GITLAB \
--set runnerToken="$RUNNER_TOKEN" \
--set certsSecretName=gitlab-gitlab-tls \
--set rbac.create=true
問題なければGitLab UI上からOnlineになっていることが確認できる。
Runnerの動作確認
適当なリポジトリを作成する。
+からNew project/repositoryを選択する。
Create blank projectを選択して適当に埋める。
RunnerはInstance Runnerで作成したため、リポジトリを作成した時点でRunnerは利用可能となっている。
作成したリポジトリからSettings->CI/CD->Runnersで現在利用可能なRunnerが確認できる。
このRunnerを使ってJobをキックしてみる。
作成したリポジトリをCloneする。
git clone https://gitlab.${MYDOMAIN}/root/gitlabrunner-test.git
Cloneしたディレクトリに移動し、動作確認用の.gitlab-ci.ymlを作成する。
cd gitlabrunner-test/
cat <<EOF > ./.gitlab-ci.yml
stages:
- echo
echo:
image: alpine
stage: echo
tags:
- shared
script:
- |
echo "runner test"
EOF
tagsにInstance Runnerと同じTagを指定することで、Instance Runnerを指定してJobを実行させている。
Pushする。
git add .gitlab-ci.yml
git commit -m "add .gitlab-ci.yml"
git push origin main
Pushすると早速Runnerが.gitlab-ci.ymlを読み込んでJobを実行する。
実行したJobはBuild->Jobs->ジョブ名から確認できる。
ということで、GitLabでRunnerを動かすところまでを確認できた。
なお、Runnerインストール時に--set rbac.create=trueをつけていないと以下のエラーが出ることがある。
ERROR: Error cleaning up secrets: resource name may not be empty
ERROR: Job failed (system failure): prepare environment: setting up credentials: secrets is forbidden: User "system:serviceaccount:gitlab:default" cannot create resource "secrets" in API group "" in the namespace "gitlab". Check https://docs.gitlab.com/runner/shells/index.html#shell-profile-loading for more information
Namespace gitlab内のdefaultのService Accountの権限を強化すれば通ると思う。