Or maybe a two click solution? :)
this post was submitted on 28 Jun 2023
125 points (95.6% liked)
Selfhosted
40034 readers
577 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:
-
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!
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Self hosting what?
In general
It's so easy to self host these days. I remember when you'd have to fuck around with Apache configs and fuck around with app config files etc. Now you just run docker. It's so great these days!
I'm still fucking with the apache configs (I fucking hate apache...). As someone with no docker experience whatsoever, are there any getting started guides you would recommend for someone looking to make the switch?
Youtube offers a lot of material on what Docker is and how it works.
For ease of use, you can use Portainer, which makes managing docker containers very simple
There's also Yacht, that has some predefined packages that you can install.
Oh, those were the days :D Apache + PHP + MySQL. Then multiple hosted software on that same server. You were screwed when one app needed newer PHP and some other stuff didn't run with new PHP.
haha yeah. Those were the days. Kids these days have it easy. Did I mention "Get off my lawn!"?
Oh, and different libraries, and compiling software to get the features you need, and the pain of moving something from one server to another because there was some unique weird environment setup needed on the host just to get it running.
And these days, just docker the shit out of everything.
Also learn how to translate docker commands to docker-compose.yml
docker-compose helped me wrap my head around docker. I can use run commands now, but prefer to either modify a compose file or create my own to spin things up.
Same here. I kept using the docker run commands that usually show up in Docker hub but started making my own compose files. So much cleaner feeling. I can keep everything all nice and neat in a single folder now. Makes backing up much easier too.
Running stacks is easier too. My entire media stack minus Plex is all in the same compose file. Need to change anything, just edit the docker-compose and up -d
Yep, this is what I do with my "media acquisition" stuff. I have Jackett, Sonarr, Radarr, Transmission all run from a single compose file.
I agree but use docker-compose instead!
Docker with Portainer and Nginx Proxy Manager makes things incredibly easy.
I might add that don't just mindlessly copy-paste things. Try to understand what those commands do and why they are needed.
Okay. I keep reading about docker. What's the difference between a docker and just installing an app on rented server space?
Does each dock (?) have its own server? (Apache or nginx or whatever?)
Does each dock host a whole site, or do you have a dock for your database and a dock for your web app?
Docker is basically a virtual machine image you write your software in. Then when you run the software you don’t need to worry about compatibility or having the right dependencies installed, it’s all included in the docker image.
Think of Docker as being Nintendo cartridges that you can take to any friends house, plug them in, and play. Servers can run more than one Docker container.
The approach greatly simplifies writing code and having it work on your server, reduces errors, and adds a layer of security.
I've read and reread, listened and relistened to info on docker/containers and I still feel like I'm missing something tbh.
Let's say you have a docker container for something and it's for a Linux distro, that won't run on another OS, will it? Maybe not even a different Linux distro from the one it was made for (e.g. Ubuntu or Arch or Fedora or whatever).
To go off your example, Docker's not like an expansion module to make your Switch games work on a PlayStation or Xbox...Right? There seems to be some kind of mixed messaging on this, the way they're so readily recommended (which seems to be related to a presumption of familiarity that often isn't there toward those inquiring).
I guess I've also been confused because like...Shouldn't old installers handle bundling or pulling relevant dependencies as they're run? I'd imagine that's where containers' security benefits come into play though, alongside being virtualized processes if I'm not mistaken.
For simplicity its easiest to imagine it as a simulator or emulator. Its not trying to be your machine (called the host machine) pretend it doesn't actually use your os, or software.
Imagine each container is a fresh new machine on your desk with a blank hard drive. The image is basically the result of a set of instructions (a Dockerfile) that docker follows to install all the stuff you need to get the machine running.
Normally it starts by installing an os like alpine Linux (alpine publish this docker image and you simply build on top of that)
Then you install any extra utilities and software you might need to run the programming, maybe python or Java (again there are images themselves based on alpine managed and updated by official sources)
Finally you install what you want and tell the computer that's what to run when it boots up (often the software you want to run gives an official docker image which has done all this for you)
So when you run a docker image its actually done all this setup for you already and just stored the resultsin a way that it can apply it straight to your shiny new container in an instant and be ready.
Docker compose is instructions on how to set up a bunch of computers with a network.
Functionally? Not much. But people who selfhost typically want everything on computers they own. Whether it's for learning purposes, or to not have their stuff on "someone else's computer" selfhosting usually means you're running software on computers you own, almost always within your own house.
Each docker image usually has a web server built in. The philosophy of docker is that it contains everything needed to run the app. Even a small linux OS (LibELEC or Alpine are favorites for docker images). So while you're not managing the web server in a docker image each docker image will have its own web server if web access is needed
Docker the program is what runs all the docker images on a computer. Each docker image is built as per the software's developer. Some docker images will have a web app and a database combined into a single image, while others will expect a separate database server running independent of the image (It won't care if the database server is a docker image or not; just that it has access)
Thanks!
To be fair thats pretty much the IT gig in general, not the docker part but the rest copy/paste run commands, then learn from whatever you screw up couple of years later you might very well end up working in IT
I think that is not just IT, but a lot of other fields as well