Статья DevSecOps. DevOps (ч.1)

Доброго времени суток.
SDLC
Продолжение статьи про DevSecOps.
Код проекта специально представлен в виде скриншотов, так как код не имеет значения в этой статье.
Кроме того, в этой статье будет рассмотрен только этап создания Pipeline, а IaC будет рассмотрен дальше.

Любой бизнес построен на одной цели - удовлетворение конечного пользователя. Если посмотреть на флоу из предыдущей главы, то можно заметить, что он занимает довольно много времени. И это особенно заметно, когда наступает время апдейтов и/или хотфиксов.
Рассмотрим ситуацию с хотфиксом:

1. Программист целый день пытался понять как же ему поправить баг, чтобы при этом еще и ничего не сломать. Но решение пришло только поздним вечером. Вот он все поправил, залил на офис, но дальше дело не двигается, т.к. инженер по развертыванию по ночам не работает.
2. Наступает утро инженер развертывает фикс на тестовом стенде, но тестировщик занят проверкой другого фикса и за этот возьмется только завтра.
3. На следующий день тестировщик начинает проверки и выясняет, что код ломает старую функциональность.
4. История повторяется…
5. Так до тех пор, пока продукт не будет готов.
6. Конкуренты уже выпустили эту фичу без багов.

Это утрированный пример. В реальной жизни у багов есть приоритеты, да и переработки в заказной разработке никто не отменял, но думаю суть ясна. Иногда компании совершают ошибочные шаги и переходят к количеству, вместо качества, т.е. проводят расширение команды. Но без поставленного процесса это не приведет ни к чему.
Помочь может методология DevOps. Это набор практик, нацеленных на активное взаимодействие специалистов по разработке со специалистами по тестированию и развертыванию для взаимной интеграции их рабочих процессов друг с другом.
Рассмотрим что нужно для внедрения DevOps.

1. CI/CD платформа (Jenkins, Gitlab CI, Circle CI)
2. Разработчикам желательно иметь Unit-тесты
3. Тестировщики ДОЛЖНЫ иметь автотесты
4. Инженер по развертыванию имеет скрипты для развертывания.

Для примера возьмем Gitlab CI и рассмотрим весь путь по интегрированию DevOps в процесс разработки.

Gitlab CI​

Gitlab предоставляет отличные возможности по CI/CD, причем совершенно бесплатно. Для этого нужен лишь репозиторий и роль Maintainer или Owner.
Важным понятием в процессе CI/CD является понятие pipeline. Это конвейер, в котором настраиваются определенные операции для автоматического исполнения.
Следующим важным понятием является runner. Это двигатель конвейера.
Приступим к настройке.
Репозиторий есть -

Чтобы включить в нем конвейер, нужно установить runner. Инструкцию по установке

Ссылка скрыта от гостей

.
Если лень читать, то вот инструкция по установке и конфигурации runner-а в docker.

1. Создаем специальный том gitlab-runner-config:

docker volume create gitlab-runner-config

1. Запускаем и конфигурируем runner:

docker run -d --name gitlab-runner --restart always -v /var/run/docker.sock:/var/run/docker.sock -v gitlab-runner-config:/etc/gitlab-runner gitlab/gitlab-runner:latest

1. Регистрируем наш runner
   1. docker run --rm -it -v gitlab-runner-config:/etc/gitlab-runner gitlab/gitlab-runner:latest register
   2. Переходим в Settings > CI/CD > Runners
   3. Вводим URL и Token

Часть полей не обязательна

Так же лучше задать tag, чтобы обращаться к вашему runner-у было проще.
Runner Executor можно выбрать docker - универсально
И последнее нужно выбрать базовый образ для докер контейнера (можно любой, например alpine, но тут ubuntu:latest)
Если все сделано правильно, то созданный runner становится видно

Итак, runner готов. Для его использования нужно написать gitlab-ci файл, который представляет собой yml файл с инструкциями.
Пример gitlab-ci.yml файла:

