`failed to start mysql server`; when NOT using Mysql about docker-gitlab

[sameersbn]

@thrisp for linking with postgresql container to work the postgresql server should expose the 5432 port. If it does not, then the container will not be able to figure out the link and will instead start a mysql server internally.

But I don't understand why the mysql server wont start in this case. Can you just try starting the container with

docker run -i -t --rm sameersbn/gitlab:latest

Can you tell me which postgresql container are you using? Can I pull it from the docker index?

[1xch]

running

docker run -i -t --rm sameersbn/gitlab:latest

seems to run ok; there is a lot of output there that looks like its doing something constructive; however I cannnot connect to the container ip address (in this instance 172.17.42.1) even after 5 minutes post command.

postgres image is:

orchardup/postgresql:latest

run with:

sudo docker run -d --name pgdatalocal -p 127.0.0.1:5432:5432 -v /opt/postgresql:/var/lib/postgresql orchardup/postgresql 

[sameersbn]

seems to run ok; there is a lot of output there that looks like its doing something constructive; however I cannnot connect to the container ip address (in this instance 172.17.42.1) even after 5 minutes post command.

172.17.42.1 seems like its the host ip of the docker0 interface and not the ip address of the container. please check.

I will try using the orchardup/postgresql:latest image and get back with you.

[sameersbn]

@thrisp I tried the orchardup/postgresql and had not issues using it.

Start postgresql container with a user and database for gitlab

mkdir -p /opt/postgresql
docker run -d --name pgdatalocal -v /opt/postgresql:/var/lib/postgresql \
-e "POSTGRESQL_USER=gitlab"  -e "POSTGRESQL_PASS=password" \
-e "POSTGRESQL_DB=gitlabhq_production"  orchardup/postgresql

Start gitlab setup with the postgresql container linked

docker run -i -t --rm --name=gitlab --link pgdatalocal:postgresql \
-v /opt/gitlab:/home/git/data \
-e "DB_USER=gitlab" -e "DB_PASS=password" -e "DB_NAME=gitlabhq_production" \
sameersbn/gitlab:latest app:rake gitlab:setup

Now start the gitlab application

docker run -i -t --rm --name=gitlab --link pgdatalocal:postgresql \
-v /opt/gitlab:/home/git/data \
-e "DB_USER=gitlab" -e "DB_PASS=password" -e "DB_NAME=gitlabhq_production" \
sameersbn/gitlab:latest

Launch the web browser.

GITLAB_IP=$(docker inspect gitlab | grep IPAddres | awk -F'"' '{print $4}')
xdg-open "http://${GITLAB_IP}"

However, please note that gitlab restore does not seem to be working when using a linked postgresql server. For example,

Creating a backup works.

docker run -i -t --rm --name=gitlab --link pgdatalocal:postgresql \
-v /opt/gitlab:/home/git/data \
-e "DB_USER=gitlab" -e "DB_PASS=password" -e "DB_NAME=gitlabhq_production" \
sameersbn/gitlab:latest app:rake gitlab:backup:create

Restoring a backup takes dump while your watching...

docker run -i -t --rm --name=gitlab --link pgdatalocal:postgresql \
-v /opt/gitlab:/home/git/data \
-e "DB_USER=gitlab" -e "DB_PASS=password" -e "DB_NAME=gitlabhq_production" \
sameersbn/gitlab:latest app:rake gitlab:backup:restore

Unpacking backup ... done
Restoring database ... 
Restoring PostgreSQL database gitlabhq_production ... [FAILED]
done
Restoring repositories ...
rake aborted!
PG::Error: ERROR:  relation "projects" does not exist
LINE 1: SELECT  "projects".* FROM "projects"   ORDER BY "projects"."...
                                  ^
: SELECT  "projects".* FROM "projects"   ORDER BY "projects"."id" ASC LIMIT 1000
/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/postgresql_adapter.rb:774:in `exec'
/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/postgresql_adapter.rb:774:in `exec_no_cache'
/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/postgresql/database_statements.rb:138:in `block in exec_query'
/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract_adapter.rb:435:in `block in log'
/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.3/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract_adapter.rb:430:in `log'
/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/postgresql/database_statements.rb:137:in `exec_query'
/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/postgresql_adapter.rb:891:in `select'
/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/database_statements.rb:24:in `select_all'
/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.3/lib/active_record/connection_adapters/abstract/query_cache.rb:63:in `select_all'
/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.3/lib/active_record/querying.rb:36:in `find_by_sql'
/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.3/lib/active_record/relation.rb:585:in `exec_queries'
/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.3/lib/active_record/relation.rb:471:in `load'
/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.3/lib/active_record/relation.rb:220:in `to_a'
/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.3/lib/active_record/relation/batches.rb:69:in `find_in_batches'
/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activerecord-deprecated_finders-1.0.3/lib/active_record/deprecated_finders/relation.rb:70:in `find_in_batches'
/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.3/lib/active_record/relation/batches.rb:25:in `find_each'
/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.3/lib/active_record/querying.rb:8:in `find_each'
/home/git/gitlab/lib/backup/repository.rb:51:in `restore'
/home/git/gitlab/lib/tasks/gitlab/backup.rake:45:in `block (4 levels) in <top (required)>'
/home/git/gitlab/lib/tasks/gitlab/backup.rake:29:in `block (3 levels) in <top (required)>'
Tasks: TOP => gitlab:backup:repo:restore
(See full trace by running task with --trace)

Now I don't know whether this is an issue with

• using postgresql in a container
• using postgresql in general
• some configuration issue for the postgresql user, given my inexperience with using postgresql
• some postgresql support issue in gitlab
• or something else

I have tried various postgresql containers and all exhibit the same behaviour. The postgresql images i tried include:

• sameersbn/postgresql
• paintedfox/postgresql
• orchardup/postgresql
  Nothing seems to work when trying to restore a gitlab backup.

[sameersbn]

@thrisp I think I know why restore is not working when a postgresql server is used. Basically the postgresql-client package needs to be installed in the gitlab container.

I will add that and check.

[sameersbn]

@thrisp yup, that was the cause of the restore operation not working when postgresql was used. fixed in fc0a6d1

[1xch]

I'm still new to using Docker, but as for starting I'm able to use the latest image with a postgresql container, the dev container I have.

[1xch]

thank you