book

Infrastructure as Code

by Kief Morris

June 2016

Intermediate to advanced

360 pages

10h 9m

English

O'Reilly Media, Inc.

Read now

Unlock full access

How I Learned to Stop Worrying and to Love the CloudMy First Virtual Server FarmThe Sorcerer’s ApprenticeCloud from ScratchWhy I’m Writing This BookWho This Book Is ForWhat Tools Are CoveredHow to Read This BookConventions Used in This BookSafari® Books OnlineHow to Contact UsAcknowledgments
Why Infrastructure as Code?What Is Infrastructure as Code?Goals of Infrastructure as CodeChallenges with Dynamic InfrastructureServer SprawlConfiguration DriftSnowflake ServersFragile InfrastructureAutomation FearErosionPrinciples of Infrastructure as CodeSystems Can Be Easily ReproducedSystems Are DisposableSystems Are ConsistentProcesses Are RepeatableDesign Is Always ChangingPracticesUse Definition FilesSelf-Documented Systems and ProcessesVersion All the ThingsContinuously Test Systems and ProcessesSmall Changes Rather Than BatchesKeep Services Available ContinuouslyAntifragility: Beyond “Robust”The Secret Ingredient of Antifragile IT SystemsConclusionWhat’s Next?
What Is a Dynamic Infrastructure Platform?Requirements for a Dynamic Infrastructure PlatformProgrammableOn-DemandSelf-ServiceInfrastructure Resources Provided by the PlatformCompute ResourcesStorage ResourcesNetwork ResourcesTypes of Dynamic Infrastructure PlatformsPublic IaaS CloudCommunity IaaS CloudPrivate IaaS CloudAntipattern: Hand-Cranked CloudHybrid and Mixed Cloud OptionsBare-Metal CloudsDeciding on a Dynamic Infrastructure PlatformPublic or Private?Cloud PortabilityMechanical Sympathy with the Cloud and VirtualizationConclusion
Choosing Tools for Infrastructure as CodeRequirement: Scriptable InterfaceRequirement: Unattended Mode for Command-Line ToolsRequirement: Support for Unattended ExecutionRequirement: Externalized ConfigurationConfiguration Definition FilesReusability with Configuration DefinitionsWorking with Infrastructure Definition ToolsProvisioning Infrastructure with Procedural ScriptsDefining Infrastructure DeclarativelyUsing Infrastructure Definition ToolsConfiguring ServersConfiguration RegistriesLightweight Configuration RegistriesIs a Configuration Registry a CMDB?The CMDB Audit and Fix AntipatternThe Infrastructure-as-Code Approach to CMDBConclusion
Goals for Automated Server ManagementTools for Different Server Management FunctionsTools for Creating ServersTools for Configuring ServersTools for Packaging Server TemplatesTools for Running Commands on ServersUsing Configuration from a Central RegistryServer Change Management ModelsAd Hoc Change ManagementConfiguration SynchronizationImmutable InfrastructureContainerized ServicesContainersManaging Ruby Applications with and without ContainersAre Containers Virtual Machines?Using Containers Rather than Virtual MachinesRunning ContainersSecurity and ContainersConclusion
Considerations for Infrastructure Services and ToolsPrefer Tools with Externalized ConfigurationPrefer Tools That Assume Infrastructure Is DynamicPrefer Products with Cloud-Compatible LicensingPrefer Products That Support Loose CouplingSharing a Service Between TeamsService Instance TemplatesMonitoring: Alerting, Metrics, and LoggingAlerting: Tell Me When Something Is WrongMetrics: Collect and Analyze DataLog Aggregation and AnalysisService DiscoveryServer-Side Service Discovery PatternClient-Side Service Discovery PatternDistributed Process ManagementOrchestrating Processes with Server RolesOrchestrating Processes with ContainersScheduling Short JobsContainer Orchestration ToolsSoftware DeploymentDeployment Pipeline SoftwarePackaging SoftwareConclusion
Server ProvisioningA Server’s LifeWhat Goes onto a ServerTypes of Things on a ServerServer RolesPatterns for Creating ServersAntipattern: Handcrafted ServerPractice: Wrap Server Creation Options in a ScriptAntipattern: Hot Cloned ServerPattern: Server TemplateAntipattern: Snowflake FactoryPatterns for Bootstrapping New ServersPushing to BootstrapPulling to BootstrapPractice: Smoke Test Every New Server InstanceConclusion
Stock Templates: Can’t Someone Else Do It?Provisioning Servers Using TemplatesProvisioning at Creation TimeProvisioning in the TemplateBalancing Provisioning Across Template and CreationThe Process for Building a Server TemplateCreating Templates for Multiple PlatformsOrigin ImagesAntipattern: Hot Cloned Server TemplateBaking a Template from an OS Installation ImageBaking a Template from a Stock ImageBuilding a Template from a UnikernelCustomizing a Server Template without Booting ItUpdating Server TemplatesReheating a TemplateBaking a Fresh TemplateVersioning Server TemplatesBuilding Templates for RolesPattern: Layered TemplateSharing Base Scripts for TemplatesAutomating Server Template ManagementCustomizing Servers Before BakingPractice: Automatically Test Server TemplatesConclusion

