OAuth authentication to gitlab when using linked containers

[obuchmann]

I encountered a Problem with OAuth authentication to gitlab when using linked containers.

2 cases:

• The variable GITLAB_URL is set automatically via linking feature (172.24.1.4) => OAuth fails when requesting gitlab Authorize because ip is not available to client via browser
• The variable GITLAB_URL is set maually and refers to the external given url (dockerhost:10080) => Gitlab Authorize required appears but OAuth fails after accept when redirecting to gitlab-ci (dockerhost:10081/user_sessions/callback?code=1234...) with 500 - maybe because gitlab-ci does not know gitlab via dockerhost:10080?

[sameersbn]

@kiselli please give some more details with respect to your setup. are you using SSL? docker commands that can be used to reproduce the issue?

[obuchmann]

Running on OS X with boot2docker (latest stable) with dockerhost pointing to boot2docker ip as hosts entry

No SSL in use and nothing predefined or Dockerfile changes. I'm using only the images from the repository.

using fig with following fig.yml:

gitlabdata:
 image: ubuntu:14.04
 volumes:
    - gitlabdata:/home/git/data   
gitlabdbdata:
 image: ubuntu:14.04
 volumes:
    - gitlabdbdata:/var/lib/postgresql
cidata:
  image: ubuntu:14.04
  volumes:
    - cidata:/home/gitlab_ci/data
cidbdata:
  image: ubuntu:14.04
  volumes:
    - cidbdata:/var/lib/postgresql

gitlabredis:
  image: sameersbn/redis:latest
gitlabdb:
  image: sameersbn/postgresql:latest
  environment:
    - DB_USER=gitlab
    - DB_PASS=password
    - DB_NAME=gitlabhq_production
  volumes_from:
    - gitlabdbdata
gitlab:
  image: sameersbn/gitlab:7.7.1 
  links:
   - gitlabredis:redisio
   - gitlabdb:postgresql
  ports:
   - "10080:80"
   - "10022:22"  
  volumes_from:
   - gitlabdata

ciredis:
  image: sameersbn/redis:latest
cidb:
  image: sameersbn/postgresql:latest
  environment:
    - DB_USER=gitlabci
    - DB_PASS=password
    - DB_NAME=gitlab_ci_production
  volumes_from:
    - cidbdata 
ci:
  image: sameersbn/gitlab-ci:latest
  links:
   - ciredis:redisio
   - cidb:postgresql
   - gitlab:gitlab
  ports:
   - "10081:80"    
  environment:   
   - GITLAB_APP_ID=f64f0d07f19fce5e05e58a0640ab5fbe4ef78801e176ac46168f6207b2ec90e8
   - GITLAB_APP_SECRET=94717780eaf30d8adffd4c7d89a40b0648cc869e8a62640813e5e5da79eeeb73
   - GITLAB_URL=http://dockerhost:10080/
  volumes_from:
   - cidata

my steps as follows:

• fig up gitlab
• creating application name: gitlab_ci callback_url: http://dockerhost:10081
• pasting GITLAB_APP and GITLAB_SECRET into fig.yml
• fig up ci
• Login with Gitlab

[sameersbn]

@kiselli I will give this a try on let you know. I am guessing that using boot2docker would probably require some additional configuration on the host for getting this to work. I cannot be sure though.

Have you set up DNS entries for your gitlab and ci servers?

[obuchmann]

No, I havn't set any DNS entrys inside the containers. I tried to solve this using docker linking. If I rely on an DNS there is no purpose of linking the containers.

But maybe the behavior of OAuth does not work togehter with docker linking because the validation authority(gitlab) has to be known to both the CI Server and the browser Client.

[sameersbn]

@kiselli using boot2docker complicates things a bit here. With the the oauth what happens is gitlab will redirect your browser to the ci server. This will probably be some : redirection in your case which i think the browser cannot connect to.

The proper way to wire everything up is to

