В TestProject мы стремимся использовать самую актуальную лучшие практики, а также в рамках обновления для некоторых компонентов и рабочих процессов в нашей инфраструктуре, мы частично переходит к Дженкинс X . Отсутствует полезный материал, доступный по настройке Jenkins X без сервера, поэтому в рамках нашей уверенности в том, чтобы делиться и отдавать сообществу, мы решили создать полномасштабное пошаговое руководство по этому вопросу!
Внедорожная интеграция Jenkins X и Kubernetes решает следующие проблемы:
- Поддержка выделенных серверов для различных компонентов, задействованных в CI / CD, таких как: серверы сборки, среды тестирования, оркестровка серверов и т. Д.
- Автоматическое развертывание параллельных сред сборки и тестирования по требованию, позволяющее тестировщикам и разработчикам параллельно выпускать и тестировать выделенные функции.
- Естественно интегрируется с потоками разработки и выпуска микросервисов.
В этом пошаговом руководстве мы собираемся создать решение CI / CD для современного облачного приложения на основе микросервисов с Jenkins X.
Jenkins X — это CI / CD-решение для современных облачных приложений в Kubernetes . Это помогает нам создавать отличные конвейеры для наших проектов и реализовывать полный CI и CD.
Непрерывная интеграция (CI) — это методология разработки программного обеспечения для автоматизации интеграции изменений кода от нескольких участников в один программный проект. Непрерывное развертывание (CD) — это методология разработки программного обеспечения, благодаря которой программное обеспечение автоматически, быстро и безопасно развертывается в производственной среде.
Вам также может понравиться: Все, что вам нужно знать о Jenkins X
Jenkins X автоматизирует управление средами и продвижение новых версий приложений между средами через GitOps.
GitOps — это методология разработки программного обеспечения для управления кластерами Kubernetes и доставки приложений. Следуя этой методологии, Git является единственным источником правды как для инфраструктуры в виде кода, так и для кода приложения. Все изменения в желаемом состоянии выполняются Git коммитами.
Jenkins X автоматически раскручивает среды предварительного просмотра для наших запросов извлечения, поэтому мы можем получить быструю обратную связь, прежде чем изменения будут объединены с master.
Давайте начнем!
Для целей данного руководства мы создали простой демонстрационный проект с микросервисным дизайном, который будет развернут в Kubernetes. Наш демонстрационный проект состоит из 3 основных сервисов: фронтенд-приложения и 2 бэкэнд-сервисов.
Наш демонстрационный проект отображает текущую версию серверных сервисов и свою собственную. Это будет полезно для иллюстрации и тестирования конвейера CI / CD, который мы создаем позже.
Наши сервисы для демонстрационных проектов написаны на Python и упакованы в контейнер Docker на основе образа Alpine. Изображение ниже иллюстрирует наш демонстрационный проект:
К концу этого урока у нас будет работающее решение CI / CD , которое позволит нам разрабатывать, тестировать и доставлять наше приложение быстрым и надежным способом.
Jenkins X Безсерверная архитектура
Перед тем, как мы начнем практическую часть руководства, мы должны охватить основные компоненты безсерверной инфраструктуры Jenkins X. Изображение ниже иллюстрирует эти компоненты:
Давайте рассмотрим немного больше:
- Kubernetes — ядро разработки наших облачных приложений, где мы создаем, тестируем и разворачиваем наши приложения.
- Реестр образов Docker — Здесь мы храним наши изображения Docker после их создания. Небольшое замечание: Jenkins X по умолчанию использует реестр Docker вашего облачного провайдера, но его можно настроить на использование другого частного реестра.
- Git — Здесь мы сохраняем наш код — исходный код приложения, конфигурацию системы и состояние системы.
- Музей карт — где мы храним наши карты Хелма.
- Testing Framework — где мы тестируем изменения нашего приложения, мы используем TestProject (это бесплатно).
- Канико — строит наши контейнеры Docker.
- Скаффолд — Размещает наши контейнеры Docker в Kubernetes.
- Черновик — Создает наши диаграммы Helm для развертывания наших приложений.
- Тектон — это то, что управляет нашими трубопроводами.
- Jenkins X — организует процесс CI / CD.
Установка и настройка Jenkins X без сервера
Теперь мы установим Jenkins X и будем использовать Google Cloud в качестве нашего облачного провайдера, но процесс установки очень похож на другие облака.
Предпосылки
- Облачный аккаунт Google (если у вас его еще нет, вы можете создать его здесь ).
- Аккаунт Github (если у вас его еще нет, вы можете создать его здесь ).
Установите Jenkins X на Google Kubernetes Engine (GKE)
- Войдите в свой облачный аккаунт Google.
- Перейти к вашей консоли (кнопка консоли в правом верхнем углу).
- Перейдите к облачной оболочке (кнопка [> _] на верхней синей полосе справа).
- Выполните следующие команды для установки jx:
Оболочка
1
mkdir -p ~/.jx/bin
2
curl -L "https://github.com/jenkins-x/jx/releases/download/$(curl --silent "https://github.com/jenkins-x/jx/releases/latest" | sed 's#.*tag/\(.*\)\".*#\1#')/jx-linux-amd64.tar.gz" | tar xzv -C ~/.jx/bin
3
export PATH=$PATH:~/.jx/bin
4
echo 'export PATH=$PATH:~/.jx/bin' >> ~/.bashrc
5. Запустите следующую команду, чтобы:
- Разверните новый кластер Kubernetes, настроенный для Jenkins X.
- Разверните серверные компоненты Jenkins X:
Оболочка
xxxxxxxxxx
1
jx create cluster gke --skip-login --git-public
6. Теперь вам будет задан ряд вопросов, которые будут настраивать установку:
- С каким проектом связать ваш кластер. Выберите «Мой первый проект», если вы новый пользователь облака Google, или выберите тот, который вам нужен.
- Где развернуть свой кластер, географический регион. Выберите ближайший к вам.
- Тип машины, если у вас нет опыта, просто выберите значение по умолчанию.
- Количество узлов для развертывания, так же, как и выше, вы можете перейти со значениями по умолчанию.
- Тип развертывания Jenkins X, который вы хотите, выберите Serverless Jenkins X с Tekton Pipelines.
- Вам будет задан вопрос, хотите ли вы создать балансировщик нагрузки, согласитесь с этим, иначе вы не сможете работать.
- Вас спросят, хотите ли вы использовать nip.io в качестве своего волшебного DNS. Согласитесь с этим.
- Не забывайте, что установка создаст несколько репозиториев в вашей учетной записи Github и запросит разрешения администратора, мы настоятельно рекомендуем создать новую учетную запись для целей учебника. Вам будут задаваться всевозможные вопросы о вашей учетной записи Github, отвечайте соответственно, не используйте свою электронную почту в качестве имени учетной записи, это может создать проблемы на более поздних этапах, используйте псевдоним, который вы выбрали для учетной записи.
- Установка начнется, и когда она будет завершена, вам будут представлены полезные ссылки и пароль для ваших служб, связанных с Jenkins X. Не забудьте сохранить его где-нибудь для будущего использования.
Это оно! Вы готовы начать.
Импортируйте существующий проект в Jenkins X
В этой части мы узнаем, как импортировать существующий проект в Jenkins X.
Различные среды, созданные по умолчанию Jenkins X
Прежде чем импортировать ваш проект в Jenkins X, нам нужно понять, какие существуют разные среды, созданные по умолчанию в Jenkins X. По умолчанию Jenkins X создает следующие среды:
- jx environment — в этой среде мы выполняем сборку и модульное тестирование.
- Промежуточная среда. В этой среде мы проводим интеграционное тестирование.
- Производственная среда — наш окончательный выпуск продукции.
- Среды предварительного просмотра — Среды для тестирования.
Шаг 1 — Создайте новый репозиторий
Первое, что вам нужно сделать, — это создать репозиторий с исходным кодом вашего проекта, а затем клонировать его в среду разработки.
В этой главе руководства мы будем использовать демонстрационный проект Backend1 в качестве примера. Вы должны разветвить основной репозиторий учебника и выполнить следующие команды, чтобы клонировать его в вашу среду разработки:
Оболочка
1
GIT_USER=[...]
2
PROJECT_NAME=[...]
3
git clone https://github.com/$GIT_USER/$PROJECT_NAME
4
cd $PROJECT_NAME/backend1
Теперь у вас есть новый репозиторий для работы, но у вас все еще нет всех необходимых файлов для работы с Jenkins X.
Шаг 2 — Добавьте необходимые файлы для Jenkins X
Чтобы добавить необходимые файлы для Jenkins X, первое, что вам нужно сделать, это импортировать проект. Команда ниже импортирует проект. Перед выполнением этой команды убедитесь, что вы находитесь в домашнем каталоге проекта, который мы только что клонировали в среду разработки:
Оболочка
xxxxxxxxxx
1
jx import --batch-mode
В рамках процесса импорта по умолчанию Jenkins X изучит код и выберет правильный пакет сборки по умолчанию для проекта на основе языка программирования. Наш проект был разработан на Python, поэтому это будет сборочный пакет Python.
Вы можете просмотреть содержимое пакета сборки, посмотрев на:
Оболочка
xxxxxxxxxx
1
/.jx/draft/packs/github.com/jenkins-x-buildpacks/jenkins-x-kubernetes/python
Чтобы проверить ход импорта, выполните команду ниже:
Оболочка
xxxxxxxxxx
1
jx get activities --filter $PROJECT_NAME
Когда импорт будет успешно завершен, вы увидите, что все файлы, находящиеся в пакете сборки, теперь отображаются в репозитории проекта, различие в том, что некоторые из них раньше были шаблонами, а теперь они являются допустимыми файлами.
Подождите, что здесь произошло?
Давайте рассмотрим, что происходит за кулисами процесса импорта:
- Jenkins X выбрал правильный пакет сборки и отправил новые файлы в репозиторий проекта.
- Jenkins X создает проект Jenkins.
- Jenkins X создает webhook для запуска сборок всякий раз, когда происходит изменение кода в репозитории проекта.
- Jenkins X использует skaffold.yaml для создания образа контейнера.
- Дженкинс X использует рулевые карты для создания сборки и отправляет ее в музей карт .
- Jenkins X фиксирует изменения в хранилище промежуточной среды.
- Он добавляет новую версию сервиса как зависимость от среды.
- Это добавляет вход для нового сервиса.
- Jenkins X применяет изменения к кластеру Kubernetes , новый сервис развертывается Kubernetes в промежуточной среде.
- Jenkins X предоставляет нам URL-адрес новой службы.
- Мы можем взаимодействовать с нашим сервисом через HTTP.
Впечатляет, а?
Крутая вещь в этом процессе заключается в том, что все изменения отслеживаются в Git и их можно просмотреть, перейдя по ссылке:
Чтобы проверить, правильно ли была развернута служба в промежуточной среде, вы можете просмотреть службу по URL-адресу, который будет напечатан в консоли в конце процесса импорта. Например, в нашем демонстрационном проекте Backend1 следующий JSON должен появиться в вашем браузере после открытия предоставленного URL:
Оболочка
xxxxxxxxxx
1
{"name": "backend1", "version": "1"}
Вы можете видеть, что вы получаете название и версию сервиса, но как насчет модульного тестирования? Этот этап не включен в пакет сборки по умолчанию. Чтобы решить эту проблему, вам понадобится специальный сборочный пакет для Jenkins X.
Создание пользовательских пакетов сборки для Jenkins X
В этой части мы создадим пользовательский пакет сборки для Jenkins X и включим в него модульное тестирование.
Пакеты сборки определяют, как создавать, тестировать и доставлять ваш проект каждый раз, когда разработчик вносит изменения в исходный код вашего проекта. Jenkins X предоставляет базовые пакеты сборки, но в реальной жизни вам необходимо создать собственный пакет сборки для вашего проекта.
Рекомендуется хранить ваши пакеты сборки в центральном хранилище и делиться ими между разработчиками в вашей компании.
Чтобы создать пользовательский пакет сборки для учебного проекта, первое, что вам нужно сделать, — это разветвить официальный репозиторий с пакетами сборки сообщества . Затем клонируйте репозиторий в свою среду разработки с помощью следующих команд:
Оболочка
xxxxxxxxxx
1
GIT_USER=[...]
2
git clone https://github.com/$GIT_USER/jenkins-x-kubernetes
3
cd jenkins-x-kubernetes
Рекомендуется добавить вышестоящий репозиторий, чтобы получать будущие обновления из официального репозитория, чтобы оставаться в курсе. Для этого используйте следующую команду:
Оболочка
xxxxxxxxxx
1
git remote add upstream https://github.com/jenkins-x-buildpacks/jenkins-x-kubernetes
Далее, чтобы создать пользовательский пакет сборки, нам нужно создать ветку репозитория. Используйте следующие команды:
Оболочка
xxxxxxxxxx
1
git checkout -b tutorial-build-pack master
2
git push -u origin tutorial-build-pack
Выбор источника для пакетов сборки в Jenkins X
По умолчанию источник пакетов сборки находится в следующей папке:
Оболочка
xxxxxxxxxx
1
/.jx/draft/packs/github.com/jenkins-x-buildpacks/jenkins-x-kubernetes
Чтобы изменить источник, чтобы он указывал на ваш только что созданный репозиторий, выполните следующие команды:
Оболочка
xxxxxxxxxx
1
jx edit buildpack \
2
-u https://github.com/$GIT_USER/jenkins-x-kubernetes \
3
-r master \
4
-b
Отныне, когда вы импортируете новый проект, Jenkins X будет использовать пакеты сборки из вашего недавно созданного репозитория.
По умолчанию Jenkins X предоставляет пакеты сборки для популярных языков разработки. В качестве основы для нашего пользовательского пакета сборки мы будем использовать пакет сборки Python, поскольку наш проект написан на Python .
Скопируйте папку пакета сборки Python в папку с названием tutorial-build-pack. Для этого выполните следующую команду:
Оболочка
xxxxxxxxxx
1
cp -R packs/python packs/tutorial-build-pack
Теперь давайте посмотрим на файлы в новой папке пакета сборки, которую мы только что создали:
- Dockerfile — содержит сборку образа Docker .
- диаграммы — Содержит диаграммы Хелма и файлы Kubernetes, которые описывают, как развернуть проект в промежуточных и производственных средах.
- pipe.yaml — содержит шаги для сборки, тестирования и доставки проекта.
- Предварительный просмотр — содержит диаграммы Хелма и файлы Kubernetes, которые описывают, как развернуть проект в среде предварительного просмотра.
- skaffold.yaml — содержит шаги для создания и сохранения образа докера.
Добавление поддержки модульного тестирования как часть пользовательского пакета сборки в Jenkins X
Чтобы реализовать модульное тестирование в пользовательском пакете сборки, необходимо расширить базовый пакет сборки. Чтобы расширить пакет сборки, вам просто нужно изменить файл pipe.yaml, который находится в домашнем каталоге пакета сборки.
Допустим, вы хотите добавить скрипт, который запускает некоторые модульные тесты перед построением изображения. В качестве примера вы запустите эхо-команду «Запуск модульных тестов!». Но на самом деле вы должны запустить команду или скрипт, который будет запускать ваши тесты.
Теперь добавьте новый шаг в pipe.yaml, чтобы выполнить новый скрипт, прежде чем мы создадим наш сервис. Для этого используйте следующие команды:
Оболочка
xxxxxxxxxx
1
…
2
release:
3
build:
4
preSteps:
5
- sh: echo “Running unit tests!”
6
…
Новый файл должен выглядеть следующим образом: https://github.com/testproject-io/jenkinsx-tutorial/blob/master/build-pack-pipeline.yaml
Чтобы изменения вступили в силу, нам нужно зафиксировать наши изменения в пакете сборки. Однако вновь созданный пакет сборки не связан ни с одним проектом.
Для целей учебника, если вы уже разветвили и клонировали основной репозиторий учебника , пропустите следующий шаг и просто войдите в папку Backend2 внутри папки репозитория.
Если вы еще не клонировали основной репозиторий учебников, выполните следующие команды:
Оболочка
xxxxxxxxxx
1
GIT_USER=[...]
2
PROJECT_NAME=[...]
3
git clone https://github.com/$GIT_USER/$PROJECT_NAME
4
cd $PROJECT_NAME/backend2
Теперь у нас есть новый репозиторий для работы. Чтобы импортировать новый проект с созданным вами пакетом сборки, выполните следующую команду:
Оболочка
xxxxxxxxxx
1
jx import --pack tutorial-build-pack --batch-mode
Чтобы проверить, правильно ли была выполнена сборка с нашим новым модульным тестом, выполните следующую команду:
Оболочка
xxxxxxxxxx
1
jx get build logs
Congrats! Ваши юнит-тесты сейчас выполняются!
Интеграционное тестирование в Jenkins X
В этой части мы узнаем, как реализовать интеграционное тестирование для служб, которые мы развертываем с помощью Jenkins X.
Чтобы понять, где внедрять интеграционные тесты, необходимо понять их цель — убедиться, что все сервисы в нашей производственной среде будут правильно взаимодействовать друг с другом.
В Jenkins X вы можете иметь столько сред, сколько хотите, но теперь мы сосредоточимся на промежуточной среде, поскольку эта среда имитирует следующую версию, которая будет выпущена для производственной среды. Следовательно, если сервисы правильно взаимодействуют в промежуточной среде, мы можем предположить, что если они будут перенесены в производственную среду, они будут работать без сбоев.
Если вы следовали руководству с самого начала, у вас должна быть промежуточная среда, которая включает в себя: два рабочих сервиса, Backend1 и Backend2. Эти сервисы не взаимодействуют друг с другом, поэтому мы не можем провести реальное интеграционное тестирование, чтобы убедиться, что сервисы взаимодействуют правильно.
Чтобы сделать пример тестирования интеграции значимым, мы добавим интерфейсный сервис, который взаимодействует с обоими сервисами.
Для целей учебника, если вы уже разветвили и клонировали основной репозиторий учебника , пропустите следующий шаг и просто войдите в папку Frontend внутри папки репозитория.
Если вы еще не клонировали основной репозиторий учебников, выполните следующие команды:
Оболочка
xxxxxxxxxx
1
GIT_USER=[...]
2
PROJECT_NAME=[...]
3
git clone https://github.com/$GIT_USER/$PROJECT_NAME
4
cd $PROJECT_NAME/frontend
5
jx import --batch-mode
После успешного завершения импорта убедитесь, что 3 службы запущены и работают в промежуточной среде.
Чтобы убедиться, что 3 службы доступны, вы можете выполнить следующую команду:
Оболочка
xxxxxxxxxx
1
jx get applications
Как выполнить интеграционные тесты с TestProject через API
TestProject — это полностью автоматизированная платформа для автоматизации тестирования. Он построен на основе Selenium и Appium , поддерживает все основные операционные системы и позволяет каждому члену вашей команды разработчиков программного обеспечения без проблем взаимодействовать и тестировать веб-приложения, приложения для Android и iOS. TestProject идеально подходит для интеграционного тестирования в конвейере CI / CD, поскольку TestProject предоставляет RESTful API, который позволяет командам R & D планировать и запускать автоматизацию, получать статус и получать результаты тестирования. Кроме того, Агенты TestProject могут быть легко развернуты на различных платформах (как локальных, так и удаленных), включая док-версию Агента, которая может быть развернута без сервера, что позволяет проводить параллельное распределенное тестирование по требованию.
Давайте начнем!
- Создайте аккаунт TestProject здесь , это абсолютно БЕСПЛАТНО!
- Загрузите и зарегистрируйте TestProject Agent .
- Создайте свои интеграционные тесты. В этом примере мы будем использовать записанные тесты , но вы также можете использовать TestProject для разработки кодовых тестов Selenium и Appium также на C # или Java .
- Сгенерируйте свой ключ API с помощью TestProject, чтобы получить доступ к TestProject Platform из ваших инструментов CI / CD.
- Выполните задание по автоматизации тестирования в TestProject, используя их API .
- Например, вы можете использовать следующий скрипт Python для выполнения задания TestProject из инструмента CI / CD: https://github.com/testproject-io/jenkinsx-tutorial/blob/master/trigger-job.py
Теперь давайте реализуем наши интеграционные тесты! Первое, что вам нужно сделать, это клонировать репозиторий промежуточной среды в вашу среду разработки. Используйте следующие команды:
Оболочка
xxxxxxxxxx
1
CLUSTER_NAME=[...]
2
GIT_USER=[...]
3
git clone https://github.com/$GIT_USER/environment-$CLUSTER_NAME-staging
4
cd environment-$CLUSTER_NAME-staging
После клонирования репозитория в вашу среду разработки в папке домашнего каталога мы можем найти файл с именем jenkins-x.yaml. В этом файле описываются этапы, представляющие конвейер для развертывания служб в промежуточной среде.
Чтобы выполнить интеграционные тесты после сборки, нам нужно добавить в этот файл следующие команды:
Оболочка
xxxxxxxxxx
1
…
2
pipelines:
3
release:
4
postBuild:
5
steps:
6
- sh: echo “Executing integration tests!”
7
- sh: python trigger-job.py
Новый файл должен выглядеть следующим образом: https://github.com/testproject-io/jenkinsx-tutorial/blob/master/staging-pipeline.yml
Теперь, когда мы добавили команды, которые будут выполнять интеграционные тесты, мы можем отправить изменения в Git.
Поздравляем! Интеграционные тесты будут выполняться каждый раз, когда что-либо развертывается в промежуточной среде!
Вы можете убедиться в этом, просмотрев журналы сборки:
Оболочка
xxxxxxxxxx
1
CLUSTER_NAME=[...]
2
GIT_USER=[...]
3
jx get build logs $GIT_USER/environment-$CLUSTER_NAME-staging/master
Удачи и удачи!