DevOps and Kubernetes Fundamentals - Infrastructure As Code With Terraform

Download as pdf or txt
Download as pdf or txt
You are on page 1of 48

DevOps and Kubernetes

Fundamentals
TRAINING

Lecturer:
Mehmetali Shaqiri
CTO @ Appstellar

Tuesday: 18:00 - 21:00


12.04.2022
Thursday: 18:00 - 21:00
28.05.2022 Saturday: 10:00 - 13:00

+
Who am I?
Mehmetali Shaqiri
CTO & Founder @ Appstellar

Before Appstellar, I co-founded a


few other companies (Worksense,
Spartansoft) and CTOed a few AWS Certified Solutions
others (MonoChain, Solaborate, Architect - Professional
CREA-KO).

I've been in the industry for 16+


years and I'm currently focused on HashiCorp Certified:
cloud infrastructure. Terraform Associate
Who Appstellar Is
Prishtina-based tech company focused on cloud software
development and DevOps services for businesses that
want to reach new heights.
Our greatest mission is to help people shape their
ideas into out-of-this-world products—and our
greatest pride is that we do it efficiently.

Founded by Mehmetali Shaqiri and


Rozafë Llalloshi in 2020

Combined experience of 23+ years

Specialized in building highly skilled


dedicated teams of developers for
startups and established businesses
in need of robust software solutions
What We Do

DEVOPS SERVICES
DEVOPS CONSULTING AND
CLOUD SOFTWARE IMPLEMENTATION
DEVELOPMENT KUBERNETES ENABLEMENT
AWS CLOUD CONSULTING
SERVERLESS SOLUTIONS
CONTAINERIZED SOLUTIONS
Infrastructure as Code
with Terraform
Get started with Terraform
Intro: Let's get things started

Terraform is one of the most


popular DevOps tools for
Infrastructure as code.
In this workshop, we will walk you through the
fundamentals of Terraform and help you not
only understand the basics but also practice
and gain hands-on experience.

4
Today's
8 Modules

9 State

Agenda 10 Resources

1 Traditional IT & Challenges


11 Data Sources

2 Infrastructure as Code
12 Variables and Outputs

3 What Is Terraform?
13 Input Variables

4 The Problem?
14 Terraform Lifecycle

5 Major Components
15 Practicing time 👨‍💻

6 Core Concepts
16 Installing Terraform

7 Providers
17 Hands-on Labs

2. Infrastructure as Code

12
2. INFRASTRUCTURE AS CODE

Types of IaC

CONFIGURATION SERVER PROVISIONING


MANAGEMENT TEMPLATING TOOLS

13
2. INFRASTRUCTURE AS CODE

2.2. Server templating tools

Pre-installed software and dependencies

Virtual machine or Docker images

Immutable infrastructure

Main use:
to create a custom image of a virtual machine or container

14
2. INFRASTRUCTURE AS CODE

2.1. Configuration Management

Designed to install and manage software

Maintains standard culture

Version Control

Idempotent

Main use:
to install and manage software on existing infrastructure resources

15
2. INFRASTRUCTURE AS CODE

2.3. Provisioning Tools

Deploy immutable infrastructure resources

Servers, databases, network components, etc.

Multiple providers

Main use:
to provision infrastructure components using a simple declarative
code

16
3. What is Terraform?
Terraform is an open-source infrastructure as Code tool developed by HashiCorp. It is used to
define and provision the complete infrastructure using an easy-to-learn declarative language.

17
3. WHAT IS TERRAFORM?

3.1. Terraform Advantages


1 Does orchestration, not just configuration management

Supports multiple providers such as AWS, Azure, GCP, DigitalOcean, and


2
many more

3 Provide immutable infrastructure where configuration changes smoothly

Uses an easy-to-understand language, HCL (HashiCorp configuration


4
language)

18
3, WHAT IS TERRAFORM?

3.1. Terraform Advantages

Terraform's state allows you to track resource


5
changes throughout your deployments.

6 Easily portable to any other provider

Supports client-only architecture, so no need for


7
additional configuration management on a server

19
4. The problem?
Day 1 Challenge Day 2+ Challenge

Our day 1 challenge - where we haven’t On day 2, we have an existing set of infrastructure which
actually started running anything yet. So, we’re trying to evolve. We’re changing it over time, we’re
how do we go from running nothing to adding new services, we’re removing services, and generally
running something?
evolvingthe way our infrastructure works

Day 1 Day 2+ /N
VM

VPC LB
TF Config. SG
20
4. THE PROBLEM?

4.1. How does Terraform really solve this problem?

Refresh
TF View ↔ Real World

Plan Real

World ↔ Desired Config

Apply
Plan ↔ Real World

21
4.1. HOW DOES TERRAFORM REALLY SOLVE THIS PROBLEM?

4.1.1. Terraform Provisioning

