this post was submitted on 13 Dec 2023
1 points (100.0% liked)

Selfhosted

40183 readers
546 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:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. 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.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
1
Should I move to Docker? (lemmy.ca)
submitted 11 months ago by [email protected] to c/[email protected]
20 comments fedilink hide all child comments
 

I'm a retired Unix admin. It was my job from the early '90s until the mid '10s. I've kept somewhat current ever since by running various machines at home. So far I've managed to avoid using Docker at home even though I have a decent understanding of how it works - I stopped being a sysadmin in the mid '10s, I still worked for a technology company and did plenty of "interesting" reading and training.

It seems that more and more stuff that I want to run at home is being delivered as Docker-first and I have to really go out of my way to find a non-Docker install.

I'm thinking it's no longer a fad and I should invest some time getting comfortable with it?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 0 points 11 months ago (1 children)

Yeah, it also has the effect that when starting up say a new postgres or web server is one simple command, a few seconds and a few mb of disk and ram, you do it more for smaller stuff.

Instead of setting up one nginx for multiple sites you run one nginx per site and have the settings for that as part of the site repository. Or when a service needs a DB, just start a new one just for that. And if that file analyzer ran in it's own image instead of being part of the web service, you could scale that separately.. oh, and it needs a redis instance and a rabbitmq server, that's two more containers, that serves just that web service. And so on..

Things that were a huge hassle before, like separate mini vm's for each sub-service, and unique sub-services for each service doesn't just become practical but easy. You can define all the services and their relations in one file and docker will recreate the whole stack with all services with one command.

And then it also gets super easy to start more than one of them, for example for testing or if you have a different client. .. which is how you easily reach a hundred instances running.

So instead of a service you have a service blueprint, which can be used in service stack blueprints, which allows you to set up complex systems relatively easily. With a granularity that would traditionally be insanity for anything other than huge, serious big-company deployments.

[–] [email protected] 1 points 7 months ago

Instead of setting up one nginx for multiple sites you run one nginx per site and have the settings for that as part of the site repository.

Doesn't that require a lot of resources since you're running (mysql, nginx, etc.) numerous times (once for each container), instead of once globally?

Or, per your comment below:

Since the base image is static, and config is per container, one image can be used to run multiple containers. So if you have a postgres image, you can run many containers on that image. And specify different config for each instance.

You'd only have two instances of postgres, for example, one for all docker containers and one global/server-wide? Still, that doubles the resources used no?