For additional conference notes, check out Rob Hirschfeld’s Dockercon retro blog post.
Three Concerns with Immutable O/S on Physical
With a mix of excitement and apprehension, the RackN team has been watching physical deployment of immutable operating systems like CoreOS Container Linux and RancherOS. Overall, we like the idea of a small locked (aka immutable) in-memory image for servers; however, the concept does not map perfectly to hardware.
Note: if you want to provision these operating systems in a production way, we can help you!
These operating systems work on a “less is more” approach that strips everything out of the images to make them small and secure.
This is great for cloud-first approaches where VM size has a material impact in cost. It’s particularly matched for container platforms where VMs are constantly being created and destroyed. In these cases, the immutable image is easy to update and saves money.
So, why does that not work as well on physical?
First: HA DHCP?! It’s not as great a map for physical systems where operating system overhead is pretty minimal. The model requires orchestrated rebooting of your hardware. It also means that you need a highly available (HA) PXE Provisioning infrastructure (like we’re building with Digital Rebar).
Second: Configuration. That means that they must rely on having cloud-init injected configuration. In a physical environment, there is no way to create cloud-init like injections without integrating with the kickstart systems (a feature of Digital Rebar Provision). Further, hardware has a lot more configuration options (like hard drives and network interfaces) than VMs. That means that we need a robust and system-by-system way to manage these configurations.
Third: No SSH. Yes another problem with these minimal images is that they are supposed to eliminate SSH. Ideally, their image and configuration provides everything required to run the image without additional administration. Unfortunately, many applications assume post-boot configuration. That means that people often re-enable SSH to use tools like Ansible. If it did not conflict with the very nature of the “do-not configure-the-server” immutable model, I would suggest that SSH is a perfectly reasonable requirement for operators running physical infrastructure.
In Summary, even with those issues, we are excited about the positive impact this immutable approach can have on data center operations.
With tooling like Digital Rebar, it’s possible to manage the issues above. If this appeals to you, let us know!