docker: Error response from daemon: Conflict. The container name "/mongodb" is already in use by container #24

akoskm · 2021-05-29T05:49:56Z

I'm trying to replace my old mongodb services setup with mongodb-github-action because it gives me an easy way to spin up a replica set.

Here's my old setup:


    services:
      mongodb:
        image: mongo:4.2
        ports:
          - 27017:27017

I removed this and put the supercharge action in my build steps:

name: Build
# This workflow is triggered on pushes to the repository.
on: [push]

jobs:
  build:
    runs-on: self-hosted
    container: 10log/10log-base
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          persist-credentials: false

      - name: Use Node.js
        uses: actions/setup-node@v1
        with:
          node-version: '14'

      - name: MongoDB in GitHub Actions
        uses: supercharge/[email protected]
        with:
          mongodb-version: '4.2'
          mongodb-replica-set: rs0


      - name: Install
        run: npm install

      - name: Bundle
        run: npm run build
        env:
          PAT_TOKEN: ${{ secrets.PAT_AKOSKM }}

      - name: Run unit tests
        env:
          MONGO_URI: mongodb://localhost:27017/test?replicaSet=rs0
        run: |
          ./version.sh
          npm run test-unit

      - name: Run client tests
        run: npm run test-client

      - name: Run integration tests
        env:
          MONGOLAB_URI: mongodb://mongodb/test?replicaSet=rs0
          MONGO_URI: mongodb://mongodb/test?replicaSet=rs0
        run: npm run test-integration

My problem is that the first test in the "Run unit tests" build step fails to connect to the mongodb instance:

(node:427) UnhandledPromiseRejectionWarning: MongoNetworkError: failed to connect to server [localhost:27017] on first connect [Error: connect ECONNREFUSED 127.0.0.1:27017
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1144:16) {
  name: 'MongoNetworkError'
}]

but I think this is caused by an uncaught error that happens much earlier, in MongoDB in GithHub Actions:

Starting as single-node replica set (in replica set [rs0])
docker: Error response from daemon: Conflict. The container name "/mongodb" is already in use by container "ba21c3f0db068d6a3978d2217b8c012a181c7c748ade61c4d3e56cc1dfaff392". You have to remove (or rename) that container to be able to reuse that name.

For reference, here's how the MongoDB in GithHub Actions command ends:

Initiating replica set [rs0]
MongoDB shell version v4.2.14
connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("f3bb2a76-c258-4466-b7e2-8dc67b73a12d") }
MongoDB server version: 4.2.14
{
	"operationTime" : Timestamp(1622264561, 1),
	"ok" : 0,
	"errmsg" : "already initialized",
	"code" : 23,
	"codeName" : "AlreadyInitialized",
	"$clusterTime" : {
		"clusterTime" : Timestamp(1622264561, 1),
		"signature" : {
			"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
			"keyId" : NumberLong(0)
		}
	}
}
Check! Initiated replica set [rs0]

The text was updated successfully, but these errors were encountered:

akoskm · 2021-05-29T07:16:27Z

