this post was submitted on 26 Jan 2024
197 points (95.8% liked)

linuxmemes

21192 readers
151 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.

  • Please report posts and comments that break these rules!

    founded 1 year ago
    MODERATORS
     
    top 50 comments
    sorted by: hot top controversial new old
    [–] azvasKvklenko@sh.itjust.works 23 points 9 months ago (1 children)

    I love Ansible while hating when people touch it. Yes, it’s very flexible but at what cost? If you actually learn it and follow some basic guidelines, you can make beautiful playbooks and inventories having wonderful automation for even complex setups while keeping it clean. But if one doesn’t care and just try to make servers go brrr, it becomes horrific glorified shell script with everything hardcoded, most tasks unaware of changes they make, cesspool of shitty templates, breaking itself in minutes, being pain to work with and making me want to delete all the shit and start all over.

    [–] Technus@lemmy.zip 11 points 9 months ago (3 children)

    I decided I wanted nothing to do with Ansible when I was half an hour into reading the website and I still didn't have a fucking clue what it is or exactly what it does.

    To this day, I couldn't really tell you. It seems to be basically a framework for automatically SSH'ing into machines and running shell scripts on them which doesn't sound robust in the slightest. It's like they took thirty years of sysadmins' discarded spit-and-duck-tape solutions and bundled them into a "framework".

    I dunno how the fuck you're supposed to manage cloud infrastructure at scale with that.

    [–] MigratingtoLemmy@lemmy.world 6 points 9 months ago (2 children)

    Terraform for day 0 operations is a better experience but it had its quirks. Ansible is nice when it's done well, but when you don't have an Ansible module for something, you're essentially writing a shell script

    [–] azvasKvklenko@sh.itjust.works 3 points 9 months ago

    Or your own module in Python if it gets too complex to do with just Ansible https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_general.html

    [–] Technus@lemmy.zip 2 points 9 months ago* (last edited 9 months ago)

    Yeah, in contrast the value proposition for Terraform was immediately obvious. "Oh, you mean I don't have to manually set up Kubernetes clusters and shit every time we want to deploy to a new region? Fucking sign me up!"

    [–] azvasKvklenko@sh.itjust.works 4 points 9 months ago (1 children)

    It’s far more than just SSHing and running shell scripts. Besides, I wouldn’t ever call it a „framework”.

    It’s a tool for Linux, BSDs and even Windows machine setup automation in a declarative fashion. Tasks are usually built out of wide range of provided modules for both universal actions (like file edits, templating, shell commands) and very specific ones (like Podman containers, Postgres users, indexes in Mongo, whatever you imagine, you can even implement your own in Python). Those tasks have logic that can detect the status for each of the tasks in each specified nodes, so they can not only be applied, but also dry run with precise diff tracking (diff of config files to be applied, packages to be installed, etc).

    It has inventory that can be both static (config file), and dynamic (e.g query an AWS account for Ec2-s or get nodes from Proxmox) that lets you group your however many hosts (by purpose, etc), attach variables to specific hosts or entire groups, or even store encrypted credentials to use them in roles. When dealing with hundreds of hosts, at some point this is something you need to do anyway, but here it really shines even with much smaller amount of machines.

    Ansible can be very reliable and provide awesome environments, but it requires some learning and due to its flexibility, it can also be used badly. I have some success stories with it in last 7 years of utilizing it for both small and big business.

    That being said, if you want some magic hammer that just does stuff without requiring any understanding, Ansible might not be the thing.

    And no, Terraform is not an replacement for Ansible and vice versa. Those two are designed for different purposes. I actually used them together in some projects.

    [–] Technus@lemmy.zip 1 points 9 months ago

    And no, Terraform is not an replacement for Ansible and vice versa. Those two are designed for different purposes. I actually used them together in some projects.

    Yeah, that's the problem. Every time infrastructure management came up, a certain coworker would always bring up Ansible. It eventually got kind of annoying.

    [–] CosmicTurtle@lemmy.world 2 points 9 months ago (3 children)

    Yup. I used ansible for a good year, maybe two, and found myself asking, "Why the fuck am I maintaining some abstract thing when I can just write a shell script and deploy that?"

    Cloud orchestration is better done with other tooling. Honestly don't see a use case for ansible beyond physical data center deployments.

    [–] timbuck2themoon@sh.itjust.works 9 points 9 months ago* (last edited 9 months ago)

    There is a reason ansible exists and is widely used. Shell scripts are brittle and don't account for a ton of use cases.

    For instance- are you going to write a shell script to determine the OS family of a server? Are you then going to do a bunch of if statements for things you want run on Debian hosts vs RedHat ones vs. Alpine? Are you going to manually make templates yourself or just use jinja templates and the template module in ansible (and use variables easily gathered by the setup module)? Are you going to manually select which hosts you're going to target or are you just going to use your ansible inventory that categorizes your machines based on location or purpose or whatever other arbitrary thing and use tags? Are you going to manually dig in and find out how many NICs are in a box, what IPs they have, what CPU, how many cores so you can set some service to use "X" amount of threads, define service templates using those machine variables, etc. etc. etc.? Are you going to make such well defined shell scripts that they can be reused over and over again against a variety of machines without breaking things and make it easy to include them in parent shell scripts?

    This is all stuff ansible does quite easily.

    It's not the end all be all of course. Some would argue (maybe rightfully) that Puppet or Salt can maintain config drift a bit better. I would argue it's not the tool to use for containerization really either. But it definitely has a real purpose in initial and maintained configuration management and in both cloud and on-prem deployments.

    [–] azvasKvklenko@sh.itjust.works 3 points 9 months ago

    Building custom images for cloud can be one. Builtins have a lot of ready to use logic that you might want in your scripts anyway

    [–] darganon@lemmy.world 2 points 9 months ago (2 children)

    They installed it for us at work as part of a project, and we went to ask the ansible guy wtf we could use it for in a windows world, and he couldn't articulate how it would be an improvement in any way over a scheduled task.

    [–] taladar@sh.itjust.works 5 points 9 months ago (1 children)

    To be fair it is not Ansible's fault that Windows does pretty much everything differently from the systems Ansible was designed for.

    [–] darganon@lemmy.world 2 points 9 months ago

    Agreed entirely.

    [–] moonpiedumplings@programming.dev 4 points 9 months ago* (last edited 9 months ago) (1 children)

    It appeals to me for management of a windows machine for a few things:

    • Lots of machines at once, over winrm. Although ssh is the default, as ansible is linux first.
    • I don't have to learn powershell - the shared language means the windows teams and the linux team don't have to learn eachother's language. In ansible, it's very easy to avoid the footguns that come with something like bash, especially after you install the red hat linter, ansible-lint, which warns of ansible's own footguns.
    • easy to version control it
    • premade stuff: the official "modules" are massive and do a lot. There are also community packages: https://galaxy.ansible.com - of course, you should probably check any stuff you run first. But ansible is very easy to read.
    • built in secret management. Encrypt secrets, but still be able to use them smoothly with the automation framework.

    For just one machine? Task scheduler is probably good enough. 2-3 machines, managed remotely? Ansible is at least worth looking at.

    Edit: also, really good docs. Like, check out this active directory module with examples: https://docs.ansible.com/ansible/latest/collections/microsoft/ad/object_info_module.html#ansible-collections-microsoft-ad-object-info-module

    The examples are very helpful, with things like getting a list of ad users. I used that to create a ansible script to shuffle all ad user passwords - while being a a linux lover who hates windows and has literally never touched ad before this.

    https://github.com/CSUN-CCDC/CCDC-2023/blob/main/windows/ansible/testing/users.yml

    https://github.com/CSUN-CCDC/CCDC-2023/blob/main/windows/ansible/roles/domain/tasks/main.yml

    [–] azvasKvklenko@sh.itjust.works 1 points 9 months ago

    Nice, I love it

    [–] MeanEYE@lemmy.world 22 points 9 months ago (8 children)

    I see Ansible as necessary evil. Not requiring server-side installed tools to work is great. But choosing yaml of all things for playbooks is downright vile. So there's nothing casual about administering that many servers and machines, especially with constant warnings about Python version incompatibility.

    [–] Technus@lemmy.zip 12 points 9 months ago* (last edited 9 months ago) (2 children)

    If we ever meet an advanced alien society, I really want to see what solutions they came up with for:

    1. Configuration languages
    2. GUI frameworks

    Because those two areas seem like there will never be a "perfect" solution.

    And to anyone that says "an alien society might be so different that they don't have those things", I think if you've invented computers then at some point you will want some way to configure them, and some way to interact with programs running on them.

    If they navigate programs entirely by sound or some shit, that'd still be interesting to see.

    Watch, it turns out most advanced alien societies just use the terminal.

    [–] Buddahriffic@lemmy.world 4 points 9 months ago

    Then it turns out the reason they are exploring the depths of space is to see if any other civilizations have figured out a better way to handle those things because their current solutions work but kinda suck (along with several other problems we can't yet fathom). And worse, they get excited when you start describing our systems.

    "Wait wait wait, please tell me more about this... stack... that allows you to reuse code with different initial values for variables. That sounds revolutionary!"

    [–] Feathercrown@lemmy.world 1 points 9 months ago

    Excellent observation. I'm honestly surprised there's no well-known "universal parser" for common languages that can handle JSON, YAML, TOML, maybe even some form of XML, etc.

    [–] rtxn@lemmy.world 7 points 9 months ago* (last edited 9 months ago) (1 children)

    I don't particularly like yaml as a data storage language because of its use of significant whitespaces, but for the minimal complexity of my own playbooks, I don't mind it.

    What would you consider to be an ideal language for playbooks?

    [–] MeanEYE@lemmy.world 2 points 9 months ago (1 children)

    Am not sure to be honest. I always liked JSON even though it's very rigid. Even so, most of software I write stores config in JSON simply because it's easy to parse and it's supported by literally everything. It's also pretty minimalist.

    Perhaps something more strict and defined would be better. I think I'd even prefer XML to YAML.

    [–] rtxn@lemmy.world 3 points 9 months ago* (last edited 9 months ago) (1 children)

    You can use JSON to write the playbooks, then use a program like yq (which is a Yaml wrapper for jq) to convert it to Yaml. Something like

    cat playbook.json | yq --yaml-output > .temp_playbook.yml
    ansible-playbook .temp_playbook.yml
    
    [–] MeanEYE@lemmy.world 1 points 9 months ago (1 children)

    I did not know that. That's a useful one. Does it work the other way around?

    [–] rtxn@lemmy.world 2 points 9 months ago

    Yes, both yq and jq are fantastic programs.

    yq can take either JSON or Yaml (or maybe others, I haven't checked) as input, then it converts it to JSON before passing it to jq. yq outputs JSON by default, or Yaml if you pass it the --yaml-output option.

    [–] umbrella@lemmy.ml 6 points 9 months ago (1 children)

    besides the annoying syntax, whats so wrong with yaml?

    its a standard tool used across many different things, id expect it to be adopted.

    [–] MeanEYE@lemmy.world 2 points 9 months ago

    Its syntax is plenty when it comes to "wrong". I've been using it for a while now and I still run into some issue with its formatting, but that of course can only be discovered when you run deployment or provisioning scripts, giving it high chance of pissing me off because it will cause something to be half-configured when it shouldn't be.

    [–] corsicanguppy@lemmy.ca 4 points 9 months ago (1 children)

    You know, for how stale its entire idea is, Ansible isn't bad. I code fucking yaml daily.

    Having said that, It's a generation behind its competition on terms of everything except calendar age. Fuck's sake, it grew from the same incubator that spawned mgmtConfig, which is as better than chef/cinc/salt/puppet as those are better than ansible. It was born with its own grandson, if there was any shared dna.

    Using Ansible is like working with Unfrozen Caveman Lawyer. Each day it grows more clunky, more waddling with the bags on its side, more obsolete. It's the 50-foot coiled rj-12 cable of config management.

    [–] MeanEYE@lemmy.world 1 points 9 months ago

    For us Ansible works and code that we have is getting dated now, but every now and then it does get a little bit of refresh to give it more life but in general you are right. Its bad sides mainly show up when you try to manage older systems or something more exotic. Then python incompatibilities, directories and server side libraries all start showing their ugly side.

    [–] Nomecks@lemmy.ca 2 points 9 months ago (1 children)

    YAML is used across a lot of modern technologies. I would imagine using YAML makes it easier to learn for a lot of DevOps type people.

    [–] taladar@sh.itjust.works 3 points 9 months ago

    And all of them are universally bad. Especially all the Kubernetes tools, Helm is so bad and at least half of it is due to the combination of YAML and templating.

    [–] bluey@lemmy.world 1 points 9 months ago (1 children)
    [–] MeanEYE@lemmy.world 1 points 9 months ago

    Thanks, I'll take a look.

    [–] possiblylinux127@lemmy.zip 1 points 9 months ago

    I love yaml so maybe its just a matter of personal choice.

    [–] Djtecha@lemm.ee 0 points 9 months ago (1 children)

    Isn't all of these tools dying with k8s? Like the entire concept of installing a playform for your service is moot at this point. Plus there's like a million other benifits over bare metal configs.

    [–] MeanEYE@lemmy.world 1 points 9 months ago (1 children)

    Nope. Far from it, especially if you have to adapt to existing structure, like having sites hosted with Plesk or cPanel on some rented hosting service. I've been also using it for easy and fast configuration of embeded devices, like RaspberryPi and similar.

    [–] Djtecha@lemm.ee 1 points 9 months ago

    Sure, legacy exists but as a systems principal engineer I would always look to improve the platform. Puppet/chef/ansible all the problems those solved are kind of moot with a kubernetes ecosystem. The only thing they might be useful for would be installing the software to get those nodes added and maybe security updates in you're running 1k+ of bare metal. And something that could all be solved with something light like dancers shell. At home I've even just moved to k3 since the containerize is just so much more consistent. Ansible not maintaining state is also a massive headache.

    [–] Neon@lemmy.world 14 points 9 months ago (2 children)
    [–] fl42v@lemmy.ml 2 points 9 months ago

    More like nix in general. Unless you need to setup some windows crap

    [–] refreeze@lemmy.world 1 points 9 months ago

    Yeah, it took a while getting deep into ansible hell for me to see the light.

    [–] slazer2au@lemmy.world 5 points 9 months ago (2 children)

    Quick, do another one but with Terraform.

    [–] beeng@discuss.tchncs.de 7 points 9 months ago* (last edited 9 months ago) (1 children)

    Terraform talks to "clouds", where as Ansible talks to devices. Whilst clouds do have many devices, I feel like Ansible has a greater ability to absorb likeness/distinctiveness (ships), over a greater scale than terraform.

    [–] slazer2au@lemmy.world 2 points 9 months ago (2 children)

    Terraform isn't limited to clouds. We use it for our onprem kit.

    [–] taladar@sh.itjust.works 3 points 9 months ago (1 children)

    I don't use Terraform but from my understanding Terraform is more for "what kind of server hardware/VM/container/... do I want" and less "which configuration do I want on that server/VM/container/..."

    [–] slazer2au@lemmy.world 0 points 9 months ago

    Which kinda sounds like the Borg.

    Do we want a drone, an operative, or whatever 7 of 9 is.

    [–] MigratingtoLemmy@lemmy.world 3 points 9 months ago

    Wait how? What do you use? I think I've seen a Terraform connector for Kubernetes but that's about it

    [–] bluey@lemmy.world 2 points 9 months ago* (last edited 9 months ago)

    afaik, terraform does not allow you to manage the state of an OS. Think managing motd file or ensuring certain packages are installed.

    You might like to try out pulumi.

    [–] Cyberflunk@lemmy.world 4 points 9 months ago* (last edited 9 months ago)

    Man... Saltstack is SO MUCH MORE effective at mass management. It's fast AF. Yet... Ansible everywhere.

    [–] 0x4E4F@sh.itjust.works 1 points 9 months ago (1 children)

    Meeh, someone had to do the job 🤷. It's not like there is a more flexible solution out there.

    [–] stardreamer@lemmy.blahaj.zone 2 points 9 months ago (1 children)

    *stares at the intern's 400 line bash script*

    There are totally more flexible options. Just don't mind the front falling off. It's totally normal!

    [–] 0x4E4F@sh.itjust.works 1 points 9 months ago

    400 line... amateur 😒...