Введение в DevOps

• DevOps. Уровень 1. Инфраструктура как код, основные инструменты
• ДП-ДЕВОПС-М

• Узнать свой номер стенда
• Проверить наличие дистрибутивов и образов (будет сделано)
• Использовать кэширующий прокси для ускорения загрузки

• Разворачиваем стенд курса Linux. Уровень 2. Администрирование сервисов и сетей

Запустите с правами Administrator

C:\cmder\cmder.exe

bash

cd

git clone http://val.bmstu.ru/unix/conf.git

cd conf/virtualbox/

!!! 8 - это номер курса, вместо X укажите Ваш номер стенда, если не знаете его, спросите преподавателя !!!

./setup.sh X 8

• !!! Добавить HDD 20GB к server
• Настройка виртуальных систем Unix с использованием Скрипты автоконфигурации

• gate

# sh net_gate.sh

# init 6

• server

# sh net_server.sh

# init 6

• Создать в Putty профили gate, server и подключиться

• Использование LVM
• Финальная настройка DNS сервера

server:~# sh conf/dns.sh

• Настройка клиента DNS на gate и server

# cat /etc/resolv.conf

search corpX.un
nameserver 192.168.X.10

# nslookup ns

• !!! Заранее выполняем на server
• Установка переменных окружения http_proxy, https_proxy и no_proxy
• Установку Сервис Ansible
• Установку Инструмент GitLab !!! запустить до первого перерыва

• !!! Заранее выполняем на host системе
• Технология Vagrant Установка

• Сервис Git
• Инструмент GitLab

• Сервис Git для каталога /etc на gate (демонстрирует преподаватель)
• Сервис DHCP

gate:~# sh conf/dhcp.sh

• Статистика DHCP сервера
• Использование утилиты make (установить)
• Определение наличия и правка профилей для служб !!! проверить, закачался ли GitLab !!!

gate# su - student

• Использование make для сопровождения файлов конфигурации сервиса
• Сервис Git для каталога ~student/dhcp/ на gate

!!! Если GitLab к этому времени не установился, начать тему Vagrant

• http://server.corpX.un/
• Используем Управление пользователями в GitLab для отключения авто регистрации, назначении пароля пользователю root и создания учетной записи student
• http://server.corpX.un:81/mail
• Подключаемся как student, New Blank Project (Project name: dhcp, без README)
• Обновление сетевого репозитория из локального
• Редактируем dhcpd.conf в GitLab IDE (Commit to master branch)

• Статистика DHCP сервера
• Клонирование и обновление локального репозитория из сетевого (можно тем же student на gate)
• Использование make для сопровождения файлов конфигурации сервиса

• Устанавливаем GitLab Runner (shell) на gate и регистрируем в GitLab
• Используем Пакет sudo для разрешений пользователя gitlab-runner
• GitLab CI/CD
• Экспериментируем или смотри вебинар :) Вход в CI/CD для Linux-админа

!!! в теме Ansible

• Создаем новый репозиторий (Project name: openvpn1, без README) в GitLab
• Пользуясь инструкцией к проекту, включаем Сервис Git для каталога openvpn1 (ubuntu20 ветка master) и помещаем его в GitLab (можно сразу добавить GitLab Runner и CI/CD для выкатки в прод)
• Используем Клонирование и обновление локального репозитория из сетевого проекта openvpn1 на локальную систему в Cmder (!!! появляется скрытое окно, в котором надо нажать Ок) и открываем проект в npp
• Используем Работа с ветками в Git для тестовой конфигурации в Роль OpenVPN сервера (можно добавить и протестировать настройки push…dhcp…dns)
• Устанавливаем и регистрируем GitLab Runner (shell) на server
• Используем GitLab CI/CD Пример shell ansible для сервиса OpenVPN с ручным тестированием конфигурации
• Используем Работа с ветками в Git для переноса изменений ветки test в master
• Дополнительное задание - добавить Тестирование конфигурации перед деплоем

1. Чем отличается GitLab от Git?
2. Что делают операции add, commit, push в Git?
3. Для чего нужен GitLab Runner?
4. Как называется файл для CI/CD в GitLab?
5. Что такое “ветка” в Git и почему переименовали master в main?

• Построение ландшафта инфраструктуры на примере Технология Vagrant
• Построение ландшафта облачной инфраструктуры с использованием HashiCorp Terraform
• Управление инфраструктурой на примере Сервис Ansible

• Добавляем DNS записи nodeN A 192.168.X.200+N в Настройка мастер сервера зоны corpX.un
• Обзор команд Технология VirtualBox
• Развертываем с использованием Технология Vagrant node1,2,3

• Сервис Ansible openvpn, docker (только слушатели), можно addusers.yml для OpenVPN
• Преподаватель импортирует систему Windows для тестирования OpenVPN
• Разворачиваем Пакет OpenVPN в конфигурации с Использование PAM аутентификации на node1,2,3 с Использование ролей
• Для подключения используем Сервис Keepalived в режиме Настройка балансировки нагрузки и client.ovpn (Настройка клиента) в windows
• Можно добавить Сервис NAT для зрелищности

• Лабораторная работа 2.4

• Преподаватель демонстрирует установку docker на node1,2,3 с Использование playbook Ansible в Vagrant