I made the error from `MongoDB in GitHub Action disappear by cleaning up the docker images on my actions runner machine:

Starting as single-node replica set (in replica set [rs0])
Unable to find image 'mongo:4.2' locally
4.2: Pulling from library/mongo

I'm still getting the same error from the tests.

akoskm · 2021-05-29T07:34:31Z

If I mess up the connection string, for example:

      - name: Run unit tests
        env:
          MONGO_URI: mongodb://mongodb/test?replicaSet=rs0
        run: |
          ./version.sh
          npm run test-unit

I get a different error:

(node:427) UnhandledPromiseRejectionWarning: MongoNetworkError: failed to connect to server [mongodb:27017] on first connect [Error: getaddrinfo ENOTFOUND mongodb
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:66:26) {
  name: 'MongoNetworkError'
}]

marcuspoehls · 2021-05-29T08:56:34Z

@akoskm Hey Akos, looks like you're connecting to MongoDB using a Node.js app. Is it the mongodb package or Mongoose or something else you're using?

Is your app using the provided MONGO_URI "as is" or do you replace/add some other values (Iike auth credentials)?

akoskm · 2021-05-29T09:14:15Z

Hey, thanks for the prompt response @marcuspoehls!

I'm using Mongoose to connect to MongoDB. MONGO_URI is used "as is".

This is how my setup was working with services:.

It's really similar to what you have in your test:

mongodb-github-action/test/replica-set.js

Lines 12 to 19 in 56f4c41

    
           before(async () => { 
        
             await Mongoose.connect('mongodb://localhost:27017/test', { 
        
               useNewUrlParser: true, 
        
               useUnifiedTopology: true, 
        
               replicaSet: replicaSetName, 
        
               serverSelectionTimeoutMS: 1500 
        
             }) 
        
           })

mine goes like this:

await mongoose.connect(MONGO_URI, { useNewUrlParser: true, useUnifiedTopology: true });

where MONGO_URI is coming from the workflow file.

marcuspoehls · 2021-05-29T10:43:29Z

Good you found the test using Mongoose. I remember running into issues with the database connection when using Mongoose and replica sets. You already copied the connection details from the test. That's good. Could you please test whether adding the replica set config to the Mongoose object helps? Maybe it gets overridden in the connection string. But I'm not sure.

akoskm · 2021-05-29T11:25:15Z

Tried this, actually, I wrapped my above connect code such as:

before(async function(){
    try {
      console.log(MONGO_URI);
      await mongoose.connect(MONGO_URI, {
        useNewUrlParser: true,
        useUnifiedTopology: true,
        serverSelectionTimeoutMS: 10000,
        replicaSet: 'rs0'
      });
      app.db = mongoose.connection;
      // please ignore these lines, I'm setting up some models like this because 5y ago it seemed like a good idea 😅
      require('../../schema/Finish')(app, mongoose);
      require('../../schema/Counter')(app, mongoose);
    } catch (err) {
      console.log(err)
    }
  });

and here's the error I'm getting:

MongooseServerSelectionError: connect ECONNREFUSED 127.0.0.1:42069
    at NativeConnection.Connection.openUri (/__w/10log-base/10log-base/node_modules/mongoose/lib/connection.js:800:32)
    at /__w/10log-base/10log-base/node_modules/mongoose/lib/index.js:342:10
    at /__w/10log-base/10log-base/node_modules/mongoose/lib/helpers/promiseOrCallback.js:31:5
    at new Promise (<anonymous>)
    at promiseOrCallback (/__w/10log-base/10log-base/node_modules/mongoose/lib/helpers/promiseOrCallback.js:30:10)
    at Mongoose.connect (/__w/10log-base/10log-base/node_modules/mongoose/lib/index.js:341:10)
    at Context.<anonymous> (/__w/10log-base/10log-base/test/unit/index.js:16:22)
    at callFn (/__w/10log-base/10log-base/node_modules/mocha/lib/runnable.js:358:21)
    at Hook.Runnable.run (/__w/10log-base/10log-base/node_modules/mocha/lib/runnable.js:346:5)
    at next (/__w/10log-base/10log-base/node_modules/mocha/lib/runner.js:454:10)
    at Immediate.<anonymous> (/__w/10log-base/10log-base/node_modules/mocha/lib/runner.js:516:5)
    at processImmediate (internal/timers.js:458:21) {
  reason: TopologyDescription {
    type: 'ReplicaSetNoPrimary',
    setName: null,
    maxSetVersion: null,
    maxElectionId: null,
    servers: Map(1) { 'localhost:42069' => [ServerDescription] },
    stale: false,
    compatible: true,
    compatibilityError: null,
    logicalSessionTimeoutMinutes: null,
    heartbeatFrequencyMS: 10000,
    localThresholdMS: 15,
    commonWireVersion: null
  }
}

marcuspoehls · 2021-05-29T12:08:48Z

@akoskm Looks like your connection string has the wrong port. Can you check whether the MONGO_URI is the one provided in your GitHub Action workflow? Because the error message says port 42069 and I guess you’re trying to connect on port 27017

akoskm · 2021-05-29T12:12:11Z

Oh sorry, in the meantime I updated my yaml config to experiment with different ports:

      - name: MongoDB in GitHub Actions
        uses: supercharge/[email protected]
        with:
          mongodb-version: '4.2'
          mongodb-replica-set: rs0
          mongodb-port: 42069

akoskm · 2021-05-30T05:35:20Z

I found in the input of this action the following:

Initiating replica set [rs0]
MongoDB shell version v4.2.14
connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("09535804-17aa-4146-b0d5-32f762bbc573") }

So I tried hardcoding the full URL I see here in my test (compressors cannot be disabled in Mongoose):

MONGO_URI = 'mongodb://127.0.0.1:42069/?compressors=snappy&gssapiServiceName=mongodb';

I got the following error:

MongooseServerSelectionError: connect ECONNREFUSED 127.0.0.1:42069
    at NativeConnection.Connection.openUri (/__w/10log-base/10log-base/node_modules/mongoose/lib/connection.js:800:32)
    at /__w/10log-base/10log-base/node_modules/mongoose/lib/index.js:342:10
    at /__w/10log-base/10log-base/node_modules/mongoose/lib/helpers/promiseOrCallback.js:31:5
    at new Promise (<anonymous>)
    at promiseOrCallback (/__w/10log-base/10log-base/node_modules/mongoose/lib/helpers/promiseOrCallback.js:30:10)
    at Mongoose.connect (/__w/10log-base/10log-base/node_modules/mongoose/lib/index.js:341:10)
    at Context.<anonymous> (/__w/10log-base/10log-base/test/unit/index.js:16:22)
    at callFn (/__w/10log-base/10log-base/node_modules/mocha/lib/runnable.js:358:21)
    at Hook.Runnable.run (/__w/10log-base/10log-base/node_modules/mocha/lib/runnable.js:346:5)
    at next (/__w/10log-base/10log-base/node_modules/mocha/lib/runner.js:454:10)
    at Immediate.<anonymous> (/__w/10log-base/10log-base/node_modules/mocha/lib/runner.js:516:5)
    at processImmediate (internal/timers.js:458:21) {
  reason: TopologyDescription {
    type: 'ReplicaSetNoPrimary',
    setName: null,
    maxSetVersion: null,
    maxElectionId: null,
    servers: Map(1) { '127.0.0.1:42069' => [ServerDescription] },
    stale: false,
    compatible: true,
    compatibilityError: null,
    logicalSessionTimeoutMinutes: null,
    heartbeatFrequencyMS: 10000,
    localThresholdMS: 15,
    commonWireVersion: null
  }
}

marcuspoehls · 2021-05-30T08:13:34Z

Looks like the connection attempt from the logs goes to the default port 27017. Even with a custom port configured.

Just to make sure: you're still using the Mongoose options for URL parser and topology? I remember those being required for replica sets. Mongoose wouldn't connect properly without these

Akos, do you work on a public project where I can look at the logs of the GitHub Action?

akoskm · 2021-05-31T04:42:11Z

I just sent you a link to the build log/yaml file in DM on Twitter.

Hopefully fixes supercharge#24.

eBsowka · 2021-07-16T09:19:48Z

Hello
Was the last issue resolved? What was the problem?
I am currently struggling with the same problem. I start the MongoDB in git actions I manage to restore database but then when I try to connect to that restored database with nextflow pipeline it gives me:
MongooseServerSelectionError: connect ECONNREFUSED 127.0.0.1:27017

akoskm · 2021-07-17T04:51:06Z

@eBsowka I'm still using the docker-network branch:

uses: supercharge/mongodb-github-action@docker-network

@marcuspoehls do you remember why this wasn't merged into master? Is it the issue with the network not being cleaned up?

marcuspoehls · 2021-07-18T06:03:22Z

@akoskm @eBsowka Yeah, I remember why I never merged the docker-network branch: the GitHub Actions runner does not properly clean up the network used to connect all containers.

There are two ways of networking when using docker actions on a self-hosted runners:

you run your tests directly on the runner
- you can connect to dependencies (like MongoDB) using localhost as the host address
you run your tests in another docker container
- the runner creates a dedicated Docker network for all containers configured in the action’s workflow file
- the runner then connects all containers to this dedicated network
- your test can then use localhost to connect to dependencies
- third-party actions (like this MongoDB container action) must also connect to the dedicated network
- yet, there’s no step to tell the runner to disconnect third-party container actions to disconnect from the network or clean themselfs up when tearing down

While writing this, I think there’s a solution we can build into this MongoDB action: an input that disconnects the container from the network ensuring that your self-hosted runner can clean up correctly (remove container, remove the network).

vladkasianenko · 2024-02-21T08:09:21Z

Any updates here?

marcuspoehls · 2024-02-21T08:49:05Z

@vladkasianenko Hey Vlad, I didn’t look into this issue over the last year. I have to get back digging and reading on container actions. Maybe GitHub changed or improved the way how they work. If you have any knowledge about solving this issue, please share it. I appreciate any progress, hint, and lead 🙂

Zig1375 · 2024-03-05T14:26:13Z

same issue, but I have it in my own server with gitea and act_runner...
My script cannot connect to mongo (from mongoose) and once I restart my action it stops because container exists...

hanyang1986 · 2024-07-29T08:48:52Z

  # Stop and remove all running Docker containers before the job
  - name: Stop and remove all running Docker containers
    run: |
      echo "Stopping all running Docker containers..."
      docker ps -q | xargs --no-run-if-empty docker stop
      echo "Removing all Docker containers..."
      docker ps -a -q | xargs --no-run-if-empty docker rm

laurogripa · 2024-10-04T12:34:36Z

Same issue here.

It works on CI/CD but fails locally when running with act.

Simple setup with single instance:

      - name: Start MongoDB
        uses: supercharge/[email protected]
        with:
          mongodb-version: ${{ matrix.mongodb-version }}

marcuspoehls · 2024-10-05T03:03:23Z

@laurogripa Hey Lauro, looks like CI/CD deletes the containers after processing the pipeline. Locally, act won’t clean up and keep the containers. When running the pipeline a second time, the containers already exist. The container recreation then fails with this issue.

One thing coming to my mind: a workaround here could be the explicit acceptance of such cases. For example, we’re extending this MongoDB GitHub Action to contact the Docker daemon and check if the container name that should be used is already present. If a container with the same name already exists, we could accept that and be done. This could be an opt-in setting that is helpful during local development.

Would you be interested in contributing this functionality?

erickmcarvalho · 2024-10-09T19:00:03Z

Hey @marcuspoehls

Is there a chance to merge the doker-network merge on some next release?

There is a concern when we use the container instruction because mongodb-github-action will be performed like a "docker in docker` approach, and the container network will not be attached.

