введение в devops инфраструктура как код использование docker и kubernetes
Отзывы по курсу «Введение в DevOps: инфраструктура как код, использование Docker и Kubernetes»
Заказ добавлен в Корзину.
Для завершения оформления, пожалуйста, перейдите в Корзину!
Авторизации
Спасибо! Вам на e-mail отправлено письмо со ссылкой для подтверждения
Если письмо не пришло, поищите его в папке со спамом или повторите подписку
DevOps с Kubernetes и VSTS. Часть 1: Локальная история
Последнее время я часто рассказываю про контейнеры, Docker и Kubernetes. На фоне этого коллеги всё чаще стали спрашивать о том, а где же здесь технологи Microsoft? Чтобы объяснить, я нашёл несколько материалов, в том числе этот набор из пары статей от Colin Dembovsky. В них есть всё: Docker, Kubernetes и наши технологии. Думаю, что для читателей Хабры это тоже должно быть интересно. Итак, встречайте, перевод первой части.
Если вы читаете мой блог, то знаете, что я фанат контейнеров в целом и Docker в частности. Когда вы в последний раз ставили софт на «голое железо»? Может быть, только на ноутбук, но и то шансы невелики. Виртуализация кардинально изменила наше отношение к ресурсам центра обработки данных, значительно увеличив их плотность и эффективность использования. Следующим этапом повышения плотности стали контейнеры, только ВМ размещаются на физических серверах, а контейнеры — в самих ВМ. Очень скоро большинство из нас не будет работать не только на уровне серверов, но даже на уровне ВМ, все рабочие нагрузки переместятся в контейнеры. Но это в перспективе.
Серия статей «Говорим о контейнерах»:
Несмотря на все преимущества контейнеров с точки зрения упаковки приложений, многим до сих пор непонятно, как запускать контейнеры в производственной среде. Установка одного контейнера станет интересным и воодушевляющим опытом для любого разработчика, но как насчет масштабирования контейнеров или объединения их в кластер? Как вы будете наблюдать за своими контейнерами? Как выявлять и устранять сбои? Здесь мы плавно переходим к проблеме оркестрации контейнеров.
В этой статье мы рассмотрим подходы к локальной разработке с использованием Kubernetes и minikube. Часть 2 посвящена вопросам создания конвейеров CI/CD для кластера Kubernetes в Azure.
Поле битвы — оркестрация
Существуют три популярные системы оркестрации контейнеров — Mesos, Kubernetes и Docker Swarm Mode. Я не буду призывать вас встать под чей-то флаг (по крайней мере пока), концептуально они все похожи. Они все используют концепцию «конфигурация как код» для развертывания множества контейнеров на множество узлов. Kubernetes предлагает ряд возможностей, которые, на мой взгляд, станут настоящим прорывом в области DevOps: карты конфигурации (ConfigMaps), секреты (Secrets) и пространства имен (namespaces).
Не вдаваясь в подробности, скажу, что пространства имен позволяют создавать различные логические среды в одном кластере. В качестве примера приведу пространство имен DEV, где вы сможете запускать небольшие копии своей среды PROD в целях тестирования. Пространства имен также применяются для реализации мультитенантности или различных контекстов безопасности. Карты конфигурации (ConfigMaps) и секреты (Secrets) позволяют хранить конфигурацию за пределами контейнеров, то есть вы сможете запускать один образ в различных контекстах без встраивания специфичного кода для конкретной среды в сами образы.
Kubernetes Workflow (рабочий процесс) и Pipeline (конвейер)
В этой статье я продемонстрирую подход к разработке с ориентацией на Kubernetes. В первой части мы рассмотрим рабочий процесс разработки, а во второй — конвейер DevOps. К счастью, благодаря MiniKube (кластеру с одним узлом Kubernetes, который запускается на ВМ) мы можем работать с полноценным кластером на ноутбуке! Это означает, что вам доступны преимущества кластерной технологии (вроде ConfigMaps) без подключения к производственному кластеру.
Итак, рассмотрим рабочий процесс разработчика. Это будет что-то вроде:
Затем вы перейдете к конвейеру DevOps, начиная с его создания. На основе ваших исходных файлов и файлов Dockerfile создаются образы, которые регистрируются в приватном реестре контейнеров. Далее необходимо передать конфигурацию в кластер Kubernetes, чтобы запустить/развернуть новые образы. Благодаря Azure и VSTS мы создадим конвейер DevOps буквально за пару-тройку кликов! Но это тема второй части нашей статьи, сейчас же мы изучаем рабочий процесс разработчика.
Подготовка среды разработки
Для демонстрации я буду использовать Windows, но в Mac или Linux настройки аналогичные. Для развертывания локальной среды разработки вам нужно установить:
Мне пришлось выполнить команду cd для перехода в корневой каталог c:\, без этого MiniKube не смог бы создать ВМ.
Внешняя сеть подключена к моей точке доступа Wi-Fi. Это означает, что когда я подключаюсь к новой сети, ВМ minikube получает новый IP-адрес. Вместо того чтобы каждый раз обновлять kubeconfig, я просто добавил строку хоста в свой файл hosts (в Windows это c:\windows\system32\drivers\etc\hosts): kubernetes, где IP — это IP-адрес ВМ minikube, полученный с помощью команды minikube ip. Для обновления kubeconfig используйте следующую команду:
Теперь при подключении к новой сети вы просто обновите IP-адрес в файле hosts, и команда kubectl по-прежнему будет работать. Сертификат генерируется для узла с именем kubernetes, поэтому используйте это имя.
Если все работает нормально, вы получите лаконичный ответ на команду kubectl get nodes:
Чтобы запустить UI Kubernetes, просто введите команду minikube dashboard. В браузере откроется следующее окно:
Наконец, для «повторного использования» контекста minikube docker выполните следующую команду:
Таким образом обеспечивается совместное использование сокета minikube docker. Выполнив команду docker ps, вы получите информацию о нескольких работающих контейнерах, это базовые системные контейнеры Kubernetes. Это также означает возможность создания здесь образов, которые могут запускаться кластером minikube.
Теперь у вас есть кластер с одним узлом. Можете приступать к разработке!
Переходим к коду
Файл docker-compose.yml определяет составное приложение из двух образов: api и frontend:
Файл Dockerfile для каждой службы максимально прост: запуск из образа ASP.NET Core 1.1, копирование файлов приложения в контейнер, открытие порта 80 и запуск dotnet app.dll (frontend.dll и api.dll для каждого сайта) в качестве точки входа для каждого контейнера:
Чтобы подготовиться к созданию образов, выполните команды dotnet restore, build и publish, произойдёт сборка и публикация проектов. Теперь можно переходить к созданию образов. При наличии готовых образов мы можем настроить службу Kubernetes на их запуск в нашем кластере minikube.
Создание образов
Проще всего для создания образов использовать Visual Studio. Настройте проект docker-compose как стартовый и запустите его. Образы будут созданы. Если вы не работаете с Visual Studio, создавайте образы, выполняя следующие команды из корневого каталога репозитория:
Теперь после выполнения команды docker images вы увидите контейнеры minikube, а также образы для frontend и api:
Объявление служб — конфигурация как код
Теперь мы можем указать, какие службы запускать в кластере. На мой взгляд, одно из преимуществ Kubernetes заключается в том, что вы должны объявлять свою среду, вместо того чтобы запускать скрипт. Такая декларативная модель намного лучше императивной, и в настоящее время она распространяется все шире благодаря Chef, Puppet и PowerShell DSC. Kubernetes позволяет нам указывать запускаемые службы, а также определять методы их развертывания. Различные объекты Kubernetes можно определять с помощью простого файла yaml. Мы объявляем две службы: api и frontend. Серверные службы (backend) обычно недоступны за пределами кластера, однако в данном случае наш демонстрационный код представляет собой одностраничное приложение, поэтому служба api должна быть доступна извне.
Перечень служб будет меняться очень редко, это службы, доступные в кластере. Однако базовые контейнеры (в Kubernetes их называют подами), из которых состоит служба, будут меняться. Они меняются при обновлении, а также при масштабировании. Для управления контейнерами, из которых состоит служба, используется конструкция Deployment. Поскольку служба и развертывание довольно тесно связаны, я поместил их в один файл. То есть у нас есть файл для службы/развертывания frontend (k8s/app-demo-frontend-minikube.yml) и файл для службы/развертывания api (k8s/app-demo-backend-minikube.yml). Если вы посчитаете нужным, можете поместить определения служб и развертываний в отдельные файлы. Изучим содержимое файла app-demo-backend.yml:
Управление конфигурацией
Теперь у нас есть несколько образов контейнеров и мы можем запускать их в minikube. Но прежде чем начать, давайте обсудим конфигурацию. Если вы слышали мои выступления или читали мой блог, то вы знаете, что я — один из главных пропагандистов концепции «создаем один раз, разворачиваем многократно». Это базовый принцип правильного DevOps. В случае с Kubernetes и контейнерами ситуация аналогичная.
Однако для этого вам нужно будет размещать конфигурацию за пределами своего скомпилированного кода, то есть понадобятся такие механизмы, как файлы конфигурации. Если вы выполняете развертывание в службах IIS или Azure App, то можете просто использовать файл web.config (для DotNet Core это будет appsettings.json) и указать разные значения для разных сред. Но как тогда быть с контейнерами? Весь код приложения находится в контейнере, поэтому вы не можете использовать разные версии конфигурационного файла, в противном случае вам понадобятся разные версии самого контейнера, то есть принцип однократного создания будет нарушен.
К счастью, мы можем использовать подключаемые тома (концепция контейнеров) в сочетании с секретами и (или) configMaps (концепция Kubernetes). Мы можем указать configMaps (по сути это пары ключ — значение) или секреты (маскированные или скрытые пары ключ — значение) в Kubernetes, а затем просто смонтировать их путем подключения томов в контейнерах. Это действительно мощный инструмент, поскольку определение пода остается прежним, но если у нас есть другой configMap, мы получаем другую конфигурацию! Мы увидим, как это работает, когда будем выполнять развертывание в облачном кластере и использовать пространства имен для изоляции среды разработки и производственной среды.
configMaps также можно указать с помощью метода «конфигурация как код». Вот конфигурация нашего configMap:
Отступление: проблема символьных ссылок на статические файлы
Я действительно столкнулся с одной проблемой при монтировании конфигурационного файла с помощью configMaps: внутри контейнера путь /app/www/config/config.json оканчивается символической ссылкой. Идею использовать configMap в контейнере я подсмотрел в отличной статье Энтони Чу (Anthony Chu), где он описывает, как подключал файл application.json для использования в файле Startup.cs.
Очевидно, с проблемой символической ссылки в файле Startup он не сталкивался. Однако для своего демонстрационного клиентского приложения я создаю конфигурационный файл, который используется SPA-приложением, и поскольку он находится на стороне клиента, конфигурационный файл должен предоставляться из приложения DotNet Core, просто в виде html или js. Нет проблем. У нас уже есть вызов UseStaticFiles в Startup, поэтому он должен просто предоставлять файл, верно? К сожалению, это не так. Скорее всего, он перешлет только первые несколько байтов из этого файла.
Я потратил пару дней, чтобы разобраться с этим. На Github есть специальная тема, можете почитать, если вам интересно. Если коротко, длина символической ссылки — это не длина самого файла, а длина пути к файлу. Промежуточное ПО StaticFiles считывает FileInfo.Length байт при запросе файла, но поскольку эта длина не равна полной длине файла, то возвращаются только первые несколько байтов. Я создал средство FileProvider для обхода этой проблемы.
Запуск образов в Kubernetes
Чтобы запустить вновь созданные службы в minikube, мы можем просто использовать kubectl для применения конфигураций. Вот список команд (выделенные строки):
Теперь у нас есть службы! Вы можете открыть информационную панель командой minikube dashboard и убедиться, что статус служб — зеленый:
Чтобы подключиться к клиентской службе, введите адрес http://kubernetes:30080:
Список (value1 и value2) — это значения, возвращаемые службой API, то есть клиент смог успешно подключиться к серверной службе в minikube!
Обновление контейнеров
После обновления своего кода вам придется пересоздавать контейнер(ы). Обновив конфигурацию, снова запустите команду kubectl apply для обновления configMap. Затем, поскольку нам не нужна высокая доступность в среде разработки, мы можем просто удалить запущенные поды и дать возможность службе репликации перезапустить их, но на этот раз с обновленной конфигурацией и (или) кодом. Конечно, в производственной среде такие вольности недопустимы, и во второй части я покажу вам, как выполнять последовательные обновления, когда мы будем работать с CI/CD в кластере Kubernetes.
Но в среде разработки я получаю список подов, удаляю их все, а затем наблюдаю, как Kubernetes волшебным образом перезапускает контейнеры (с новыми идентификаторами). В итоге я получаю обновленные контейнеры.
Обратите внимание, что идентификаторы подов меняются, поскольку и сами поды уже другие. Если мы переключимся на клиентскую часть, то увидим обновленный код.
Заключение
Я действительно впечатлен возможностями Kubernetes и тем, как эта платформа способствует популяризации концепции «инфраструктура как код». Вы можете достаточно просто развернуть кластер локально на вашем ноутбуке с помощью minikube и начать разработку в среде, максимально приближенной к производственной, а это всегда хорошая идея. Вы можете использовать секреты и карты configMaps, аналогичные тем, что применяются в производственных контейнерах. В целом это отличный подход к разработке, позволяющий придерживаться лучших практик с самого начала.
Введение в DevOps: инфраструктура как код, использование Docker и Kubernetes
Introduction to DevOps: Infrastructure as Code, using Docker and Kubernetes
09.02.06 Сетевое и системное администрирование
Курс предназначен для инженеров DevOps и системных администраторов, желающих освоить принципы и технологии Infrastructure as a Code для автоматизации развертывания и управления IT инфраструктурой предприятия.
Ближайшая группа
воскресенье:
10:00 — 17:10
Для физ.лиц
Для организаций*
*Для оформления заказа от организации обращайтесь по тел. +7(495) 780-48-44
Преподаватели
Кузнецов Илья Васильевич
Описание курса
Цели курса
Учебный центр «Специалист» при МГТУ имени Баумана специально разработал этот курс для инженеров DevOps и системных администраторов, желающих освоить принципы и технологии Infrastructure as a Code для автоматизации развертывания и управления IT-инфраструктурой предприятия.
Слушатели
Аудитория курса
Вы научитесь
Специалисты, обладающие этими знаниями и навыками, в настоящее время крайне востребованы.
Большинство выпускников наших курсов делают успешную карьеру и пользуются уважением работодателей.
Предварительная подготовка
Требуемая подготовка: Успешное окончание курса Linux. Уровень 1. Основы администрирования систем Debian, Ubuntu, CentOS или эквивалентная подготовка. Успешное окончание курса Linux. Уровень 2. Администрирование сервисов и сетей или эквивалентная подготовка. Успешное окончание курса Linux. Уровень 3. Обеспечение безопасности систем, сервисов и сетей или эквивалентная подготовка.
Программа курса
Аудиторная нагрузка в классе с преподавателем: 24 ак. ч. + 12 ак. ч. бесплатно*
* По данному курсу бесплатно предоставляются дополнительные часы для самостоятельной работы в компьютерных классах Центра, где проводятся занятия. Вы можете закрепить полученные знания, выполнить домашние задания, проконсультироваться у специалистов Центра. Дополнительные часы предоставляются в дни занятий по предварительному согласованию с администратором комплекса.
По окончании обучения на курсе проводится итоговая аттестация. Аттестация проводится в виде теста на последнем занятии или на основании оценок практических работ, выполняемых во время обучения на курсе.
Преподаватели
Кузнецов Илья Васильевич
Отзывы выпускников
Костаков Александр Андреевич
Понравилась тема про ансибл. Это то, что я реально смогу (и буду) применять на практике.
Богданов Виталий Викторович
Самый полезный и самый тяжелый курс, которой я проходил.
Тишин Антон Юрьевич
Имея лишь базовые представления о материале, после окончания курса чувствую себя уверенно. Курс является основой, достаточной для трудоустройства. Материал достаточно хорошо изложен, все закреплено действиями, понятными при прослушивании лекций. Гибкая форма обучения, направленная на получение знаний.
Сомов Дмитрий Евгеньевич
Достаточно ёмкий курс по наполнению. Рассматриваются наиболее востребованные на сегодняшний день технологии DevOps на примере хорошо зарекомендовавших себя инструментов, использование которых считается мейнстримом (Vagrant, Anisble, GitLab, GitHub, Jenkins, Docker, Kubernetes).
Расписание групп обучения
Сортировать:
с 24.10.2021
по 07.11.2021
воскресенье утро-день
10:00 — 17:10
м.Бауманская
м.Авиамоторная
Стоимость для физ. лиц
с 27.11.2021
по 11.12.2021
воскресенье утро-день
10:00 — 17:10
м.Бауманская
м.Авиамоторная
Стоимость для физ. лиц
с 30.01.2022
по 13.02.2022
воскресенье утро-день
10:00 — 17:10
м.Бауманская
м.Авиамоторная
Стоимость для физ. лиц
с 10.04.2022
по 24.04.2022
воскресенье утро-день
10:00 — 17:10
м.Бауманская
м.Авиамоторная
Стоимость для физ. лиц
с 22.05.2022
по 05.06.2022
воскресенье утро-день
10:00 — 17:10
м.Бауманская
м.Авиамоторная
Стоимость для физ. лиц
с 14.08.2022
по 28.08.2022
воскресенье утро-день
10:00 — 17:10
м.Бауманская
м.Авиамоторная
Стоимость для физ. лиц
с 09.10.2022
по 23.10.2022
воскресенье утро-день
10:00 — 17:10
м.Бауманская
м.Авиамоторная
Стоимость для физ. лиц
с 29.10.2022
по 12.11.2022
суббота утро-день
10:00 — 17:10
м.Бауманская
м.Авиамоторная
Стоимость для физ. лиц
с 19.11.2022
по 03.12.2022
суббота утро-день
10:00 — 17:10
м.Бауманская
м.Авиамоторная
Стоимость для физ. лиц
* Данная скидка действительна при заказе и оплате онлайн обучения только сегодня. Запишитесь прямо сейчас со скидкой!
Стоимость обучения
Частным лицам
26 990 ₽
24 250 ₽ (-10%)
От 1 440 руб./месяц
Организациям
29 990 ₽
26 990 ₽ (-10%)
Указана минимальная цена за индивидуальное обучение. Число часов работы с преподавателем в 2 раза меньше, чем при обучении в группе. Если Вам для полного усвоения материала курса потребуется больше часов работы с преподавателем, то они оплачиваются дополнительно. В случае занятий по индивидуальной программе расчёт стоимости обучения и количества необходимых часов производится отдельно.
Для юридических лиц (организаций) указана цена, действующая при полной предоплате.
Документы об окончании
В зависимости от программы обучения выдаются следующие документы:
Cертификат международного образца
Удостоверение *
Свидетельство
* Для получения удостоверения вам необходимо предоставить копию диплома о высшем или среднем профессиональном образовании.
Сертификаты международного образца выводятся после окончания курса в личном кабинете слушателя.
Данное предложение действует только для частных лиц.