GitLab を Docker で運用し、永続化ファイルをまるごと移転する際に気をつけること

OS -> Linux ソフトウェア Web

GitLab を Docker で

概略については公式ページに以下のようにまとまっています。

ほとんどの場合は上記ページの内容に従えば問題なく GitLab が起ち上がると思います。今回の私の場合は「他のマシンで運用していた Docker の GitLab から、永続化ファイルをまるまるコピーして、別のマシンで新たに Docker で GitLab を運用しようとした際のできごと」になります。

Docker Compose

私が利用したのは Docker Compose を利用する方法です。docker-compose.ymlは上記公式ページほぼそのままです。

web:
  image: gitlab/gitlab-ce
  container_name: my-gitlab
  restart: always
  hostname: my_gitlab
  environment:
    GITLAB_OMNIBUS_CONFIG: |
      external_url 'http://192.168.162.155:12345'
      gitlab_rails['time_zone'] = 'Asia/Tokyo'
      gitlab_rails['gitlab_email_enabled'] = true
      gitlab_rails['gitlab_email_from'] = 'foobar@gmail.com'
      gitlab_rails['gitlab_email_display_name'] = 'GitLab on foobar'
      gitlab_rails['gitlab_email_reply_to'] = 'foobar@gmail.com'
      gitlab_rails['gitlab_email_subject_suffix'] = ''
  ports:
    - '12345:12345'
    - '12346:443'
    - '12347:22'
  volumes:
    - '/srv/docker/gitlab/config:/etc/gitlab'
    - '/srv/docker/gitlab/logs:/var/log/gitlab'
    - '/srv/docker/gitlab/data:/var/opt/gitlab'

ハマったところ その1

docker-compose.yml内の記述では（というか YAML の記述では）、適切にクォートでくくってやる必要があります。私はポート番号の箇所をくくらなかったために、661342番のポートを指定したことになって少々ハマりました。

ハマったところ その2

以下、必ずしもそうとは言えないようなので撤回です。

external_urlのポート番号と、portsで指定するポート番号との関係でハマりました。結論を言うと、「external_urlでのポート番号が22222だとしたら、portsのポート番号（ウェブサーバ）は22222:22222のように、ホストとコンテナで同じ番号を指定する」です。

詳細は公式ページにあるので省略しますが、上記のように設定しない場合にはnginx['listen_port']の設定項目を追加しなければならないので面倒です。

ハマったところ その3

「その1」と「その2」は一番最初の GitLab の構築の際も問題となる点です。「その3」のハマりどころは、冒頭で述べたように「他のマシンで運用していた Docker の GitLab から、永続化ファイルをまるまるコピーして、別のマシンで新たに Docker で GitLab を運用しようとした際に特有のできごと」です。

上記の場合に何が起きたかというと、大体想像がつくかもしれませんが「パーミッションの問題」が起きました。永続化のファイルをrootでコピーしたことが原因だと考えられます。

$ docker-compose upをすると流れるメッセージの途中に赤文字で以下の文字が現れました。

Error executing action `run` on resource 'execute[/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-keys check-permissions]'

check-permissionsとあったので、示されているgitlab-keysのパーミッションを変えればいいんだろうと思いましたが……永続化ファイルには含まれていません。となるとコンテナの中のファイルなわけで、そうすると、コンテナを作るたびにこのエラーがついてまわることになる？んでしょうか。設定ファイルの書き方で回避できる？いや、以前の環境ではそんな面倒くさいことしなくても普通に起動できていたし……。

こういう場合の大原則、ログを見ましょう。今回はコンソール上を流れている（いた）文字列です。すると親切にも以下のコマンドを実行しなさい、という記述があるではないですか（ごめんなさい、正確なメッセージはログが流れてしまいましたので分かりません）。

$ sudo docker exec -it gitlab update-permissions
$ sudo docker restart gitlab

ここでgitlabのところはご自分で指定したコンテナ名に置き換えてください。このコマンドを実行するだけでいいです。一度実行したら、コンテナを壊しても問題ありません。

詳しくは後で調べようと思っていますが、永続化ファイルのパーミッションが適切に置き換わったことで、前出のgitlab-keysのパーミッションの問題が解決したのだと思っています。

ログイン画面が出てきたときの歓び

これであとは$ docker-compose up -dでデーモン起動すれば GitLab サーバの完成です。細かい設定については gitlab.rbファイルやdocker-compose.ymlの環境変数で指定します。ここまで来られれば、それらの設定をいじることは容易でしょう*1。

結論

何度この内容を書いたのかは覚えていませんが、「エラーが起きた際にはログと公式ドキュメントが大事」。これに尽きますね。

*1:ただし gitlab.rb は凄まじい長さですが

Powered by はてなブログ