ローカルでDocker を使って GitLab CIを設定するのは鬼門だった

普通に公開用のドメインでやるより相当ハードルが高かった。というか一部動かず解決しなかった。

• docker-compose.yml の名前で解決できることと出来ないことがある
  • CIでDockerを走らせる場合は、(GitLabを立ち上げる docker-compose.ymlではなく）GitLab Runner の設定でextra_hosts を設定する必要がある
  • GitLab Runner がプライベートのDocker Registry からイメージを取ってくるとき、名前解決できる必要がある
    • GitLabの/etc/hosts も GitLab Runner の/etc/hosts も GitLab Runner が立ち上げた /etc/hosts も見てくれない？ 名前解決用のサーバー的な何かを別途追加する必要があるかもしれない（未解決）
    • なんか GitLab Runner がDockerを起動するための golang が /etc/hosts を見ないとか、 /etc/nsswitch.conf を設定しろとか issue があったけど、うまく設定できず
• 各所でSSLが必須
  • Let's Encrypt で適当なサブドメインを作って証明書を持ってくると解決できる
  • https-portal とか ansible とか使ってほとんど自動化できるけど、簡単に自動化しすぎると今度は Let's Encrypt の Rate Limit に引っかかったりする。
  • サブドメインを多く使う場合は、Let's Encryptはサーバーに直接入れて複数ドメインのSANs証明書を手動で取るのが良いかもしれない。

golang の名前解決方針とかGitLab Runner の仕組みとか知りたいわけではなくて、単にローカルでCIのテストをしたいだけなんだけど…全然たどりつかない。ということで一旦諦めて普通に名前解決できるドメインでやった。

GitLab を Docker で入れて、Docker Registry を Dockerで入れて、連携するネットワークの部分を書いて、設定ファイルを上手く連動するようにやって、SSLなどでエラーが起きないようにして、などなど。
もしかすると普通に apt-get で GitLab Omnibus を入れたら一瞬で解決したのかもしれない。
確かにDockerを使えば単品の構築は楽で一瞬で立ち上がるが、それぞれの連携がつらい。エラーが見えづらい。オールインワンパッケージがあるなら、それを入れるのが良さそう。

プロダクション環境でDockerを使うためには、今GitLabで苦労したようなことを自前システムでもやるってことだよねえ…。
まあ最初からDockerで使うように作る場合とパッケージ提供ベースをDocker対応するのとでは全然違うのかもしれないが。