Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Help about MediaWiki
FUTO
Search
Search
Appearance
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Introduction to a Self Managed Life: a 13 hour & 28 minute presentation by FUTO software
(section)
Main Page
Discussion
English
Read
Edit
Edit source
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
Edit source
View history
General
What links here
Related changes
Special pages
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
= Why I Used Virtual Machines Instead of Docker for Some Parts of My System = <span id="feel-free-to-skip-this-section-scroll-down-to-understanding-the-basics-of-docker-section"></span> == FEEL FREE TO SKIP THIS SECTION & SCROLL DOWN TO ''“Understanding the basics of Docker”'' section == '''This is another section that is completely unnecessary to read if you simply want to get to a working system. Feel free to fast forward to the ''“Understanding the basics of Docker”''. This is here to provide insight into why I structured the guide the way I did.''' Docker is a great way to managing programs in lightweight, isolated environments. It changed how sysadmins deploy and maintain their systems. Virtual machines are going out of fashion for many sysadmins; but in this guide, you’ll notice that I’ve grouped certain services into '''virtual machines ''' instead of using Docker for everything. Let me explain why <span id="building-my-system-piece-by-piece"></span> == 1. Building My System Piece by Piece == Back when I started getting into self managing my own servers 15 years ago, my setup wasn’t built all at once. It was cobbled together using the hardware I had lying around; old laptops, physical servers & spare drives. As these machines aged, broke, or were [https://www.youtube.com/watch?v=X86F1j5gCQs bashed in with a titanium nightstick when they frustrated me], I started turning their hard drives into virtual machines. This was as simple as using <code>ddrescue</code> to create an image of the working hard drive, then using Virtual Machine Manager to run that image. * '''Why not Docker?''' By the time docker even came out(around 2013), I already had 3 virtual machines that were created from disk images of machines that were running in my closet or my store. At the time, Docker didn’t even exist. Rebuilding everything using docker from scratch once it came out wasn’t an efficient use of time while running a business & [https://www.youtube.com/watch?v=qFVwQCFhKSE wasting most of my spare time fighting my state’s incompetent government]. <span id="time-efficient-migration-from-physical-to-virtual"></span> == 2. Time-Efficient Migration from Physical to Virtual == Taking a physical server and turning it into a virtual machine takes no effort. # Pull drive out of physical server. # Run <code>ddrescue -f -d -r 3 /dev/sdb phonesystem.iso</code> # Open virtual machine manager # Enter a few commands in terminal to create a bridge network interface so the virtual machines work; once done, I never have to do this again for any other virtual machine. # Import the <code>phonesystem.iso</code> file as a virtual machine. # Mess with BIOS/UEFI settings if necessary in virtual machine manager to get it to work. # Assign the virtual machine the amount of CPU cores/RAM I think it should have based on what it is doing. # Run it. # Be happy. It only takes a few seconds to type the commands & click the icons necessary in virtual machine manager. Compare that to re-architecting the entire system for Docker: it would have taken way more effort, downtime, etc. for an improvement in performance I will never notice as a person who has a few users for my server. Some of these servers were running years before Docker was a thing, & fixing what wasn’t broken made no sense. Virtual machines offered a way to keep my systems running as they were once the hardware died & have them set to back up with no extra work on my part. Over the years, I changed to using programs that were in docker exclusively. I went from a normal nextcloud deployment where I manually installed everything from scratch(including dependencies) to immich for images which was all docker. I went from self-managed email where the individual components(mailcot, dovecow, mysql, rspamd, etc.) were all installed from scratch to mailcow. Along the way, I just installed the dockerized version of the program on the virtual machine that was assigned to that “group” of services <span id="certain-programs-arent-built-for-docker"></span> == 3. Certain Programs Aren’t Built for Docker == Not every program is Docker-friendly. For example: * '''FreePBX (or PBXinaflash):''' You ''could'' theoretically create a custom Docker setup for these, but it would involve a ridiculous amount of work with little to no benefit for someone with my number of users(1, me, or 1 or 2 other people sometimes). For my use case (& most home users), the performance penalty of using FreePBX in a virtual machine instead of dockerized is as noticeable as using '''Gentoo Linux''' with <code>emerge</code> to compile the entire thing from a stage 1 tarball vs. using gentoo with <code>apt</code> to install programs. * '''Home Assistant:''' The developers themselves recommend using their pre-built VM image (HaOS) instead of Docker. If the devs think it’s better, I’m not going to argue. I can barely write a zfs health monitoring email script. Who am I to argue with the developers of the best home automation software on earth on the best way to run their program? Even if I wanted to use Docker for everything, I’d still have at least two VMs running. Adding another one or two doesn’t bother me. <span id="idiotproof-backups---the-most-important-one"></span> == 4. Idiotproof backups - the most important one == This is a beginner’s guide. Backing up Docker volumes, containers, networks, images, and configs is 100% doable. But let’s be honest, it requires some degree of competence. Backing up a virtual machine, on the other hand, is '''completely idiot-proof.''' * A virtual machine backup is just a single <code>.qcow2</code> disk image and a single <code>.xml</code> configuration file. Drag and drop those two files to another system, import them into Virtual Machine Manager, and the virtual machine runs. * There’s no need to rebuild Docker containers, recreate volumes, or edit <code>docker-compose.yml</code> files. It’s so simple that someone with absolutely no technical expertise could do it in one click. * Infact it is so easy that even I can do it. If I can do it, it is truly idiotproof. The backup script I provide is one I use myself. Once a week, it backs up all of my virtual machines as well as their configuration files to a ZFS pool which will continue running even if several hard drives fail. If I screw something up, it is two terminal commands or a few clicks in the GUI & I’m back up & running as if nothing stupid ever happened. '''For beginners, when it comes to backups, simplicity is priceless.''' Added complexity means you are less likely to ''use'' your backup system & less likely to ''understand'' how restoring from a backup works. <span id="why-this-guide-uses-virtual-machines"></span> == Why this guide uses virtual machines == In this guide, I’ve grouped services into virtual machines because it mirrors how I built my system over the past 15 years. This approach makes it easier for total beginners to back up and restore their setups without worrying about the complexities of Docker. Here’s how I’ve organized the VMs: # '''Android Services:''' Alternatives to Google Drive, Google Photos, and Google Docs. # '''Identity and Communication Services:''' Alternatives to Gmail, Google Calendar, Google Contacts, and Google Chrome’s password manager. # '''Phone System:''' FreePBX for managing calls. # '''Home Automation:''' Home Assistant for smart home management. <span id="you-do-not-have-to-do-anything-this-way-if-you-dont-want-to."></span> == You do not have to do anything this way if you don’t want to. == You’re welcome to adapt this setup, or not. If you prefer Docker, you can combine many of these services into one host system. However, I still recommend using virtual machines for the following: * '''FreePBX:''' The extra effort required to make this work in Docker isn’t worth it. * '''Home Assistant:''' The HaOS image is the easiest and most reliable way to run Home Assistant, as per the developers’ recommendations. This guide wasn’t about doing everything new - it was about all of you asking how ''I'' had set up ''my'' system. Since my system works for everything under the sun & has continued to for longer than I’ve been allowed to buy alcohol, I keep it going. <span id="understanding-the-basics-of-docker"></span>
Summary:
Please note that all contributions to FUTO may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
FUTO:Copyrights
for details).
Do not submit copyrighted work without permission!
To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:
Cancel
Editing help
(opens in new window)