Dave Eddy has learned systems programming the traditional way with books and man pages. Now he's sharing what he's learned, starting with bash.
:link: https://shipit.show/124
I consider myself pretty handy with bash but don’t even bother asking me how to do anything with arrays (especially associative). So that’s also a role of thumb for me.
Also glad to hear the same reservations about Go. I’ve been getting deeper into Kubernetes and have been trying to force myself to like it.
I fully respect that people have done great things with it. There’s nothing too hard about it as a language. It would give me the benefits I want (speed, concurrency, ease of deployment) at the level I mostly work at (between system and application). But after trying about 4 times I don’t like writing it and reading it feels kind of like PHP for me. (No shade intended, just not my taste.)
Bash definitely has its place, just think about all these java tools which require lots of startup parameters nobody can recall and everybody just wraps in a small script :sweat_smile:
But also for more complex stuff. When we started using docker at work, there was nur a clear guidance if docker swarm or kubernetes will win the orchestration game. I just needed a single node installer and as less as overhead for customers. I ended up writing a kind of mini-installer/runner in bash. It was advancing over time and was just packaged as rpm. Batteries included basically, just docker or later podman was required, the rpm even included the container images (I know, typically I should use registries for that, but I needed to serve air-gapped environments).
Bash did all the heavy lifting, creating secrets or prompted for values, displayed licenses, we supported even localisation to different languages.
It handled the correct startup and shutdown of services, provided backup and log collection utilities.
Eventually we could even setup database replication over the bash script.
There were steps which I did not love and would probably have done in golang today, but bash served me well all the years and I did not need to recompile it with most recent golang to fix CVEs :laughing:
Also, the prototype startup script was working in a few hours and I kept advancing it iterativly. I could get quite fast quite far with bash and the "runtime" was just part of the default os packages, which is also a plus for security concerned customers. Those were also not that happy about docker at all :see_no_evil:
Packaging containers in rpm is such a neat idea! If you already have an rpm repo (directory with web server) you don’t need to overly complicate it. Now I want to make a createrepo
for oci artifacts on the file system
We have to push docker images out (no pull) in some of our deployment scenarios. Docker-exporting to tgz and then deploying metal components packaged a .debs has always felt hacky to me.
I had been considering putting the images in .debs too just to make it more consistent, but didn’t because I thought the package gods would strike me down. But knowing that someone else has done something similar gives me a little more confidence.
@Justin Garrison It was the simplest approach I could imagine. Some enterprise customers already had internal rpm repos for their red hat fleet, others could just upload the rpm to their VM and locally install it. I noticed if I save a list of images with docker save
it even deduplicates image layers. I pushed everything out as a single rpm, customers just imported the rpm in the repositories and ran yum update
. The rpm postinstall hook just executed docker load
.
The cli command was shipped as part of the rpm as well.
If customers just updated the rpm, the old containers kept running, so no outage. Once a short outage of a minute or so was feasible, they could use the restart
option which would update the containers with the new images.
I had other scripts available to setup database replication if HA was required, but it was quite simple to get running which helped a lot in doing POCs especially for conservative customers.
Last updated: Dec 12 2024 at 15:40 UTC