Here is my idea:

tests:
  run-as: ubuntu-latest

  container:
    image: php:cli
    
  steps:
    uses: supercharge/[email protected]
    with:
        network: ${{ job.container.network }}

This way, we keep the network managed with the GitHub Actions while also ensuring the MongoDB container uses the same network as the workflow job.

Due this limitation, in my case, I needed to do the steps performing manually the docker commands, like:

run: docker exec ${{ env.container_name }} composer install

laurogripa · 2024-10-09T20:44:07Z

@laurogripa Hey Lauro, looks like CI/CD deletes the containers after processing the pipeline. Locally, act won’t clean up and keep the containers. When running the pipeline a second time, the containers already exist. The container recreation then fails with this issue.

One thing coming to my mind: a workaround here could be the explicit acceptance of such cases. For example, we’re extending this MongoDB GitHub Action to contact the Docker daemon and check if the container name that should be used is already present. If a container with the same name already exists, we could accept that and be done. This could be an opt-in setting that is helpful during local development.

Would you be interested in contributing this functionality?

@marcuspoehls thanks for your answer!

Oh, yeah, good catch. I thought about this, I was killing the container but forgetting to remove it 🤦

Of course, I'd love to contribute. How do you think this opt-in setting should look, something like MONGODB_REUSE_CONTAINER=$8 with false as default?

