![\"Gallery](\"https://vic.demuzere.be/assets/articles/images/FNb7V7tLnMZ0WeLcNBuTw6rek7IgSd4j.jpg\")
I've been looking for a way to host online photo galleries for a while.\nSince the rise of social media a lot of "do it yourself" projects have been abandoned.\nFor galleries this means that they're stuck in the age of HTML tables and ugly designs.\nThe social media generation expects easy to use and well designed user interfaces.\nI don't want to give them a chance to say "it would have been better on social media."
\nAs my own website is statically generated my web server does not provide any scripting capabilities.\nThis makes it secure, low maintenance and fast.\nIn order to be hosted on the same server, the gallery should be generated upfront and require no server-side code.\nPicture galleries are something I tend to forget, I don't want to be doing security updates for a grid of images.
\nAfter trying a few tools, I ended up using thumbsup.\nIt's very easy to use and creates great albums mostly with default settings.\nNo configuration files, no special projects: just give it a folder with images and it'll create something nice.
\n
The command below creates a basic gallery with the great built-in flow theme.\nRunning it in docker makes it even easier as you don't have to mind the python and image resizing dependencies.
\ndocker run -t \\\n\t-v /path/to/source:/input:ro \\\n\t-v /path/to/gallery:/output \\\n\t-u $(id -u):$(id -g) \\\n\tghcr.io/thumbsup/thumbsup:2.16.0 \\\n\tthumbsup \\\n\t--input /input \\\n\t--output /output \\\n\t--title "Gallery title" \\\n\t--cleanup \\\n\t--theme flow\nThe resulting gallery in the output directory is self-containing: it doesn't need the source folder to function.\nOther than that, the website it creates works as you'd expect when opening a folder of images.\nSubfolders are represented as galleries named after the folder, images in the root folder are shown below the galleries.
\nMore configuration options can be found in the thumbsup documentation.
\n","url":"https://vic.demuzere.be/articles/static-gallery-with-thumbsup/","date_published":"2019-12-23T16:13:30Z","date_modified":"2026-05-13T17:29:47Z","language":"en"},{"id":"https://vic.demuzere.be/articles/combining-traditional-configuration-management-with-docker/","content_html":"Configuration management systems like Ansible, Chef, Salt and Puppet are the traditional and proven way to automate server management.\nUsing a tool like one of these has a lot of benefits over manual configuration: Setting up a new server (for new projects or to replace a broken server) can be performed faster and more accurately than we could do manually.\nIt also makes sure that servers and individual services are configured exactly the same when you're doing it multiple times.\nNo doubt about the benefits of configuration management systems.
\nThen Docker came and brought a new way to manage services.\nWith the Dockerfile it introduced a standardized way to describe exactly what should be running inside a container.\nWhile containers were nothing new, the easy to use of the Docker toolchain changed everything.
\nIf you're just managing a few servers and are not planning to scale using Kubernetes or similar orchestration tools, using docker can make managing your services harder.\nKeeping containers up to date means you have to manage another package manager and configuration depends on whatever the image maintainer decided to add to the image.\nHaving a bit more flexibility in the software you're running is awesome, though!\nThat's why I decided to combine services running inside Docker containers with traditional configuration management.
\nSince I want to use my existing Ansible code to manage nginx and its configuration, I need to be able to:
\n/etc/nginx/var/log/nginxphp-fpm, Go webservices, ..)/var/wwwBut I also want features that I can't get on my standard debian system like TLS 1.3 and brotli compression.
\nFirst step was to create an nginx docker image with support for everything I want.\nThe systemd unit below takes care of downloading and starting the container on my server.\nVolumes are mounted on every important path listed above to make sure I can configure everything as if the nginx service was installed using the default Debian package.
\n[Unit]\nDescription=Nginx\nAfter=docker.service\nRequires=docker.service\n\n[Service]\nTimeoutStartSec=0\nRestart=always\nExecStartPre=/usr/bin/docker pull sorcix/nginx:latest\nExecStart=/usr/bin/docker run --net=host --name nginx --rm -v /etc/nginx:/etc/nginx:ro -v /var/log/nginx:/var/log/nginx:rw -v /etc/ssl:/etc/ssl:ro -v /var/www:/var/www sorcix/nginx:latest\nExecReload=/usr/bin/docker exec nginx nginx -s reload\nExecStop=/usr/bin/docker exec nginx nginx -s quit\n\n[Install]\nWantedBy=multi-user.target\nThe --net=host part makes the container use host networking instead of the separate docker network that is usually created for containers.\nForwarding ports 80 and 443 is not required (which actually makes traffic handling a little faster) and we can connect to services running on the host.\nNote that this also means that the additional security that containers usually provide is now missing.\nThat's fine with me as I'm using this as a drop in replacement for the default Debian nginx package which does not provide containerization at all.
The ExecStartPre command downloads new versions of the sorcix/nginx container every time I restart nginx.\nAs I manage the container image myself this isn't really an issue, but you should disable this when using images created by others.