5 ms·
As a sysadmin I just want to point out to this mostly dev crowd, that my current favorite method of operations is to have multiple compartmentalized VM's which
by arca_vorago 10y ago
As a sysadmin I just want to point out to this mostly dev crowd, that my current favorite method of operations is to have multiple compartmentalized VM's which then may or may not hold containers or jails.
Why do I do it this way? Because having a full stack VM for each use-case on a good server is realistically not that much more resource hungry than a container, but the benefits are noticeable.
Lots of the core reason stems from security concerns. For example, there are quite a few Microsoft Small Business Server styled linux attempts at hitting the business space, but instead of playing to the strengths of modern hardware, they all mostly throw every service on the same OS just like SBS does... which is a major weakness. So instead of an AD server that also does dns and dhcp and the list goes on, each thing in my environments get it's own seperate VM (eg, SAMBA4 by itself, bind by itself, isc-kea by itself, and so on)
Another reason for this is log parsing related. It's much easier to know that when the bind VM OSSEC logs go full alert, I know exactly what to fix. On multi container systems, a single failure or comprimise can end up affecting many containerizations and convoluting the problem/solution process.
Of course, the main weakness to such a system is any attempt to break out of the VM space illicitly could comprimise many systems, but that's why you harden the VM's and have good logging in the first place, but also do it to the host system, along with using distributed seperation of hosts and good backups.
Just some real world usage from a sysadmin I wanted to convey. I still will do a container or a VM with many containers for the devs if needed, but when it comes time to deploy to prod, I tend to use a full stack VM. I'm also open to talk about weaknesses in this system, as I'd be curious to hear what devs think.
To be fair, I still haven't fully caught up with the whole devops movement either, so perhaps I'm behind.
Also, a big shoutout to proxmox for a virtual environment system, FOSS and production quality since 4.0. I have also run BSD systems with jails in a similar way. The key pont of the article is that zones/jails/vms are top level isolations and containers are not (but that doesn't make containers bad!)
- shamsalmon 10y agoHave you considered a solution like graylog for centralized logging with both the VMs and Containers? Thats what my company tends to do with clients and we frequently choose containers and multiple VMs together running something like docker stack. As long as you do proper security practices on the container itself, such as not running the application as root, I dont see any downside to running things in containers over VMs as long as you have proper logging. Combined with something like ansible or another config management you can automate this whole process and it works really well for us.
- arca_vorago 10y agoYeah I use graylog and elk stack and ansible already, there is still an isolation level with full VM's you don't get with containers. (namespace sharing issues, kernel-level system call attack issues, etc). Of course VM's have the same issues with the host OS, but there is a single layer more for an attacker to penetrate, and as we know, security is all about layers. On that note, a FOSS ansible tower alternative popped up on my radar recently that looks interesting. https://github.com/ansible-semaphore/semaphore https://github.com/ansible-semaphore/semaphore
- shamsalmon 10y agoThanks for sharing! Currently only using jenkins for our ansible deployments but this looks like a great WIP for an eventual replacement.
- greenshackle2 10y ago+1 for proxmox. I use it to run VMs and LXC containers at home for my toy projects.