Starting Sails.js inside a Docker container causes a Grunt error - node.js

I'm creating a Sails.js + MongoDB application and using Docker to run them locally. This is what my Docker setup looks like:
Dockerfile
FROM node:8.9.3-alpine
LABEL Name=web-service Version=1.0.0
# Container configuration
ENV NODE_ENV development
WORKDIR /usr/src/app
COPY ["package.json", "npm-shrinkwrap.json*", "./"]
RUN npm install -g sails#0.12.4 grunt nodemon && npm install && mv node_modules ../
VOLUME /usr/src/app
EXPOSE 1337
CMD nodemon
docker-compose.yml
version: '3.4'
services:
web-service:
image: web-service:latest
build: .
environment:
NODE_ENV: development
ports:
- 1338:1337 # HOST_PORT is 1338 to avoid conflicts with other Sails.js apps running on host
volumes:
- type: volume
source: .
target: /usr/src/app
read_only: true
mongoDb:
image: mongo:3.6
ports:
- 27018:27017 # HOST_PORT is 27018 to avoid conflicts with other MongoDB databases running on host
volumes:
- ./volumes/mongodb:/data/db
My image builds just fine however, when I run docker-compose up, I see the following error:
web-service_1 | [nodemon] starting `node app.js`
web-service_1 | info:
web-service_1 | info: .-..-.
web-service_1 | info:
web-service_1 | info: Sails <| .-..-.
web-service_1 | info: v0.12.4 |\
web-service_1 | info: /|.\
web-service_1 | info: / || \
web-service_1 | info: ,' |' \
web-service_1 | info: .-'.-==|/_--'
web-service_1 | info: `--'-------'
web-service_1 | info: __---___--___---___--___---___--___
web-service_1 | info: ____---___--___---___--___---___--___-__
web-service_1 | info:
web-service_1 | info: Server lifted in `/usr/src/app`
web-service_1 | info: To see your app, visit http://localhost:1337
web-service_1 | info: To shut down Sails, press <CTRL> + C at any time.
web-service_1 |
web-service_1 | debug: -------------------------------------------------------
web-service_1 |
web-service_1 | debug: :: Wed Jan 10 2018 18:37:23 GMT+0000 (UTC)
web-service_1 | debug: Environment : development
web-service_1 | debug: Port : 1337
web-service_1 | debug: -------------------------------------------------------
web-service_1 |
web-service_1 |
web-service_1 | error:
web-service_1 | ------------------------------------------------------------------------
web-service_1 | Fatal error: Unable to create directory "/usr/src/app/.tmp" (Error code: EROFS).
web-service_1 | Running "less:dev" (less) task
web-service_1 | ------------------------------------------------------------------------
web-service_1 | error: Looks like a Grunt error occurred--
web-service_1 | error: Please fix it, then **restart Sails** to continue running tasks (e.g. watching for changes in assets)
web-service_1 | error: Or if you're stuck, check out the troubleshooting tips below.
web-service_1 | error: Troubleshooting tips:
web-service_1 | error:
web-service_1 | error: *-> Are "grunt" and related grunt task modules installed locally? Run `npm install` if you're not sure.
web-service_1 | error:
web-service_1 | error: *-> You might have a malformed LESS, SASS, CoffeeScript file, etc.
web-service_1 | error:
web-service_1 | error: *-> Or maybe you don't have permissions to access the `.tmp` directory?
web-service_1 | error: e.g., `/usr/src/app/.tmp` ?
web-service_1 | error:
web-service_1 | error: If you think this might be the case, try running:
web-service_1 | error: sudo chown -R YOUR_COMPUTER_USER_NAME /usr/src/app/.tmp
If I understand correctly, Grunt and my packages from package.json should be installed because the image builds just fine. Could this be an issue with permissions as it says in the error above? If yes, how do I CHOWN the folder inside my container? Thanks.

The sails grunt task is trying to create a .tmp directory on the /usr/src/app volume you have set read_only: true on, remove the read only and it will work.
Obviously that volume won't be read only any more. The app user will need to write to the .tmp directory during the normal sails startup but not to the rest of the volume. You could run the app as a user without write privileges to /usr/src/app in the container image but with access to /usr/src/app/.tmp

Related

Rabbitmq instances are crashing

I am using docker-compose.yml file to spin 3 instances of RabbitMQ in a single host. Running docker on mac, When I run docker-compose up, I see erlang cookies are not matching for the instances in the cluster. Let me know if you need any other information.
version: '3'
services:
rabbitmq1:
image: rabbitmq:3.8.34-management
hostname: rabbitmq1
environment:
- RABBITMQ_ERLANG_COOKIE=12345
- RABBITMQ_DEFAULT_USER=guest
- RABBITMQ_DEFAULT_PASS=guest
- RABBITMQ_DEFAULT_VHOST=/
rabbitmq2:
image: rabbitmq:3.8.34-management
hostname: rabbitmq2
depends_on:
- rabbitmq1
environment:
- RABBITMQ_ERLANG_COOKIE=12345
- RABBITMQ_DEFAULT_USER=guest
- RABBITMQ_DEFAULT_PASS=guest
- RABBITMQ_DEFAULT_VHOST=/
volumes:
- ./cluster-entrypoint.sh:/usr/local/bin/cluster-entrypoint.sh
entrypoint: /usr/local/bin/cluster-entrypoint.sh
rabbitmq3:
image: rabbitmq:3.8.34-management
hostname: rabbitmq3
depends_on:
- rabbitmq1
environment:
- RABBITMQ_ERLANG_COOKIE=12345
- RABBITMQ_DEFAULT_USER=guest
- RABBITMQ_DEFAULT_PASS=guest
- RABBITMQ_DEFAULT_VHOST=/
volumes:
- ./cluster-entrypoint.sh:/usr/local/bin/cluster-entrypoint.sh
entrypoint: /usr/local/bin/cluster-entrypoint.sh
haproxy:
image: haproxy:1.7
volumes:
- ./haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro
depends_on:
- rabbitmq1
- rabbitmq2
- rabbitmq3
ports:
- 15672:15672
- 5672:5672
Below is my cluster-entrypoint.sh file
#!/bin/bash
set -e
# Start RMQ from entry point.
# This will ensure that environment variables passed
# will be honored
/usr/local/bin/docker-entrypoint.sh rabbitmq-server -detached
# Do the cluster dance
rabbitmqctl stop_app
rabbitmqctl join_cluster rabbit#rabbitmq1
# Stop the entire RMQ server. This is done so that we
# can attach to it again, but without the -detached flag
# making it run in the forground
rabbitmqctl stop
# Wait a while for the app to really stop
sleep 2s
# Start it
rabbitmq-server
Sorry for too many logs. I have used RabbitMQ:3.8.34 image, erlang cookies for all instances in cluster are different and RabbitMQ1 starts but other instances does not start.
Below is the log:
haproxy_1 | <7>haproxy-systemd-wrapper: executing /usr/local/sbin/haproxy -p /run/haproxy.pid -db -f /usr/local/etc/haproxy/haproxy.cfg -Ds
rabbitmq1_1 |
rabbitmq1_1 | warning: /var/lib/rabbitmq/.erlang.cookie contents do not match RABBITMQ_ERLANG_COOKIE
rabbitmq1_1 |
rabbitmq1_1 | WARNING: '/var/lib/rabbitmq/.erlang.cookie' was populated from '$RABBITMQ_ERLANG_COOKIE', which will no longer happen in 3.9 and later! (https://github.com/docker-library/rabbitmq/pull/424)
rabbitmq2_1 |
rabbitmq2_1 | warning: /var/lib/rabbitmq/.erlang.cookie contents do not match RABBITMQ_ERLANG_COOKIE
rabbitmq2_1 |
rabbitmq2_1 | WARNING: '/var/lib/rabbitmq/.erlang.cookie' was populated from '$RABBITMQ_ERLANG_COOKIE', which will no longer happen in 3.9 and later! (https://github.com/docker-library/rabbitmq/pull/424)
rabbitmq3_1 |
rabbitmq3_1 | warning: /var/lib/rabbitmq/.erlang.cookie contents do not match RABBITMQ_ERLANG_COOKIE
rabbitmq3_1 |
rabbitmq3_1 | WARNING: '/var/lib/rabbitmq/.erlang.cookie' was populated from '$RABBITMQ_ERLANG_COOKIE', which will no longer happen in 3.9 and later! (https://github.com/docker-library/rabbitmq/pull/424)
rabbitmq1_1 | WARNING: 'docker-entrypoint.sh' generated/modified the RabbitMQ configuration file, which will no longer happen in 3.9 and later! (https://github.com/docker-library/rabbitmq/pull/424)
rabbitmq1_1 |
rabbitmq1_1 | Generated end result, for reference:
rabbitmq1_1 | ------------------------------------
rabbitmq1_1 | loopback_users.guest = false
rabbitmq1_1 | listeners.tcp.default = 5672
rabbitmq1_1 | default_pass = guest
rabbitmq1_1 | default_user = guest
rabbitmq1_1 | default_vhost = /
rabbitmq1_1 | management.tcp.port = 15672
rabbitmq1_1 | ------------------------------------
rabbitmq3_1 | WARNING: 'docker-entrypoint.sh' generated/modified the RabbitMQ configuration file, which will no longer happen in 3.9 and later! (https://github.com/docker-library/rabbitmq/pull/424)
rabbitmq3_1 |
rabbitmq3_1 | Generated end result, for reference:
rabbitmq3_1 | ------------------------------------
rabbitmq3_1 | loopback_users.guest = false
rabbitmq3_1 | listeners.tcp.default = 5672
rabbitmq3_1 | default_pass = guest
rabbitmq3_1 | default_user = guest
rabbitmq3_1 | default_vhost = /
rabbitmq3_1 | management.tcp.port = 15672
rabbitmq3_1 | ------------------------------------
rabbitmq2_1 | WARNING: 'docker-entrypoint.sh' generated/modified the RabbitMQ configuration file, which will no longer happen in 3.9 and later! (https://github.com/docker-library/rabbitmq/pull/424)
rabbitmq2_1 |
rabbitmq2_1 | Generated end result, for reference:
rabbitmq2_1 | ------------------------------------
rabbitmq2_1 | loopback_users.guest = false
rabbitmq2_1 | listeners.tcp.default = 5672
rabbitmq2_1 | default_pass = guest
rabbitmq2_1 | default_user = guest
rabbitmq2_1 | default_vhost = /
rabbitmq2_1 | management.tcp.port = 15672
rabbitmq2_1 | ------------------------------------
rabbitmq3_1 | RABBITMQ_ERLANG_COOKIE env variable support is deprecated and will be REMOVED in a future version. Use the $HOME/.erlang.cookie file or the --erlang-cookie switch instead.
rabbitmq3_1 | Stopping rabbit application on node rabbit#rabbitmq3 ...
rabbitmq3_1 | Error: unable to perform an operation on node 'rabbit#rabbitmq3'. Please see diagnostics information and suggestions below.
rabbitmq3_1 |
rabbitmq3_1 | Most common reasons for this are:
rabbitmq3_1 |
rabbitmq3_1 | * Target node is unreachable (e.g. due to hostname resolution, TCP connection or firewall issues)
rabbitmq3_1 | * CLI tool fails to authenticate with the server (e.g. due to CLI tool's Erlang cookie not matching that of the server)
rabbitmq3_1 | * Target node is not running
rabbitmq3_1 |
rabbitmq3_1 | In addition to the diagnostics info below:
rabbitmq3_1 |
rabbitmq3_1 | * See the CLI, clustering and networking guides on https://rabbitmq.com/documentation.html to learn more
rabbitmq3_1 | * Consult server logs on node rabbit#rabbitmq3
rabbitmq3_1 | * If target node is configured to use long node names, don't forget to use --longnames with CLI tools
rabbitmq3_1 |
rabbitmq3_1 | DIAGNOSTICS
rabbitmq3_1 | ===========
rabbitmq3_1 |
rabbitmq3_1 | attempted to contact: [rabbit#rabbitmq3]
rabbitmq3_1 |
rabbitmq3_1 | rabbit#rabbitmq3:
rabbitmq3_1 | * connected to epmd (port 4369) on rabbitmq3
rabbitmq3_1 | * epmd reports: node 'rabbit' not running at all
rabbitmq3_1 | no other nodes on rabbitmq3
rabbitmq3_1 | * suggestion: start the node
rabbitmq3_1 |
rabbitmq3_1 | Current node details:
rabbitmq3_1 | * node name: 'rabbitmqcli-797-rabbit#rabbitmq3'
rabbitmq3_1 | * effective user's home directory: /var/lib/rabbitmq
rabbitmq3_1 | * Erlang cookie hash: gnzLDuqKcGxMNKFokfhOew==
rabbitmq3_1 |
docker-rabbitmq-cluster_rabbitmq3_1 exited with code 69
rabbitmq2_1 | RABBITMQ_ERLANG_COOKIE env variable support is deprecated and will be REMOVED in a future version. Use the $HOME/.erlang.cookie file or the --erlang-cookie switch instead.
rabbitmq2_1 | Stopping rabbit application on node rabbit#rabbitmq2 ...
rabbitmq2_1 | Error: unable to perform an operation on node 'rabbit#rabbitmq2'. Please see diagnostics information and suggestions below.
rabbitmq2_1 |
rabbitmq2_1 | Most common reasons for this are:
rabbitmq2_1 |
rabbitmq2_1 | * Target node is unreachable (e.g. due to hostname resolution, TCP connection or firewall issues)
rabbitmq2_1 | * CLI tool fails to authenticate with the server (e.g. due to CLI tool's Erlang cookie not matching that of the server)
rabbitmq2_1 | * Target node is not running
rabbitmq2_1 |
rabbitmq2_1 | In addition to the diagnostics info below:
rabbitmq2_1 |
rabbitmq2_1 | * See the CLI, clustering and networking guides on https://rabbitmq.com/documentation.html to learn more
rabbitmq2_1 | * Consult server logs on node rabbit#rabbitmq2
rabbitmq2_1 | * If target node is configured to use long node names, don't forget to use --longnames with CLI tools
rabbitmq2_1 |
rabbitmq2_1 | DIAGNOSTICS
rabbitmq2_1 | ===========
rabbitmq2_1 |
rabbitmq2_1 | attempted to contact: [rabbit#rabbitmq2]
rabbitmq2_1 |
rabbitmq2_1 | rabbit#rabbitmq2:
rabbitmq2_1 | * connected to epmd (port 4369) on rabbitmq2
rabbitmq2_1 | * epmd reports: node 'rabbit' not running at all
rabbitmq2_1 | no other nodes on rabbitmq2
rabbitmq2_1 | * suggestion: start the node
rabbitmq2_1 |
rabbitmq2_1 | Current node details:
rabbitmq2_1 | * node name: 'rabbitmqcli-568-rabbit#rabbitmq2'
rabbitmq2_1 | * effective user's home directory: /var/lib/rabbitmq
rabbitmq2_1 | * Erlang cookie hash: gnzLDuqKcGxMNKFokfhOew==
rabbitmq2_1 |
docker-rabbitmq-cluster_rabbitmq2_1 exited with code 69
rabbitmq1_1 | Configuring logger redirection
rabbitmq1_1 | 2022-07-05 02:43:40.659 [debug] <0.288.0> Lager installed handler error_logger_lager_h into error_logger
rabbitmq1_1 | 2022-07-05 02:43:40.670 [debug] <0.291.0> Lager installed handler lager_forwarder_backend into error_logger_lager_event
rabbitmq1_1 | 2022-07-05 02:43:40.670 [debug] <0.312.0> Lager installed handler lager_forwarder_backend into rabbit_log_mirroring_lager_event
rabbitmq1_1 | 2022-07-05 02:43:40.670 [debug] <0.303.0> Lager installed handler lager_forwarder_backend into rabbit_log_feature_flags_lager_event
rabbitmq1_1 | 2022-07-05 02:43:40.670 [debug] <0.309.0> Lager installed handler lager_forwarder_backend into rabbit_log_ldap_lager_event
rabbitmq1_1 | 2022-07-05 02:43:40.670 [debug] <0.294.0> Lager installed handler lager_forwarder_backend into rabbit_log_lager_event
rabbitmq1_1 | 2022-07-05 02:43:40.670 [debug] <0.297.0> Lager installed handler lager_forwarder_backend into rabbit_log_channel_lager_event
rabbitmq1_1 | 2022-07-05 02:43:40.670 [debug] <0.306.0> Lager installed handler lager_forwarder_backend into rabbit_log_federation_lager_event
rabbitmq1_1 | 2022-07-05 02:43:40.670 [debug] <0.300.0> Lager installed handler lager_forwarder_backend into rabbit_log_connection_lager_event
rabbitmq1_1 | 2022-07-05 02:43:40.671 [debug] <0.315.0> Lager installed handler lager_forwarder_backend into rabbit_log_prelaunch_lager_event
rabbitmq1_1 | 2022-07-05 02:43:40.672 [debug] <0.318.0> Lager installed handler lager_forwarder_backend into rabbit_log_queue_lager_event
rabbitmq1_1 | 2022-07-05 02:43:40.673 [debug] <0.321.0> Lager installed handler lager_forwarder_backend into rabbit_log_ra_lager_event
rabbitmq1_1 | 2022-07-05 02:43:40.675 [debug] <0.324.0> Lager installed handler lager_forwarder_backend into rabbit_log_shovel_lager_event
rabbitmq1_1 | 2022-07-05 02:43:40.676 [debug] <0.327.0> Lager installed handler lager_forwarder_backend into rabbit_log_upgrade_lager_event
rabbitmq1_1 | 2022-07-05 02:43:40.691 [info] <0.44.0> Application lager started on node rabbit#rabbitmq1
rabbitmq1_1 | 2022-07-05 02:43:41.159 [debug] <0.284.0> Lager installed handler lager_backend_throttle into lager_event
haproxy_1 | [ALERT] 185/024336 (8) : parsing [/usr/local/etc/haproxy/haproxy.cfg:32] : 'server rabbitmq2' : could not resolve address 'rabbitmq2'.
haproxy_1 | [ALERT] 185/024336 (8) : parsing [/usr/local/etc/haproxy/haproxy.cfg:33] : 'server rabbitmq3' : could not resolve address 'rabbitmq3'.
haproxy_1 | [ALERT] 185/024336 (8) : parsing [/usr/local/etc/haproxy/haproxy.cfg:43] : 'server rabbitmq2' : could not resolve address 'rabbitmq2'.
haproxy_1 | [ALERT] 185/024336 (8) : parsing [/usr/local/etc/haproxy/haproxy.cfg:44] : 'server rabbitmq3' : could not resolve address 'rabbitmq3'.
haproxy_1 | [ALERT] 185/024336 (8) : Failed to initialize server(s) addr.
haproxy_1 | <5>haproxy-systemd-wrapper: exit, haproxy RC=1
docker-rabbitmq-cluster_haproxy_1 exited with code 1
rabbitmq1_1 | 2022-07-05 02:43:43.065 [info] <0.44.0> Application mnesia started on node rabbit#rabbitmq1
rabbitmq1_1 | 2022-07-05 02:43:43.066 [info] <0.273.0>
rabbitmq1_1 | Starting RabbitMQ 3.8.34 on Erlang 24.3.4.1 [emu]
rabbitmq1_1 | Copyright (c) 2007-2022 VMware, Inc. or its affiliates.
rabbitmq1_1 | Licensed under the MPL 2.0. Website: https://rabbitmq.com
rabbitmq1_1 |
rabbitmq1_1 | ## ## RabbitMQ 3.8.34
rabbitmq1_1 | ## ##
rabbitmq1_1 | ########## Copyright (c) 2007-2022 VMware, Inc. or its affiliates.
rabbitmq1_1 | ###### ##
rabbitmq1_1 | ########## Licensed under the MPL 2.0. Website: https://rabbitmq.com
rabbitmq1_1 |
rabbitmq1_1 | Erlang: 24.3.4.1 [emu]
rabbitmq1_1 | TLS Library: OpenSSL - OpenSSL 1.1.1o 3 May 2022
rabbitmq1_1 |
rabbitmq1_1 | Doc guides: https://rabbitmq.com/documentation.html
rabbitmq1_1 | Support: https://rabbitmq.com/contact.html
rabbitmq1_1 | Tutorials: https://rabbitmq.com/getstarted.html
rabbitmq1_1 | Monitoring: https://rabbitmq.com/monitoring.html
rabbitmq1_1 |
rabbitmq1_1 | Logs: <stdout>
rabbitmq1_1 |
rabbitmq1_1 | Config file(s): /etc/rabbitmq/rabbitmq.conf
rabbitmq1_1 |
rabbitmq1_1 | Starting broker...2022-07-05 02:43:43.068 [info] <0.273.0>
rabbitmq1_1 | node : rabbit#rabbitmq1
rabbitmq1_1 | home dir : /var/lib/rabbitmq
rabbitmq1_1 | config file(s) : /etc/rabbitmq/rabbitmq.conf
rabbitmq1_1 | cookie hash : VlfoFK5J8f9Ln3G9sXDoPQ==
rabbitmq1_1 | log(s) : <stdout>
rabbitmq1_1 | database dir : /var/lib/rabbitmq/mnesia/rabbit#rabbitmq1
rabbitmq1_1 | 2022-07-05 02:43:44.265 [info] <0.44.0> Application amqp_client started on node rabbit#rabbitmq1
rabbitmq1_1 | 2022-07-05 02:43:44.279 [info] <0.584.0> Management plugin: HTTP (non-TLS) listener started on port 15672
rabbitmq1_1 | 2022-07-05 02:43:44.279 [info] <0.612.0> Statistics database started.
rabbitmq1_1 | 2022-07-05 02:43:44.279 [info] <0.611.0> Starting worker pool 'management_worker_pool' with 3 processes in it
rabbitmq1_1 | 2022-07-05 02:43:44.279 [info] <0.44.0> Application rabbitmq_management started on node rabbit#rabbitmq1
rabbitmq1_1 | 2022-07-05 02:43:44.292 [info] <0.44.0> Application prometheus started on node rabbit#rabbitmq1
rabbitmq1_1 | 2022-07-05 02:43:44.294 [info] <0.625.0> Prometheus metrics: HTTP (non-TLS) listener started on port 15692
rabbitmq1_1 | 2022-07-05 02:43:44.294 [info] <0.525.0> Ready to start client connection listeners
rabbitmq1_1 | 2022-07-05 02:43:44.294 [info] <0.44.0> Application rabbitmq_prometheus started on node rabbit#rabbitmq1
rabbitmq1_1 | 2022-07-05 02:43:44.297 [info] <0.669.0> started TCP listener on [::]:5672
rabbitmq1_1 | 2022-07-05 02:43:45.321 [info] <0.525.0> Server startup complete; 4 plugins started.
rabbitmq1_1 | * rabbitmq_prometheus
rabbitmq1_1 | * rabbitmq_management
rabbitmq1_1 | * rabbitmq_web_dispatch
rabbitmq1_1 | * rabbitmq_management_agent
rabbitmq1_1 | completed with 4 plugins.
rabbitmq1_1 | 2022-07-05 02:43:45.322 [info] <0.525.0> Resetting node maintenance status
I am not sure what I am missing. Sorry for too much of logs.
After analysing your files and log files I can observe few issues.
Your setup will be able to start only once while there no files/configuration and you are doing it from the scratch. The reason of such behaviour is that RabbitMQ stores configuration to internal DB called Mnesia and it is mandatory that once nodes added it should be present for further start. If you won't follow it you will observer errors that the node waiting for mnesia to find its nodes.
Another issue with repetitive start is that node that was added (2 or 3) to a cluster marks itself as a cluster member, you will see an error that main node (1) expects to connect to earlier connected but your entry-point already reset 2 and 3 nodes.
You cannot combine versions of RabbitMQ cause it might contain different data structures that will not allow nodes to sync and you will have an error like "schema_integrity_check_failed...", it should be all identical.
When I was using RabbitMQ, my configuration ensures that there is persistent location (disk) with all the data and that repetitive start will use already initialised data. Also it is a good practice to use cluster management software such as etc or consul that is supported by RabbitMQ and you don't need to handle it yourself.
Hope that would help.
Generally I was able to successfully start your setup on my machine (macOS) with docker, the script is the following:
ensure you never started the compose in order to avoid the data from previous runs
prepare everything in the folder
do docker-compose up, enjoy everything works
use docker-compose down for cleanup the stack not '... stop' command cause the data will stay
Below you can find a log for the start, please ignore ha_proxy error, there is no config file attached so it must fail
% docker-compose up
Creating network "rabbitmq_default" with the default driver
Creating rabbitmq_rabbitmq1_1 ... done
Creating rabbitmq_rabbitmq3_1 ... done
Creating rabbitmq_rabbitmq2_1 ... done
Creating rabbitmq_haproxy_1 ... done
Attaching to rabbitmq_rabbitmq1_1, rabbitmq_rabbitmq3_1, rabbitmq_rabbitmq2_1, rabbitmq_haproxy_1
(due to limitation I've put it here)
My setup looks like this, the only change is that rabbitMQ data is persisted and init is done manually, you also can mount data folder from file system path
version: '3'
services:
rabbitmq1:
image: rabbitmq:3.8.34-management
hostname: rabbitmq1
environment:
- RABBITMQ_ERLANG_COOKIE=12345
- RABBITMQ_DEFAULT_USER=guest
- RABBITMQ_DEFAULT_PASS=guest
- RABBITMQ_DEFAULT_VHOST=/
volumes:
- rabbitmq-01-data:/var/lib/rabbitmq
rabbitmq2:
image: rabbitmq:3.8.34-management
hostname: rabbitmq2
depends_on:
- rabbitmq1
environment:
- RABBITMQ_ERLANG_COOKIE=12345
- RABBITMQ_DEFAULT_USER=guest
- RABBITMQ_DEFAULT_PASS=guest
- RABBITMQ_DEFAULT_VHOST=/
volumes:
- rabbitmq-02-data:/var/lib/rabbitmq
rabbitmq3:
image: rabbitmq:3.8.34-management
hostname: rabbitmq3
depends_on:
- rabbitmq1
environment:
- RABBITMQ_ERLANG_COOKIE=12345
- RABBITMQ_DEFAULT_USER=guest
- RABBITMQ_DEFAULT_PASS=guest
- RABBITMQ_DEFAULT_VHOST=/
volumes:
- rabbitmq-03-data:/var/lib/rabbitmq
volumes:
rabbitmq-01-data:
rabbitmq-02-data:
rabbitmq-03-data:
Manual run on every "follower" node
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit#rabbitmq1
rabbitmqctl start_app
Don't forget to enable redundant queues if applicable for your case
rabbitmqctl set_policy ha "." '{"ha-mode":"all"}'
I have a complete RabbitMQ setup that forms a cluster using docker-compose here:
https://github.com/lukebakken/docker-rabbitmq-cluster
Please note that the following mirroring policy is NOT recommended. There is no need to mirror queues to all nodes -
rabbitmqctl set_policy ha "." '{"ha-mode":"all"}'
You should mirror to 2 nodes in your cluster.
BETTER YET, use the latest version of RabbitMQ and use Quorum Queues! Classic HA mirroring will be removed from RabbitMQ in version 4.0
https://www.rabbitmq.com/quorum-queues.html
NOTE: the RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.

Dockerized Node App unable to connect to Dockerized Postgres Database

I have tried many possible solutions to it, Not able to make any of them work.
Here it goes:
I built a nodejs container and a postgres docker container. Used docker compose to configure them both and used Dockerfile to build the nodejs/typescript application.
docker-compose.yml
version: "3"
volumes:
pg_vol:
networks:
app-network:
driver: bridge
services:
db:
container_name: db
image: postgres
ports:
- "5432:5432"
environment:
- POSTGRES_DB=db22
- POSTGRES_USER=postgres
- POSTGRES_PASSWORD=q123
volumes:
- pg_vol:/var/lib/postgresql/data
networks:
- app-network
webapp:
container_name: webapp
build:
context: ./
dockerfile: Dockerfile
environment:
- DATABASE_URL=postgres://postgres:q123#db:5432/db22
ports:
- "5000:5000"
networks:
- app-network
depends_on:
- db
Dockerfile
FROM node:14
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm install
COPY ./dist .
CMD [ "npm", "start" ]
When I do docker-compose up --build, it shows an error while connecting to the postgres db. DB starts alright.
Error STDOUT
Starting db ... done
Starting webapp ... done
Attaching to db, webapp
db |
db | PostgreSQL Database directory appears to contain a database; Skipping initialization
db |
db | 2020-11-24 16:32:25.918 UTC [1] LOG: starting PostgreSQL 13.1 (Debian 13.1-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
db | 2020-11-24 16:32:25.918 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
db | 2020-11-24 16:32:25.918 UTC [1] LOG: listening on IPv6 address "::", port 5432
db | 2020-11-24 16:32:25.923 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
db | 2020-11-24 16:32:25.928 UTC [25] LOG: database system was shut down at 2020-11-24 16:32:18 UTC
db | 2020-11-24 16:32:25.933 UTC [1] LOG: database system is ready to accept connections
webapp |
webapp | > backend-postgres#1.0.0 start /usr/src/app
webapp | > node app.js
webapp |
webapp | undefined
webapp | undefined
webapp | running in-code config
webapp | Error: connect EHOSTUNREACH 172.19.0.2:5432
webapp | at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1146:16) {
webapp | errno: -113,
webapp | code: 'EHOSTUNREACH',
webapp | syscall: 'connect',
webapp | address: '172.19.0.2',
webapp | port: 5432
webapp | }
webapp | npm ERR! code ELIFECYCLE
webapp | npm ERR! errno 1
webapp | npm ERR! backend-postgres#1.0.0 start: `node app.js`
webapp | npm ERR! Exit status 1
webapp | npm ERR!
webapp | npm ERR! Failed at the backend-postgres#1.0.0 start script.
webapp | npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
webapp |
webapp | npm ERR! A complete log of this run can be found in:
webapp | npm ERR! /root/.npm/_logs/2020-11-24T16_32_26_955Z-debug.log
webapp exited with code 1
Please help with correcting me.
System:
Fedora 33 (Workstation Edition)
EDIT:
I restarted the docker container with command docker start webapp. Same error as above.
Judging by logs: the app exits with 1 because the host at port 5432 was unreachable,maybe the database was not ready yet (you can verify it by checking if db22 is created on db container ).What you can is : add restart policy on webapp ,using this :
webap : ..
restart_policy: condition: on-failure
then check then if the problem persists
My system is Fedora 33 (Workstation Edition). This had some issues with Docker.
Turns out:
With the release of Fedora 33, Docker is not supported by Fedora 33 officially. Oct 29, 2020
I uninstalled docker. Rebooted my laptop.
Then install Podman and Podman Compose. Everything works perfectly fine.
Thank you all for help.

Docker-compose up exited with code 1 but successful docker-compose build

When trying to docker-compose up I get errors from the frontend and backend where they exit with code 1. docker ps shows that the postgres container is still running but the frontend and backend still exit. Using npm start, there is no errors. I don't know if it this helps, but my files do not copy from my src folder to /usr/src/app/ so maybe there is an error with my docker-compose or Dockerfiles.
Docker ps shows:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
509208b2243b postgres:latest "docker-entrypoint.s…" 14 hours ago Up 11 minutes 0.0.0.0:5432->5432/tcp example_db_1
docker-compose.yml
version: '3'
services:
frontend:
build: ./frontend
volumes:
- ./data/nginx:/etc/nginx/conf.d
- ./data/certbot/conf:/etc/letsencrypt
- ./data/certbot/www:/var/www/certbot
- ./frontend/build:/usr/share/nginx/html
ports:
- 80:80
- 443:443
depends_on:
- backend
backend:
build: ./backend
volumes:
- ./backend/src:/usr/src/app/src
- ./data/certbot/conf:/etc/letsencrypt
ports:
- 3000:3000
depends_on:
- db
db:
image: postgres:latest
restart: always
environment:
POSTGRES_USER: example
POSTGRES_PASSWORD: example1234
POSTGRES_DB: example
ports:
- 5432:5432
certbot:
image: certbot/certbot
volumes:
- ./data/certbot/conf:/etc/letsencrypt
- ./data/certbot/www:/var/www/certbot
# Automatic certificate renewal
# entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"
This is what the backend Dockerfile looks like.
FROM node:current-alpine
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app/
COPY package*.json /usr/src/app/
RUN npm install
COPY . /usr/src/app/
EXPOSE 3000
ENV NODE_ENV=production
CMD ["npm", "start"]
And the output error:
example_db_1 is up-to-date
Starting example_certbot_1 ... done
Starting example_backend_1 ... done
Starting example_frontend_1 ... done
Attaching to example_db_1, example_certbot_1, example_backend_1, example_frontend_1
backend_1 |
backend_1 | > example-backend#1.0.0 start /usr/src/app
backend_1 | > npx tsc; node ./out/
backend_1 |
certbot_1 | Saving debug log to /var/log/letsencrypt/letsencrypt.log
certbot_1 | Certbot doesn't know how to automatically configure the web server on this system. However, it can still get a certificate for you. Please run "certbot certonly" to do so. You'll need to manually configure your web server to use the resulting certificate.
frontend_1 | 2020/02/13 11:35:59 [emerg] 1#1: open() "/etc/letsencrypt/options-ssl-nginx.conf" failed (2: No such file or directory) in /etc/nginx/conf.d/app.conf:21
frontend_1 | nginx: [emerg] open() "/etc/letsencrypt/options-ssl-nginx.conf" failed (2: No such file or directory) in /etc/nginx/conf.d/app.conf:21
db_1 | The files belonging to this database system will be owned by user "postgres".
db_1 | This user must also own the server process.
db_1 |
db_1 | The database cluster will be initialized with locale "en_US.utf8".
db_1 | The default database encoding has accordingly been set to "UTF8".
db_1 | The default text search configuration will be set to "english".
db_1 |
db_1 | Data page checksums are disabled.
db_1 |
db_1 | fixing permissions on existing directory /var/lib/postgresql/data ... ok
db_1 | creating subdirectories ... ok
db_1 | selecting dynamic shared memory implementation ... posix
db_1 | selecting default max_connections ... 100
db_1 | selecting default shared_buffers ... 128MB
db_1 | selecting default time zone ... Etc/UTC
db_1 | creating configuration files ... ok
db_1 | running bootstrap script ... ok
db_1 | performing post-bootstrap initialization ... ok
db_1 | syncing data to disk ... ok
db_1 |
db_1 | initdb: warning: enabling "trust" authentication for local connections
db_1 | You can change this by editing pg_hba.conf or using the option -A, or
db_1 | --auth-local and --auth-host, the next time you run initdb.
db_1 |
db_1 | Success. You can now start the database server using:
db_1 |
db_1 | pg_ctl -D /var/lib/postgresql/data -l logfile start
db_1 |
db_1 | waiting for server to start....2020-02-12 21:51:40.137 UTC [43] LOG: starting PostgreSQL 12.1 (Debian 12.1-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
db_1 | 2020-02-12 21:51:40.147 UTC [43] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
db_1 | 2020-02-12 21:51:40.229 UTC [44] LOG: database system was shut down at 2020-02-12 21:51:39 UTC
db_1 | 2020-02-12 21:51:40.240 UTC [43] LOG: database system is ready to accept connections
db_1 | done
db_1 | server started
db_1 | CREATE DATABASE
db_1 |
db_1 |
db_1 | /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
db_1 |
db_1 | 2020-02-12 21:51:40.606 UTC [43] LOG: received fast shutdown request
db_1 | waiting for server to shut down....2020-02-12 21:51:40.608 UTC [43] LOG: aborting any
active transactions
db_1 | 2020-02-12 21:51:40.614 UTC [43] LOG: background worker "logical replication launcher" (PID 50) exited with exit code 1
db_1 | 2020-02-12 21:51:40.614 UTC [45] LOG: shutting down
db_1 | 2020-02-12 21:51:40.652 UTC [43] LOG: database system is shut down
db_1 | done
db_1 | server stopped
db_1 |
db_1 | PostgreSQL init process complete; ready for start up.
db_1 |
db_1 | 2020-02-12 21:51:40.728 UTC [1] LOG: starting PostgreSQL 12.1 (Debian 12.1-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
db_1 | 2020-02-12 21:51:40.729 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
db_1 | 2020-02-12 21:51:40.729 UTC [1] LOG: listening on IPv6 address "::", port 5432
db_1 | 2020-02-12 21:51:40.748 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
db_1 | 2020-02-12 21:51:40.788 UTC [61] LOG: database system was shut down at 2020-02-12 21:51:40 UTC
db_1 | 2020-02-12 21:51:40.799 UTC [1] LOG: database system is ready to accept connections
db_1 | 2020-02-13 09:51:41.562 UTC [787] LOG: invalid length of startup packet
db_1 | 2020-02-13 11:09:27.384 UTC [865] FATAL: password authentication failed for user "postgres"
db_1 | 2020-02-13 11:09:27.384 UTC [865] DETAIL: Role "postgres" does not exist.
db_1 | Connection matched pg_hba.conf line 95: "host all all all md5"
db_1 | 2020-02-13 11:32:18.771 UTC [1] LOG: received smart shutdown request
db_1 | 2020-02-13 11:32:18.806 UTC [1] LOG: background worker "logical replication launcher"
(PID 67) exited with exit code 1
db_1 | 2020-02-13 11:32:18.806 UTC [62] LOG: shutting down
db_1 | 2020-02-13 11:32:18.876 UTC [1] LOG: database system is shut down
db_1 |
db_1 | PostgreSQL Database directory appears to contain a database; Skipping initialization
db_1 |
db_1 | 2020-02-13 11:33:01.343 UTC [1] LOG: starting PostgreSQL 12.1 (Debian 12.1-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
db_1 | 2020-02-13 11:33:01.343 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
db_1 | 2020-02-13 11:33:01.343 UTC [1] LOG: listening on IPv6 address "::", port 5432
db_1 | 2020-02-13 11:33:01.355 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
db_1 | 2020-02-13 11:33:01.427 UTC [23] LOG: database system was shut down at 2020-02-13 11:32:18 UTC
db_1 | 2020-02-13 11:33:01.466 UTC [1] LOG: database system is ready to accept connections
example_certbot_1 exited with code 1
example_frontend_1 exited with code 1
backend_1 | Authenticating with database...
backend_1 | internal/fs/utils.js:220
backend_1 | throw err;
backend_1 | ^
backend_1 |
backend_1 | Error: ENOENT: no such file or directory, open '/etc/letsencrypt/live/example.org/privkey.pem'
backend_1 | at Object.openSync (fs.js:440:3)
backend_1 | at Object.readFileSync (fs.js:342:35)
backend_1 | at Object.<anonymous> (/usr/src/app/out/index.js:68:23)
backend_1 | at Module._compile (internal/modules/cjs/loader.js:955:30)
backend_1 | at Object.Module._extensions..js (internal/modules/cjs/loader.js:991:10)
backend_1 | syscall: 'open', 811:32)
backend_1 | code: 'ENOENT', loader.js:723:14)
backend_1 | path: '/etc/letsencrypt/live/example.org/s/loader.js:1043:10)privkey.pem'
backend_1 | }
backend_1 | npm ERR! code ELIFECYCLE
backend_1 | npm ERR! errno 1
backend_1 | npm ERR! example-backend#1.0.0 start: `npx tsc; noprivkey.pem'de ./out/`
backend_1 | npm ERR! Exit status 1
backend_1 | npm ERR!
backend_1 | npm ERR! Failed at the example-backend#1.0.0 startde ./out/` script.
backend_1 | npm ERR! This is probably not a problem with npm. There is likely additional logging output above. script.
backend_1 | here is likely additional logging ou
backend_1 | npm ERR! A complete log of this run can be found in:
backend_1 | npm ERR! /root/.npm/_logs/2020-02-13T11_36_10_3:30Z-debug.log 30Z-debug.log
example_backend_1 exited with code 1
There are no errors with certbot when run outside this project.
Directory structure:
src/
- docker-compose.yml
- init.letsencrypt.sh
- .gitignore
backend
src
- Dockerfile
- package.json
- .gitignore
data
nginx
- app.conf
frontend
src
- Dockerfile
- package.json
- .gitignore
Any help would be appreciated, thanks.
Updated nginx.conf:
server {
listen 80;
server_name example.org;
location / {
root /var/www/html/;
index index.html;
autoindex on;
}
location /frontend {
proxy_pass http://example.org:8080;
try_files $uri /public/index.html;
}
location /backend {
proxy_pass http://example.org:3000;
}
location /db {
proxy_pass http://example.org:5432;
}
}
new error when changing .gitignore:
frontend_1 | 2020/02/13 16:34:58 [emerg] 1#1: cannot load certificate "/etc/letsencrypt/live/example.org/fullchain.pem":
BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/example.org/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
frontend_1 | nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/example.org/fullchain.pem": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/example.org/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
example_frontend_1 exited with code 1
The setup seems very complicated. My advice for you: Try to reduce the complicated overhead with the certbot as own docker-container.
#docker-compose.yml
version: '3'
services:
frontend:
build: ./frontend
volumes:
- ./data/nginx:/etc/nginx/conf.d
# no source-code of the frontend via volumes -
# only a nginx-image with your source.
# nginx-conf as volume is valid.
ports:
- 8080:80
depends_on:
- backend
backend:
build: ./backend
# dont put your source as volume in,
# your docker-image should contains the whole code
# and no certbot magic here
ports:
- 3000:3000
depends_on:
- db
db:
image: postgres:latest
restart: always
environment:
POSTGRES_USER: example
POSTGRES_PASSWORD: example1234
POSTGRES_DB: example
ports:
- 5432:5432
This is much cleaner and easy to read. Now you should setup a reverse proxy on your hostmachine (easy with nginx). Configure your published ports into your nginx-reverse-proxy (proxy_pass localhost:8080 for your frontend as example).
After that you can install the certbot and obtain your lets-encrypt-certificates. The certbot should discover your nginx-endpoints automatically and can automatic renew your certificates.

