Please enable JavaScript.

Coggle requires JavaScript to display documents.

Learn TERRAFORM - Coggle Diagram

- - - - usually one VPC per region - communication across VPCs is not possible via private networks
        
        put instances in the same VPC if they need to communicate
    - - range of private IP addresses
        
        Typical ranges
      - not reachable from the internet
        
        mainly used to host backend services / databases
        
        a NAT gateway could be used for outgoing communication
    - - used for public front-services - e.g. a load balancer is usually in the public subnet
    - - usually ingress rules are really restrictive while all IPs are allowed on egress
  - - - instances also come with root EBS which gets deleted when terminated
      - extra EBS storage are available until you don't instruct AWS to remove it
      - is created as a resource and then added to an instance
  - - - scripts can be added directly as string or the templating system of terraform can be used
        
        aneven better option could be to use cloud-init
  - - - EIPs are public IPs assignable to an EC2
        
        EIPs are billed if not assigned to an EC2
    - - when registering domains with other providers, add AWS name servers to that domain
        
        AWS has many name servers - check the tf output for aws_route53_zone.example-com.name_servers
  - - - create a subnet group
      - create a parameter group to change settings in the DB
      - create a security group for network traffic control
  - - - users can be attached to groups
      - users can authenticate (also with MFA)
      - Roles can give users and services temporary accesses that they usually wouldn't have
        
        e.g. you crate a role my-bucket-access and assign it to an EC2 instance at boot time. Then you give the role read & write permissions to the bucket. When you login you can now assume this role without using your own credentials but you'll be given temporary access credentials instead to read/write the bucket
      - there are many AWS-managed policies that can be attached to roles/groups or a custom policy can be created
  - - - an AWS launch configuration that specifies the properties of the instance to be launched (e.g. AMI id)
      - an autoscaling group specifying autoscaling properties (min instances, max instances, health checks etc)
      - additionally an autoscaling policy together with a cloudwatch alarm to trigger the adjustment- if not the only way to trigger autoscaling is manually
  - - - automatically redistribute traffic across multiple EC2 instances
      - ELB scales when receives more traffic and performs health checks on the EC2 instances and recognizes when a new instance is added if attached to an autoscaling group
      - can be used as an SSL terminator
      - can spread over multiple AZs
      - it's like nginx as a service
    - - routes traffic based on application-level information (e.g. route /api and /website to different instances - ELB cannot do that)
        
        allows to define target groups and then attach instances to those target groups. Rules can be registered in listeners that usually have default action that re matched when no other rule applies
      - with ALB you can specify multiple rules to send traffic to another target and each rule will have a priority assigned
  - - - Provision an ECR
        
        Get the ECR URL
    - - runs custom AMIs provided by amazon having docker and a custom ECS agent
      - first it's needed to define the cluster, then an autoscaling group is needed to launch EC2s to join the cluster The instance needs to have permission to access ecs and to pull the image from ECR
      - before the docker app can be launched, a task definition needs to be provided, which is describing what docker container is to be run on the cluster
        
        also additional info like max cpu, max memory, env. vars etc.
        
        a service definition is going to run a specific amount of containers based on the task definition
        
        a service is always running (will be restarted if stopped), can be scaled and an ELB can be put in front of it - ELB is used to provide high avail. since if an instance stops working, traffic will not be redirected to it
        
        to make changes later on to the task definition (e.g. via Jenkins) changes there will need to be ignored otherwise terraform will reverse the changes of updated task definitions
  - - - ECS is cheaper but is AWS-specific
      - K8S is popular but it's complicated - ECS to deploy simple apps
- - - - Accessing variables
      - can also be specified in a file called "terraform.tfvars"
        
        this file is usually used to put credentials & secrets and it's not meant to be committed
      - simple types: string, number, bool
      - complex types: list(type), set(type), map(type), object({<attr_name = <value>, ...}), tuple([<value>,...])
      - use variables to hide secrets and for elements that might change - makes things more generic
    - - always need to specify a provider (e.g. aws)
        
        once a provider is selected run terraform init to let terraform download the relevant plugin for the provider
      - define a resource
      - plan resource changes: terraform plan -out out.terraform
      - apply changes: terraform apply [out.terraform]
        
        using without a file is a shortcut for plan + apply w/ temporary file
      - destroy: terraform destroy
  - - - Chef is integrated within Terraform
      - File Upload: define a provisioner with a file to launch the configuration/installation
        
        after uploading the script it needs to be executed with remote-exec
        
        an ssh key would need to be defined in order to connect and execute the script (therefore the additional "aws_key_pair" resource)
        
        key is generated locally and uploaded (ssh-keygen)
  - - - these attributes can be accessed in the format ${<resource type>.<resource name>.<attribute>}
        
        can also be used in scripts (e.g. in the provisioner)
        
        in a tipycal flow, these could produce inputs for a congig SW like ansible
  - - - locally, tf uses the local backend
      - backends: s3 & dynamoDB, consul,terraform enterprise which all support locking
        
        needs to be launched with aws profile having needed permissions tok access s3/dynamo
      - PROs: all team sees the same remote state, local sensitive info are not stored, possibility to run remote operations
      - to use a remote backend you first configure the backend code and then run terraform init
  - - - this info can be used as input to tf
  - - - allows to build templates based on variables from tf resource attributes
        
        the template can be then be used to seed an instance (e.g. aws ec2 user-data)
        
        locals is just a way to scope variables and keep things cleaner
  - - - modules can be used from git (with terraform get) or from local
- - - - create multiple AWS accounts as well!
    - - write code in modules so you can reuse them in both dev and prod
  - - - upgrading between tf versions
      - renaming of resources without recreating them
      - changed a key in a for_each but don't want to recreate the resources
      - change position of resources in a list
      - stop tf managing resources but don't want to destroy resource
      - show attributes of a resource