book

Infrastructure as Code

Name: Infrastructure as Code
Author: Kief Morris
ISBN: 9781491924358

by Kief Morris

June 2016

Intermediate to advanced

360 pages

10h 9m

English

O'Reilly Media, Inc.

Read now

Unlock full access

Preface
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
I. Foundations
1. Challenges and Principles
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?
2. Dynamic Infrastructure Platforms
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
3. Infrastructure Definition Tools
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
4. Server Configuration Tools
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
5. General Infrastructure Services
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
II. Patterns
6. Patterns for Provisioning Servers
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
7. Patterns for Managing Server Templates
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

8. Patterns for Updating and Changing Servers
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
9. Patterns for Defining Infrastructure
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
III. Practices
10. Software Engineering Practices for Infrastructure
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
11. Testing Infrastructure Changes
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
12. Change Management Pipelines for Infrastructure
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
13. Workflow for the Infrastructure Team
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
14. Continuity with Dynamic Infrastructure
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
15. Organizing for Infrastructure as Code
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
Index

Content preview from Infrastructure as Code

Part III. Practices

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9781491924334Errata Page

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Infrastructure as Code

by Kief Morris

Part III. Practices

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.