TECHBLOGスキルブログ

Docker for windowsでGitlabコンテナにGoogleOpenIDを設定するまでの話

2018.11.01

はじめに

こんにちはシステム開発Gの中川です。

去年末くらいから社内で使用している色んな物にGoogleOpenIDでログイン出来るよう設定しています。
社内メールでGoogle Accountを使っているととても有効な手段となっており、各個人のアカウントもシンプルに管理が出来るようになります。
今回はその一環で社内のソース管理で使用しているGitLabに設定をする前にローカル環境でお試しした時の話をします。

今回の記事はWindowsでやっていますが、これはただの個人的な趣味嗜好となっています。
他のOSでも読み替えて実施出来るかと思います。

Docker for windowsのインストール

コンテナは公式で用意されていますが、WindowsでDockerを使用するためにはHyper-vが必要なためProかEnterpriseにする必要があります。
Homeの人も昔と違ってStoreからさくっとアップデート可能になっているので、お金は必要となりますが環境を用意するのは楽になっています。
久々にアップグレードしたのですが、本当に楽になっていて驚きました。

Docker自体のインストールは公式からすぐに可能なため、手順自体は割愛します。

Gitlabコンテナのダウンロードから起動

公式のやり方に沿ってコンテナを持ってきます。
コマンドがLinux仕様なので、少し変更してあげる必要があります。
ここでは、変更前後のコマンドを載せます。

Windows上でコマンドを実行するのはPowerShellで行っています。

変更前

sudo docker run --detach \
    --hostname gitlab.example.com \
    --publish 443:443 --publish 80:80 --publish 22:22 \
    --name gitlab \
    --restart always \
    --volume /srv/gitlab/config:/etc/gitlab \
    --volume /srv/gitlab/logs:/var/log/gitlab \
    --volume /srv/gitlab/data:/var/opt/gitlab \
    gitlab/gitlab-ce:latest

変更後

docker run -i `
--hostname gitlab.example.com `
--publish 80:80 --publish 22:22 `
--name gitlab `
--restart always `
--volume E:/gitlab/config:/etc/gitlab `
--volume E:/gitlab/logs:/var/log/gitlab `
--volume gitlab:/var/opt/gitlab `
gitlab/gitlab-ce:latest

変更点は以下の通りです。
1. sudoはいりません
2. –publishは自身の環境に合わせて変更してください。今回はローカルの確認だけで良いので443ポートを削除します。
3. –volumeの指定をWindowsのパスに合わせて変更します。
4. 公式では「/var/opt/gitlab」も–volumeに含めていますが、Docker for Windowsで行うと上手くいきません。Named Volume上に作るようにすれば上手く起動出来たため、今回は「docker volume create gitlab」と専用のvolumeを作って対応することにしました。他の方法では現状上手くいきません。

上記の事を含めて修正したコマンドが上記となります。
Windows側のDockerのSettingsからShared Drivesの設定を行うのを忘れないようにする必要があるのと、–volumeに設定するドライブは「:/」から始める点にご注意ください。
他の指定方法も検索した際に見つかりましたが、他の手段ではファイルは出来たけど再起動したり消えたり、そもそもファイルが出来ないといった感じで上手くいきませんでした。

それでは、コマンドを流します。

docker ps -a

なんとなく起動したなというのが分かるかと思います。
また、`–volume`で指定したファイルが出来ているのも確認します。
起動までに結構かかるので、のんびり待ってください。

起動が上手くいかない場合の対処法

なぜか起動が上手くいかずに再起動を繰り返すことが良くあったため、その際にやったことを記載します。

1. まずはrestartする
restart直後はexecで内部を触れることが多いため、とりあえずrestartします。

docker restart gitlab

2.コンフィグの反映を試みる
大抵コンフィグを反映させると起動出来たので、とりあえずやってみます。
これでエラーとなることはなかったのですが、エラーになった場合は「docker logs gitlab」とするとログが出てきますので、それを見ながら解消を試みます。

これでもダメな場合はいったんコンテナを削除して入れなおした方が良いと思います。

docker exec -it gitlab gitlab-ctl reconfigure

Google側の設定を行う

IDとSecretは用意したことにします。
コールバックURLについてはSupported Providersのリンクから飛んだ先にきちんと書いていますので、ホスト部分を環境に合わせて変更して設定してください。

Gitlab側の設定を行う

コンテナ内部の設定ファイルを書き換えます。

docker exec -it gitlab vim /etc/gitlab/gitlab.rb

書き換え後の設定ファイルは以下となります。
設定の元となっている記述はあるので、少し書き換えれば良いのですぐに設定は完了します。
Providerの設定を公開する訳には流石にいかないので、そこは自身の環境に合わせて修正してください。

