ama VS cluster-api

If you want to stick on one machine, you can always just use a single node Docker Swarm to get the fully automated zero downtime deploys you want with Docker Compose:

https://github.com/BretFisher/ama/discussions/146

Follow Bret here

Check out Bret Fishers courses and content - https://www.bretfisher.com/

This Awesome List is maintained by Bret Fisher (and coming soon, maintainers #3). This is a curated list of working tools and resources for using Swarm. It is not an official list, but a community effort to help people find the best tools and resources for Swarm in 2023 and beyond.

https://www.bretfisher.com/ - awesome guy, awesome discord (https://devops.fan). Awesome Talks

Composer is not meant to run in production. It is only meant for development or building images. Make sure to read Getting started with swarm mode and check this if you want to use run your build image on a proper environment. (recommended)

I don't know if I would call myself an expert, but worrying about security is a big concern of mine and my job. While there are some security benefits to running your app in a container, you're correct in thinking there are some things to keep in mind while writing your Dockerfiles and using Docker. Check out Bret Fisher's write up on security concerns using Docker. This is the second time that I've mentioned him. He's a Docker Captain and recognized by Docker as an expert. His advice is sound.

Only one host for production environment. What to use: docker-compose or single node swarm? · Issue #8 · BretFisher/ama (github.com)

In this blog post, we will demonstrate how easy and fast it is to deploy Sveltos on an RKE2 cluster with the help of ArgoCD, register two RKE2 Cluster API (CAPI) clusters and create a ClusterProfile to deploy Prometheus and Grafana Helm charts down the managed CAPI clusters.

4. Having moved to a container orchestrator, all of my nodes are immutable. Hardware and VM instances _can_ be born magically into existence. Nearly all infra providers support [cluster-api](https://cluster-api.sigs.k8s.io/). Network infrastructure can now be managed with TF, so I go that route.

## Linux curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.4.4/clusterctl-linux-amd64 -o clusterctl sudo install -o root -g root -m 0755 clusterctl /usr/local/bin/clusterctl ## Mac brew install clusterctl

Did you ever try CAPI? https://github.com/kubernetes-sigs/cluster-api

You might find interesting the capi-rancher-import k8s operator we use in Sylva, it would adopt in Rancher server the Cluster API created k8s clusters (with bootstrap provider kubeadm or even rke2 - you can lookup CAPBR for the latter). I understand your clusters are not created by Cluster API, so if you could move the workloads/resources to new clusters created by Cluster API, this can come handy. (Adoption of non-CAPI clusters into CAPI is not yet a standard practice, more in https://github.com/kubernetes-sigs/cluster-api/issues/7776)

Most of the comments have mentioned older tools like kubespray, Ansible, Rancher etc. I would suggest the cloud native way using ClusterAPI or use a tool that relies on ClusterAPI in the backend called Talos

Cluster API

Sveltos is a powerful open source project that makes managing Kubernetes add-ons a breeze. It automatically discovers ClusterAPI powered clusters and allows you to easily register any other cluster (like GKE). Then, it seamlessly manages Kubernetes add-ons across all your clusters.