Docker port has unwanted port declaration - docker

I am using Docker latest version, here is the output of "docker version"
docker version
Client:
Cloud integration: 1.0.14
Version: 20.10.6
API version: 1.41
Go version: go1.16.3
Git commit: 370c289
Built: Fri Apr 9 22:46:57 2021
OS/Arch: darwin/amd64
Context: default
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 20.10.6
API version: 1.41 (minimum version 1.12)
Go version: go1.13.15
Git commit: 8728dd2
Built: Fri Apr 9 22:44:56 2021
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.4.4
GitCommit: 05f951a3781f4f2c1911b05e61c160e9c30eaa8e
runc:
Version: 1.0.0-rc93
GitCommit: 12644e614e25b05da6fd08a38ffa0cfe1903fdec
docker-init:
Version: 0.19.0
GitCommit: de40ad0
I run a simple python flask images as followed https://docs.docker.com/language/python/build-images/
docker run --publish 5000:5000 python-docker-test
My container has up and run without any problem. The problem is I observed an addition port declaration as below
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8e8188fe2db3 python-docker-test "python3 -m flask ru…" 4 seconds ago Up 3 seconds 0.0.0.0:5000->5000/tcp, :::5000->5000/tcp test_docker_python-docker-test_1
Or more specifically:
PORTS
0.0.0.0:5000->5000/tcp, :::5000->5000/tcp
Output of docker port command
~$ docker port test_docker_python-docker-test_1 5000
0.0.0.0:5000
:::5000
Question is: Why do we have such :::5000 or generally :::<port_num>? Can we avoid this ?
Problem that I have is my bash script that fetch the output docker port need to be modified a bit. It's not a big deal. I just curious if there are some update in Docker 20.10.3.
Thanks
Alex

0.0.0.0 is the wildcard address in IPv4.
:: is the wildcard address of IPv6.
Docker does it so that it can receive requests from both IPv4 and IPv6 network interfaces.
To only bind port in the IPv4 interface, you have to specify the network interface explicitly.
docker run --publish 0.0.0.0:5000:5000 python-docker-test
Docker doc about networking

Related

Why can I start a process in a container that ''docker ps'' says has exited?

I have a docker container on AWS EC2 instance :
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b78279ed9e51 gnumeric "sleep infinity" 2 months ago Exited (137) 4 weeks ago gnumeric
$ docker exec gnumeric ps -ef
UID PID PPID C STIME TTY TIME CMD
1000 1 0 0 Jan15 ? 00:00:00 sleep infinity
1000 4861 0 0 21:31 ? 00:00:00 ps -ef
$ uname -a
Linux ip-10-0-2-199.ec2.internal 5.10.149-133.644.amzn2.x86_64 #1 SMP Tue Oct 18 16:52:42 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
$ docker version
Client:
Version: 20.10.17
API version: 1.41
Go version: go1.18.6
Git commit: 100c701
Built: Wed Sep 28 23:10:17 2022
OS/Arch: linux/amd64
Context: default
Experimental: true
Server:
Engine:
Version: 20.10.17
API version: 1.41 (minimum version 1.12)
Go version: go1.18.6
Git commit: a89b842
Built: Wed Sep 28 23:10:55 2022
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.6
GitCommit: 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
runc:
Version: 1.1.3
GitCommit: 1e7bb5b773162b57333d57f612fd72e3f8612d94
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Why can I run commands on a container with Exited status ?
Update
$ docker version # Windows
Client:
Cloud integration: v1.0.29
Version: 20.10.22
API version: 1.41
Go version: go1.18.9
Git commit: 3a2c30b
Built: Thu Dec 15 22:36:18 2022
OS/Arch: windows/amd64
Context: default
Experimental: true
Server: Docker Desktop 4.16.1 (95567)
Engine:
Version: 20.10.22
API version: 1.41 (minimum version 1.12)
Go version: go1.18.9
Git commit: 42c8b31
Built: Thu Dec 15 22:26:14 2022
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.14
GitCommit: 9ba4b250366a5ddde94bb7c9d1def331423aa323
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d
docker-init:
Version: 0.19.0
GitCommit: de40ad0

A specific hostname (smtp.office365.com) can't be resolved in a docker user-defined bridge network

