Consider moving to ansible
Closed this issue · 4 comments
It would be a nice move for abstracting the parts of of the scripts than can be done remotely, from the things we have to supervise.
We have a lot of package manager stuff in here that gets no benefit at all from being in shell scripts, and re-running them always takes a while because they are dumb and do not consider whether something is already installed. Ansible could help alleviate that + could potentially help version manage some stuff better as well.
If things go awry, we should be able to just run a subset of the ansible code against localhost provided it's modular enough.
Some stuff that's likely going to be awkward:
- compiling llvm for debian (not needed for gentoo/arch)
- compiling profanity for debian (ditto)
- setting up a dev environment that clones a bunch of my repos
- dotfile installation
- host level secrets
- secrets with shell install scripts
The secrets part could be solved by bringing in blackbox though, maybe just a good.
Host level (non-secret) changes will have a better home in here rather than in dotfiles (not going to start symlinking from /etc to /home/clux anyway to get the benefits the normal dotfiles have w.r.t. version management). May as well get used to having ansible provision host level stuff and updating ansible first, since this is more sensible for larger sets of servers anyway.
Host secrets, blackbox + host specific roles?
My images that are built with genboot[0] come with ansible and git pre-installed. I wonder if you could combine this strategy with systemd-firstboot to git clone && ansible-playbook.
Had a bit of a go, now with ansible. Understand more how it works, and what I have to do. But it's a bit awkward. Stuff that's super natural in bash, explodes into weird yaml with edge cases where I have to battle ansible, but it's at least more readable. Not fully sold, yet, but jotting down some issues I've encountered so far.
- pip not being able to install local modules with a local connection when run in a virtualenv (which I need because system interpreter is 3.5)
- no way to parallelize tasks/roles afaikt
- jinja2 filters are horrible - I would rather have plain python somewhere
But, things work, logging is good, install are fast second time around as they should be - apart from npm which is dumb as always. Current workflow
wget -qO- https://github.com/clux/dotclux/archive/ansible.tar.gz | tar xz
# cd, venv, pip install -r ..
ansible-playbook -i hosts -vv --ask-become-pass machine.yml --tags=nodejsEtc. Looks like it can be a nice workflow if I don't go insane doing this.
As for how far down I can get this, systemd-firstboot would be awesome. How realistic of a goal that would be is probably more reliant on the OS. Hard to do stuff that low level with Arch (when you have to boot after installing nvidia drivers to blacklist nouveau) or Debian (which I've only really tried installing through the awkward installer that prompts you every 5 minutes, and already comes with tons of stuff that the docker base does not).
Ansible branch now set as default as the current skeleton works pretty well for arch. Opening more specific issues soon.