Is Ansible even useful these days?
It seems like it's only useful for guys who operate a bunch of VMs with a star wars based-naming scheme who gets a thrill when he gets to use it to add a local user on Anakin.
It just seems like a big sink of wasted time and effort compared to say containers + terraform.
I just inherited a giant mass of ansible which was used to manage cloud resources in Azure of all things. Not even VMs. What in the hell. This shit is completely useless, inconsistent, out of date, and to top it off the guy who made it committed every secret in the company to the git repo.
I just don't like it.
It has its uses.
There's a shitton of VMs here and it does automated monthly system updoot (because ITsec said so).
Which means : turning the monitoring off, turning that piece of shit java software off, updooting software, rebooting, monitoring on again.
And then you got custom playbooks because some pieces of shit are in clusters, and all managed with AWX.
It also can be useful for the creation of VMs (standard parckages and corpo config…) and automating software that doesn't updoot by itself… or I shit you not, need 20+ steps in a terminal to unzip, move, stop, start stuff… (no they don't offer a rpm or deb package).
Yeah, I can see how it's actual useful. I've written a fair bit myself.
I'm just having a rant because of this mass of ansible I got handed over
Shell scripts do all that better. I hate zoomers.
No they don't. Shell scripts don't collect the level of "facts" trivially like Ansible does and ansible does it in a "cross platform" way. You'll need to write your own Linux syscalling binaries if you want to collect the same information in a trivial, sane and cross distro way. Says absolutely frick all for winshit, gayOS or cucklicenseBSD, but most everyone is probably using Ansible for Linux only anyway.
Also I still hate ansible, but that's not the point. Shell trannies are delusional and honestly I think powershell is probably better only because at least powershell lets you do win32 calls right in the shell. I suppose you could write stubs in bash and call out GCC, but that assumes a lot of details. Ideally shells would be forced to actually expose more libc like features, but that's asking too much from such a shitty ancient software.
powershell is a million times better than linux shells
using linux shells feels like banging rocks together compared to powershell
>yeah bro just use windows to manage linux
LOOOOOOOOOOOOOOOOOOOOOOOOOL
>yeah bro just use a worse ansible
LOOOOOOOOOOOOOOOOOOOOOOOOOL
I have strongly mixed feelings on this. I see powershell's potential, but most of it comes from basically being dotnet and being able to compile dotnet stubs that can call C-like or system .NET assemblies.
Bash is pretty dumb overall, but if you can make guarantees like having: GNU findutils (includes xargs), grep, awk, sed and coreutils, you're mostly ok for most all appropriate shell use cases.
Not sure if moronic or merely pretending.jpg
holy frick you're dumb
You must be 18 or older to browse this site. Go poo in your dedicated shitting street near your village school, pajeet, not in this thread.
config management has been around since the 60's, are you fricking moronic?
holy frick you're dumb. are you even out of college yet?
Ansible is a mixed bag. I've been using it pretty much exclusively every day for over a year to manage a few dozen bare metal servers and virtual guests. It took me a lot of iteration to get it in a place where its ergonomic and easy for other devs to use. Its super powerful and has by far the best community support out of any configuration management solution, besides maybe Terraform, which I don't put in the same category.
There are a lot of pain points with it though:
- Debugging anything with jinja expressions is... infuriating.
- Debugging custom Python plugins is... infuriating.
- Writing complex logic in YAML is... infuriating.
Overall I find the best way to use Ansible is use it as a way to pair hosts with configuration. Keep playbooks simple, put most of your logic in roles, and the minute you're looping over arrays to build different data structures to pass to a module, write a python or modules. Working with Python in Ansible land can be a huge pain in the ass, for example, there's no good, non-hacky way to share code across plugins. Python errors are obscured by some bullshit Ansible message that doesn't actually tell you what's wrong, but anything is better than getting some moronic jinja error with absolutely no hint as to where in the fricking string it is. "You passed the wrong data type into this filter you use 20 times, frick you if you wanna now which call though!"
While very frustrating, when it works, its fricking incredible. I have a dozen prometheus collectors that need a new job? Update one line in my config, run a playbook, and you're done.
I plan on starting my own configuration management solution soon where I try to correct all the pain points I have with Ansible. Goal is keep it as simple as possible with a really great dev UX. I just need to try salt first because that apparently does a lot of things better than Ansible, but has had stalled development and less community support.
nixos is just better than Ansible. it's that simple.
you've clearly never worked in a real environment with multiple server, or even hundreds or thousands. you nix idiots are so fricking dumb and inexperienced it's funny
>t. never used nixops or just pull nixos derivations in a timed task.
you delusional morons don't realize how good it is to have everything be repeatable perfectly with proper full dependency tracking.
you've clearly never worked in a real environment with multiple server, or even hundreds or thousands. you nix idiots are so fricking dumb and inexperienced it's funny
Neither have you, or you're such a delusional man baby b***h you think your way, that's provably inferior, is correct.
Don't @ me again, RH cuckold.
The irony is your own RH weenies recognized the superiority of NixOS and implemented the whole ostree library, but then cucked it with being just a "library" and encouraging the broken FHS brain damage.
>just learn a language to configure your server bro
no thanks
>just use this thing that has no stars / forks / commits on github anywhere compared to ansible bro
LOL
>He thinks ansible isn't a programming language itself.
NixOS is at least a turing complete ML-like programming language. Ansible is some fake garbage built on yaml grammars with insane semantics. Also ansible is turing complete as well.
literally the only good use I found for Ansible was deploying Tinc to a bunch of EL7 machines I have ssh access to. that's about it. I wouldn't use it for anything more general than that.
My servers have a Lord of the Rings based naming scheme actually
Not everything is cloud. There are still plenty of datacenter + dedi boxes and vms without container orchestration running in corporations. Because regulations or skittish customers make it hard to use the cloud. Or because they have compute-heavy work where the Amazon tax makes cloud a bad choice.
If you have large enough dev teams then some ansible scripts to setup their WSL or linux env might even be useful.
If you think Ansible is bad you haven't seen Chef
if you think chef is bad you haven't seen nix
I've seen Nix, Nix-shell, NixOS, Guix, Ansible, Chef, Puppet and SaltStack, and it's all unnecessarily complicated.
really? then what do you use to configure all packages, files, folders, users, and code on thousands of machines? enlighten me
Powershell DSC
but then you're basically using "ansible but worse"
It depends on the workplace. One company will want Saltstack, another one Chef, another one Ansible, another one Puppet - all for different reasons. Currently I'm in a company that does things with Ansible and I'm glad I'm not the poor sod that has to support it. I do something else - Bazel. Also we dropped Nix-anything like a hot potato due to security issues. Well, more like, nobody wants to be the ambassador of Nix's side of security issues inside the company.
>I do something else - Bazel
oh jesus, anon, I'm so sorry
What do you mean?
Didn't crash for us, just needed a metric frickton of security clearances to download things that weren't from GitHub and you needed to compile it all, because of course the Nix binary repo isn't on GitHub
>nix
>crashes
My devenv bootstraps via ansible. I can switch PCs and VMs all day long and it'll always be the same.
I used it, but I'm still kinda confused at how to organize it. There's a shit ton of documentation, almost too much it feels like. It need a section of documentation for "small company that wants to move beyond shell scripts"
nothing. terraform + packer + literally any config managment is basically end state. nix adds nothing at all except a giant headache
nix is for tinkerers, it targets the same sort of people who spend weeks setting up their vim configuration to be just right.
nix users literally do not have jobs. you can tell by what they say, they make themselves very obvious
job cucking morons like you are the lowest information shitposters on IQfy. I in fact have a job and deploy properly layered nixos derived container images to k8s all the time.
you people are just baby duck shitters who don't know how your shit works or how to build workable systems.
and before some shitter (You)'s me again or mentions me indirectly:
before NixOS, I use to run buildroot forks to accomplish a lot of the same goals because I'm not a moron and want trustable, repeatable builds from source of all my software. I don't necassarily care about reproducible as most the time that quality is generally removing specific dynamic information from binaries, like timestamps of builds, commit, authorships and other weird stuff. It doesn't seem to matter practically. Things like WebPKI alone can make it hard to be testable and reproducible.
honestly depends. US Government has autismal requirements on "SBOMs" for secure room stuff, but most the time it's poorly enforced and basically based on vendors signing off indemnity endlessly and washing their hands of it while they use shit like Eclipse Temurin container images for OpenJDK JRE and other vaguely opaque and public images.
sadly I use it for all of our server builds with terraform and to apply CIS hardening and its a pain the ass.
>committed every secret in the company to the git repo.
you realize you can get it to prompt you for secrets?
>- hosts: dynamically_created_group
> vars_prompt:
> - name: administrator_password
> prompt: Password for [email protected]
> private: yes
>What would NixOS add to this stack?
repeatable builds and an actual SBOM, especially if you enforce source only provenance.
what's the use case for this?
docker build is repeatable
source provenance?
prove it isn't
We already get reproducible builds and a SBOM with the aforementioned stack. Those two things are not unique to NixOS.
its great
using it to manage metal with vms running on it with some storage on the side.
sharing a number of roles with a coworker who manages a bunch of VMs in a different env.
getting started takes a while, especially learning what "feels good" and what doesnt.
pulling in machines that have been managed by hand before is a lot of tedious work.
but once you grasp jinja, how to deal with defaults and handlers and how to unify your sandbox/dev and production and only separate by group_vars combined with dynamic inventory and custom fact scripts it does go very hard
https://github.com/NorfairKing/nix-does-not-guarantee-reproducibility
nix isn't even reproducible, so why are shills pushing it so hard on this board 24/7? hmmmmm
Your nix derivations can be as reproducible as every other distro. It's not worth it though. If you're doing binary distribution, then it matters. Otherwise either your compiler is subtly different than the author's or your code is full of dynamic build time generated shit and it will never be reproducible. Also, when I use nixpkgs I read the actual definition and never use hydra builds.
ok Eelco, we don't care and we're not using your gay system lol
I don't get puppet/ansible. They seem like really complicated ways of achieving a very simple thing.
You have this complicated bag of spiders declarative configuration with a bolted on scripting system that takes in all these semi-black box "community" plugins to manage apache, php, mysql, etc. and this pile of fragile chaos installs and configures you servers as described in theory, but mostly as the plugin author believes is "aesthetic" for his work. And missing features and hack jobs to get your specific use case working is the order of the day.
Vs. just having linux VMs that you can provision with a provisioning file and then you scp across a shell script that has your final bunch of apt installs and an rsync to get all your /etc and user data across.
Seems much easier to me. And less prone to failure. You don't need to debug a bunch of puppet forge nonsense when you move to ubuntu 24.04 because the fragile system all breaks. You simply update your master copies and go.
Containers have gone full moron with infrastructre-as-code and fair play to them, but for them it's a solution to a problem they created, for bare metal and regular VM users it's a problem we don't have.
Pretty much all I use it for is setting up meshed software because I already wrote the code for it. It's god awful imo and I don't know why anyone would use it. If you assume a viable python interpreter exists, you can just as easily assume you can probably build a static linked (musl) binar(ies) that can do all the same tasks without the fake and gay yaml scripting language ansible expects you to use. Maybe if ansible could be used like a python library, I'd care but they still mark the "Python API" for internal use only.
I've had some luck replacing some of my shit with nushell musl builds but it's kind of memey. Honestly I'd rather all the machines were NixOS instead because you literally can just git pull and nixos-rebuild switch --flake '.#muhconfig' and be done with it.
Idiots can't easily mutate NixOS and if they do, they break it anyhow. All service configs in one source tree, etc. I've literally seen nothing like it in Linux. Not even kickstart for red hat distros is this complete and ansible is incredibly error prone at keeping configurations in sync. I've seen shitty ansible artifacts in various config files because the idiot's regex wasn't correct so the config change isn't idempotent. Anyhow frick Ansible.
>Vs. just having linux VMs that you can provision with a provisioning file and then you scp across a shell script that has your final bunch of apt installs and an rsync to get all your /etc and user data across.
you think this is good because you've never managed a real environment with many real working servers. go to any work place and float this idea. you'll be laughed out of the company. you don't have real world professional experience managing servers. managing a personal server at home isn't the same as managing real serious server in a company making actual money
>but for them it's a solution to a problem they created
you just admitted you don't understand what problem containers even solves.
>for bare metal and regular VM users it's a problem we don't have.
you don't even know what the problem is
I don't want to update shit I want to shoot it in the head and make a new one. Ansible is gay.
>be ansible
>61.2k stars
>initial release: 2012
>be nix
>10.9k stars
>initial release 2003
end of story