Infrastructure as Code (for Epub True) (Kief Morris) (z-library.sk, 1lib.sk, z-lib.sk)
Code
With this book, Kief Morris describes patterns and practices for building and evolving infrastructure as code. The third edition provides a broader context for infrastructure, explaining how to design and implement infrastructure to better support the strategic goals and challenges of an organization, such as supporting growth while better managing costs.
3
Views
Registered users can read the full content for free
Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.
Page
1
(This page has no text content)
Page
2
Praise for Infrastructure as Code, Third Edition Infrastructure as Code is one of those fundamental approaches that everyone talks about as a high level idea, usually pointing at their favorite tool as the way to deliver it; but if you want to make it work, you need to understand the techniques involved, not just the tools. Infrastructure as Code, the book, delivers that understanding so you can work with your choice of tools and platforms as they evolve and this new edition brings one of the definitive books on the topic up to date with newer technologies like containers and serverless, and more recent tools. —Mary Branscombe, freelance technology journalist and author An essential guide to using code to manage infrastructure wherever it may be, on premises or in the cloud. —Simon Bisson, freelance technology writer
Page
3
Essential reading for anyone getting into the Infrastructure as Code space. This book manages to cover a lot of ground, while delivering deep insights at each step of the way, including exploring the core principles and practices of cloud infrastructure, the tools available today, and the techniques for managing servers, environments, applications, workflows, automated tests, governance, and more. —Yevgeniy Brikman, Cofounder of Gruntwork and author of Terraform: Up and Running Fair warning: this book will transform the way you approach Infrastructure as Code. It challenges you to think beyond today’s solutions and push the boundaries of infrastructure management. Its insights, attention to real- life scenarios, and understanding of the developer perspective are timeless, and will remain relevant in the ever-evolving technology landscape. —Lipi Deepaakshi Patnaik, Senior Software Developer, Zeta Suite
Page
4
This 3rd edition is a natural evolution of the 1st and 2nd editions. Where the 1st edition is primarily focused on managing virtual machines, and the 2nd is on the divide between VMs and cloud, this 3rd edition is full on managing cloud infrastructure. But…staying equal to itself, it is a principles, practices, and patterns book. That is what I especially like about the Infrastructure as Code book. Although the book gives some tooling references, which can be helpful, it is not a book on how I can do something with my favorite tool. It is especially focused on understanding the baseline, i.e., mastering the principles. Once we recognize this, we can design and implement infrastructure code and resources most effectively. —Thierry de Pauw, ThinkingLabs
Page
5
Infrastructure as Code THIRD EDITION Designing and Delivering Dynamic Systems for the Cloud Age Kief Morris
Page
6
Infrastructure as Code by Kief Morris Copyright © 2025 Kief Morris. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com. Acquisitions Editor: John Devins Development Editor: Jill Leonard Production Editor: Beth Kelly Copyeditor: Sharon Wilkey Proofreader: Kim Cofer Indexer: Potomac Indexing, LLC
Page
7
Interior Designer: David Futato Cover Designer: Karen Montgomery Illustrator: Kate Dullea June 2016: First Edition December 2020: Second Edition March 2025: Third Edition Revision History for the Third Edition 2025-03-13: First Release See http://oreilly.com/catalog/errata.csp?isbn=9781098150358 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Infrastructure as Code, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of
Page
8
or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights. 978-1-098-15035-8 [LSI]
Page
9
Preface I began working as a systems administrator in a team that managed Unix servers and workstations at the Computer Science department of the University of Tennessee. From then, into the dot-com days and after, I’ve been drawn to applying what I learned about software development to automate managing servers and other infrastructure. I discovered the Infrastructures.org website in 2001, which was an eye-opener. The authors introduced me to Mark Burgess' pioneering infrastructure tool CFEngine and the value of automatically provisioning servers in a consistent, repeatable way, something I used to build physical servers in data centers for a series of startup and scale-up companies in the 2000s. Infrastructure as Code, as a term, appeared around the same time that Andrew Clay Shafer and Patrick Debois kicked off the DevOps movement with a talk at the Agile 2008 conference. The first uses I’ve found for the term “Infrastructure as Code” are from a talk called “Agile Infrastructure” that Shafer gave at the Velocity conference in 2009 and an article John Willis wrote summarizing the talk. Adam Jacob, who cofounded Chef, and 1
Page
10
Luke Kanies, founder of Puppet, also used the term around this time. Infrastructure as Code tools create the opportunity to work in ways that help you to deliver changes more frequently, quickly, and reliably, improving the overall quality of your systems. But the benefits don’t come from the tools themselves. They come from the way you use them. Innovators are creating new tools and techniques for building and managing infrastructure using code, as well as potential new generations of tools that move beyond the “as code” paradigm. Whatever tools we use, the trick is to leverage the technology to embed quality, reliability, and compliance into the process of making changes. Why I Wrote This Book As cloud computing and Infrastructure as Code grew from a niche into the mainstream in the 2010s, I learned how to put Infrastructure as Code into practice by reading blog posts, attending talks, and working with various tools with consulting clients. I waited for one of the DevOps luminaries I admired to write a book I could share as a comprehensive collection of guidance for this practice. By the middle of the decade, they had yet to write it, so I outlined my ideas for what they should write,
Page
11
carried on fleshing it out, and ended up with the first edition of this book in 2016. The first edition focused on server configuration using tools like Chef and Puppet. The second edition in 2020 shifted to infrastructure “stacks” using tools like Amazon Web Services (AWS) Cloud Development Kit (CDK) and Terraform, with more interest in cloud native application runtimes like container clusters and serverless. With this third edition, the shift to using infrastructure code to provide application runtimes based on containers and serverless over configuring server images is much further along. More people are interested in coding infrastructure using general-purpose languages, as enabled by CDK and Pulumi, and are curious about shifting to integrating application and infrastructure code. As infrastructure engineers and architects, we need to know how infrastructure enables value for the organization. We must move beyond infrastructure spaghetti code that creates a sprawl of unmanageable environments. This edition shares emerging patterns and practices for a more componentized, composable approach to Infrastructure as Code.
Page
12
In this book I share approaches that are widely used today, but I don’t believe we’re anywhere near the end of the journey of finding better ways to manage digital infrastructure. I hope this edition will help you manage your infrastructure more effectively. And I also hope it will inspire you to push beyond current practices. We may eventually move beyond using code to define infrastructure. But whatever specific tools we use, I believe that thoughtful use of effective software design principles and techniques can help us do better, and I hope this new edition will help.
Page
13
What This Book Is and Isn’t This book’s thesis is that practices, patterns, and techniques can be applied across infrastructure platforms using various infrastructure tools. It focuses less on specific tools and more on how to use them. Although I discuss available tools, you won’t find details of how to work with any particular one. You will find patterns, practices, and techniques that should be relevant to whatever tools and platforms you use. You won’t find many code examples for real-world tools or clouds. Tools change too quickly in this field to keep code examples accurate. The advice in this book should age more slowly and be applicable across tools. Instead, I write pseudocode examples for fictional tools to illustrate concepts. Too many topics fall under the label “infrastructure” for this book to cover. So I’ve kept the scope focused on using code to manage infrastructure as a service (IaaS) cloud infrastructure, leaving subjects like engineering platforms, developer portals, site reliability engineering (SRE), observability, container orchestration, and AI for other books and resources.
Page
14
Who This Book Is For This book is for people involved in providing and using infrastructure to deliver and run software. You may have a background in systems and infrastructure or software development and delivery. Your role may be engineering, testing, architecture, or management. I assume you have some exposure to cloud infrastructure and infrastructure automation tools. Readers new to Infrastructure as Code should find this book a good introduction to the topic. However, you will get the most out of it if you know how infrastructure cloud platforms work, and the basics of at least one infrastructure coding tool. I suggest complementing this book with learning resources for the specific cloud platforms and Infrastructure as Code tools you use. Those with more experience working with these tools should find a mixture of familiar and new concepts and approaches. The content should create a common language and articulate challenges and solutions in ways that experienced practitioners and teams find helpful.
Page
15
Principles, Practices, and Patterns I use the terms principles, practices, and patterns (and antipatterns) to describe essential concepts. Here are the ways I use each of these terms: Principle A principle is a rule that helps you choose between potential solutions. Practice A practice is a way of implementing something. A given practice is not always the only way to do something and may not be the best way to do it for a particular situation. You should use principles to guide you in choosing the most appropriate practice for a given situation. Pattern A pattern is a potential solution to a problem. It is similar to a practice in that different patterns may be more effective in different contexts. Each pattern is described in a format that should help you evaluate its relevance for your problem.
Page
16
Antipattern An antipattern is a potential solution that you should avoid in most situations. It usually seems like a good idea or is something that you fall into doing without realizing it. WHY I DON’T USE THE TERM “BEST PRACTICE” Folks in our industry love to talk about “best practices.” However, this term often leads people to think there is only one solution to a problem, no matter the context. I prefer to describe practices and patterns and note when they are helpful along with their limitations. I describe some of these as more effective or appropriate while staying open to alternatives, and I explain why some practices are less effective. The FoodSpin Examples I use a fictional company called FoodSpin to illustrate concepts throughout this book. FoodSpin is a digital service that allows restaurants to provide searchable menus for customers to order and pay for their meals. “Introduction to FoodSpin and Its Strategy” gives a high-level view of the company’s strategy. I use FoodSpin’s team workloads and infrastructure estate to illustrate design patterns and implementation techniques.
Page
17
Many of my code examples use fictitious IaaS platforms, infrastructure tools, and pseudocode whose syntax may vary from example to example, depending on my point. I intend to illustrate concepts that apply across technology stacks. For More See the book’s companion website and subscribe to the newsletter. Conventions Used in This Book The following typographical conventions are used in this book: Italic Indicates new terms, URLs, email addresses, filenames, and file extensions. Constant width Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.
Page
18
Constant width bold Shows commands or other text that should be typed literally by the user. Constant width italic Shows text that should be replaced with user-supplied values or by values determined by context. TIP This element signifies a tip or suggestion. NOTE This element signifies a general note. WARNING This element indicates a warning or caution.
Page
19
O’Reilly Online Learning NOTE For more than 40 years, O’Reilly Media has provided technology and business training, knowledge, and insight to help companies succeed. Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, visit http://oreilly.com. How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472
Page
20
800-889-8969 (in the United States or Canada) 707-827-7019 (international or local) 707-829-0104 (fax) support@oreilly.com https://oreilly.com/about/contact.html We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at https://oreil.ly/infrastructure-as-code-3e. For news and information about our books and courses, visit https://oreilly.com. Find us on LinkedIn: https://linkedin.com/company/oreilly-media. Watch us on YouTube: https://youtube.com/oreillymedia. Acknowledgments I assumed that updating from the second edition of this book to the third would be much easier than it was, or at least less work than writing the first two editions. On the contrary, it was a huge effort. Fortunately, as with the earlier editions, I’ve had a wealth of support from many people.
The above is a preview of the first 20 pages. Register to read the complete e-book.
AI Reading Assistant
Whole-book reading guide from stratified index samples; jump to passages in the text
AI guide
【One-Line Pitch】
A pattern-driven guide to designing, delivering, and evolving cloud infrastructure as code, written for engineers and architects who want to move beyond tool tutorials toward durable design judgment. Read it if you own infrastructure that must change frequently without breaking.
【Book Arc】
- **Opening (~0%–10%)**: Frames the core argument — infrastructure as code is a Cloud Age approach to automating infrastructure that embraces continual change, not a way to freeze it. Introduces the FoodSpin running example, the antipattern vocabulary, and why the author avoids "best practice" language.
- **Early (~10%–35%)**: Builds the conceptual toolkit: what counts as infrastructure code versus configuration, how IaaS platforms, platform services, and SaaS APIs fit together, and how stacks are built, modeled, and deployed. Covers configuration parameters, secrets handling, and the first design patterns for sizing and structuring stacks.
- **Middle (~35%–55%)**: Moves into design patterns and antipatterns in depth — stack modules, facade and obfuscation modules, reusable stacks, vertical versus shared designs, and how to organize environments and resource groups. Server lifecycle patterns appear here: pull versus push configuration, role inheritance, and replacing servers rather than mutating them.
- **Late (~55%–85%)**: Applies the patterns to delivery and operations: pipelines, testing, governance, and the organizational forces (team ownership, coupling, coordination cost) that shape infrastructure design. The excerpts are thinner here, so treat this stage as directionally mapped rather than fully detailed.
- **Ending (~85%–100%)**: Closes on evolving infrastructure over time and the strategic context — supporting growth while managing cost — plus emerging directions such as infrastructure from code and post-code automation. The excerpts do not cover the closing chapters in detail.
【Key Takeaways】
- **Change is the goal, not the risk** (Opening): The book reframes frequent, reliable change as the source of resilient systems, citing Accelerate research, and treats heavyweight change control as the Iron Age antipattern.
- **Antipatterns beat "best practices"** (Opening): Morris deliberately avoids one-size-fits-all prescriptions, describing patterns with their trade-offs and limitations so you can judge fit for your context.
- **DevOps is people and culture first** (Opening): Tooling alone — a Jenkins install or a separate "DevOps team" — can add barriers rather than remove them; IaC is valuable only insofar as it bridges collaboration gaps.
- **Code versus configuration is a real distinction** (Early): Code defines aspects consistent across deployed instances; configuration specifies what differs per instance. Mixing them into stack code couples code to environments and raises the cost of creating new ones.
- **Stack sizing is a design decision** (Early/Middle): Full System Stacks, Micro Stacks, and vertical workload-aligned designs trade cohesion against coupling and coordination overhead; shared runtimes create deployment dependencies that block independent upgrades.
- **Modules are not free abstractions** (Middle): Facade Modules that don't simplify, Obfuscation Modules, and Unshared Modules are named antipatterns; wrapping low-level resources rarely solves the real problem for non-infrastructure users.
- **Replace servers, don't nurse them** (Middle): Continuous synchronization leaves gaps, and servers built at different times drift; replacement from a baked image is the more reliable path, with pull configuration preferred over push.
- **Secrets should be generated, not handled** (Early): Deployment-generated and runtime-generated secrets keep credentials out of human hands and out of pipeline logs, reducing exposure and misuse.
【Reading Tips】
- Read the opening chapters closely for the vocabulary — code versus configuration, stack versus stack instance, pattern versus antipattern — because the rest of the book assumes it.
- Treat the pattern chapters as a reference catalog: skim the pattern names and motivations first, then deep-read only the patterns that match your current stack-sizing or module problems.
- Pay attention to the FoodSpin examples; they recur and make abstract trade-offs concrete.
- When a pattern is presented, ask what forces it resolves and where it breaks — the book's value is in the reasoning, not the recipe.
- If you are new to IaC, read the early chapters before touching tool-specific material; the excerpts suggest tooling is secondary to design.
【Coverage Limits】
This guide is based on stratified excerpts covering roughly the first half of the book in detail, with only directional coverage of later delivery, governance, and evolution chapters. Specific chapter titles, figures, and closing material are not fully represented.
Passage locations
Excerpt 1
e approach to automating cloud infrastructure in a way that embraces continual change to achieve high reliability and quality. DEVOPS AND INFRASTRUCTURE AS C...
View in text
Excerpt 2
Infrastructure as Code model, at least as practiced today. Many experiments and innovations are aimed at moving beyond the current code-oriented model. The b...
View in text
Excerpt 3
reused across the instances couples the code tightly to the environments it’s used in. A configuration change requires changing stack code, which needs more...
View in text
Excerpt 4
t includes software and configuration common to all servers. This role might have networking hardening, administrative user accounts, and agents for monitori...
View in text
Recommended for You
{{#thumbnailUrl}}
{{/thumbnailUrl}}
{{^thumbnailUrl}}
{{/thumbnailUrl}}
Loading recommended books...
Failed to load, please try again later
Tip the Site
Scan the WeChat Pay or Alipay code to tip. No login required.
WeChat Pay
Alipay