Когда речь заходит о DevOps, часто упоминаются такие вещи, как CI/CD, IaC, Docker, K8s, Ansible, Terraform, Git, Jenkins, Prometheus, Grafana и т.п.
В этой части мы на простом примере рассмотрим для чего нам пригодятся перечисленные выше инструменты, продвигаясь от разработчика-одиночки до полноценной команды. Не пугайтесь, если какие-то этапы вам покажутся непонятными или сложными, в следующих частях курса я объясню многие вещи более подробно.
Предыдущая часть курса доступна по ссылке:
Всё начинается с идеи
Итак, вам пришла умная мысль создать приложение, которое облегчит жизнь миллионам пользователей по всему миру. Недолго думая, вы садитесь за редактор и начинаете воплощать идею в жизнь.
Спустя небольшой период времени у вас готова первая версия приложения, но она доступна только на вашем компьютере по адресу localhost. Даже если вы пробросите порты и поделитесь своим IP, стоит вам выключить ПК, как доступ к вашему приложению будет потерян.
Вы решаете арендовать VDS или VPS и скопировать проект туда. После переноса исходников на сервер, приложение не будет работать просто так. Для начала необходимо настроить ОС и установить необходимые зависимости.
Если приложение написано на Python, PHP, Java или другом языке, вам необходимо установить его на сервер. Аналогично потребуется поступить с библиотеками и сторонними пакетами, которые использует ваше приложение. Версии пакетов на вашем ПК и на сервере должны совпадать.
Справившись с настройкой сервера, вы решаете заниматься разработкой приложения на своём ПК, а на сервере лишь запускать приложение, чтобы оно было доступно всем пользователям. Таким образом ваш компьютер становится средой разработки, а сервер - производственной средой:
Осталось купить доменное имя и сопоставить его с IP-адресом вашего сервера.
Рабочий процесс (WorkFlow)
На данном этапе рабочий процесс можно представить следующим образом:
- Разработка (Develop). Вы написали код на своём ПК и теперь его необходимо перенести на сервер.
- Сборка (Build). Перенос исходников - сомнительное мероприятие. Гораздо проще собрать приложение, чтобы сервер сразу мог с ним работать.
- Развёртывание (Deploy). После переноса приложения достаточно запустить исполняемый файл.
Сейчас рабочий процесс представляет из себя три простых шага.
Git
Спустя время приложение набирает большую популярность, пользователям требуются новые функции, и вы понимаете, что вам нужна помощь. Вы включаете в проект своих друзей, друзей их друзей, друзей друзей друзей
и так далее.
Теперь каждый разработает в своей среде разработки, но над одним проектом, используя общую кодовую базу. Вы понимаете, что требуется хранилище кода, но это не должно быть чем-то типа обычного файлового хранилища, иначе начнутся конфликты при одновременной работе с файлом или проблемы перезаписи чужих изменений и много чего ещё.
В этой ситуации вам на помощь может прийти такой инструмент, как git. Он позволяет работать одновременно над одним приложением, сохранять изменения поэтапно, настраивать права доступа для пользователей и т.п.
Установив git на ПК, каждый разработчик может скачать последнюю версию кода (git pull) и беспрепятственно добавить собственные изменения (git push).
GitHub - наиболее популярный веб-сервис для хостинга IT-проектов и их совместной разработки, созданный на базе git.
На собственных мощностях, как правило, используют GitLab.
При работе в большой команде, заниматься сборкой приложения на собственном ПК так, чтобы оно включало все последние версии исходников, будет очень сложно. Лучше для этих целей добавить отдельный сервер, который будет отвечать за сборку приложения. Кроме того, теперь значительно возросла вероятность появления ошибок в приложении, поэтому помимо сервера сборки, вам также пригодится тестовый сервер.
CI/CD
Теперь рабочий процесс выглядит следующим образом: каждый разработчик пишет код на своём ПК, а затем пушит изменения в git-репозиторий. Далее вы вручную копируете исходники на сервер сборки и собираете в исполняемый файл. Затем также вручную копируете исполняемый файл на тестовый сервер, тестируете приложение и, убедившись, что явных ошибок нет, копируете и разворачиваете его в продакшен:
Вы выполняете описанные действия раз в месяц в ручном режиме, однако этот временной интервал является слишком большим, т.к. некоторые разработчики выкатывают новые фичи раз в день.
Чтобы иметь возможность выпускать изменения быстрее и с большей степенью автоматизации, необходимо прибегнуть к помощи инструментов CI/CD.
CI/CD представляет собой автоматизированный процесс непрерывной интеграции и непрерывного развёртывания приложений.
Для автоматизации процессов (создания пайплайнов, т.е. конвейеров) можете использовать такие инструменты, как Jenkins, GitHub Actions или GitLab CI/CD.
Однократно настроив необходимые инструменты, приложение будет автоматически собираться как только кто-то запушит изменения в git. После оно так же автоматически поместится на сервер тестирования и при успешном прохождении тестов, будет автоматически развёрнуто в производственной среде.
Такая автоматизация позволяет быстрее реализовывать новые функции и исправлять возникающие ошибки, т.к. чем меньше изменений было внесено, тем проще найти причину неправильной работы приложения.
Контейнеры
После настройки CI/CD Pipeline, всё ещё требуется ручная настройка зависимостей. При переходе на новую версию Java или Python вам придётся вручную заниматься установкой и удалением пакетов на серверах.
Если бы приложение могло разворачиваться вместе со всеми необходимыми зависимостями, это сильно упростило бы задачу. Здесь нам на помощь приходят контейнеры.
Контейнеры разворачиваются из образов и содержат в себе все необходимые библиотеки и зависимости. Самой популярной технологией контейнеризации на сегодняшний день является Docker. Более подробно про контейнеры рекомендую прочитать здесь:
При использовании контейнеров docker, разработчику достаточно создать DockerFile с описанием необходимых зависимостей и команд. Он будет использоваться для сборки Docker Image, который затем будет запущен в тестовой и производственной среде.
Контейнеры решают ещё одну проблему: благодаря их использованию, мы можем развернуть несколько экземпляров приложения на одном сервере, причём они будут полностью изолированны друг от друга.
Оркестрация контейнеров
Теперь вы можете развернуть несколько экземпляров на одном сервере, а в зависимости от нагрузки, их количество может увеличиваться или сокращаться. Осталось решить несколько задач:
- Как следить за тем,чтобы контейнеры работали правильно?
- Как перезагрузить сбойный контейнер?
- Как автоматизировать увеличение и уменьшение количества используемых контейнеров?
Справиться с обозначенными выше функциями вам помогут платформы оркестрации контейнеров, например Kubernetes.
Рекомендую ознакомиться с оркестрацией контейнеров подробнее по ссылке ниже:
IaC
Теперь модель рабочих процессов кажется завершённой и больше автоматизировать нечего, однако, это не совсем так:
Если понадобится развернуть ещё один сервер в облачной среде или на гипервизоре, вам по-прежнему придётся делать это руками.
Такая подготовка сервера не защищена от человеческого фактора и сильно уступает по скорости автоматической настройке. Также было бы неплохо задокументировать все настройки, с которыми разворачивается сервер.
Terraform & Ansible
Решить эти проблемы помогут два популярных инструмента. Terraform развернёт сервер с необходимыми настройками, т.е. подготовит инфраструктуру, Ansible настроит её (установит пакеты и зависимости, добавит пользователей, отредактирует права доступа и т.п.).
Оба инструмента имеют схожие возможности, но каждый из них имеет свои преимущества в определённых областях. Terraform - подготовка инфраструктуры, Ansible - её настройка.
Оба инструмента используют в своей работе файлы, имеющие определённый синтаксис, с их помощью вся инфраструктура может быть описана в виде кода, этот подход называется Infrastructure-as-Code.
Мониторинг
Теперь инфраструктура готова, но вам необходимо следить за состоянием серверов, получать информацию о нагрузке и заблаговременно предпринимать некоторые действия. Например, просмотр загрузки ЦП или ОЗУ, объём свободного места на дисках и т.п.
С этим помогут справиться Prometheus и Grafana.
Prometheus
Prometheus централизованно собирает метрики (показатели) с различных серверов. Чтобы представить собранную информацию в виде графиков и диаграмм требуется такой инструмент, как Grafana.
Grafana
Grafana составляет графики на основе информации, которую собрал Prometheus.
Заключение
И так, от идеи создания вы переходите к написанию кода, сборке, тестированию и развёртыванию приложений. Пользователи работают с приложением и выдвигают новые идеи и требования, которые вы реализуете в коде. Таким образом цикл замыкается и может повторяться до бесконечности:
Спасибо, что дочитали статью до конца. Поддержите канал лайком и подпиской, чтобы чаще видеть в ленте подобный контент.
Для желающих поддержать материально:
- Сбербанк: 2202 2013 5155 5152
- Тинькофф: 2200 7008 1567 2323
