Docker on VM vs bare install on VM
https://lemmy.world/post/23413638
=> More informations about this toot | More toots from machinin@lemmy.world
Containers are just processes with flags. Those flags isolate the process’s filesystem, memory, etc.
The advantages of containers is that the software dependencies can be unique per container and not conflict with others. There are no significant disadvantages.
Without containers, if software A has the same dependency as software B but need different versions of that dependency, you’ll have issues.
=> More informations about this toot | More toots from scott@lem.free.as
Thanks for this - the one advantage I’m noticing is that too update the services I’m running, I have to rebuild the container. I can’t really just update from the UI if an update is available. I can do it, it is just somewhat of a nuisance.
How often are there issues with dependencies? Is that a problem with a lot of software these days?
=> More informations about this toot | More toots from machinin@lemmy.world
But rebuilding your container is pretty trivial from the command line all said and done. I have something like this alias’d in my .bashrc to smooth it along:
Docker compose pull; docker compose down; docker compose up -d
I regularly check on my systems and go through my docker dirs and run my alias to update everything fairly simply. Add in periodic schedule image cleanups and it has been humming along for a couple years for the most part (aside from one odd software issues and hardware failures).
=> More informations about this toot | More toots from Passerby6497@lemmy.world
Is there a specific reason you’re taking the services down before bringing them back up? Just docker compose up -d recreates all services that had a new image pulled, but leaves the others running.
=> More informations about this toot | More toots from tofubl@discuss.tchncs.de
Probably just a hold over from when I was first learning. Had issues with a couple services not actually updating without it, so I just do it to be absolutely sure. Also, I only ever run one app per compose, so that forces a “reboot” of the whole stack when I update.
=> More informations about this toot | More toots from Passerby6497@lemmy.world
I know rebuilding containers is trivial, but updating a service in the UI is more trivial than that. I’m just trying to make my life as trivial as possible 😁. It seems like containers may be worth the little bit of extra effort.
=> More informations about this toot | More toots from machinin@lemmy.world
I mean, for anything where you’re willing to trust the container provider not to push breaking changes, you can just run Watchtower and have it automatically update. That’s how most of my stuff runs.
=> More informations about this toot | More toots from Voroxpete@sh.itjust.works
If you’re not using some sort of automatic updates, you’re not seriously trying to make your life as trivial as possible. 😂 Just use fixed major version tags where possible in order to avoid surprise breakage.
=> More informations about this toot | More toots from avidamoeba@lemmy.ca
I beg to disagree about the disadvantages. An important one is that you cannot easily update shared libraries globally. This is a problem with things like libssl or similar. Another disadvantage is the added complexity both wrt. to operation but also in general the amount of code running. It can also be problematic that many people just run containers without doing any auditing. In general containers are pretty opaque compared to os packaged software which is usually compiled individually for the os.
This being said, systemd offers a lot of isolation features that allows similar isolation to containers but without having to deal with docker.
=> More informations about this toot | More toots from callcc@lemmy.world This content has been proxied by September (3851b).Proxy Information
text/gemini