book

Infrastructure as Code, 2nd Edition

by Kief Morris

December 2020

Intermediate to advanced

427 pages

11h 11m

English

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

Why I Wrote This BookWhat’s New and Different in This EditionWhat’s NextWhat This Book Is and Isn’tSome History of Infrastructure as CodeWho This Book Is ForPrinciples, Practices, and PatternsThe ShopSpinner ExamplesConventions Used in This BookO’Reilly Online LearningHow to Contact UsAcknowledgments
From the Iron Age to the Cloud AgeInfrastructure as CodeBenefits of Infrastructure as CodeUse Infrastructure as Code to Optimize for ChangeObjection: “We don’t make changes often enough to justify automating them”Objection: “We should build first and automate later”Objection: “We must choose between speed and quality”The Four Key MetricsThree Core Practices for Infrastructure as CodeCore Practice: Define Everything as CodeCore Practice: Continuously Test and Deliver All Work in ProgressCore Practice: Build Small, Simple Pieces That You Can Change IndependentlyConclusion
Principle: Assume Systems Are UnreliablePrinciple: Make Everything ReproduciblePitfall: Snowflake SystemsPrinciple: Create Disposable ThingsPrinciple: Minimize VariationConfiguration DriftPrinciple: Ensure That You Can Repeat Any ProcessConclusion
The Parts of an Infrastructure SystemInfrastructure PlatformsInfrastructure ResourcesCompute ResourcesStorage ResourcesNetwork ResourcesConclusion
Why You Should Define Your Infrastructure as CodeWhat You Can Define as CodeChoose Tools with Externalized ConfigurationManage Your Code in a Version Control SystemInfrastructure Coding LanguagesInfrastructure ScriptingDeclarative Infrastructure LanguagesProgrammable, Imperative Infrastructure LanguagesDeclarative Versus Imperative Languages for InfrastructureDomain-Specific Infrastructure LanguagesGeneral-Purpose Languages Versus DSLs for InfrastructureImplementation Principles for Defining Infrastructure as CodeSeparate Declarative and Imperative CodeTreat Infrastructure Code Like Real CodeConclusion
What Is an Infrastructure Stack?Stack CodeStack InstanceConfiguring Servers in a StackLow-Level Infrastructure LanguagesHigh-Level Infrastructure LanguagesPatterns and Antipatterns for Structuring StacksAntipattern: Monolithic StackPattern: Application Group StackPattern: Service StackPattern: Micro StackConclusion
What Environments Are All AboutDelivery EnvironmentsMultiple Production EnvironmentsEnvironments, Consistency, and ConfigurationPatterns for Building EnvironmentsAntipattern: Multiple-Environment StackAntipattern: Copy-Paste EnvironmentsPattern: Reusable StackBuilding Environments with Multiple StacksConclusion
Using Stack Parameters to Create Unique IdentifiersExample Stack ParametersPatterns for Configuring StacksAntipattern: Manual Stack ParametersPattern: Stack Environment VariablesPattern: Scripted ParametersPattern: Stack Configuration FilesPattern: Wrapper StackPattern: Pipeline Stack ParametersPattern: Stack Parameter RegistryConfiguration RegistryImplementing a Configuration RegistrySingle or Multiple Configuration RegistriesHandling Secrets as ParametersEncrypting SecretsSecretless AuthorizationInjecting Secrets at RuntimeDisposable SecretsConclusion

