sameersbn / docker-gitlab-ci

Dockerfile to build a GitLab CI container image.
http://www.damagehead.com/docker-gitlab-ci/
MIT License
198 stars 51 forks source link

immediately exits on launch the gitlab-ci container #35

Open nemonik opened 9 years ago

nemonik commented 9 years ago

On OS X, the container immediately exits on launch the gitlab-ci container

docker logs ec7684e05bdf
mkdir: cannot create directory '/home/gitlab_ci/data/backups': Permission denied

and

CONTAINER ID        IMAGE                                                                     COMMAND                CREATED             STATUS                     PORTS               NAMES
ec7684e05bdf        sameersbn/gitlab-ci:7.11.4                                                "/app/init app:start   12 seconds ago      Exited (1) 6 seconds ago                       gitlab-ci              
52075b51378c        sameersbn/redis:latest                                                    "/start"               5 minutes ago       Up 5 minutes               6379/tcp            redis-gitlab-ci        
47078f2cef5f        sameersbn/postgresql:9.4                                                  "/start"               6 minutes ago       Up 5 minutes               5432/tcp            postgresql-gitlab-ci   

I used the quickstart, docker-compose.yml method. Thoughts?

nemonik commented 9 years ago

appears to be same as #32

sameersbn commented 9 years ago

@nemonik yes, that is correct. I just made a new 7.11.4-1 point release with the fix. You can use it.

nemonik commented 9 years ago

I got a bit farther on OS X by adding --publish=10022:22 and modifying _--env='GITLABURL to _--env='GITLABURL=http://`boot2docker ip`:10080' to the docker run to start and run the gitlab-ci container.

docker run --name=gitlab-ci -d \\n--link=postgresql-gitlab-ci:postgresql --link=redis-gitlab-ci:redisio \
--publish=10022:22 --publish=10080:80 \
--env='GITLAB_CI_PORT=10081' --env='GITLAB_URL=http://`boot2docker ip`:10080' \
--env='GITLAB_APP_ID=xxx' --env='GITLAB_APP_SECRET=yyy' \
--volume=/srv/docker/gitlab-ci/gitlab-ci:/home/gitlab_ci/data \\nsameersbn/gitlab-ci:7.11.4-1

gitlab-ci starts, but clicking on Login with GitLab, but it returns:

500

We're sorry, but something went wrong.

The logs, although likely not useful:

➜  ~ docker logs 7f42051b7dcd725f9643d1813403c04783f44ddd2aade871d47722d484152619
Waiting for database server to accept connections
2015-06-10 16:41:50,813 CRIT Supervisor running as root (no user in config file)
2015-06-10 16:41:50,813 WARN Included extra file "/etc/supervisor/conf.d/sidekiq.conf" during parsing
2015-06-10 16:41:50,813 WARN Included extra file "/etc/supervisor/conf.d/cron.conf" during parsing
2015-06-10 16:41:50,813 WARN Included extra file "/etc/supervisor/conf.d/unicorn.conf" during parsing
2015-06-10 16:41:50,814 WARN Included extra file "/etc/supervisor/conf.d/nginx.conf" during parsing
2015-06-10 16:41:50,837 INFO RPC interface 'supervisor' initialized
2015-06-10 16:41:50,837 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2015-06-10 16:41:50,837 INFO supervisord started with pid 1
2015-06-10 16:41:51,840 INFO spawned: 'sidekiq' with pid 117
2015-06-10 16:41:51,841 INFO spawned: 'unicorn' with pid 118
2015-06-10 16:41:51,843 INFO spawned: 'cron' with pid 119
2015-06-10 16:41:51,846 INFO spawned: 'nginx' with pid 120
2015-06-10 16:41:52,870 INFO success: sidekiq entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2015-06-10 16:41:52,871 INFO success: unicorn entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2015-06-10 16:41:52,871 INFO success: cron entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2015-06-10 16:41:52,871 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

Thoughts?

CalaxDev commented 9 years ago

I experience this error too and it is pretty bothering us right now. @sameersbn please can you look at it and help?

sameersbn commented 9 years ago

@nemonik @Z3roCoder this is basically a communication issue between the gitlab and ci containers. using ip addresses in GITLAB_HOST / GITLAB_URL seems to cause such issues. Please refer to https://github.com/sameersbn/docker-gitlab-ci/issues/28 for possible fixes.

CalaxDev commented 9 years ago

@sameersbn Alright, the other issue helped me to be at least able to click "Login" to GitLab. But now, after clicking Authorize, I get another 500 Error.

GitLab-CI Config:

