Дипломный практикум в Yandex.Cloud

• Цели:
• Этапы выполнения:
  • Создание облачной инфраструктуры
  • Создание Kubernetes кластера
  • Создание тестового приложения
  • Подготовка cистемы мониторинга и деплой приложения
  • Установка и настройка CI/CD
• Что необходимо для сдачи задания?
• Как правильно задавать вопросы дипломному руководителю?

Цели:

1. Подготовить облачную инфраструктуру на базе облачного провайдера Яндекс.Облако.
2. Запустить и сконфигурировать Kubernetes кластер.
3. Установить и настроить систему мониторинга.
4. Настроить и автоматизировать сборку тестового приложения с использованием Docker-контейнеров.
5. Настроить CI для автоматической сборки и тестирования.
6. Настроить CD для автоматического развёртывания приложения.

Этапы:

• Создание облачной инфраструктуры
• Создание Kubernetes кластера
• Создание тестового приложения
• Подготовка cистемы мониторинга и деплой приложения
• Установка и настройка CI/CD
• Ссылки на все ресурсы
• Заключение
• Скриншоты

Создание облачной инфраструктуры

• Характеристики инфраструктуры легко можно изменить для экономии бюджета гранта на Yandex Cloud. Это наглядно видно в модулях терраформ.

  Но для демонстрации я оставлю хосты непрерываемые, чтобы проверяющий мог проверить их в любое время. При этом, если строго следовать требованиям задания, то значения переменных для моего модуля по созданию групп ВМ выглядели бы так:

  cores         = 2
  memory        = 2
  core_fraction = 5
  preemptible   = true

• Версия Terraform

  Terraform v1.8.3
  on linux_amd64

  Также в модулях я выставил ограничение по версиям Terraform. Может слишком жестко, что только от 1.8.3, но "я художник - я так вижу".

  required_version = ">=1.8.3"

Предварительная подготовка к установке и запуску Kubernetes кластера.

1. Подготовительные работы я вынес за рамки выполнения дипломного проекта, так как считаю, что SA для работы Terraform и S3-bucket должны быть реализованы без привязки к проекту. Но так как и они выполняются через мои модули Terraform, то можно было бы выполнить их вместе с проектом в одном манифесте.

   • Модуль подготовки SA и S3-bucket

2. Создание VPC я бы таким же образом вынес в отдельный этап, и обращался с к данным VPC через terraform_remote_state, но сделал по заданию, так как этот момент считаю некритичным.

   • Модуль VPC

3. Все остальные ресурсы так же создаются с помощью модулей, которые расположены в моем репозитории

4. Конфигурация манифестов Terraform для выполнения дипломного проекта:

   • Репозиторий
   • Пример выполнения terraform apply

5. Скриншоты этапа:

   • Дашборд каталога
   • Сервисные аккаунты
   • DNS записи
   • Copmute cloud/ВМ
   • Copmute cloud/Группы ВМ
   • Terraform apply complete

• Дополнительно реализован HTTPS доступ ко всем WEB сервисам в данном задании. Модуль
• Хосты кластера реализованы через instance_group. Проводил тесты с количеством: 3 мастера - 6 воркеров. Проблем нет. Количество хостов можно легко менять. Динамический инвентори отрабатывает без ошибок
• Ориентировочное время выполнения манифестов - 17-20 минут

Создание Kubernetes кластера

1. Кластер подготавливается и настраивается с помощью моей Ansible роли. В проде я бы использовал Kubespray, но было интересно создать свою роль. Очевидно, что моя роль и близко не стоит с Kubespray, но сколько людей занимаются его разработкой и какое количество времени?

   • Репозиторий с Ansible ролью ansible-kubeadm

2. Конфигурация кластера запускается на первом этапе с помощью Terraform:

   • Модуль запуска Ansible

Данный модуль также формирует инвентори файл для работы Ansible. Все операции производятся через созданый на первом этапе бастион. Все хосты кластрера находятся в приватных подсетях.

• Доступ kubectl производится через Load Balancer на группу мастеров
• Доступ приложений кластера поизводится через Application Load Balancer на группу воркеров (на ingress controller)

Файл ~/.kube/config создается так же из роли, для чего я предусмотрел переменные.

# Setting up a local configuration file
kubeadm_local:
  config_path: "~/.kube/config"
  user: "{{ lookup('env', 'USER') }}" # variable with the name of the user running ansible?
  make_config: true                   # Danger! Rewrite your config file if kubeadm_local.config_path: "~/.kube/config"

