Having said that, this caught my eye:
> There may be backwards incompatibilities in the core playbook language. Please see the porting guide for details.
Doing incompatible changes is not something specific to Ansible, for example Puppet has also done it time and again. We've been using both Ansible and Puppet in my previous job, and we always found it mildly annoying that upgrading a system (Linux, FreeBSD) would, in addition to the other "usual" dangers, bring along the danger of the new version not having a package for the "old" version of Puppet or Ansible that we were using. Which would force us to divert attention to the automation tool's problems instead of using the automation tool to solve problems.
I do understand that nothing can stand still and everything must evolve and change, but at some point this acquires the flavour of changes for the sake of changes. Especially when regressions happen and things that were working perfectly are now breaking, it is not exactly pleasant to have to devote time to them.
It's not exactly clear how can Perl programs or shell scripts or Makefiles from 20 years ago play perfectly fine unchanged, but the syntax of a manifest or playbook that does a couple of simple operations cannot remain stable. It's not like those tools were created yesterday, in which case it would be reasonable to expect changes in their first years.
You ended up with lots of magic an internal domain knowledge about how to do things, and often had to get clever to get the result you wanted. They were often somewhere both not opinionated and too opinionated, and generally suffered from being "DSL"s domain-specific languages which were really just syntatic magic in various languages which really needed to be actual programming languages or more explicitly policy setting frameworks. They were in the middle of several extremes and tried to be lots of things at once and generally just didn't do a great job, unfortunately.
How does Kubernetes not also result in the same? I'm not questioning plenty of improvements and the somewhat different domain it brings to the table overall but genuinely curious. From what I've seen any tool designed to integrate and manage complex, disparate systems is going to end up with lots special cases, domain knowledge, and require digging into implementation details on a regular basis for anything other than absolute common-case uses.
This is a good point, and most problems came because the tools were still only involved in mutating state of the machine. They eventually evolved to be declarative, but that's just cosmetic.
In the CM tools if you added declaration that package should be installed and you removed it the package will still be there. You had an entry to say that it should be uninstalled.
This basically ensures that machines that are configured the same way often ends up being drifted apart.
NixOS solves this problem by having language that instead of describing what should be updated instead has a declarative language that describes how the entire system should be built. When you change configuration it actually rebuilds the OS from scratch. It might seem like a lengthy process, but it is actually a quick because of caching. Nix just fetches missing pieces from repo and places in ints store, rebuilds things that are not in the binary cache and then updates symlinks to new locations. Because of using symlinks, upgrades are atomic, and you can also roll back your changes.
The catch? It is a paradigm shift, it also doesn't help that the language used is functional. So it's a steep learning curve.
This assertion makes absolutely no sense at all, and reads like a Markov chain of buzzwords.
Kubernetes is containers autoscaling, blue-green deployments, revertible deployment histories.
Ansible and the like is configuration as code. That's it.
The closest there is between kubernetes and configuration-as-code tools is Docker's dockerfile.
(Yeah, k8s does a whole lot more and is more opinionated, but still...)
It's clear when you deal with both types of systems. Perl optimized for stability and backwards compatibility at the cost of new features and new language conveniences. This is great and a strength when all your competitors are playing catch-up or don't have enough market share to make an impact, but once that's not the case, anything new they bring to the table is a point in their favor, and you get what we have now, the long slow death of Perl.
Backwards compatibility is wonderful until there's a really useful feature that it prevents, then all of a sudden it's a more complex story because it's not just preventing busywork, it's preventing progress.
It's a similar attitude to the parts of the OSS community who feel that anyone complaining about poor documentation or usability just "doesn't want to do the work" to understand the system.
I was contrary to the idea of 3rd party software repositories, and was of the opinion that one should strive to depend as much as possible from system provided packages.
But the same experience that you mention now, is what gave my point of view a 180 degree change, and now I'd rather install something from pip or NPM. I can just pin the desired version, and they more or less have the policy of holding past versions in a frozen state, so if I know for a fact that version 1.2.3 is exactly right for my needs, I'll keep using that one regardless of system.
The weak point of packaging systems (my experience is Debian and Ubuntu) is that normally there are not many (if _any_ at all) alternative versions offered for the same software. They are built with the general assumption that you should use the latest ones, and of course they don't even attempt to offer a history of versions of every package. So every time you upgrade, it happens what you say, "divert attention to the tool's problems instead of using the tool to solve problems" (very good wording by the way, I liked it a lot)
Semver doesn't make life easier. Making backward compatible changes is what makes life easier.
at this point i've started transitioning as much of my administration stuff as i can away from ansible. there's some good stuff in their codebase, but it's easier for me to find it in the source code and copy-paste it into my own projects than it is for me to work within the ansible structure. ansible solved a lot of problems for us, but over the time we've been using it i'm pretty sure it's caused more problems than it's solved.
Any preferred alternatives you can share?
I do not think it is a case of hindsight 20/20. These are basic things like object need multiple fields but it is rigidly defined with 2 fixed strings and now one need object V2 to update. Or all functionality dumped at base URL so no scope of adding sub-functionality without breaking the whole pattern. I can understand no one can plan for how complex functionality evolve over time. But here I see perennial amateur hour with every release. And it is doubly irritating when these frameworks are already many layer deep stack of bullshit abstractions so ideally they should be able to handle changes without breaking.
Ansible at least had the advantage of being a 'broad' tool from the get go. So a lot of the common use cases were covered. But I'm sure surprises still popped up :-)
"Due to a limitation in pip, if you are upgrading from Ansible 3 (or earlier), you need to uninstall Ansible and Ansible Base before installing Ansible 4"
Python does some things really well, but their package managers leave what to be desired [especially for the uninitiated].
I don't even think backwards incompatibilities are the biggest reason. In practice, the problem is often around bugfixes and upgrades. Upgrades are much easier if you can do them independently. It sucks to have to upgrade the kernel and other tooling just to grab a small bugfix--or hold off on a transition waiting until both OS issues and code base issues are resolved.
> It's not exactly clear how can Perl programs or shell scripts or Makefiles from 20 years ago play perfectly fine unchanged
In all likelihood they don't. For open source projects they probably have a lot of workarounds and cruft to support a variety of environments and spans of versions they are both written against and tested against. Internal code is written and tested against a specific version relying on your proprietary environment.
this is not coupled to OS to begin with,ansible is just a bunch of python modules in a long trenchcoat
OTOH, in the case of Ansible, I've had good success with `pip install --user` to get a local (to my user) Ansible install that's separate from the system, and it looks like specific versions of software can be requested.
https://github.com/ansible-community/ansible-build-data/blob...
Curious on the general take here.
Terraform is a Infrastructure as Code tool (IaC). Great at deploying the underlying raw resources.
Just like you can take a screw driver and use it as a hammer, punch or pry bar. You could also deploy infra with Ansible or configure servers with Terraform. I have done it, seen others do it and try my best to avoid it. You really want the best tool for the job but sometimes you need the best tool for the person/situation. A air powered hammer is a really nice tool to have but if you are in a place where they don't have compressed air, then a regular hammer will do and if the locals don't have hammers, then find a rock. So sometimes we do weird things with our tools, is it useful? Possibly to the person at the time.
I don't think Ansible is trying to fit into IaC. I think CaC and IaC are just a set of tools that are trying to fit into DevOps/SRE.
A really nice approach I have built for clients over the years when deploying non-containerized applications is to use Packer with Ansible to build a image of the server. Then use Terraform to deploy the infra. Then comeback with Ansible to do runtime stuff like Security tools, enroll into monitoring and also deploy the running application if not already baked into the image.
If you are containerized then just switch out packer for docker.
If you're only doing AWS or Google Cloud, Ansible can do that. Whether it does it better or worse than Terraform is all dependent on your use case.
If you're doing anything on premise, or outside of GCP/AWS, Ansible can do that as well. From the using OOB management (HP iLO/Dell iDRAC) to install the OS, to configuring vmware clusters to deploying k8s to declaring resources within k8s. Got network switches and firewalls at your office? You can manage that with Ansible. If you have a bunch of edge compute, Ansible can manage that as well.
What it comes down to is if you've got teams working with anything outside of AWS/GCP. They'll probably be using Ansible, and since you've already go Ansible knowledge across your organization, it would make sense to leverage that expertise and Ansible's cloud integrations.
All of that said - Terraform is much more popular when it comes to the major cloud platforms. If all you have is cloud, then you'll probably start with Terraform and stay there.
https://github.com/ansible-collections/community.kubernetes https://www.ansible.com/integrations/cloud/amazon-web-servic... https://www.ansible.com/integrations/cloud/google-cloud-plat... https://www.ansible.com/integrations/networks
1. IaC for the network, database, container definitions, and other cloud things. I use terraform here. 2. CI/CD for the application software, which ultimately builds a container image from version control, tags it in some well-know way, and tells the container scheduler to redeploy. I tend to use CircleCI, but any CI solution will do. 3. Configuration management for my container definitions, injecting environment variables for config/secrets into the definition or runtime. I tend to use Ansible or Terraform here.
For me, the main criteria is whether the product has a large number of components with configuration that needs to reuse common structures. If I'm just deploying one or two components (e.g. your typical early-stage monolith), Terraform is fine. Bt if you have many users contributing to many components and want to provide higher-level tools, I vastly prefer using Ansible; you just have more control.
That is, I believe in Ansible as a tool for applying configuration from source control to some other system; I would no longer use it to provision cloud resources.
Granted, moving from wiki pages and ad-hoc scripts to any system would have been a big improvement.
As a developer working on a small startup, I don't like using Docker because it makes the fan on my MBP go crazy and drains the battery almost instantly. Whereas I've had zero problems with VirtualBox. Until containerization actually works properly and provides a good developer experience, I can't see myself switching unless forced.
It seems like a good fit in that role, as the other main option is writing your operator in Go, which is even more imperative, and usually ends up seeming a little too low level and like overkill for the tasks an operator actually has to do at runtime. Either one can be a good option, but many people will go with ansible, and I see it carving out quite an important little niche with operators.
I honestly spend more time getting it setup, testing, and deploying then I do using it. In my heart I know that this is the right approach, and the way I should be managing my servers. But the time-saved just isn't there. The consistency is awesome.
I have 2 complaints about Ansible. (1) Minor annoyance - It's slow. It's as slow as if I were sending individual commands from SSH. A scripted solution that is as slow as my typing is a hard sell. It doesn't make spelling mistakes but it does make different mistakes. I can live with this annoyance, but I have literally spun up a new server, SSH'd in, created my Ansible user, and launched my "Initial Server deployment script", went for lunch; and came back to it just finishing.
That example is even excusable. But a simple script: "check for system updates & report back if needed" for 50 servers is slow as fuck. Running them in parallel would be better.
My biggest most scornful vehement hatred is for yml files and python being white-space sensitive. I will piss on the shoes of the person that ever thought of that. Fuck them. Even though I have vim templates for .yml, Even though I have 'turn tabs to spaces', even though I have whitespace characters SHOWN; There is ALWAYS atleast one someplace.
I hold a hatred that only Khaan can feel towards Kirk about this.
But other then that, I really want to love it.
It does run in parallel by default though: https://docs.ansible.com/ansible/latest/user_guide/playbooks...
They subsequently offered an ssh-based option for those that wanted the poor performance of Ansible across larger fleets, or where agents were not palatable.
Unfortunately it doesn't address your second concern, as it also uses yml + jinja.
Amen. The irony of making something invisible syntactically significant is quite something.
Was it really a limitation in Pip? Or did the Ansible devs just really want this non-backwards-compatible release to use the same name as before, just so they wouldn't have to use a new package name like "ansible4"? Even though that would allow both pre-ansible4 and ansible4 scripts to co-exist? And considering everybody has to test and update their code for ansible 4 anyway?? This seems to just cause more pain for devs and admins with no real benefit. Which is to say, par for the course.
This is the main reason I have always hated using Ansible. Arbitrary decisions leading to a cumbersome, bloated, undocumented, difficult mess.
$ ansible --version
ansible [core 2.11.0]
$ python -c 'from ansible_collections.ansible_release import ansible_version; print(ansible_version)'
4.0.0Does anyone know what they're talking about? This is a pain to deal with in my app, and I've never seen it with any other pip package.
There was a Herculean effort to try to get it to just upgrade cleanly, but in the end it turned out there was no way.
Ansible is perhaps the worst option, next to CFEngine and some other legacy ones. It's just the one everyone goes for because nobody wants to maintain a puppet/chef/salt/etc server, and encoding a bastardized DSL in YAML seems easier than writing Ruby.
https://github.com/skx/marionette/
It turns out that three operations suffice for almost 90% of my needs:
* Populate a file, from a template with variable expansion.
* Run a shell-command.
* Install a package.
I added support for pulling a docker container too, just for fun. Although I never made the effort to pimp/promote it, the tool is stable and useful as-is.
For mgmt, I don't see anything particularly novel that it brings to the space. It doesnt use YAML, but if I'm going to write pseudocode I may as well reach for Pulumi or python. Why would you recommend mgmt over Ansible or Terraform? Since this can use Consul, why wouldn't I just use Consul for event driven changes?
I think they're interpreted code. The yml has steps which aren't too different from statements.
If what the project creator says matters, the GPL has less legal meaning.
I personally think the GPLv3 does protect more than just compiled code, and that Ansible is off their rocker with the GPL.
Edit: For that matter, ansible only runs on your own local machine. Without redistribution, the GPL doesn't really have teeth anyway.
Too many years in the industry with projects called final... Basically a tag saying 'this shit ain't never gonna be over! Run for the hills!'.
And nothing is more set in stone than a bunch of yml ;) /s
Release of the following:
Name: ansible
Version: 4.0.0
Combined, it's the "Ansible 4.0.0 Release" in whatever order makes sense. If you have something that is not a release, then you would not call it a release. But if you think you are close to a release and you want to be sure, you could state that this is a candidate but not entirely sure. You can even have multiple incarnations of candidates. You end up with a "release candidate" and you could suffix it with number if you have more than one.
While many creators and vendors some up with all sorts of schemes, there are a few standards available with extensive documentation like https://semver.org or simply mimic what well-respected projects are using.
The problem is of course that nobody agrees on anything if you have a large quantity of things (including large quantity of people), and the urge to create 'a standard to fix the mess' which just adds to the mess in the end. This whole thing is of course not all that important in the grand scheme of things, and an intersection of the 'standards' XKCD commic and 'everything is great and nobody is happy' seems to be where we end up every time.
Here it doesn't mean "the project is done, no more development".
It just means this is the official release of version 4.0 - e.g. no more betas, etc.
I know how semver works and I found the final naming ironic.