Since I had difficulties in upgrading my NAS, as I detailed here on this post. I decided that I need to move my NAS services to another server called, workervm. The first service that I decided to move is this web site, my blog, which is a WordPress site hosted by an Apache2 instance with a MySQL database backend.
I decided that instead of installing all the required components on workervm, I will use run WordPress inside a podman container. I already have podman installed and configured for rootless quadlet deployment.
The first step is to backup my entire WordPress document root directory and moved the contents to the target server. I placed the contents on /mnt/hdd/backup on workervm. I also need to perform a dump of the SQL database. On the old blog server, I had to do the following:
sudo mysqldump -u wordpressuser -p wordpress > ../../wordpress.bk.sqlI then proceeded to create the following network, volume, and container files on workervm in ${HOME}/.config/containers/systemd:
I wanted a private network for all WordPress related containers to share and also ensure that DNS requests are resolved properly. Contents of wordpress.network:
[Unit]
Description=Network for WordPress and MariaDB
After=podman-user-wait-network-online.service
[Network]
Label=app=wordpress
NetworkName=wordpress
Subnet=10.100.0.0/16
Gateway=10.100.0.1
DNS=192.168.168.198
[Install]
WantedBy=default.targetI also create three podman volumes. The first is where the database contents will be stored. Contents of wordpress-db.volume:
[Unit]
Description=Volume for WordPress Database
[Volume]
Label=app=wordpressContents of wordpress.volume:
[Unit]
Description=Volume for WordPress Site itself
[Volume]
Label=app=wordpressWe also needed a volume to store Apache2 related configurations for WordPress. Contents of wordpress-config.volume:
[Unit]
Description=Volume for WordPress configurations
[Volume]
Label=app=wordpressNow with the network and volumes configured, lets create our database container with wordpress-db.container:
[Unit]
Description=MariaDB for WordPress
[Container]
Image=docker.io/library/mariadb:10
ContainerName=wordpress-db
Network=wordpress.network
Volume=wordpress-db.volume:/var/lib/mysql:U
# Customize configuration via environment
Environment=MARIADB_DATABASE=wordpress
Environment=MARIADB_USER=wordpressuser
Environment=MARIADB_PASSWORD=################
Environment=MARIADB_RANDOM_ROOT_PASSWORD=1
[Install]
WantedBy=default.targetNote that the above container refers database volume that we configured earlier as well as the network. We are also using the community forked version of MySQL (MariaDB).
Finally we come to the configuration of the WordPress container, wordpress.container:
[Unit]
Description=WordPress Application
# Ensures the DB starts first
Requires=wordpress-db.service
After=wordpress-db.service
[Container]
Image=docker.io/library/wordpress:latest
ContainerName=wordpress-app
Network=wordpress.network
PublishPort=8168:80
Volume=wordpress.volume:/var/www/html:z
Volume=wordpress-config.volume:/etc/apache2:Z
# Customize via Environment
Environment=WORDPRESS_DB_HOST=wordpress-db
Environment=WORDPRESS_DB_USER=wordpressuser
Environment=WORDPRESS_DB_PASSWORD=################
Environment=WORDPRESS_DB_NAME=wordpress
[Install]
WantedBy=default.targetNotice the requirement for the database container to be started first, and this container also uses the same network but the two volumes are different.
We have to refresh the system since we changed the container configurations.
systemctl --user daemon-reloadWe can then start the WordPress container with:
systemctl --user start wordpressOnce the container is started, we can check both the WordPress and its database container status with:
systemctl --user status wordpress wordpress-dbAnd track its log with:
journalctl --user -xefu wordpressIt is now time to restore our old content with:
podman cp /mnt/hdd/backup/. wordpress-app:/var/www/html/
podman unshare chmod -R go-w ${HOME}/.local/share/containers/storage/volumes/systemd-wordpress/_data
podman unshare chown -R 33:33 ${HOME}/.local/share/containers/storage/volumes/systemd-wordpress/_dataThe copy will take some time, and once it is completed, we have to fix the permissions and ownerships. Note that both of these have to be performed with podman unshare command so that proper uid and gid mapping can be performed.
I also had to restore the database contents with:
cat wordpress.bk.sql | podman exec -i wordpress-db /usr/bin/mariadb -u wordpressuser --password=############# wordpressLastly I needed to modify my main/old Apache server where the port forwarding is directed to so that blog.lufamily.ca requests are forwarded to this new server and port.
Define BlogHostName blog.lufamily.ca
Define DestBlogHostName workervm.localdomain:8168
<VirtualHost *:443>
ServerName ${BlogHostName}
ServerAdmin kangclu@gmail.com
DocumentRoot /mnt/airvideo/Sites/blogFallback
Include /home/kang/gitwork/apache2config/ssl.lufamily.ca
SSLProxyEngine on
ProxyPreserveHost On
ProxyRequests Off
ProxyPass / http://${DestBlogHostName}/
ProxyPassReverse / http://${DestBlogHostName}/
# Specifically map the vaultAuth.php to avoid reverse proxy
RewriteEngine On
RewriteRule /vaultAuth.php(.*)$ /vaultAuth.php$1 [L]
ErrorLog ${APACHE_LOG_DIR}/blog-error.log
CustomLog ${APACHE_LOG_DIR}/blog-access.log combined
</VirtualHost>Note that on the old server I still have the document root pointed to a fallback directory. In this fallback directory I have php files that I needed to be served directly without being passed to WordPress but the requested path shares the same domain name as my WordPress site. The rewrite rule performs this short circuit processing. When vaultAuth.php is requested, we skip the reverse proxy all together.
This is working quite well. I am actually using the new location of this blog site to write this post. I plan to migrate the other services on my NAS in a similar manner with podman.
The idea is that once the majority of the services have been ported to workervm, then I can reinstall my NAS with a fresh install of Ubuntu 24.04 LTS without doing a migration.