Kief Morris - Infrastructure as Code
Here you can read online Kief Morris - Infrastructure as Code full text of the book (entire story) in english for free. Download pdf and epub, get meaning, cover and reviews about this ebook. year: 2020, publisher: OReilly Media, Inc., genre: Computer. Description of the work, (preface) as well as reviews are available. Best literature library LitArk.com created for fans of good reading and offers a wide selection of genres:
Romance novel
Science fiction
Adventure
Detective
Science
History
Home and family
Prose
Art
Politics
Computer
Non-fiction
Religion
Business
Children
Humor
Choose a favorite category and find really read worthwhile books. Enjoy immersion in the world of imagination, feel the emotions of the characters or learn something new for yourself, make an fascinating discovery.
- Book:Infrastructure as Code
- Author:
- Publisher:OReilly Media, Inc.
- Genre:
- Year:2020
- Rating:5 / 5
- Favourites:Add to favourites
- Your mark:
Infrastructure as Code: summary, description and annotation
We offer to read an annotation, description, summary or preface (depends on what the author of the book "Infrastructure as Code" wrote himself). If you haven't found the necessary information about the book — write in the comments, we will try to find it.
Kief Morris: author's other books
Who wrote Infrastructure as Code? Find out the surname, the name of the author of the book and a list of all author's works by series.
Infrastructure as Code — read online for free the complete book (whole text) full work
Below is the text of the book, divided by pages. System saving the place of the last page read, allows you to conveniently read the book "Infrastructure as Code" online for free, without having to search again every time where you left off. Put a bookmark, and you can go to the page where you finished reading at any time.
Font size:
Interval:
Bookmark:
by Kief Morris
Copyright 2020 Kief Morris. All rights reserved.
Printed in the United States of America.
Published by OReilly Media, Inc. , 1005 Gravenstein Highway North, Sebastopol, CA 95472.
OReilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com .
- Editors: John Devins and Virginia Wilson
- Production Editor: Christopher Faucher
- Cover Designer: Karen Montgomery
- June 2016: First Edition
- July 2020: Second Edition
- 2019-12-03: First Release
- 2020-01-22: Second Release
See http://oreilly.com/catalog/errata.csp?isbn=9781098114671 for release details.
The OReilly logo is a registered trademark of OReilly Media, Inc. Infrastructure as Code, the cover image, and related trade dress are trademarks of OReilly Media, Inc.
While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.
978-1-098-11460-2
Modern organizations are increasingly using dynamic cloud platforms, whether public or private, to exploit digital technology to deliver services and products to their users. Automation is essential to managing continuously changing and evolving systems, and tools that define systems as code have become dominant for this.
Although cloud technology and infrastructure coding tools are becoming pervasive, most teams are still learning the best ways to put them to use.
This book is my attempt to share what Ive learned from various people, teams, and organizations. Im not giving you specific instructions on how to implement a specific tool or language. Instead, Ive assembled principles, practices, and patterns that you can use to shape how you approach the design, implementation, and evolution of your infrastructure.
These draw heavily on agile engineering principles and practices. I believe that given cloud-based infrastructure is essentially just another software system, we can benefit from lessons learned in other software domains.
Infrastructure as code has grown along with the DevOps movement. Andrew Clay-Shafer and Patrick Debois triggered the DevOps movement with . My own Infrastructure as Code journey began a decade or so before this.
I set up my first server, a dialup BBS,
By 2007, my team had accumulated around 20 1U and 2U physical servers in our offices server racks. These overflowed with test instances of our companys software, along with a variety of miscellaneous applications and services - a couple of wikis, bug trackers, DNS servers, mail servers, databases, and so on. Whenever someone found something else to run, we crammed it onto an existing server. When the product folks wanted a new environment, it took several weeks to order and assemble the hardware.
Then we learned that virtualization was a thing. We started with a pair of beefy HP rack servers and VMWare ESX Server licenses, and before long, everything was a VM. Every application could run on a dedicated VM, and it took minutes to create a new environment.
Virtualization made it easy to create new servers, which solved one set of problems. But it led to a whole new set of problems.
A year later, we were running well over 100 VMs and counting. We were well underway with virtualizing our production servers and experimenting with Amazons 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 our infrastructures shocking appetite for storage.
We created virtual servers, then more, then even more. They overwhelmed us. When something broke, we tracked down the VM and fixed whatever was wrong with it, but we couldnt keep track of what changes wed made where. We felt like Mickey Mouse in The Sorcerers Apprentice from Fantasia (an adaption of the von Goethe poem).
Well, a perfect hit!
See how he is split!
Now theres 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, Im begging you!
Excerpted from Brigitte Dubiels translation of Der Zauberlehrling (The Sorcerers Apprentice) by Johann Wolfgang von Goethe
We faced a never-ending stream of updates to the operating systems, web servers, application servers, database servers, JVMs, and other software packages we used. We struggled to keep up with them. We might apply them successfully to some VMs, but on others, the upgrades broke things. We didnt have time to stomp out every incompatibility, and over time had many combinations of versions of things strewn across hundreds of VMs.
We were using configuration automation software even before we virtualized, which should have helped with these issues. I had used CFEngine in previous companies, and when I started this team, we tried a new tool called Puppet. Later, my colleague introduced us to Chef when he spiked out ideas for an AWS infrastructure. All of these tools were useful, but particularly in the early days, they didnt get us out of the quagmire of wildly different servers.
In theory, we should have configured our automation tools to run continuously, applying and reapplying the same configuration to all of our servers every hour or so. But we didnt trust them enough to let them run unattended. We had too much variation across our servers, and it was too easy for something to break without us noticing. We would write a Puppet manifest to configure and manage a particular application server. But when we ran it against a different server, we found that it had a different version of Java, application server software, or OS packages. The Puppet run would fail, or worse, corrupt 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 to make it work. We would write a new manifest to carry out a specific upgrade, and then run it against our servers one at a time, carefully checking the result and making fixes as needed.
Configuration automation was a useful aid, better than shell scripts, but the way we used it didnt save us from our sprawl of inconsistent servers.
Things changed when we began moving things onto the cloud. The technology itself wasnt 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 managing servers based on what we had learned with our virtualized farm. We also followed what people were doing 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 we could rebuild every server automatically from scratch. 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 include it or else fix the design of the service so that it was no longer an edge case.
Font size:
Interval:
Bookmark:
Similar books «Infrastructure as Code»
Look at similar books to Infrastructure as Code. We have selected literature similar in name and meaning in the hope of providing readers with more options to find new, interesting, not yet read works.
Discussion, reviews of the book Infrastructure as Code and just readers' own opinions. Leave your comments, write what you think about the work, its meaning or the main characters. Specify what exactly you liked and what you didn't like, and why you think so.