Get Puppet Enterprise First 10 nodes are free!
Try it now
Request a demo
Automate IT and infrastructure, manage complex workflows, and mitigate risk at scale.
Try the full-featured Puppet Enterprise for free on 10 nodes.
Puppet Comply Find and prevent compliance failures
Compliance Enforcement Modules Remediate to stay in compliance
Continuous Delivery for Puppet Enterprise Build, test, and deploy infrastructure as code faster and easier
Content & Modules Pre-built scripts to automate common tasks
CentOS EOL Here’s how to secure your CentOS infrastructure – even after EOL.
Find thousands of component modules built by the community and guidance on using them in your own infrastructure.
Visit Puppet Forge >>
Open Source PuppetPerfect for individuals and small infrastructure
BoltAutomate tasks in orchestration workflows
See all open source projects >>
Contribute to open source projects >>
As IT organizations wrap their heads around DevOps, there’s one term they often find being used with "DevOps": infrastructure as code. It's an important term to understand because it's one of the essential elements of managing infrastructure at scale, and it's also at the very core of DevOps.
Table of Contents
Infrastructure as code (IaC) is the practice of treating infrastructure as if it were code — just like software. Infrastructure as code enables organizations to automate tasks and processes that would otherwise be done manually, like managing infrastructure and provisioning resources.
Treating infrastructure as if it were code lets you adopt powerful practices that have been used by software developers for years, and with great success — practices that include version control, peer review, automated testing, release tagging, release promotion, and continuous delivery.
Infrastructure as code collects information like configurations, resource dependencies, resource properties, instructions, access, and version control information to enable automation.
The older methods of infrastructure management — manual processes and documentation, brittle single-purpose scripts, and graphical user interface based tools — each had their uses in the past. Today, though, with the perpetual need to scale infrastructure, adoption of ephemeral infrastructure, and greater application system complexity, new ways of keeping things under control are needed.
The wide adoption of virtualization and self-service cloud infrastructure has shifted the bottleneck from allocating servers to configuring them. Where it used to take weeks or months to allocate a server, now it can be done in a minute or two.
These new challenges require a change to the way IT works, but the primary challenges are the same as they’ve always been:
To address these challenges at modern scale (both in terms of infrastructure and organization), while still keeping up with the needs of the business (not to mention keeping the lights on), you need new methods of collaborating, delivering, and gaining situational awareness.
Infrastructure as code tools re used to automate the creation, deployment, and management of infrastructure resources. Tasks that can be automated by an infrastructure as code tool include:
Creating and provisioning servers
Puppet is just one example of a platform that provides infrastructure as code provisioning and configuration. Terraform, Ansible, Chef, and Saltstack offer different capabilities to meet your infrastructure goals. Using an infrastructure as code tool like Puppet, you might automate the deployment of applications across end devices or keep servers up-to-date with security patches. You could create and enforce rules around configuration settings and dependencies to ensure that devices are in line with company policy.
With a range of infrastructure as code tools, each with their own specialty and capabilities, it's important to consider what your organization needs. How often are you rolling out applications or updates? How many servers do you have, and how many end users are you reaching?
Infrastructure as code (IaC) and infrastructure as a service (IaaS) are two different things. The main difference is that IaC turns infrastructure configurations into lines of code so they can be managed automatically. IaaS offers on-demand virtual computing resources via the internet (like servers, networking, and storage).
You can think of IaC as the set of instructions for provisioning and configuring IT resources and services – just turned into code, so you can automate, repeat, and manage them easily. Examples of IaC include Puppet, Terraform, and Chef.
See how Puppet IaC stacks up: Puppet vs. Terraform and Puppet vs. Chef >>
On the other hand, IaaS doesn’t define any system-level configurations. It just gives you resources and services you need to run your application code, with all the necessary configurations built in. Examples of IaaS include Amazon AWS, Microsoft Azure, and Google Cloud Platform.
Learn how automation simplifies multi-cloud deployment across IaaS providers >>
Previous methods of IT management won't work if you're trying to address modern scale and agility requirements. Graphical tools often have a low learning curve, but they fall apart when trying to account for differences between platforms or porting configurations as code progresses from one environment to another. Graphical tools also make it difficult — or impossible — to share pieces of configuration with other teams, do peer review on proposed changes, view historical changes, and roll back to a previous set of configurations. And scripts are equally unsuitable for modern scale and agility. They're brittle, unmaintainable, are sprawled throughout teams and individuals, and are rarely portable between environments.
Defining your infrastructure as code solves these problems because code is portable, reusable, shareable, testable, and introspectable. And in case we haven't said it clearly enough, manual changes are just terrible — period.
Code is portable, reusable, and can be managed with version control. By using infrastructure as code, as changes are made to the code, these changes are committed to version control, where they can be peer-reviewed, tested, collaborated on, and approved (merged) by peers.
Once the change has been accepted, it can be automatically deployed to thousands of systems just as easily as to a single system. The version control system also provides an audit history. Using a continuous integration/continuous delivery system, these steps can be codified into a continuous delivery pipeline. The result of using infrastructure as code with version control is a workflow that promotes collaboration, dramatically shortens feedback loops, reduces deployment risk, and keeps a continuous history of who did what.
It's like IaC for compliance. Learn more with our free eBook.
DISCOVER POLICY AS CODE
Gene Kim’s Three Ways is a path towards continuously improving IT’s ability to serve the business through rapid learning, experimentation, and continuous feedback loops. With the Three Ways, IT builds and reinforces a culture of fast feedback, collaboration, iteration, and visibility — all of which support the rapid learning, experimentation and continuous feedback that help the business become more competitive.
The cultural characteristics of the Three Ways are enforced through the technical practices of infrastructure automation, peer review, continuous delivery, automated testing, and deployment automation. All of these technical practices, by the way, are DevOps practices, and all are enabled by managing infrastructure as code.
Beyond just scalability, there are reasons that DevOps would see the benefit of infrastructure as code in the long run — auditability is a powerful reason. A clear record of infrastructure changes means that time is saved when troubleshooting is required, which is extremely helpful for compliance and auditing purposes.
When code can be reproduced, testing, debugging, and disaster recovery are also part of the benefits of infrastructure as code. For any organization, no matter how complex, there are going to be risks associated with managing infrastrucure across different users, devices, and for different needs. You might not be able to foresee these issues, but you can implement a repeatable way to handle issues that appear. IaC acts as both the fire alarm and a fire extinguisher for situations like these.
If you're not currently using infrastructure as code, you'll want to ask yourself:
In order to align everyone in IT, it’s important to establish a common language for everyone to use when contributing to and managing infrastructure. With a common language, everyone can propose infrastructure improvements, collaborate on infrastructure implementations, and read the code itself to understand how any part of the infrastructure is being managed. (You may have seen the term "executable documentation" for infrastructure code. That's because the code itself enforces the documented infrastructure policies.)
When choosing your infrastructure code language, there are important factors you should consider. Since you want everyone aligning with a common language, the language needs to have a low learning curve, be declarative, be idempotent, and holistically manage the infrastructure as a single source of truth. Let’s break that down.
It’s important to consider the strengths and skill level of everyone who contributes to the infrastructure. Are they all software developers with degrees in computer science? Probably not. At the same time, do not underestimate their capabilities, nor their experience in writing some form of code. Ask your DBA to show you their PL/SQL queries — that should convince you your DBA really does know how to write code. Or ask to see your Windows administrator’s batch files or login scripts. Almost anyone in IT can pick up an infrastructure language, provided it is well-designed, purpose-built, and imposes a strong opinion on how it should be used.
Idempotence is defined as the property of an action always having the same result. A example in mathematics is taking the absolute value of a number and continuing to apply the absolute value to the result. No matter how many times you perform that operation, the result is always the same. An example operation from Unix is the rm -f command. No matter the beginning state, the result is always that the file does not exist.
The more your code is idempotent, the more it can handle any condition, and always do the correct thing. Idempotency is a critical component to successfully using infrastructure as code.
As more and more of your IT team contributes to the infrastructure code, you need to know the solution you’ve chosen can scale to potentially hundreds of contributors across a plethora of teams. Where are all the different places the infrastructure code can live? How many different pieces of code manage the same system? What happens when two contributors write code that manages the same configuration differently?
With holistic modeling, all the infrastructure code is combined to a single central source of truth that identifies how each piece of infrastructure code relates to every other piece. Because the relationships between all the pieces of code is understood, common mistakes such as two contributors trying to manage the same configuration differently are caught, and problems averted.
Puppet was born from the combination of software development and operations and grew as the concept of DevOps gained traction, and infrastructure as code is at the center of it all. With infrastructure as code, Puppet allows you to scale your infrastructure automation with your organization's IT needs, meaning you can do more provisioning, deliver apps faster, stay in compliance, and build more resilient infrastructure with code – and get the same result every time.
Infrastructure as code is an important practice to adopt if you want to implement DevOps in your organization — ultimately making your IT organization more responsive, collaborative, faster, and more innovative.
Puppet can help you reach your DevOps goals using infrastructure as code for your specific organizational needs. Even better, you can see how Puppet works within your infrastructure with a free trial:
START MY PUPPET TRIAL
This blog was originally published on February 9, 2017, and has since been updated for accuracy and relevance.
Product Manager, Puppet by Perforce