云计算时代：基础设施即代码的转型与实践

需积分: 9 121 浏览量更新于2024-07-19 收藏 8.19MB PDF 举报

"《基础设施即代码》(Infrastructure as Code)是一本深入探讨如何利用云计算、虚拟化和配置自动化技术，将IT基础设施管理融入软件开发方法的著作。随着DevOps运动的发展，基础设施即代码的概念应运而生，它将源控制系统、测试驱动开发(TDD)和持续集成(CI)等软件开发实践与基础设施管理相结合。这本书的目的是解决传统硬件基础设施管理中的挑战，如难以自动化扩展的服务器环境，以及团队在面对多变且不一致的服务器配置时所遇到的问题。在过去的硬件时代，基础设施管理往往依赖于手动操作和定制配置，这在虚拟化和云环境中变得不再适用。通过基础设施即代码，团队可以采用敏捷开发的理念，比如版本控制、模块化和自动化测试，来标准化和管理云中的服务器和资源。例如，Netflix、Amazon和Etsy等知名企业以及传统行业如出版商、银行甚至英国政府，都在实践中证明了这一方法的有效性。书中详细阐述了如何运用这些原则和工具，实现基础设施的模块化、版本化和自动化管理，包括如何编写基础设施定义语言(Infrastructure Definition Language, IDL)如YAML或JSON，以便在云平台如AWS、Azure或Google Cloud中实现自动部署。此外，还会介绍如何进行持续交付和持续部署，确保基础设施的稳定性和可靠性，同时提升团队的协作效率。作者Kief Morris在书中分享了他在云计算环境下的服务器管理经验，以及在波士顿、Farnham、Sebastopol、Tokyo和Beijing等地的案例研究。该书的ISBN是978-1-491-92435-8，版权信息表明此书于2016年首次出版，并由O'Reilly Media公司发行。本书不仅适合DevOps团队阅读，也对希望转型或提升云基础设施管理能力的企业和个人具有参考价值。在第一版的修订历史中，该书于2016年6月7日首次发布，并提供了在线版本供读者选择。如果你对如何将基础设施视为可管理的代码，或者想了解如何利用DevOps方法改进IT基础设施管理，那么《基础设施即代码》将是你不可错过的一本书。"

Things came to a head with virtualization. The story of my stumbling adoption of

virtualization and the cloud may be familiar, and it illustrates the role that infrastruc‐

ture as code has to play in modern IT operations.

My First Virtual Server Farm

I was thrilled when my team got the budget to buy a pair of beefy HP rack servers and

licenses for VMware ESX Server back in 2007.

We had in our office’s server racks around 20 1U and 2U servers named after fruits

(Linux servers) and berries (Windows database servers) running test environments

for our development teams. Stretching these servers to test various releases, branches,

and high-priority, proof-of-concept applications was a way of life. Network services

like DNS, file servers, and email were crammed onto servers running multiple appli‐

cation instances, web servers, and database servers.

So we were sure these new virtual servers would change our lives. We could cleanly

split each of these services onto its own virtual machine (VM), and the ESX hypervi‐

sor software would help us to squeeze the most out of the multicore server machines

and gobs of RAM we’d allocated. We could easily duplicate servers to create new

environments and archive those servers that weren’t needed onto disk, confident they

could be restored in the future if needed.

Those servers did change our lives. But although many of our old problems went

away, we discovered new ones, and we had to learn completely different ways of

thinking about our infrastructure.

Virtualization made creating and managing servers much easier. The flip side of this

was that we ended up creating far more servers than we could have imagined. The

product and marketing people were delighted that we could give them a new envi‐

ronment to demo things in well under a day, rather than need them to find money in

the budget and then wait a few weeks for us to order and set up hardware servers.

The Sorcerer’s Apprentice

A year later, we were running well over 100 VMs and counting. We were well under‐

way with virtualizing our production servers and experimenting with Amazon’s new

cloud hosting service. The benefits virtualization had brought to the business people

meant we had money for more ESX servers and for shiny SAN devices to feed the

surprising appetite our infrastructure had for storage.

But we found ourselves a bit like Mickey Mouse in “The Sorcerer’s Apprentice” from

Fantasia. We spawned virtual servers, then more, then even more. They over‐

