Infrastructure as Code

Infrastructure as Code, 2nd Edition by Kief Morris, ISBN: 9781098114671

登録は簡単!. 無料です
または 登録 あなたのEメールアドレスで登録
Infrastructure as Code により Mind Map: Infrastructure as Code

1. I. Foundations

1.1. 1. What Is Infrastructure as Code?

1.1.1. Objections

1.1.1.1. We don’t make changes often enough to justify automating them

1.1.1.2. We should build first and automate later

1.1.1.3. We must choose between speed and quality

1.1.2. The Four Key Metrics

1.1.2.1. Delivery lead time

1.1.2.2. Deployment frequency

1.1.2.3. Change fail percentage

1.1.2.4. Mean Time to Restore (MTTR)

1.1.3. Core Practices

1.1.3.1. Define Everything as Code

1.1.3.1.1. Reusability

1.1.3.1.2. Consistency

1.1.3.1.3. Transparency

1.1.3.2. Continuously Test and Deliver All Work in Progress

1.1.3.3. Core Practice: Build Small, Simple Pieces That You Can Change Independently

1.1.4. Conclusion

1.2. 2. Principles of Cloud Age Infrastructure

1.2.1. Principles

1.2.1.1. Assume Systems Are Unreliable

1.2.1.2. Make Everything Reproducible

1.2.1.3. Create Disposable Things

1.2.1.4. Minimize Variation

1.2.1.5. Ensure That You Can Repeat Any Process

1.2.2. Snowflake Systems

1.2.3. Configuration Drift

1.2.4. The Automation Fear Spiral

1.2.5. Conclusion

1.3. 3. Infrastructure Platforms

1.3.1. The Parts of an Infrastructure System

1.3.1.1. Applications

1.3.1.2. Application runtimes

1.3.1.3. Infrastructure platform

1.3.2. Infrastructure Platforms

1.3.2.1. Public IaaS cloud services

1.3.2.2. Private IaaS cloud products

1.3.2.3. Bare-metal cloud tools

1.3.3. Multicoud

1.3.3.1. Hybrid cloud

1.3.3.2. Cloud agnostic

1.3.3.3. Polycloud

1.3.4. Infrastructure Resources

1.3.4.1. Compute Resources

1.3.4.1.1. Virtual machines (VMs)

1.3.4.1.2. Physical servers

1.3.4.1.3. Server clusters

1.3.4.1.4. Containers

1.3.4.1.5. Application hosting clusters

1.3.4.1.6. FaaS serverless code runtimes

1.3.4.2. Storage Resources

1.3.4.2.1. Block storage (virtual disk volumes)

1.3.4.2.2. Object storage

1.3.4.2.3. Networked filesystems (shared network volumes)

1.3.4.2.4. Structured data storage

1.3.4.2.5. Secrets management

1.3.4.3. Network Resources

1.3.4.3.1. Network address blocks

1.3.4.3.2. Names, such as DNS entries

1.3.4.3.3. Routes

1.3.4.3.4. Gateways

1.3.4.3.5. Load balancing rules

1.3.4.3.6. Proxies

1.3.4.3.7. API gateways

1.3.4.3.8. VPNs (virtual private networks)

1.3.4.3.9. Direct connection

1.3.4.3.10. Network access rules (firewall rules)

1.3.4.3.11. Asynchronous messaging

1.3.4.3.12. Cache

1.3.4.3.13. Service mesh

1.3.5. Conclusion

1.4. 4. Core Practice: Define Everything as Code

1.4.1. What You Can Define as Code

1.4.1.1. Choose Tools with Externalized Configuration

1.4.1.2. Manage Your Code in a Version Control System

1.4.1.2.1. Traceability

1.4.1.2.2. Rollback

1.4.1.2.3. Correlation

1.4.1.2.4. Visibility

1.4.1.2.5. Actionability

1.4.2. Infrastructure Coding Languages

1.4.2.1. Infrastructure Scripting

1.4.2.2. Declarative Infrastructure Languages

