62 lines
3.1 KiB
Markdown
62 lines
3.1 KiB
Markdown
+++
|
|
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. |