compose-cli
compose-cli copied to clipboard
Not getting Device Code Prompt for Docker ACI
Description
I am going through the process of configuring Docker ACI on a Fedora 35 server via SSH to move some of my docker-compose deployments to Azure but still manage the compose files from my Linux machine. I was able to get the Cloud Integration installed & confirmed that under docker version but when I attempt to login with docker login azure
. The prompt will continue to hang forever
I've carefully read the documentation on Docker Docs & If the Docker CLI cannot open a browser, it should fall back to the Azure Device Code Flow & allow me to authenticate from another browser but I do not seem to getting that prompt
However I can login without issue using az login --use-device-code
using the Azure CLI
Steps to reproduce the issue:
- Install Latest Release via Manual Install as documented on Docker Docs
- Run
docker login azure
as sudo user
Describe the results you received:
After running docker login azure
, the prompt will hang there until the command is exited.
Describe the results you expected:
For after x amount of time, it would fall back to Device Code Authentication or similar Azure CLI having a switch to force device code authentication
Output of docker-compose --version
:
docker-compose version 1.29.2, build unknown
Output of docker version
:
Client: Docker Engine - Community
Cloud integration: v1.0.29
Version: 20.10.17
API version: 1.41
Go version: go1.17.11
Git commit: 100c701
Built: Mon Jun 6 23:04:23 2022
OS/Arch: linux/amd64
Context: default
Experimental: true
Server: Docker Engine - Community
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:02:06 2022
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.7
GitCommit: 0197261a30bf81f1ee8e6a4dd2dea0ef95d67ccb
runc:
Version: 1.1.3
GitCommit: v1.1.3-0-g6724737
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Output of docker context show
:
You can also run docker context inspect context-name
to give us more details but don't forget to remove sensitive content.
default
Output of docker info
:
Client:
Context: default
Debug Mode: false
Plugins:
app: Docker App (Docker Inc., v0.9.1-beta3)
buildx: Docker Buildx (Docker Inc., v0.8.2-docker)
compose: Docker Compose (Docker Inc., v2.6.0)
scan: Docker Scan (Docker Inc., v0.17.0)
Server:
Containers: 2
Running: 2
Paused: 0
Stopped: 0
Images: 2
Server Version: 20.10.17
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 0197261a30bf81f1ee8e6a4dd2dea0ef95d67ccb
runc version: v1.1.3-0-g6724737
init version: de40ad0
Security Options:
seccomp
Profile: default
cgroupns
Kernel Version: 5.18.16-100.fc35.x86_64
Operating System: Fedora Linux 35 (Server Edition)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.44GiB
Name: mas-sp-dh01
ID: 662I:4LKD:TE7B:6DL5:BUEU:PX6W:TXND:JIML:IEGE:AIXA:3SVV:45HC
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Additional environment details (AWS ECS, Azure ACI, local, etc.): Currently deploying to Azure ACI & Local Docker Host is running Fedora 35 Azure S2S VPN Between Local Network & Azure VNET
I was able to do some further testing on this, I had spun up an Azure Spot instance running Ubuntu 20.04 & this seems to detect it is a server & falls back to the web browser without issue when running docker login azure
. I am not as well versed to understand where this could causing an issue. Possibly someone could shed a bit more light with this or as a workaround adding a switch to force Device Code Auth.
Output of docker version
:
Client: Docker Engine - Community
Cloud integration: v1.0.29
Version: 20.10.17
API version: 1.41
Go version: go1.17.11
Git commit: 100c701
Built: Mon Jun 6 23:02:57 2022
OS/Arch: linux/amd64
Context: default
Experimental: true
Server: Docker Engine - Community
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:03 2022
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.7
GitCommit: 0197261a30bf81f1ee8e6a4dd2dea0ef95d67ccb
runc:
Version: 1.1.3
GitCommit: v1.1.3-0-g6724737
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Output of docker info
:
Client:
Context: default
Debug Mode: false
Plugins:
app: Docker App (Docker Inc., v0.9.1-beta3)
buildx: Docker Buildx (Docker Inc., v0.8.2-docker)
compose: Docker Compose (Docker Inc., v2.6.0)
scan: Docker Scan (Docker Inc., v0.17.0)
Server:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 0
Server Version: 20.10.17
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: false
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 0197261a30bf81f1ee8e6a4dd2dea0ef95d67ccb
runc version: v1.1.3-0-g6724737
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 5.15.0-1017-azure
Operating System: Ubuntu 20.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 7.765GiB
Name: mas-az-dockerdev
ID: Q2ZH:JM5R:MES3:TGT7:AKBX:7IG5:TUJV:QEUF:J6L3:JBRI:EXKR:MX2L
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed because it had not recent activity during the stale period.