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

And avoid some useless work

Antoine Hamon
Feb 28, 2019 · 3 min read
Image for post
Image for post

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

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?

  • 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!

Nephely

Cloud Architecture, SRE, High-Availability, Microservices &…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store