Rabbitmq instances are crashing - linux

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.

Related

unable to run kibana with docker-compose

I am trying to run Kibana with opendistro elasticsearch using the following docker-compose:
version: '3'
services:
odfe-node1:
image: amazon/opendistro-for-elasticsearch:1.11.0
container_name: odfe-node1
environment:
- cluster.name=odfe-cluster
- node.name=odfe-node1
- discovery.seed_hosts=odfe-node1
- cluster.initial_master_nodes=odfe-node1
- bootstrap.memory_lock=true # along with the memlock settings below, disables swapping
- "ES_JAVA_OPTS=-Xms1g -Xmx1g" # minimum and maximum Java heap size, recommend setting both to 50% of system RAM
ulimits:
memlock:
soft: -1
hard: -1
nofile:
soft: 65536 # maximum number of open files for the Elasticsearch user, set to at least 65536 on modern systems
hard: 65536
volumes:
- odfe-data1:/usr/share/elasticsearch/data
ports:
- 9200:9200
- 9600:9600 # required for Performance Analyzer
networks:
- odfe-net
kibana:
image: amazon/opendistro-for-elasticsearch-kibana:1.11.0
container_name: odfe-kibana
ports:
- 5601:5601
expose:
- "5601"
environment:
ELASTICSEARCH_URL: https://odfe-node1:9200
ELASTICSEARCH_HOSTS: https://odfe-node1:9200
networks:
- odfe-net
volumes:
odfe-data1:
networks:
odfe-net:
after running the above docker-compose using
docker-compose up
i get the following error:
Starting odfe-kibana ... done
Starting odfe-node1 ... done
Attaching to odfe-kibana, odfe-node1
odfe-node1 | OpenDistro for Elasticsearch Security Demo Installer
odfe-node1 | ** Warning: Do not use on production or public reachable systems **
odfe-node1 | Basedir: /usr/share/elasticsearch
odfe-node1 | Elasticsearch install type: rpm/deb on CentOS Linux release 7.8.2003 (Core)
odfe-node1 | Elasticsearch config dir: /usr/share/elasticsearch/config
odfe-node1 | Elasticsearch config file: /usr/share/elasticsearch/config/elasticsearch.yml
odfe-node1 | Elasticsearch bin dir: /usr/share/elasticsearch/bin
odfe-node1 | Elasticsearch plugins dir: /usr/share/elasticsearch/plugins
odfe-node1 | Elasticsearch lib dir: /usr/share/elasticsearch/lib
odfe-node1 | Detected Elasticsearch Version: x-content-7.9.1
odfe-node1 | Detected Open Distro Security Version: 1.11.0.0
odfe-node1 | /usr/share/elasticsearch/config/elasticsearch.yml seems to be already configured for Security. Quit.
odfe-node1 | Unlinking stale socket /usr/share/supervisor/performance_analyzer/supervisord.sock
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:12Z","tags":["warning","plugins-discovery"],"pid":1,"message":"Expect plugin \"id\" in camelCase, but found: opendistro-notebooks-kibana"}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:22Z","tags":["info","plugins-service"],"pid":1,"message":"Plugin \"telemetryManagementSection\" has been disabled since the following direct or transitive dependencies are missing or disabled: [telemetry]"}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:22Z","tags":["info","plugins-service"],"pid":1,"message":"Plugin \"newsfeed\" is disabled."}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:22Z","tags":["info","plugins-service"],"pid":1,"message":"Plugin \"telemetry\" is disabled."}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:22Z","tags":["info","plugins-service"],"pid":1,"message":"Plugin \"visTypeXy\" is disabled."}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:26Z","tags":["warning","legacy-service"],"pid":1,"message":"Some installed third party plugin(s) [opendistro-alerting, opendistro-anomaly-detection-kibana, opendistro_index_management_kibana, opendistro-query-workbench] are using the legacy plugin format and will no longer work in a future Kibana release. Please refer to https://ela.st/kibana-breaking-changes-8-0 for a list of breaking changes and https://ela.st/kibana-platform-migration for documentation on how to migrate legacy plugins."}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:27Z","tags":["info","plugins-system"],"pid":1,"message":"Setting up [38] plugins: [usageCollection,telemetryCollectionManager,kibanaUsageCollection,kibanaLegacy,mapsLegacy,timelion,share,legacyExport,esUiShared,bfetch,expressions,data,home,console,apmOss,management,indexPatternManagement,advancedSettings,savedObjects,opendistroSecurity,visualizations,visualize,visTypeVega,visTypeTimelion,visTypeTable,visTypeMarkdown,tileMap,inputControlVis,regionMap,dashboard,opendistro-notebooks-kibana,charts,visTypeVislib,visTypeTimeseries,visTypeTagcloud,visTypeMetric,discover,savedObjectsManagement]"}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:28Z","tags":["info","savedobjects-service"],"pid":1,"message":"Waiting until all Elasticsearch nodes are compatible with Kibana before starting saved objects migrations..."}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:29Z","tags":["error","elasticsearch","data"],"pid":1,"message":"Request error, retrying\nGET https://odfe-node1:9200/_nodes?filter_path=nodes.*.version%2Cnodes.*.http.publish_address%2Cnodes.*.ip => connect ECONNREFUSED 172.19.0.3:9200"}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:31Z","tags":["warning","elasticsearch","data"],"pid":1,"message":"Unable to revive connection: https://odfe-node1:9200/"}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:32Z","tags":["warning","elasticsearch","data"],"pid":1,"message":"No living connections"}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:32Z","tags":["error","savedobjects-service"],"pid":1,"message":"Unable to retrieve version information from Elasticsearch nodes."}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:33Z","tags":["warning","elasticsearch","data"],"pid":1,"message":"Unable to revive connection: https://odfe-node1:9200/"}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:33Z","tags":["warning","elasticsearch","data"],"pid":1,"message":"No living connections"}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:35Z","tags":["warning","elasticsearch","data"],"pid":1,"message":"Unable to revive connection: https://odfe-node1:9200/"}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:35Z","tags":["warning","elasticsearch","data"],"pid":1,"message":"No living connections"}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:37Z","tags":["warning","elasticsearch","data"],"pid":1,"message":"Unable to revive connection: https://odfe-node1:9200/"}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:37Z","tags":["warning","elasticsearch","data"],"pid":1,"message":"No living connections"}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:40Z","tags":["warning","elasticsearch","data"],"pid":1,"message":"Unable to revive connection: https://odfe-node1:9200/"}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:41Z","tags":["warning","elasticsearch","data"],"pid":1,"message":"No living connections"}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:42Z","tags":["warning","elasticsearch","data"],"pid":1,"message":"Unable to revive connection: https://odfe-node1:9200/"}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:42Z","tags":["warning","elasticsearch","data"],"pid":1,"message":"No living connections"}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:45Z","tags":["warning","elasticsearch","data"],"pid":1,"message":"Unable to revive connection: https://odfe-node1:9200/"}
odfe-kibana | {"type":"log","#timestamp":"2022-09-05T11:04:45Z","tags":["warning","elasticsearch","data"],"pid":1,"message":"No living connections"}
odfe-kibana exited with code 137
odfe-node1 exited with code 137
i donn know why i am always got this exit status with those only two services running with docker-compose
so if anyone had the same issue or can help, please feel free
Exit code 137 indicates that the container was terminated due to an out of memory issue.
Try adding
ulimits:
memlock:
soft: -1
hard: -1
to Kibana service as well.