marcuspoehls self-assigned this May 29, 2021

akoskm added a commit to akoskm/mongodb-github-action that referenced this issue Jun 5, 2021

use the network created by the github-runner

320ce2d

Hopefully fixes supercharge#24.

akoskm mentioned this issue Jun 5, 2021

use the network created by the github-runner #25

Merged

marcuspoehls closed this as completed in #25 Jun 5, 2021

marcuspoehls reopened this Jun 7, 2021

This was referenced Apr 3, 2023

Automatically Update Talawa-Docs with the latest API Schema PalisadoesFoundation/talawa-api#1240

Closed

Generate image of GraphQL schema with each PR PalisadoesFoundation/talawa-api#1244

Closed

alexdlukens mentioned this issue Mar 12, 2024

Allow user-defined container name #58

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

docker: Error response from daemon: Conflict. The container name "/mongodb" is already in use by container #24

docker: Error response from daemon: Conflict. The container name "/mongodb" is already in use by container #24

akoskm commented May 29, 2021

akoskm commented May 29, 2021

akoskm commented May 29, 2021

marcuspoehls commented May 29, 2021

akoskm commented May 29, 2021 •

edited

Loading

marcuspoehls commented May 29, 2021

akoskm commented May 29, 2021

marcuspoehls commented May 29, 2021

