Eugeny Shtoltc - IT Cloud

Тут можно читать онлайн Eugeny Shtoltc - IT Cloud - бесплатно ознакомительный отрывок. Жанр: foreign-comp, год 2021. Здесь Вы можете читать ознакомительный отрывок из книги онлайн без регистрации и SMS на сайте лучшей интернет библиотеки ЛибКинг или прочесть краткое содержание (суть), предисловие и аннотацию. Так же сможете купить и скачать торрент в электронном формате fb2, найти и слушать аудиокнигу на русском языке или узнать сколько частей в серии и всего страниц в публикации. Читателям доступно смотреть обложку, картинки, описание и отзывы (комментарии) о произведении.
  • Название:
    IT Cloud
  • Автор:
  • Жанр:
  • Издательство:
    неизвестно
  • Год:
    2021
  • ISBN:
    нет данных
  • Рейтинг:
    5/5. Голосов: 11
  • Избранное:
    Добавить в избранное
  • Отзывы:
  • Ваша оценка:
    • 100
    • 1
    • 2
    • 3
    • 4
    • 5

Eugeny Shtoltc - IT Cloud краткое содержание

IT Cloud - описание и краткое содержание, автор Eugeny Shtoltc, читайте бесплатно онлайн на сайте электронной библиотеки LibKing.Ru
In this book, the Chief Architect of the Cloud Native Competence Architecture Department at Sberbank shares his knowledge and experience with the reader on the creation and transition to the cloud ecosystem, as well as the creation and adaptation of applications for it. In the book, the author tries to lead the reader along the path, bypassing mistakes and difficulties. To do this, practical applications are demonstrated and explained so that the reader can use them as instructions for educational and work purposes. The reader can be both developers of different levels and ecosystem specialists who wish not to lose the relevance of their skills in an already changed world.

IT Cloud - читать онлайн бесплатно ознакомительный отрывок

IT Cloud - читать книгу онлайн бесплатно (ознакомительный отрывок), автор Eugeny Shtoltc
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

project = "node-cluster-243923"

region = "europe-north1"

}

resource "google_container_cluster" "node-ks" {

name = "node-ks"

location = "europe-north1-a"

node_locations = ["europe-north1-b", "europe-north1-c"]

initial_node_count = 1

}

resource "google_container_node_pool" "node-ks-pool" {

name = "node-ks-pool"

cluster = "$ {google_container_cluster.node-ks.name}"

location = "europe-north1-a"

node_count = "1"

node_config {

machine_type = "n1-standard-1"

}

autoscaling {

min_node_count = 1

max_node_count = 2

}

}

Let's see what happened and look for the IP address of the cluster entry point:

essh @ kubernetes-master: ~ / node-cluster / Kubernetes $ gcloud container clusters list

NAME LOCATION MASTER_VERSION MASTER_IP MACHINE_TYPE NODE_VERSION NUM_NODES STATUS

node-ks europe-north1-a 1.12.8-gke.6 35.228.20.35 n1-standard-1 1.12.8-gke.6 6 RECONCILING

essh @ kubernetes-master: ~ / node-cluster / Kubernetes $ gcloud container clusters describe node-ks | grep '^ endpoint'

endpoint: 35.228.20.35

essh @ kubernetes-master: ~ / node-cluster / Kubernetes $ ping 35.228.20.35 -c 2

PING 35.228.20.35 (35.228.20.35) 56 (84) bytes of data.

64 bytes from 35.228.20.35: icmp_seq = 1 ttl = 59 time = 8.33 ms

64 bytes from 35.228.20.35: icmp_seq = 2 ttl = 59 time = 7.09 ms

–– 35.228.20.35 ping statistics –

2 packets transmitted, 2 received, 0% packet loss, time 1001ms

rtt min / avg / max / mdev = 7.094 / 7.714 / 8.334 / 0.620 ms

By adding variables, which I selected in a separate file just for clarity, which parameterize our config for different uses, we can use it, for example, to create test and production clusters. Variables can be added as var.name_value , and inserted into the text similarly to JS: $ {var.name_value} , as well as path.root .

essh @ kubernetes-master: ~ / node-cluster / Kubernetes $ cat variables.tf

variable "region" {

default = "europe-north1"

}

variable "project_name" {

type = string

default = ""

}

variable "gce_key" {

default = "./kubernetes_key.json"

}

variable "node_count_zone" {

default = 1

}

They can be passed through the -var switch , for example: sudo ./terraform apply -var = "project_name = node-cluster-243923" .

essh @ kubernetes-master: ~ / node-cluster / Kubernetes $ cp ../kubernetes_key.json.