PostgreSQL not working on docker when volume is initialized

I am using windows docker
my docker-compose file is as shown below:
version: '3.5'
services:
postgres:
container_name: postgres_container
image: postgres
environment:
POSTGRES_USER: ${POSTGRES_USER:-postgres}
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-root}
PGDATA: /data/postgres
volumes:
- ./postgres-data:/var/
ports:
- "5432:5432"
restart: unless-stopped
When i build it i get following error log and container exits
Attaching to postgres_container
postgres_container | The files belonging to this database system will be owned by user "postgres".
postgres_container | This user must also own the server process.
postgres_container |
postgres_container | The database cluster will be initialized with locale "en_US.utf8".
postgres_container | The default database encoding has accordingly been set to "UTF8".
postgres_container | The default text search configuration will be set to "english".
postgres_container |
postgres_container | Data page checksums are disabled.
postgres_container |
postgres_container | fixing permissions on existing directory /data/postgres ... ok
postgres_container | creating subdirectories ... ok
postgres_container | selecting dynamic shared memory implementation ... posix
postgres_container | selecting default max_connections ... 100
postgres_container | selecting default shared_buffers ... 128MB
postgres_container | selecting default time zone ... Etc/UTC
postgres_container | creating configuration files ... ok
postgres_container | running bootstrap script ... ok
postgres_container | performing post-bootstrap initialization ... ok
postgres_container | syncing data to disk ... ok
postgres_container |
postgres_container |
postgres_container | Success. You can now start the database server using:
postgres_container |
postgres_container | pg_ctl -D /data/postgres -l logfile start
postgres_container |
postgres_container | initdb: warning: enabling "trust" authentication for local connections
postgres_container | You can change this by editing pg_hba.conf or using the option -A, or
postgres_container | --auth-local and --auth-host, the next time you run initdb.
postgres_container | waiting for server to start....2020-04-17 13:18:31.599 UTC [47] LOG: starting PostgreSQL 12.2 (Debian 12.2-2.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
postgres_container | 2020-04-17 13:18:31.607 UTC [47] LOG: could not bind Unix address "/var/run/postgresql/.s.PGSQL.5432": Input/output error
postgres_container | 2020-04-17 13:18:31.607 UTC [47] HINT: Is another postmaster already running on port 5432? If not, remove socket file "/var/run/postgresql/.s.PGSQL.5432" and retry.
postgres_container | 2020-04-17 13:18:31.607 UTC [47] WARNING: could not create Unix-domain socket in directory "/var/run/postgresql"
postgres_container | 2020-04-17 13:18:31.607 UTC [47] FATAL: could not create any Unix-domain sockets
postgres_container | 2020-04-17 13:18:31.610 UTC [47] LOG: database system is shut down
postgres_container | stopped waiting
postgres_container | pg_ctl: could not start server
postgres_container | Examine the log output.
postgres_container |
postgres_container | PostgreSQL Database directory appears to contain a database; Skipping initialization
postgres_container |
postgres_container | 2020-04-17 13:18:32.246 UTC [1] LOG: starting PostgreSQL 12.2 (Debian 12.2-2.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
postgres_container | 2020-04-17 13:18:32.246 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
postgres_container | 2020-04-17 13:18:32.246 UTC [1] LOG: listening on IPv6 address "::", port 5432
postgres_container | 2020-04-17 13:18:32.255 UTC [1] LOG: could not bind Unix address "/var/run/postgresql/.s.PGSQL.5432": Input/output error
postgres_container | 2020-04-17 13:18:32.255 UTC [1] HINT: Is another postmaster already running on port 5432? If not, remove socket file "/var/run/postgresql/.s.PGSQL.5432" and retry.
postgres_container | 2020-04-17 13:18:32.255 UTC [1] WARNING: could not create Unix-domain socket in directory "/var/run/postgresql"
postgres_container | 2020-04-17 13:18:32.255 UTC [1] FATAL: could not create any Unix-domain sockets
postgres_container | 2020-04-17 13:18:32.259 UTC [1] LOG: database system is shut down
postgres_container exited with code 1
I checked 5432 port its open and no process is using it.
when i remove volume from my docker-compose.yml file it works
perfectly
the volume i am using ./postgres-data is the local directory on my system i want to map it to the PostgreSQL container to restore database.
You are using docker on Windows and mounting the directory where the socket will be created (/var) as volume but windows filesystem doesn't support unix sockets.
Change the configuration in order to:
leave the unix socket (/var/run/postgresql/...) inside the docker without mounting as volume
mount data directory as volume

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.

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

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

Node Postgres Docker

I try to set up Docker with my node.js app which uses sequelize to connect to postgres.
const sequelize = new Sequelize(
process.env.DB_NAME,
process.env.DB_USER,
process.env.DB_PASS,
{
host: process.env.DB_HOST,
port: process.env.DB_PORT,
dialect: 'postgres',
},
);
In my .env file I declare
DB_HOST=postgres (which is the name of the service declared in the docker-conpose.yml) and DB_PORT=5432 among all the other environment variables.
My Dockerfile looks as follows:
FROM node:8.6.0
# Working directory for application
WORKDIR /usr/src/app
EXPOSE 8080
COPY . /usr/src/app
# In this file I create a user and a DB and give him the privlages
ADD init.sql /docker-entrypoint-initdb.d/
RUN npm install
And my docker-compose.yml looks as follows:
version: "2"
services:
postgres:
image: "postgres:9.4"
restart: always
ports:
- "5432:5432"
env_file:
- .env
node:
build: .
ports:
- "8080:8080"
depends_on:
- postgres
command: ["npm", "start"]
When I docker-compose up I get the error that the Sequelize is not able to connect to the DB.
Unhandled rejection SequelizeConnectionRefusedError: connect ECONNREFUSED 172.18.0.2:5431
Can someone help me with this error?
all the docker logs:
WARNING: Image for service node was built because it did not already exist. To rebuild this image you must use docker-compose build or docker-compose up --build.
Creating graphqlpostgrestemplate_postgres_1 ...
Creating graphqlpostgrestemplate_postgres_1 ... done
Creating graphqlpostgrestemplate_node_1 ...
Creating graphqlpostgrestemplate_node_1 ... done
Attaching to graphqlpostgrestemplate_postgres_1, graphqlpostgrestemplate_node_1
postgres_1 | The files belonging to this database system will be owned by user "postgres".
postgres_1 | This user must also own the server process.
postgres_1 |
postgres_1 | The database cluster will be initialized with locale "en_US.utf8".
postgres_1 | The default database encoding has accordingly been set to "UTF8".
postgres_1 | The default text search configuration will be set to "english".
postgres_1 |
postgres_1 | Data page checksums are disabled.
postgres_1 |
postgres_1 | fixing permissions on existing directory /var/lib/postgresql/data ... ok
postgres_1 | creating subdirectories ... ok
postgres_1 | selecting default max_connections ... 100
postgres_1 | selecting default shared_buffers ... 128MB
postgres_1 | selecting dynamic shared memory implementation ... posix
postgres_1 | creating configuration files ... ok
postgres_1 | creating template1 database in /var/lib/postgresql/data/base/1 ... ok
postgres_1 | initializing pg_authid ... ok
postgres_1 | initializing dependencies ... ok
postgres_1 | creating system views ... ok
node_1 | npm info it worked if it ends with ok
node_1 | npm info using npm#5.3.0
node_1 | npm info using node#v8.6.0
postgres_1 | loading system objects' descriptions ... ok
node_1 | npm info lifecycle graphql-postgres-template#1.0.0~prestart: graphql-postgres-template#1.0.0
node_1 | npm info lifecycle graphql-postgres-template#1.0.0~start: graphql-postgres-template#1.0.0
node_1 |
node_1 | > graphql-postgres-template#1.0.0 start /usr/src/app
node_1 | > nodemon --exec babel-node index.js
node_1 |
postgres_1 | creating collations ... ok
postgres_1 | creating conversions ... ok
postgres_1 | creating dictionaries ... ok
postgres_1 | setting privileges on built-in objects ... ok
postgres_1 | creating information schema ... ok
postgres_1 | loading PL/pgSQL server-side language ... ok
node_1 | [nodemon] 1.12.1
node_1 | [nodemon] to restart at any time, enter rs
node_1 | [nodemon] watching: .
node_1 | [nodemon] starting babel-node index.js
postgres_1 | vacuuming database template1 ... ok
postgres_1 | copying template1 to template0 ... ok
postgres_1 | copying template1 to postgres ... ok
postgres_1 | syncing data to disk ... ok
postgres_1 |
postgres_1 | Success. You can now start the database server using:
postgres_1 |
postgres_1 | postgres -D /var/lib/postgresql/data
postgres_1 | or
postgres_1 | pg_ctl -D /var/lib/postgresql/data -l logfile start
postgres_1 |
postgres_1 |
postgres_1 | WARNING: enabling "trust" authentication for local connections
postgres_1 | You can change this by editing pg_hba.conf or using the option -A, or
postgres_1 | --auth-local and --auth-host, the next time you run initdb.
postgres_1 | ****************************************************
postgres_1 | WARNING: No password has been set for the database.
postgres_1 | This will allow anyone with access to the
postgres_1 | Postgres port to access your database. In
postgres_1 | Docker's default configuration, this is
postgres_1 | effectively any other container on the same
postgres_1 | system.
postgres_1 |
postgres_1 | Use "-e POSTGRES_PASSWORD=password" to set
postgres_1 | it in "docker run".
postgres_1 | ****************************************************
postgres_1 | waiting for server to start....LOG: could not bind IPv6 socket: Cannot assign requested address
postgres_1 | HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
postgres_1 | LOG: database system was shut down at 2017-10-10 12:17:15 UTC
postgres_1 | LOG: MultiXact member wraparound protections are now enabled
postgres_1 | LOG: database system is ready to accept connections
postgres_1 | LOG: autovacuum launcher started
postgres_1 | done
postgres_1 | server started
postgres_1 | ALTER ROLE
postgres_1 |
postgres_1 |
postgres_1 | /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
postgres_1 |
postgres_1 | waiting for server to shut down....LOG: received fast shutdown request
postgres_1 | LOG: aborting any active transactions
postgres_1 | LOG: autovacuum launcher shutting down
postgres_1 | LOG: shutting down
postgres_1 | LOG: database system is shut down
node_1 | Tue, 10 Oct 2017 12:17:16 GMT sequelize deprecated String based operators are now deprecated. Please use Symbol based operators for better security, read more at http://docs.sequelizejs.com/manual/tutorial/querying.html#operators at node_modules/sequelize/lib/sequelize.js:236:13
node_1 | WARNING: No configurations found in configuration directory:/usr/src/app/config
node_1 | WARNING: To disable this warning set SUPPRESS_NO_CONFIG_WARNING in the environment.
node_1 | Tue, 10 Oct 2017 12:17:17 GMT body-parser deprecated undefined extended: provide extended option at index.js:53:30
node_1 | Unhandled rejection SequelizeConnectionRefusedError: connect ECONNREFUSED 172.18.0.2:5431
node_1 | at connection.connect.err (/usr/src/app/node_modules/sequelize/lib/dialects/postgres/connection-manager.js:96:24)
node_1 | at Connection.connectingErrorHandler (/usr/src/app/node_modules/pg/lib/client.js:123:14)
node_1 | at emitOne (events.js:115:13)
node_1 | at Connection.emit (events.js:210:7)
node_1 | at Socket. (/usr/src/app/node_modules/pg/lib/connection.js:71:10)
node_1 | at emitOne (events.js:115:13)
node_1 | at Socket.emit (events.js:210:7)
node_1 | at emitErrorNT (internal/streams/destroy.js:64:8)
node_1 | at _combinedTickCallback (internal/process/next_tick.js:138:11)
node_1 | at process._tickDomainCallback (internal/process/next_tick.js:218:9)
node_1 | [nodemon] clean exit - waiting for changes before restart
postgres_1 | done
postgres_1 | server stopped
postgres_1 |
postgres_1 | PostgreSQL init process complete; ready for start up.
postgres_1 |
postgres_1 | LOG: database system was shut down at 2017-10-10 12:17:16 UTC
postgres_1 | LOG: MultiXact member wraparound protections are now enabled
postgres_1 | LOG: database system is ready to accept connections
postgres_1 | LOG: autovacuum launcher started
To your Docker-compose add link configuration option in your service node point to service postgres something like this:
node:
links:
- postgres
Then you can connect to postgresdb point with name service postgres

Resources