At some point in a previous company we had a lot of individual VPSes set up basically the same way. I was sick of internal documentation that listed step-by-step commands intertwined with descriptions and manual actions, and any attempt at puppet or ansible just blew up because it was something else to learn by the team (believe me, I tried, it just wouldn't stick with anyone).

So I created `apply`[0].

This small bash thing pushes bash scripts called 'units' through ssh to execute through an uploaded 'run' script:

   ./push units/update units/sshd units/ssh_authorized_keys [email protected]

By writing those 'unit' scripts to be idempotent you can just run them again and again. 'units' can be aggregated in 'groups', which can themselves reference 'groups':

   ./push groups/base groups/ruby units/dockerd [email protected]

Finally, you can define 'hosts', which are like 'groups', only they save you some typing, which it could do in sequence or parallel:

   ./apply hosts/foo.example.com hosts/bar.example.com

And since units/, groups/, and hosts/, are just directories and files, autocompletion works immediately and you could get creative with shell expansion for arguments.

It was a deceptively simple experience, immediately accessible, trivially enabled literate coding, and overall extremely useful both to set up and maintain those VPSes as well as creating dev environments, or local VMs to test a e.g one-shot unit performing a change or migration.

[0]: https://gitlab.com/adhoc-gti/apply

[1]: https://github.com/lloeki/apply (personal fork)

The agent approach is mostly ok, it tends however to suffer when you have more than a few hundred machines (I’ve found, anyway) that your ansible code rots a bit. Say for that one server, you know the one, the weird etl thing bi uses, was run once and during a prod problem you suddenly have to start fixing the ansible code to rebuild it.

With an agent, it’s applying all the time and this doesn’t happen.

We actually moved to salt from ansible and we’re happy..

I'm a bit confused - agent vs. agentless isn't obviously correlated to continuous vs. on human action to me. Write a cronjob / systemd timer / scheduled task / Jenkins job / Travis cronjob / GitHub Actions scheduled event / CloudWatch + Lambda / whatever you like to run your Ansible playbook, from one machine/container/whatever, on your entire fleet. (It's certainly no harder than writing a cronjob or whatever to run your config management on every machine - if you can schedule tasks on all your machines, you can certainly schedule them on one.)

That gets you the standard advantages of agentless setups, including not requiring the runtime of your config management tool to be everywhere, being able to reprovision ephemeral + immutable cloud resources, and being able to centrally report errors, without any more risk of configuration drift or bitrot.

while ansible does push more commonly (and checkout mitogen for speed increases there), its also trivial to do pull mode with some loss of multi-node orchestration, and just cron/systemd timer it.

Have also had issues with agents in high security areas.

Machines sitting behind VNets, governed by security review boards makes getting agents approved a bit tricky

This behaviour is why I'm using (and liking) Chef these days, where six years ago I absolutely hated Chef.

I still love Ansible, especially for small quick things. As with many tools, though, it's not the only one I reach for any more.

Salt agents in particular call out to the master making NAT a non issue. While it does have problems of its own (connection scaling), it made automating servers across 600 physical locations much easier.

I manage thousands of machines with rrconf

That is not entirely true. Ansible needs python installed on the target host, and a lot of modules (plugins?) require additional python libraries on the target.

The av agent that GP refers to is a script that runs periodically on target hosts to pull the latest configuration using Git. Ansible has a Python dependency but no agent running on target hosts, instead relying on SSH to push configuration changes.

Ideally, I’d like to see a configuration tool that uses Ansible’s SSH push model but without the Python dependency.

Strictly speaking, shouldn't it be possible to bodge ansible to send and execute a static python interpreter to bootstrap a host? I've been bitten by "oh no, that Python's too old" or similar several times now. The idea of bootstrapping from only having a `sh` on the far end seems like it ought to be a thing, but (for instance) mitogen only goes part-way.

There was a pen-test tool designed on these lines once called Mosquito Lisp, which as far as I can see evolved into something called WaspVM: https://github.com/swdunlop/WaspVM I have no idea if it's in use, alive, or even working these days.

Is anyone working on this side of the problem and I've missed it?

If python is considered an agent, isn't bash now an agent?

It doesn't need any python. Ansible opens a regular ssh session and can run anything from it - including python if available.

Only with the “raw” module... which is what you use to ensure Python is installed on a machine managed by Ansible.

you can use the "raw" module without python.

Ansible does create a bunch of temp files. I've even had issues where my ansible barfed because my uid changed and the old temp files couldn't be accessed anymore.

The key selling points of Ansible for me were --check and --diff which make it much easier to test and debug a playbook

This is more similar to using ansible-pull than the traditional approach.