====== DevOps ====== MVP (Minimal Viable Product) - быстро написанное ПО/сервис, минимально покрывающее поставленную задачу. Нужно для проверки, взлетит проект или нет. Жизненный цикл ПО - от планирования до прекращения использования. - Планирование, анализ (технический, экономический, подходы) - Определение требований (спецификация ПО) - Проектирование архитектуры - Разработка - Тестирование - Развёртывание и поддержка Модели разработки определяют стиль и подход, наиболее подходящие для того или иного проекта. * Waterfall - поэтапная модель. Хорошо документировано и спланировано, но долго, и очень трудно/дорого внести изменения по ходу или откатиться на предыдущий этап. Применяется при строго фиксированном бюджете или на простых проектах. * V-модель - на каждом этапе параллельно проводится тестирование. Мало ошибок, но опять же долго и трудно/дорого менять план. Применяется при необходимости непрерывного функционирования разрабатываемого ПО. * Agile - работающий продукт важнее документация, взаимодействие людей важнее процессов, работа с заказчиком важнее условий контракта, изменения важнее плана. * Scrum - постоянные мелкие улучшения. Книги:\\ Джефф Сазерленд - Scrum. Революционный метод управления проектами\\ Эндрю Стеллман, Дженнифер Грин - Постигая Agile: ценности, принципы и методологии ===== git (VCS, version control system) ===== VCS обеспечивает хранение версий ПО и вносимые изменения каждого разработчика. Соответственно, это позволяет их отслеживать, откатываться, делить на ветки. Децентрализация - каждый разраб скачивает репозиторий на свою тачку, и если сервер не работает, можно переехать на другой, загрузив туда код. Самые популярные системы - Github, Gitlab, Bitbucket. Сохранение состояния проекта - как снапшот, на который делается ссылка. Книги:\\ Скотт Шакон - [[https://git-scm.com/book/en/v2|Pro Git]] ==== Ветвления ==== === Trunk-Based Development === [[https://www.optimizely.com/optimization-glossary/trunk-based-development/|Trunk-Based Development]] - частые мелкие изменения прямо в master. Ветки feature короткоживущие и ведутся чаще всего одним разработчиком. {{:learning:pasted:20220722-060928.png?600}} Подходит для мелких проектов и небольших команд, или когда нужно что-то быстро написать (MVP). === Feature Branch Workflow === Feature Branch Workflow - новые функции разрабатываются отдельно от master (где всегда содержится рабочий код), ветки feature существуют долго, в рамках этих веток делаются pull-реквесты для совместной работы. {{:learning:pasted:20220722-062952.png?600}} === Gitflow === Gitflow - основная разработка ведётся в ветке develop, ветки feature делаются от неё и сливаются с ней же. Master - это история релизов с единственной производной от неё - hotfix, где правятся баги. После исправления ошибок hotfix сливается с master и develop. Когда в develop достаточно изменений для релиза, создаётся ветка release и там код допиливается без добавления новых функций и пишется документация, затем она сливается в master (и в develop) и ей присваивается версия, а ветка release удаляется. {{:learning:pasted:20220722-061909.png}} https://bitworks.software/2019-03-12-gitflow-workflow.html === Gitlab flow === Разработка ведётся аналогично GitHub flow — в отдельных ветках, которые также сливаются в master, но содержимое ветки master развёрнуто на тестовом сервере. Дополнительно у вас есть ветки окружений, содержимое которых соответствует содержимому ваших окружений. Обычно существует три окружения, но их может быть больше или меньше в зависимости от ваших требований: - Master/main - тестовое окружение - Preprod - опытное окружение - Prod - пром {{:learning:pasted:20240529-103458.png?800}} https://habr.com/ru/companies/intersystems/articles/354158/ Использование веток релиза нужно, если ПО выпускается для внешних пользователей. В этом случае ветки нужно называть с использованием минорной версии, например, ''2.3-stable'' или ''2.4-stable''. {{:learning:pasted:20240529-104947.png?600}} Сливать изменения в тематических ветках нужно именно в мастер (не в релиз!), а потом делать cherry-pick оттуда в релизные ветки, иначе баг останется в следующих версиях, когда из непропатченной мастер-ветки создадут новый релиз. Слияние с основной веткой и последующий cherry-pick в релизную называется "upstream first" policy. После cherry-pick в релизной ветке нужно увеличивать патч-версию, устанавливая новый тег. Некоторые проекты также имеют ветку stable, которая указывает на тот же коммит, что и последняя ветка release. В этом случае не принято иметь ветку production. ===== Бережливое производство ===== Lean manufacturing - это постоянный поиск улучшения процессов и снижение количества ненужных и неэффективных действий. Важно определить ценность продукта - то, что решает ключевую потребность (проблему, задачу) потребителя, и сосредоточиться на ней. Например, ценность мессенджера - в передаче текстовых сообщений, а не в смайлах и стикерах, и т. п. Принципы: - Сформулировать ценность - Организовать процесс её создания (планирование, распределение обязанностей, разработка, тестирование и т. д.) - Обеспечить бесперебойную работу над реализацией - все должны быть заняты делом, а не простаивать и ждать друг друга - Не работать без запроса - "впрок", и "чтобы было" - Постоянно работать над улучшением Применительно к разработке тормозом являются ручное развёртывание, тестирование и прочие рутинные неавтоматизированные операции. Есть ряд сервисов по автоматизации сборки, тестирования и деплоя - Travis CI, GitLab CI, Drone CI, TeamCity, Buildbot, Bamboo, Jenkins и т. д. Книги: * Бережливое производство: Как избавиться от потерь и добиться процветания вашей компании. Джеймс П. Вумек, Дэниел Джонс * Continuous delivery. Практика непрерывных апдейтов. Эберхард Вольф * Непрерывное развёртывание ПО. Автоматизация процессов сборки, тестирования и внедрения новых версий программ. Джез Хамбл ===== Какие проблемы решает DevOps ===== DevOps нацелен на решение следующих проблем: * Функциональные колодцы - изолированность отделов (разработка, эксплуатация, тестирование, менеджеры и т. п.). Медленный поиск ошибок, постоянный поиск ответственных, нечёткие границы ответственности, потеря времени и денег бизнесом. * Нисходящая спираль - хаотичное делегирование задач отделам из-за недопонимания, чем они конкретно занимаются. Примеры: плохо выстроенные процессы, отсутствие интереса, проблемы при установке и сопровождении продукта, плохая обратная связь, всё делается вручную, бюрократия, изоляция отделов. Необходимо выстраивать горизонтальные связи, т. е., непосредственное общение сотрудников между собой и обращение к соответствующему отделу в случае каких-то проблем самих сотрудников. Книги: "Руководство по DevOps" Джон Уллис, Патрик Дебуа DevOps = бережливое производство + Agile. Есть несколько методологий Agile: ==== Scrum ==== - Разделение цели на конкретные задачи (user-story), расстановка приоритетов для них. - Разделение времени работы группы на //спринты// (1-2 недели) и показ работы, сделанной за это время. - Согласование с заказчиком приоритетов и планов по результатам работы прошедшего спринта. - Улучшение процесса после каждого спринта. Скрам подразумевает //ритуалы// - совещания в неизменном составе, где ставятся задачи. Большая встреча планирования проводится в начале спринта. Сложность каждой задачи оцениваются коллективно в очках (story-points) и группе даются те задачи, сумма очков которых соответствует //скорости// этой группы (среднее арифметическое очков выполненных задач за несколько спринтов). Скорость увеличивается, если группа выполняет задачи досрочно и берёт новые, что будет учитываться в будущих спринтах. Стендап - короткая ежедневная встреча в рамках группы. Каждый участник отвечает на вопросы: - Что я сделал вчера? - Что я собираюсь сделать сегодня? - Есть ли проблемы, нужна ли мне помощь? В конце спринта - 2 больших совещания: демонстрация сделанного и //ретроспектива// - закрытая встреча группы, работа над улучшением процессов. Скрам критикуется за бюрократию, которой в Agile должно быть по-минимуму. ==== Kanban ==== Визуализация этапов, доска, разделённая горизонтальными полосами. ^Задача ^Разработка\\ Лимит 3 ^Выполнено ^Тестирование\\ Лимит 2 ^Протестировано ^Развёртывание\\ Лимит 2 ^Работает ^Завершено ^ |7 |4 | |5 |2 |3 | |1 | |8 |6 | | | | | | | |9 | | | | | | | | Каждый //стикер// (задача) находится на определённом этапе. Лимит (WIP - work in progress) - это кол-во одновременно возможных задач на этапе, зависит от кол-ва участников и т. п. * В Канбане задача может двигаться только слева направо //по потоку//. Если возникает необходимость вернуть задачу на этап назад, значит, критерии завершённости или набор этапов нужно переосмыслить. * Поиск "бутылочных горлышек". Необходимо улучшать время выполнения задачи и менять критерий WIP (лимит). Если задачи застревают на каком-то этапе - значит, туда нужно направить больше ресурсов/сотрудников или перераспределить их между этапами. ===== 3 пути DevOps ===== ==== Поток создания ценности ==== - Работа должна быть на виду, процессы - прозрачными. Определение, где возникают проблемы (видно на доске Канбана). - Постоянный поиск и решение проблем. Автоматизация. - Уменьшать кол-во делегирований. Чтобы устранить перебрасывание задач и ожидание. - Уменьшать кол-во незавершённой работы. Сократить постоянную дерготню и переключение с задачи на задачу до передачи её на следующий этап. - Уменьшать объём самих задач. С ними легче справиться, их быстрее можно обработать. ==== Обратная связь ==== Необходима связь как с клиентом, так и между участниками группы. Мониторинг, доступность информации, оперативность. Чем быстрее поступит обратная связь - тем лучше, быстрее можно будет что-то исправить. ==== Научный подход к новациям и ошибкам ==== Необходимо экспериментировать в контролируемой среде, чтобы развиваться. Принимать рацпредложения. Ошибки - не заниматься поиском и наказанием виноватых, а найти причину и научиться не повторять этой ошибки, разобрать, что случилось. Тогда работники не будут стремится скрывать ошибки. Иногда ошибка указывает на неэффективно выстроенный процесс. Ошибки можно делать в контролируемой среде и намеренно с целью выявить слабые места, например, для K8s есть kube-monkey. Ещё есть Canary deploy - тест новой версии на части пользователей (уменьшение репутационного и финансового риска, если релиз кривой). Книги: "Руководство по DevOps" Джин Ким ==== 5 идеалов ==== - Стремление к простоте - код, оргструктура и процессы не должны быть запутанно-сложными - Удовольствие от работы, условия, дающие возможность сфокусироваться на достижении результата - Постоянное совершенствование - Психологическая безопасность - открытое обсуждение проблем и выработка механизма их предотвращения вместо поиска крайнего - Внимание к нуждам заказчика, не забывая и о нуждах своей компании [[https://vc.ru/u/439760-dmitriy-blinov/207822-istoriya-sozdaniya-agile-manifesta|История создания Agile-манифеста]]\\ [[https://habr.com/ru/company/vk/blog/272237/|Мастер-класс Бориса Вольфсона. Основы Agile]] ===== Проверка кода ===== Существуют стандарты оформления кода (code conventions) - это правила, которые направлены на облегчение понимания и поддержки кода. Например, PEP 8 (Style Guide for Python Code) или Google C++ Style Guide. Проверки можно проводить как локально в редакторе, так и централизованно в репозитории. Централизованная проверка может быть реализована как с помощью самого репозитория (например, в Gitlab), так и с помощью подключаемых сервисов (SonarQube, Codacy). Помимо проверки на стандарты оформления, полезно проводить проверку на безопасность. Есть несколько вариантов такой проверки. * SAST (Static Application Security Testing) - т. н. "тестирование белого ящика". Это поиск уязвимостей в коде без его запуска. Для такой проверки необходим доступ к коду, ошибки обнаруживаются на раннем этапе, но возможны ложные срабатывания. * DAST (Dynamic Application Security Testing) - "тестирование чёрного ящика". Имитация атаки на систему - SQL-инъекции, некорректные запросы и т. п. Нужно работающее приложение, доступ к коду не нужен (соответственно, эта проверка не покажет, где именно ошибка). Требует больше времени, чем SAST. Также выявляет проблемы быстродействия на разных этапах, например, аутентификации. * IAST (Interactive Application Security Testing) - анализ работы приложения изнутри. Это мониторинг, собирающий данные о работе приложения и анализ полученных данных. IAST может выполняться на любом этапе - от сборки до работы готового приложения. Может указать место в коде, где содержится ошибка, хорошо интегрируется с CI/CD, влияет на работу приложения из-за тесной связи с ним. * RASP (Runtime Application Security Protection) - анализ поведения приложения и контекста выполнения. Сканирование запросов и анализ их обработки приложением. Может не только сообщать о подозрительной активности, но иногда и блокировать её. Влияет на производительность, лучше не применять без других вариантов проверок безопасности. ==== SonarQube ==== Популярный сервис проверки кода. Что умеет: * Анализ кода и поиск ошибок в популярных языках программирования * Отчёты об ошибках * Интегрируется с IDE (VSCode и т. п.) и репозиториями (Gitlab), встраивается в пайплайны (GitLab, Jenkins) * История показателей качества кода, графики * Плагины для расширения набора функций Как происходит анализ: - //Сканеры (analyzers)// определяют, на чём написан код и отправляют его на сервер - //Правила (rules)// на сервере проверяют проект. Есть предустановленные, но можно сделать свои под специфику проекта. Правила сгруппированы к //профили качества (quality profiles)// - это наборы правил. Можно добавить свои профили, добавив туда нужные правила - К проекту применяется профиль качества и выставляется //уровень качества (quality gate)//, из которого можно понять, можно выпускать релиз или нет. Уровень качества можно задать под свои требования, например, чтобы повторяющихся строк было не более 15% - По результатам анализа высылается письмо или webhook [[https://about.gitlab.com/devops-tools/sonarqube-vs-gitlab/|Sonarcube VS GitLab]]\\ [[https://docs.gitlab.com/ee/user/application_security/sast/|SAST]]\\ [[https://docs.sonarqube.org/latest/analysis/gitlab-integration/|Настройка DonarQube для Maven]]\\ [[https://sonarcloud.io/explore/projects|Открытый SonarQube]] ===== Инфраструктура как код (IAC) ===== Инфраструктура как код (IAC, IAaC от англ. Infrastructure as a Code) — подход к управлению и описанию инфраструктуры через конфигурационные файлы, а не через ручное редактирование конфигураций на серверах. Процесс настройки инфраструктуры становится аналогичен процессу программирования ПО. Границы между написанием приложений и созданием сред для этих приложений стираются. Используя IAC мы получаем много преимуществ: * Нет ручной настройки * Настройка (создание) инфраструктуры занимает гораздо меньше времени * Масштабируемость: один человек может управлять огромным количеством машин * Возможность использовать git для отслеживания изменений в инфраструктуре * Воспроизводимость: инфраструктура, поднятая с помощью скриптов всегда будет одинаковой * Ценность элемента инфраструктуры падает: проще поднять новую, чем восстанавливать старую https://martinfowler.com/bliki/SnowflakeServer.html Vagrant для гипервизора (на сентябрь 2022 закрыт для РФ). * Сервера-снежинки - каждый сервер уникален, т. к. его долгое время настраивали руками, и в случае чего поднять такой же невозможно. "Дрифт конфигурации". * Сервера-фениксы - сервер развёртывается из конфигурационного файла, что позволяет его развёртывать и масштабировать очень быстро. Kief Morris - Infrastructure as code ==== Terraform - управление инфраструктурой ==== :!: Свободный аналог - Opentofu. https://opentofu.org/, https://github.com/opentofu/opentofu. Скачать: https://hashicorp-releases.yandexcloud.net/terraform/ export PATH=$PATH:/path/to/terraform/executable Файл для скачивания доп. компонентов с серверов Яндекса вместо родного сайта. provider_installation { network_mirror { url = "https://terraform-mirror.yandexcloud.net/" include = ["registry.terraform.io/*/*"] } direct { exclude = ["registry.terraform.io/*/*"] } } Далее нужно [[https://cloud.yandex.ru/docs/tutorials/infrastructure-management/terraform-quickstart#configure-provider|настроить провайдер]] (провайдер - с чем работаем: AWS, Linode, K8s и т. д.). # Справка terraform --help terraform apply --help terraform fmt # форматирование файлов Terraform в текущем каталоге terraform init # подготовка необходимого для работы в текущем каталоге (установка провайдеров, указанных в конфигурации) terraform validate # проверка файлов Terraform на синтаксические ошибки terraform plan # вывод плана изменений terraform apply # применение изменений конфигурации инфраструктуры terraform destroy # удаление инфраструктуры, описанной в текущем каталоге terraform output # вывод значений переменных состояния terraform show # текущее состояние инфраструктуры terraform state # манипуляции с файлами состояния terraform version # версия Terraform # Шаги при работе с Terraform terraform init → terraform validate → terraform plan → terraform apply → terraform destroy [[https://medium.com/codex/terraform-best-practices-how-to-structure-your-terraform-projects-b5b050eab554|Terraform best practices — how to structure your Terraform projects]] ==== Управление конфигурацией ==== Системы управления конфигурацией (SCM) появились из необходимости автоматизации процесса конфигурации серверов. Это контроль и отслеживание изменений в системе: версий установленных пакетов, файлов конфигурации, настроек ОС. По аналогии с программным кодом такую конфигурацию можно хранить в git и управлять этой конфигурацией по процессам разработки (pull requests, сode review, тестирование). Задачи SCM (software configuration management): * определение, что является изменением, влияющим на продукт, а что нет * предоставление информации, кто и когда сделал изменение * быстрое и удобное применение определённой версии рабочей конфигурации Вместо скриптов и консольных команд, с которыми возникают проблемы при их применении на большом количестве серверов, есть инструменты, такие как Ansible, [[https://puppet.com/docs/|Puppet]], [[https://docs.chef.io/|Chef]], SaltStack. Задачи SCM (software configuration management): * определение, что является изменением, влияющим на продукт, а что нет * предоставление информации, кто и когда сделал изменение * быстрое и удобное применение определённой версии рабочей конфигурации | ^ Ansible ^ Puppet ^ Chef ^ SaltStack ^ ^Язык |Python, любой для модулей |Ruby |Ruby, Erlang |Python, ZeroMQ | ^Манифест |yaml |свой формат |Ruby DSL |yaml | ^Агенты |нет (SSH/WinRM) |требуется |требуется |требуется, но есть возможность работать по SSH | ^Инфраструктура |простая |сложная |средняя |средняя | ^Популярность |большая |средняя |средняя |низкая | ^Сложность освоения |невысокая |средняя |средняя |средняя | [[https://habr.com/en/post/343644/|Введение в системы управления конфигурацией]] ===== CI/CD ===== **Continuous integration (CI):**\\ Build [auto]-> Unit tests [auto]→ Deploy (stage) [auto]→ Acceptance tests **Continuous Delivery (CD):**\\ Build [auto]-> Unit tests [auto]→ Deploy (stage) [auto]→ Acceptance tests [manual]→ Deploy (prod) **Continuous Deployment (CD):**\\ Build [auto]-> Unit tests [auto]→ Deploy (stage) [auto]→ Acceptance tests [auto]→ Deploy (prod) ===== SaaS ===== Software as a Service - приложение как сервис, находящееся в облаке. 12 факторов, как построить приложение SaaS-friendly (Twelve-factor app) - База кода - одно приложение - один репозиторий. Разрабы могут создавать ветки (не репозитории) и деплоить на тестовые стенды. Приложение не собирается из нескольких репозиториев одновременно, но если нужно несколько, то они указываются как зависимости. - Зависимости - они все должны быть прописаны, не надо надеяться, что они установлены по умолчанию. Версии тоже надо прописывать. Изоляция, чтобы избежать конфлоктов версий - virtualenv в питоне и контейнеры. - Конфигурация - переменные для подключения ко внешним сервисам нужно хранить в конфигах, внешние подключения определяются в переменных. - Сторонние службы - любые изменения, касающиеся сторонних служб, должны происходить без изменения кода приложения. Например, изменение хоста для подключения к внешней БД. - Сборка, релиз, выполнение - любое изменение в коде должно пройти эти этапы (сборка - создание артефакта, релиз - соединение с конфигурацией под среду запуска, выполнение - запуск и работа в целевой среде). Релизы нужно помечать версией для простого отката в прошлой версии в случае чего. - Процессы - так как приложение может быть в любой момент масштабировано, перезапущено и т. п., любая stateful-информация должна храниться вовне - s3, БД и так далее. - Привязка портов - каждое приложение должно иметь собственный порт для связи с ним. - Параллелизм - приложение должно уметь масштабироваться не только вертикально (добавлением ресурсов), но и горизонтально (запуском нескольких копий). - Утилизируемость - приложение по-максимуму независимо от состояния (stateless), если оно что-то кэширует, то на минимальное время. Завершается по SIGTERM, быстро и без проблем. - Минимальная разница тест/прод - если все тесты завершены успешно, новый код может быть разлит на прод через минимальное время. Разрабы имеют доступ к проду, видят результаты работы. Стенды теста и прода должны быть максимально одинаковыми. - Логи - пишутся в stdout, а не в файл, т. к. в облаках обработкой логов будет заниматься внешний сервис. - Администрирование - возможность подключения к работающему приложению и запуска скриптов, которые должны иметь возможность использования переменных окружения. https://12factor.net/ru/\\ https://www.redhat.com/architect/12-factor-app