Docker build with rockylinux:9 failed, not able to resolve host name to mirrors site

General Discussions
,
1

Hello All:

I am trying to build a docker container image with rockylinux-9 without success. I can always build a docker container with rockylinux:8.9 without any problem, using the same Dockerfile.

My Dockerfile contains:

FROM rockylinux:8.9
RUN yum install -y epel-release openssl
WORKDIR /usr/jc
ENTRYPOINT [“/usr/jc/my-entrypoint.sh”]
CMD [“/bin/bash”]

My build script is:

#!/bin/bash
BUILD_DATE=01-20-24
docker build -f Dockerfile -t jc/rocky:$BUILD_DATE .
docker save jc/rocky:$BUILD_DATE --output jc-rocky-docker-$BUILD_DATE.tar
gzip jc-rocky-docker-$BUILD_DATE.tar

The script works fine with rockylinux:8.9 and produces the image gzip file. But after changing 8.9 to 9.3 (or 9.2, or 9 for that matter) in the Dockerfile, it always fails during the “docker build” processing, with errors during the BaseOS step:

Sending build context to Docker daemon 1.108 GB
Step 1/5 : FROM rockylinux:9.3
—> eeea865f4111
Step 2/5 : RUN yum install -y epel-release openssl
—> Running in 48e238283494

Rocky Linux 9 - BaseOS 0.0 B/s | 0 B 00:00
Errors during downloading metadata for repository ‘baseos’:

It seems the new rockylinux:9 could not resolve the URL. However, if I run the curl command on my host:

curl -X GET “copy URL in the error message here”

I can get the full mirror list.

I tried adding “RUN cat /etc/hosts && cat /etc/resolv.conf” to Dockerfile, and compared the contents between 8.9 and 9.3, they are exactly the same. The resolv.conf contains only one nameserver entry whish is 8.8.8.8 (supposedly google). Even if I purposely added a nameserver entry using my host’s resolv.conf, it did not help and I got the same errors:

RUN echo nameserver x.x.x.x (my host’s entry value) >> /etc/resolv.conf && yum install -y epel-release openssl

My host system is CentOS 7.7:

CentOS Linux release 7.7.1908 (Core)
Derived from Red Hat Enterprise Linux 7.7 (Source)
NAME=“CentOS Linux”
VERSION=“7 (Core)”
ID=“centos”
ID_LIKE=“rhel fedora”
VERSION_ID=“7”
PRETTY_NAME=“CentOS Linux 7 (Core)”
ANSI_COLOR=“0;31”
CPE_NAME=“cpe:/o:centos:centos:7”
…

My docker version:
Docker version 1.13.1, build 7d71120/1.13.1

I tried search on this site, and also googled but did not come up with any specific helpful info. Please help me with any pointers or insights.

Thanks in advance.

JC

2

Sounds like a good debugging approach.

Where is /usr/jc/my-entrypoint.sh coming from?

3

Hi bluepuma77:

Thanks for looking into the problem.

I trimmed down my real Dockerfile to a minimum to show the error. In the actual Dockerfile it contains lots of other commands to put necessary files into place. Such as

RUN mkdir /usr/jc
ADD my-entrypoint.sh /usr/jc

The my-entrypoint.sh also does lots of processing to set up software packages such as kafka inside container…

I omitted them because the error was happening on the RUN yum install command.

JC

4

It’s funny, you are the second person today that is installing a load of tools into a single fat container.

Containers are about isolation, you should run Kafka in a separate container to decouple systems. To easier upgrade individual components.

Anyway, this works for me on Debian:

# Dockerfile
FROM rockylinux:8.9
RUN yum install -y epel-release openssl

root@server1:/tmp# docker build -f Dockerfile .
...
Successfully built c467225861bc
5

Hi bluetpuma77:

Point taken - yes I planned to move Kafka and other “heavy” ones off my container in the near future.

Yes, rockylinux:.8.9 also works for me. If I change 8.9 to 9.3 (9.2 or 9), it fails with the error. My host is running CentOs 7.7. I plan to find a machine running with a higher version of CentOs or RH to see what will happen.

Regards,
JC

6

Works for me on Debian.

# Dockerfile
FROM rockylinux:9.3
RUN yum install -y epel-release openssl

root@server1:/tmp# docker build -f Dockerfile .
...
Successfully built 5f827e900233

It’s time to upgrade anyway :wink:

CentOS Linux 7 will reach end of life (EOL) on June 30, 2024

7

I guess I will have to. Thanks

8

Just an update: run the same on a RedHat 9.2 host. No error. So the problem seems to be caused by outdated CentOS 7.