dockerode | Docker + Node = Dockerode (Nodejs module for Docker's Remote API) | Continuous Deployment library

Just use Array.prototype.filter

The docker API will only return locally running containers when using the GET /containers/json endpoint, so a 404 is expected when trying to return a container on another docker engine. Swarm managers are only able to return swarm objects for the whole cluster. Regular containers are not swarm objects.

When interacting with swarm mode, you can list swarm services and swarm tasks. GET /services and GET /tasks. Since tasks are indeed a swarm mode object, you can list all tasks for the whole swarm from any manager.

Tasks do then go on to create containers on the various nodes in the swarm. If you want to list containers across the whole swarm, you must use the GET /containers/json API endpoint directly on each node.

These API endpoints are analogous to the following commands:

• GET /containers/json - docker container ls
• GET /services - docker service ls
• GET /tasks?filter=... - docker service ps ... (see documentation for the correct filtering syntax)

I have answered this in the context of the Docker API instead of in the context of any one docker API library for increased readability.

Docker will not notice if you try to make manual changes to your container's network configuration. You can docker rm your container and docker run it again to bring things back into a consistent state.

By way of analogy, you might try logging into your home WiFi router. It might say your laptop is 192.168.1.2 and your printer is 192.168.1.3. You can certainly run ifconfig to change your laptop's IP address to 192.168.1.3/24, or to 10.20.30.40/16; but if you do your router won't have any idea this is going on, IP routing won't work correctly if you try to call out (or if you've set up a reverse NAT rule to allow inbound calls back in), and you can get strange network conflicts if you try to print.

Docker completely manages containers' network interfaces. There's no reason to run ifconfig or ip in a container. The container-private IP address is really an implementation detail, and it's unusable in many common circumstances; I would also avoid looking this up. You similarly shouldn't need to manually set it, but if you do, the "create a container" Docker API (basically directly exposed by dockerode) lets you specify the NetworkingConfig.

Mocha uses the debug package. In turn, debug uses the DEBUG environment variable.

To enable debug statements in Mocha, we typically use DEBUG=mocha*. Setting DEBUG=* would cause any module using debug to output debug info.

It's likely you (or some program) has set DEBUG=* or has enabled debug statements via code, e.g.,:

The problem is that your directory is not mapped.

This options object is the equivalent of the options --rm -v $PWD:/app -w /app

Fixed it by doing this instead of stream.pipe(process.stdout)

For docker.run(), The [ process.stdout, process.stderr ] streams are where the underlying stdio data is piped to.

Change these arguments to writable streams you control. You can use something like a memory stream, a file or implement a stream yourself.