Added a short post on ansible

content/posts/naive_classes.md

@@ -369,8 +369,7 @@ but it's still perfectly functional.
 
 It amazes me to no end that you can straight-up rewrite a significant
 portion of the language in itself, and you can just change it however
-you want to. I couldn't imagine doing anything even remotely similar
-to that in, say, Java or C.
+you want to.
 
 I hope you were entertained by this attempt at reinventing the wheel. 
 I certainly enjoyed making it.

content/posts/setup_p1.md

@@ -8,7 +8,7 @@ draft = false
 
 # My Setup
 
-In this 'series' I will be walking you through my process of how I
+In this post I will be walking you through my process of how I
 host everything on this server.
 
 I'm currently running, on top of [my blog](https://emin.software), a [gitea

content/posts/setup_p2.md

@@ -0,0 +1,62 @@
++++
+title = 'My Setup Pt. 2'
+subtitle = 'Ansible.'
+summary = "Raw docker isn't very pleasant. Neither is docker compose, once you have a couple different services. What about ansible?"
+date = 2025-02-26T18:28:17+03:00
+draft = false
++++
+
+Raw docker compose files are nice and all, but they're not all that great for
+reproducability all things considered. 
+
+Yes, docker compose is great and it works,
+but it only works once you already got your server to a point where it has
+docker and docker compose installed, your server configured, etc. and once you
+have a couple services you have to manage several docker compose files, and
+configuration files and folders for each of those services.
+
+Eventually, a single `docker compose up -d` starts to not be enough, as you
+now have to ensure proper ordering between the containers, configure some
+of them to be on the same network, give them names... Putting that information
+into more compose files just doesn't feel as nice for me, because at that
+point each compose file no longer fully encapsulates a container/service,
+it needs to know about the environment it will run in *outside* the compose
+file. At this point, what is the purpose of these files being separate?
+What benefit is there to keeping a dozen separate configuration files
+that each have to know about the others' internals? In my opinion, none. 
+
+No, I would instead prefer to put all of that configuration into a singular
+file. A shell script serves me better in that case. 
+
+Well, you *can* throw all containers into a singular compose file. However
+this brings its own problems, as now the file is a gigantic mess. Not
+really as elegant as I would like.
+
+Point is, the containers are easy to reproduce, deploy and use. However, (and 
+this might seem a little like a gourmet going "this wine just doesn't have the
+flavour I want" while talking about a really expensive bottle of wine) I
+would *really prefer* to be able to manage all these services from a single
+file, and I would *really enjoy* being able to automate setting up and
+maintaining a server.
+
+I recently learned about ansible. Ansible is, in some ways, exactly what I wanted.
+Easy, simple way to automate maintanence on one or more servers - exactly what
+I want.
+
+I now use Ansible's `containers.podman.podman_container` to start containers,
+`containers.podman.podman_pod` to put all those containers into a pod (for
+containers that are easily grouped, like those that serve web pages and such).
+As ansible abstracts away much of the issues of managing a linux server,
+these operations will generally work regardless of whatever distro the
+server happens to be running.
+
+I have an ansible playbook to start everything I want started on the server,
+one to backup data, and one to restore backups. I could literally replace
+my current server within minutes, and honestly I have to say that feels great.
+I mean, in practice, I shouldn't need to do that very often. But I *CAN*.
+
+Anyway, today's post is a short one. I want to post more often, but if I try
+to make every post 200 lines of markdown long I'll probably post like twice a
+year. I'd rather post a little more often :)
+
+Have a nice day.