whelmed us. When something broke, we tracked down the VM and fixed whatever

was wrong with it, but we couldn’t keep track of what changes we’d made where.

xiv | Preface

Well, a perfect hit!

See how he is split!

Now there’s hope for me,

and I can breathe free!

Woe is me! Both pieces

come to life anew,

now, to do my bidding

I have servants two!

Help me, O great powers!

Please, I’m begging you!

—Excerpted from Brigitte Dubiel’s translation of “Der Zauberlehrling” (“The Sor‐

cerer’s Apprentice”) by Johann Wolfgang von Goethe

As new updates to operating systems, web servers, app servers, database servers,

JVMs, and various other software packages came out, we would struggle to install

them across all of our systems. We would apply them successfully to some servers,

but on others the upgrades broke things, and we didn’t have time to stomp out every

incompatibility. Over time, we ended up with many combinations of versions of

things strewn across hundreds of servers.

We had been using configuration automation software even before we virtualized,

which should have helped with these issues. I had used CFEngine in previous compa‐

nies, and when I started this team, I tried a new tool called Puppet. Later, when spik‐

ing out ideas for an AWS infrastructure, my colleague Andrew introduced Chef. All

of these tools were useful, but particularly in the early days, they didn’t get us out of

the quagmire of wildly different servers.

The problem was that, although Puppet (and Chef and the others) should have been

set up and left running unattended across all of our servers, we couldn’t trust it. Our

servers were just too different. We would write manifests to configure and manage a

particular application server. But when we ran it against another, theoretically similar

app server, we found that different versions of Java, application software, and OS

components would cause the Puppet run to fail, or worse, break the application

server.

So we ended up using Puppet ad hoc. We could safely run it against new VMs,

although we might need to make some tweaks after it ran. We would write manifests

for a specific task and then run them against servers one at a time, carefully checking

the result and making fixes as needed.

So configuration automation was a useful aid, somewhat better than shell scripts, but

the way we used it didn’t save us from our sprawl of inconsistent servers.

Preface | xv

Cloud from Scratch

Things changed when we began moving things onto the cloud. The technology itself

wasn’t what improved things; we could have done the same thing with our own

VMware servers. But because we were starting fresh, we adopted new ways of manag‐

ing servers based on what we had learned with our virtualized farm and on what we

were reading and hearing from IT Ops teams at companies like Flickr, Etsy, and

Netflix. We baked these new ideas into the way we managed services as we migrated

them onto the cloud.

The key idea of our new approach was that every server could be automatically

rebuilt from scratch, and our configuration tooling would run continuously, not ad

hoc. Every server added into our new infrastructure would fall under this approach.

If automation broke on some edge case, we would either change the automation to

handle it, or else fix the design of the service so it was no longer an edge case.

The new regime wasn’t painless. We had to learn new habits, and we had to find ways

of coping with the challenges of a highly automated infrastructure. As the members

of the team moved on to other organizations and got involved with communities

such as DevOpsDays, we learned and grew. Over time, we reached the point where

we were habitually working with automated infrastructures with hundreds of servers,

with much less effort and headache than we had been in our “Sorcerer’s Apprentice”

days.

Joining ThoughtWorks was an eye-opener for me. The development teams I worked

with were passionate about using XP engineering practices like test-driven develop‐

ment (TDD), continuous integration (CI) and continuous delivery (CD). Because I

had already learned to manage infrastructure scripts and configuration files in source

control systems, it was natural to apply these rigorous development and testing

approaches to them.

Working with ThoughtWorks has also brought me into contact with many IT opera‐

tions teams, most of whom are using virtualization, cloud, and automation tools to

handle a variety of challenges. Working with them to share and learn new ideas and

techniques has been a fantastic experience.

Why I’m Writing This Book

I’ve run across many teams who are in the same place I was a few years ago: people

who are using cloud, virtualization, and automation tools but haven’t got it all run‐

ning as smoothly as they know they could.

Much of the challenge is time. Day-to-day life for system administrators is coping

with a never-ending flow of critical work. Fighting fires, fixing problems, and setting

xvi | Preface

up new business-critical projects doesn’t leave much time to work on the fundamen‐

tal improvements that will make the routine work easier.

My hope is that this book provides a practical vision for how to manage IT infra‐

