Configuring without CM

Posted by in Devops, Startup, Technology

Configuration Management is one of the best things you can have in your infrastructure. It gives you a clear picture of what and where things would be running, it gives you the capability to involve the software design principles in your infrastructure design. But there are times where you don’t actually need CM, because they come with some overhead. For organizations, who don’t want to adopt to a full-scale CM can use something like FSS.

Who should use this?

People who have services, where the machine configuration changes once or twice in a month. For such people incorporating CM might be time taking and not a necessary step at that moment. You might want to focus on other aspects of your DevOps activities, and probably visit this later.

So how to configure without CM?

Simple terms, AMI/Image versioning. So you use incremental change method, where you add/subtract items and give it a new version and store it, and then use this to launch machines.

Base Linux Image
First, you should have a Base Linux AMI. This image should contain all your common applications/services which you want to keep in all machines. Things like monitoring scripts, alerting scripts, access control goes over here. You can also add scripts which can add proper hostnames based on your standard nomenclature policy. This base Linux image will rarely change, but whenever you change the content of this image you will need to upgrade all your individual service images.
Using this base image will:
– help you launch any custom machine requirements faster,
– automatically plug it in all your alerting/monitoring systems.

Individual Service Image
This image is launched from base Linux image and you install all your required package on top of the base, once you are ready. You create a image out of it and store it. Don’t forget to keep this versioned. This same image can then be used for Autoscaling and other requirements.

Note: The machines will just have the latest required software packages, not the application code. If you frequently change your code then you need to have a mechanism to pull the latest build.  If you don’t have build mechanism, then you can consider triggering a deployment on the machine whenever a new machine launches via auto scaling.

If your release cycles are not that frequent, then you can actually consider keeping images with application code. But having a defined build process is recommended any day.