When I create a simple Dockerfile:
FROM wordpress:4.9.4-php7.2-apache
COPY --chown=www-data:www-data "plugins/" "/usr/src/wordpress/wp-content/plugins/"
It runs just fine locally and everything is nice and dandy but pushing it to Heroku fails when apache is starting.
The container dies to fast to go in and have a look at which modules are actually loaded.
Any ideas? Does anyone knows which modules are actually needed or what can fails in the scripts here.
Note that before the error the message Complete! WordPress has been successfully copied to /var/www/html is printed which seems to indicate the actual wp setup is successful.
We had to switch to the buildpack, no time to sort this.
I was investigating this issue today with @fresswolf
What we found is that Heroku is doing something very strange with docker images that contain apache. It seems that before the container is started Heroku is injecting some files into the folde /etc/apache2/.
The "php" docker image is enabling the module "mpm_prefork", and thus creates the file /etc/apache2/mods-enabled/mpm_prefork.load. Heroku later injects its own set of configuration files which includes the file /etc/apache2/mods-enabled/mpm_event.load. We end up with 2 mpm modules loaded, which makes apache fail.
We opened a support ticket with Heroku about it.
Steps to reproduce:
/etc/apache2/ removed. When the container is started it will list the contents of `/etc/apache2/FROM debian:stretch-slim
RUN apt-get update && apt-get install -qy apache2
RUN rm -rf /etc/apache2
ENTRYPOINT []
CMD ["find", "/etc/apache2"]
$ docker build -t test .
$ docker run --rm test
/etc/apache2/mods-enabled/:
total 0
$ docker tag test registry.heroku.com/<app-name>/web
$ docker push registry.heroku.com/<app-name>/web
$ heroku container:release -a <app-name> web
$ heroku logs -ta <app-name>
2018-06-07T18:05:20.749367+00:00 heroku[web.1]: Starting process with command `find /etc/apache2`
2018-06-07T18:05:22.413759+00:00 app[web.1]: /etc/apache2
2018-06-07T18:05:22.413777+00:00 app[web.1]: /etc/apache2/conf-enabled
2018-06-07T18:05:22.413779+00:00 app[web.1]: /etc/apache2/conf-enabled/serve-cgi-bin.conf
2018-06-07T18:05:22.413780+00:00 app[web.1]: /etc/apache2/conf-enabled/localized-error-pages.conf
2018-06-07T18:05:22.413782+00:00 app[web.1]: /etc/apache2/conf-enabled/other-vhosts-access-log.conf
2018-06-07T18:05:22.413783+00:00 app[web.1]: /etc/apache2/conf-enabled/security.conf
2018-06-07T18:05:22.413784+00:00 app[web.1]: /etc/apache2/conf-enabled/charset.conf
2018-06-07T18:05:22.413785+00:00 app[web.1]: /etc/apache2/magic
2018-06-07T18:05:22.413786+00:00 app[web.1]: /etc/apache2/ports.conf
2018-06-07T18:05:22.413788+00:00 app[web.1]: /etc/apache2/sites-available
2018-06-07T18:05:22.413789+00:00 app[web.1]: /etc/apache2/sites-available/000-default.conf
2018-06-07T18:05:22.413790+00:00 app[web.1]: /etc/apache2/sites-available/default-ssl.conf
2018-06-07T18:05:22.413792+00:00 app[web.1]: /etc/apache2/mods-available
2018-06-07T18:05:22.413793+00:00 app[web.1]: /etc/apache2/mods-available/session_dbd.load
2018-06-07T18:05:22.413794+00:00 app[web.1]: /etc/apache2/mods-available/mime_magic.conf
[...]
The files are magically there again.
@njam, any response from Heroku on this issue?
Yes! Actually they developed a fix, but haven't rolled it out globally yet.
You can enable the fix for a specific application with:
heroku labs:enable --app=YOUR-APP runtime-new-layer-extract
Thank you for quick response!
It doesn't work in my case. On applying the new fix, it gives me: (13)Permission denied: AH00072: make_sock: could not bind to address [::]:80.
This is my Dockerfile:
FROM php:7.2-apache
RUN apt-get update && apt-get install -y python3
RUN ln -s /etc/apache2/mods-available/rewrite.load /etc/apache2/mods-enabled/rewrite.load
COPY src/ /var/www/html/
@rharish101
The web process must listen for HTTP traffic on $PORT, which is set by Heroku.
https://devcenter.heroku.com/articles/container-registry-and-runtime#dockerfile-commands-and-runtime
@rharish101 did you find a fix?
Yeah, I just had to listen to HTTP traffic on $PORT, as pointed out by njam.
Yeah, I just had to listen to HTTP traffic on $PORT, as pointed out by njam.
How exactly did you do this? I tried something like:
RUN sed -i 's/Listen 80/Listen $PORT/g' /etc/apache2/ports.conf
but this does not work (it just changes 80 to $PORT in ports.conf).
@arniwesth It seems like the $PORT environment variable isn't being expanded here. Try replacing the single-quotes with double-quotes, as follows:
RUN sed -i "s/Listen 80/Listen $PORT/g" /etc/apache2/ports.conf
@rharish101 Thx for your reply. Unfortunately, it does not make a difference.
I gave up and ditched Docker for this app.
The heroku $PORT environment variable doesn't seem to be available via the Dockerfile.
I was able to create a shell script to use in CMD which does have access to the variable.
#!/usr/bin/env bash
sed -i "s/Listen 80/Listen ${PORT:-80}/g" /etc/apache2/ports.conf
apache2-foreground "$@"
FROM php:7.3-apache-buster
COPY ./docker/run-apache2.sh /usr/local/bin/
CMD [ "run-apache2.sh" ]
Thanks @travismiller for the example! It was super useful. We ended up with the following script:
#!/usr/bin/env bash
# https://github.com/docker-library/wordpress/issues/293
sed -i "s/Listen 80/Listen ${PORT:-80}/g" /etc/apache2/ports.conf
/usr/local/bin/docker-entrypoint.sh apache2-foreground
By using the docker-entrypoint.sh, php files are copied to /var/www/html when starting. It was useful in our case.
This worked for me
sed -i "s/Listen 80/Listen ${PORT:-80}/g" /etc/apache2/ports.conf
sed -i "s/Listen 80/Listen ${PORT:-80}/g" /etc/apache2/apache2.conf
sed -i "s/VirtualHost \*:80/VirtualHost \*:${PORT:-80}/g" /etc/apache2/sites-available/000-default.conf
Most helpful comment
Yes! Actually they developed a fix, but haven't rolled it out globally yet.
You can enable the fix for a specific application with: