33,59 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Build, combine, and launch infrastructure in a fast, secure, and effective manner
About This Book
- An up-to-date and comprehensive resource on Terraform that lets you quickly and efficiently launch your infrastructure
- Learn how to implement your infrastructure as code and make secure, effective changes to your infrastructure
- Learn to build multi-cloud fault-tolerant systems and simplify the management and orchestration of even the largest scale and most complex cloud infrastructures
Who This Book Is For
This book is for developers and operators who already have some exposure to working with infrastructure but want to improve their workflow and introduce infrastructure as a code practice.
Knowledge of essential Amazon Web Services components (EC2, VPC, IAM) would help contextualize the examples provided. Basic understanding of Jenkins and Shell scripts will be helpful for the chapters on the production usage of Terraform.
What You Will Learn
- Understand what Infrastructure as Code (IaC) means and why it matters
- Install, configure, and deploy Terraform
- Take full control of your infrastructure in the form of code
- Manage complete complete infrastructure, starting with a single server and scaling beyond any limits
- Discover a great set of production-ready practices to manage infrastructure
- Set up CI/CD pipelines to test and deliver Terraform stacks
- Construct templates to simplify more complex provisioning tasks
In Detail
Terraform is a tool used to efficiently build, configure, and improve production infrastructure. It can manage existing infrastructure as well as create custom in-house solutions.
This book shows you when and how to implement infrastructure as a code practices with Terraform. It covers everything necessary to set up complete management of infrastructure with Terraform, starting with the basics of using providers and resources.
This book is a comprehensive guide that begins with very small infrastructure templates and takes you all the way to managing complex systems, all using concrete examples that evolve over the course of the book. It finishes with the complete workflow of managing a production infrastructure as code – this is achieved with the help of version control and continuous integration. At the end of this book, you will be familiar with advanced techniques such as multi-provider support and multiple remote modules.
Style and approach
This book focuses on providing the practical skills required to make full use of Terraform. It will take the readers slowly from very small infrastructure templates to the managing complex systems, all by using concrete examples, evolving over the course of the book.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 249
Veröffentlichungsjahr: 2017
Ähnliche
Table of Contents
Getting Started with Terraform
Getting Started with Terraform
Copyright © 2017 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: January 2017
Production reference: 1240117
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham
B3 2PB, UK.
ISBN 978-1-78646-510-8
www.packtpub.com
Credits
Author
Kirill Shirinkin
Copy Editor
Dipti Mankame
Reviewer
Anton Babenko
Project Coordinator
Judie Jose
Commissioning Editor
Kartikey Pandey
Proofreader
Safis Editing
Acquisition Editor
Prachi Bisht
Indexer
Pratik Shirodkar
Content Development Editor
Abhishek Jadhav
Graphics
Kirk D'Penha
Technical Editor
Aditya Khadye
Production Coordinator
Deepika Naik
About the Author
Kirill Shirinkin is an IT consultant who focuses on Cloud technologies and DevOps practices. He has worked in companies of different sizes and areas, from an online language learning leader to a major IT provider for the global travel industry and one of the largest management consultancies. He is also a cofounder of online mentorship platform mkdev.me, where he leads a team and teaches his students all about DevOps.
About the Reviewer
Anton Babenko is currently working as a senior automation engineer at Stelligent Systems AB, where he specializes in infrastructure management and deployment using Amazon Web Services. He is an AWS certified professional with all five available certifications. Also, he has been working as a web developer, team lead, and chief technology officer for the last 10 years. He has been constantly involved in automation (from testing to marketing) and exploring ways to do it properly and as risk-free as possible. He has strong interest and experience in the DevOps toolset.
www.PacktPub.com
For support files and downloads related to your book, please visit www.PacktPub.com.
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www.packtpub.com/mapt
Get the most in-demand software skills with Mapt. Mapt gives you full access to all Packt books and video courses, as well as industry-leading tools to help you plan your personal development and advance your career.
Why subscribe?
Customer Feedback
Thank you for purchasing this Packt book. We take our commitment to improving our content and products to meet your needs seriously—that's why your feedback is so valuable. Whatever your feelings about your purchase, please consider leaving a review on this book's Amazon page. Not only will this help us, more importantly it will also help others in the community to make an informed decision about the resources that they invest in to learn.
You can also review for us on a regular basis by joining our reviewers' club. If you're interested in joining, or would like to learn more about the benefits we offer, please contact us: [email protected].
Preface
With ever-rising adoption of Cloud technologies and infrastructure SaaS products, as well as always the constantly sizes of infrastructures the need, to manage it all in the form of code becomes more and more apparent. Cloud providers such as Amazon Web Services have dozens of services and all of them require secure, re-usable and predictable configuration. Terraform, the primary tool for this job, appeared in 2014 and quickly gained popularity among system administrators and software developers. Since the first release, Terraform has achieved a lot of traction. It became the new de facto tool for managing the cloud environments. Terraform is also a tool that is quite new, that is changing with every release and that requires a new mindset and new practices from teams that adopt it.
In this book you will learn how Terraform works and how to use it, with many examples of real-life applications of it. You will explore modern approaches to managing the infrastructure, such as Infrastructure as Code and Immutable Infrastructure. You will also learn many new small utilities that either improve the experience of working with Terraform or cover the layers that Terraform is not supposed to manage. By the end of this book not only will you now how to use Terraform, but you will be in an expert in treating your whole Infrastructure as Code, with Terraform being the core of this procedure.
What this book covers
Chapter 1, Infrastructure Automation, covers infrastructure automation in general, why is it needed at all (with a list of the main reasons to do it) and which tools exist to solve this problem. By the end of this chapter you will know which problem Terraform solves and why it is the best tool for particular infrastructure automation tasks.
Chapter 2, Deploying First Server, walks through all the necessary steps to install Terraform, gives a short overview of AWS and EC2, and explain in detail how to create your very first EC2 instance with Terraform.
Chapter 3, Resource Dependencies and Modules, explains one of most important features of Terraform: dependency graph. You will figure out how dependencies work and see it in practice by extending the template from previous chapter. At the moment we find out our template is too big, we will use Terraform modules to DRY our code and also use more advanced dependency features.
Chapter 4, Storing and Supplying Configuration, teaches how to make Terraform templates more configurable. You will see all the possible ways to supply data to Terraform templates, to basic variables to using any external data source.
Chapter 5, Connecting with Other Tools, talks about how you can connect Terraform templates to external tools. It shows how to combine Terraform and Ansible, Puppet, or Chef, how to provision servers, and how to run Inspec tests against them.
Chapter 6, Scaling and Updating Infrastructure, dives deep into managing existing infrastructures with Terraform. It gives an overview of the various ways to perform updates with Terraform and explains what Immutable Infrastructure is and how to use it with Terraform. It gives a full example of performing both rolling updates and blue-green deployments, as well as tricks on running smaller updates.
Chapter 7, Collaborative Infrastructure, provides best practices of using Terraform in a team. It shows how to refactor and split Terraform templates into remote modules, how to organize your code to be re-usable, and how to handle sensitive data inside Terraform templates. It also teaches how to do full Continuous Integration of a Terraform-based infrastructure.
Chapter 8, Future of Terraform, speculates on the future of Terraform. It also recaps everything learned so far and gives some extra thoughts and hints on topics that were too small too deserve a separate chapter.
What you need for this book
This book assumes a basic level of understanding the Linux operating system. The book will go through configuring numerous AWS resources. Being familiar with AWS is a plus, but is not required, as all required services will be explained. Usage of some cloud services in this book will require you to spend a dollar or two on them. Although the book assumes Linux as the primary workstation operating system, all of the content applies to MacOS and most of it will work the same way on Windows as well.
Internet connectivity is required to install the necessary tools, including Terraform. It is also required to perform any Terraform operations.
Who this book is for
This book is essentially intended to both software developers and system administrators, as well as specialists who have knowledge of both areas: system reliability engineers, DevOps engineers, cloud architects and so on.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book-what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of. To send us general feedback, simply e-mail [email protected], and mention the book's title in the subject of your message. If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code
You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
You can download the code files by following these steps:
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/Getting-Started-with-Terraform. We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!
Downloading the color images of this book
We also provide you with a PDF file that has color images of the screenshots/diagrams used in this book. The color images will help you better understand the changes in the output. You can download this file from https://www.packtpub.com/sites/default/files/downloads/GettingStartedwithTerraform_ColorImages.pdf.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books-maybe a mistake in the text or the code-we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at [email protected] with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at [email protected], and we will do our best to address the problem.
Chapter 1. Infrastructure Automation
Before starting to learn Terraform, you first need to learn certain concepts in the modern infrastructure. To be able to use the new tool, one needs to understand what problem it solves. In order to do it, this chapter will cover the following topics:
What is Infrastructure as Code and why is it needed?
The amount of servers used by almost any project is growing rapidly mostly due to increasing adoption of cloud technologies. As a result, traditional ways of managing IT infrastructure become less and less relevant.
The manual approach fits well for the farm of a dozen, perhaps even a couple of dozens of servers. But when we're talking about hundreds of them, doing anything by hand is definitely not going to play out well.
It's not only about servers, of course. Every cloud provider gives extra services on top, be it a virtual networking service, an object storage, or a monitoring solution, which you don't need to maintain yourself. These services function like a Software as a Service (SaaS). And actually, we should treat various SaaS products as part of our infrastructure as well. If you use NewRelic for monitoring purposes, then it is your infrastructure too, with the difference that you don't need to manage servers for it yourself. But how you use it and whether you use it correctly is up to you.
No surprises, companies of any size, from small start-ups to huge enterprises, are adopting new techniques and tools to manage and automate their infrastructures. These techniques got a new name eventually: Infrastructure as Code (IaC).
Dated something around 2009, the Infrastructure as Code term is all about approaching your IT-infrastructure tasks the same way you develop software. This includes the things similar to the following:
Infrastructure as Code is a foundation for DevOps culture because once both operations and developers approach their work in the same way and by following principles laid out preceding, they already have some common ground.
Not saying that if your infrastructure is treated like code, then the border between development and operations becomes so blurry that the whole existence of this separation can become eventually quite questionable.
Of course, the introduction of Infrastructure as Code requires a new kind of tools.
Declarative vs Procedural tools for Infrastructure as Code
What is infrastructure code specifically? It highly depends on your particular infrastructure setup.
In the simplest case, it might be just a bunch of shell scripts and component-specific configuration files (Nginx configuration, cron jobs, and so on) stored in source control. Inside these shell scripts, you specify exact steps computer needs to take to achieve the state you need:
This is what we call procedural programming. It's not bad. For example, build steps of Continuous Integration tools such as Jenkins that are a perfect fit for a procedural approach—after all the sequence of command is exactly what you need in this case.
However, you can only go that far with shell scripts when it comes to configuring servers and higher level pieces. The more common and mature approach these days is to use tools that provide a declarative, rather than a procedural way to define your infrastructure. With declarative definitions, you don't need to think how to do something; you only write what should be there.
Perhaps the main benefit of it is that rerunning a declarative definition will never do the same job twice, whereas executing the same shell script will most likely break something on the second run. Proper configuration management tool will ensure that the server will be in the exactly same state as defined in your code. This property of modern configuration and provisioning tools is named idempotency.
Let's look at an example. Let's say that you have a box in your network that hosts packages repository. For some reason, instead of using DNS server, you want to hardcode the IP address of this box to the /etc/hosts file with a domain name repository.internal.
Note
In Unix-like systems, the /etc/hosts file contains a local text database of DNS records. The system tries to resolve DNS name by looking at this file first, and only asking DNS-server only after.
Not a complex task to do, given that you only need to add a new line to the /etc/hosts file. To achieve this, you could have a script like the following:
echo 192.168.0.5 repository.internal >> /etc/hosts/hostsRunning it once will do the job: required entry will be added to the end of the /etc/hosts file. But what will happen if you execute it again? You guessed it right: exactly the same line will be appended again. And even worse, what if the IP address of repository box will change? Then, if you execute your script, you will end up with two different host entries for the same domain name.
You can ensure idempotency yourself inside the script, with the high usage of conditional checks. But why reinvent the wheel when there is already a tool to do exactly this job? It would be so much better to just define the end result, without composing sequence of commands to achieve this.
And that is exactly what configuration management tools such as Puppet and Chef do by providing you a special Domain Specific Language (DSL) for defining the desired state of the machine. The certain downside is the necessity to learn a new DSL: a special small language focused on solving one particular task. It's not a complete programming language, neither does it to be; in this case, its only job is to describe the state of your server.
Let's look at how the same task could be done with the help of a Puppet manifest:
host { 'repository.internal': ip => '192.168.0.5', }Applying this manifest multiple times will never add extra entries, and changing the IP address in the manifest will be reflected correctly in host files changing the existing entry, and not creating a new one.
Note
There is an additional benefit I should mention: on top of idempotency, you often get platform agnosticism. What it means is that the same definition could be used for completely different operating systems without any change. For example, by using package resource in Puppet, you don't care whether the underlying system uses rpm or deb.
Now you should better understand that when it comes to configuration management tools that provide the declarative way of doing things are preferred.
Modern configuration management tools such as Chef or Puppet completely solved the problem of setting up a single machine. There is an increasing number of high-quality libraries (be it cookbooks or modules) for configuring all kinds of software in an (almost) OS-agnostic way. But configuring what goes inside single server is only part of the picture. The other part that is located a layer above also requires a new tooling.
Infrastructure as Code in the Cloud
Quite often servers are only one part of infrastructure. With cloud platforms such as Amazon Web Services (AWS), Google Cloud Platform, and OpenStack advancing more and more, there is an increased need for automating and streamlining the way people work with services these platforms provide. If you rely heavily on at least one cloud provider for major parts of your project, you will start meeting challenges in applying consistent patterns of their usage.
The approach of modern configuration management tools, while having been around for quite some time and having been adopted by many companies, has some inconveniences when it comes to managing anything but servers.
There is a strong likelihood you would want these patterns to be written once and then applied automatically. Even more, you need to be able to reproduce every action and test its result of it, following the aforementioned Infrastructure as Code principles. Otherwise, working with cloud providers will either end up in so-called ClickOps, where you work with infrastructure primarily by clicking buttons in web interface of cloud provider, or you will script all the processes by using APIs of this provider directly. And even if scripting APIs sounds like a big step towards true Infrastructure as Code, you can achieve much more using existing tools for this exact task.
There is a certain need for configuration tool that operates one level higher than a setup of a single server, a tool that would allow writing a blueprint that would define all of the high-level pieces at once: servers, cloud services, and even external SaaS products. A tool like this is called differently: infrastructure orchestrator, infrastructure provisioner, infrastructure templating, and so on. No matter how you call it, at some point in time, your infrastructure will really need it.
Requirements for infrastructure provisioner
Before proceeding to the existing solutions, let's lay out the list of most important requirements for a tool such as this, so we are able to choose it wisely.
Supports a wide variety of services
AWS alone already has dozens of entities to take care of. Other players (DigitalOcean, Google Cloud, Microsoft Azure, and so on) increase this number significantly. And if you want to add smaller SaaS providers to the game, you get hundreds of resources to manage.
Idempotency
Same as with a single server configuration, reapplying infrastructure template should not do the job twice. If you have a template defining 50 different resources, from EC2 instances to S3 buckets, then you do not want to duplicate or recreate all of them every time you apply the template. You want only missing parts to be created, existing ones to be in the desired state and the ones, which have become obsolete to be destroyed.
Dependency resolution
It is important to be able not just to define 2 app servers, 1 DB server and 2 security groups,but to also point them to each other using some lookup mechanism. Especially when creating a complete environment from scratch, you want to ensure the correct order of creation to achieve a flawless bootstrap of each component.
Note
Here and further in the book, the term environment will mean a complete set of resources that infrastructure consists of. It includes a network setup, all servers, and all related resources.
Robust integration with existing tools
Even though it is pretty awesome to have all infrastructure in one beautiful template, you still need to take care of what is happening on each particular server: applications need to be deployed, databases need to be configured, and so on. This is not the job for infrastructure provisioning tool. But certainly a tool like this should easily integrate with other tools such as Chef, which solves this problem already.
Platform agnosticism
Ideally, templates should be platform agnostic. This means that if I define a template for 2 app servers, 1 db server, all talk to each other, I should be able to easily switch from AWS to local Vagrant without rewriting the template. Platform agnosticism is difficult to obtain, while at the same time, might not really be needed that often. Completely changing the underlying platform is a rather rare event that happens perhaps once or twice in a product's lifetime.
Smart update management
This is a tricky one, and at the moment of writing, no tool can do it flawlessly in every case (and, honestly, unlikely it will ever do). What happens when I change a type of three EC2 instances from m3.medium to c4.xlarge? Will my m3.medium instances shut down and be replaced one by one with new ones? Will they be instantly destroyed leading to a few minutes of downtime? Or will the tool just ignore the updated instance type? Or will it not and then just override old nodes and I will end up with three new nodes and three old EC2 instances that I have to remove manually? Solutions to this problem differ from platform to platform, which makes it more complicated for the tool to be platform agnostic.
Ease of extension
The last requirement is of particular importance: there must be an easy way to extend this tool to support other resources. For example, if a tool lacks support for AWS Kinesis or particular feature or property of already supported service, and there is no plan to support it officially, then there has to be a way to implement it yourself quickly.