With some docker image with nslookup (for example I'm going to use tutum/dnsutils), if I try this command:
docker run -it --rm tutum/dnsutils nslookup smtp.office365.com
it returns:
Server: 172.25.32.1
Address: 172.25.32.1#53
Non-authoritative answer:
smtp.office365.com canonical name = outlook.office365.com.
outlook.office365.com canonical name = outlook.ha.office365.com.
outlook.ha.office365.com canonical name = outlook.ms-acdc.office.com.
outlook.ms-acdc.office.com canonical name = ITM-efz.ms-acdc.office.com.
Name: ITM-efz.ms-acdc.office.com
Address: 40.99.9.18
...
Then, I create a network by running docker network create testnet and try this command:
docker run -it --rm --net testnet tutum/dnsutils nslookup smtp.office365.com
it returns:
Server: 127.0.0.11
Address: 127.0.0.11#53
Non-authoritative answer:
*** Can't find smtp.office365.com: No answer
Why is there such a difference?
If I try these commands with the host outlook.office365.com, both successfully return the resolved ip address.
I'm using docker in WSL with these versions:
$docker version
Client: Docker Engine - Community
Version: 20.10.21
API version: 1.41
Go version: go1.18.7
Git commit: baeda1f
Built: Tue Oct 25 18:01:58 2022
OS/Arch: linux/amd64
Context: default
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 20.10.21
API version: 1.41 (minimum version 1.12)
Go version: go1.18.7
Git commit: 3056208
Built: Tue Oct 25 17:59:49 2022
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.12
GitCommit: a05d175400b1145e5e6a735a6710579d181e7fb0
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d
docker-init:
Version: 0.19.0
GitCommit: de40ad0
This is the default behavior of bridge networks:
By default, traffic from containers connected to the default bridge
network is not forwarded to the outside world.
Please refer to the official doc here to enable forwarding.

docker-compose spec says cpus option is deprecated but docker run says use --cpus

Reading docker-compose spec (https://github.com/compose-spec/compose-spec/blob/master/spec.md#cpus) it says that cpus option is DEPRECATED, so even if it still works when I use it, I think it is not a great idea.
cpus
DEPRECATED: use deploy.reservations.cpus
cpus define the number of (potentially virtual) CPUs to allocate to service containers. This is a fractional number. 0.000 means no limit.
On the other hand, docker run docs says (https://docs.docker.com/config/containers/resource_constraints/#configure-the-default-cfs-scheduler) that --cpus option is more convenient.
Specify the CPU CFS scheduler period, which is used alongside --cpu-quota. Defaults to 100000 microseconds (100 milliseconds). Most users do not change this from the default. For most use-cases, --cpus is a more convenient alternative.
So I'm very confused: should or shouldn't i use cpus in docker-compose? if don't, how do I efficiently control a service cpu usage?
I'm using docker without swarm.
Context
$ docker version
Client:
Version: 20.10.2
API version: 1.41
Go version: go1.13.8
Git commit: 20.10.2-0ubuntu1~20.04.2
Built: Tue Mar 30 21:24:57 2021
OS/Arch: linux/amd64
Context: default
Experimental: true
Server:
Engine:
Version: 20.10.2
API version: 1.41 (minimum version 1.12)
Go version: go1.13.8
Git commit: 20.10.2-0ubuntu1~20.04.2
Built: Mon Mar 29 19:10:09 2021
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.3.3-0ubuntu2.3
GitCommit:
runc:
Version: spec: 1.0.2-dev
GitCommit:
docker-init:
Version: 0.19.0
GitCommit:
$ docker-compose version
docker-compose version 1.29.2, build 5becea4c
docker-py version: 5.0.0
CPython version: 3.7.10
OpenSSL version: OpenSSL 1.1.0l 10 Sep 2019
you should use deploy.reservations.cpus as the warning suggests, example:
https://github.com/compose-spec/compose-spec/blob/master/deploy.md#cpus
services:
frontend:
image: awesome/webapp
deploy:
resources:
limits:
cpus: '0.50'
memory: 50M
reservations:
cpus: '0.25'
memory: 20M
so what it means is cpus should be under reservations, under deploy.

Error response from daemon: experimental session with v1 builder is no longer supported, use builder version v2 (BuildKit) instead

I try to build a simple docker file and I get the error.
Error response from daemon: experimental session with v1 builder is no longer supported, use builder version v2 (BuildKit) instead
What's wrong?
The build command I use is as follows.
docker build -f .\DockerFile -t helloworld:dev .
The docker file is very simple and looks as follows.
FROM buildpack-deps:curl AS download-env
RUN wget https://raw.githubusercontent.com/mongodb/docs-assets/primer-dataset/primer-dataset.json
The docker version command gives the following output.
Client: Docker Engine - Community
Cloud integration 0.1.18
Version: 19.03.13
API version: 1.40
Go version: go1.13.15
Git commit: 4484c46d9d
Built: Wed Sep 16 17:00:27 2020
OS/Arch: windows/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 20.10.0-beta1
API version: 1.41 (minimum version 1.12)
Go version: go1.13.15
Git commit: 9c15e82
Built: Tue Oct 13 18:14:39 2020
OS/Arch: linux/amd64
Experimental: true
containerd:
Version: 1.4.1
GitCommit: c623d1b36f09f8ef6536a057bd658b3aa8632828
runc:
Version: 1.0.0-rc92
GitCommit: ff819c7e9184c13b7c2607fe6c30ae19403a7aff
docker-init:
Version: 0.19.0
GitCommit: de40ad0
And the /etc/docker/daemon.json file is as follows
{
"hosts": [
"unix://",
"tcp://0.0.0.0:2375"
],
"experimental": true,
"debug": true,
"metrics-addr": "0.0.0.0:9323"
}
Looks like this is an issue with the Docker Community Edition (i.e. Docker for Desktop). Here's the commit that fixes it: https://github.com/docker/docker-ce/commit/95971a49f97defa51b166211fbd6d44080540a62
In the mean time, you can do one of the following:
Downgrade your Docker CE server version (to 19.x.y, I believe), or
upgrade your Docker CLI version (to 20.x.y, I believe), or
run Docker commands with DOCKER_BUILDKIT=1, or
add the following to your /etc/docker/daemon.json file:
"features": { "buildkit": true }
Once a patch is released, you can upgrade your Docker CE server version and run Docker as before.
I was using this test script as instructed here.
Then I replaced the test script with the get script here.
Now the engine version is 19.03.13 instead of 20.10.0-beta1.
D:\Trials\Devops\Vagrant\vagrant_ubuntu_docker_multiple>docker version
Client: Docker Engine - Community
Cloud integration 0.1.18
Version: 19.03.13
API version: 1.40
Go version: go1.13.15
Git commit: 4484c46d9d
Built: Wed Sep 16 17:00:27 2020
OS/Arch: windows/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 19.03.13
API version: 1.40 (minimum version 1.12)
Go version: go1.13.15
Git commit: 4484c46d9d
Built: Wed Sep 16 17:01:06 2020
OS/Arch: linux/amd64
Experimental: true
containerd:
Version: 1.3.7
GitCommit: 8fba4e9a7d01810a393d5d25a3621dc101981175
runc:
Version: 1.0.0-rc10
GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dd
docker-init:
Version: 0.18.0
GitCommit: fec3683

dockerd with userland-proxy set to false

Configured docker daemon with --iptables=true and --userland-proxy=false.
With that no more docker-proxy processes.
But, containers on the host can't talk with each other through the host IP and forwarded port on host.
This seems to be expected. But is there anyway to enable container to container communication through host forwarded ports (without getting into iptables modification each and everytime a new container is brought up).
[root#AppServer ~]# docker version
Client:
Version: 18.03.1-ol
API version: 1.37
Go version: go1.9.4
Git commit: 0d51d18
Built: Wed Aug 22 21:59:42 2018
OS/Arch: linux/amd64
Experimental: false
Orchestrator: swarm
Server:
Engine:
Version: 18.03.1-ol
API version: 1.37 (minimum version 1.12)
Go version: go1.9.4
Git commit: 0d51d18
Built: Wed Aug 22 22:03:05 2018
OS/Arch: linux/amd64
Experimental: false
[root#AppServer ~]#

Resources