Selfhosted

60810 readers

732 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:

Detailed Rules Post

Be civil.
No spam.
Posts are to be related to self-hosting.
Don't duplicate the full text of your blog or readme if you're providing a link.
Submission headline should match the article title.
No trolling.
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.

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 3 years ago

MODERATORS

curbstickle@anarchist.nexus

curbstickle_lw@lemmy.world

How do you manage your Docker-compose or Podman data? (discuss.tchncs.de)

submitted 2 years ago by smileyhead@discuss.tchncs.de to c/selfhosted@lemmy.world

11 comments fedilink hide all child comments

All the times I just put docker-compose.yml to one user (my user) directory and call it a day.

But what about a service with multiple admins or with more horizontally split up load?

you are viewing a single comment's thread
view the rest of the comments

[–] eager_eagle@lemmy.world 3 points 2 years ago* (last edited 2 years ago) (1 children)

I had Portainer setup, but it was clunky and the web UI added little value.

Now I just have a local git repo with a directory for each compose stack and run docker compose commands as needed. The repo holds all yaml and config files I care to keep track. Env variables are in gitignored .env files with similar .env.example in version control. I keep sensitive info in my password manager if I have to recreate a .env from its example counterpart.

To handle volumes, I avoid docker-managed volumes at all costs to favor cleaner bind mounts instead. This way the data for each stack is always along with the corresponding configuration files. If I care about keeping the data, it's either version controlled (when mostly text) or backed up with kopia (when mostly binary).

[–] retrodaredevil@lemmy.world 2 points 2 years ago

I do something similar, but I avoid gitignore at all costs because any secret data should have root read only permissions on it. Plus any data that is not version controlled goes in a common directory, so all I have to do is backup that directory and I'm good. It makes moving between machines easy if I ever need to do that.