Selfhosted
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:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
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.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
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!
view the rest of the comments
There have been some great answers on this so far, but I want to highlight my favourite part of Docker: the disposability.
When you have a running Docker container, you can hop in, fuck about with files, break stuff as you try to figure something out, and then kill the container and all of the mess you've created is gone. Now tweak your config and spin up a fresh one exactly the way you need it.
You've been running a service for 6 months and there's a new upgrade. Delete your instance and just start up the new one. Worried that there might be some cruft left over from before? Don't be! Every new instance is a clean slate. Regular, reproducible deployments are the norm now.
As a developer it's even better: the thing you develop locally is identical to the thing that's built, tested, and deployed in CI.
I <3 Docker!
What about your preferences/configs/files (when you spun up a fresh one)?
The most popular way of configuring containers are by using environment variables that live outside the container. But for apps that use files to store configuration, you can designate directories on your host that will be available inside the container (called "volumes" in Docker land). It's also possible to link multiple containers together, so you can have a database container running alongside the app.
If you have all of that set up then, what benefit is there to blowing away your container and spinning up a 'fresh' one? I've never been able to wrap my head around docker, and I think this is a big part of it.
There's a lot more to an application than its configuration. It may require certain specific system libraries, need a certain way of starting up, or a whole host of other special things. With a container, the app dev can precreate a perfect environment for their program and save you LOADS of hassle trying to set it up.
The benefit of all this is that you can know exactly where application state is stored, know that you're running the app in it's right environment, and it becomes turbo easy to install updates, or roll back if needed.
Totally spin up a VM, install docker on it, and deploy 2-3 web apps. You'll notice that you use the same way of configuring them, starting and stopping them, and you might not want to look back ;)
I've played with it a bit. I think I was using something called DockStarter and Portainer. Like I said though, I could never quite grasp what was going on. Now for my home webapps I use Yunohost, and for my media server I use Swizzin CE. I've found these to be a lot easier, but I will try Docker again sometime.