環境によっては設定内のexternal_urlも修正しないとRedirect先の生成がgitlab.example.comになってしまいエラーとなるため注意が必要です。

### OmniAuth Settings
###! Docs: https://docs.gitlab.com/ce/integration/omniauth.html
 gitlab_rails['omniauth_enabled'] = true
 gitlab_rails['omniauth_allow_single_sign_on'] = ['google_oauth2']
# gitlab_rails['omniauth_sync_email_from_provider'] = 'saml'
# gitlab_rails['omniauth_sync_profile_from_provider'] = ['saml']
# gitlab_rails['omniauth_sync_profile_attributes'] = ['email']
# gitlab_rails['omniauth_auto_sign_in_with_provider'] = 'saml'
 gitlab_rails['omniauth_block_auto_created_users'] = true
# gitlab_rails['omniauth_auto_link_ldap_user'] = false
# gitlab_rails['omniauth_auto_link_saml_user'] = false
 gitlab_rails['omniauth_external_providers'] = ['google_oauth2']
 gitlab_rails['omniauth_providers'] = [
   {
     "name" => "google_oauth2",
     "app_id" => "YOUR APP ID",
     "app_secret" => "YOUR APP SECRET",
     "args" => { "access_type" => "offline", "approval_prompt" => "" }
   }
 ]

設定変更した部分について説明していきます。

・omniauth_enabled
trueとしなければOpenIDでのログインが不可のためtrueにする必要があります。

・omniauth_allow_single_sign_on
ユーザーの自動生成を許可するかを決定します。
OpenIDでログインしようとしたユーザーがいなかった場合にユーザーとして自動生成するかの制御です。

true/false/[providers]と設定を記載することが可能となっています。
今回はgoogleからのログインは許可したいので[‘google_oauth2’]とします。
1つしかないのでtrueとするのと何か違うのかというと違いはありませんが、ログイン先を増やしたいとなった時のために設定を加えています。

・omniauth_block_auto_created_users
自動生成されたユーザーをBlockするかを決定します。
Blockしなければ自動生成されたユーザーはすぐにGitlabの機能を使用することが可能となります。
ここはtrue/falseで設定の制御を行うことができます。

今回は自動生成出来ても、それがこちらが許可すべきユーザーかを制御したいのでfalseで設定します。

・omniauth_external_providers
OpenIdとして許可するProviderを記述します。
許可可能なProviderは公式に書かれているので、こちらを参考にしてください。

・omniauth_providers
Providerの設定を記述していきます。
初期に書かれている設定からappIDとSecretを修正するだけなので、頑張って記載する必要はありません。

Gitlabの設定反映

設定を反映させるため、コンフィグの再構築を行います。

docker exec -it gitlab gitlab-ctl reconfigure

再構築後OpenIDでのログインが可能となっていれば成功です。
ログイン画面の下にGoogleからログインするためのアイコンが出ているので、それが目印です。

なぜかログインしようとしたら500エラーが出る

たいていは時刻設定がずれているために発生します。
なので、起きた場合はコンテナ内の時刻を確認します。

docker exec -it gitlab date

特に何も設定しないとUTCになっているかと思います。
この時間についてはHyper-Vの設定から時刻の同期を行う設定を行えば同期してくれるという話しかみかけないのですが、このコンテナはなぜか同期してくれませんでした。
時間かけて調べましたが分からなかったので、手動で時刻を動かして同期させて確認しています。
永続化させてないので、再起動したら元に戻りますが今回は自分の環境で確認出来れば良いという理由で妥協しました。

実際にログインしてみる

設定次第では新規ユーザーが作れなかったり、ユーザー作れても許可が必要だったりしますが、そこは上に書いている設定の書き換えが必要です。
新規ユーザー以外もアカウントページから紐づけが出来るため、既存で存在するユーザーもそこから紐づけて次からのログインでOpenIDを使用するといったことも可能となっています。

途中で設定を入れる際に既存ユーザーの扱いをどうするのかというのはよく課題になるのですが、考慮不要なのがうれしいところです。

そんな訳でこれにて全て完了となります。
Windowsならではのはまりポイントではまって色々と時間を使ってしまいましたが、設定自体は簡単かつすぐに設定可能なので、是非皆様も試していただければと思います。


              

OTHER CONTENTSその他のコンテンツ

UNITRUST会社を知る

  • 私たちについて

  • 企業情報

SERVICE事業内容

  • システム開発

CONTACT
お問い合わせ

あなたの「想い」に挑戦します。

どうぞお気軽にお問い合わせください。

受付時間:平日9:00〜18:00 日・祝日・弊社指定休業日は除く

お問い合わせ