I'm having issues using docker compose with private repositories.
Looking for similar issues i can't get --verbose to give any meaningful output, to help debugging the issue.
When i use docker compose to pull images from a private registry i receive the error:
"Error response from daemon: unauthorized: unauthorized to access
repository: myrepo/myservice, action: pull: unauthorized to access
repository: myrepo/myservice, action: pull"
I've made sure to run the docker login command, before running docker compose up.
If i run docker pull on the image described in the compose file, the image is downloaded as expected, but running docker compose up fails.
i'm using docker for windows.
docker compose version 2.13.
docker version:
PS C:\Users\kov\source\repos\localsetup> docker version
Client:
Cloud integration: v1.0.29
Version: 20.10.21
API version: 1.41
Go version: go1.18.7
Git commit: baeda1f
Built: Tue Oct 25 18:08:16 2022
OS/Arch: windows/amd64
Context: default
Experimental: true
Server: Docker Desktop 4.15.0 (93002)
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 18:00:19 2022
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.10
GitCommit: 770bd0108c32f3fb5c73ae1264f7e503fe7b2661
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d
docker-init:
Version: 0.19.0
GitCommit: de40ad0
my docker compose file:
services:
appRestApiEndpoint:
image: myregistry.io/repo/app-rest-api-endpoint
container_name: my-service
ports:
- 5000:80
networks:
- backend
environment:
- ASPNETCORE_ENVIRONMENT=myEnvVariable
networks:
backend:
I can provide you with the following solution / workaround, though I'm not sure if this is the "wanted" behavior of docker-compose or a bug; see the link I mentioned above.
Create the following config file
For Linux I know the file is: ~/.docker/config.json
For Windows it might be similar to C:\Users\<username>\.docker\config.json
Example for Docker Hub registry:
{
"auths": {
"https://index.docker.io/v1/": {
"auth": "<auth-string>"
}
}
}
<auth-string> is the base64-encoded string: <docker-loginname>:<auth-token>. The <auth-token> can be generated by logging into docker hub.
Example for Harbor docker registry:
{
"auths": {
"<harbor-url": {
"auth": "<auth-string>"
}
}
}
<auth-string> is base64(<loginname>:<password>)
Related
Basically, I need to have a service that knows about where it is (it's "external to the LAN" IP address) - but in addition, can still communicate to services within a docker network.
Which is giving me mixed results. My docker host (Mac, but linux ultimately will be what I use) has a LAN-facing IP in the 10.0.0.0/24 subnet - that's fine, it's report it's IP as being 192.168.65.4 .. which is the docker subnet... is there a way to ensure cross-platform, it can see it's full LAN IP? (i.e, 10.0.0.100), as well as being able to connect to other containers? (i.e, redis)..
The reason I need to do this, is that I have docker containers that communicate with devices, that need to reference this host's IP address. I thought about setting an environment variable, which I can do, but I'd want it to be entirely dynamic, I could put this docker-compose file anywhere, and it would still behave as expected. I've looked into the host.docker.internal environment variable solution, however I wasn't able to get that to function.
I tried doing this:
docker-compose.yml
version: "3.7"
services:
test_env:
build: test_env
container_name: "test_env"
network_mode: "host"
ports:
- "5000:5000"
environment:
- PYTHONUNBUFFERED=1
restart: on-failure
app.py (just a rando python script) - ultimately this will be a flask app
import flask
from flask import request, Response, Flask, render_template
import socket
hostname = socket.gethostname()
ip_address = socket.gethostbyname(hostname)
print(ip_address)
app = Flask(__name__)
#app.route('/index.html')
def index():
return ip_address
potato#xyz ~ % docker version
Client: Docker Engine - Community
Version: 20.10.17
API version: 1.41
Go version: go1.18.3
Git commit: 100c70180f
Built: Mon Jun 6 21:36:39 2022
OS/Arch: darwin/arm64
Context: default
Experimental: true
Server: Docker Desktop 4.11.1 (84025)
Engine:
Version: 20.10.17
API version: 1.41 (minimum version 1.12)
Go version: go1.17.11
Git commit: a89b842
Built: Mon Jun 6 23:01:01 2022
OS/Arch: linux/arm64
Experimental: false
containerd:
Version: 1.6.6
GitCommit: 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
runc:
Version: 1.1.2
GitCommit: v1.1.2-0-ga916309
docker-init:
Version: 0.19.0
GitCommit: de40ad0
potato#xyz ~ % sw_vers
ProductName: macOS
ProductVersion: 12.6
BuildVersion: 21G115
potato#xyz ~ %
I know it isn't the easiest answer, but thanks to all in advance.
when running docker compose version it show me the current version.
$ docker compose version
Docker Compose version v2.12.2
but when trying to use it
$ sudo docker compose up
docker: 'compose' is not a docker command.
See 'docker --help'
this is my docker version
$ sudo 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:02:21 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 18:00:04 2022
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.9
GitCommit: 1c90a442489720eec95342e1789ee8a5e1b9536f
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d
docker-init:
Version: 0.19.0
GitCommit: de40ad0
I expected $ sudo docker compose up
to run my .yml
You may need to run the command as a super user.
try this: sudo docker-compose up
There seems to be a discrepancy in the implementation between docker compose CLI command and docker-compose CLI. Although they follow the same specification for Compose.
Services
As a simple example, I have two compose files
docker-compose.hello-world.yml
version: '3.7'
services:
hello:
image: hello-world:nano-server
container_name: hello_world
docker-compose.base.yml
very simple base file
version: '3.7'
volumes:
dummy-vol:
I can override them using the -f flag as follows:
docker compose -f docker-compose.hello-world.yml -f docker-compose.base.yml config > docker-compose.yml
Discrepancy
If one uses the above command using the docker compose CLI in built in the Docker Engine:
docker compose -f docker-compose.hello-world.yml -f docker-compose.base.yml config
The resultant configuration generated is:
here test-con is just the name of the directory I have the files in
name: test-con
services:
hello:
container_name: hello_world
image: hello-world:nano-server
networks:
default: null
networks:
default:
name: test-con_default
However when using the docker-compose CLI,
docker-compose -f docker-compose.hello-world.yml -f docker-compose.base.yml config
generates the following output:
services:
hello:
container_name: hello_world
image: hello-world:nano-server
version: '3.7'
volumes:
test: {}
As you can see name key value is not generated with docker-compose.
Is there a way to suppress generating the name key-value from docker compose CLI?
System Specs
docker version
Client:
Version: 20.10.12
API version: 1.41
Go version: go1.17.5
Git commit: e91ed5707e
Built: Mon Dec 13 22:31:40 2021
OS/Arch: linux/amd64
Context: default
Experimental: true
Server:
Engine:
Version: 20.10.12
API version: 1.41 (minimum version 1.12)
Go version: go1.17.5
Git commit: 459d0dfbbb
Built: Mon Dec 13 22:30:43 2021
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v1.6.1
GitCommit: 10f428dac7cec44c864e1b830a4623af27a9fc70.m
runc:
Version: 1.1.0
GitCommit: v1.1.0-0-g067aaf85
docker-init:
Version: 0.19.0
GitCommit: de40ad0
docker compose version
Docker Compose version 2.3.3
docker-compose version
docker-compose version 1.29.2, build unknown
docker-py version: 5.0.3
CPython version: 3.10.2
OpenSSL version: OpenSSL 1.1.1m 14 Dec 2021
This discrepancy is resolved when upgraded to v2.4.1 for docker.
Upon conducting the same test:
docker-compose -f docker-compose.hello-world.yml config > std.yml
as well as
docker compose -f docker-compose.hello-world.yml config > cli.yml
and checking to see if there is any difference using diff
diff std.yml cli.yml
now provides the same configuration in both tools
name: test-com
services:
hello:
container_name: hello_world
image: hello-world:nano-server
networks:
default: null
networks:
default:
name: test-com_default
I have installed docker on my local machine using the following command
docker run -d --name some-rabbit -p 5672:5672 -p 5673:5673 -p 15672:15672 rabbitmq:3-management
I have no issues with the installation and I am able to access rabbitmq management console on my local machine using localhost and ip address
http://localhost:15672/ OR
http://192.168.1.111:15672/#/
Both of these URLs are working fine on the machine where RabbitMQ is installed.
Now, I want to access this management console from some other machine ( IP address 192.168.1.116) which is in the same network.
When I tried to access management console using IP (192.168.1.111) address I am getting following error:-
This site can't be reached. 192.168.1.111 took too long to respond. Try:
Checking the connection
Checking the proxy and the firewall
ERR_CONNECTION_TIMED_OUT
I have verified that machine is reachable and I was able to ping 192.168.1.111 (machine where RabbitMQ is installed through docker) from 192.168.1.116
Below are details of docker installation
C:\Users\heman>docker version
Client: Docker Engine - Community
Version: 19.03.12
API version: 1.40
Go version: go1.13.10
Git commit: 48a66213fe
Built: Mon Jun 22 15:43:18 2020
OS/Arch: windows/amd64
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 19.03.12
API version: 1.40 (minimum version 1.12)
Go version: go1.13.10
Git commit: 48a66213fe
Built: Mon Jun 22 15:49:27 2020
OS/Arch: linux/amd64
Experimental: true
containerd:
Version: v1.2.13
GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429
runc:
Version: 1.0.0-rc10
GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dd
docker-init:
Version: 0.18.0
GitCommit: fec3683
Kubernetes:
Version: v1.16.6-beta.0
StackAPI: v1alpha3
I have a single node docker swarm which has just been created with docker swarm init.
I have a docker-stack.yml which contains the following deployment:
version: '3.3'
services:
website:
image: docker.pkg.github.com/foo/bar/bar:latest
ports:
- "80:80"
- "443:443"
environment:
HOST: bar.com
secrets:
- site.key
- site.cert
networks:
- foo-net
networks:
foo-net:
driver: overlay
external: true
secrets:
site.key:
external: true
site.cert:
external: true
First, I login into the registry and it tells me that the login was successful.
Second, I deploy the stack
$ docker stack deploy --with-registry-auth --compose-file docker-stack.yml foo
Creating service foo_bar
After that, the service is running and everything works as expected.
However, when I try to deploy a stack with the same command a second time (a few seconds later), it fails with the following message.
$ docker stack deploy --with-registry-auth --compose-file docker-stack.yml foo
Updating service foo_website (id: uvtqpdx74784dy9egj5i1c7sb)
image docker.pkg.github.com/foo/bar/bar:latest could not be accessed on a registry to record
its digest. Each node will access docker.pkg.github.com/foo/bar/bar:latest independently,
possibly leading to different nodes running different
versions of the image
Why does this happen?
All networks and secrets are created beforehand and my docker version is:
$ docker version
Client:
Version: 19.03.6
API version: 1.40
Go version: go1.12.17
Git commit: 369ce74a3c
Built: Fri Feb 28 23:45:43 2020
OS/Arch: linux/amd64
Experimental: false
Server:
Engine:
Version: 19.03.6
API version: 1.40 (minimum version 1.12)
Go version: go1.12.17
Git commit: 369ce74a3c
Built: Wed Feb 19 01:06:16 2020
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.3.3-0ubuntu1~18.04.2
GitCommit:
runc:
Version: spec: 1.0.1-dev
GitCommit:
docker-init:
Version: 0.18.0
GitCommit:
I appreciate any help!
Thanks