1. Что общего и в чем отличие между Ansible, Vagrant и Terraform?
2. Что означает термин Provision в Vagrant?
3. Что такое module, playbook, role в Ansible?
4. Назовите каталоги в роли Ansible
5. Что должно быть установлено на целевой системе для управления через Ansible?
6. Каким образом Vagrant управляет VM?
7. Как реализован Ansible provision в Vagrant?

• Технология Docker

• Преподаватель импортирует linux систему external-host для нагрузочного тестирования и демонстрирует “разработку” приложения на VM server
• Web сервер на shell (методически, для обсуждения кода, можно, для упрощения, удалить из него все за комментированные строки)
• Сервис INETD
• Через Настройка балансировки нагрузки в Keepalived предоставляем доступ снаружи
• Install Vegeta on Ubuntu 20.04
• ftp/tcp server failing (looping)

• duration=60s rate=400 выдерживают 10 экземпляров приложения
• в качестве external-host можно использовать gate

external-host# curl http://172.16.1.X

external-host# echo "GET http://172.16.1.X" | vegeta attack -duration=60s -rate=400 | vegeta report

server# tail -f /var/log/syslog

• Устанавливаем Технология Docker на server
• Используя su - gitlab-runner (пригодится для тестов CI/CD из командной строки, для удобства работы выполнить Настройка командных интерпретаторов), знакомимся с технологией и упаковываем приложение (без sftp) в Docker образ
• Запускаем несколько копий вручную, и, через Настройка балансировки нагрузки, повторяем нагрузочное тестирование
• Знакомимся с docker-compose для запуска нескольких копий приложения

Методически, достаточно показать на node1

• Создаем (без README) проект webd и размещаем каталог webd в On-Premise gitlab пользуясь инструкцией к проекту
• Включаем GitLab Docker Registry
• Cохраняем образ, используя Локальные репозитории
• Сервис NFS на server (преподаватель)
• Установка nfs клиента на node1,2,3 и монтирование /var/www
• Проверяем наличие, или устанавливаем Docker на node1,2,3
• Используя доступ к Локальные репозитории на node1,2,3 запускаем несколько экземпляров приложения и, через Настройка балансировки нагрузки, повторяем нагрузочное тестирование

• Автоматизируем сборку образа используя Проверка синтаксиса и GitLab CI/CD, проверяем “в ручном” режиме, а затем, в автоматическом, не забыв назначить переменные проекта, метки Gitlab Runner и сделав add, commit и push

• Модифицируем docker-compose для загрузки и запуска нескольких копий приложения и тестируем на server
• Используя Подключение через API скачиваем на node1,2,3 файл docker-compose и запускаем
• Считаем, что пришлось делать “вручную”: выбирать узлы, монтировать nfs, загружать файл docker-compose, выяснять порты - выход: Система Kubernetes

1. Зачем нужен Docker?
2. Чем Docker отличается от LXC?
3. Из каких частей состоит имя образа?
4. Чем Docker контейнер отличается от Docker образа?
5. Как ПО в Docker контейнере может взаимодействовать с системой и другими контейнерами?
6. Зачем нужен Dockerfile?
7. Зачем “запихивать” сразу много инструкций в команду RUN?
8. Зачем нужен docker-compose?

• Система Kubernetes

• Может закончиться место на диске VM server и понадобиться Удаление архива установленных пакетов плюс отключение GitLab Prometheus или Расширение существующего логического тома
• Производим Установка minikube для gitlab-runner@server (для доступа к репозиторию, на нем же, понадобится включить Сервисы Gateway и routing)
• Инструмент командной строки kubectl для gitlab-runner@server

• Изучаем Базовые объекты k8s
• Для понимания работы Ingress, настраиваем NGINX для доступа к приложению webd в minikube с хост системы
• Тестируем livenessProbe с extern-host

extern-host# cat /etc/hosts

...
172.16.1.X     webd.corpX.un

• Автоматизируем deploy используя GitLab CI/CD, сталкиваемся с необходимостью править версию в манифесте, рассмотрев вариант envsubst видим необходимость в Helm

• DevOps. Уровень 2. Использование Kubernetes

• Разворачиваем новый Кластер Kubernetes из node1,2,3
• Тестируем, используя Базовые объекты k8s из Docker Hup, в процессе подключив Инструмент командной строки kubectl gitlab-runner@server к новому кластеру
• Тестируем Базовые объекты k8s из локального репозитория и deploy GitLab CI/CD в новом кластере (потребуется Настройка доступа к Insecure Private Registry и, при использовании nfs-volume, Установка nfs клиента на node1,2,3)
• Используем Helm Chart для развертывания и тестирования Ingress в новом кластере
• Создаем Helm Chart для развертывания приложения webd (предварительно проводим Удаление объектов deployment, service и Ingress (можно весь namespace my-ns) и добавляем index.html в Создание образа для приложения с использованием Dockerfile для упрощения примера)
• Используем Helm Chart для deploy приложения webd в GitLab CI/CD, демонстрируем history и rollback
• Через Настройка балансировки нагрузки в Keepalived предоставляем доступ снаружи для тестирования нагрузки и отказоустойчивости
• Работа со своим репозиторием для Helm Charts

• Почему Kubernetes часто обозначают K8s?
• Чем K8s отличается от Docker-Compose?
• Что используется для описания состояния объектов в K8s?
• Как связаны понятия Deployment, Replica Sets, Pods?
• Для чего используются Namespace?
• Что общего и в чем различие между Service и Ingress?
• Что используется для подключения Pod к общим файлам?
• Для чего нужен Helm и что используется для его описания?