MONITOR CDN
Day 1 Day 2+ /N
VM

DNS
VPC LB
TF Config. SG

22
4.1. HOW DOES TERRAFORM REALLY SOLVE THIS PROBLEM?

4.1.2. Advantages of this workflow

Our day one experience is identical to our day two.


1
This is important because day two is sort of forever.
This is something we’re gonna keep doing. Refresh
TF View ↔ Real World

The other advantage of this is day N when we decide


Plan Real

World ↔ Desired Config

2 we might need to decommission this. We don’t need


Apply
Plan ↔ Real World

this service anymore, we don’t want this


infrastructure, maybe this was just a staging Destroy
Plan ↔ Real World

environment or test environment. We then have the


option to come in and destroy. And when we do a
destroy, it’s basically an unwinding everything that’s
been done...

23
4. THE PROBLEM?

4.2. How Terraform Works?


TF Config.
Providers

AWS / Azure / GCP


IaaS
OpenStack / VMware

Heroku / K8s / Lambda PaaS


CORE
State Datadog / Fastly / GitHub SaaS

K8s
IaaS Service DNS CDN

24
4. THE PROBLEM?

4.3. Terraform Enterprise Application Goals


Making sure the state management is done locally
1

Making sure we’re only doing one run at a time, so we ensure there’s the
2 sequential application

Sensitive credentials to not be stored on all of our developers' machines.


3
Instead, we want those variables to be kept centrally and encrypted

25
5. Major Components

1 Terraform Core 2 Providers

CORE

26
6. Core Concepts
Provider A plugin to interact with APIs of service and access its related
resources.

A folder with Terraform templates where all the configurations


Module
are defined

It consists of cached information about the infrastructure


State
managed by Terraform and the related configurations.

It refers to a block of one or more infrastructure objects


Resources (compute instances, virtual networks, etc.), which are used in
configuring and managing the infrastructure.

27
6. Core Concepts
Implemented by providers to return information on external objects to
Data Source
Terraform.

Also used as input variables, it is key-value pair used by Terraform


Variables
modules to allow customization.

Return values of a Terraform module that can be used by other


Output Values configurations.

One of the stages that determines what needs to be created, updated, or


Plan destroyed to move from the real/current state of the infrastructure to the
desired state.

One of the stages where it applies the changes real/current state of the
Apply infrastructure in order to move to the desired state.

28
7. Providers
Terraform relies on plugins called Every resource type is implemented by
"providers" to interact with cloud a provider; without providers,
providers, SaaS providers, and other Terraform can't manage any kind of
APIs. infrastructure.
Terraform configurations must declare Terraform configurations must declare
which providers they require so that which providers they require so that
Terraform can install and use them. Terraform can install and use them.
Each provider adds a set of resource Each provider adds a set of resource
types and/or data sources that types and/or data sources that
Terraform can manage. Terraform can manage.

29
8. Modules
Modules are containers for multiple In addition to modules from the local
resources that are used together. A filesystem, Terraform can load
module consists of a collection of .tf modules from the local filesystem or a
and/or .tf.json files kept together in a public or private registry
directory. The Terraform Registry hosts a broad
Modules are the main way to package collection of publicly available free-to-
and reuse resource configurations use Terraform modules
with Terraform. Terraform Cloud and Terraform
Every Terraform configuration has at Enterprise both include a private
least one module, known as its root module registry for sharing modules
module internally within your organization.

30
9. State
Terraform must store state about your Prior to any operation, Terraform does a
managed infrastructure and configuration. refresh to update the state with the real
This state is used by Terraform to map real- infrastructure.
world resources to your configuration, While the format of the state files are just
keep track of metadata, and improve JSON, direct file editing of the state is
performance for large infrastructures. discouraged.
This state is stored by default in a local file The primary purpose of Terraform state is
named "Terraform.tfstate", but it can also to store bindings between objects in a
be stored remotely, which works better in a remote system and resource instances
team environment. declared in your configuration.
Terraform uses this local state to create
plans and make changes to your
infrastructure.

31
10. Resources
Resource Blocks documents the syntax for declaring resources.

Resource Behavior explains in more detail how Terraform handles resource

declarations when applying a configuration.

The Meta-Arguments section documents special arguments that can be used with

every resource type, including depends_on, count, for_each, provider, and lifecycle.

Provisioners documents configuring post-creation actions for a resource using the

provisioner and connection blocks. Since provisioners are non-declarative and

potentially unpredictable, we strongly recommend that you treat them as a last

resort.

32
11. Data Sources
Data sources allow Terraform to use information defined outside of Terraform, defined
by another separate Terraform configuration, or modified by functions.

33
12. Variables and Outputs

Input variables are like function


arguments.

Output values are like function


return values.

Local values are like a function's


temporary local variables.
34
12. VARIABLES AND OUTPUTS

12.1. Input Variables


