πŸ“• Node [[ansible]]
πŸ“„ ansible.md by @neil οΈπŸ”— ✍️

Ansible

[[Infrastructure as code]].

Configuration management.

neil: Getting started with Ansible. Definitely enjoying it as a reproducible way of documenting all the steps involved in a server’s setup.

But… am I going to forget how to do all the actual underlying commands if everything is just an Ansible task in a yaml file? What if I need them in an emergency??

brennen: yes.

brennen: i don’t care for ansible very much in general, but apart from implementation details i’ve forgotten (it’s been a few years since i used it intensively), i think most of my discontent is with the entire class of tool it occupies.

as far as i can tell, configuration management is an unsolved problem and there a lot of disconnects between the ways things like puppet, chef, ansible, helm, k8s, et al. claim to model system state and how that state is actually achieved.

neil: My journey so far is: a) I have a bunch of servers I’ve configured manually over time, this is not good for disaster recovery; b) maybe I’ll just write a shell script with all the steps; c) may as well use something someone else has done for this; d) this is cool but…is it going to be more trouble than it’s worth?

brennen: i wish i had a good answer to that, but i really really don’t. at work, i swim in a sea of ad hoc tooling (shell, python, php, golang), puppet manifests, jenkins jobs, templated dockerfiles, and deeply nested yaml. on a very good day i can probably claim to understand about 1% of it.

all that stuff is what it is for Reasons, but in my personal life it’s all kind of driven me back in the direction of least-common-denominator shell scripts and text files with some notes about what to run.

brennen: i think a lot of people get good value out of something like ansible (or even, say, something like https://www.fabfile.org/), but i think it’s good to know it can be a real tarpit going in and consciously try to keep things simple.

neil: I’m doing pretty small-fry stuff so if I can get by with something not too much far above shell scripts and docs, that’d be my ideal.

πŸ“„ ansible.md by @agora@botsin.space
πŸ“„ ansible.md by @an_agora@twitter.com
πŸ“„ ansible.md by @anagora@matrix.org
  • [[2022-11-14 21:16:39]] [[@flancian:matrix.org]] (link):
    •                - report to Nathan on wiki consolidation with a yes :)
                  - keep tech/operations as the One Repository to clone if you're a new member of the twg
                  - fold [[sauce]] general scripts into [[tech operations]]
                  - fold [[systemd unit]] files in [[sauce]] into [[ansible]]
                  - fold [[tech operations]] wiki into [[general.wiki]]
                  - [[redoak]] did the last mastodon upgrades, we could ask how long of a maintenance window we should call
                  - Announce maintenance window for upgrades: **Let's shoot for Monday 21 at 18-20 UTC**
      
πŸ“„ ansible.md by @flancian@social.coop
πŸ“„ ansible.md by @flancian@twitter.com

Today we made some progress on setting up a new (secondary) server for #socialcoop, and I started learning [[ansible]]: https://t.co/ABRHE0TQMZ

Pretty fun! I’m glad I was finally able to make some time.


Loading pushes...

Rendering context...