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.

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)

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.

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!

Just go for kubernetes

/s

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

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]