Comment

Comment on After 1.5 years of learning selfhosting, this is where I'm at

<- View Parent

xantoxis@lemmy.world ⁨5⁩ ⁨months⁩ ago

Sure, I mean, we could talk about

dynamic inventory on AWS means the ansible interpreter will end up with three completely separate sets of hostnames for your architecture, not even including the actual DNS name. if you also need dynamic inventory on GCP, that’s three completely different sets of hostnames, i.e. they are derived from different properties of the instances than the AWS names.
btw, those names are exposed to the ansible runtime graph via different names i.e. ansible_inventory vs some other thing, based on who even fuckin knows, but sometimes the way you access the name will completely change from one role to the next.
ansible-vault’s semantics for when things can be decrypted and when they can’t leads to completely nonsense solutions like a yaml file with normal contents where individual strings are encrypted and base64-encoded inline within the yaml, and others are not. This syntax doesn’t work everywhere. The opaque contents of the encrypted strings can sometimes be treated as traversible yaml and sometimes cannot be.
ansible uses the system python interpreter, so if you need it to do anything that uses a different Python interpreter (because that’s where your apps are installed), you have to force it to switch back and forth between interpreters. Also, the python setting in ansible is global to the interpreter meaning you could end up leaking the wrong interpreter into the role that follows the one you were trying to tweak, causing almost invisible problems.
ansible output and error reporting is just a goddamn mess. I mean look at this shit. Care to guess which one of those gives you a stream which is parseable as json? Just kidding, none of them do, because ansible always prefixes each line.
tags are a joke. do you want to run just part of a playbook? --start-at. But oops, because not every single task in your playbook is idempotent, that will not work, ever, because something was supposed to happen earlier on that didn’t. So if you start at a particular tag, or run only the tasks that have a particular tag, your playbook will fail. Or worse, it will work, but it will work completely differently than in production because of some value that leaked into the role you were skipping into.

source

Sort:hotnew top

notfromhere@lemmy.ml ⁨5⁩ ⁨months⁩ ago
Dynamic inventory. I haven’t used it on a cloud api before but I have used it against kube API and it was manageable. Are you saying through kubectl the node names are different depending on which cloud and it’s not uniform?

I’ve tried ansible vault and didn’t make it very far… I agree that thing is a mess.

Thank god I haven’t ran into interpreter issues, that sounds like hell.

Ansible output is terrible, no argument there.

I don’t remember the name for it, but I use parameterized template tasks. That might help with this?

I think this is due to not a very good IDE for including the whole scope of the playbook, which could be a condemnation of ansible or just needing better abstraction layers for this complex thing we are trying to manage the unmanageable with.
source
- xantoxis@lemmy.world ⁨5⁩ ⁨months⁩ ago
  Really all of these have solutions, but they’re constantly biting you and slowing down development and requiring people to be constantly trained on the gotchas. So it’s not that you can’t make it work, it’s that the cost of keeping it working eats away at all the productive things you can be doing, and that problem accelerates.
  
  The last bullet is perhaps unfair; any decent system would be a maintainable system, and any unmaintainable system becomes less maintainable the bigger your investment in it. Still, it’s why I urge teams to stop using it as soon as they can, because the problem only gets worse.
  
  source
  - notfromhere@lemmy.ml ⁨5⁩ ⁨months⁩ ago
    You urge teams to stop using it [ansible?] as soon as they can? What do you recommend to use instead?
    
    source
    xantoxis@lemmy.world ⁨5⁩ ⁨months⁩ ago
    Well people use ansible for a wide variety of things so there’s no straightforward answer. It’s a Python program, it can in theory do anything, and you’ll find people trying to do anything with it. That said, some common ways to replace it include
    
    you need terraform or pulumi or something for provisioning infrastructure anyway, so a ton of stuff can be done that way instead of using ansible. Infra tools aren’t really the same thing, but there are definitely a few neat tricks you can do with them that might save you from reaching for ansible.
    
    Kubernetes + helm is a big bear to wrestle, but if your company is also a big bear, it’s worth doing. K8s will also solve a lot of the same problems as ansible in a more maintainable way.
    
    Containerization of components is great even if you don’t use kubernetes.
    
    if you’re working at the VM level instead of the container level, cloud-init can allow you to take your generic multipurpose image and make it configure itself into whatever you need at boot. Teams sometimes use ansible in the cloud-init architecture, but it’s usually doing only a tiny amount of localhost work and no dynamic invetory in that role, so it’s a lot nicer there.
    
    maybe just write a Python program or even a shell script? If your team has development skills at all, a simple bespoke tool to solve a specific problem can be way nicer.
    
    source
    -> View More Comments