Infrastructure as Code (IaC) is a philosophy and a set of practices for deploying and managing networks in the cloud age. IaC is designed to maximize the benefits of cloud computing and leverage the capabilities of automated configuration and deployment tools, such as Puppet, Chef, Salt, Ansible, and Terraform. The fully automated installation and configuration provided by these tools allows the admin to define complete systems with configuration files.
Configuration files are sets of instructions with specifications on how to assemble and configure the system. This instruction set can take many different forms and go by other names depending on the tool (e.g., a cookbook in Chef and a playbook in Ansible). Regardless of the differences between platforms, this ability to define a complete configuration in advance leads to a new vision of infrastructure, in which knowledge of the systems resides in code form, and get rapidly deployed in the cloud without the need for conventional installation or reconfiguration with console commands.
The steps for deploying your own solution will vary depending on your automation platform and the details of your network, but keep these principles in mind as you start to explore the possibilities of IaC.
- Simple and Modular Systems
In the hardware era, an office might employ a single server system for email, file storage, and several other tasks, but the first lesson of IaC is to break away from the all-in-one mentality. Large, multipurpose systems add complexity, and complexity can lead to errors and security problems. Design your IaC infrastructure to be simple, streamlined, and modular and then deploy them like building blocks to address the needs of your environment.
- Single Source of Truth
Multiple versions of the same configuration file can cause confusion and lead to mistakes. Each configuration should have a single source. This means implementing clear and effective versioning using a version control system such as Git. However, the single source of truth philosophy means more than just version control. The focus should be on a central constellation of standard templates, with customizations occurring through a clear and predictable process rather than on the fly.
- No External Documentation
The configuration file itself should hold all the information necessary for understanding the contents. Placing instructions and commentary about the configuration in separate documents requires the team to track and maintain separate files in parallel. The age-old habit of changing the configuration first and updating the documents later makes extra work, leads to mistakes, and invites the possibility of the configuration and the documentation falling out of sync.
Most IaC platforms provide a means for adding comments to the code, but it is also important for team members to become familiar with the interface tools and declarative language used with the IaC platform to read and understand the details of the configuration.
- Assurance Through Automated Testing
Automated testing is a central tenet of DevOps and the IaC philosophy. The modularity and reproducibility built into the IaC environment makes it easy to model the production setting in a testing environment. Testing should begin after you make a change to the configuration and should proceed systematically with unit testing, function testing, integration testing, and regression testing before the new version of the system gets deployed.
- Lean In for Immutable
In IaC, the configuration lives in the code. The goal is to express the details of the configuration through the configuration file. Once the system spins into life, you could get tempted to manage and reconfigure it as you would any other computer system, but the uniformity principle is best served by leaving it alone. Local snowflake reconfiguration can lead to errors and make the system difficult for others to secure and maintain. Ideally, you should make all changes through the configuration file and then redeploy when there is a need for an update, rather than tweaking a running system.
- Design Your Processes for Collaboration
Knowledge of the overall configuration and goals should be shared across the team, rather than bottlenecked with a single user. Version control is a key component of the collaborative environment, but it is only the beginning. You should deploy interactive processes and collaboration tools in a way that maximizes information and shared responsibility while still maintaining sensible security and auditing policies. A human with unshared or non-transferable information is a threat to the continuity of operations.
Keep these principles in mind as you explore the possibilities of IaC and envision a deployment process for your own IaC infrastructure.
Comments