Hi,
Advice on build Immutable VM’s ( VMware ) and is that possible using Ansible ?
What is the best way to do?
What do you mean by immutable VM?
Sounds like you're referring to a 'golden image'. A golden image is a static bootable image that is deployed when running up any VMs. I prefer this approach over the alternatives.
The golden image boots up but doesn't do anything useful. If you're using SSH for Ansible the golden image would have accounts and keys setup so that the Ansible server can login, became superuser and install what is needed to make the system useful.
Thus each class of host needed is built from a single image. The golden image can be periodically updated but some people deploy them in isolated networks and run security updates before moving them in to live networks.
A lot has been written about this online.
Rob
Hi all,
I wrote two articles about creating base images
- Automated installation of Windows Server 2012 r2 using Ansible - https://medium.com/@AbhijeetKasurde/ansible-automating-windows-server-2012-r2-installation-in-vcenter-227577f5917c
- Automated installation of CentOS 7 using Ansible - https://medium.com/@AbhijeetKasurde/automating-centos-7-installation-using-ansible-and-kickstart-483807a3774c
once installation is complete, you can mark the VMs as “Template”. These templates or golden images can be used to create new VMs.
I’ll second @abhijeet and the use of the “vmware_guest” and “vmware_guest_sendkey” modules. It permits you to completely build your templates from a known ISO from your vendor (validated with a SHA256 checksum), using a kickstart file of your own, and no human interaction. And if the checksum, kickstart, and “sendkeys” strings are all part of your code commit, then you’re getting well into “infrastructure as code”.
The “immutable” usually refers to container images brought in from an image repository, but the VMware template is a close analog to that. And if you can re-produce the same image (as you could with a base docker image), then it’s both immutable (at that level) and reproducable.
Thanks @abhijeet and @Dan,
In my environment i use Ansible for Configuration Management , Virtual Machines builds and lot more automation.
How can we make Virtual Machine ( Centos/Redhat linux OS ) immutable once vm deployed?
Hi
You didn’t respond to @raubvogel@gmail.com question whatmeant by immutable VMs, but @Robert Brockway did.
Assuming that explanation is what you mean, then making an immutable VM in your context is just turning it into a VMware template once it’s done building (and confirmed it’s working as expected etc).
Hi,
@raubvogel@gmail.com Immutable vm means once virtual machines deployed from gold image / template the virtual machine will be in read only like containers running in docker.
Thanks Rob,
In my environment I build VM from template, the main goal is how can I change/convert the virtual machine to immutable (read only).
An immutable vm in which servers are never modified after they’re deployed. If something needs to be updated, fixed, or modified in any way, new servers built from a common image with the appropriate changes are provisioned to replace the old ones. After they’re validated, they’re put into use and the old ones are decommissioned.
If you want to go to immutable VM or close to it then I think you should look at fedora CoreOS
An immutable vm in which servers are never modified after they’re deployed. If something needs to be updated, fixed, or modified in any way, new servers built from a common image with the appropriate changes are provisioned to replace the old ones. After they’re validated, they’re put into use and the old ones are decommissioned.
So the suggestions in the thread still meet your need, you just need to look at what you’re requesting from a slightly different angle.
From the Docker/Containers point of view, the “immutable image” is a binary container that your infrastructure uses to build the actual running “system” that handles your workload.
From the VM point of view, the “immutable image” IS the template image itself, not the VMs that are deployed. Once the VMs are running, it would be possible to kick off a patch process, or other installation steps. It would be a LOT of work to make the running VM truly “immutable” - and it would probably break a lot of services depending on the OS.
And a running container image built from one of the “immutable images” is just designed to be hard to login to make changes, but nothing is forcing it to not change. Most any container needs some level of access to create temporary files, adjust system settings to join a cluster, etc.
One of your first questions was:
How can we make Virtual Machine ( Centos/Redhat linux OS ) immutable once vm deployed?
Based on this early question, I suspect that part of your confusion is where the “immutable” descriptor applies. It does not apply to the VM that is running the workload (e.g. the web site, app server, database, etc). Rather, “immutable” describes the container image as it is stored in the container repository. This way if the developers use a build process fully contained within a Git repository, and the version (hash) of that process is "abcd1234, and it produces a docker/container image with a hash of 11223344, then you can be pretty safe knowing that as long as the container image hash is the same weeks later, the code within that image hasn’t changed. And your security team can audit the same build process - presumably able to confirm the abcd1234 hash - and they can also verify the container hash of 11223344 - then they are also comfortable knowing that no one outside your development chain has tampered with it.
If you find a week later that the container hash has changed to 43219876 (essentially “corrupt” for some reason), anyone can see that the containers are different and the sites should be redeployed from the known good containers. Assuming the container repository hasn’t been corrupted and the initial container image hash is still 11223344, then you can deploy from there and get rid of the corrupt one.
The “immutable” comes in because you’re never making code/configuration changes to the system that is running. If you do have to make a change (e.g. a patch, configuration update, etc) you use your build process to produce a new container, store it’s hash for future reference, then replace each of the old running images with a copy of this new image.
Back to your question…
You can use a lot of tools to build a new VM starting only with an ISO and known build process (kickstart files, ansible playbooks, ISO boot strings, etc). Once your process can use the stock (and well known) RedHat/CentOS/Ubuntu/Debian ISOs, boot a VM from it, and feed in the boot parameters so the system build is fully automated, then you’re able to produce the “immutable” VM template you were initially asking about. From there, your users can deploy full VMs starting with the latest version of the immutable VM template knowing that it is properly secured per your group or companies standards.