Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
> Just...Why?
I can imagine some cases where you might want to setup infrastructure-related software on your cluster and to do so through Ansible (using manifests or Helm charts under the hood), so that you have one template that you can use for setting up clusters later, for various use cases.
For example, you might want a custom ingress controller, or to deploy a service mesh like Istio, or maybe Kiali as well. Perhaps you want to launch Rancher on your cluster to give your engineers an arguably easier way to interact with the cluster, or to explore it in a more visual way than just using something like the kubectl CLI (though tools like k9s are great, too: https://k9scli.io/).
I actually utilized a similar approach when working with Ansible + Docker Swarm (since I needed a more lightweight orchestrator that played nicely with Docker, but to manage the nodes with Ansible): I deployed my own "ingress" (just a web server container with some configuration), some supporting software like Sonatype Nexus for storing custom images, Portainer for graphic cluster management and some other software for similar concerns.
Once that was done and other server configuration (e.g. user accounts, groups, permissions, folders, services etc.; though most less relevant for the containers themselves) were set up, other CI/CD pipelines could deploy apps across the cluster without Ansible being involved - but it was good for setting up the base for it all.
But if you wanted to use Ansible for deploying almost all of your apps, like in the article? I guess you could do that if you have a lot of buy-in into using Ansible and just prefer the way you do things with it.