Create Docker image for NodeJS + PostgreSQL web application

I've been reading Docker's documentation, but I can't get around creating an image that will work.
I have a NodeJS application that uses PostgreSQL as database:
var connectionString = process.env.DATABASE_URL || 'postgres://localhost:5432/db';
var pg = require('pg');
var pgp = require('pg-promise')();
var db = pgp(connectionString);
db.func('some_storedProcedure').then(//...)
//...
I first created a Dockerfile according to Node's documentation for it:
FROM node:argon
# Create app directory
RUN mkdir -p /app
WORKDIR /app
# Install app dependencies
COPY package.json /app
RUN npm install
# Bundle app source
COPY . /app
EXPOSE 5000
CMD [ "npm", "start" ]
I then followed this post regarding connecting the database to it with docker-compose. the docker-compose.yml file looks like:
web:
build: .
ports:
- "5000:5000"
volumes:
- .:/app
links:
- db
environment:
DATABASE_URL: postgres://myuser:mypass#db:5432/db
db:
image: postgres
environment:
POSTGRES_USER: myuser
POSTGRES_PASSWORD: mypass
This is (some) of what is returned when I run docker-compose up with these files, after creating the image.
npm info ok
---> 87dbbae35721
Removing intermediate container c73f826a0b3d
Step 6 : COPY . /app
---> ec56bfc11d3c
Removing intermediate container 745ddf82d742
Step 7 : EXPOSE 5000
---> Running in b2be5aecd9d6
---> a7d126a7ea5e
Removing intermediate container b2be5aecd9d6
Step 8 : CMD npm start
---> Running in 0379d512c688
---> 266517f47311
Removing intermediate container 0379d512c688
Successfully built 266517f47311
WARNING: Image for service web was built because it did not already exist. To rebuild this image you must use `docker-compose build` or `docker-compose up --build`.
Starting imagename_db_1
Creating imagename_web_1
Attaching to imagename_db_1, imagename_web_1
web_1 | npm info it worked if it ends with ok
web_1 | npm info using npm#2.15.1
web_1 | npm info using node#v4.4.3
web_1 | npm info prestart SharedServer#5.8.0
web_1 | npm info start SharedServer#5.8.0
web_1 |
web_1 | > SharedServer#5.8.0 start /app
web_1 | > node index.js
web_1 |
web_1 | Wed, 27 Apr 2016 00:41:19 GMT body-parser deprecated bodyParser: use individual json/urlencoded middlewares at index.js:13:9
web_1 | Wed, 27 Apr 2016 00:41:19 GMT body-parser deprecated undefined extended: provide extended option at node_modules/body-parser/index.js:105:29
web_1 | Node app is running on port 5000
db_1 | LOG: database system was interrupted; last known up at 2016-04-25 00:17:59 UTC
db_1 | LOG: database system was not properly shut down; automatic recovery in progress
db_1 | LOG: invalid record length at 0/17076E8
db_1 | LOG: redo is not required
db_1 | LOG: MultiXact member wraparound protections are now enabled
db_1 | LOG: database system is ready to accept connections
db_1 | LOG: autovacuum launcher started
When I access http://localhost:5000, I see the web application running, but whenever I fire up something that tries to access the database, I get a HTTP 500 error with the following body
code: "28P01"
file: "auth.c"
length: 98
line: "285"
name: "error"
routine: "auth_failed"
severity: "FATAL"
What am I doing wrong? I'm not sure I understand what I'm doing with Docker, and the only thing I have for documentation are simple recipes to build specific environments (or at least, that's what I've understood)
Thanks.
Check your pg_hba.conf in $PGDATA allows connections from node.js.
By default the pg_hba.conf is like so:
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
This is fine for your standard psql connectivity via the OS owner as it allows local connections trusted for localhost IP address 127.0.0.1. However if you have an IP address set on the server, which I'm guessing you do then you need to allow an entry for that because in your node.js configuration you're referring to a host of "DB". So ping "DB" and add that IP address:
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
host db myuser <ip-for-db-host> md5
Once you've changed that file you will need to perform a pg_ctl reload.

Nodemon doesn't restart

I have a nodemon running in a docker-container with a mounted volume on OSX. Nodemon is receiving the file-change but it doesn't restart the server.
Output:
Creating piclet_web_1...
Attaching to piclet_web_1
web_1 | 7 Sep 13:37:19 - [nodemon] v1.4.1
web_1 | 7 Sep 13:37:19 - [nodemon] to restart at any time, enter `rs`
web_1 | 7 Sep 13:37:19 - [nodemon] watching: *.*
web_1 | 7 Sep 13:37:19 - [nodemon] starting node ./index.js
web_1 | restify listening at http://[::]:80 //normal output of started node-app
//file-change, which gets detected
web_1 | 7 Sep 13:37:30 - [nodemon] restarting due to changes...
//no output of restarted server
Dockerfile:
FROM node:0.12.7-wheezy
EXPOSE 80
RUN npm install nodemon -g
ADD app /app
WORKDIR app
RUN npm install
docker-compose.yml
web:
build: .
ports:
- "80:80"
volumes:
- ./app/lib:/app/lib
links:
- db
command: "nodemon -L ./index.js"
db:
image: mongo:3.1.7
I solved the issue by choosing another base-image for the container: node:0.12.7 instead of node:0.12.7-wheezy

Resources