~dricottone/blog

1d3ed4e0cd6688de2477cf664b7ffbbc3d4eeeb8 — Dominic Ricottone 1 year, 3 months ago b407ec9
Now content

Added a new post.

Also added highlighting to the code in an older post.
2 files changed, 106 insertions(+), 3 deletions(-)

A content/posts/buildkit.md
M content/posts/html_and_xml.md
A content/posts/buildkit.md => content/posts/buildkit.md +103 -0
@@ 0,0 1,103 @@
---
title: BuildKit
date: "2023-05-29T21:29:33-05:00"
draft: false
---

Taking a few weeks to focus on DIY homekeeping and Eastern European history
has done wonders for my burnout and energy.
I moved through several of my longest-standing TODOs this weekend.
I'm a bit concerned I might overwork myself with this pace, so I'll
probably return to transcribing college notes in June.

----

I now have a fully functioning mail server on my LAN.
Will I ever expose it to the internet?
Probably.
But that's definitely back to the bottom of my TODO stack.

----

I setup a private (Alpine/Arch) package repository and a private container
image registry.
My scattered Dockerfiles and container recipes are being aggregated into a
single repository for centralized and standardized management.
This became possible because I also got around to testing and deploying
BuildKit for my infrastructure.
(More on this to come.)
A similar effort is under way with the build system for my package repository
but that's not quite ready yet.
I swear this won't sit on my desk as a TODO for the next year.

----

Leveraging this streamlined tooling, I upgraded my deployment of sr.ht to use
independent containers for **each** of the ~15 constituent services.

Security and feature releases were a major headache because they (a) required
me to rebuild the entire APK dependency tree, and (b) required a complete
tear-down and re-build of my monolithic container.
Now I can migrate and upgrade the services independently.
Better yet, the reliable `sshd(8)` and `postfix(1)` services never have to come
down.
I'll likely work on a fallback web server to denote that the services are down
for maintenance. Another TODO for the stack...

----

I, much like the majority of `docker(1)` users I'm sure, have been ignoring the
`docker build` deprecation notices for a long time.

For the most part I deploy containers to Raspberry Pi servers, on which I run
rootless `podman(1)`.
But I do most of my testing and development on my significantly more powerful
PC.
The discrepancy of `podman(1)` vs `docker(1)` is hardly insurmountable, and
if anything I appreciate the portability I've been forced to program into my
scripts.
But the architecture discrepancy has been a major headache for years.
It frustrated attempts to organize a private registry.
It has forced a massive degree of duplication upon me, for which I had to setup
*more* systems to account for user *(read: my)* error.

Last week I read about the multi-platform support in BuildKit and decided to
finally bite the bullet of upgrading the deprecated builder.
I did run into a series of strange bugs, for which the only remedy seemed to be
deleting the first builder container I initialize for any user.
It hasn't resurfaced so I guess I'll just let it slide.
Apart from that, I am pleasantly surprised by how seamless an upgrade it was!

Multi-platform builds were trivial to implement.
The non-local push is a brilliant change that I didn't realize would be so
useful until I was using it for everything.
And of course, the heavy caching and parallelism is greatly appreciated.
I've re-organized my entire workflow around BuildKit and a private registry,
with all container images being built on a single host.

```bash
docker buildx build --push --platform linux/arm64,linux/amd64 --tag $registry/example:latest .
```

My understanding is that this would all work well with `podman(1)` as well,
since they replaced their build system with Buildah a while ago.
Slightly bikeshedded names... although some comments suggest that you can use
`--tag` still.

```bash
podman build --push --platform linux/arm64,linux/amd64 --manifest $registry/example:latest .
```

Even more useful, they support manifest manipulation for cross-platform images
that genuinely require independent builds.

```bash
podman manifest create $registry/example:latest example:amd64 example:arm64
podman manifest push $registry/example:latest
docker manifest rm $registry/example:latest
```

But I don't have a powerful build server running `podman(1)`, and that's the
key factor to my decision.
Perhaps... that's another TODO for the bottom of my stack.


M content/posts/html_and_xml.md => content/posts/html_and_xml.md +3 -3
@@ 80,7 80,7 @@ But for my personal projects, a hack job is just as good.
[^1]: Compare the XML declaration, document type declaration, and root
      element for XHTML:

      ```
      ```xml
      <?xml version="1.0" encoding="UTF-8" ?>
      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
      <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">


@@ 89,7 89,7 @@ But for my personal projects, a hack job is just as good.
      To the document type declaration, root element, and charset declaration for
      HTML4:

      ```
      ```html
      <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
      <html lang="en">
      <head><meta charset="utf-8">


@@ 97,7 97,7 @@ But for my personal projects, a hack job is just as good.

      To that for HTML5:

      ```
      ```html
      <!DOCTYPE html>
      <html lang="en">
      <head><meta charset="utf-8">