ProxMox is what’s known as a HyperVisor or Virtual Machine. The general concept is that each element in ProxMox is an entire operating system, with each service configured in those operating systems. This requires maintaining and configuring an operating system for each service you want to run, or if you install multiple services in a singe host node, you’re back to the config conficts that we’re trying to avoid in the first place.
Docker’s approach is different. With Docker, You can use any host, including a daily desktop OS with many sort of half-VMs that only have access to specific parts of the system as defined in the Docker configuration. For instance, if you just need a service that handles chat, it doesn’t need to access much outside its own data and a port to access the internet. So instead of needing to manage the OS and the service, you’re left with just the service.
Another major boon is that it’s very easy to simply turn them off and back on and have them revert to their working state. If you really manage to screw up a configuration, no more digging through the OS to try and figure out what you can and can’t delete. You just nuke the system and try again. Outside writing the changes, it takes just a few seconds to reboot the service.
And one last bonus is that again, it’s very portable when using Docker Compose. Docker Compose takes this a step further and lets you configure the entire service through a single config file. You can put together multi-service database applications with a copy-paste and a few changes to the config. Absolutely massive time saver for people like me who are terrible at managing database applications, but really enjoy the benefits of them.
I used to do the VM approach, but having one script to one service works way better for me personally.
Can you elaborate? I’m still exploring what is best.
ProxMox is what’s known as a HyperVisor or Virtual Machine. The general concept is that each element in ProxMox is an entire operating system, with each service configured in those operating systems. This requires maintaining and configuring an operating system for each service you want to run, or if you install multiple services in a singe host node, you’re back to the config conficts that we’re trying to avoid in the first place.
Docker’s approach is different. With Docker, You can use any host, including a daily desktop OS with many sort of half-VMs that only have access to specific parts of the system as defined in the Docker configuration. For instance, if you just need a service that handles chat, it doesn’t need to access much outside its own data and a port to access the internet. So instead of needing to manage the OS and the service, you’re left with just the service.
Another major boon is that it’s very easy to simply turn them off and back on and have them revert to their working state. If you really manage to screw up a configuration, no more digging through the OS to try and figure out what you can and can’t delete. You just nuke the system and try again. Outside writing the changes, it takes just a few seconds to reboot the service.
And one last bonus is that again, it’s very portable when using Docker Compose. Docker Compose takes this a step further and lets you configure the entire service through a single config file. You can put together multi-service database applications with a copy-paste and a few changes to the config. Absolutely massive time saver for people like me who are terrible at managing database applications, but really enjoy the benefits of them.