akoskm commented May 29, 2021

akoskm commented May 30, 2021

marcuspoehls commented May 30, 2021

akoskm commented May 31, 2021

eBsowka commented Jul 16, 2021

akoskm commented Jul 17, 2021

marcuspoehls commented Jul 18, 2021

vladkasianenko commented Feb 21, 2024

marcuspoehls commented Feb 21, 2024

Zig1375 commented Mar 5, 2024 •

edited

Loading

hanyang1986 commented Jul 29, 2024

laurogripa commented Oct 4, 2024

marcuspoehls commented Oct 5, 2024

erickmcarvalho commented Oct 9, 2024

laurogripa commented Oct 9, 2024

docker: Error response from daemon: Conflict. The container name "/mongodb" is already in use by container #24

docker: Error response from daemon: Conflict. The container name "/mongodb" is already in use by container #24

Comments

akoskm commented May 29, 2021

akoskm commented May 29, 2021

akoskm commented May 29, 2021

marcuspoehls commented May 29, 2021

akoskm commented May 29, 2021 • edited Loading

marcuspoehls commented May 29, 2021

akoskm commented May 29, 2021

marcuspoehls commented May 29, 2021

akoskm commented May 29, 2021

akoskm commented May 30, 2021

marcuspoehls commented May 30, 2021

akoskm commented May 31, 2021

eBsowka commented Jul 16, 2021

akoskm commented Jul 17, 2021

marcuspoehls commented Jul 18, 2021

vladkasianenko commented Feb 21, 2024

marcuspoehls commented Feb 21, 2024

Zig1375 commented Mar 5, 2024 • edited Loading

hanyang1986 commented Jul 29, 2024

laurogripa commented Oct 4, 2024

marcuspoehls commented Oct 5, 2024

erickmcarvalho commented Oct 9, 2024

laurogripa commented Oct 9, 2024

akoskm commented May 29, 2021 •

edited

Loading

Zig1375 commented Mar 5, 2024 •

edited

Loading