|
|
Subscribe / Log in / New account

The container orchestrator landscape

The container orchestrator landscape

Posted Sep 4, 2022 11:35 UTC (Sun) by kleptog (subscriber, #1183)
In reply to: The container orchestrator landscape by Cyberax
Parent article: The container orchestrator landscape

I was pretty enthusiastic about Swarm in the beginning as has a good model for managing containers. But if you're deploying production applications with it you get into a point that others have noted: all the management of permanent resources is done in Swarm itself. And the API is just the Docker API with no authentication.

So if you have a complicated application where the resources (say networks, or services) depend on configuration settings, you have to write a kind of wrapper which reads the configuration and then uses that to update the Swarm configuration. And that configuration is stored separately to Swarm itself. This is annoying and error prone. Because the tool to do this is complex you get the situation where you distribute the tool in a container and then start it up passing the Docker control socket in.

So Swarm can work well if your application is simple enough to deploy via a Docker Compose file. But if you're getting to the point where you're thinking "I need to make a tool to generate the Compose file for me" you're basically at the point where you need something more powerful than Swarm can offer.

That said: for our CI environment, and local testing Swarm works fine. But for production it's too weak. Fortunately for containers, they don't care what tool they're running under.


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds