GitLab環境を再構築するに至った経緯
私は2020年頃からGitLabをインストールして色々と試してきました。ずっと Subversionをメインに使ってきたこともあって、Git自体は、お客様の指定がない限りは使っていなかったのですが、2022年から、あるお客様のソース管理が Gitに移行し、今年度に入って本格的に GitLabを使うこととなったために、私のローカル環境のGitLabを整備することにしました。GitLabを使うからには最低でもCI/CDの環境を整えたいと考えて、ここ数週間ほど格闘してようやく使えるようになったので、その記録を残しておきます。
私がGitLabを初めて Ubuntu にインストールした2020年頃、公式のドキュメントに従ってインストールしたものの初回インストールで失敗した記録が残っています。インストール後にGitLabの設定をしなおしたら動いたのですが、その後、アップデートをするたびに、アップデートスクリプトでエラーが出るなど大変な目にあいました。このようにUbuntuの環境で安定運用には程遠い状況だったのですが、AlmaLinux用の公式パッケージが出て、そちらをインストールしてからは安定運用できるようになりました。
今回、環境を再整備するにあたり、当初はこの AlmaLinux の GitLab をそのまま使い、GitLab Runner は、新しく Ubuntu サーバをたてて構築しました。現時点（2024年4月時点）で、GitLab Runner の公式インストール手順に AlmaLinux はない状況です。RHEL/CentOS/Fedora用の手順が存在するので、その手順で AlmaLinux へインストールできるのかもしれませんが、余計なトラブルに遭遇したくなかったので、素直に Ubuntu を選択しました。この構成でCI/CDを動かすことには成功したのですが、途中様々な躓きがありました。一番大きな原因は GitLab を http で運用していたことです。
我が家のWeb系システムはリバースプロキシを介して、URLによって各サーバに振り分けられています。AlmaLinuxで動かしていた GitLab もそのひとつです。 nginx で Let’s Encrypt を用いた https 接続を受け付けたあと、http (ポート80) で GitLab に投げていました。実はここに大きな罠が潜むことになります。外からは https で動いているように見える GitLab ですが内部では http で動いているというジレンマがあちこちで起きることになりました。辻褄を合わせて名前解決やGitLabの設定を操ることで最終的には動かすことはできましたが、ここに数日を費やすことになったのです。こういう状況は今後拡張性に問題が出てしまいます。そこで AlmaLinux の GitLab を https で動かすように再設定してみましたが思うように動いてくれなかったので、悩みを断ち切るために GitLab自体を新規にインストールしなおす判断をしました。GitLabはインストール時に URLを https に指定すれば Let’s Encrypt が自動でセットアップされて https で動くようになります。我が家の構成を考えた時、今までリバースプロキシ側で運用していた Let’s Encrypt との辻褄を合わせる必要があります。解決策として Let’s Encrypt証明書の更新は GitLab に任せて、その証明書をリバースプロキシ側に転送して同じ証明書を使うことで https → https の転送を実現することにしました。
GitLab自体を https とすることで素直なシステム連携を実現することができました。
具体的な構築については、後日、改めて記事にします。
