Why You Should Not Create Your Own OS Images For Your Cloud

And avoid some useless work

When you start playing with cloud providers you are quickly tempted to create your own OS images to make your deployments more convenient (as you may think at first). But this habit is usually too much of an overkill, add a lot work and can be very time consuming: you have to create and maintain a specific build process (or CI pipeline), you have to update your images regularly, and update your deployments accordingly (not to say that migrations can sometimes be a real challenge). I’m telling you, all of this can be prevented! How?

VM self-provisioning

Yes, let your VMs provision themselves. There are many provisioning softwares out there that will be a good fit for this (Ansible, Chef, Puppet, …), just choose the one you like the most or the one you are more familiar with.

How does that work?

Well whenever using a cloud provider (or your own virtualization software) you can configure your VM to run a script at startup (called UserData on AWS and OpenStack, CustomData on Azure). This requires your base image to have cloud-init installed but little chance this is not the case.

The whole idea is to have your provisioning scripts uploaded to your object storage, then just write a cloud-init script that first installs your provisioning software and the object storage client, next downloads scripts from the object storage and finally launches the provisioning. It’s that simple!

What are the advantages?

• As said in the introduction you no longer need to have a build pipeline, nor any VM replacement in your deployments.
• Updates are very easy: create a Cron task script that re-run the process regularly, upload your changes on your object storages, wait for the next time the task is scheduled and voilà!
• Most of provisioning tasks can easily be tested locally (Docker is a perfect tools for that). Evidently cloud related actions are more difficult to test but can still be test on a test VM.
• Scripts can be managed with your version controller software. So changes can be tracked and versioned.
• Most provisioning scripts can be shared across VMs and other projects.
• It actually saves you money! Hosting your own cloud images on your cloud provider is actually not free.

Is self-provisioning suited for every cases?

Well as you might guess the answer is no. There are still some cases where self-provisioning is not really appropriate:

• Your VM provisioning is taking too much time and this specific VM is used for auto-scaling services. As this type of VM are spawned when your application load is increasing, you don’t want to wait too long before scaling up your application and face the risk of having a bad user experience. In that case I would recommend using a mix of the two techniques: build minimal cloud images where time consuming tasks are performed, and delegate the rest to your provision tool to benefit its advantages.
• You can’t rely or you don’t have access to the Internet. This can be palliated with a local package repository.
• You have to perform an action that cannot be done by your provisioning software (but I doubt that is possible).

That’s all folk! I hope I have convinced you!