DiUS / pact_broker-docker

'Dockerised' pact broker
http://pact.io
MIT License
76 stars 102 forks source link

Example `docker-compose up` does not start successfully due to passenger/RVM. #79

Closed BookOfGreg closed 5 years ago

BookOfGreg commented 5 years ago

Pre issue-raising checklist

I have already (please mark the applicable with an x):

Software versions

Expected behaviour

When I use the example docker-compose here I should have a working pact-broker.

docker-compose up

I changed the nginx ports to the following as I am not running this as root and do not need SSL yet:

    ports:
      - "8080:80"

Actual behaviour

It appears Passenger shuts down on startup but the container doesn't finish?

broker_app_1  | [ N 2018-10-22 10:12:06.9462 29/T1 age/Cor/CoreMain.cpp:1080 ]: Received command to shutdown gracefully. Waiting until all clients have disconnected...
broker_app_1  | [ N 2018-10-22 10:12:06.9462 29/T1 age/Cor/CoreMain.cpp:994 ]: Checking whether to disconnect long-running connections for process 471, application /home/app/pact_broker/public
broker_app_1  | [ N 2018-10-22 10:12:06.9463 29/T9 Ser/Server.h:886 ]: [ApiServer] Freed 0 spare client objects
broker_app_1  | [ N 2018-10-22 10:12:06.9463 29/T9 Ser/Server.h:531 ]: [ApiServer] Shutdown finished
broker_app_1  | [ N 2018-10-22 10:12:06.9464 29/T4 Ser/Server.h:886 ]: [ServerThr.1] Freed 128 spare client objects
broker_app_1  | [ N 2018-10-22 10:12:06.9465 29/T4 Ser/Server.h:531 ]: [ServerThr.1] Shutdown finished
broker_app_1  | [ N 2018-10-22 10:12:06.9465 29/T1 age/Cor/CoreMain.cpp:994 ]: Checking whether to disconnect long-running connections for process 471, application /home/app/pact_broker/public
broker_app_1  |
broker_app_1  | [ N 2018-10-22 10:12:07.3723 29/T4 age/Cor/CoreMain.cpp:589 ]: Signal received. Gracefully shutting down... (send signal 1 more time(s) to force shutdown)
broker_app_1  | [ N 2018-10-22 10:12:07.4707 29/T1 age/Cor/CoreMain.cpp:1150 ]: Passenger core shutdown finished
broker_app_1  | Oct 22 10:12:31 cf33b1761c91 syslog-ng[20]: syslog-ng starting up; version='3.5.6'
broker_app_1  | ok: run: /etc/service/nginx-log-forwarder: (pid 25) 0s
broker_app_1  | [ N 2018-10-22 10:12:32.2939 26/T1 age/Wat/WatchdogMain.cpp:1267 ]: Starting Passenger watchdog...
broker_app_1  | [ N 2018-10-22 10:12:32.3028 29/T1 age/Cor/CoreMain.cpp:1165 ]: Starting Passenger core...
broker_app_1  | [ N 2018-10-22 10:12:32.3029 29/T1 age/Cor/CoreMain.cpp:249 ]: Passenger core running in multi-application mode.
broker_app_1  | [ N 2018-10-22 10:12:32.3070 29/T1 age/Cor/CoreMain.cpp:905 ]: Passenger core online, PID 29
broker_app_1  | [ E 2018-10-22 10:12:34.4163 29/T8 age/Cor/SecurityUpdateChecker.h:376 ]: A security update is available for your version (5.1.11) of Passenger, we strongly recommend upgrading to version 5.3.5.
broker_app_1  | [ E 2018-10-22 10:12:34.4164 29/T8 age/Cor/SecurityUpdateChecker.h:381 ]:  Additional information:
broker_app_1  | - [Fixed in 5.3.2] [CVE-2018-12026, 12027, and 12028] These are local denial of service, local information disclosure and local privilege escalation vulnerabilities that could be exploited by malicious applications or malicious users on the system.
broker_app_1  | - [Fixed in 5.3.2] [CVE-2018-12029] A local privilege escalation vulnerability existed in the Nginx module that occurs when `passenger_instance_registry_dir` is configured to a directory with lax permissions.
broker_app_1  | App 45 stdout:
broker_app_1  | App 45 stderr:
broker_app_1  | App 45 stderr: Warning: PATH set to RVM ruby but GEM_HOME and/or GEM_PATH not set, see:
broker_app_1  | App 45 stderr:     https://github.com/rvm/rvm/issues/3212
broker_app_1  | App 45 stderr:
nginx_1       | 192.168.112.1 - - [22/Oct/2018:10:12:40 +0000] "GET / HTTP/1.1" 401 0 "-" "curl/7.58.0" "-"
broker_app_1  | App 471 stdout:

I also believe the postgres DB has never been migrated.

postgres_1    | 2018-10-22 10:19:13.310 UTC [55] ERROR:  relation "schema_migrations" does not exist at character 27
postgres_1    | 2018-10-22 10:19:13.310 UTC [55] STATEMENT:  SELECT NULL AS "nil" FROM "schema_migrations" LIMIT 1
postgres_1    | 2018-10-22 10:19:13.322 UTC [55] ERROR:  relation "schema_info" does not exist at character 27
postgres_1    | 2018-10-22 10:19:13.322 UTC [55] STATEMENT:  SELECT NULL AS "nil" FROM "schema_info" LIMIT 1

Edit: If I'm using a sqlite db I get a similar issue, but more debug logs:

App 46 stdout:
broker_app_1  | App 46 stdout: E, [2018-10-22T10:49:26.215719 #46] ERROR -- : SQLite3::SQLException: no such table: schema_migrations: SELECT NULL AS 'nil' FROM `schema_migrations` LIMIT 1
broker_app_1  | App 46 stdout: E, [2018-10-22T10:49:26.221352 #46] ERROR -- : SQLite3::SQLException: no such table: schema_info: SELECT NULL AS 'nil' FROM `schema_info` LIMIT 1
broker_app_1  | App 46 stdout: E, [2018-10-22T10:49:26.319264 #46] ERROR -- : SQLite3::SQLException: no such table: tags_backup0: SELECT NULL AS 'nil' FROM `tags_backup0` LIMIT 1

Steps to reproduce

docker-compose up on the example docker-compose.

Relevent log files

Please ensure you set logging to DEBUG and attach any relevant log files here (or link from a gist).

bethesque commented 5 years ago

The db logs are fine, they're just saying that the schema_info table does not yet exist (as you would expect the first time).

The RVM error comes up all the time as well, it can be ignored.

Does it work when you don't change the ports?

BookOfGreg commented 5 years ago

Opening another tab and using curl -v http://localhost:80 or 8080 makes no difference and doesn't trigger anything additional in the logs. Do I need to manually trigger the database to setup when using the docker-compose?

Sorry for the daft question, I feel like I child when I can't solve these simple things myself, I'm probably missing something obvious. I really appreciate your time helping me.

BookOfGreg commented 5 years ago

Not sure what the difference is but it's working now. Could be that I cleared a load of disk space on the docker host. but honestly couldn't pin it down.