Content tagged with #Continuous Deployment.https://dbuho.meen© 2026 Damián Búhodamian.buho@proton.me (Damián Búho)damian.buho@proton.me (Damián Búho)Thu, 12 Nov 2026 16:25:24 GMTResilience60https://dbuho.me/favicon-48x48.pnghttps://dbuho.mehttps://dbuho.me/post/what-is-b19/?utm_source=tag-continuous-deployment&utm_medium=rss01M3DBSDTEQ9SDFATFNBFXEQ7BA big part of my portfolio consists of so-called b19-style images. (b19 means nothing—you just can&#39;t get a proper namespace these days.) It started as an internal effort for my personal and commercial projects, but ended up as a set of conventions unified across 100+ various images (both wrappers and originals). I wanted every container to behave in a predictable way, agnostic of the tech stack, whether it&#39;s a source-based or upstream-based project. I&#39;m not urging anyone to adopt this directly yet—I need some time in public to polish everything—but if you&#39;re tasked with a similar unification job or manage a fleet, feel free to steal the conventions. The conventions are anchored in B19/Ubuntu and flow organically into all downstream projects. The conventions are unopinionated (though the defaults can be). What&#39;s inside?Tue, 09 Jun 2026 02:59:00 GMT<p>A big part of my portfolio consists of so-called b19-style images.<br /> <em>(b19 means nothing—you just can&#39;t get a proper namespace these days.)</em></p> <p>It started as an internal effort for my personal and commercial projects, but ended up as a set of conventions unified across 100+ various images (both wrappers and originals). I wanted every container to behave in a predictable way, agnostic of the tech stack, whether it&#39;s a source-based or upstream-based project.</p> <p>I&#39;m not urging anyone to adopt this directly yet—I need some time in public to polish everything—but if you&#39;re tasked with a similar unification job or manage a fleet, feel free to steal the conventions.</p> <p>The conventions are anchored in <a href="https://dbuho.me/project/b19-ubuntu/">B19/Ubuntu</a> and flow organically into all downstream projects.<br /> The conventions are unopinionated (though the defaults can be).</p> <p>What&#39;s inside?</p> <h2>Basic container decency</h2> <ul> <li>Follows 12-factor app guidelines</li> <li>Reasonable, secure, and safe defaults with minimal user input required</li> <li>Images should be immutable; all state lives in volumes</li> <li>Support for XDG and other industry standards</li> <li>Proper telemetry everywhere</li> <li>File operations use locks, always keeping concurrency in mind</li> </ul> <h2>The Dockerfile orchestrates</h2> <ul> <li>No shell sagas</li> <li>No mile-long <code>RUN</code> commands—one <code>RUN</code> per stage</li> <li>Minimal layers</li> </ul> <h2>Switches, toggles, handles</h2> <p>B19-style images expose switches for all kinds of behavior: there&#39;s no such thing as &quot;too many switches.&quot; Where possible, switches are set via environment variables (relying on various mounts and binds is messy).<br /> Configuration files are generated via Jinja2 templates driven by environment variables.</p> <h2>Everything is <code>.d</code></h2> <p>Numbered hooks everywhere. Everything can be extended or overridden via simple drop-in shell scripts in downstream projects. Hooks can be inherited:</p> <ul> <li>Build is <code>build.d</code></li> <li>Healthcheck is <code>healthcheck.d</code></li> <li>Entrypoint is <code>entrypoint.d</code></li> </ul> <h2>Designed with off-grid in mind</h2> <ul> <li>Do not assume connectivity is guaranteed</li> <li>Do not assume fast or stable connectivity</li> <li>Timeouts, backoffs, and retries everywhere</li> </ul> <p>In other words, a b19 distribution comes with all the things you would end up adding to an official image anyway—right out of the box.</p>MetaContainerizationDockerContinuous IntegrationContinuous Deploymentdamian.buho@proton.me (Damián Búho)