Введение в методологию DevOps. Основные определения

Stateful - Stateless инфраструктуры и Микросервисы

Тема очень тесно переплетена с предыдущей по принципу управления и менеджмента системами и экземплярами приложений.

Для инфраструктуры понятия Stateless/stateful я бы описал следующим образом: это типы инфраструктуры в которой важно или не важно, продолжит ли после перезагрузки система с того же состояния что было до отключения.

Здесь всё условно и зависит от самого приложения, которое вы поддерживаете, но, в значительном количестве случаев, можно привести следующие примеры:

• Множество балансировщиков нагрузки, к примеру - Nginx. За исключением случаев, когда приложение поддерживает длительные keep-alive соединения сокетов, которые не переподключаются самостоятельно - вы можете свободно убить любой из балансировщиков нагрузки, и все подключения сбалансируются на оставшиеся, а убитый экземпляр можно заменить новым балансировщиком. Или к примеру front-end часть которая отдает статику, балансирует нагрузку друг с другом. В случае если один из бэкендов, отдающих статику, вылетает - балансировщик нагрузки это замечает и легко может подобрать нехватающие данные с оставшихся. Это - stateless. Вам безразлично в каком состоянии остановится и восстановится экземпляр приложения.
• Stateful - это когда вам важно чтобы приложение сохранило состояние перед перезапуском, или новый экземпляр продолжил с того же места. По большей части все эти требования так или иначе относятся к целостности обрабатываемых или хранимых данных. Пример - базы данных в которые пишутся транзакции, и, к примеру, происходит репликация на другие ноды. Ещё один пример - файловые дисковые подключения: NFS, Ceph, самба и так далее. Постоянную репликацию данных очень тяжело обеспечить, и всегда важно чтобы после перезагрузки все файлы были в ожидаемо последнем состоянии. В случае повреждения файловов - можно потерять ощутимый кусок информации.

Минусов и плюсов тут нет, в работе DevOps-a присутствуют оба типа приложений, и придётся поддерживать оба. И в процессе разработки инфраструктуры нужно иметь ввиду как эти концепции работают.

Теоретически можно сказать что для Stateless идеально подходит концепция Cattle а для Stateful - Pet, но это не так. Зачастую и stateless приложения удобнее и выгоднее поддерживать постоянными инстансами, а stateful - перезапустить как Pet, но имея возможность выполнить graceful shutdown и сохранив все данные.

Компетенции необходимые каждому DevOps-инженеру

Профессия DevOps инженера включает в себя множество различных компетенций, обладание которыми желательно каждому DevOps-у.

Язык программирования для написания скриптов.

Наиболее оптимальные варианты Python или Golang. DevOps-инженер не программист. Конечно, есть разработчики, которые совмещают сразу 2 компетенции. Написание кода DevOps-инженеру нужно для того, чтобы автоматизировать процессы, а также создавать личные инструменты. Наиболее популярным языком среди DevOps-ов и простым для изучения является Python в силу простоты написания скриптов автоматизации. Также часто используется Golang. Он работает быстрее Python, но его изучение занимает больше времени, однако его весомым преимуществом является то, что весь код собирается в один файл который удобно перебрасывать между машинами.

• Операционные системы.

  Полезно вникнуть в особенности различных операционок семейства Unix. Возможно, вы не будете использовать каждую из них, но знать заранее с каким проектом придется столкнуться - невозможно. Строение операционных систем лучше изучить детально: каким образом происходит работа внутри системы, файловой подсистемы, сокетов, оперативной памяти и сетей, как система взаимодействует с потоками и разнообразными процессами, каким образом она выполняет распределение нагрузок и ресурсов.

• Умение работать с терминалом.

  Терминал - рабочая среда DevOps-a. Нужно знать, как быстро выполнять базовые манипуляции с системой, текстом, сетью. В системе нужно уметь смотреть состояние ресурсов, выполнять локальные конфигурации, отслеживать, к примеру, сетевой трафик и открытые соединения, конфигурацию ядра. В работе встретится много работы с текстом, например, редактирование конфигураций. Для этого лучше использовать редакторы в терминале - Vi/Vim/Nano. Пригодятся знания инструментов обработки текста, вроде grep/awk/wc/cat/echo и т.д. Часто придётся смотреть логи локально, поэтому нужно знать соответствующие инструменты.

• Сети

  Взаимодействия приложений и пользователей с приложениями происходит через сеть. Важно знать, как она работает, по каким принципам взаимодействуют хосты в сети, как работает DNS, как помочь клиенту найти нужный хост (а также сделать отказоустойчивость и балансировку нагрузки), как соединить большие сети, какие протоколы как передают данные и как их шифровать.

• Облачные инфраструктуры

  Принципы работы облачных инфраструктур схожи: виртуальные сети, вычислительные инстансы, хранилища и способы авторизации. Остальное зависит от провайдера и предоставляемых сервисов.

• Оркестрация контейнеров

  В эпоху микросервисов контейнеризация используется очень активно. Контейнерами нужно как-то управлять, для этого существует несколько главных инструментов - оркестраторов. Самый распространенный (так как поддерживается и продвигается Google) - Kubernetes, также используется Docker-Swarm, в больших корпорациях - Openshift.

• Метрики и логирование

  Метрики и логирование - основной инструмент в анализе инцидентов, и того, как работает инфраструктура. Важно знать, как и куда собирать метрики, логи, как и на основе чего создавать алерты.

Наиболее важные вещи будут рассмотрены в этом курсе. Остальные рекомендуются к самостоятельному изучению.

Что такое CI/CD ?

CI/CD делится на три понятия, два из которых предельно близки:

• CI - Continuous integration (Непрерывная интеграция)
• CD - Continuous delivery (Непрерывная доставка) и Continuous deployment (Непрерывное развёртывание)

Давайте рассмотрим чуть более конкретные примеры.

CI (Continuous integration)- это в принципе одно и тоже понятия для любых типов пайплайнов. Это включает в себя параллельную разработку командой разработчиков одного продукта - то есть использование git или любой VCS (version control system), а также постоянную проверку нового кода и поддержание его в работоспособном состоянии. Плюс сюда же включена сборка продукта в некие артефакты.

CD (Continuous delivery) - это доставка артефактов на окружение, ручное или автоматизированное тестирование самого продукта, и подготовка к деплою в продакшен окружение. Однако само развертывание производится по ручному разрешение.

CD (Continuous deployment) - в случае Continuous deployment это та же доставка, однако полностью в автоматическом режиме новая версия доставляется в продакшен окружение.

Выводы

DevOps в классическом понимании - методология разработки программного обеспечения. На практике DevOps инженер это специалист, отвечающий за инфраструктур, развертывание, создание и поддержание работоспособности сред разработки и тестирования.

Существуют различные DevOps концепции ,наиболее популярные - SaaS. PaaS. IaaS., Pet vs Cattle, Stateful - Stateless.

Профессия DevOps инженера находится между железом и разработкой, поэтому для эффективной работы необходимо понимание как высокоуровневых, так и низкоуровневых инструментов.