Dmitry
de388b14ea
Affected files: .obsidian/app.json .obsidian/appearance.json .obsidian/core-plugins.json .obsidian/plugins/obsidian-style-settings/data.json 00 Inbox/Без названия.md
181 lines
11 KiB
Markdown
181 lines
11 KiB
Markdown
---
|
||
status: seed
|
||
type: concept
|
||
tags: []
|
||
created: 2025-12-17
|
||
updated: 2026-02-27
|
||
aliases: []
|
||
---
|
||
## Часть 2. Пайплайны в GitlabCI
|
||
|
||
Пайплайны в GitlabCI строятся на основе языков Shell и Yaml.
|
||
|
||
С помощью них можно описывать этапы процессов CI/CD и их желаемое поведение.
|
||
|
||
Язык Yaml позволяет описывать конфигурацию этапов в декларативном ключе.
|
||
|
||
Основной файл, в котором описывается работа пайплайна, носит название Gitlab-ci.yml.
|
||
|
||
**Shell:**
|
||
|
||
В GitlabCI при описании этапов пайплайна можно задействовать Shell.
|
||
|
||
**Shell** — командный интерпретатор операционных систем семейства Unix.
|
||
|
||
Shell позволяет существенно расширить возможности описания процессов CI/CD.
|
||
|
||
**Stage:**
|
||
|
||
Структура файла Gitlab-ci.yml предполагает разбиение пайплайна на этапы (Stages).
|
||
|
||
Каждый Stage представляет из себя этап пайплайна с полным описанием его работы.
|
||
|
||
Этапы (Stages) могут выполняться последовательно или параллельно.
|
||
|
||
Так могут выглядеть типовые этапы (Stages) в пайплайне GitlabCI.
|
||
|
||
stages:
|
||
- build - test
|
||
- deploy
|
||
|
||
build-job:
|
||
stage: build
|
||
script:
|
||
- do some build
|
||
|
||
test-job:
|
||
stage: test
|
||
script:
|
||
- do some test
|
||
|
||
deploy-job:
|
||
stage: deploy
|
||
script:
|
||
- do some deploy
|
||
|
||
**Запуск пайплайна можно инициировать тремя способами:**
|
||
|
||
- Вручную (через веб-интерфейс или API).
|
||
- Автоматически по событию (Push, Commit, Merge-request, etc).
|
||
- Используя Web-hook.
|
||
|
||
**Как ручной, так и автоматический запуск пайплайнов может быть** **дополнительно параметризован при запуске:**
|
||
|
||
- Указание специфических переменных.
|
||
- Выбор учетных данных (Credentials).
|
||
- Сборка по конкретному коммиту, ветке, тэгу.
|
||
- .. и многое другое
|
||
|
||
**Вложенные пайплайны:**
|
||
|
||
В зависимости от сложности процессов CI/CD, пайплайны могут быть составными — содержать вложенные пайплайны, выполняющиеся последовательно или параллельно.
|
||
|
||
**Интеграция:**
|
||
|
||
В случае использования в процессах CI/CD нескольких инструментов, возможна их интеграция (к примеру, исходный код хранится в gitlab, а пайплайны запускаются в Jenkins) через встроенный в GitlabCI механизм интеграций.
|
||
|
||
**GitlabCI имеет понятный веб интерфейс, в котором отображаются** **результаты прохождения пайплайнов и их отдельных этапов** **в простом и доступном виде:**
|
||
|
||
|
||
|
||
## Часть 3. Пайплайны в Jenkins
|
||
|
||
Для полноценной работы Jenkins будет достаточно предустановленных плагинов, но наличие минимально необходимых дополнительных плагинов существенно **облегчит** построение и модификацию пайплайнов.
|
||
|
||
|
||
|
||
Не забывайте своевременно производить обновление используемых плагинов, чтобы избежать ошибок и уязвимостей.
|
||
|
||
|
||
|
||
После установки плагина, его требуется настроить для работы, сделать это можно в настройках Jenkins:
|
||
|
||
- Глобальные настройки.
|
||
- Настройки инструментов.
|
||
- Настройки безопасности.
|
||
- Конфигурирование сред исполнения.
|
||
|
||
|
||
|
||
Настройки проекта в Jenkins сводятся к конфигурации самого проекта и его интеграций, а также настройке пайплайна.
|
||
|
||
Для описания поведения пайплайна мы можем использовать графический интерфейс или язык **Groovy**.
|
||
|
||
|
||
|
||
Если вы испытываете трудности с языком Groovy — вам придет на помощь встроенный редактор запросов.
|
||
|
||
Сгенерированный запрос можно использовать в описании вашего пайплайна.
|
||
|
||
|
||
|
||
Хорошей практикой является описание пайплайна в отдельном файле, который хранится не в Jenkins и подвергается защите от несанкционированного внесения изменений.
|
||
|
||
Такой файл часто носит название Jenkinsfile и хранится в репозитории (например, в Gitlab), а не в самом Jenkins.
|
||
|
||
|
||
|
||
Хранящийся в репозитории Jenkinsfile, вместе с самим исходным кодом продукта, защищен от изменений (их могут вносить только уполномоченные члены команды или с использованием процедуры Merge-request).
|
||
|
||
|
||
|
||
Инициировать процедуру запуска пайплайна можно несколькими способами:
|
||
|
||
- Вручную (веб-интерфейс или API).
|
||
- Автоматически, с использованием интеграций (посредством плагинов).
|
||
- Используя Web-hook.
|
||
- С помощью планировщика сборок.
|
||
|
||
|
||
|
||
Имея опыт работы с языком **Groovy**, используя разнообразные плагины и следуя хорошим практикам организации пайплайнов, можно добиться грамотного построения процессов CI/CD:
|
||
|
||
- Параметризованные сборки.
|
||
- Хранение Jenkinsfile в репозитории с ограничением на изменение.
|
||
- Интеграция с Git, Kubernetes, Инструментами обеспечения информационной безопасности и Observability.
|
||
- Отказоустойчивая и безопасная конфигурация доступа к Jenkins для других инструментов.
|
||
- Визуализация процессов.
|
||
|
||
## Часть 4. Внедрение и развитие процессов CI/CD
|
||
|
||
## Внедрение и развитие процессов CI/CD
|
||
|
||
В зависимости от того, в каком состоянии находятся существующие процессы разработки, тестирования и администрирования, процессы CI/CD должны внедряться предсказуемо и поэтапно.
|
||
|
||
Любые существующие процессы CI/CD должны развиваться не прекращаясь.
|
||
|
||
**Обогатить имеющиеся процессы непрерывной сборки и доставки** **можно следующими практиками:**
|
||
|
||
- IaC.
|
||
- Orchestration.
|
||
- Observability.
|
||
- Info-security.
|
||
|
||
При настройке процессов непрерывной доставки используйте подход декларативного описания инфраструктуры и конфигурации в виде кода (практики IaC).
|
||
|
||
Старайтесь придерживаться микросервисной архитектуры там, где это оправдано.
|
||
|
||
Ориентируйтесь на контейнерные технологии.
|
||
|
||
Изучайте и применяйте технологии оркестрации контейнерных и неконтейнерных рабочих нагрузок в режиме кластера.
|
||
|
||
**Не пренебрегайте развитием практик обеспечения Observability:**
|
||
|
||
- Мониторинг.
|
||
- Трассировки.
|
||
- Аудит.
|
||
- Журналирование.
|
||
- Обработка логов.
|
||
- Сбор обратной связи.
|
||
|
||
Дополняйте этими практиками этапы своих пайплайнов, или добавляйте новые этапы на их основе.
|
||
|
||
**Существующие практики CI/CD можно и нужно обогащать** **внедрением проверок по информационной безопасности из** **методологии Devsecops:**
|
||
|
||
- Различные виды анализа (SAST, SCA, DAST, IAST, RASP).
|
||
- Сканирование инфраструктуры.
|
||
- Использование профильных инструментов для работы с сенсетивной информацией.
|
||
|
||
Помните о том, что процессы CI/CD — это лишь одна из множества Devops-практик, которые важно и нужно применять для создания благоприятной атмосферы в коллективной работе над цифровым продуктом.
|
||
|
||
**Devops** — это, в первую очередь, культура взаимодействия всех участников жизненного цикла цифрового продукта. |