Models for Server Change ManagementAd Hoc Change ManagementContinuous Configuration SynchronizationImmutable ServersContainerized ServersGeneral Patterns and PracticesPractice: Minimize Server TemplatesPractice: Replace Servers When the Server Template ChangesPattern: Phoenix ServersPatterns and Practices for Continuous DeploymentPattern: Masterless Configuration ManagementPractice: Apply CronContinuous Synchronization FlowThe Unconfigured CountryPatterns and Practices for Immutable ServersServer Image as ArtifactSimplifying Confirmation Management Tooling with Immutable ServersImmutable Server FlowBootstrap Configuration with Immutable ServersTransactional Server UpdatesPractices for Managing Configuration DefinitionsPractice: Keep Configuration Definitions MinimalOrganizing DefinitionsPractice: Use Test-Driven Development (TDD) to Drive Good DesignConclusion
EnvironmentsAntipattern: Handcrafted InfrastructureDefining Infrastructure Stacks as CodeAntipattern: Per-Environment Definition FilesPattern: Reusable Definition FilesPractice: Test and Promote Stack DefinitionsSelf-Service EnvironmentsOrganizing InfrastructureAntipattern: Monolithic StackAvoid “Lift and Shift” When Migrating InfrastructureDividing an Application Environment into Multiple StacksManaging Configuration Parameters Between StacksSharing Infrastructure ElementsPractice: Manage Application Code and Infrastructure Code TogetherApproaches to Sharing DefinitionsPractice: Align Infrastructure Design with the Scope of ChangeExample: An Infrastructure Design for MicroservicesRunning Definition ToolsConclusion
System QualityPoor-Quality Systems Are Difficult to ChangeHigh-Quality Systems Are Easier and Safer to ChangeInfrastructure Quality Through CodeFast FeedbackVCS for Infrastructure ManagementWhat to Manage in a VCSContinuous Integration (CI)Continuously Testing Branches Is Not Continuous IntegrationWho Broke the Build?Ignoring Tests That FailCI for InfrastructureContinuous Delivery (CD)The Problem with the Integration PhaseDeployment Pipelines and Change PipelinesContinuous Delivery Is Not Continuous DeploymentCode QualityClean CodePractice: Manage Technical DebtManaging Major Infrastructure ChangesFeature TogglesConclusion
The Agile Approach to TestingAutomating Tests for Fast FeedbackOrganically Building a Test SuiteStructuring the Test Suite: The Test PyramidAvoiding an Unbalanced Test SuitePractice: Test at the Lowest Level PossiblePractice: Only Implement the Layers You NeedPractice: Prune the Test Suite OftenPractice: Continuously Review Testing EffectivenessImplementing a Balanced Test SuiteLow-Level TestingMid-Level TestingHigher-Level TestsTesting Operational QualityManaging Test CodePractice: Keep Test Code with the Code It TestsAnti-Pattern: Reflective TestsTechniques to Isolate Components for TestingRefactoring Components so They Can Be IsolatedManaging External DependenciesTest SetupRoles and Workflow for TestingPrinciple: People Should Write Tests for What They BuildThe Test-Writing HabitPrinciple: Everyone Should Have Access to the Testing ToolsThe Value of a Quality AnalystTest-Driven Development (TDD)Conclusion
Benefits of a Change Management PipelineGuidelines for Designing PipelinesEnsure Consistency Across StagesGet Immediate Feedback for Every ChangeRun Automated Stages Before Manual StagesGet Production-Like Sooner Rather Than LaterBasic Pipeline DesignsThe Local Development StageThe Build StagePublishing a Configuration ArtifactAutomated Testing StagesManual Validation StagesApply to LiveThe Rhythm of the PipelinePractices for Using a PipelinePractice: Prove Production Readiness for Every ChangePractice: Start Every Change from the Beginning of the PipelinePractice: Stop the Line on Any FailureScaling Pipelines to More Complex SystemsPattern: Fan-In PipelinesPractice: Keep Pipelines ShortPractice: Decouple PipelinesIntegration ModelsTechniques for Handling Dependencies Between ComponentsPattern: Library DependencyPattern: Self-Provisioned Service InstanceProviding Pre-Release Library BuildsProviding Test Instances of a Service to ConsumersUsing Test Instances of a Service as a ConsumerPractices for Managing Interfaces Between ComponentsPractice: Ensure Backward Compatibility of InterfacesPractice: Decouple Deploying from ReleasingPractice: Use Version TolerancePractice: Provide Test DoublesPractice: Test the Provider with Contract TestsPractice: Test with a Reference ConsumerPractice: Smoke Test the Provider InterfacePractice: Run Consumer-Driven Contract (CDC) TestsConclusion
Automate Anything That MovesMake the Change ManuallyAd Hoc AutomationAutonomic AutomationAutonomic Automation WorkflowUsing a Local SandboxUsing Local Virtualization for a SandboxExample Workflow with Local TestingUsing the Virtualization Platform for SandboxesCodebase Organization PatternsAntipattern: Branch-Based CodebasesPattern: One Trunk per ComponentPattern: Single TrunkWorkflow EffectivenessExpediting ChangesCode ReviewsFitting Governance into the WorkflowConclusion
Service ContinuityTrue AvailabilityUsing Dynamic Server Pools for RecoverySoftware Design for Dynamic InfrastructureCompartmentalizing for ContinuityZero-Downtime ChangesPattern: Blue-Green ReplacementPattern: Phoenix ReplacementPractice: Reduce the Scope of ReplacementPattern: Canary ReplacementRouting Traffic for Zero-Downtime ReplacementsZero-Downtime Changes with DataData ContinuityReplicating Data RedundantlyRegenerating DataDelegating Data PersistenceBacking Up to Persistent StorageDisaster RecoveryContinuous Disaster RecoveryThe DR Plan: Planning for DisasterPractice: Prefer Rebuilding Things over Cold StandbyContinuous Monitoring through the PipelineSecurityAutomatically Papering over CompromisesReliable Updates as a DefenseProvenance of PackagesAutomated HardeningAutomating Security Validation in the PipelineThe Change Pipeline as a VulnerabilityManaging Security Risks with Cloud AccountsConclusion
Evolutionary ArchitectureLearning under FireStart with a Trailblazer PipelineMeasuring EffectivenessAgree on Desired Outcomes FirstChoose Metrics that Help the TeamTrack and Improve Cycle TimeUse Kanban to Make Work VisibleRetrospectives and Post-MortemsOrganize to Empower UsersPitfalls of the Divided Function ModelAdopt a Self-Service ModelTake Full Responsibility: You Build It, You Run ItOrganizing into Cross-Functional TeamsGovernance through Continuous Change ManagementProvide Solid Building BlocksProve Operational Readiness in the PipelineSharing Ownership of Operational QualityReview and Audit Automated ProcessesOptimize for Time to Detect and Fix ProblemsConclusion: It’s Never Finished

Content preview from Infrastructure as Code

Chapter 12. Change Management Pipelines for Infrastructure

Previous chapters have discussed the use of continuous integration (CI) to automatically test changes to scripts, tools, and configuration definitions, as they are committed to source control. They have also mentioned continuous delivery (CD), which builds on this to provide assurance that all of the elements of a system work correctly after a change.

This chapter explains how to implement continuous delivery for infrastructure by building a change management pipeline.

A deployment pipeline¹ is used in CD to manage the deployment and testing of software to a series of validation stages whenever there is a change to the codebase. The validations ensure that the codebase is production ready and that it will deploy correctly and reliably. The same automated process is used to deploy and configure the software in each environment, including production, to prevent the classic “worked in test; failed in live” issues that arise from inconsistencies and manual processes.

The point of CD and the software deployment pipeline is to allow changes to be delivered in a continuous flow, rather than in large batches. Changes can be validated more thoroughly, not only because they are applied with an automated process, but also because changes are tested when they are small, and because they are tested immediately after being committed. The result, when done well, is that changes can be made more frequently, more rapidly, and more reliably. ...