swarmsible VS crossplane

We use Docker Swarm for our deployments, so I will answer the questions based on that.

We have built some tooling around setting up and maintaining the swarm using ansible [0]. We also added some Hetzner flavour to that [1] which allows us to automatically spin up completely new clusters in a really short amount of time.

deploy from source repo:

- We use Azure DevOps pipelines that automate deployments based on environment configs living in an encrypted state in Git repos. We use [2] and [3] to make it easier to organize the deployments using `docker stack deploy` under the hood.

keep software up to date:

- We are currently looking into CVE scanners that export into prometheus to give us an idea of what we should update

load balancing:

- depending on the project, Hetzner LB or Cloudflare

handle scaling:

- manually, but i would love to build some autoscaler for swarm that interacts with our tooling [0] and [1]

automate backups:

- docker swarm cronjobs either via jobs with restart condition and a delay or [4]

maintain security:

- Hetzner LB is front facing. Communication is done via encrypted networks inside Hetzner private cloud networks

- [0] https://github.com/neuroforgede/swarmsible

Pretty much the same as our goto for projects at work: Hetzner + Docker (Swarm) with some Ansible to orchestrate things

We have built some automation around cluster management over at https://github.com/neuroforgede/swarmsible.

I used to do everything in ansible, but Docker Stacks are just so much nicer to use.

In any case automation is king. I don't have to remember stuff if I can just look at some IaC Code :).

Our tooling can be found here https://github.com/neuroforgede/swarmsible . It is not yet documented tbh, but most things are pretty straight forward to use if you have used ansible, docker etc already.

Story of one of the projects I am involved in:

We came from Ansible managed deployments of vanilla docker with nginx as single node ingress with another load balancer on top of that.

Worked fine, but HA for containers that are only allowed to exist once in the stack was one thing that caused us headaches.

Then, we had a workshop for Rancher RKE. Looked promising at the start, but operating it became a headache as we didn't have enough people in the project team to maintain it. Certificates expiring was an issue and the fact that you actually kinda had to baby-sit the cluster was a turn off.

We killed the switch to kubernetes.

In the meantime we were toying around with Docker Swarm for smaller scale deployments and inhouse infrastructure. We didn't find anything to not like and are currently moving into that direction.

How we do things in Swarm:

1. Monitoring using an updated Swarmprom stack (https://github.com/neuroforgede/swarmsible/tree/master/envir...)

For anyone interested in this, check out: https://github.com/neuroforgede/swarmsible/blob/master/environments/test/test-swarm/stacks/02_monitoring/README.md

did anyone adopt in production https://crossplane.io ?

- https://github.com/crossplane/crossplane/blob/master/design/one-pager-composition-environment.md

In the overall scheme of things , look at services like backstage.io , crossplane.io and opslevel.com to get ideas. This is not necessarily an endorsement of the services. If all you want is to handle cloud resources and that's it, Terraform can be enough with what ever flavor of web technologies you and your team are comfortable with and can support it along the way. Doesn't take much to create a js based website to collect data from a form, or use other means to collecting data as long as its recorded and transparent for accountability.

XRs are written in a fully declarative manner. And when I am building my XR from underlying managed resources provided by some crossplane provider I need to parametrize resources, use conditionals and create arrays of resuorces The issues of declarativeness in the world of automation are well known- we typically resort to some form of templating and we invent some imperative expressions into that templating language/format. This is currently not very well supported with Crossplane however Crossplane team realizes this issue and they are conteptualizing solution here

I have an idea for a project that would interface with Crossplane. The project has some code that would save tons of time if I could use it directly in my project, but it is located in the internal directory. I can't import the modules directly, but the project is open sourced under an Apache 2.0 license, so the code itself is available for use under that license.

There are always new projects like crossplane that sit on top on architecture systems like terraform, vagrant. The pressure to abstract away any sort of resources is mounting, companies can save a lot by for example by alt hosting S3 endpoints. The train is going the direction not to tie anything to a specific platform implementation if its not a must. Most of the companies I work with use AWS as a hosting provider, but Microsoft for github and related CI matters. As I learned, AWS quality is very dependent on location, eu-central-1 is dead stable for our use cases serving about millions requests a day.

Practically, you'll be replacing stock k8s resources (deployments) with custom ones like Argo Rollouts with Keda autoscaling, so you have to plan the respective Gitops CD pipeline (fluxcd/argocd with some crossplane), as well.