First of all, congratulations to the team of Ansible and these tools have benefited us in numerous ways that cannot be understated.
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.
The reason why kubernetes et al. are so popular is that the orchestration tools like ansible, puppet, salt, chef... they all failed to deliver ultimately great software. Plagued by mediocre quality external modules and a constant churn of semi-backwards incompatible changes which required frequent maintenance, they have just been hard to use.
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.
> 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.
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.
> How does Kubernetes not also result in the same?
Here's the difference between kubernetes and ansible (and alikes) (and I'm over-simplifying a bit of course, but the idea is there)
* With kubernetes, you write down the state you want your infrastructure to be in, and k8s figures out how to get there
* With ansible, you write down how to get to the state you want and ansible runs those steps, and hopefully they end up in the same state. The issue is that if you run the same set of steps on a Debian linux distribution, and on a Ubuntu distribution, well, they might end up in a similar state, but they actually aren't; for starters: one is debian, the other is unbuntu.
That does not seem avoidable. I have never used kubernetes, but this seems highly suspect:
>With kubernetes, you write down the state you want your infrastructure to be in, and k8s figures out how to get there
My guess is that this devolves to "run this script" or "copy this file" in practice as well. Or it just becomes tautological, i.e. "here's the state I want the system to be in (and that means run this script and then copy this file over here, and don't forget to symlink it over there)". Am I wrong?
Kubernetes itself tries Very Hard to completely abstract those implementation details. Like, obsessively hard. You (assuming "you" are somebody who wants to run something in k8s) should never need to know or care what it's doing "under the hood" to run your pod in the way you say.
What's happened though is that Kubernetes expects for you to hand it an artifact that encapsulates all of the messy steps required before it can "run the thing." In practice that means the "run the script and symlink stuff" kind of glue is still present, it's just moved into Dockerfiles (which are, more or less, just fancy shell scripts themselves), build scripts, CI/CD pipelines, and startup scripts.
The big shift is more that the responsibility for managing this junk is pushed, organizationally, onto whoever knows how to operate the actual application (because they'll be creating the Dockerfile). Usually that's a developer.
So it's not wrong to say:
> With kubernetes, you write down the state you want your infrastructure to be in, and k8s figures out how to get there
But it's not really a complete explanation, because it assumes you've already gotten to the point that you've bundled an artifact up that will "do the right thing" when Kubernetes provides the fundamental pieces of infrastructure you define in your template.
Yeah you're (mostly) incorrect. I recommend looking into terraform and how it handles state, that will give you a better idea of how it's possible to do infrastructure in a "this is what i want, figure out how to get there" way.
Terraform isn't the best implementation of it; k8s has full control over the infra so it's even more powerful in that regard.
Kubernetes doesn't attempt to be an API that can solve any orchestration issue, it is an abstraction on the underlying architecture. It's a lot easier to be backwards compatible here (and if you are not, create an operator that is).
Now whether its the right abstraction is a matter of debate. But ultimately like VMs or containers, its so far proven to be a valuable tool, at least for medium sized companies.
One of the best things about K8s is its pretty stable API. We use GKE and the upgrades happen without issues 99% of the time.
The other benefit that k8s got for "free" was with containers: developers could stuff in whatever environment, software and configs they wanted inside the container. This removed most of the "my app broke because some shared lib didn't install properly" sorts of issues. This separation b/w software configuration and application configuration is extremely powerful.
Yea, I think with both ansible (and stuff like puppet) and kubernetes they are both powerful tools that are pretty leaky abstractions. They are great for sharing and implementing recipes, but that abstraction layer makes it a little more difficult to become a master chef and understand/control exactly what's happening. They are awesome to have in your toolbox, but I still find it incredibly useful to have a tool like python in there as well.
I’m not saying kube really fixes all of these problems or is a better solution, but it exists as a response to a crappy solution. in other words one problematic solution replaced another problematic solution. Stay in the field long enough and you see a pendulum where one kind of solution with problems is replaced by a different kind of solution with different problems... and then it swings back and a new general goes back to a new iteration of the first kind of solution and gets to rediscover the old problems again, back and forth over and over.
> The reason why kubernetes et al. are so popular is that the orchestration tools like ansible, puppet, salt, chef... they all failed to deliver ultimately great software. Plagued by mediocre quality external modules and a constant churn of semi-backwards incompatible changes which required frequent maintenance, they have just been hard to use.
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.
Nix is an incredibly far-sighted vision, and it's great to work with... once you get your head around it all. I much prefer to build containers using it, and it does a much better job of "provisioning" than any other tool I've used. I remember being appalled when I first used Ansible and discovering that adding a package, then removing the stanza to add that package, resulted in the package persisting on the system.
The point is that had they worked well, containers may not have become as popular as they are now.
Containers are only somewhat used for scalable microservices. They're mostly just an easier way to deploy software than creating your own RPM package and using orchestration tools to deploy it on VMs.
I hope that you do understand the difference of server provisioning and container orchestration, as mentioned above, solve completely different problems.
> The reason why kubernetes et al. are so popular is that the orchestration tools like ansible, puppet, salt, chef... they all failed to deliver ultimately great software.
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.
I think it still makes some sense. For example, if you look at the process of software development like this:
[business requirements] -> ... -> [deployed and working software]
Then it stands to reason that Ansible and Kubernetes are just two ways of getting to the same end result.
Where they differ, is the approaches that they take to achieving that result:
Ansible: [run a playbook ahead of time] -> [the environment for your app will be set up] -> [you can deploy to it through Jenkins/GitLab/whatever] -> [your app will run, but Ansible will know almost nothing about it unless run]
Kubernetes: [create a cluster ahead of time] -> [you'll be able to run any containers on it] -> [you can deploy to a registry through Jenkins/GitLab/whatever] -> [Kubernetes will make sure that your app remains running]
So essentially, i believe that many people have the stance, that they can probably just set up an environment for an application and forget about it (or at least not constantly monitor it), which is more in line with what Ansible provides, whereas Kubernetes is more suited to situations where it's impossible to have "stable software" (i.e. most business applications, since they don't have the quality of projects like the Linux kernel).
If you want fault tolerance, you have to do additional work with Ansible, like writing systemd services for restarts, manually setting up your load balancers and working on ensuring proper failover, as well as service discovery. And i'd reason that if something is hard to do, oftentimes it simply won't be done at all! Yet with Kubernetes, a lot of that comes out of the box (even though i think that it's often too complicated, K3s does seem sane, but personally Docker Swarm or Hashicorp Nomad hit the sweet spot of features vs complexity).
It sounds like you think kubernetes et al. are a suitable replacement for ansible et al. , however k8s are not able to provision settings on a Web Application Firewall from F5 and the iLO links on your HP blade server farm. Et Al. Your statement works if you are letting AWS/MS/Google do all that for you and all you are responsible for are package dependencies and joining the right VLANs. Not everyone is so lucky and actual Configuration Management tools like Ansible+, while not perfect, make Domain Specific (i.e. real world Multi-Vendor) large environments run on time for most of the time.
And of course you’re right, the use cases don’t totally overlap. However there is a big chunk of the core functionality which is absolutely competing ways to solve the same set of problems.
> 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 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.
There seems to have been a strong swing in the past decade or so towards busywork being not just acceptable but in some way laudable. "Doing the work" to keep your product using all latest versions is noble, whether or not you actually gain anything by upgrading. I can't shake the feeling that it all ties in to the industry wide push for SaaS and subscription models and evergreen software, all of which share an underlying motivation of everlasting job security for software companies and the people who work for them.
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.
It's fun how one's own perpectives and opinions change and adapt with the experience of facing real-world problems over years of professional (or otherwise any kind of) experience.
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)
All semver does is tell you you are pinned to some obsolete tool, and you are going to go through a soul sucking 6 months of yak shaving to stay up to date. (rails programmer since v3 here)
Semver doesn't make life easier. Making backward compatible changes is what makes life easier.
Does that make it easier or does it just mean you'll be more aware upfront that to get the security fixed or support you need for some new feature you need to upgrade to an incompatible version
if it was just incompatible syntax changes, that would be one thing. but it's not - it's incompatible administration and structure changes. they just stabilized the new modules shift a couple months ago, which restructured all their documentation and issue tracking, breaking uncountable links and closing thousands of open issues. and that wasn't the first time they'd done that.
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.
There's pyinfra (https://github.com/Fizzadar/pyinfra) if you like Python (disclaimer: I started the project), heavily inspired by Ansible just without the yaml/jinja2 hybrid stuff.
I've been following pyinfra precisely because every new Ansible release makes my heart sink knowing how much work it's going to cause me and how inscrutable debugging our playbooks is every time. I've been trying to find the time to port over all our existing Ansible playbooks but have really only scratched the surface so far. However, I have high hopes, pyinfra looks like a well thought through project.
Join the club of staying on Ansible 2.9 forever! It’s 2015 MacBook level good and still being developed. 2.9.21 was released two weeks ago and 2.9.22 is coming soon.
The way Ansible is developed it’s way easier to fork your own and backport bug fixes and features you need because it’s a toss up whether the fix you need actually got merged or whether it languishes in the GH issues.
i haven't even explored the options for shifting to another ansible-like system, i've just gone back to the supposed "bad old days" of a collection of random tools with shell scripts to fill in the gaps.
a combination of docker containers and terraform (for managing aws) is doing most of the heavy lifting for me.
I did this before with perl’s SSH::Batch. You can install it from CPAN and get really simple ability to run code on groups of servers in parallel. Works great.
Eventually I switched to Ansible because it made the more complicated things a lot simpler.
I am not much familiar with Ansible/Puppet etc. However working in Java and dealing with frameworks like Spring/boot, kafka etc I notice a phenomenon of large number of breaking changes, specially when one update in couple of years as opposed to update with every release. Now when I dig into changes it just points to extremely poor design to begin with. It just couldn't handle slight change in requirement without breaking changes.
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.
I tend to think this is an issue with 'designing' systems vs 'evolving' them. When you build something to 'scratch your own itch' and it suddenly becomes popular, lots of stuff you didn't think of tends to pop up. Maybe all the market studies, focus groups, ad nauseum in 'traditional' BigCo development actually did have some value.
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"
I've never used things like Ansible or Puppet in a professional environment, but I can appreciate how difficult my recommendation is. If you're using a technology for a significant part of your business, decouple it from the OS. Where that line is drawn is subjective.
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.
> we always found it mildly annoying that upgrading a system (Linux, FreeBSD) would [...] bring along the danger of the new version not having a package for the "old" version of Puppet or Ansible that we were using.
If this is the only issue, it sounds only mildly annoying. Either upgrade your tooling to use the newer version of be prepared to package up that old version of Puppet/Ansible--as long as you control what version is installed and are comfortable with the range of versions the package manager offers.
The type of scenario I had in mind is relying on something like Python, Ruby, Perl, etc. Something the OS may also deeply rely on. This came up a lot when macOS stopped updating a lot of GPL2 stuff to avoid shipping GPL3 or when they announced they'd stop shipping Python, Perl, and Ruby. You also see it when people try and change system Python version outside of the package manager in Linux and can no longer boot--the same thing can just as easily happen with libraries.
I feel you: in our environment, we stayed on Puppet 3 for exactly the sort of reason you call out for the longest time, and upgrading our Puppet codebase to be 4+ compatible was a major effort.
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.
Yes, that's another reason I am sticking with Bash for teaching for my book on deployments. Your Bash will only change if your tools change. If you want to know how things work under the hood, you don't want to go through a rabbit hole of Python modules that also change beneath you.
checked the release notes and it seems like they still don't allow you to run ansible with "python -m". that would have fixed a few issues with virtual environments.
I know Ansible has a huge number of fans but I am genuinely curious about the future. That is, I've been trying to figure out where ansible fits in the bigger picture of the modern trend towards IaC. Is it in conflict with that because of its semi-imperative nature? Or is what it does an essential piece of how IaC needs to work to do declarative infrastructure management? I see that for example you can use ansible within terraform. Do people really do that and is it useful? Or is it something you would only do if you have a lot of legacy infrastructure already configured via Ansible.
So Ansible is a Configuration as Code tool (CaC). You know for configuring your servers and network things.
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.
It's hard to say. I don't see too much point in running Ansible inside Terraform or Terraform inside Ansible (yes, you can go either way). Ansible lagged for years on its support of kubernetes and helm (it had it, but it didn't work). Now (like in the last 12 months) got good support for both, but it might be too late. Terraform has the majority of mind share when it comes to Kubernetes support.
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.
When I set up a product deployment system, I want:
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.
I've used ansible for parts of IaC. It was terrible. The person who made that decision had one tool in his box and it was ansible. I use it as part of packer, if I need complex changes while generating AMIs and I use it for my field deployed metal. It's great for both of those use cases.
Even in container world, I still find Ansible/Chef useful for a number of low-level system tuning tasks. Things like setting NUMA affinities, modifying kernel parameters, setting IRQ interrupts, loading kernel modules, setting NIC parameters, etc. That kind of stuff is often overlooked, but done right can have pretty dramatic performance impact.
I’d say that a tool like Packer is heavily reliant upon Ansible to be useful so I don’t see Ansible going anywhere anytime soon. If there’s a better tool than Ansible out there to pair with Packer please let me know!
This is now our primary use of Ansible as well. We install and minimally configure systems in machine images, then use cloud-init to do the remaining 1% of config at VM build time.
I don’t know about Ansible within terraform, but I use them together for non-container infra. Terraform for deploying the actual VMs and other stuff, and Ansible for post deployment OS/application provisioning. Using them this way has been extremely flexible and easy to maintain. I also provision AMIs this way with Packer calling an Ansible playbook to set everything up. The beauty of that is you can run that same playbook on already provisioned VMs to keep them in sync too.
I could never get why Ansible was popular - to me it felt like a real step backwards from Puppet. Running a bunch of commands once is rarely what you want (except perhaps for deployments, but there are dedicated tools for that).
For deployments, for upgrades, for setting up testing/staging machines. We picked it because it's agentless (just seems to self-evidently be better for our scale) and written in Python (the devil we know and love). Ours is a reasonably stable and a fairly small environment (~40-50 hosts, mostly containers), and it has been a very good fit.
Granted, moving from wiki pages and ad-hoc scripts to any system would have been a big improvement.
How so? Ansible describes a sequence of mutative steps, Puppet describes a desired end state; the latter seems far more amenable to immutable infrastructure than the former.
We run ansible-pull as the very last step of a CloudFormation build (instance or autoscaling group). So it's a local pull, not a push from somewhere else. Only done once, hence the immutability. To make changes you replace the instance.
Puppet (can) keep it's hooks into an already running instance and continue making changes to it.
> That is, I've been trying to figure out where ansible fits in the bigger picture of the modern trend towards IaC.
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.
There have been a litany of bugs and long running issues in docker for Mac causing high CPU usage. It is worth checking out the issues to see if one of the fixes works for you. Many of them relate to how volumes are mounted. I finally settled on a config and this is a non-issue. Of course, having to do this for any piece of infra is terrible, but docker is such a lingua franca on the server side that its worth it in this case.
I've been maintaining the ansible scripts for a dev vagrant box for 5 years. I've found it needs constant care and feeding/tweaking. I finally just gave up and install what I need locally with brew. Also vbox uses all the memory and makes the fans go brrrr.
Ditto on the constant care. And the Ops comment on brittle 3rd party modules is spot on.
I went back to a shell script to configure our developer VMs when I realised I was spending more time debugging Ansible updates than scripting it myself would take. And now I know exactly what's going on.
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 want to love it more then I do. I think it doesn't fit my needs quite enough.
When setting up a new system for a LAMP role, it might save me 5 minutes of work. When upgrading/updating my herd of LAMP servers, it might save me 5 minutes, and general 'management' of 50+ LAMP servers all in different AWS regions it's very handy. I like it. I just don't use it often enough to justify it.
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.
Your first concern is addressed by saltstack - they chose an agent based approach, with client subscription, as the default, which makes for a significantly faster experience.
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.
yaml never bothered me, so I just used it, but you could use a different one. I suppose none of the ones from the list would make parent poster happy, but then one could write own renderer.
> 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.
Amen. The irony of making something invisible syntactically significant is quite something.
This maybe a Frankenstein baby but when I’m dealing with ec2’s I appreciate creating the AMI using Ansible and Packer. Then referencing said AMI from a terraform script. I rarely do this anymore as I’ve moved the majority of infra under Kubernetes but the couple times I did it this way it didn’t feel dirty.
I use ansible to setup my LXC containers for personal stuff like pihole and freeipa. I'm not really sure what my alternative is. I can destroy / create the container and set it up in one command.
We do use ansible for provisioning in combination with AWS CDK. The cases are simple as when you don't utilize container services, but roll out your own server infrastructure using EC2.
"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"
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.
Because after Ansible 2.9 they made a huge change in how module resolution works and put most of the modules in a separate repository to be versioned independently.
>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:
Does 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.
Unfortunately due to some things that happened with the way they renamed packages after the split (from ansible to ansible-core and ansible-base), it required a full 'uninstall and reinstall' operation, otherwise Pip gets things a bit confused and the installation breaks completely.
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.
Pretty cool but Ansible just seems too slow to me. I'm just comparing this against like native scripting, Terraform, etc. I guess Ansible is still the best option for configuration management, but I keep hoping someone will come out with a new tool, preferably built with Go or Rust.
While I don't have any hard numbers, I would bet a lot of money that any "slowness" of ansible has nothing to do with the use of Python. Everything happens over SSH, that's a lot of network roundtrips.
SSH can be quicker, I believe ansibles use of SSH processes is more the issue. An old but still relevant benchmark exists in my pyinfra project which uses SSH (amongst other protocols) but a Python implementation, and its significantly quicker and more scalable than ansible: http://docs.pyinfra.com/en/1.x/performance.html
> I guess Ansible is still the best option for configuration management
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.
I run Mitogen which makes it super fast. There was some discussion of merging them. But the Ansible side got all grumpy and refused. It was a bad decision, because it hurts Ansible being so slow.
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.
Red Hatters keep leaving the company and building config management tools =D.
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?
Actually you always have an option to properly secure.
If you have own data center and more than one machine you do have a LAN.
I'm guessing you're talking about public cloud like AWS.
Similarly you can have private subnets (which is the best practice).
If you have a single instance that's only public, you can place definitions on local S3 and have instance pull it. You can secure everything so it's not accessible from outside, and you don't need service to be available from the outside.
If you have multiple instances and all are on public subnets and talk to each other over the Internet, you should rethink your design, but at very least have firewall configured. Security groups that list themselves could help.
In a word: Hetzner. Dedicated servers scattered across data centers, sufficiently numerous to make IPAM too painful to manually tie them together with wireguard. It's possible that some sort of overlay network or VPN could be made to work, but I could also just expose port 22 with only public key auth enabled, use ansible, and be done.
I never used Hetzner but based on my research, Hetzner says that they only have 3 data centers:
- Nuremberg, Germany
- Falkenstein/Vogtland, Germany
- Helsinki, Finland
so you could place 3 instances, one in each and would have to use public IP to communicate between them.
But, Hetzner also offers Cloud Network, which is essentially a LAN that you should prefer for communicating.
Anyway, whatever works for you, using Ansible is easier, because doesn't require any prior setup, but you pay that back with worse experience keeping things running and slower speed.
Thanks for looking out for us =D
Link for any who's interested: https://github.com/purpleidea/mgmt/
I and others have been working quite hard on it, so please come join us =D
Hey there, I've been following "mgmt" for years, hoping it was going to be the next big thing. I did see a while ago that you made a significant investment in developing mgmt full-time but then didn't see much news out of the community afterwards.
I'm curious whether there's a status update you could provide? I'd love to get involved as I think it truly represents a next generation style config management system, but I also had fears it was dead in the water or not being actively developed!
Why are you blindly upgrading? The only safe way to use Ansible in production or on a team is to pin the version everyone uses because even minor releases can break playbooks and change behavior.
Does anyone use Ansible in GitOps ? If so, what other tools do you use? Gitlab? Other?
If not, what would you recommend for non-Kubernetes infrastructure for GitOps?
We have a word that describes that better than 'final': release. And if it's on physical media, you could even call it GM (Golden Master). They are not words that stand on their own, you would combine it with the artifact name and the version you are releasing.
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.
I think the reason "final" is used is because you'll often have releases like
Foo 2.0 alpha release
Foo 2.0 RC1
Foo 2.0 RC2
etc, and if you just have "Foo 2.0" as a release it can be somewhat ambiguous as to whether someone named something wrong when downloading or describing it and left of that portion of the name, or if it's actually the full release, so they want a word to distinguish it as the actual full and final release of that version and not "the 2.0 branch"
"Final" may not be the best word choice for that, but it does at least accomplish the task of distinguishing the actual final product of that version from any other types of releases or the branch that will eventually become that.
Final has a finality to it as you somewhat pointed out ;-)
Perhaps, the best option would have been to omit any wording:
release 4.0.0 would be the real version
release 4.0.0-beta would be the beta version
release 4.0.0-rc1 would be the first release candidate
Then again, words like 'final' and 'release' have too many meanings. Release doesn't mean version or 'no longer secret' but mostly 'available for people that just want to use it'. It's probably (like GM) mostly originated from the times where software versions required distribution management with physical aspects which makes 'release' have more of a meaning.
beta would be 4.0.0b or 4.0.0-1 or 4.0.0-BETA. But context is important here; it's not called final because it's the final major 4 version but because this is the 'release' version of major version 4 according to the mailing list.
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.