On Tuesday, October 27, 2020 at 2:41:06 AM UTC-5 SP wrote: > 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. -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/2289946e-1b26-47dc-97a3-6c39b7531db0n%40googlegroups.com.
