7

Oh wow, fuck Ansible

Turns out there is no way to automatically undo the things it did, because surely nobody would ever want to remove software...

Now I have a half fucked server that I can manually clean up again 👍

Comments
  • 2
    I haven't had much experience with Ansible, but when I do it's always this.
  • 4
    It gets cleaned when you buy new hardware anyway
  • 3
    Use Vagrant to raise quickly fresh virtual machines as a code, and mess with them with ansible
  • 2
    Generally, I prefer Terraform because it cleans up after itself. However, setting Ansible state to “absent” before deleting the code helps a lot. Lastly, if your Ansible is good, blow the server out and create a new one with your Ansible.
  • 1
    Since we are pulling high calibers... I prefer just to install small Kubernetes cluster at least at my servers, everything running in it in Docker images, leaving pollution of host to zero

    Even before kubernetes, I started to apply docker/Docker -compose.
    Then all running app instances we can wipe from host with one command and to delete all their dependencies with them

    Technically this is way better solution than using Vagrant and way more modern
  • 1
    https://docs.ansible.com/ansible/...

    Check out the state param...
  • 1
    This is the bad side of maintaining a infrastructure resource state: it’s like a database, there is no way to unfuck depending on the case.

    Containers are not glorified tarballs only, they are the avatar of immutability hehe
  • 2
    Everything's has it's pros and cons.

    I wouldn't trust any form of revert unless it is based on an snapshot mechanism of the filesystem...

    Reverting stuff sounds simple, but there are always caveats - which is exactly why it's not really implementable in a package or configuration manager imho.

    As one example: When a package generates an user id or an group id - does revert mean you delete the user and the group id? If yes, then readding the user or group id would lead to another user or group id for that package ...

    (Unless specific UID / GID is used - but this makes another problem, there aren't that many that can be generated :) )

    If the package had an daemon that generated files, what happens to those files?...
    Just as two examples, the deeper one goes, the more nasty it becomes.

    Use snapshots of the file system or a similar backup technique.

    Ansible is the wrong tool for that.

    But one can combine Ansible in an workflow with an backup / snapshot mechanism... ;)
  • 1
    @IntrusionCM Good points, and that's probably why Ansible can't do it.

    I was and still am planing to implement an ansible alternative myself and my initial thoughts were to differentiate between reversible and non reversible operations. Since non-reversible operations (e.g. deleting a file) are much less common for my planed use cases (I never want to delete something I haven't also created) this would be fine. Then I'd also have a module that you can instruct to keep perfect backups of certain resources which then makes non reversible tasks reversible, but of course manually
  • 0
    @IntrusionCM The thing with uid/gids is quite interesting though... Are the monotonically increasing?
  • 1
    @12bitfloat

    Usually yes.

    I cannot remember exactly the files where it could be configured, but I think somewhere in useradd / groupadd it should be mentioned.

    I think it were the same files to configure the range of system uid / gid and max number of uid / gid...

    Though it's been a looooooooong time that I had to fuck around with that.
  • 0
    @IntrusionCM Well... fuck :D
Add Comment