dockhippie/mongodb

Docker images for mongodb

mongodb's Issues

The backup script fails when MONGODB_AUTH is not set

My config is the following:

services:
  mongo:
    image: webhippie/mongodb:latest
    restart: always
    volumes:
     - ./data/db:/var/lib/mongodb
     - ./data/backup:/var/lib/backup
    environment:
     - MONGODB_SMALLFILES=1
     - MONGODB_OPLOG_SIZE=128
     - MONGODB_REPL_SET=rs0
     - MONGODB_STORAGE_ENGINE=wiredTiger

After upgrading the container recently (I needed a more modern version of MongoDB) the backup script no longer works. The problem seems to be related to this line:

if [[ -n "${MONGODB_AUTH}" ]]; then

it checks if MONGODB_AUTH is empty, but when it's not configured, the default value is false, not empty:

root@c62257dc78d8:/var/lib/mongodb# source /usr/bin/entrypoint
root@c62257dc78d8:/var/lib/mongodb# echo $MONGODB_AUTH
false

This causes it to call mongodump with --authenticationDatabase admin, which seems to fail on newer versions (or so I assume, because I don't see any changes to the backup script in the git log):

root@c62257dc78d8:/var/lib/mongodb# mongodump --authenticationDatabase admin --db=$DATABASE --out /tmp
2022-06-22T08:12:33.111+0000	Failed: can't create session: could not connect to server: connection() error occurred during connection handshake: auth error: sasl conversation error: unable to authenticate using mechanism "SCRAM-SHA-1": (AuthenticationFailed) Authentication failed.
root@c62257dc78d8:/var/lib/mongodb# mongodump --db=$DATABASE --out /tmp
... works normally ...

Suprisingly, this doesn't seem to be an issue when calling mongo to list the databases:

root@c62257dc78d8:/var/lib/mongodb# mongo --authenticationDatabase admin --eval 'JSON.stringify(db.adminCommand( { listDatabases: 1, nameOnly: true } ))'
MongoDB shell version v5.0.9
connecting to: mongodb://127.0.0.1:27017/?authSource=admin&compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("11430c48-3ec8-4605-b40c-f71e4fde031d") }
MongoDB server version: 5.0.9
{"databases":[...],"ok":1,"$clusterTime":{"clusterTime":{"$timestamp":{"t":1655885769,"i":1}},"signature":{"hash":{"$binary":"AAAAAAAAAAAAAAAAAAAAAAAAAAA=","$type":"00"},"keyId":{"$numberLong":"0"}}},"operationTime":{"$timestamp":{"t":1655885769,"i":1}}}

MONGODB_AUTH=1 causes error while starting local service to create users

Hello!
I noticed this issue while setting up my mongodb server with your container: BadValue: --fork has to be used with --logpath or --syslog

I looked into your project and figured out it was caused by the creation of the users when the MONGODB_AUTH environment variable is set to 1. Maybe we could add an environment variable to set the log path? or whether to use syslog or not?
It could be useful to configure logs as well in addition to solve the issue.

I tried it on mongodb:5 and mongodb:4.4 and got the same error.

Thanks for your docker images, it really helped me as there were no other docker image for ARMv7 for MongoDB.

upgrade mongo to newer version, now I get 2.6.10

thanks

unrecognised option '--enableFreeMonitoring'

Hello,
I noticed the following error while running MongoDB : unrecognised option '--enableFreeMonitoring'. I checked on MongoDB 6.0, 5.0 and 4.0 with mongod --help and saw that the option was not in version 5 and 6 anymore.

As said here: https://www.mongodb.com/docs/v6.0/administration/free-monitoring/

Free monitoring is deprecated

Free monitoring will be deprecated in April 2023 and decommissioned in August 2023.

Beginning in April 2023, new users can’t enable free monitoring on MongoDB Community instances. Deployments currently using free monitoring can continue to access the free monitoring UI until August 2023.

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

dockerfile

latest/Dockerfile.amd64

latest/Dockerfile.arm64

v4.0/Dockerfile.amd64

• ghcr.io/dockhippie/ubuntu 16.04-amd64@sha256:6a49dac4aeea6b73490c7a8190cec438dca8e4f44355a74002578bf9e2632ed8

v4.0/Dockerfile.arm64

• ghcr.io/dockhippie/ubuntu 16.04-arm64@sha256:2cc3481aeb92d47e7ed9e1ca4cc7cdd7d8f8e0a3381d7e7caa05867a76519719

v4.2/Dockerfile.amd64

• ghcr.io/dockhippie/ubuntu 18.04-amd64@sha256:3c98462c376d2bf8ca3862baa72a8cf68cd936667175914ebd3df8cd03fc5dc6

v4.2/Dockerfile.arm64

• ghcr.io/dockhippie/ubuntu 18.04-arm64@sha256:d6834c4950581075726ff6ec70082fc85a9fdf3e284c6ff132f6f134c695461c

v4.4/Dockerfile.amd64

• ghcr.io/dockhippie/ubuntu 20.04-amd64@sha256:9fc941b8473c2f0f3713d690c1b76c6513925953099dc085d24f4c2e410fd184

v4.4/Dockerfile.arm64

• ghcr.io/dockhippie/ubuntu 20.04-arm64@sha256:73af716bb48f2a9c164a075f28ad4a6704bbe21e61adc37c732fa3a51ce1080e

v5.0/Dockerfile.amd64

• ghcr.io/dockhippie/ubuntu 20.04-amd64@sha256:9fc941b8473c2f0f3713d690c1b76c6513925953099dc085d24f4c2e410fd184

v5.0/Dockerfile.arm64

• ghcr.io/dockhippie/ubuntu 20.04-arm64@sha256:73af716bb48f2a9c164a075f28ad4a6704bbe21e61adc37c732fa3a51ce1080e

v6.0/Dockerfile.amd64

• ghcr.io/dockhippie/ubuntu 22.04-amd64@sha256:7a9783fd7953e88ecfcd59476dbb7b5a8cd8f7bed0c8d2568bb521658f58b780

v6.0/Dockerfile.arm64

• ghcr.io/dockhippie/ubuntu 22.04-arm64@sha256:73c0a703091b6cc39134723e78b09f2e13b0965b7a2aeee26e8eb05ab1c4b281

v7.0/Dockerfile.amd64

v7.0/Dockerfile.arm64

github-actions

.github/workflows/automerge.yml

• tibdex/github-app-token v2
• dependabot/fetch-metadata v2

.github/workflows/docker.yml

• actions/checkout v4
• docker/metadata-action v5
• docker/setup-qemu-action v3
• docker/setup-buildx-action v3
• docker/login-action v3
• docker/login-action v3
• docker/login-action v3
• docker/build-push-action v6
• docker/build-push-action v6
• actionhippie/manifest v1
• actionhippie/manifest v1
• actionhippie/manifest v1

.github/workflows/readme.yml

• actions/checkout v4
• actionhippie/pushrm v1
• actionhippie/pushrm v1

.github/workflows/v4.0.yml

• actions/checkout v4
• docker/metadata-action v5
• docker/setup-qemu-action v3
• docker/setup-buildx-action v3
• docker/login-action v3
• docker/login-action v3
• docker/login-action v3
• docker/build-push-action v6
• docker/build-push-action v6
• actionhippie/manifest v1
• actionhippie/manifest v1
• actionhippie/manifest v1

.github/workflows/v4.2.yml

• actions/checkout v4
• docker/metadata-action v5
• docker/setup-qemu-action v3
• docker/setup-buildx-action v3
• docker/login-action v3
• docker/login-action v3
• docker/login-action v3
• docker/build-push-action v6
• docker/build-push-action v6
• actionhippie/manifest v1
• actionhippie/manifest v1
• actionhippie/manifest v1

.github/workflows/v4.4.yml

• actions/checkout v4
• docker/metadata-action v5
• docker/setup-qemu-action v3
• docker/setup-buildx-action v3
• docker/login-action v3
• docker/login-action v3
• docker/login-action v3
• docker/build-push-action v6
• docker/build-push-action v6
• actionhippie/manifest v1
• actionhippie/manifest v1
• actionhippie/manifest v1

.github/workflows/v5.0.yml

• actions/checkout v4
• docker/metadata-action v5
• docker/setup-qemu-action v3
• docker/setup-buildx-action v3
• docker/login-action v3
• docker/login-action v3
• docker/login-action v3
• docker/build-push-action v6
• docker/build-push-action v6
• actionhippie/manifest v1
• actionhippie/manifest v1
• actionhippie/manifest v1

.github/workflows/v6.0.yml

• actions/checkout v4
• docker/metadata-action v5
• docker/setup-qemu-action v3
• docker/setup-buildx-action v3
• docker/login-action v3
• docker/login-action v3
• docker/login-action v3
• docker/build-push-action v6
• docker/build-push-action v6
• actionhippie/manifest v1
• actionhippie/manifest v1
• actionhippie/manifest v1

.github/workflows/v7.0.yml

• actions/checkout v4
• docker/metadata-action v5
• docker/setup-qemu-action v3
• docker/setup-buildx-action v3
• docker/login-action v3
• docker/login-action v3
• docker/login-action v3
• docker/build-push-action v6
• docker/build-push-action v6
• actionhippie/manifest v1
• actionhippie/manifest v1
• actionhippie/manifest v1

---

• Check this box to trigger a request for Renovate to run again on this repository

Init script not exists

I not found init script mechanism for create datatbases and collections after first start of db

The backup script fails on 6.0

$ docker run --rm webhippie/mongodb:6.0
$ docker exec container_name backup
/usr/bin/backup: line 27: mongo: command not found

This worked fine on 5.0.

Just replacing mongo with mongosh in the backup script seems to work (in the place where uses it to query list of databases, mongodump works normally). There are a bunch more occurrences in the healthcheck and container (for setting passwords) scripts, so I presume more things may be broken.

Action Required: Fix Renovate Configuration

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: Cannot find preset's package (github>webhippie/renovate:docker)

Connection error when creating/updating root user on container start up with --auth

Hello,
I encountered the following error while using the mongodb:5 image:

[...]

> update root user
Error: couldn't connect to server 127.0.0.1:27017, connection attempt failed: SocketException: Error connecting to 127.0.0.1:27017 :: caused by :: Connection refused :
connect@src/mongo/shell/mongo.js:372:17
@(connect):3:6
exception: connect failed
exiting with code 1

It seems to be only happening when the container is started with docker-compose. It works fine with a docker run. Here are my configs:

docker-compose.yaml
---
version: "3.8"

services:
  mongodb:
    container_name: mongodb
    image: ${IMAGE_MONGODB}
    env_file:
      - ./docker/mongodb.env
    restart: always
    networks:
      - mongodb_network
    volumes:
      - ${DATA_PATH}/mongodb/:/var/lib/mongodb/
    deploy:
      resources:
        limits:
          cpus: "0.80"
          memory: 32M

networks:
  mongodb_network:
    name: mongodb_network
    external: true

Note: mongodb_network is created with the following command:

$ docker network create \
	--attachable \
	--driver bridge \
	--internal \
	--gateway 172.28.4.1 \
	--subnet 172.28.4.0/24 \
	mongodb_network

I though the error was due to the --internal but it occurs with or without it.

Here is the content of the docker/mongodb.env file:

mongodb.env
---
MONGODB_AUTH=true
MONGODB_AUTH_DB=authentication
MONGODB_ROOT_USERNAME=root
MONGODB_ROOT_PASSWORD=root
MONGODB_USERNAME=test
MONGODB_PASSWORD=test
MONGODB_DATABASE=testdb
MONGODB_PERFORM_UPGRADE=true
MONGODB_PERFORM_REPAIR=true

And finally the command which works:

$ docker run \
    --detach \
    --volume $PWD/data/home-pouliquen/mongodb/:/var/lib/mongodb/ \
    --env-file docker/mongodb.env \
    --name mongodb \
    webhippie/mongodb:5

Th error occurs when the MONGODB_AUTH=true in the container script (l. 84-107).
I did not find anything to explain it, nor to correct it.
I hope you will be able to solve the issue with all these elements.

Thank you!

Unrecognized env variable

Hello, I attempted to run this container with a few of the specified environment variables:

        environment:
            - MONGODB_SSL_ALLOW_CONNECTIONS_WITHOUT_CERTIFICATES=true
            - MONGODB_SSL_ALLOW_INVALID_CERTIFICATES=true
            - MONGODB_SSL_ALLOW_INVALID_HOSTNAMES=true

It resulted in these errors:

> starting mongodb service

Error parsing command line: unrecognised option '--sslAllowConnectionsWithoutCertificates'

try 'mongod --help' for more information

If I comment out - MONGODB_SSL_ALLOW_CONNECTIONS_WITHOUT_CERTIFICATES=true then the container is able to start.

Are the environment variables correct?

Change Suggestion option to remove lock file

Hi Guys.

I'm not too experienced with container, but I'm working on that, so maybe this is not really an issue.

I have a suggestions, working on my pi cluster when you suddenly run into an issue that might cause you to just pull the plug, however that leave us with a corrupt .lock file within the container. So my suggestion is to fix this, by removing the .lock file using an ENV variable (if possible) when the container spins up.

I suggest an ENV.
REMOVE_LOCK_ON_STARTUP: true | false
This will use the MONGODB_DBPATH to find the lock file.
This will help to fix the lock issue in case of a power failure.

By the way, Really great job on this image, it's great for my raspberry pi cluster! :)