[HN Gopher] Ansible Techniques I Wish I'd Known Earlier
___________________________________________________________________
Ansible Techniques I Wish I'd Known Earlier
Author : oedmarap
Score : 225 points
Date : 2021-08-27 13:42 UTC (9 hours ago)
(HTM) web link (zwischenzugs.com)
(TXT) w3m dump (zwischenzugs.com)
| mccoyc wrote:
| Another one for the list is `--start-at-task` and `--list-tasks`,
| for those tasks that are statically imported. If you have a task
| bomb out, you can take over from where you left off. Doesn't work
| in all playbooks, if facts need to be set earlier, but it's still
| very useful and saves tons of time. Obvious, but I wish I knew
| that one earlier too.
| avaika wrote:
| I'm using ansible for some years already. The biggest game
| changer for me was ansible molecule [0].
|
| I integrated it to the repo, where I store my code and it just
| runs all the test cases for my code. It saved me a bunch of hours
| of investigation in test environments before I even released the
| code. Highly recommend to try it even for a small project.
|
| Apart of that play with ansible strategies if you have more than
| one server to apply the role. It really might save you some
| minutes of a runtime.
|
| [0]: https://molecule.readthedocs.io/en/latest/
| willejs wrote:
| This is really great advice. Chef was doing this years ago with
| test kitchen and inspec (and serverspec). Most community
| cookbooks came with extensive test suites, and in turn made it
| easy to encourage people to write tests for cookbooks in house.
| It seems theres a real lack of testing in opensource Ansible
| playbooks a lot of the time, and a lot of times when I see it
| used in organizations.
| usrme wrote:
| It's a damn shame it took until this article for me (and it
| appears some others) to learn about the console and the debugger;
| those seem like massive time savers! My own biggest helper has
| been to use "ANSIBLE_STDOUT_CALLBACK=yaml" wherever "ansible-
| playbook" is called (https://jpmens.net/2021/03/12/alter-ansible-
| s-output-on-debu...). It makes the verbose output much more
| readable and is especially handy for tasks that can spew
| thousands of lines at ones (e.g. "apt update/upgrade").
| rakshazi wrote:
| ansible-console is a treasure! I wish I saw that article years
| ago...
| amanzi wrote:
| The `--step` flag will definitely be useful for me, didn't know
| about that.
|
| My one tip I'll add is to use the `--diff` argument when running
| a playbook to print out the specific changes made for each step.
| For debugging, use `--diff --check` to see all the changes that
| will be made - useful if it's been a while since you last run
| your playbook over a host.
| gizdan wrote:
| Ansible is abysmal. I don't know why anyone still chooses it.
| It's a mess of yaml and what feels like a million yaml files that
| is always extremely hard to follow. Honestly writing some python,
| or bash is a lot easier to follow, read, and understand. The only
| thing it has going for it is the inventory system. I wish ansible
| would die already.
|
| The tips mentioned in the article are helpful, but still beyond
| the initial development of roles, maintaining roles is a pain no
| one can alleviate. It is the perl of automation. I wish people
| would stop using it. I've yet to start a job where people haven't
| regretted going towards ansible.
| dialogbox wrote:
| Do you have any suggestions on good set of sdk or library for
| writing those automations in python? The main reason for using
| ansible for me was always because of their rich built in tasks.
| I tried writing in python my automations but even very simple
| tasks were needed too much effort compare to ansible so I had
| to return back.
| _red wrote:
| >bash and python
|
| Neither of those of idempotent.
|
| It seems likely you are coming at this from the perspective of
| "when I find an ansible playbook on github its hard to follow
| whats going on".
|
| There is a certain truth to that, but much of its complexity is
| probably related to said playbook developers trying to abstract
| away specifics and create a playbook that works on a variety of
| distributions / configuration options.
|
| Ansible can be as simple as a single file that proceeds
| sequentially like a bash script.
| voidfunc wrote:
| Most of the ansible roles I come across written by my team
| are not idempotent either, its a huge lie that Ansible is
| idempotent. Its idempotent if you put the effort into make it
| be but if I see tons of shell or command module invocations
| without prerequisite checks to see if the work should be
| done. Most devs I see using Ansible treat it like a shell
| script written in YAML and to that purpose it sucks.
| quadrifoliate wrote:
| > >bash and python
|
| > Neither of those of idempotent.
|
| There is nothing magical about Ansible that makes it
| idempotent by default either.
|
| The simple stuff like having specific versions of a package
| installed that you might be thinking of is just using Python
| under the hood. If you get into more complicated stuff,
| especially around custom infrastructure abstractions you use
| internally, guess what, you will have to write a bunch of
| Python and effectively call it from Ansible. And you will
| have to put in extra effort to make sure it's idempotent.
|
| At which point you start thinking...why not just write a
| Python script instead? At least that gives you _all_ of the
| flexibility.
| gizdan wrote:
| > It seems likely you are coming at this from the perspective
| of "when I find an ansible playbook on github its hard to
| follow whats going on".
|
| No, I've worked with ansible over 3 jobs, for the past 4
| years. It hasn't been hard to convince colleagues to move
| away from Ansible once I show the competition. Sadly the
| migration process is rarely easy.
| notabee wrote:
| Yes, it can get hairy but I just have a hard time seeing an
| adhoc mess of python and bash doing the equivalent amount of
| lifting without becoming an even bigger hairball. And the
| thing is, you can also just run those same bash and python
| scripts using Ansible if you really want to, just to keep
| them orchestrated properly.
| corty wrote:
| Maybe a stupid redundant slightly offtopic question, but I'll ask
| anyways:
|
| What is the best way to couple Ansible with some git repository
| to automatically apply changes while still being able to trace
| and debug?
| xorcist wrote:
| Tower? Open sourced by Red Hat as AWX, it is a central Ansible
| hub for exactly that purpose.
| edaemon wrote:
| This definitely isn't the best way because it's far from
| painless, but we use GitHub Actions to run some Ansible
| playbooks. When there's a problem that needs debugging we add a
| tmate[0] session with mxschmitt's action[1] so we can step
| through the playbook, etc.
|
| [0]: https://tmate.io/
|
| [1]: https://github.com/mxschmitt/action-tmate
| Datagenerator wrote:
| Or Jenkins pipelined steps which might include setting up the
| pipenv to include the setup of Ansible in your git as
| requirement file. So it starts with Groovy and switches to
| Ansible etc
| ratorx wrote:
| Ansible doesn't have the right model for painless auto
| application, because it's only idempotent in some cases and not
| others (e.g. removing config).
|
| It's a good tool to set up a server from scratch to a desired
| state, but not to go between two versions of desired state. So
| a git-based deployment workflow is doomed for failure as soon
| as you start actually using the history (or removing config).
| notabee wrote:
| We've been using the git module to pull down the desired
| version of the repo and then using synchronize to copy it
| over. That could be used to overwrite whatever was previously
| being copied from the git repo. So, can you explain where
| that doesn't work for a git based deployment? It's a pattern
| we use a lot. (A slight tangent though, systemd-tmpfiles can
| ruin your day if it partially deletes the repo, because that
| makes the git module crap out.)
| WFHRenaissance wrote:
| Build/Buy a real CI/CD system for this TBH. Once you hit a
| certain level of complexity, this sort of deployment strategy
| will mostly just amplify pain.
| whirlwin wrote:
| I have used Ansible for some years. I recently switched jobs to a
| company having no automation on VMs. And we are migrating our
| workload to managed services in the cloud (managed Kubernetes), I
| have to say I'm relieved I don't have to deal with Ansible again.
| It's probably very efficient in many ways, but just copying a
| file/directory with the correct options is a bit of pain in
| Ansible. Having not to worry about VMs anymore is a huge win for
| me at least. /OffTopicEnd
| yjftsjthsd-h wrote:
| > just copying a file/directory with the correct options is a
| bit of pain in Ansible.
|
| How so? Do you mean you had trouble remembering what arguments
| to pass to the copy module? (I'm not sure what other options
| there are to be a pain)
| linsomniac wrote:
| Gotta try that console and debugger, those weren't even on my
| radar!
| kimbernator wrote:
| Unfortunately, console appears to be effectively ignored by the
| developers and it's pretty obvious when you're in it. There's
| just a lot of things that you can't do. It's a shame, too,
| because ansible is particularly frustrating to write for me
| coming from chef where everything is written in pure ruby and
| the REPL is basically just IRB with some extra stuff. Having an
| interactive environment to see how the data I'm handling is
| being transformed would be helpful, but ansible-console just
| doesn't do what I need most of the time.
| thibaut_barrere wrote:
| These are both great. I still have an issue with console for
| things requiring a sudo access, for some reason, but it is
| still very handy!
|
| Another trick I use routinely is this, to display a given
| variable across all hosts:
|
| ANSIBLE_STDOUT_CALLBACK=json poetry run ansible all -m debug -a
| var=vault_ssl_cert | jq ".plays[0].tasks[0].hosts"
| zwischenzug wrote:
| Nice, I might steal that for part II...
| mrweasel wrote:
| Me neither, but they are certainly something I can use.
|
| I still lack something that will tell me where a variable is
| sourced from.
| reilly3000 wrote:
| I wish I had read this a couple of weeks ago. I am new to Ansible
| but needed to use it to migrate a legacy system. I'm not really
| accustomed to long build times and kept running out of things to
| do in the interim while I was waiting for it to break.
| c7DJTLrn wrote:
| At work we use Puppet and I have to say that although the DSL is
| much more expressive and nicer to use than YAML, Puppet's tooling
| sucks in comparison. There isn't really any way to test your
| Puppet code that I know of, you just have to apply it and check
| if it all looks good. Puppet doesn't have a set of good practices
| established either. Different companies use completely different
| repository structures, compiler settings, linter settings.
| Modules for managing common software like Docker are low quality
| and riddled with issues.
|
| Ansible and Puppet claim to be declarative but it's a lie.
| Configuration management really needs a rethink. I know Nix
| exists but that has a huge barrier to entry and companies don't
| want to use something that isn't battle tested. In my view, the
| ideal config management tool would be fast, testable, and
| provably idempotent. It would also be as far away as possible
| from the Python/Ruby swamp that Ansible and Puppet are stuck in.
| zatarc wrote:
| https://puppet.com/blog/unit-testing-rspec-puppet-for-beginn...
| inshadows wrote:
| Puppet is declarative, isn't it? You declare states and
| relationships, and it computes plan of action.
|
| Ansible is not declarative at all though, and it's not even
| funny how almost every fan says it is. It's just a sequence of
| actions.
| c7DJTLrn wrote:
| Sadly, no. Puppet masquerades as being declarative just like
| Ansible does. It's very easy to get into a situation where
| your Puppet class is just a fancy shell script which works
| the first time and then fails because a file doesn't exist or
| something. There is nothing to lint for this or to protect
| against this.
| LIV2 wrote:
| At a previous job we used beaker tests as part of our
| pipeline to test puppet modules & environments before we
| would merge to prod. One of the things this tests is that
| the module applies and doesn't try to change anything /
| error out on subsequent runs.
|
| The documentation sucks though imo, every different guide
| you find will show a completely different way of doing it
| moreati wrote:
| Over the years I've tweeted Ansible tips, and Ansible Gotchas for
| my own memory and others
|
| https://twitter.com/search?q=from%3Amoreati%20ansible%20tip&...
| https://twitter.com/search?q=from%3Amoreati%20ansible%20gotc...
___________________________________________________________________
(page generated 2021-08-27 23:00 UTC)