[アップデート] AWS CodePipeline のソースプロバイダーで Self-Managed 版 GitLab がサポートされました

いわさです。

先日 Amazon Linux 2023 へ GitLab Community Edition をインストールする方法をブログで紹介させて頂きました。

この記事の背景として、まず昨年末に AWS CodePipeline のソースステージで Slef-Managed 版の GitLab がサポートされるアップデートがありました。

半年ほど前に SaaS 版の GitLab が CodePipeline でサポートされていたのですが少し遅れて Self-Managed 版もサポートされたというわけです。

このアップデートが公開された時には「非 SaaS な GitLab もサポートされたんだなぁ。ほーん」なんて思っていたのですが、1 週間ほど前に「現在は Self-Managed 版の GitLab と Jenkins を組み合わせて使っているのだが、Jenkins 部分を AWS のマネージドサービスへ移行したい」という相談を受けて驚きました。

AWS はよくわからないのですが、私にタイムリーなアップデートを突然出してくれるんですよね。
ここはありがたく使わせてもらいましょう。

使ってみる

さて、前回の記事で EC2 上で GitLab Community Edition をセットアップ済みです。
公式手順に従うと、パブリックサブネット上で稼働する Amazon Linux 2023 上で GitLab が稼働しており、Let's Encrypt で SSL 証明書が自動で発行されているはずです。

そんな感じで既に EC2 上で GitLab をホスティング済みであることを前提に、本日は CodePipeline に組み込んでいってみようと思います。

流れとしては CodePipeline のソースステージで GitLab Self-Managed を選択するのですが、事前に CodeStar 接続をセットアップ済みだとスムーズです。なので、先に接続から作成してしまいましょう。

CodeStar のホストを作成

Code 系サービスのいずれかを開くと、デベロッパー系ツールのメニューにアクセスすることが出来ます。
まずは接続メニューの「ホスト」タブからホストを作成します。

ホストというのは CodeStar 接続で出てくる概念で、サードパーティプロバイダーのホスティング先を抽象化したリソースと定義されています。ただ、実際に検証した感じだとおそらく「サードパーティプロバイダーへアクセスするリソース」が正しいと思いました。

プロバイダーで「GitLab Self Managed」が選択出来ます。
URL は外部から名前解決・アクセスが可能な GitLab Community Edition のエンドポイントとして以下を指定しました。何かパスが必要なのかなぁよくわからんなぁと思ってとりあえず設定してみたのですがこちらで正しかったみたいです。

また、ここで VPC の設定が可能です。
今回は非 VPC を使うのですが、ユーザーが管理する VPC を通って GitLab へアクセスする必要がある場合は、VPC を使用する必要があります。

ホストを作成すると、セットアップステータスが「保留中」となりました。

ここで「ホストをセットアップ」ボタン押して認証情報を設定することで保留されたセットアップが進行します。
ボタンを押すと、個人用アクセストークンが要求されます。GitLab コンソール上から発行しましょう。

GitLab の個人メニューの「Access Tokens」から発行が可能です。
GitLab 公式ドキュメントでは次のページで手順が紹介されています。

発行されたアクセストークンを先程のダイアログ上で入力すると、ホストのセットアップステータスが「利用可能」になりました。

続いてこのホストを使って接続を作成する必要があります。
ホストの画面から「接続を作成」ボタンが表示されるのですが、本日時点ではなぜか押しても何も起きませんでした。調子が悪い（？）ようです。

CodeStar 接続を作成

そのため、接続メニューから新規作成しましょう。

プロバイダーでまたまた GitLab Self Managed を選択しましょう。

この接続、どうやら URL を入力することで、自動で同一エンドポイントのホストと紐づけが行われるようです。
もし同一エンドポイントのホストが複数存在している場合はホストを選択することができます。

接続を作成すると、またまたステータスが保留中で作成されました。
ここで「保留中の接続を更新」を押します。

そうすると接続で指定したホストに紐づいているアクセストークンを使って、GitLab へ認可を取りにいきます。
ここでユーザー操作が必要になるので許可するアクセス内容を確認して「Authorize」ボタンを押しましょう。

接続作成時には PAT を使用しない旨がドキュメントに記述されていました。
>Your PAT is used to authorize the host and is not otherwise stored or used by connections. To set up a host, you can create a temporary PAT and then after you set up the host, you can delete the PAT.
https://docs.aws.amazon.com/codepipeline/latest/userguide/connections-gitlab-managed.html

接続とホストのステータスがどちらも「利用可能」になれば CodeStar 接続の準備は完了です。

あとは CodePipeline で使うだけ

後は CodePipeline のソースステージで使うだけです。
パイプラインの内容はいつもどおり設定すれば良くて、ソースプロバイダーで GitLab Self Managed を指定するくらいです。理由は特に無いですが今回は最近出た V2 パイプラインを使ってみました。

ソースステージのソースプロバイダーに「GitLab Self Managed」が追加されていますので選択します。

そうすると先程準備した接続が選択出来るはずなので選択します。
適切に構成された接続が選択されている場合はトークンの権限に基づいてリポジトリが参照出来るはずです。
ここでリポジトリが参照出来ていない場合はトークンのアクセス許可とユーザーへのプロジェクト割り当て状況を GitLab 側で確認してみましょう。

今回はシンプルにビルドステージ無し、デプロイステージは S3 バケットへの出力で構成しました。 つまり GitLab のリポジトリから CodePipeline がコードを取得して S3 バケットに展開してくれるだけです。

パイプライン実行後、無事成功しました。
この画面からもコミットメッセージが取得できていることが確認できているのでうまくいってそうですね。

デプロイ先の S3 バケットを見てみると、取得されたソースコードがデプロイされていました。
無事成功です。

さいごに

本日は AWS CodePipeline のソースプロバイダーで Self-Managed 版 GitLab がサポートされたので使ってみました。

ホストの構成を今回初めて行ったので、従来の SaaS 版の GitLab よりちょっと手こずりました。
今回念のためホストから作成を行いましたが、接続から一気に作成することも出来るようでした。ただ、既存のホストが残っていると接続作成時に自動選択されてうまくいかない場合があったので、ホストを一度削除して、ホスト作成からやり直すと確実です。

GitLab 使いつつ CodePipeline も使いたいというシーンは限られていそうですけども、Self-Managed 版お使いの方はチェックしてみてください。
今回は非 VPC 構成で紹介しましたが GitLab 側でセキュリティグループの絞り込みを行いたかったので、その場合は VPC 構成が必要になります。そのあたりも試しているので次回以降紹介したいと思います。