ci:
  image: sameersbn/gitlab-ci:latest
  links:
    - redis:redisio
    - postgresql:postgresql
  external_links:
    - maildev_maildev_1:maildev
  ports:
    - "10081:80"
  environment:
    - TZ=Asia/Kolkata
    - GITLAB_URL=http://192.168.16.133:10080/gitlab/
    - GITLAB_APP_ID=*APPIDHERE*
    - GITLAB_APP_SECRET=*APPSECRETHERE*
    - GITLAB_CI_HOST=192.168.16.133
    - GITLAB_CI_RELATIVE_URL_ROOT=/gitlabci
#    - GITLAB_CI_PORT=10081
    - GITLAB_CI_EMAIL=ci@example.com
    - GITLAB_CI_SUPPORT=support@example.com
    - GITLAB_CI_NOTIFY_ON_BROKEN_BUILDS=true
    - GITLAB_CI_NOTIFY_PUSHER=false
    - GITLAB_CI_BACKUPS=daily
    - GITLAB_CI_BACKUP_TIME=01:00
    - SMTP_ENABLED=true
    - SMTP_DOMAIN=maildev
    - SMTP_HOST=maildev
    - SMTP_PORT=25
    - SMTP_STARTTLS=false
    - SMTP_AUTHENTICATION=login
  volumes:
    - /srv/docker/gitlab-ci/gitlab-ci:/home/gitlab_ci/data

GitLab runs on 192.168.16.133:10080/gitlab/ GitLab-CI runs on 192.168.16.133:10081/gitlabci/

My production.log tells me the following:

Started GET "/gitlabci/" for 127.0.0.1 at 2015-06-19 16:22:33 +0530
Processing by ProjectsController#index as HTML
  Rendered projects/_public.html.haml (27.7ms)
  Rendered projects/index.html.haml within layouts/application (37.1ms)
  Rendered layouts/_head.html.haml (10367.3ms)
  Rendered layouts/_nav.html.haml (6.1ms)
  Rendered layouts/_info.html.haml (2.3ms)
Completed 200 OK in 10471ms (Views: 10427.5ms | ActiveRecord: 17.0ms)
Started GET "/gitlabci/user_sessions/auth" for 127.0.0.1 at 2015-06-19 16:22:44 +0530
Processing by UserSessionsController#auth as HTML
Redirected to http://192.168.16.133:10080/gitlab/oauth/authorize?client_id=fa0718e9ef9122245fe1c6c7e3a98d80d41fdf822f243743d179b18f2ceb1046&redirect_uri=http%3A%2F%2F192.168.16.133%3A10081%2Fgitlabci%2Fuser_sessions%2Fcallback&response_type=code
Completed 403 Forbidden in 61ms (ActiveRecord: 10.5ms)
Started GET "/gitlabci/user_sessions/auth" for 127.0.0.1 at 2015-06-19 16:22:45 +0530
Processing by UserSessionsController#auth as HTML
Redirected to http://192.168.16.133:10080/gitlab/oauth/authorize?client_id=fa0718e9ef9122245fe1c6c7e3a98d80d41fdf822f243743d179b18f2ceb1046&redirect_uri=http%3A%2F%2F192.168.16.133%3A10081%2Fgitlabci%2Fuser_sessions%2Fcallback&response_type=code
Completed 302 Found in 5ms (ActiveRecord: 0.7ms)
Started GET "/gitlabci/user_sessions/callback?code=9fa6d2bcf605eadb3edf5a60648970ab90c0056b066cd9fe41113d9e4677573b" for 127.0.0.1 at 2015-06-19 16:22:49 +0530
Processing by UserSessionsController#callback as HTML
  Parameters: {"code"=>"9fa6d2bcf605eadb3edf5a60648970ab90c0056b066cd9fe41113d9e4677573b"}
Completed 500 Internal Server Error in 1008ms

Faraday::ConnectionFailed (No route to host - connect(2) for "192.168.16.133" port 10080):
  app/controllers/user_sessions_controller.rb:18:in `callback'
sameersbn commented 9 years ago

@Z3roCoder are you using boot2docker by any chance?

CalaxDev commented 9 years ago

@sameersbn No, I am solely using docker on CentOS7

sameersbn commented 9 years ago

@Z3roCoder Please exec into the gitlab-ci container and try accessing the gitlab container, eg wget http://192.168.16.133:10080 -O -. If this does not work, then it is probably some firewall rules or selinux causing problems. You can try disabling selinux setenforce 0 to test it.

CalaxDev commented 9 years ago

"No route to host" - Hmm... How do I get Gitlab-CI Container to communicate with gitLab? I have externally linked GitLab to GitLab-CI and told GitLab to expose its port?

sameersbn commented 9 years ago

@Z3roCoder The host is probably not allowing the two containers to talk to each other. This should probably be configured at the firewall (iptables) or it is possible that selinux is not allowing this communication.