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">