1. Create DNS entries for the gitlab and ci servers. If this is a personal installation then you can make entries in your /etc/hosts file (the path to the hosts file might be different on osx).
2. Setup a reverse proxy server such as nginx/haproxy/hipache that proxies connections to each domain to the correct docker container. To give you a better understanding

| user | ---> git.example.com(80)---> | - proxy - |  ---10080---> | gitlab container | 

| user | ---> ci.example.com(80) ---> | - proxy - |  ---10081---> | ci container | 

p.s. the two | - proxy - | blocks represent a single reverse proxy server

I hope this makes sense

[cedvan]

Hello,

I've similar problem. I use Docker version 1.3.1, build 4e9bbfa on ubuntu 14.04 server. I've two DNS gitlab.domain.com and gitlab-ci.domain.com with nginx reverse proxy on host. I use SSL with certificates official and trusted on server. Gitlab and Gitlab CI work in same host, and I use docker link.

When I request Gitlab to authorize account access to gitlab CI. I click on Authorize button, and Gitlab redirect to _https://gitlab-ci.norsys.fr/user_sessions/callback?code=efc836..._, and I have a 502 Bad gateway nginx error.

an idea ?

[sameersbn]

@cedvan

• try specifying the GITLAB_URL parameter for the ci container instead of using docker links. Gitlab oauth seems to not play nicely when docker links are used to set the GITLAB_URL parameter.
• the gitlab container needs to trust the ssl cert of the gitlab-ci container and vice versa.
• lastly, check your reverse proxy configuration.

[cedvan]

• I have copy gitlab/certs/gitlab.crt to gitlab-ci/certs/ca.crt
• I have copy gitlab-ci/certs/gitlab_ci.crt to gitlab/certs/ca.crt
• I have delete link gitlab and add -e "GITLAB_URL=https://gitlab.domain.com"
• I have application gitlab-ci in Gitlab settings with Callback URL https://gitlab-ci.norsys.fr/user_sessions/callback
• I restart Gitlab
• I remove and run Gitlab-CI

