Dmytro on Things

Most of the base images in the Docker registry do not offer immutable tags. This means that if you’re building your Docker image based on, for example, an official Ruby image ruby:3.3.0-slim, it might change overnight, and the machines that have already downloaded this tag will never receive an updated image.

Now and then you receive a report about something not working as expected. This time it was scarier than usual: a job, killed by Docker after consuming too much memory with an OOM error, was disappearing from the queue without a trace. In production, we deploy sidekiq-pro for its reliability guarantees, specifically super_fetch strategy for pulling work from the queue, and normally should re-queue the job after a restart.

The idea to restart the blog was lingering in my brain for quite some time. It was never the right time: sometimes I was not sure I have anything to say, often it was dissatisfaction with the available tools and a fear of the amount of effort this endeavor will require. But sometimes you have to accept that things will not be perfect from the start, and some tinkering will be always required.

Nginx is a powerful HTTP server, often used as a reverse proxy for all kinds of service configurations. But even though it is well documented and understood, there are still questions that have contradictory or incomplete answers. One of them is HTTP client header parsing configuration settings, which you normally tweak when nginx returns error 400 and you see “client sent too long header line” in the log.