My initial build attempt fails with temporary DNS failure

I don’t know much about docker so expect some uninformed questions. I have Ubuntu 24.04 LTS running Docker Desktop, The Docker Desktop I downloaded from Install Docker Desktop on Linux | Docker Docs. Docker version

$ docker --version
Docker version 29.6.0, build fb59821

I went through the various walk through examples for the Welcome container. That all seemed to go well. So, I asked AI what I would need in order to build a container that runs an Apache web server with a PHP app that communicates with a MySQL database. I want to be able to use Xdebug from VSCode on my local host and be able to administer MySQL from PHPMyAdmin. It suggested the Dockerfile and docker-compose.yml files below.

When I run

$ docker compose up --build -d

The build fails. It complains that for pecl is has a temporary DNS failure

10.02 Updating channel "pecl.php.net"
25.04 Channel "pecl.php.net" is not responding over https://, failed with message: Connection to `ssl://pecl.php.net:443' failed: php_network_getaddresses: getaddrinfo for pecl.php.net failed: Temporary failure in name resolution
25.04 Trying channel "pecl.php.net" over http:// instead
35.05 Cannot retrieve channel.xml for channel "pecl.php.net" (Connection to `pecl.php.net:80' failed: php_network_getaddresses: getaddrinfo for pecl.php.net failed: Temporary failure in name resolution)

From the Ubuntu host an nslookup works just fine:

$ nslookup pecl.php.net
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
pecl.php.net	canonical name = pecl-internal-php-net.b-cdn.net.
Name:	pecl-internal-php-net.b-cdn.net
Address: 212.102.40.120

AI recommended trying

docker run --rm alpine ping -c 3 8.8.8.8

That gives me 100% packet loss.

AI had me try these fixes.
Configure /etc/docker/daemon.json

{
  "bip": "192.168.250.1/24",
  "dns": ["8.8.8.8", "1.1.1.1"]
}

I verified that net.ipv4.ip_forward=1 is on.
AI had me use network: host in docker-compose.yml

But the build environment remained completely sandboxed.

After hours of going back and forth with AI, AI finally said to essentially copy down all the pieces I need and then configure the build to use the local pieces and not use the automatic download.

But, my objective isn’t to get a working container. It’s to learn how to use the system to create containers automatically. So, I have bailed on AI and I need to ask a real person

The files below are just kind of left over after hours of recommendations to try this and that,including moving /etc/resolv.conf from the stub file and setting POSTROUTE flags in IP. I think I undid all that stuff as none of it gained me anything. AI really seemed to be just shooting in the dark and it was getting circular. I don’t know enough to defend any of the settings in the Dockerfie and docker-compose.yml. I am not sure which ones were part of the original suggestion and what ones AI had me add or change when trying to debug the DNS issue.

I would appreciate any pointers on how I can get an automated build to work on my Ubuntu host

Thanks Chris

Dockerfile:

FROM php:8.2-apache

# Install required PHP extensions for MySQL and Xdebug
RUN docker-php-ext-install pdo pdo_mysql mysqli \
    && pecl channel-update pecl.php.net \
    && pecl install xdebug \
    && install-php-extensions xdebug

# Configure Xdebug 3
RUN echo "xdebug.mode=debug" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini \
    && echo "xdebug.start_with_request=yes" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini \
    && echo "xdebug.client_host=host.docker.internal" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini \
    && echo "xdebug.client_port=9003" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini \
    && echo "xdebug.log=/tmp/xdebug.log" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini

docker-compose.yml:

# Newer docker will select the version.
# Setting it is redundant and can cause confusion
# version: '3.8'

services:
  # Apache + PHP Service
  web:
    build:
      context: .
      network: host
    ports:
      - "8080:80"
    volumes:
      - ./src:/var/www/html
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      - XDEBUG_CONFIG=client_host=host.docker.internal

  # MySQL Database Service
  db:
    image: mysql:8.0
    restart: always
    ports:
      - "3306:3306"
    environment:
      MYSQL_ROOT_PASSWORD: rootpassword
      MYSQL_DATABASE: my_database
    volumes:
      - db_data:/var/lib/mysql

  # phpMyAdmin Service
  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    restart: always
    ports:
      - "8081:80"
    environment:
      PMA_HOST: db
      PMA_USER: root
      PMA_PASSWORD: rootpassword

volumes:
  db_data:

I discovered Gordon. It went through and repeatedly asked permission to change the Dockerfile. In the end it concluded:

Ubuntu 24.04 with systemd-resolved. By removing the xdebug pecl dependency, the build completes. Your services are running on ports 8080 (web), 3306 (MySQL), and 8081 (phpMyAdmin). To re-enable xdebug later, use a precompiled PHP image with xdebug included, or install it via apt if available in the base image.

So, it seemed to fix something Ubuntu 24.04 specific regarding systemd-resolv. It then decided Xdebug was a problem and just bailed on it. But after Gordon made a couple of dozen edits I was able to remove all images and containers and then run the build from the command line myself using

$ DOCKER_BUILDKIT=0 docker compose up --build -d

I am not sure what the DOCKER_BUILDKIT=0 is about. But I have something to work with.
I still need to learn a little bit more about how to get Xdebug in place, but I can sort through that.

So, I consider my situation resolved. But realize I am still climbing the learrning curve.

Thanks

Nothing that you shared as recommended by AI seems to be actualyl related to DNS resolution which was your original issue. Stub resolver should not matter either, but on servers I often disable that indeed, but not on a desktop.

Side note: Since you are on Linux, unless you need Docker Desktop features, Docker CE is often easier to use. Docker Desktop adds features for development, but also more complexity.

When you have DNs resolution issue only in containers, or as you dicovered even network error, it is usually caused by how your LAN network is colliding with Docker networks or the network of Docker Desktop’s virtual machine or sometimes caused by IPV6 enabled in Docker and not on the host. Proxies or VPNs can also cause problems, but if everything works now, it would be hard to tell what actually caused the problem. MTU setting is another potential cause of network issues.

I don’t think changing the Dockerfile could solve anything, but if you used compose and created enough Docker networks left on the system (also not sure why it would happen), you could get a new IP from an IP range which is not colliding with anything in your environment. But that is just a guess.

I disabled buildkit for long when it was new, but I would not do it in 2026. Building images without buildkit is the legacy way and I don’t see any reason to do it today. But once it was often a solution when something didn’t work.

If you don’t use buildkit some Dockerfile features will not work and the build could also be slower sometimes. I’m surprised it can be still disabled :slight_smile:

Thanks for the insight. I noticed that the docker-compose.yml that Gordon left me with had:

web:
    build:
      context: .
      args:
        DOCKER_BUILDKIT: 1
    dns:
      - 8.8.8.8
      - 8.8.4.4

Yet Gordon said to set DOCKER_BUILDKIT=0 on the command line. I assume that would over ride the file.

I asked Gordon to clear all containers and images so I could do a fresh build. Gordon cleared it all out and I ran a build without setting DOCKER_BUILDKIT=0 as Gordon had recommended

$ docker compose up --build -d
<bunch o stuff>
✔ Image phpmyadmin/phpmyadmin  Pulled                                                                             10.5s
 ✔ Image mysql:8.0              Pulled                                                                              9.3s
 ✔ Image test1-web              Built                                                                              15.9s
 ✔ Network test1_default        Created                                                                             0.0s
 ✔ Volume test1_db_data         Created                                                                             0.0s
 ✔ Container test1-phpmyadmin-1 Started                                                                             0.3s
 ✔ Container test1-web-1        Started                                                                             0.3s
 ✔ Container test1-db-1         Started   

So, it seems to build without requiring the DOCKER_BUILDKIT=0

My original concern was to be able to build a container that could run. I have accomplished that. So, I consider this resolved.

Interestingly enough the ping test still fails:

$ docker run --rm alpine ping -c 3 8.8.8.8
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
55afa1ecc21d: Pull complete 
56dceff11b33: Download complete 
f5124fb579e2: Download complete 
Digest: sha256:28bd5fe8b56d1bd048e5babf5b10710ebe0bae67db86916198a6eec434943f8b
Status: Downloaded newer image for alpine:latest
PING 8.8.8.8 (8.8.8.8): 56 data bytes

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

So, I am not real sure all the networking issues have been resolved. Right now I am not concerned about that. I need to continue studying tutorials and experimenting so that I can understand what docker does and how it works. I will deal with the networking issue along the way.

I wasn’t aware that there was a CE version. I had installed the Docker tool that is in the Ubuntu repositories, but when I clicked on the icon it wouldn’t even start up. A search about Docker pointed to Docker Desktop, so I removed all the docker packages I had gotten from the Ubuntu repository and loaded docker desktop.

For now I’ll probably stick with Docker Desktop since I have gotten this far. It seems like Docker CE is a subset of Docker Desktop so I don’t think I am missing anything.

Again thanks for the comments. I learned a couple of things.

This is not normal. You probably have a collision between your lan (or a subnet reachable via a route) and the ip address of Docker Desktop’s utility vm’s subnet, like @rimelek mentioned in his post.

While the first is designed to run payload for 24/7, the other is a developer productivity tool, helping developers during development with a convenient ui. While the first runs the Docker Engine as a service on your host, the latter runs its Docker Engine inside a utility vm. The suggestion aimed to simplify the setup, and reduce the number of moving parts that could potentially be involved in the behaviour you experience.

A build argument is for setting a variable in build time inside the containers that are created for each RUN instruction so you cat do things based on variables without leaving that variable in the final container image and as a result, without that variable inside the container that you run from the image.

I don’t think DOCKER_BUILDKIT is valid in a build argument. It will not break anything, just doesn’t do anything either. If Gordon created a file like that, it looks like a mistake / AI hallucination. Just to be sure I asked it if it was valid and said no.

Were ylou able to ping it from outside containers on your host?

@meyay correctly interpreted my intention. In addition to that, be aware that some tutorials may not work since the whole network and volumes are in the already mentioned virtual machine. And some features require a physical machine or a virtual machne with nested virtualization support. As far as I know it is not supported in Docker Desktop, but it is not likely that you will miss it for a while. Just keep in mind what Docker CE and Docker Desktop were made for so when something doesnt work, you will have a guess why..

I understand that. I still had t share some thoughts and you can ignore until you are concerned again :slight_smile: Still other users can read it if they have similar issues.