Docker-compose: Error connecting to the Mongo database

Questions and Answers Database-MongoDB
1

This has thrown for a loop but I’m sure it’s something very simple that I’m misunderstanding. I’m putting together a docker development environment for a blog site. It consist of three components: strapi, API service which pulls data from a third party, and a mongodb database.

I followed along with the tutorial on the docker-compose section of the docs and used the docker-compose.yml from this blog: How to run a Strapi dev stack using Docker compose

Although, I’m hitting a snag. If attempt to compose my containers using the compose file below, Strapi fails to connect to my mongo instances.

version: '3'
services:
  # fitbit-stats-graph-service: 
  #   build: ./api
  #   ports:
  #   - "3000:3000"
  #   links:
  #   - mongo # link this service to the database service
  #   volumes:
  #   - .:/usr/src/app
  #   depends_on:
  #   - mongo
  mongo_db: 
    image: mongo
    container_name: mongo_db
    ports:
      - '27016:27017'
    environment:
      MONGO_INITDB_ROOT_USERNAME: strapi
      MONGO_INITDB_ROOT_PASSWORD: strapi
    networks:
      - strapi-app-network
    volumes:
      - strapidata:/data/db
  strapi: 
    image: strapi/strapi
    depends_on: mongo_db
    restart: unless-stopped
    environment:
      DATABASE_CLIENT: mongo
      DATABASE_NAME: strapi
      DATABASE_HOST: mongo_db
      DATABASE_PORT: 27016
      DATABASE_USERNAME: strapi
      DATABASE_PASSWORD: strapi
    networks:
      - strapi-app-network
    volumes:
      - ./app:/srv/app
    ports:
      - '1337:1337'
    depends_on:
      - mongo_db

networks:
  strapi-app-network:
    driver: bridge

volumes: 
  strapidata:

I commented out my service since I thought maybe it had a play into it.

mongodb spins up but if Strapi tries to connect to it, I get connection refusals

strapi_1    | [2020-10-05T21:12:53.266Z] debug ⛔️ Server wasn't able to start properly.
strapi_1    | [2020-10-05T21:12:53.268Z] error Error connecting to the Mongo database. connect ECONNREFUSED 172.19.0.2:27016

I’ve tried a couple of things: I thought maybe that mongo isn’t up and running by the time Strapi starts is loading and added a depends_on property to the yaml. I also played around different host names thinking the issue was related to the use of the ip address in Strapi but that didn’t lead to anything fruitful.

I’m using a Debian operating system

Is this enough information that you need?

2

Can you please use code blocks?

3

Caught me in the middle of my edit :smiley:

1 Like
4

So, I went back to the docker-compose example from the blog post and basically followed the steps again using the example compose file in a brand new directory.

When I spun up the containers, the process walks through each step and was successful. So I’m wondering if the setup I have from my project is incorrect in one of the other properties.

5

I’ll do some testing locally and see if I can find the error in your file.

Just as a general question though, are you planning to containerize Mongo in production?
If yes, I would strongly advise against that.

6

What would be the issue with containerizing Mongo in production? What would be a better approach instead?

7

https://eng.uber.com/dockerizing-mysql/

Quote from that Uber article:

All of this means that you should really only use Docker if you’re willing to invest quite a lot of resources in it. Furthermore, Docker should be treated as a piece of technology, not a solution to end all problems. At Uber we did a careful design which had Docker as one of the components in a much bigger system to manage MySQL databases. However, not all companies are at the same scale as Uber, and for them a more straightforward setup with something like Puppet or Ansible might be more appropriate.

Most of the reasons involve crashing/instability and management/scaling properly. Resources also becomes a concern especially with the added latency of docker itself, Red Hat’s Podman has solved a lot of the network latency issues but you are still injecting another level of virtualization and the added latency.

Most databases are designed to be extremely latency sensitive (both network and Disk/Memory I/O) and where possible Dedicated hardware with a private LAN (Don’t expose your database to the public internet, looking at you Atlas).

The goal of containers is to provide a stable and repeatable environment to run a scalable application (typically dynamically) and you would not be dynamically scaling your Database cluster.