essh @ kubernetes-master: ~ / node-cluster / Kubernetes $ sudo ../terraform apply -var = "project_name = node-cluster-243923"

Our project in the folder is not only a project, but also a module ready to use:

essh @ kubernetes-master: ~ / node-cluster / Kubernetes $ cd ..

essh @ kubernetes-master: ~ / node-cluster $ cat main.tf

module "Kubernetes" {

source = "./Kubernetes"

project_name = "node-cluster-243923"

}

essh @ kubernetes-master: ~ / node-cluster $ sudo ./terraform apply

Or upload to the public repository:

essh @ kubernetes-master: ~ / node-cluster / Kubernetes $ git init

Initialized empty GIT repository in /home/essh/node-cluster/Kubernetes/.git/

essh @ kubernetes-master: ~ / node-cluster / Kubernetes $ echo "terraform.tfstate" >> .gitignore

essh @ kubernetes-master: ~ / node-cluster / Kubernetes $ echo "terraform.tfstate.backup" >> .gitignore

essh @ kubernetes-master: ~ / node-cluster / Kubernetes $ echo ".terraform /" >> .gitignore

essh @ kubernetes-master: ~ / node-cluster / Kubernetes $ rm -f kubernetes_key.json

essh @ kubernetes-master: ~ / node-cluster / Kubernetes $ git remote add origin https://github.com/ESSch/terraform-google-kubernetes.git

essh @ kubernetes-master: ~ / node-cluster / Kubernetes $ git add.

essh @ kubernetes-master: ~ / node-cluster / Kubernetes $ git commit -m 'create a k8s Terraform module'

[master (root-commit) 4f73c64] create a Kubernetes Terraform module

3 files changed, 48 insertions (+)

create mode 100644 .gitignore

create mode 100644 main.tf

create mode 100644 variables.tf

essh @ kubernetes-master: ~ / node-cluster / Kubernetes $ git push -u origin master

essh @ kubernetes-master: ~ / node-cluster / Kubernetes $ git tag -a v0.0.2 -m 'publish'

essh @ kubernetes-master: ~ / node-cluster / Kubernetes $ git push origin v0.0.2

After publishing in the module registry https://registry.terraform.io/, having met the requirements such as having a description, we can use it:

essh @ kubernetes-master: ~ / node-cluster $ cat main.tf

module "kubernetes" {

# source = "./Kubernetes"

source = "ESSch / kubernetes / google"

version = "0.0.2"

project_name = "node-cluster-243923"

}

essh @ kubernetes-master: ~ / node-cluster $ sudo ./terraform init

essh @ kubernetes-master: ~ / node-cluster $ sudo ./terraform apply

On the next creation of the cluster, I got the error ZONE_RESOURCE_POOL_EXHAUSTED "does not have enough resources available to fulfill the request. Try a different zone, or try again later" , indicating that there are no required servers in this region. For me this is not a problem and I do not need to edit the module's code, because I parameterized the module with the region, and if I just pass the region region = "europe-west2" to the module as a parameter , terraform after the update and initialization command ./terrafrom init and the application command ./terraform apply will transfer my cluster to the specified region. Let's improve our module a little by moving the provider from the Kubernetes child module to the main module (the main script is also a module). Having brought it to the main module, we will be able to use one more module, otherwise the provider in one module will conflict with the provider in another. Inheritance from main module to child modules and their transparency applies only to providers. The rest of the data for transferring from child to parent will have to use external variables, and from parent to child – to parameterize the parent, but this is later, when we will create another model. Also, moving the provider to the parent module will be useful when creating the next module that we will create, since it will create Kubernetes elements that do not depend on the provider, and thus we can untie the Google provider from our module and can be used with other providers supporting Kubernetes. Now we don't need to pass the project name in the variable – it is set in the provider. For the convenience of development, I will use the local connection of the module for now. I created a folder and file for a new module:

essh @ kubernetes-master: ~ / node-cluster $ ls nodejs /

main.tf

essh @ kubernetes-master: ~ / node-cluster $ cat main.tf

// module "kubernetes" {

// source = "ESSch / kubernetes / google"

// version = "0.0.2"

//

// project_name = "node-cluster-243923"

// region = "europe-west2"

//}

provider "google" {

credentials = "$ {file (" ./ kubernetes_key.json ")}"

project = "node-cluster-243923"

region = "europe-west2"

}

module "Kubernetes" {

source = "./Kubernetes"

project_name = "node-cluster-243923"

region = "europe-west2"

}

module "nodejs" {

source = "./nodejs"

}

essh @ kubernetes-master: ~ / node-cluster $ sudo ./terraform init

essh @ kubernetes-master: ~ / node-cluster $ sudo ./terraform apply

