43
Is dockStarter a waste of time?
(lemmy.ml)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 03 Jun 2024
43 points (97.8% liked)
Selfhosted
40152 readers
515 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
Aside from the myriad issues it has on its own, the easiest answer is: it doesn't scale on multiple machines and instances.
Example: I have 10 services in a compose file, and I need each service to scale independently across multiple servers. Which is easier, more reproducible, and reliable: controlling the docker compose state across many instances, or communicating with a central management service with one command to do it all for me?
What you need then is swarm compose, that can run any service in global mode (in all nodes all the time) or scale mode.
No, then you're just orchestrating the service level stuff, and nothing else. Docker's tools will never compare to cluster scaling efforts where the entire horizontal layer to be scaled can be orchestrated from the instance up to containers.
not sure I understand you, in docker swarm your containers are started on n number of works from a single compose file on a manager. you can add any number of work nodes to scale your service as needed
N number of EXISTING nodes. Proper container orchestration platforms handle all the provisioning of instances, scaling of services, IAM...etc.
Docker Swarm (and all Docker tools) only handle...Docker.
Swarm is another thing I would never recommend in production.
That's not container orchestration, that's infrastructure orchestration. Depending on your use case docker swarm could just the right tool for the job.
You've been using Aws and they will happily let you add more nodes to your container runner of choice
No, it's container orchestration. As-in "I orchestrate all the scaling needed to run and scale the containers".
Sure, but what you are describing is the problem that k8s solves.
I've run plenty of production things from docker compose. Auto scaling hasn't been a requirement, and HA was built into the application (so 2 separate VMs running the compose stack). Docker was perfect for it, and k8s would've been a sledgehammer.
K8s isn't the only container orchestration platform out there, it's just what is the widely used flavor right now. Any of the micro clusters would still be better than the Docker tools, for a multitude of reasons, and if someone is learning about this right now, they might as well put the effort forth to get familiar.
I've never seen a large scale Compose or Swarm cluster, and wouldn't be working for a team who ran such things. Alternatives would also be: ECS (if on AWS), Openshift, Rancher, and most other cloud platforms have some form of their own that handles provisioning, as well is IAM/RBAC seamless integrations, and other networking integrations for whatever platform.