What is infrastructure as code and why do you need it? – The Next Web

As DevOps grows, it helps to know about how it works. One of the big things in DevOps is infrastructure as code. This means that you treat your infrastructure the exact same as you would treat your application code. So youll check it into version control, write tests for it, and make sure that it doesnt diverge from what you have across multiple environments.

Handling infrastructure as code prevents problems like unexpected code changes and configuration divergence between environments like production and development. It also ensures that every deployment you do is the exact same. You dont have to worry about those weird differences that happen with manual deploys when this is implemented correctly.

Something else to consider is that you dont need to use different programming languages, like Python or Go. There will be some tool specific languages, but those are usually simple and have great documentation around them. The main thing youre changing with infrastructure as code is the way that you handle your systems.

Instead of logging into a server and manually making changes, youll use a development approach to work on these tasks. That means you wont have to deal with a lot of issues that only one person in the company knows about. This way, everyone has the ability to update and deploy changes to the infrastructure and the changes are preserved the same way code is when you check it into version control.

While infrastructure as code helps with many aspects of getting and keeping a reliable version of your app on production, it really adds value when you add automation to it.

One of the first things you want to look at is how you take your code and make it into an artifact. An artifact is any deployable element that is produced by your build process. For example, when you are working with an app built in React, you know that the npm build command produces a build directory in the root of your project. Everything in that directory is what gets deployed to the server.

In the case of infrastructure as code, the artifacts are things like Docker images or VM images. You have to know what artifacts you should expect from your infrastructure code because these will be versioned and tested, just like your React app would be. Some examples of infrastructure artifacts include OS packages, RPMs, and DEBs.

With your artifacts built, you need to test them just like you would with code. After the build is finished, you can run unit and integration tests. You can also do some security checks to make sure no sensitive information is leaked throughout the process.

A few tools you might write infrastructure automation with include Chef or Ansible. Both of these can be unit tested for any syntax errors or best practice violations without provisioning an entire system.

Checking for linter and formatter errors early on can save you a lot of unnecessary problems later because it keeps it consistent no matter how many developers make changes. You can also write actual tests to make sure that the right server platforms are being used in the correct environment. You can also check that your packages are being installed as you expect them to be.

You can take it to the next level and run integration tests to see if your system gets provisioned and deployed correctly. Youll be able to check to make sure the right packages get installed and that the services you need are running on the correct ports.

Another type of testing you can add to your infrastructure code is security testing. This includes making sure youre in compliance with industry regulations and making sure that you dont have any extra ports open that could give attackers a way in. The way youll write tests will largely depend on the tools you decide to use and well cover a few of those in the next section.

Testing is a huge part of automating infrastructure as code because it saves you a lot of debugging time on silent errors. Youll be able to track down and fix anything that might cause problems when you get ready to deploy your infrastructure and use it to get your application updates to production consistently.

The tools you use will help you build the infrastructure code that you need for your pipelines. There are a number of open-source and proprietary tools available for just about any infrastructure needs you have.

Some of the tools youll see commonly used in infrastructure as code include:

The specific tool you decide to go with will depend on the infrastructure and application code you already have in place and the other services you need to work with. You might even find that a combination of these tools works the best for you.

The most important thing with infrastructure as code is to understand everything that goes into it. That way you can make better decisions on which tools to use and how to structure your systems.

When you hear people talking about provisioning, it means that they are getting the server ready to run what you want to deploy to it. That means you get the OS and system services ready for use. Youll also check for things like network connectivity and port availability to ensure everything has connections to what they need.

Deployment means that there is an automatic process that handles deploying apps and upgrading apps on a server. Another term youll hear a lot is orchestration. Orchestration helps coordinate operations across multiple systems.

So once your initial provisioning is finished, orchestration makes sure you can upgrade and a running system and that you have control over the running system.

Then theres configuration management. It makes sure that applications and packages are maintained and upgraded as needed. This also handles change control of a systems configuration after the initial provisioning happens. There are a few important rules in configuration management.

The more complex your infrastructure becomes, the more important it is for these basic rules to be followed.

If youre wondering how you use these tools to make something useful, it highly depends on what systems youre working with. If youre working with simple applications, it might be worth looking into setting up AWS CloudFormation. If youre thinking about going with microservices, Docker might be a good tool to use along with Kubernetes to orchestrate them.

If youre working with a huge distributed environment, like a corporate network that has custom applications, you might consider using Puppet, Conducto (my company), or Chef. If you have a site with really high uptime requirements, you might use an orchestration tool like Ansible or Conducto.

These arent hard rules you should follow because all of these tools can be used in a number of ways. The use cases Ive mentioned here are just some of the common ways infrastructure as code tools are used. Hopefully these use cases give you a better idea of how useful infrastructure as code can be.

Published October 19, 2020 08:00 UTC

Visit link:
What is infrastructure as code and why do you need it? - The Next Web