I used it at work, and hated every moment of it. You're programming in yaml, which is an ultimate moronation. Brainlets are still using it to this day.
Don't be a moron, use nixos for truly reproducible infrastructure.
>We just use bash and pssh and pscp on thousands of baremetal servers
That's fricking moronic beyond belief, but just moronic enough to make me believe that there's an actual company out there doing exactly that
I used it extensively to provision and manage thousands of bare metal boxes. It was fricking awful. Writing it sucks, running it sucks, debugging it sucks, literally nothing about it is good. It's slow as frick unless you do all sorts of complicated shit to make machines run plays against themselves, and even then it's much slower than just using a bash script.
Good for somewhat straightforward deployment orchestration and replacing people who can only follow a runbook with automation.
Using it at scale in place of something like Puppet, Chef, or Salt is a fools errand and will leave you in tears.
Everything that is good about it for doing simple stuff (no agent, it's just yaml bro, no central server, just runs with ssh credentials) in practice works against it at scale for doing real config management.
If your systems are roughly immutible and you can let ansible set it up the first time and then not touch them again except for re-deploy it can be fine. But you don't want to try and manage much more than a few hundred nodes with ansible in push mode.
Pull can maybe be done, but it kind of sucks for different reasons.
The language itself is great if you are doing relatively straight forward stuff (install this package, run this command, wait for port, restart this thing, write this file, etc)
The moment you get out of that scope things become a fricking mess. You end up with horrible hacks trying to make a markup language act like a real language and it's suffering.
>You end up with horrible hacks trying to make a markup language act like a real language and it's suffering.
This. I have gotten in many fights trying to prove that Ansible fricking sucks. It's fricking Yaml for crying out loud. THEY USED PYTHON TO MAKE SOMETHING 100 TIMES SLOWER THAN PYTHON, AND THEY REPLACED THE ELEGANT SUCCINCT SYNTAX OF PYTHON WITH FRICKING YAML THAT TAKES 10 LINES FOR AN ASSIGNMENT AND HAS 2 BUGS PER LINE THAT WILL BITE YOU ON PROD DEPLOYMENT. FRICK THIS.
>How many of you actually sue this professionally and at what scale?
We use it. My opinion? It's crap, people are using it as a wrapper around SSH. >idempotency is a meme, you end up running commands instead of relying on Ansible galaxy abandonware >jinja2 templates are good but you shouldn't be using ansible bloat for this >it's verbose as frick, it takes like 5 lines to register a variable from the command output, 15 lines to loop over this variable, there isn't even a straight forward println() function and there are so many subtle bugs around escaping and expansion, it sucks >it's dog slow around everything and almost impossible to automate tests with it
I'm thinking of recreating Ansible with zero bloat and let people use the 2 things that actually want, jinja2 and ssh/remote connection manager. But ansible is another bloated DevOps tool like terraform and kubernetes.
>But ansible is another bloated DevOps tool like terraform and kubernetes.
I did a data lake provisioning with TF and now I have to do a pipeline for some machine learning shenanigans.
I'm seriously considering going for just shell scripts that interact with the cloud's CLI just avoid dealing with TFs HCL syntax and constant changes to the providers.
I do, and it's painful + slow. End up having to just write python modules in the end for a lot of stuff if you actually care about doing things at scale in a timely fashion.
funny, thought they were more. (medium public sector entity)
it ain't that bad, but our playbooks are full of shell statements because figuring out the specifics of lineinfile and friends and dealing with the hell that's yaml is a pain anyway.
I use it at work to manage around ~70 Linux servers. Mostly use it for user mangement, adding the VM to our monitoring and installing / updating the container engine.
used it for network automation in a $BIGCORP. Render config templates for new builds, make changes across hundreds of sites and devices, scrape config data for analysis, compliance, inventory and other reporting etc.
I used it at work, and hated every moment of it. You're programming in yaml, which is an ultimate moronation. Brainlets are still using it to this day.
Don't be a moron, use nixos for truly reproducible infrastructure.
I used to use it when I was managing VMs more. Now if I'm managing a VM I go the packer route. I do more container management now.
>I do more container management now.
Which is the set route in the future anyway. Frick VM based computing, just send it all to container heaven.
for provisioning it's fine, but for long term managing it's not that great
We just use bash and pssh and pscp on thousands of baremetal servers instead of any of this trash. If you can’t write bash well we don’t hire.
>We just use bash and pssh and pscp on thousands of baremetal servers
That's fricking moronic beyond belief, but just moronic enough to make me believe that there's an actual company out there doing exactly that
>on thousands of baremetal servers
In what century are you living right now, anon?
tfw nehalem cores lmao, no Unrestricted Guest cpu feature lmao
I used it extensively to provision and manage thousands of bare metal boxes. It was fricking awful. Writing it sucks, running it sucks, debugging it sucks, literally nothing about it is good. It's slow as frick unless you do all sorts of complicated shit to make machines run plays against themselves, and even then it's much slower than just using a bash script.
Good for somewhat straightforward deployment orchestration and replacing people who can only follow a runbook with automation.
Using it at scale in place of something like Puppet, Chef, or Salt is a fools errand and will leave you in tears.
Everything that is good about it for doing simple stuff (no agent, it's just yaml bro, no central server, just runs with ssh credentials) in practice works against it at scale for doing real config management.
If your systems are roughly immutible and you can let ansible set it up the first time and then not touch them again except for re-deploy it can be fine. But you don't want to try and manage much more than a few hundred nodes with ansible in push mode.
Pull can maybe be done, but it kind of sucks for different reasons.
The language itself is great if you are doing relatively straight forward stuff (install this package, run this command, wait for port, restart this thing, write this file, etc)
The moment you get out of that scope things become a fricking mess. You end up with horrible hacks trying to make a markup language act like a real language and it's suffering.
>You end up with horrible hacks trying to make a markup language act like a real language and it's suffering.
This. I have gotten in many fights trying to prove that Ansible fricking sucks. It's fricking Yaml for crying out loud. THEY USED PYTHON TO MAKE SOMETHING 100 TIMES SLOWER THAN PYTHON, AND THEY REPLACED THE ELEGANT SUCCINCT SYNTAX OF PYTHON WITH FRICKING YAML THAT TAKES 10 LINES FOR AN ASSIGNMENT AND HAS 2 BUGS PER LINE THAT WILL BITE YOU ON PROD DEPLOYMENT. FRICK THIS.
>How many of you actually sue this professionally and at what scale?
We use it. My opinion? It's crap, people are using it as a wrapper around SSH.
>idempotency is a meme, you end up running commands instead of relying on Ansible galaxy abandonware
>jinja2 templates are good but you shouldn't be using ansible bloat for this
>it's verbose as frick, it takes like 5 lines to register a variable from the command output, 15 lines to loop over this variable, there isn't even a straight forward println() function and there are so many subtle bugs around escaping and expansion, it sucks
>it's dog slow around everything and almost impossible to automate tests with it
I'm thinking of recreating Ansible with zero bloat and let people use the 2 things that actually want, jinja2 and ssh/remote connection manager. But ansible is another bloated DevOps tool like terraform and kubernetes.
>But ansible is another bloated DevOps tool like terraform and kubernetes.
I did a data lake provisioning with TF and now I have to do a pipeline for some machine learning shenanigans.
I'm seriously considering going for just shell scripts that interact with the cloud's CLI just avoid dealing with TFs HCL syntax and constant changes to the providers.
im too cool for that crap, i use powershell
It's cancerous. It's like 5x loc compared to bash/ssh. People at my workplace abuse the shit out of it.
>Got a random server with a bunch of shit already installed? Just run some playbook until it werks (it doesn't work)
I do, and it's painful + slow. End up having to just write python modules in the end for a lot of stuff if you actually care about doing things at scale in a timely fashion.
I know Cinemark uses this to update all their servers every month.
Yes I use it. Kinda janky and annoying to set up, but I like it.
$ wc -l /etc/ansible/hosts
97 /etc/ansible/hosts
funny, thought they were more. (medium public sector entity)
it ain't that bad, but our playbooks are full of shell statements because figuring out the specifics of lineinfile and friends and dealing with the hell that's yaml is a pain anyway.
I use it at work to manage around ~70 Linux servers. Mostly use it for user mangement, adding the VM to our monitoring and installing / updating the container engine.
used it for network automation in a $BIGCORP. Render config templates for new builds, make changes across hundreds of sites and devices, scrape config data for analysis, compliance, inventory and other reporting etc.