<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>DevOps on Alexander's Blog</title><link>https://alexanderbakin.com/tags/devops/</link><description>Recent content in DevOps on Alexander's Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 20 Aug 2026 21:15:35 +0400</lastBuildDate><atom:link href="https://alexanderbakin.com/tags/devops/index.xml" rel="self" type="application/rss+xml"/><item><title>Fixing logrotate's Glob Confusion</title><link>https://alexanderbakin.com/logrotate-fix/</link><pubDate>Thu, 20 Aug 2026 00:00:00 +0000</pubDate><guid>https://alexanderbakin.com/logrotate-fix/</guid><description>&lt;p&gt;A follow-up to &lt;a href="https://alexanderbakin.com/logrotate-wildcard-bug/"&gt;the wildcard bug post&lt;/a&gt; from last year.&lt;/p&gt;
&lt;h2 id="picking-the-thread-back-up"&gt;Picking the Thread Back Up&lt;/h2&gt;
&lt;p&gt;The rename workaround, &lt;code&gt;*.example.com&lt;/code&gt; to &lt;code&gt;_.example.com&lt;/code&gt;, fully resolved the operational problem. Retention became predictable again, and there was no pressing reason to go further. But a workaround isn&amp;rsquo;t a fix, and the actual bug was still sitting in logrotate&amp;rsquo;s own source, waiting to bite the next person who names a file after a wildcard domain. This week I finally sat down and found it properly, instead of just renaming files around it.&lt;/p&gt;</description></item><item><title>The Wildcard That Broke Nginx Log Rotation</title><link>https://alexanderbakin.com/logrotate-wildcard-bug/</link><pubDate>Sat, 05 Jul 2025 00:00:00 +0000</pubDate><guid>https://alexanderbakin.com/logrotate-wildcard-bug/</guid><description>&lt;p&gt;One of those infrastructure problems that looks simple, until you realize the filename itself is part of the problem.&lt;/p&gt;
&lt;h2 id="the-setup"&gt;The Setup&lt;/h2&gt;
&lt;p&gt;We had Nginx configured to handle wildcard subdomains: &lt;code&gt;server_name *.example.com;&lt;/code&gt;, with access logs named after the server block. That&amp;rsquo;s a convenient pattern for multi-tenant setups where subdomains get created dynamically and you don&amp;rsquo;t want to hand-maintain a vhost file per tenant. Nginx doesn&amp;rsquo;t care that the resulting log filename contains a literal &lt;code&gt;*&lt;/code&gt; - it just opens the file and writes to it.&lt;/p&gt;</description></item><item><title>From 4 Hours to 20 Minutes: Replacing a Manual Deployment with GitLab CI</title><link>https://alexanderbakin.com/faster-gitlab-ci/</link><pubDate>Tue, 09 Apr 2024 00:00:00 +0000</pubDate><guid>https://alexanderbakin.com/faster-gitlab-ci/</guid><description>&lt;p&gt;Deploying used to mean an engineer, a runbook document, and four hours of undivided attention. Not four hours of a pipeline running in the background, four hours of a person actively driving it: SSH into the target host, pull the latest code, run the build script by hand, stop the old process, start the new one, watch the logs to see if it came up clean, and post a status update. It worked, in the sense that it got code to production. It didn&amp;rsquo;t scale, in the sense that &amp;ldquo;get code to production&amp;rdquo; now depended entirely on one specific person having a free afternoon.&lt;/p&gt;</description></item></channel></rss>