I’ll chime in because I’ve been using a container/image I put together earlier this year. I’ll share what I did.
My Dockerfile is big but kind of standard for what you’d attempt with Eramba in a container:
FROM ubuntu:bionic
ENV LOCALE="en_US.UTF-8"
RUN apt-get update && apt-get install -y locales && locale-gen ${LOCALE}
ENV LANG=${LOCALE}
ENV LANGUAGE=${LOCALE}
ENV LC_ALL=${LOCALE}
ENV DEBIAN_FRONTEND=noninteractive
ENV APACHE_CONF_DIR=/etc/apache2
ENV PHP_CONF_DIR=/etc/php/7.3
ENV PHP_DATA_DIR=/var/lib/php
ENV WWW_DIR=/var/www/html
ENV ERAMBA_APP_DIR=${WWW_DIR}/eramba_v2/app
ENV ERAMBA_DATASOURCE=Database/Mysql
ENV ERAMBA_DB_PERSISTENT=false
ENV ERAMBA_DB_HOST=localhost
ENV ERAMBA_DB_LOGIN=eramba
ENV ERAMBA_DB_PASS=eramba
ENV ERAMBA_DB_NAME=eramba_v2
ENV ERAMBA_DB_PREFIX=
ENV ERAMBA_DB_ENCODING=utf8
ENV GRC_HOME=/opt/grc
RUN apt-get install -y vim && apt-get install -y net-tools && apt-get install mysql-client -y && apt-get install -y wget
RUN \
BUILD_DEPS='software-properties-common' \
&& dpkg-reconfigure locales \
&& apt-get install --no-install-recommends -y $BUILD_DEPS \
&& add-apt-repository -y ppa:ondrej/php \
&& add-apt-repository -y ppa:ondrej/apache2 \
&& apt-get update \
&& apt-get install mysql-client -y \
&& apt-get install -y curl apache2 libapache2-mod-php7.3 php7.3-cli php7.3-readline php7.3-mbstring php7.3-zip php7.3-intl php7.3-xml php7.3-json php7.3-curl php7.3-gd php7.3-pgsql php7.3-mysql php7.3-ldap php-pear \
&& apt-get install php-ldap -y \
# Apache settings
&& cp /dev/null ${APACHE_CONF_DIR}/conf-available/other-vhosts-access-log.conf \
&& rm ${APACHE_CONF_DIR}/sites-enabled/000-default.conf ${APACHE_CONF_DIR}/sites-available/000-default.conf \
&& a2enmod rewrite php7.3 \
# Install composer
&& curl -sS https://getcomposer.org/installer | php -- --version=1.8.4 --install-dir=/usr/local/bin --filename=composer \
# Cleaning
&& apt-get purge -y --auto-remove $BUILD_DEPS \
&& apt-get autoremove -y \
&& rm -rf /var/lib/apt/lists/* \
# Forward request and error logs to docker log collector
&& ln -sf /dev/stdout /var/log/apache2/access.log \
&& ln -sf /dev/stderr /var/log/apache2/error.log \
&& chown www-data:www-data ${PHP_DATA_DIR} -Rf
#RUN wget -O /tmp/wkhtmltox.deb https://github.com/wkhtmltopdf/wkhtmltopdf/releases/download/0.12.5/wkhtmltox_0.12.5-1.bionic_amd64.deb && yes | apt-get update | dpkg -i /tmp/wkhtmltox.deb; apt-get install -y -f; apt --fix-broken install
COPY ./app/wkhtmltox_0.12.5-1.bionic_amd64.deb /tmp/wkhtmltox.deb
RUN apt-get update | dpkg -i /tmp/wkhtmltox.deb; apt-get install -y -f; apt --fix-broken install
# eramba app import
COPY ./eramba_latest.tar /opt/grc/app/
COPY ./updates /opt/grc/updates
RUN mkdir -p ${WWW_DIR} && tar -xvf /opt/grc/app/eramba_latest.tar -C ${WWW_DIR}
RUN rm -rf /opt/grc/app
# all the eramba config bits that make this work
COPY ./conf/database.php.template ${ERAMBA_APP_DIR}/Config/
COPY ./conf/app_local.php ${ERAMBA_APP_DIR}/Config/
COPY ./conf/CLIENT_KEY ${ERAMBA_APP_DIR}/Vendor/other/
COPY ./conf/eramba.conf ${APACHE_CONF_DIR}/sites-enabled/eramba.conf
COPY ./conf/php.ini ${PHP_CONF_DIR}/apache2/conf.d/custom.ini
#COPY ./conf/apache2.conf ${APACHE_CONF_DIR}/apache2.conf
EXPOSE 80 443
COPY entrypoint.sh /opt/grc/bin/entrypoint.sh
RUN chmod 755 /opt/grc/bin/entrypoint.sh
RUN chown -R www-data:www-data ${WWW_DIR}/eramba_v2/*
WORKDIR ${WWW_DIR}
CMD ["/opt/grc/bin/entrypoint.sh"]
But this only gets you the “latest” e2.5.5. You’ll notice I COPY ./updates to /opt/grc/updates, that’s used in the entrypoint.sh which I’ll snip a bit of below:
#!/bin/bash
WWW_DIR=/var/www/html
ERAMBA_APP_DIR=$WWW_DIR/eramba_v2/app
ERAMBA_DB_CONF=$ERAMBA_APP_DIR/Config/database.php
# default marida DB port
ERAMBA_DB_PORT=3306
mkdir -p ${GRC_HOME}/conf/
ERAMBA_VER=${GRC_HOME}/conf/ERAMBA_VERSION
cp -f $ERAMBA_DB_CONF.template $ERAMBA_DB_CONF
# update the eramba db conf at runtime in case we want to change
sed -ie "s/ERAMBA_DATASOURCE/$ERAMBA_DATASOURCE/g" $ERAMBA_DB_CONF
sed -ie "s/ERAMBA_DB_PERSISTENT/$ERAMBA_DB_PERSISTENT/g" $ERAMBA_DB_CONF
sed -ie "s/ERAMBA_DB_HOST/$ERAMBA_DB_HOST/g" $ERAMBA_DB_CONF
sed -ie "s/ERAMBA_DB_LOGIN/$ERAMBA_DB_LOGIN/g" $ERAMBA_DB_CONF
sed -ie "s/ERAMBA_DB_PASS/$ERAMBA_DB_PASS/g" $ERAMBA_DB_CONF
sed -ie "s/ERAMBA_DB_NAME/$ERAMBA_DB_NAME/g" $ERAMBA_DB_CONF
sed -ie "s/ERAMBA_DB_PREFIX/$ERAMBA_DB_PREFIX/g" $ERAMBA_DB_CONF
sed -ie "s/ERAMBA_DB_ENCODING/$ERAMBA_DB_ENCODING/g" $ERAMBA_DB_CONF
# test that the eramba db exists at the db location
NEW=0
TRIES=10
WAIT=3
echo "trying to connect to the db and check if the eramba schema is loaded..."
for TRY in $(seq 1 $TRIES); do
sleep $WAIT
TABLES=$(MYSQL_PWD=$ERAMBA_DB_PASS mysql -u $ERAMBA_DB_LOGIN -h $ERAMBA_DB_HOST --port=$ERAMBA_DB_PORT $ERAMBA_DB_NAME -e "show tables" 2>/tmp/sqlout)
if [ $? -ne 0 ]; then
if [ $TRY -eq $TRIES ]; then
echo "tried $TRY times to reach the configured db unsuccessfully, the required database, or the credentials provided are invalid"
echo "double check the env variables defined and ensure that the specified database has been created"
echo "check and make sure the database container/service is running and restart this container"
cat /tmp/sqlout
exit -1
fi
fi
done
if [ ${#TABLES} -eq 0 ]; then
NEW=1
echo "db $ERAMBA_DB_NAME is empty, attempting to load the eramba schema"
SLOAD=$(MYSQL_PWD=$ERAMBA_DB_PASS mysql -u $ERAMBA_DB_LOGIN -h $ERAMBA_DB_HOST --port=3306 $ERAMBA_DB_NAME < $ERAMBA_APP_DIR/Config/db_schema/e2.5.5.sql)
if [ $? -eq 0 ]; then
echo "eramba schema is present in the db"
else
echo "loading the eramba db schema seems to have failed, check yout db settings and restart the container"
exit -1
fi
fi
echo "trying to fire off all eramba updates"
SQL="SELECT value FROM settings WHERE variable = 'DB_SCHEMA_VERSION';"
SCHEMA_LVL=$(MYSQL_PWD=$ERAMBA_DB_PASS mysql -s -u $ERAMBA_DB_LOGIN -h $ERAMBA_DB_HOST --port=3306 $ERAMBA_DB_NAME -e "$SQL")
echo "schema is at version $SCHEMA_LVL"
cd $ERAMBA_APP_DIR
UPDATES=($(ls $GRC_HOME/updates | sort --version-sort | paste -sd' '))
echo "UPDATES: ${UPDATES[@]}"
LIDX=0
LENGTH=${#UPDATES[@]}
if [[ -f $ERAMBA_VER ]]; then
echo "this isn't a new install, performing a version check..."
for (( i=0; i<$LENGTH; i++ )); do
FILE="${UPDATES[$i]}"
FF="${FILE%.*}"
LIDX=$((LIDX+1))
echo "inspecting update $FF"
if [[ "$FF" == "$SCHEMA_LVL" ]]; then
echo "found update $FF at our current schema level"
break
fi
done
else
echo "this is a base install, we'll install all versions"
fi
if [ $LIDX -eq $LENGTH ]; then
echo "we're already up to date"
else
echo "for (( i=$LIDX; i<$LENGTH; i++ )); do"
for (( i=$LIDX; i<$LENGTH; i++ )); do
FILE="${UPDATES[$i]}"
FF="${FILE%.*}"
echo "attempting to apply update $FILE"
TRIES=5
for TRY in $(seq 1 $TRIES); do
yes | Console/cake update update ${GRC_HOME}/updates/$FILE
if [ $? -ne 0 ]; then
if [ $TRY -eq $TRIES ]; then
echo "tried $TRY times to update unsuccessfully, exiting..."
exit -1
fi
echo "update $FILE failed to install, this can happen sometimes, retrying $(($TRIES-$TRY)) more times"
else
echo "update $FILE complete"
echo "$FF" > $ERAMBA_VER
break
fi
done
done
fi
chown -R www-data:www-data ${WWW_DIR}/eramba_v2/*
. /etc/apache2/envvars
exec apache2 -D FOREGROUND
1/3 of the shell code is addressing the issue of what this deployment’s version is. When you do the initial deployment, the entrypoint will check what the update level is at and apply those updates (I was thinking you could volume mount an updates directory and when you start the container it’ll check and apply any that are missing).
However this approach still has a major limitation I haven’t had time to work out yet! (but I think I can)
The updates will modify both container files and apply DB migrations when they run. The 1st time the container runs, it’ll update the service and DB to the latest, and run fine. If you stick any other updates in there and restart, they’ll get applied.
BUT when you re-create the container, (down/up) the container files are destroyed and you’ll need to naturally re-apply the updates to get the initial container files 2.5.5 to the latest, but your DB schema is already at the latest.
This is primarily a headache because Eramba doesn’t ship a clean install of their code that is the latest, just updates from an old version to the latest.
If Eramba started shipping releases as a clean install, initial DB schema, and upgrade DB schema (from the last version), they could approach new installs as getting the latest and loading the initial DB schema, and upgrades as coping the latest over the previous and running the upgrade DB schema. (or some variant of this like shipping a clean install, and an upgrade for every release)
Without the ability to perform a clean install of the latest, it means that any containers will need to be treated as a precious snapshot that cannot be lost. You cannot re-create the container because the DB migrations can’t be re-run when all you want is the latest version of the files in the container.
Also waiting for all those updates to install when starting a container for the first time is a pain.
Finally, I have a 2nd container that runs once to apply “post” configuration, like setup LDAP authentication, etc… which you can’t do until after Eramba and its updates are running. I do this via some careful DB inserts and a wrote a web client to interact with the Web UI in a limited way.