5 ms·

I'm not sure if I am understanding this (aviary.sh) correctly, but it looks like this requires an agent to run on the configured hosts. One of the things that

I'm not sure if I am understanding this (aviary.sh) correctly, but it looks like this requires an agent to run on the configured hosts. One of the things that I love about Ansible's model is that we never need an agent on the host. Once you configure something with Ansible, there's no artifact of the configuration left on the machine.

pampa 6y ago
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.
- soco 6y ago
  It doesn't need any python. Ansible opens a regular ssh session and can run anything from it - including python if available.
  - dfinninger 6y ago
    Only with the “raw” module... which is what you use to ensure Python is installed on a machine managed by Ansible.
- pnutjam 6y ago
  you can use the "raw" module without python.
- cloin 6y ago
  If python is considered an agent, isn't bash now an agent?
- divbzero 6y ago
  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.
- regularfry 6y ago
  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 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?
pnutjam 6y ago
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.
thr0w3345 6y ago
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..
- kapilvt 6y ago
  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.
- discordance 6y ago
  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
- geofft 6y ago
  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.
- nullify88 6y ago
  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.
fanf2 6y ago
The key selling points of Ansible for me were --check and --diff which make it much easier to test and debug a playbook
thayne 6y ago
This is more similar to using ansible-pull than the traditional approach.
lloeki 6y ago
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 root@foo.example.com 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 root@foo.example.com 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 https://gitlab.com/adhoc-gti/apply [1]: https://github.com/lloeki/apply https://github.com/lloeki/apply (personal fork)

pampa 6y ago

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.

soco 6y ago
It doesn't need any python. Ansible opens a regular ssh session and can run anything from it - including python if available.
- dfinninger 6y ago
  Only with the “raw” module... which is what you use to ensure Python is installed on a machine managed by Ansible.
pnutjam 6y ago
you can use the "raw" module without python.
cloin 6y ago
If python is considered an agent, isn't bash now an agent?
divbzero 6y ago
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.
regularfry 6y ago
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 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?

pnutjam 6y ago

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.

thr0w3345 6y ago

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..

kapilvt 6y ago
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.
discordance 6y ago
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
geofft 6y ago
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.
nullify88 6y ago
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.

fanf2 6y ago

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

thayne 6y ago

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

lloeki 6y ago

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 root@foo.example.com 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 root@foo.example.com 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 https://gitlab.com/adhoc-gti/apply [1]: https://github.com/lloeki/apply https://github.com/lloeki/apply (personal fork)