Now let's transfer data from the Kubernetes infrastructure module to the application module:

essh @ kubernetes-master: ~ / node-cluster $ cat Kubernetes / outputs.tf

output "endpoint" {

value = google_container_cluster.node-ks.endpoint

sensitive = true

}

output "name" {

value = google_container_cluster.node-ks.name

sensitive = true

}

output "cluster_ca_certificate" {

value = base64decode (google_container_cluster.node-ks.master_auth.0.cluster_ca_certificate)

}

essh @ kubernetes-master: ~ / node-cluster $ cat main.tf

// module "kubernetes" {

// source = "ESSch / kubernetes / google"

// version = "0.0.2"

//

// project_name = "node-cluster-243923"

// region = "europe-west2"

//}

provider "google" {

credentials = file ("./ kubernetes_key.json")

project = "node-cluster-243923"

region = "europe-west2"

}

module "Kubernetes" {

source = "./Kubernetes"

project_name = "node-cluster-243923"

region = "europe-west2"

}

module "nodejs" {

source = "./nodejs"

endpoint = module.Kubernetes.endpoint

cluster_ca_certificate = module.Kubernetes.cluster_ca_certificate

}

essh @ kubernetes-master: ~ / node-cluster $ cat nodejs / variable.tf

variable "endpoint" {}

variable "cluster_ca_certificate" {}

To check the balancing of traffic from all nodes, start NGINX, replacing the standard page with the hostname. We'll replace it with a simple command call and resume the server. To start the server, let's look at its call in the Dockerfile: CMD ["Nginx", "-g", "daemon off;"] , which is equivalent to calling Nginx -g 'daemon off;' at the command line. As you can see, the Dockerfile does not use BASH as an environment for launching, but starts the server itself, which allows the shell to live in the event of a process crash, preventing the container from crashing and re-creating. But for our experiments, BASH is fine:

essh @ kubernetes-master: ~ / node-cluster $ sudo docker run -it Nginx: 1.17.0 which Nginx

/ usr / sbin / Nginx

sudo docker run -it –rm -p 8333: 80 Nginx: 1.17.0 / bin / bash -c "echo \ $ HOSTNAME> /usr/share/Nginx/html/index2.html && / usr / sbin / Nginx – g 'daemon off;' "

Now let's create our PODs in triplicate with NGINX, which Kubernetes will try to distribute to different servers by default. Let's also add the service as a balancer:

essh @ kubernetes-master: ~ / node-cluster $ cat nodejs / main.tf

terraform {

required_version = "> = 0.12.0"

}

data "google_client_config" "default" {}

provider "kubernetes" {

host = var.endpoint

token = data.google_client_config.default.access_token

cluster_ca_certificate = var.cluster_ca_certificate

load_config_file = false

}

essh @ kubernetes-master: ~ / node-cluster $ cat nodejs / main.tf

resource "kubernetes_deployment" "nodejs" {

metadata {

name = "terraform-nodejs"

labels = {

app = "NodeJS"

}

}

spec {

replicas = 3

selector {

match_labels = {

app = "NodeJS"

}

}

template {

metadata {

labels = {

app = "NodeJS"

}

}

spec {

container {

image = "Nginx: 1.17.0"

name = "node-js"

command = ["/ bin / bash"]

args = ["-c", "echo $ HOSTNAME> /usr/share/Nginx/html/index.html && / usr / sbin / Nginx -g 'daemon off;'"]

}

}

}

}

}

resource "kubernetes_service" "nodejs" {

metadata {

name = "terraform-nodejs"

}

spec {

selector = {

app = kubernetes_deployment.nodejs.metadata.0.labels.app

}

port {

port = 80

target_port = var.target_port

}

type = "LoadBalancer"

}

Let's check the work using kubectl, for this we transfer the secrets from gcloud to kubectl.

essh @ kubernetes-master: ~ / node-cluster $ sudo ./terraform apply

essh @ kubernetes-master: ~ / node-cluster $ gcloud container clusters get-credentials node-ks –region = europe-west2-a

Fetching cluster endpoint and auth data.

kubeconfig entry generated for node-ks.

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать


Eugeny Shtoltc читать все книги автора по порядку

Eugeny Shtoltc - все книги автора в одном месте читать по порядку полные версии на сайте онлайн библиотеки LibKing.




IT Cloud отзывы


Отзывы читателей о книге IT Cloud, автор: Eugeny Shtoltc. Читайте комментарии и мнения людей о произведении.


Понравилась книга? Поделитесь впечатлениями - оставьте Ваш отзыв или расскажите друзьям

Напишите свой комментарий
x