Ansible 2.10(mail-archive.com)
mail-archive.com
Ansible 2.10
https://www.mail-archive.com/[email protected]/msg53862.html
9 comments
Main change: "Ansible engine" is decoupled from "Ansible content" (modules and plugins).
This is a big deal, and very welcome.
Note that Ansible 2.10 is now packaged two ways: 'ansible-base' ( just the engine and a few core modules), and 'ansible' (not yet released - Ansible base plus a bundle of all the modules and plugins that were in what was before just Ansible 2.9).
Doesn't work?
Secure Connection Failed: Error code SSL_ERROR_BAD_MAC_READ
Secure Connection Failed: Error code SSL_ERROR_BAD_MAC_READ
The direct Google Groups list I think: https://groups.google.com/forum/#!topic/ansible-project/_oKp...
That link seems to require a google account to access. So the mail-archive.com link was rather more useful.
Recently started using this. Works brilliantly for our production infrastructure. Well done to Ansible team.
no no no, it's alpha9, not stable yet!
> 2020-09-22: ansible-2.10 GA release date.
Right! I'm sorry for misinformation!
@dang, could you please rename this to: Ansible-base 2.10.0 released
@dang, could you please rename this to: Ansible-base 2.10.0 released
Love using Ansible (though I don't always love writing YAML).
PROTIP: I use it to manage my laptops/workstations with a hosts entry like:
PROTIP: I use it to manage my laptops/workstations with a hosts entry like:
[laptop-thinkpad]
localhost ansible_connection=local
Another nice trick is to use your shebang line.
#!/usr/bin/env ansible-playbook
---
- hosts: localhost
connection: local
vars:
home: "{{ lookup('env', 'HOME') }}"
tasks:
# ...
pip install -r requirements.txt
./install --tags=bashDeprecated group name format. ;)
I started using Ansible when it was brand new, like 0.2 I believe. It changes so fast that I've had junior co-workers come in and teach me new best practices in Ansible.
I started using Ansible when it was brand new, like 0.2 I believe. It changes so fast that I've had junior co-workers come in and teach me new best practices in Ansible.
First I used debian packages and maintained a (multiarch!) repository to setup my computers, then I used Ansible and had to first install Python and SSH on every machine, now I just run a script and I'm done in a few minutes and very few manual steps.
I found Ansible for personal computers to be brittle and cumbersome as reinstalls are usually for OS upgrades and those tend to have breaking changes.
I found Ansible for personal computers to be brittle and cumbersome as reinstalls are usually for OS upgrades and those tend to have breaking changes.
Someone made the comment below, which can't be responded to, but I did have a question about it. The comment:
> Immutable infrastructure killed Ansible.
I haven't used Ansible in several years, but when I was using it I was using it to build immutable AMIs. So obviously this comment is off base. However, I have been using terraform for years now.
Can anyone describe why one might use Ansible over Terraform? I understand the differences, but I don't think I know people using Ansible as their primary deployment/provisioning solution recently.
> Immutable infrastructure killed Ansible.
I haven't used Ansible in several years, but when I was using it I was using it to build immutable AMIs. So obviously this comment is off base. However, I have been using terraform for years now.
Can anyone describe why one might use Ansible over Terraform? I understand the differences, but I don't think I know people using Ansible as their primary deployment/provisioning solution recently.
> Can anyone describe why one might use Ansible over Terraform?
Anywhere you're dealing with bare metal you can't really use Terraform. Terraform also doesn't get you much within a host, so to speak. One example of that idea, if you use Packer to bake AMIs, with Ansible as the provisioner, you get the simplicity of Packer with the integrated secrets management and templating of Ansible.
Also, not everything is an immutable infrastructure change. Sometimes you just need to do things repeatably against a set of hosts, and Ansible is good at that.
Anywhere you're dealing with bare metal you can't really use Terraform. Terraform also doesn't get you much within a host, so to speak. One example of that idea, if you use Packer to bake AMIs, with Ansible as the provisioner, you get the simplicity of Packer with the integrated secrets management and templating of Ansible.
Also, not everything is an immutable infrastructure change. Sometimes you just need to do things repeatably against a set of hosts, and Ansible is good at that.
The tooling for Terraform with bare metal is poor, but it is out there. There are plugins for MAAS, Cobbler, Some giant HPE thing I never wanted to touch.
If you're willing to write code, I found it a good fit for provisioning servers over ILO/Redfish.
If you're willing to write code, I found it a good fit for provisioning servers over ILO/Redfish.
Good to know, I'll check it out at some point.
I use both in conjunction. There are Ansible modules to run terraform, for example.
The biggest issue for me is that Terraform is still pretty bad at looping and handling dependencies sometimes. They have ways to try to work around it, but sometimes it's much easier to say "Do X, then Y, then Z".
With Ansible, I can explicitly set the step order, and even write a quick module if I need to interface with an external API.
The biggest issue for me is that Terraform is still pretty bad at looping and handling dependencies sometimes. They have ways to try to work around it, but sometimes it's much easier to say "Do X, then Y, then Z".
With Ansible, I can explicitly set the step order, and even write a quick module if I need to interface with an external API.
The kids who grew up with containers are resistant to config management tools.
To me it is a weird regression back to “imaging” machines constructed haphazardly with shell scripts and manual action, it’s just faster.
It makes it difficult to work in the current environment.
To me it is a weird regression back to “imaging” machines constructed haphazardly with shell scripts and manual action, it’s just faster.
It makes it difficult to work in the current environment.
I began using Ansible much before I learnt of Terraform . However , my Ansible scripts have been working flawlessly and the Python plugins and YAML makes it easy for me to figure out what it was that I wrote so many years ago.( Note to self -- must learn Terraform, Packer).
I'm not too experienced with Terraform, can one use it to, for example, do a rolling deployment with something like haproxy as the load balancer?
I view Ansible and Terraform as complementary tools; I can imagine performing rolling upgrades by using Ansible to shoot down a node and then have Terraform rebuild it; and Terraform could use Ansible to configure the nodes, if you're not using images.
For smaller systems one could use Ansible to create the infrastructure too, but I don't think it scales very well.
For smaller systems one could use Ansible to create the infrastructure too, but I don't think it scales very well.
Conceptually this is exactly what Terraform is made for. It will deploy things with the parallelism rate you specify, and is designed to neatly scale your infra up and down.
To do a rolling deployment though, it does become awkward, as you essentially have to model both the old version and the new version in your code, and then run the commands several times to scale up the new cluster and scale down the old one in stages. It's basically a modelling of a blue/green deploy.
To do a rolling deployment though, it does become awkward, as you essentially have to model both the old version and the new version in your code, and then run the commands several times to scale up the new cluster and scale down the old one in stages. It's basically a modelling of a blue/green deploy.
[deleted]
Ansible has been nice for replacing a bunch of ad-hoc shell scripts for my Digital Ocean boxes for personal projects. I have a bunch of simple provisioning scripts I can re-run as many times as I want, and I have simple deploy scripts that automatically skip unnecessary steps. Cannot imagine a better tool for single-host devops, really - if I were putting together a list of "how to run your own small infrastructure" it'd be higher priority than anything else.
I am curious, as a bit of a devops outsider, how it fits into the toolset of a modern application. From what I can tell, a lot of the aspects of Ansible are made redundant in a world of _hosted_ containers - you don't need Ansible if you're, say, deploying container images to EKS/ECS/whatever - but if you were to self-host your Docker hosts (or... whatever the Kubernetes is equivalent is called), Ansible still seems to me to be the best tool around for standing up and maintaining those hosts.
I am curious, as a bit of a devops outsider, how it fits into the toolset of a modern application. From what I can tell, a lot of the aspects of Ansible are made redundant in a world of _hosted_ containers - you don't need Ansible if you're, say, deploying container images to EKS/ECS/whatever - but if you were to self-host your Docker hosts (or... whatever the Kubernetes is equivalent is called), Ansible still seems to me to be the best tool around for standing up and maintaining those hosts.
Ansible is a good choice for maintaining the k8s infra itself, but IMO is not good at maintaining hardware or managing containers.
The major problem with Ansible compared to container orchestrators is that Ansible has no concept of previously known state. It makes some things that are easy in Terraform (deletions) more difficult, as you have to write a new playbook to delete stuff. So can't say, "I don't want to run this nginx container on this host anymore" by just removing that host from the part of your inventory that gets nginx, or removing nginx from that hosts playbook. You have to explicitly remove it.
This is not a huge problem if you're into immutable infrastructure, where you just wipe any host and redeploy, as it lets you go from known state to known state reliably. This kind of relgates Ansible to yaml shell scripts, but it's generally a lot tidier and gives you a nice framework for knowing where you are in your script.
When trying to apply Ansible to more infrastructure related stuff, again, it can do it, but's not the right tool. You can write a playbook to deploy a host or scale your EC2, but you basically have to do that separate from the provisioning of the hosts you just deployed.
For container orchestration, I found Ansible more of a hinderance than a help. Ansible is very imperative, and most orchestration tools are deliberately declarative. There's no particular reason to use it to deploy, scale, delete basically anything in k8s or swarm, as there is very little value add over using the tools themselves.
Overall I find Ansible best suited to building the containers or vms that you will run on your cluster, as these are necessarily imperative steps that fit it well. This also applies to the hosts that make up your cluster, if you aren't able to prepare an immutable image for them or get them to auto join.
The major problem with Ansible compared to container orchestrators is that Ansible has no concept of previously known state. It makes some things that are easy in Terraform (deletions) more difficult, as you have to write a new playbook to delete stuff. So can't say, "I don't want to run this nginx container on this host anymore" by just removing that host from the part of your inventory that gets nginx, or removing nginx from that hosts playbook. You have to explicitly remove it.
This is not a huge problem if you're into immutable infrastructure, where you just wipe any host and redeploy, as it lets you go from known state to known state reliably. This kind of relgates Ansible to yaml shell scripts, but it's generally a lot tidier and gives you a nice framework for knowing where you are in your script.
When trying to apply Ansible to more infrastructure related stuff, again, it can do it, but's not the right tool. You can write a playbook to deploy a host or scale your EC2, but you basically have to do that separate from the provisioning of the hosts you just deployed.
For container orchestration, I found Ansible more of a hinderance than a help. Ansible is very imperative, and most orchestration tools are deliberately declarative. There's no particular reason to use it to deploy, scale, delete basically anything in k8s or swarm, as there is very little value add over using the tools themselves.
Overall I find Ansible best suited to building the containers or vms that you will run on your cluster, as these are necessarily imperative steps that fit it well. This also applies to the hosts that make up your cluster, if you aren't able to prepare an immutable image for them or get them to auto join.
Ansible is one of those tools that is so general that it can just absorb whatever operational complexity you throw at it. It might not be pretty, and you might want to tattoo the Jinja and YAML specs on your arm but even in the world of hosted containers I still use it to act as the glue for the disparate systems I have to coordinate.
Having Ansible actually completely manage our hosted k8s environment has been really nice since Ansible has gone through the effort of gritting their teeth on templating and manipulating YAML in a semi-sane way. I've tried and tried to like Helm but you just hit the ceiling of what's possible so fast. Being able to add new filters, expose new/dynamic data to templates, pull data from outside sources, and have both Ansible-lang and Python as escape-hatches is something I don't want to give up.
Having Ansible actually completely manage our hosted k8s environment has been really nice since Ansible has gone through the effort of gritting their teeth on templating and manipulating YAML in a semi-sane way. I've tried and tried to like Helm but you just hit the ceiling of what's possible so fast. Being able to add new filters, expose new/dynamic data to templates, pull data from outside sources, and have both Ansible-lang and Python as escape-hatches is something I don't want to give up.