#: "" => "<computed>"
self_link: "" => "<computed>"
tags_fingerprint: "" => "<computed>"
zone: "" => "us-central1-a"
google_compute_instance.terraform: Still creating … (10s elapsed)
google_compute_instance.terraform: Still creating … (20s elapsed)
google_compute_instance.terraform: Still creating … (30s elapsed)
google_compute_instance.terraform: Still creating … (40s elapsed)
google_compute_instance.terraform: Creation complete after 40s (ID: terraform)
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
That's it, we have created a server instance. Now let's remove it:
~ / terraform (agil7e-aleph-20391) $ ./terraform apply
google_compute_instance.terraform: Refreshing state … (ID: terraform)
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
– destroy
Terraform will perform the following actions:
– google_compute_instance.terraform
Plan: 0 to add, 0 to change, 1 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
google_compute_instance.terraform: Destroying … (ID: terraform)
google_compute_instance.terraform: Still destroying … (ID: terraform, 10s elapsed)
google_compute_instance.terraform: Still destroying … (ID: terraform, 20s elapsed)
google_compute_instance.terraform: Still destroying … (ID: terraform, 30s elapsed)
google_compute_instance.terraform: Still destroying … (ID: terraform, 40s elapsed)
google_compute_instance.terraform: Still destroying … (ID: terraform, 50s elapsed)
google_compute_instance.terraform: Still destroying … (ID: terraform, 1m0s elapsed)
google_compute_instance.terraform: Still destroying … (ID: terraform, 1m10s elapsed)
google_compute_instance.terraform: Still destroying … (ID: terraform, 1m20s elapsed)
google_compute_instance.terraform: Still destroying … (ID: terraform, 1m30s elapsed)
google_compute_instance.terraform: Still destroying … (ID: terraform, 1m40s elapsed)
google_compute_instance.terraform: Still destroying … (ID: terraform, 1m50s elapsed)
google_compute_instance.terraform: Still destroying … (ID: terraform, 2m0s elapsed)
google_compute_instance.terraform: Still destroying … (ID: terraform, 2m10s elapsed)
google_compute_instance.terraform: Still destroying … (ID: terraform, 2m20s elapsed)
google_compute_instance.terraform: Destruction complete after 2m30s
Apply complete! Resources: 0 added, 0 changed, 1 destroyed.
Building infrastructure in AWS
To create an AWS cluster configuration, create a separate folder for it, and the previous one in a parallel one:
esschtolts @ cloudshell: ~ / terraform (agil7e-aleph-20391) $ mkdir gcp
esschtolts @ cloudshell: ~ / terraform (agil7e-aleph-20391) $ mv main.tf gcp / main.tf
esschtolts @ cloudshell: ~ / terraform (agil7e-aleph-20391) $ mkdir aws
esschtolts @ cloudshell: ~ / terraform (agil7e-aleph-20391) $ cd aws
Role is an analogue of a user, only not for people, but for services such as AWS, and in our case, these are EKS servers. But I do not see users as an analogue of roles, but groups, for example, a group for creating a cluster, a group for working with a database, etc. Only one role can be assigned to a server, and a role can contain multiple rights (Polices). As a result, we do not need to work with logins and passwords, or with tokens, or with certificates: store, transfer, restrict access, transfer – we only indicate in the WEB toolbar (IMA) or using the API (and derivatively in the configuration) the rights … Our cluster needs these rights in order for it to self-configure and replicate as it consists of standard AWS services. To manage the components of the AWS EC2 cluster (server), AWS ELB (Elastic Load Balancer, balancer) and AWS KMS (Key Management Service, key manager and encryption), you need AmazonEKSClusterPolicy access, to monitor AmazonEKSServicePolicy using CloudWatch Logs components (monitoring by logs) , Route 53 (creating a network in the zone), IAM (rights management). I did not describe the role in the config and created it through IAM according to the documentation: https://docs.aws.amazon.com/eks/latest/userguide/service_IAM_role. html # create-service-role.
For greater reliability, the nodes of the Kubernetes cluster should be located in different zones, that is, data centers. Each region contains several zones to maintain fault tolerance, while maintaining minimal letency (server response time) for the local population. It is important to note that some regions may be represented in several copies within the same country, for example, US-east-1 in US East (N. Virginia) and US-east-2 in US East (Ohio) – regions are designated in numbers. So far, the creation of an EKS cluster is available only to the US-east zone.
The VPC for the developer, at its simplest, boils down to naming a subnet as a specific resource.
Let's write the configuration according to the documentation www.terraform.io/docs/providers/aws/r/eks_cluster. html :
esschtolts @ cloudshell: ~ / terraform / aws (agile-aleph-203917) $ cat main.tf
provider "aws" {
access_key = "$ {var.token}"
secret_key = "$ {var.key}"
region = "us-east-1"
}
# Params
variable "token" {
default = ""
}
variable "key" {
default = ""
}
# EKS
resource "aws_eks_cluster" "example" {
enabled_cluster_log_types = ["api", "audit"]
name = "exapmle"
role_arn