5. Скриншоты этапа:
   • Команда kubectl get pods --all-namespaces
   • Команда kubectl get nodes -o wide
   • Пример созданного файла конфигурации

Создание тестового приложения

1. Создан отдельный Git репозиторий.

   • Репозиторий Nginx-Feniks

2. Регистр образа разместил на своем Gitlab.

   • Пример запуска приложения:

   docker run -d --name feniks-web -p 80:80 registry.infernofeniks.ru/feniks/nginx-feniks:lastest

Подготовка cистемы мониторинга и деплой приложения

Данное задание выполнено на втором этапе.

Функция установки мониторинга кластера включены в Ansible роль.

Дополнительно реализована замена стандартного пароля (admin:admin) в Grafana Web GUI. Так же указано в переменных Ansible роли.

• Репозиторий с Ansible ролью ansible-kubeadm

HTTPS доступ к web интерфейсу grafana:

• GRAFANA.INFERNOFENIKS.TECH

super

netology

kubeadm_grafana_fqdn: grafana.infernofeniks.tech
kubeadm_grafana_user: super
kubeadm_grafana_password: netology

HTTPS доступ к тестовому приложению (Деплой через Gitlab):

• MYAPP.INFERNOFENIKS.TECH

HTTPS доступ к тестовому приложению (деплой через ArgoCD):

• MYAPP.INFERNOFENIKS.TECH/ARGOCD
  
  

Скриншоты этапа:

• Grafana cluster
• Grafana kubelet
• Grafana networking
• Alertmanager
• Prometheus

Установка и настройка CI/CD

Для выполнения доставки приложения в кластер Kubernetes реализовано два сбособа:

1. Реализация через ArgoCD. Работа выполняется по следующему алгоритму:

   • При создание тега в репозитории с приложением выполняется пайплайн:
     • проверка синтаксиса
     • тест
     • сборка
     • автоматический деплой в репозиторий конфигураций приложений для ArgoCD

2. Реализация через ручное задание в пайплайне:

   • В дополнение к первому способу появляется возможность ручного запуска задачи для деплоя приложения в кластер Kubernetes

     Но необходимо внести данные в Gitlab CI/CD Variables - $KUBE_CONFIG

     Значение переменной KUBE_CONFIG - это cat ~/.kube/config | base64

• Интерфейс ci/cd сервиса Gitlab

• репозиторий конфигураций приложений для ArgoCD

• HTTPS доступ к тестовому приложению (Деплой через Gitlab)

• HTTPS доступ к тестовому приложению (деплой через ArgoCD)

Скриншоты этапа:

• Gitlab pipelines
• Gitlab registry
• ArgoCD dashboard
• ArgoCD dashboard_app
• ArgoCD dashboard_demo

Веб доступы к ресурсам

Заключение

Все операции выполняются полностью автоматически после запуска Terrafom.

Единственно исключение - ручной запуск CI/CD в пайплайне Gitlab, так как нужно вручную внести в переменную значение конфигурационного файла кластера. Данный момент полностью перекрывается с помощью ARGOCD (описано выше).

Пароль от ARGOCD копируется на локальную машину с которой производится запуск манифестов в файл: cat /tmp/kubernetes_argocd_pass

Все скриншоты

1. Создание облачной инфраструктуры

   • 
   • 
   • 
   • 
   • 
   • 

2. Создание Kubernetes кластера

   • 
   • 
   • 

3. Создание тестового приложения

   • Описание в репозитории

4. Подготовка cистемы мониторинга и деплой приложения

   • 
   • 
   • 
   • 
   • 

5. Установка и настройка CI/CD

   • 
   • 
   • 
   • 
   • 
   • 

Что необходимо для сдачи задания?

1. Репозиторий с конфигурационными файлами Terraform и готовность продемонстрировать создание всех ресурсов с нуля.
2. Пример pull request с комментариями созданными atlantis'ом или снимки экрана из Terraform Cloud или вашего CI-CD-terraform pipeline.
3. Репозиторий с конфигурацией ansible, если был выбран способ создания Kubernetes кластера при помощи ansible.
4. Репозиторий с Dockerfile тестового приложения и ссылка на собранный docker image.
5. Репозиторий с конфигурацией Kubernetes кластера.
6. Ссылка на тестовое приложение и веб интерфейс Grafana с данными доступа.
7. Все репозитории рекомендуется хранить на одном ресурсе (github, gitlab)