I have a PHP application with a MariaDB backend which I am trying to containerize. I have a lot of scripts that have previously been run while initializing a Vagrant config.
Most of my setup works, But i have a feeling that I have a chicken and egg situation:
docker-compose.yml
services:
myapp:
image: myapp-php
container_name: myapp-php
build:
context: .
dockerfile: ./containerconfig/docker/php/Dockerfile
args:
- SERVER_NAME=${SERVER_NAME}
- WWWPATH=${WWWPATH}
- MYAPPSESSIONNAME=${MYAPPSESSIONNAME}
- SITETITLE=${SITETITLE}
- SITENAME=${SITENAME}
- EMAIL=${EMAIL}
- DBUSER=${MARIADB_USER}
- DBPASS=${MARIADB_PASSWORD}
- MYSQL_DATABASE=${MARIADB_DATABASE}
- MYSQL_HOSTNAME=${DBHOST}
- MYSQL_PORT=${DBPORT}
- LOG_PATH=${LOG_PATH}
- CERT_LOCATION=${CERT_LOCATION}
volumes:
- ./src:${WWWPATH}:rw
- ./log/apache2:/var/log/apache2/myapp:rw
ports:
- '80:80'
- '443:443'
environment:
- VIRTUAL_HOST=myapp.docker
env_file:
- .env
depends_on:
db:
condition: service_healthy
init-db:
condition: service_completed_successfully
db:
image: mariadb
container_name: myapp-db
restart: always
### https://mariadb.com/kb/en/mariadb-server-docker-official-image-environment-variables/
environment:
MARIADB_ROOT_PASSWORD: ${MARIADB_ROOT_PASSWORD}
MARIADB_DATABASE: ${MARIADB_DATABASE}
MARIADB_USER: ${MARIADB_USER}
MARIADB_PASSWORD: ${MARIADB_PASSWORD}
healthcheck:
test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
interval: 10s
timeout: 5s
retries: 3
ports:
- "127.0.0.1:3366:3306"
init-db:
image: myapp-db-init
container_name: myapp-db-init
init: true
build:
context: .
dockerfile: ./containerconfig/docker/db-initiator/Dockerfile
volumes:
- ./resources/database/SQL:/tmp/sql-scripts:ro
- ./containerconfig/scripts:/tmp/init-scripts:ro
depends_on:
db:
condition: service_healthy
env_file:
- .env
entrypoint: [ "sh", "-c", "apk add mysql-client && sleep 10 && /tmp/init-scripts/mysql.sh "]
FROM php:8.2-apache
USER root
RUN apt-get update && apt-get install -y libpng-dev
&& docker-php-ext-install pdo_mysql mysqli gd iconv
COPY containerconfig/conf/myap.conf /tmp/
COPY containerconfig/conf/servername.conf /tmp/
# create folder for init scripts and copy them to it
RUN mkdir /tmp/init-scripts
RUN mkdir /var/log/apache2/myapp
RUN mkdir /etc/apache2/ssl-certs
COPY containerconfig/scripts/* /tmp/init-scripts/
# clean up apt cache
RUN apt-get clean autoclean
RUN apt-get autoremove --yes
RUN rm -rf /var/lib/{apt,dpkg,cache,log}/
# make
ARG SERVER_NAME ${SERVER_NAME}
ARG WWWPATH ${WWWPATH}
ARG MYAPPSESSIONNAME ${MYAPPSESSIONNAME}
ARG SITETITLE ${SITETITLE}
ARG SITENAME ${SITENAME}
ARG EMAIL ${EMAIL}
ARG DBUSER ${DBUSER}
ARG DBPASS ${DBPASS}
ARG MYSQL_DATABASE ${MYSQL_DATABASE}
ARG MYSQL_HOSTNAME ${MYSQL_HOSTNAME}
ARG MYSQL_PORT ${MYSQL_PORT}
ARG CERT_LOCATION ${CERT_LOCATION}
RUN /tmp/init-scripts/apache.sh
RUN /tmp/init-scripts/write_config.sh
WORKDIR ${WWWPATH}
EXPOSE 86
The write_config.sh script creates two dummy json files and copies a template config and fills it out. the two json files are created fine, but the copied template is not found:
# excerpt from write_config.sh
echo "*** creating new config file @ $CONFIG_FILE"
cp "$WWWPATH/globals.template.inc.php" $CONFIG_FILE
#---
# emulate files made by build job
echo '{"branch": "dummyFrontEndBranch", "commit": "000000"}' > "$WWWPATH/frontend_meta.json"
echo '{"branch": "dummyBackendBranch", "commit": "000000"}' > "$WWWPATH/backend_meta.json"
This gives the following errors:
*** creating new config file @ /var/www/html/globals.inc.php cp: cannot stat '/var/www/html/globals.template.inc.php': No such file or directory sed: can't read /var/www/html/globals.inc.php: No such file or directory
I assume that the issue is that I am running the script in the dockerfile, and further assume that the volume is not mounted before that has completed. I am not sufficiently well-versed in how to fix this.
The pattern I typically use for this sort of operation is an entrypoint wrapper script. For your image’s ENTRYPOINT, write a shell script that does whatever first-time setup you need to do, then use the shell exec built-in to switch to the image’s CMD as the main container process. The entrypoint script doesn’t run as part of the image build, which means it runs after volumes are mounted, and it can see runtime environment: variables.
Your base image already declares its own CMD (your image doesn’t have one) so you need to look at the Docker Hub image page and ideally find the original GitHub source for the Dockerfile. That ends with
ENTRYPOINT ["docker-php-entrypoint"]
CMD ["apache2-foreground"]
so in our own wrapper, we need to include the parent image’s ENTRYPOINT value in the final exec line, and repeat the CMD in our own Dockerfile.
#!/bin/sh
# myapp-entrypoint
# Run startup-time scripts
/tmp/init-scripts/apache.sh
/tmp/init-scripts/write_config.sh
# Also do the work that the init-db container does here
/tmp/init-scripts/mysql.sh
# Switch to the base image's setup
exec docker-php-entrypoint "$@"
# end of Dockerfile
ENTRYPOINT ["/tmp/init-scripts/myapp-entrypoint"]
CMD ["apache2-foreground"]
The next issue you will run into is that Dockerfile ARG aren’t visible any more when the main container process runs. The various things you have set as ARG now you need to inject as environment variables instead. This is generally a better practice in any case – you don’t want to have to rebuild your image just because the database password changed, and you don’t want the database password to be visible in docker history.
# docker-compose.yml
version: '3.8'
services:
myapp:
build:
context: .
# TODO: move Dockerfile up to project root directory
dockerfile: ./containerconfig/docker/php/Dockerfile
# no args:
volumes:
# TODO: remove this mount
- ./src:${WWWPATH}:rw
- ./log/apache2:/var/log/apache2/myapp:rw
ports:
- '80:80'
- '443:443'
environment:
- SERVER_NAME # <-- runtime environment:, not build: { args: }
- WWWPATH
- MYAPPSESSIONNAME
- ...
- MYSQL_DATABASE=${MARIADB_DATABASE}
- MYSQL_HOSTNAME=db
- VIRTUAL_HOST=myapp.docker # (was in the original Compose setup)
env_file:
- .env
depends_on:
db:
condition: service_healthy
db: { ... }
In the Dockerfile, you do not need to specifically declare these ENV variables (and again their values aren’t available at build time, and could change running the same image in different environments).
I would recommend COPYing your application code into the image, rather than injecting it via a bind mount. This will make it possible to run the image in a deployed environment with only Docker, Compose, and the Compose configuration available, without also needing a copy of the application source checked out.
2