3 ms·

I thought this was about deploying a Kubernetes cluster with Ansible, but nope, it's really about deploying YAML files to Kubernetes, with Ansible. Just...Why?

TomBombadildoze 4y ago
When all you have is a hammer, everything looks like a nail.
MuffinFlavored 4y ago
Sounds like the title should be "Deploying To Kubernetes With Ansible", since this isn't about deploying a Kubernetes cluster?
ikiris 4y ago
... oh god why. Also thank you for the very apt and red flagging summary kind sir.
nijave 4y ago
Yeah, title made me think kube-spray
sprior 4y ago
I had the same impression.
KronisLV 4y ago
> 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/ https://k9scli.io/). Edit: Many suggest that using something like Argo CD would be a better tool for this, due to its specialization, though. 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. Admittedly, using Helm or one of the alternatives in this case might be a better choice.

TomBombadildoze 4y ago

When all you have is a hammer, everything looks like a nail.

MuffinFlavored 4y ago

Sounds like the title should be "Deploying To Kubernetes With Ansible", since this isn't about deploying a Kubernetes cluster?

ikiris 4y ago

... oh god why. Also thank you for the very apt and red flagging summary kind sir.

nijave 4y ago

Yeah, title made me think kube-spray

sprior 4y ago

I had the same impression.

KronisLV 4y ago

> 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/ https://k9scli.io/). Edit: Many suggest that using something like Argo CD would be a better tool for this, due to its specialization, though. 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. Admittedly, using Helm or one of the alternatives in this case might be a better choice.