fix(docker): handle TLS, improve ddev utility dockercheck, fixes #8111#8115
Merged
Conversation
stasadev
changed the title
ddev utility dockercheck, fixes #8111ddev utility dockercheck, fixes #8111
|
Download the artifacts for this pull request:
See Testing a PR.
|
4 tasks
rfay
approved these changes
Feb 9, 2026
rfay
left a comment
rfay
left a comment
Member
There was a problem hiding this comment.
The code looks good and my manual testing using a docker-ce on Linux configured for TLS worked fine.
The only question I had, despite being completely successful:
The client certs live in ~/.docker/tls right? But that's the docker client's territory, not the docker API, which we're using. Do we need DOCKER_CERT_PATH=$HOME/.docker/tls ? (It doesn't seem so, but ...)
Member
Author
We use |
## The Issue Docker client initialization in docker_manager.go wasn't reading TLS environment variables (DOCKER_TLS_VERIFY, DOCKER_CERT_PATH, DOCKER_TLS), causing "Client sent an HTTP request to an HTTPS server" errors when connecting to Docker daemons that require TLS. ## How This PR Solves The Issue **docker_manager.go:** - Added InstallFlags() call to populate ClientOptions from environment variables - Added SetDefaultOptions() to validate TLS certificate file paths - Uses pflag.NewFlagSet() to enable environment variable parsing - Continues using client.New(client.FromEnv) for API client creation **utility-dockercheck improvements:** - Downloads docker-compose before version check to ensure it's available - Displays TLS configuration status (enabled/disabled, cert paths) - Skips buildx checks on Podman (buildx is Docker-specific) - Skips buildx build test on Podman (uses native podman build) - Updated test to handle both Docker and Podman environments ## Manual Testing Instructions 1. Verify TLS environment variables are now respected (on standard Docker setup): ```bash # Should work (TLS without verification) DOCKER_TLS=1 ddev version # Should fail with certificate error, confirming env vars are respected DOCKER_TLS_VERIFY=1 ddev version # Expected error: "unable to resolve docker endpoint: open /home/user/.docker/ca.pem: no such file or directory" ``` 2. Test with TLS-enabled Docker daemon (if available): ```bash export DOCKER_TLS_VERIFY=1 export DOCKER_CERT_PATH=/path/to/certs ddev version ``` 3. Test dockercheck command displays TLS config: ```bash ddev utility dockercheck ``` Verify TLS configuration status is shown 4. Test on Podman (if available): ```bash ddev utility dockercheck ``` Verify buildx checks are skipped with appropriate messages ## Automated Testing Overview - Updated TestUtilityDockercheckCmd to verify TLS configuration output - Added conditional buildx check that only runs on Docker (not Podman) - Test uses dockerutil.IsPodman() for platform-aware assertions ## Release/Deployment Notes This fix enables DDEV to work with Docker daemons that require TLS connections. No breaking changes. Improves Podman compatibility in dockercheck diagnostic tool. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
stasadev
force-pushed
the
20260206_stasadev_docker
branch
from
d0c0bbe to
007cbed
Compare
Member
Author
|
I reverted the changes for Podman: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Issue
Docker client initialization in docker_manager.go wasn't reading TLS environment variables (
DOCKER_TLS_VERIFY,DOCKER_CERT_PATH,DOCKER_TLS), causing "Client sent an HTTP request to an HTTPS server" errors when connecting to Docker daemons that require TLS.How This PR Solves The Issue
docker_manager.go:
Uses the same technique as in https://github.com/docker/cli/blob/727bc3ea5b2cccf0d1ef77d7049848851e973477/cmd/docker-trust/trust/commands.go#L34-L44 to handle TLS
utility-dockercheck improvements:
Manual Testing Instructions
Verify TLS environment variables are now respected (on standard local Docker setup):
Test dockercheck command displays TLS config:
Using https://gitlab.com/consensus.enterprises/misc/ddev-in-ci
This will install
gitlab-ci-local, and run all of the jobs in the.gitlab-ci-yml.Copy
ddevbinary from this PR (see a comment with artifacts below) to the current directory and create aDockerfile:Run:
docker build -t ddev-test . --no-cacheThen edit https://gitlab.com/consensus.enterprises/misc/ddev-in-ci/-/blob/main/.gitlab-ci.yml, add:
And run:
From the output, it works:
Automated Testing Overview
Release/Deployment Notes
This fix enables DDEV to work with Docker daemons that require TLS connections. No breaking changes.