1.4.2.3. Programmable, Imperative Infrastructure Languages

1.4.2.4. Domain-Specific Infrastructure Languages

1.4.2.5. Idempotency

1.4.3. Implementation Principles for Defining Infrastructure as Code

1.4.3.1. Separate Declarative and Imperative Code

1.4.3.2. Treat Infrastructure Code Like Real Code

1.4.3.3. Code as Documentation

1.4.4. Conclusion

2. II. Working with Infrastructure Stacks

2.1. 5. Building Infrastructure Stacks as Code

2.1.1. What Is an Infrastructure Stack?

2.1.1.1. “Stack” As a Term

2.1.1.2. Stack Code

2.1.1.3. Stack Instance

2.1.1.4. Configuring Servers in a Stack

2.1.1.5. Low-Level Infrastructure Languages

2.1.1.6. High-Level Infrastructure Languages

2.1.2. Patterns and Antipatterns for Structuring Stacks

2.1.2.1. Antipatterns: Monolithic Stack

2.1.2.2. Patterns: Application Group Stack

2.1.2.3. Patterns: Service Stack

2.1.2.4. Patterns: Micro Stack

2.1.2.5. Blast Radius

2.1.3. Conclusion

2.2. 6. Building Environments with Stacks

2.2.1. What Environments Are All About

2.2.1.1. Delivery Environments

2.2.1.2. Multiple Production Environments

2.2.1.2.1. Fault tolerance

2.2.1.2.2. Scalability

2.2.1.2.3. Segregation

2.2.2. Patterns for Building Environments

2.2.2.1. Antipattern: Multiple-Environment Stack

2.2.2.2. Antipattern: Copy-Paste Environments

2.2.2.3. Pattern: Reusable Stack

2.2.3. Building Environments with Multiple Stacks

2.2.4. Conclusion

2.3. 7. Configuring Stack Instances

2.3.1. Using Stack Parameters to Create Unique Identifiers

2.3.1.1. Design Principle: Keep Parameters simple

2.3.2. Patterns for Configuring Stacks

2.3.2.1. Antipattern: Manual Stack Parameters

2.3.2.2. Pattern: Stack Environment Variables

2.3.2.3. Pattern: Scripted Parameters

2.3.2.4. Pattern: Stack Configuration Files

2.3.2.5. Pattern: Wrapper Stack

2.3.2.6. Pattern: Pipeline Stack Parameters

2.3.2.6.1. CI Servers, Pipelines, and Secrets

2.3.2.7. Pattern: Stack Parameter Registry

2.3.3. Configuration Registry

2.3.3.1. Implementing a Configuration Registry

2.3.3.1.1. Infrastructure Automation Tool Registries

2.3.3.1.2. General-Purpose Configuration Registry Products

2.3.3.1.3. Platform Registry Services

2.3.3.1.4. DIY ConfigurationRegistries

2.3.3.2. Single or Multiple Configuration Registries

2.3.4. Handling Secrets as Parameters

2.3.4.1. Encrypting Secrets

2.3.4.2. Secretless Authorization

2.3.4.3. Injecting Secrets at Runtime

2.3.4.4. Disposable Secrets

2.3.5. Conclusion

2.4. 8. Core Practice: Continuously Test and Deliver

2.5. 9. Testing Infrastructure Stacks

3. III. Working with Servers and Other Application Runtime Platforms

3.1. 10. Application Runtimes

3.2. 11. Building Servers as Code

3.3. 12. Managing Changes to Servers

3.4. 13. Server Images as Code

3.5. 14. Building Clusters as Code

4. IV. Designing Infrastructure

4.1. 15. Core Practice: Small, Simple Pieces

4.2. 16. Building Stacks from Components

4.3. 17. Using Stacks as Components

5. V. Delivering Infrastructure

5.1. 18. Organizing Infrastructure Code

5.2. 19. Delivering Infrastructure Code

5.3. 20. Team Workflows

5.4. 21. Safely Changing Infrastructure