Should I be learning docker compose instead of relying on dockStarter to manage my containers? I got portainer up, should I just use that to manage my stack?
I’m committed this summer to finally learning docker. I’m on day 3 and the last puzzle piece is being able to access qbittorrent locally while running the container through the vpn.
You must log in or register to comment.
I recommend Dockge over Portainer if you want a web admin panel. https://github.com/louislam/dockge
It’s basically docker compose in a website, and you can just decide one day to turn it off and use the compose files directly. No proprietary databases or other weirdness.
Seconded, have been using it for a while and its simple and great!
Thirded. It’s helped me a lot with picking up the compose syntax, to the point that I’m now comfortable combining disparate services into their own stacks. And I can spin something up from an example compose in less than a minute.
And it will convert a docker run command to a compare file.
And it has a beta feature where you can point it at a second server and it will manage that too.
I’ve not used dockge so it may be great but at least for this case portainer puts all the stack (docker-compose) files on disk. It’s very easy to grab them if the app is unavailable.
I use a single Portainer service to manage 5 servers, 3 local and 2 VPS. I didn’t have to relearn anything beyond my management tool of choice (compose, swarm, k8s etc)
It doesn’t seem to have the webhooks functionality that Portainer has though.
It also works in the “other” direction- if you’re already using compose files, you can point dockge to their existing location (stacks directory) and it will scan and pick them up!
That’s the one I use exactly because of that. I know compose, not going to learn another program to do the same, just want something that gives me an easier way to edit them than sshing into my box and using an editor.
Never heard of dockStarter so I’m gonna say yes
Compose is good for getting started, and might be sufficient for a long time. Eventually I moved to k8s but I also use that for work so it was an easy move for me.
I just started working with k8s (OpenShift). I don’t see myself switching my private setup to k8s. How long did it take you to be comfortable with it that you made that decision?
I started learning k8s about 5 years ago, and in about 8 months I was ready to setup k3s at home and manage everything with ArgoCD.
Approximately 3 years ago I set up a second cluster on digital ocean and moved some workloads to that, including ArgoCD which manages both the remote DO cluster and the home k3s cluster
@synae @Mountain_Mike_420 your using K8s at home isn’t that overkill.
If you’re learning in any kind of professional capacity, you may want to get familiar with running things on k8s. I would never deploy Compose in any kind of production environment.
I would never deploy Compose in any kind of production environment.
May I ask you why?
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
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.
Yah, IMO, if your goal is to learn how to really use and maintain Docker, then you don’t want a script getting in the way. Also IMO, DOcker is not that hard to learn (not that I am an expert yet).
I would recommend it as it is fairly easy to understand and most Foss services give you an example to use. You can also convert docker run examples to compose (search docker composeriser) although it doesn’t always work.
I found composer files easier when learning it, to digest what is going on (ports, networks, depends_on etc) and can compare with other services to see what is missing (container name, restart schedule etc). I can then easily backup the compose files, env files and data directories to be able to very quickly get a service up again (although DBs are trickier but found a docker image that I can stick on the compose files which backups the DB dumps regularly)
I’ve been using DockSTARTer for years and it does what I need, when I need it.
If the goal is to learn, then go for learning Docker directly.
If the goal is to do it well and quickly, don’t reinvent the wheel.
i used dockStarter for a while, but ultimately moved away from it to roll my own docker-compose. This was a few years ago though.
For me, i always want to make it fit with how i want to run my server, so a lot of the times i wanted to adjust the settings. The other big thing is that I always find services not in the library, so need to learn it anyway.
There is nothing (i dont think) stopping you from doing both!
Yes, in an ideal world, you would learn all the tools the software offers so when a third party tool come along you know what problem it is trying to solve.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters HA Home Assistant automation software ~ High Availability VPS Virtual Private Server (opposed to shared hosting) k8s Kubernetes container management package
3 acronyms in this thread; the most compressed thread commented on today has 17 acronyms.
[Thread #781 for this sub, first seen 3rd Jun 2024, 13:15] [FAQ] [Full list] [Contact] [Source code]
Just go for kubernetes
/s
