While updating one of my websites I noticed that a CSS file wasn't being updated.
\nAs I'm using Cloudflare to cache my website my first guess was that the cache on their side wasn't being cleared.\nPushed the clear cache button multiple times without any effect. It's clearly broken!\nA direct request to my webserver cleared any blame on Cloudflare though: my server was replying with an old version of my CSS file.
\nThen it must be rsync! I'm using rsync to push the new versions of my website from my development machine to the server.\nA few retries later the funny looking webpages suggested the CSS was still wrong.\nChecking the file on my server confirmed that rsync had actually replaced the CSS, retrying the upload was useless.
\nWhy was nginx still serving the old CSS? Turns out it was my configuration.
\nAs recommended by most optimization guides my nginx configuration allows using sendfile.\nThis option is especially useful for static websites like mine, as every single page can be served right from the filesystem.
\nhttp {\n sendfile on;\n tcp_nopush on;\n}\nBut what does it do exactly?
\nThe nginx documentation explains the sendfile option as:
\n\nEnables or disables the use of sendfile().
\n
That's exactly what I would expect from a boolean option!\nSendfile is actually a Linux system call executed by nginx, for more information we have to resort to the man pages.
\n\n\nsendfile() copies data between one file descriptor and another.\nBecause this copying is done within the kernel, sendfile() is more\nefficient than the combination of read(2) and write(2), which would\nrequire transferring data to and from user space.
\n
So basically nginx just asks the kernel to copy the contents of a file to the connection with the visitor's browser.\nThis makes serving static files a lot faster, as it eliminates the step where nginx copies the file into its own buffers. Yay!
\nAnother optimization I've been using is the open_file_cache options:
http {\n open_file_cache max=1000 inactive=20s;\n open_file_cache_errors on;\n open_file_cache_min_uses 2;\n open_file_cache_valid 30s;\n}\nWhen we turn to the nginx documentation again, what we should know about the open file cache is that it contains information about files being served from the filesystem:
\nThis cache is quite useful as the modification time allows nginx to reply to If-Modified-Since requests without actually opening the file.\nAnother situation that happens quite frequently is a non-existing file being requested multiple times.\nThe best known example is the favicon.ico that most browsers request whenever you visit a website.\nAs nginx already knows that the file is not actually there, it can simply reply with a 404 response right away.
Great, huh?
\nRemember how sendfile copies data from one file descriptor to another?\nIf the file on disk was replaced (not just modified) then this causes nginx to keep sending data from the old file instead of the new one.\nThis can be very confusing if you also have a web cache (Varnish, or a service like Cloudflare for example) as you'll be blaming the cache first.
Looks like there is no way to clear the open file cache.\nAs I don't want to restart nginx every time I update my website I have modified my configuration to no longer cache files for 30s.
\nAs an extra: rsync is the reason why my files were replaced.
\n\n\nAfter the temp-file has been completed, its ownership and permissions and modification time are set. It is then renamed to replace the basis file.
\n
This means the existing file is not modified. It is actually replaced by a new file, to make sure we don't end up with only half of the contents in case transfer fails.
\n","url":"https://vic.demuzere.be/articles/nginx-outdated-content-being-served/","date_published":"2019-12-05T15:35:00Z","date_modified":"2023-11-28T19:55:32Z","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.