I have always same problem :(

[sameersbn]

@cedvan first can you try curling curl https://gitlab.example.com from the ci container and curl https://gitlab-ci.example.com from the gitlab container? These should work without any issues and without having to do curl -k. If this test passes then we can confirm that the certificates are installed and trusted.

Now the only thing that could cause the problem would be the reverse proxy configuration. Here is the gist of my reverse proxy nginx configuration for gitlab. It can be adjusted for gitlab-ci as well. Hope you find this useful.

[cedvan]

Ok. I had an internal DNS problem ... My sysadmin is not cool !

It's work ! Thanks for help

[cedvan]

Just question off topic :

It's possible make indepandant project image gitlab and gitlab ci. ie dockerfile not inherit your specific ubuntu ? In order to allow the fork as valid backup ;)

[sameersbn]

@cedvan I dont understand what you mean.

[cedvan]

Currently dockerfile file of your project docker-gitlab uses your specific docker-ubuntu project. So docker-gitlab project is dependant of docker-ubuntu project. So if I want to save your work with a fork, I have to fork 2 projects, docker-gitlab and docker-ubuntu. I would like docker-gitlab uses native image ubuntu:14.04 for be completely independant, to just fork him.

The backup is necessary to save the system in a company, because if you stop your development, it is necessary that we can keep this software

[sameersbn]

@cedvan There are couple of reasons why I have a custom ubuntu image and why my images are built on top of this image.

1. sameersbn/ubuntu installs a set of common packages that I find useful across images. This also results in an improvement of disk space usage.
2. It also allow me to configure/apply system configurations and fixes in one place and have those changes take effect in all other images. As a result I dont have to repeat my self across images.
3. the official ubuntu:14.04 image is constantly updated with the same tag. This means that the ubuntu:14.04 image you download today will not be the same if you download it a month from now. This poses a problem when dealing with user issues where you have the "works for me" argument.
4. using a properly tagged version of sameersbn/ubuntu:14.04.XXXXXXXX guarantees that everyone is using the same base image and this helps a lot while dealing with issues. This is also one of the primary reason why I tag the gitlab images.

The sameersbn/ubuntu image currently offers me a lot of convenience that I am not willing to trade.

If you want to have a backup, yes you would have to fork 2 repos. Whats the big deal in that? You also have the choice of forking just the gitlab repo and merge contents for the dockerfile from the sameersbn/ubuntu repo into the gitlab repo. Its only a couple of lines.

You have a valid concern about development getting halted at some point, please consider contributing to the development of the image(s) in whatever way possible. Its the only way an open source project can survive.

[cedvan]

Ok, I understand !

I just started development project open-source arsenal created for automated creation of a full development stack. It will offer to install automatically using an interface nodejs several services open-source:

• Gitlab
• Gitlab CI
• Satis
• Docker Registry
• Sonar
• Redmine
• maybe other ?

all will be container, arsenal itself will be a container dind for encapsulate sercices.

Arsenal is dependant all images services. Some images are maintained by me as Satis or Postfix. For others I will try to contribute to the development of open-source images as docker-gitlab and docker-gitlab-ci. I hope to help you in the future.

Sources : https://github.com/cedvan/arsenal

[cedvan]

This argument is nice :

the official ubuntu:14.04 image is constantly updated with the same tag. This means that the ubuntu:14.04 image you download today will not be the same if you download it a month from now. This poses a problem when dealing with user issues where you have the "works for me" argument.

Finally I will take your system to the base on my containers and so for base Arsenal

[RunsFor]

Hi,

I had similar problem. Boot2docker has at least two interfaces:

1. External interface which you use to communicate with containers. For me its 192.168.59.103.
2. Internal interface which works as a gateway between containers, when they communicate each other. In my case its 172.17.42.1.

Since dockers port forwarding option -p binds to all host interfaces, all you need to do is to set up /etc/hosts files in containers and your local machine, so it would resolve dockerhost into the same boot2docker vm.

Basically it should looks like this:

local machine:

# /etc/hosts
192.168.59.103 dockerhost

gitlab and gitlab-ci containers:

# /etc/hosts
172.17.42.1 dockerhost

[sameersbn]

@RunsFor thanks for sharing the info.

[ebuildy]

I am getting 500 errors on the callback:

/user_sessions/callback?code=....

How can I debug it?

Thanks,

[sameersbn]

@ebuildy are you using https? If yes, I suggest you disable https on both gitlab and ci and check it all works fine. If it does, then you know the issue arises from ssl configuration.

For finer debugging you can access the container shell and watch the logs at /var/log/gitlab/ and /var/log/gitlab-ci for the gitlab and gitlab-ci containers respectively.

[ebuildy]

You are right, mount log volume helps a lot. BTW, is it possible to mount configuration as well?

I finally got it working by using the same DNS between my laptop and the Docker host. Now I have "setup" my fig.yml, it's really fantastic to see gitlab + gitlab-ci + runner working everywhere in just 5 minutes!

Thanks you again,

[sameersbn]

@ebuildy you can specify all required env variables in a file and specify it using the --env-file docker option. I don't know if this option is available in fig.

[ebuildy]

Yes this is working very well but need to re-init the docker container ;-( which can take a long time.

[sameersbn]

@ebuildy I dont understand what you mean.

[MichaeMimouni]

If that may help someone, i had a 500 error on calling the gitlab-ci user_sessions/callback. I'm using @sameersbn docker gitlab-ci:7.12.2 and gitlab:7.12.2-2 with an nginx reverse https proxy in front. As @sameersbn says, curl MUST call the gitlab url from the gitlab-ci docker without the '-k' switch. Which in my case didn't work. So as i'm on ubuntu 14.04, the way to trust my ca (i'm not using a self-signed but Gandi is not trusted on all system), is to copy the .pem as /usr/local/share/ca-certificates/certificate.crt and then run update-ca-certificates. Take care to force the extension to crt to work. And Tada!!!

[sameersbn]

@MichaeMimouni thats right. However you can copy your .pem file as ca.crt in the certs directory of the data volume and the image will automatically trust the certificate when the container is started. Refer to Installing Trusted SSL Server Certificates for details.