Docker Swarm => Kamal ... is Kamal a good choice in our usecase

[GiamBoscaro]

I like the ideas behind Kamal and I was wondering if I could adopt it for our system, but I am not really sure it is a fit for our usecase.
Our application is a web application made in Angular, and a backend made with many microservices in Node and Python, some database, Keycloak for authentication, ELK stack for logging. At the moment our system is running in a single docker compose in staging, and with a docker swarm in production, with a Traefik ingress. Some microservices are replicated, some are not.

Do you think I can substitute the docker swarm stack with Kamal?
In particular, I have the following doubts (not in a particular order):

• Not all images can have curl installed for the healthcheck
• Not all containers are replicated. If a single container is deployed in a server, I would like not to specify the server but to automatically select one based on available resources
• No build or push, all the images are build through Jenkins already
• There will be no more docker overlay network, so I guess the services will communicate between each other by using the external URL and passing through Traefik
• How to configure it? One deploy.yaml for each microservice, or one big deploy.yaml with the web application as service, and all the other microservices, db etc. as accessories?

[eric1234]

Not all images can have curl installed for the healthcheck

Curl is just the default healthcheck command. You can set whatever command you want so you can use wget or whatever.

I would like not to specify the server but to automatically select one based on available resources

This I don't think you can do. The deploy.yml file is pre-processed via ERB so maybe you could have some custom Ruby code that is picking for you based on some criteria?

No build or push, all the images are build through Jenkins already

The --skip-push switch is what you want. This will skip building and pushing your app but instead just pull from the already built containers. Just keep in my that Kamal uses the git hash as the version so I think your pre-built images will need to follow that pattern.

I guess the services will communicate between each other by using the external URL and passing through Traefik

Depends on the service if it goes through Traefik. Example your database services would not. But yes you would just use connection info to the other servers to communicate with each other. This is another place you can use ERB to DRY things up in your deploy.yml. That connection info doesn't necessarily have to be a public IP. Communication could also be via a private network.

One deploy.yaml for each microservice

This would be my recommendation as that is the whole point of microservices. Each service is developed and deployed independently. If you combine everything together then might as well embrace a monolith and get the simplicity win.

[GiamBoscaro]

Thank you for your answer!

So, I see that --skip-push can be a useful command for our use case but I had already tried it and indeed I could not deploy because it was pulling an image with an hash. But obviously our pipeline is not producing these tags but just a normal : tag. And it is a little bit weird to tag an image like this.

Also in our case we do not have pure micro services, for example our services are all connecting to one o two databases, or to a database cluster. But it is not a pure micro service with is own db. So also in this case the Kamal configuration would be a little bit strange, something much more similar to a docker compose maybe?

I am thinking that really using docker compose and docker swarm or k8s could be a better solution for us. Do you think I am missing something?