Input variables serve as parameters for a Terraform module, allowing aspects
of the module to be customized without altering the module's that source
code, and allowing modules to be shared between different configurations.

Input variables are like function arguments.

Output values are like function return values.

Local values are like a function's temporary local variables.

35
12.1. INPUT VARIABLES

12.1.1. Declaring an Input Variable


Each input variable accepted by a module must be declared using a variable
block:

36
12. VARIABLES AND OUTPUTS

12.2. Arguments

Terraform CLI defines the following optional arguments for variable


declarations:

default A default value which then makes the variable optional

type This argument specifies what value types are accepted for the variable

description This specifies the input variable's documentation

validation A block to define validation rules, usually in addition to type constraints

sensitive Limits Terraform UI output when the variable is used in configuration

37
12. VARIABLES AND OUTPUTS

12.1. Type Constraints

Type constraints are created from The type constructors allow you
a mixture of type keywords and to specify complex types such as
type constructors. The supported collections:
type keywords are:
list(<TYPE>)
string set(<TYPE>)
number map(<TYPE>)
bool object({<ATTR NAME> =
<TYPE>, ... })
tuple([<TYPE>, ...])

38
12. VARIABLES AND OUTPUTS

12.4. Input Variable Documentation

Because the input variables of a module are part of its user interface, you can briefly
describe the purpose of each variable using the optional description argument:

39
12. VARIABLES AND OUTPUTS

12.5. Using Input Variable Values

Within the module that declared a variable, its value can be accessed from within
expressions as var.<NAME>, where <NAME> matches the label given in the declaration
block:

Note: Input variables are created by a variable block, but you reference them as
attributes on an object named var.

40
12. VARIABLES AND OUTPUTS

12.6. Variable Definition Precedence

The above mechanisms for setting variables can be used together in any combination. If
the same variable is assigned multiple values, Terraform uses the last value it finds,
overriding any previous values. Note that the same variable cannot be assigned multiple
values within a single source.

Terraform loads variables in the following order, with later sources taking precedence
over earlier ones:
Environment variables Any *.auto.tfvars or *.auto.tfvars.json files,
processed in lexical order of their filenames.
The Terraform.tfvars file, if present.
The Terraform.tfvars.json file, if present. Any -var and -var-file options on the
command line, in the order they are
provided. (This includes variables set by a
Terraform Cloud workspace.)

41
13. Terraform Lifecycle

Init Plan Apply Destroy


terraform init terraform plan terraform apply terraform destroy

42
14. Terraform Enterprise

43
14. TERRAFORM ENTERPRISE

14.1. Collaboration Capabilities

FEATURE BENEFITS

Teams work in-parallel, leverage other workspaces, errors


WORKSPACES contained to workspace.

TEAM MANAGEMENT Multi-tenancy for separate BU. Govern separate teams with correct
permissions.

PRIVATE MODULE Pre-built sets of resources with best practices built-in; self-service
REGISTRY model of infrastructure.

CONFIGURATION Developers build configuration from pre-defined IaC modules;


provision on-demand.
DESIGNER
Allows developers to use preferred workflows while still having the
REMOTE OPERATIONS benefits of TFE.
SOURCE: HASHICORP

44
14. TERRAFORM ENTERPRISE

14.2. Governance and Policy Capabilities

FEATURE FUNCTIONALITY BENEFITS

Create policies as code and Eliminate provisioned resources that don't follow security,
SENTINEL enforce them on every compliance, or operational policies.
provisioning run.

SAML for SSO provides the ability Determine read and write controls for all users; easily automate
SAML
to govern user access to your and manage user control in TFE GUI.
applications.

Associate changes with correlated workspaces to know who is


AUDIT Track historical changes across all doing what to the infrastructure. Reduce cloud costs ($10B is
providers. overpaid annually) by understanding what can be de-provisioned.

SOURCE: HASHICORP

45
15. Terraform Best Practices
1. 2.
1. Don’t commit the .tfstate file

2. Configure a backend

3. Back up your state files


3.

4. Keep your backends small

5. Use one state per


4.
environment 5.

SOURCE: OPEN UP THE CLOUD

46
15. Terraform Best Practices
6. 7.
6. Setup backend state locking
Execute Terraform in an automated
7. build
Manipulate state only through the
8, 8.
commands
9. Use variables (liberally) 10.

10. Use modules (only where necessary)

9.

SOURCE: OPEN UP THE CLOUD

47
Now let’s do some practical stuff! 👨‍💻

48
Installing Terraform

https://learn.hashicorp.com/tutoria
ls/terraform/install-cli

50
Verifying Terraform Installation

Verify that the installation worked by opening a new terminal session


and listing Terraform's available subcommands.

Add any subcommand to Terraform -help to learn more about what it


does and available options.

51
Hands-on Labs

52
Thank you
for being a stellar
crowd!

Get in touch with me at:


[email protected]

You might also like