I am working on moodle docker. Because I had to upgrade moodle version, that is why I had to install a new version of php- from php7 to php8. That is why I had to replace alpine image to php:8.2-fpm-alpine.
One part of the code is:
FROM php:8.2-fpm-alpine AS ts
RUN apk add --update-cache \
git \
&& rm -rf /var/cache/apk/*
ARG github_access
#some github pulling
FROM php:8.2-fpm-alpine
# based on https://docs.moodle.org/400/de/PHP - there are a few missing and some of them can not be installed
RUN apk add --update-cache \
php\
nginx \
php-fpm \
#php7-iconv \
php-mbstring \
php-curl \
php-openssl \
php-tokenizer \
#some more codes
COPY --from=ts <some source> <some destination>
#some more codes like this
COPY config-default.php /usr/share/nginx/html/
COPY nginx /etc/nginx
COPY php /etc/php7
EXPOSE 80
EXPOSE 443
STOPSIGNAL SIGTERM
CMD /usr/local/bin/start-server
Once I build it, in console I can see that this line runs forever:
=> [internal] load metadata for docker.io/library/php:8.2-fpm-alpine 53.2s
I found that it is from this line:
FROM php:8.2-fpm-alpine AS ts
I tested with alpine:3.15, alpine:latest, etc. and had the same issue.
No, just trying docker pull php:8.2-fpm-alpine directly works… The error must be some contradiction between the 2 images that are being called in the same dockerfile as I mentioned. Unfortuantely, using the same image there also leads to the same issue.
It is likely that @bluepuma77’s first post is the answer. I got the notification about the Docker Hub issue, but I didn’t need to pull images the last two days.
About
if that’s what you didn’t understand, buildkit is the curent default builder in Docker. Since buildkit has a different method to build images than the previous builder had, sometimes we try to disable t see if that makes a difference as long as we can, because sometime in the future we won’t be able to disable it.
@rimelek@bluepuma77 , thank you for your texts. And I apologize for the late response. So, after 3 days, what I tried first is to run the dockerfile once again.
Surpisingly, this line:
=> [internal] load metadata for docker.io/library/php:8.2-fpm-alpine
ran (which was taking forever to run 3 days ago.
But, still it is taking forever to build, with no trace on which line:
[+] Building 14.4s (82/82) FINISHED
....
⠿ Container moodle-deployment-moodle-1 Starting
@bluepuma77 I checked the link your shared. I am not sure if my issue is also related to that, as I am not getting any error msgs or anything, I cannot say for sure.
Not surprising at all if you it was caused by the issue mentioned by @bluepuma77
Building was finished. The problem i starting the container which is a different issue. What is related to the build and sarting the container is the CMD instruction. This is not a good idea usually:
CMD /usr/local/bin/start-server
Use this way:
CMD ["/usr/local/bin/start-server"]
Otherwise Docker when Docker sends the stop signal to the container it will be ignored and the container will be forced to stop by a KILL signal after 10 seconds. Fixing this will not make the container start though.
and tried it out. Unfortunately the issue is there. In docker desktop also I am seeing that the container is created, yet not running. The Logs is empty though, so I cannot see any possible error. I wonder if there is any other way to check the error.
@rimelek, I tried with a previous version of Dockerfile which used to work before. Now it is not working, so I have all reasons to believe that its due to what @bluepuma77 stated. However, how will I be sure, as the Dockerfile or Docker compose does not specify if its ipv4 or ipv6?
Well, as I wrote it before, that was not expected to fix your issue at all.
The fact that you are using Docker Desktop is something that you should have mentioned in your first post. I actually suspected it because these kind of issues are more common in Docker Desktop than Docker CE. If Docker Hub has issues that affects all Docker hosts but when you already have the image I don’t think I ever saw not starting containers on Linux using Docker CE.
Sorry, I probably lost track of the topic. How ipv4 and ipv6 is related to your current issue. Or are you saying when you shared that docker build worked it was because you changed the Dockerfile but the original file doesn’t work? But the hub issue was fixed.
About the relevance of the Docker Hub issue:
The issue with the IPv6 and “Docker in Docker” might not have been related to your case directly, but who knows what it required to investigate and fix the original issue. Maybe it caused other issues in the meantime. When something is worong with Docker Hub there could be side effects not discovered by the Docker staff.
On the other hand it could be important to know that the Docker daemon is running in a container inside Docker Desktop’s virtual machine. Which means the ipv6 issue could have been related to Docker in Docker and other Docker in container scenarios like Docker Desktop. I can’t confirm it, that is just an idea.
