![[アップデート]セルフマネージド型GitLabサーバでAWS CodeBuildをセルフマネージドランナーと使用できるようになりました！](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-13b6316711749d13ded65f44766275b5/8ef19e710e2492ae651bb70e34be2e95/aws-codebuild)
[アップデート]セルフマネージド型GitLabサーバでAWS CodeBuildをセルフマネージドランナーと使用できるようになりました！
2025.02.27お疲れさまです。とーちです。
唐突ですが、まず昨年11月の私のボヤキを見て頂きたいと思います。
当時、このアップデートを見て、セルフマネージド型のGitLabサーバを扱っていた私は「これを使えば楽にGitLabランナーを動かせる！」と思ったものでした。
しかし、現実は非情です。上記のアップデートで対応していたのはあくまでも、SaaS版GitLab であり、セルフマネージド型のGitLabはサポートされていなかったのです。（ということを散々検証した後に気づきました）
しかし、今回のアップデートでついにセルフマネージド型のGitLabサーバでもCodeBuildをセルフマネージドランナーとして動かせるようになりました！実際に試してみた内容を紹介します！
とりあえずまとめ
- GitLab.comだけでなく、セルフホストしたGitLabサーバーでもCodeBuildをCI/CDランナーとして利用可能になった
今回の検証環境
とりあえずサクッとGitLabサーバを立てて試してみました。
今回検証した構成は下記の通りです。
細かい条件については以下の通り
- NLBはパブリックサブネット、EC2はプライベートサブネット
- パブリックサブネットにはNATゲートウェイを配置
- NLBに証明書を発行してHTTPSでアクセス、NLBからGitLabまでの経路はHTTP
- NLBのセキュリティグループ（インバウンド）は検証用途なので全開放
- GitLabサーバのバージョンは17.8
実際にやってみた
AWS公式ドキュメントに従って設定していきます。
1. GitLabでの準備作業
先にユーザーとプロジェクトを作っておいたほうが良さそうだったので、作っておきます。
ユーザーの作成
Administrator権限を持つユーザーを作成しました。
プロジェクトの作成
作成したユーザーでログインし直して、プロジェクトを作ります。プロジェクトはPrivateで作成しています。
個人用アクセストークンの発行
また、CodeBuildからGitLabへの接続で個人用アクセストークンを使うので、これも発行しておきます。
参考：https://docs.gitlab.com/user/profile/personal_access_tokens/
スコープを「api」にするのを忘れないようにしましょう。ドキュメントにも記載があります
作成したらアクセストークンの文字列をコピーして控えておきます。
2. AWS CodeConnectionsでGitLab Self-Managedに接続
次に、CodeConnectionsでGitLab Self-Managedに接続します。
ここからはAWSマネージメントコンソールに移り、Codeシリーズの画面から、接続設定を作成します。
以下のような設定で作成しました。
以下のボタンを押して接続処理を続けます。
先程作成したアクセストークンを入力します。
ここで少しだけ引っかかったのですが、最初NLBのインバウンドセキュリティグループを自分のグローバルIPだけに絞っていました。しかしその設定だとAWSからGitLabサーバに接続できず、以降の画面に進まなくなってしまいます。今回はセキュリティグループを全開放にすることで対応しましたが、もっといい方法もあるかもしれません。
認証画面が表示されるので「Authorize...」ボタンを押します。
続行を押します。
無事接続できました
3. CodeBuildでビルドプロジェクトの作成
次にCodeBuildでビルドプロジェクトを作成していきます。
AWS公式ドキュメントはこちら：https://docs.aws.amazon.com/codebuild/latest/userguide/sample-gitlab-runners.html
プロジェクトタイプは「Runner project」にして、Runner providerに「GitLab Self Managed」を選択します。
アカウントのデフォルト設定をしていればそのGitLab接続設定が使われるようですが、特に設定していないので、「Use override credentials for this project only」でデフォルトの接続設定を上書きして設定します。
GitLab CI/CDワークフローのサンプルがコピペできるようになっています。親切ですね。
CodeBuildが動く環境の設定です。コンピューティングはEC2とLambda両方選べますが、無難にEC2にしてみました。その他の設定はすべてデフォルトのまま、とりあえずビルドプロジェクトを作成してみます。
正常にビルドプロジェクトが作成できていれば、https://＜GitLabサーバドメイン＞/user-name/repository-name/-/hooks のURLからwebhookが作成されていることを確認できます。
GitLabでイベントが発生するとこのWebhookが設定されたURLにリクエストを送り、その結果CodeBuildが処理を開始するようです。
参考：https://gitlab-docs.creationline.com/ee/user/project/integrations/webhooks.html
4. GitLabプロジェクトにCI/CDパイプラインの設定ファイルを配置
続いてGitLabのプロジェクトにCI/CDパイプラインの処理が書かれたYAMLファイルを配置します。
今回はCodeBuildのプロジェクト作成画面で表示されたYAMLファイルをそのまま配置してみました。
stages:
- build
build-job:
stage: build
script:
- echo "Hello World"
tags:
- codebuild-codebuild-update-test-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
tagsの箇所でCodeBuildのプロジェクトを指定できるようになっています。指定したプロジェクトでどのコンピューティングを使うか、どのイメージを使うかなどが決まります。
タグの形式は以下のようになっています：
codebuild-<codebuild-project-name>-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
5. パイプラインの実行
GitLabにYAMLファイルを配置すると、パイプラインがpending状態になりました。オッ、動くか！？
無事動きました！うおおおお！
まとめ
というわけでセルフマネージド型GitLabサーバでCodeBuildをセルフマネージドランナーとして動かせるようになったアップデートでした！
去年の私の悔しい思いが無事浄化されたので神アップデートです。これからはGitLabのセルフマネージドランナーを使用する際はCodeBuildを第一選択肢として考えていいんじゃないでしょうか。
皆さんもぜひ試してみてください！
以上とーちでした。
