Различия

Показаны различия между двумя версиями страницы.

--- learning:devops [27.02.2023 13:50] – [Terraform - управление инфраструктурой] viacheslav
+++ learning:devops [30.07.2024 19:21] (текущий) – внешнее изменение 127.0.0.1
@@ Строка 1: / Строка 1: @@
+====== 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/
+<code bash>
+export PATH=$PATH:/path/to/terraform/executable
+</code>
+Файл для скачивания доп. компонентов с серверов Яндекса вместо родного сайта.
+<file yaml ~/.terraformrc>
+provider_installation {
+  network_mirror {
+    url = "https://terraform-mirror.yandexcloud.net/"
+    include = ["registry.terraform.io/*/*"]
+  }
+  direct {
+    exclude = ["registry.terraform.io/*/*"]
+  }
+}
+</file>
+Далее нужно [[https://cloud.yandex.ru/docs/tutorials/infrastructure-management/terraform-quickstart#configure-provider|настроить провайдер]] (провайдер - с чем работаем: AWS, Linode, K8s и т. д.).
+<code bash>
+# Справка
+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
+</code>
+[[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 [<color #22b14c>auto</color>]-> Unit tests [<color #22b14c>auto</color>]→ Deploy (stage) [<color #22b14c>auto</color>]→ Acceptance tests
+**Continuous Delivery (CD):**\\
+Build [<color #22b14c>auto</color>]-> Unit tests [<color #22b14c>auto</color>]→ Deploy (stage) [<color #22b14c>auto</color>]→ Acceptance tests [<color #ed1c24>manual</color>]→ Deploy (prod)
+**Continuous Deployment (CD):**\\
+Build [<color #22b14c>auto</color>]-> Unit tests [<color #22b14c>auto</color>]→ Deploy (stage) [<color #22b14c>auto</color>]→ Acceptance tests [<color #22b14c>auto</color>]→ Deploy (prod)
+===== SaaS =====
+Software as a Service - приложение как сервис, находящееся в облаке.
+факторов, как построить приложение SaaS-friendly (Twelve-factor app)
+  - База кода - одно приложение - один репозиторий. Разрабы могут создавать ветки (не репозитории) и деплоить на тестовые стенды. Приложение не собирается из нескольких репозиториев одновременно, но если нужно несколько, то они указываются как зависимости.
+  - Зависимости - они все должны быть прописаны, не надо надеяться, что они установлены по умолчанию. Версии тоже надо прописывать. Изоляция, чтобы избежать конфлоктов версий - virtualenv в питоне и контейнеры.
+  - Конфигурация - переменные для подключения ко внешним сервисам нужно хранить в конфигах, внешние подключения определяются в переменных.
+  - Сторонние службы - любые изменения, касающиеся сторонних служб, должны происходить без изменения кода приложения. Например, изменение хоста для подключения к внешней БД.
+  - Сборка, релиз, выполнение - любое изменение в коде должно пройти эти этапы (сборка - создание артефакта, релиз - соединение с конфигурацией под среду запуска, выполнение - запуск и работа в целевой среде). Релизы нужно помечать версией для простого отката в прошлой версии в случае чего.
+  - Процессы - так как приложение может быть в любой момент масштабировано, перезапущено и т. п., любая stateful-информация должна храниться вовне - s3, БД и так далее.
+  - Привязка портов - каждое приложение должно иметь собственный порт для связи с ним.
+  - Параллелизм - приложение должно уметь масштабироваться не только вертикально (добавлением ресурсов), но и горизонтально (запуском нескольких копий).
+  - Утилизируемость - приложение по-максимуму независимо от состояния (stateless), если оно что-то кэширует, то на минимальное время. Завершается по SIGTERM, быстро и без проблем.
+  - Минимальная разница тест/прод - если все тесты завершены успешно, новый код может быть разлит на прод через минимальное время. Разрабы имеют доступ к проду, видят результаты работы. Стенды теста и прода должны быть максимально одинаковыми.
+  - Логи - пишутся в stdout, а не в файл, т. к. в облаках обработкой логов будет заниматься внешний сервис.
+  - Администрирование - возможность подключения к работающему приложению и запуска скриптов, которые должны иметь возможность использования переменных окружения.
+https://12factor.net/ru/\\
+https://www.redhat.com/architect/12-factor-app