Why Continuously Test Infrastructure Code?What Continuous Testing MeansWhat Should We Test with Infrastructure?Challenges with Testing Infrastructure CodeChallenge: Tests for Declarative Code Often Have Low ValueChallenge: Testing Infrastructure Code Is SlowChallenge: Dependencies Complicate Testing InfrastructureProgressive TestingTest PyramidSwiss Cheese Testing ModelInfrastructure Delivery PipelinesPipeline StagesScope of Components Tested in a StageScope of Dependencies Used for a StagePlatform Elements Needed for a StageDelivery Pipeline Software and ServicesTesting in ProductionWhat You Can’t Replicate Outside ProductionManaging the Risks of Testing in ProductionConclusion
Example InfrastructureThe Example StackPipeline for the Example StackOffline Testing Stages for StacksSyntax CheckingOffline Static Code AnalysisStatic Code Analysis with APITesting with a Mock APIOnline Testing Stages for StacksPreview: Seeing What Changes Will Be MadeVerification: Making Assertions About Infrastructure ResourcesOutcomes: Proving Infrastructure Works CorrectlyUsing Test Fixtures to Handle DependenciesTest Doubles for Upstream DependenciesTest Fixtures for Downstream DependenciesRefactor Components So They Can Be IsolatedLife Cycle Patterns for Test Instances of StacksPattern: Persistent Test StackPattern: Ephemeral Test StackAntipattern: Dual Persistent and Ephemeral Stack StagesPattern: Periodic Stack RebuildPattern: Continuous Stack ResetTest OrchestrationSupport Local TestingAvoid Tight Coupling with Pipeline ToolsTest Orchestration ToolsConclusion
Cloud Native and Application-Driven InfrastructureApplication Runtime TargetsDeployable Parts of an ApplicationDeployment PackagesDeploying Applications to ServersPackaging Applications in ContainersDeploying Applications to Server ClustersDeploying Applications to Application ClustersPackages for Deploying Applications to ClustersDeploying FaaS Serverless ApplicationsApplication DataData Schemas and StructuresCloud Native Application Storage InfrastructureApplication ConnectivityService DiscoveryConclusion
What’s on a ServerWhere Things Come FromServer Configuration CodeServer Configuration Code ModulesDesigning Server Configuration Code ModulesVersioning and Promoting Server CodeServer RolesTesting Server CodeProgressively Testing Server CodeWhat to Test with Server CodeHow to Test Server CodeCreating a New Server InstanceHand-Building a New Server InstanceUsing a Script to Create a ServerUsing a Stack Management Tool to Create a ServerConfiguring the Platform to Automatically Create ServersUsing a Networked Provisioning Tool to Build a ServerPrebuilding ServersHot-Cloning a ServerUsing a Server SnapshotCreating a Clean Server ImageConfiguring a New Server InstanceFrying a Server InstanceBaking Server ImagesCombining Baking and FryingApplying Server Configuration When Creating a ServerConclusion
Change Management Patterns: When to Apply ChangesAntipattern: Apply On ChangePattern: Continuous Configuration SynchronizationPattern: Immutable ServerHow to Apply Server Configuration CodePattern: Push Server ConfigurationPattern: Pull Server ConfigurationOther Server Life Cycle EventsStopping and Restarting a Server InstanceReplacing a Server InstanceRecovering a Failed ServerConclusion
Building a Server ImageWhy Build a Server Image?How to Build a Server ImageTools for Building Server ImagesOnline Image Building ProcessOffline Image Building ProcessOrigin Content for a Server ImageBuilding from a Stock Server ImageBuilding a Server Image from ScratchProvenance of a Server Image and its ContentChanging a Server ImageReheating or Baking a Fresh ImageVersioning a Server ImageUpdating Server Instances When an Image ChangesProviding and Using a Server Image Across TeamsHandling Major Changes to an ImageUsing a Pipeline to Test and Deliver a Server ImageBuild Stage for a Server ImageTest Stage for a Server ImageDelivery Stages for a Server ImageUsing Multiple Server ImagesServer Images for Different Infrastructure PlatformsServer Images for Different Operating SystemsServer Images for Different Hardware ArchitecturesServer Images for Different RolesLayering Server ImagesSharing Code Across Server ImagesConclusion
Application Cluster SolutionsCluster as a ServicePackaged Cluster DistributionStack Topologies for Application ClustersMonolithic Stack Using Cluster as a ServiceMonolithic Stack for a Packaged Cluster SolutionPipeline for a Monolithic Application Cluster StackExample of Multiple Stacks for a ClusterSharing Strategies for Application ClustersOne Big Cluster for EverythingSeparate Clusters for Delivery StagesClusters for GovernanceClusters for TeamsService MeshInfrastructure for FaaS ServerlessConclusion
Designing for ModularityCharacteristics of Well-Designed ComponentsRules for Designing ComponentsUse Testing to Drive Design DecisionsModularizing InfrastructureStack Components Versus Stacks as ComponentsUsing a Server in a StackDrawing Boundaries Between ComponentsAlign Boundaries with Natural Change PatternsAlign Boundaries with Component Life CyclesAlign Boundaries with Organizational StructuresCreate Boundaries That Support ResilienceCreate Boundaries That Support ScalingAlign Boundaries to Security and Governance ConcernsConclusion
Infrastructure Languages for Stack ComponentsReuse Declarative Code with ModulesDynamically Create Stack Elements with LibrariesPatterns for Stack ComponentsPattern: Facade ModuleAntipattern: Obfuscation ModuleAntipattern: Unshared ModulePattern: Bundle ModuleAntipattern: Spaghetti ModulePattern: Infrastructure Domain EntityBuilding an Abstraction LayerConclusion
Discovering Dependencies Across StacksPattern: Resource MatchingPattern: Stack Data LookupPattern: Integration Registry LookupDependency InjectionConclusion
Organizing Projects and RepositoriesOne Repository, or Many?One Repository for EverythingA Separate Repository for Each Project (Microrepo)Multiple Repositories with Multiple ProjectsOrganizing Different Types of CodeProject Support FilesCross-Project TestsDedicated Integration Test ProjectsOrganize Code by Domain ConceptOrganizing Configuration Value FilesManaging Infrastructure and Application CodeDelivering Infrastructure and ApplicationsTesting Applications with InfrastructureTesting Infrastructure Before IntegratingUsing Infrastructure Code to Deploy ApplicationsConclusion
Delivering Infrastructure CodeBuilding an Infrastructure ProjectPackaging Infrastructure Code as an ArtifactUsing a Repository to Deliver Infrastructure CodeIntegrating ProjectsPattern: Build-Time Project IntegrationPattern: Delivery-Time Project IntegrationPattern: Apply-Time Project IntegrationUsing Scripts to Wrap Infrastructure ToolsAssembling Configuration ValuesSimplifying Wrapper ScriptsConclusion
The PeopleWho Writes Infrastructure Code?Applying Code to InfrastructureApplying Code from Your Local WorkstationApplying Code from a Centralized ServicePersonal Infrastructure InstancesSource Code Branches in WorkflowsPreventing Configuration DriftMinimize Automation LagAvoid Ad Hoc ApplyApply Code ContinuouslyImmutable InfrastructureGovernance in a Pipeline-based WorkflowReshuffling ResponsibilitiesShift LeftAn Example Process for Infrastructure as Code with GovernanceConclusion
Reduce the Scope of ChangeSmall ChangesExample of RefactoringPushing Incomplete Changes to ProductionParallel InstancesBackward Compatible TransformationsFeature TogglesChanging Live InfrastructureInfrastructure SurgeryExpand and ContractZero Downtime ChangesContinuityContinuity by Preventing ErrorsContinuity by Fast RecoveryContinuous Disaster RecoveryChaos EngineeringPlanning for FailureData Continuity in a Changing SystemLockSegregateReplicateReloadMixing Data Continuity ApproachesConclusion