Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
pyinfra
pyinfra automates infrastructure using Python. It’s fast and scales from one server to thousands. Great for ad-hoc command execution, service deployment, configuration management and more.
We have a word for that: 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.
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.
https://github.com/ansible-collections/community.kubernetes
I wrote a proof-of-concept tool, inspired by puppet more than anything, but since it runs locally it is perhaps comparable to ansible too:
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.