build-job:
  stage: build
  script:
    - echo "Hello, $GITLAB_USER_LOGIN!"

test-job1:
  stage: test
  script:
    - echo "This job tests something"

test-job2:
  stage: test
  script:
    - echo "This job tests something, but takes more time than test-job1."
    - echo "After the echo commands complete, it runs the sleep command for 20 seconds"
    - echo "which simulates a test that runs 20 seconds longer than test-job1"
    - sleep 20

deploy-prod:
  stage: deploy
  script:
    - echo "This job deploys something from the $CI_COMMIT_BRANCH branch."

Результат запуска pipeline из документации

Шаблон есть, можно его менять по своему усмотрению.

Unit-тесты​

Хорошей, но не обязательной практикой является ведение разработчиками unit-тестов. Суть unit-тестов в том, чтобы проверить правильность работы функций в коде. Как писать unit-тесты я в этой статье описывать не буду, каждый точит, как он хочет.
Напишем код, в котором будет функция, которая складывает два числа.

И напишем для нее unit-тест.

Отредактируем gitlab-ci.yml

После заливки изменений выполняется pipeline и изменение вступает в силу

Если тест провалился, то и заливка на deploy-prod не проходит

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

Автотесты​

Автотесты, в отличие от unit-тестов, это программа минимум. Хотя я настоятельно не рекомендую пропускать шаг с юнитами, без них все же можно и обойтись. Но вот без автотестов, сама идея DevOps теряет свой смысл. Ведь если тестировщикам придется все тестировать руками при каждом обновлении, то разницы не будет.
В этой главе напишем автотесты на pytest, которые проверяют только доступность некоторого ресурса. В данном случае не нашего, но суть такая же.
test1.py

Изменим gitlab-ci, чтобы использовать новые тесты

Теперь у нас “готово” два шага из 3-х, которые улучшают жизнь.

Скрипты для развертывания​

В этом примере для развертывания используется бесплатный сервер AWS EC2. О том как его получить и настроить можно почитать в интернете или посмотреть видео на ютубе.
Для тех, кому лень:

1. Заходим на
   Ссылка скрыта от гостей
2. Выбираем EC2
   
3. Launch instance

4. Заполняем имя

5. Application and OS Images (Amazon Machine Image). Выбираем подходящий образ. В моем случае я выбрал - Ubuntu.

6. Key pair (login). Обязательный ключ для подключения к машине. Если есть выберете, если нет - сгенерируйте. Если генерируете, и не потеряйте ключ, иначе вы потеряете все машины, в которых выбрали этот ключ.

7. Network settings. Здесь нужно выбрать параметры безопасности. То есть открыть порты для подключения. Можете настроить прямо здесь, а можете создать правила заранее.

8. Advanced details. Можно не трогать.
9. Summary. Проверяем, что все верно и “Launch Instance”

Shell runner​

Чтобы нам использовать docker в нашем gitlab CI, необходимо установить Gitlab runner, но в executor выбрать shell. По умолчанию выбирается bash. И если runner ставится на Ubuntu, как у меня в AWS, то это нам подходит. Инструкцию по установке :

# Скачиваем бинарный файл

sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64



# Даем разрешения на исполнение

sudo chmod +x /usr/local/bin/gitlab-runner



# Создаем пользователя Gitlab Runner

sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash



# Устанавливаем и запускаем как сервис

sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner

sudo gitlab-runner start

# Регистрируем

sudo gitlab-runner register --url https://gitlab.com/ --registration-token $REGISTRATION_TOKEN

Теперь изменим в gitlab-ci.yml stage : deploy

Если все успешно, то по адресу машины мы должны увидеть то, что выводит наш скрипт

Как видите ничего сложного. Конечно бывают различного рода задачи, для которых нужно подумать, но если вы можете их решить без DevOps, то и с внедрением CI сможете.