structure, with techniques and patterns that teams can try and use. I will avoid the

details of configuring and using specific tools so that the content will be useful for

working with different tools, including ones that may not exist yet. Meanwhile, I will

use examples from existing tools to illustrate points I make.

The infrastructure-as-code approach is essential for managing cloud infrastructure of

any real scale or complexity, but it’s not exclusive to organizations using public cloud

providers. The techniques and practices in this book have proven effective in virtual‐

ized environments and even for bare-metal servers that aren’t virtualized.

Infrastructure as Code is one of the cornerstones of DevOps. It is the “A” in “CAMS”:

culture, automation, measurement, and sharing.

Who This Book Is For

This book is for people who work with IT infrastructure, particularly at the level of

managing servers and collections of servers. You may be a system administrator,

infrastructure engineer, team lead, architect, or a manager with technical interest.

You might also be a software developer who wants to build and use infrastructure.

I’m assuming you have some exposure to virtualization or IaaS (Infrastructure as a

Service) cloud, so you know how to create a server, and the concepts of configuring

operating systems. You’ve probably at least played with configuration automation

software like Ansible, Chef, or Puppet.

While this book may introduce some readers to infrastructure as code, I hope it will

also be interesting to people who work this way already and a vehicle through which

to share ideas and start conversations about how to do it even better.

What Tools Are Covered

This book doesn’t offer instructions in using specific scripting languages or tools.

There are code examples from specific tools, but these are intended to illustrate con‐

cepts and approaches, rather than to provide instruction. This book should be helpful

to you regardless of whether you use Chef on OpenStack, Puppet on AWS, Ansible

on bare metal, or a completely different stack.

The specific tools that I do mention are ones which I’m aware of, and which seem to

have a certain amount of traction in the field. But this is a constantly changing land‐

scape, and there are plenty of other relevant tools.

Preface | xvii

The tools I use in examples tend to be ones with which I am familiar enough to write

examples that demonstrate the point I’m trying to make. For example, I use Terra‐

form for examples of infrastructure definitions because it has a nice, clean syntax,

and I’ve used it on multiple projects. Many of my examples use Amazon’s AWS cloud

platform because it is likely to be the most familiar to readers.

How to Read This Book

Read Chapter 1, or at least skim it, to understand the terms this book uses and the

principles this book advocates. You can then use this to decide which parts of the

book to focus on.

If you’re new to this kind of automation, cloud, and infrastructure orchestration tool‐

ing, then you’ll want to focus on Part I, and then move on to Part II. Get comfortable

with those topics before proceeding to Part III.

If you’ve been using the types of automation tools described here, but don’t feel like

you’re using them the way they’re intended after reading Chapter 1, then you may

want to skip or skim the rest of Part I. Focus on Part II, which describes ways of using

dynamic and automated infrastructure that align with the principles outlined in

Chapter 1.

If you’re comfortable with the dynamic infrastructure and automation approaches

described in Chapter 1, then you may want to skim Parts I and II and focus on

Part III, which gets more deeply into the infrastructure management regime: archi‐

tectural approaches as well as team workflow.

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 ele‐

ments such as variable or function names, databases, data types, environment

variables, statements, and keywords.

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 deter‐

mined by context.

xviii | Preface

剩余361页未读，继续阅读

feng_kwuo

粉丝: 0
资源: 13

云计算时代：基础设施即代码的转型与实践

Infrastructure-As-Code-Intro:我的基础架构示例（代码网络研讨会）

Terraform: Up and Running: Writing Infrastructure as Code

Infrastructure as Code Managing Servers in the Cloud epub

Infrastructure as as Code教程：Infrastructure as Code教程。 涵盖了Packer，Terraform，Ansible，Vagrant，Docker，Docker Compose，Kubernetes

Infrastructure as Code Managing Servers in the Cloud

Terraform Up and Running Writing Infrastructure as Code epub

Terraform Up and Running Writing Infrastructure as Code azw3

Infrastructure as Code在阿里的初步实践.pdf

Infrastructure as Code在阿里的初步实践.pptx

THR1136 - Getting started with infrastructure as code.pptx

最新资源

Infrastructure as as Code教程：Infrastructure as Code教程。涵盖了Packer，Terraform，Ansible，Vagrant，Docker，Docker Compose，Kubernetes