В чем отличие пайплайна от джобы Jenkins?
Мне нужно понять, что называют джобой в Jenkins, а что пайплайном. Исходя из источников из интернета:
Jenkins Pipeline — набор плагинов, позволяющий определить жизненный цикл сборки и доставки приложения как код.
Jenkins Jobs — это набор задач, которые выполняются последовательно, как определено пользователем.
Из этого описания кажется, что набор задач (Джоба) — это набор этапов (тесты, линтеры, SonarQube, сборка артефакта и т.д), а набор плагинов (Пайплайн) — это какие именно плагины используются. Но я думаю, что моё восприятие про пайплайн не верно, потому что кажется, что два эти термина используют как синонимы. На скрине — две джобы: JavaTpoint Maven, JavaTpoint Pipeline. Но когда говорят «запустить пайплайн», имеется ввиду запустить джобу? Это синонимы или есть отличие?
JenkinsQueueJob@2 — задача задания очереди Jenkins версии 2
Эта задача используется для постановки задания в очередь на сервере Jenkins.
Синтаксис
# Jenkins queue job v2 # Queue a job on a Jenkins server. - task: JenkinsQueueJob@2 inputs: serverEndpoint: # string. Required. Jenkins service connection. jobName: # string. Required. Job name. #isMultibranchJob: false # boolean. Job is of multibranch pipeline type. Default: false. #multibranchPipelineBranch: # string. Required when isMultibranchJob = true. Multibranch pipeline branch. #captureConsole: true # boolean. Capture console output and wait for completion. Default: true. #capturePipeline: true # boolean. Optional. Use when captureConsole = true. Capture pipeline output and wait for pipeline completion. Default: true. # Advanced #isParameterizedJob: false # boolean. Alias: parameterizedJob. Parameterized job. Default: false. #jobParameters: # string. Optional. Use when parameterizedJob = true. Job parameters. #failOnUnstableResult: false # boolean. Fail on unstable result. Default: false. #retryCount: '3' # string. Number of retries for failed connection. Default: 3. #delayBetweenRetries: '60' # string. Time between retries. Default: 60. # Jenkins queue job v2 # Queue a job on a Jenkins server. - task: JenkinsQueueJob@2 inputs: serverEndpoint: # string. Required. Jenkins service connection. jobName: # string. Required. Job name. #isMultibranchJob: false # boolean. Job is of multibranch pipeline type. Default: false. #multibranchPipelineBranch: # string. Required when isMultibranchJob = true. Multibranch pipeline branch. #captureConsole: true # boolean. Capture console output and wait for completion. Default: true. #capturePipeline: true # boolean. Optional. Use when captureConsole = true. Capture pipeline output and wait for pipeline completion. Default: true. # Advanced #isParameterizedJob: false # boolean. Alias: parameterizedJob. Parameterized job. Default: false. #jobParameters: # string. Optional. Use when parameterizedJob = true. Job parameters. # Jenkins Queue Job v2 # Queue a job on a Jenkins server. - task: JenkinsQueueJob@2 inputs: serverEndpoint: # string. Required. Jenkins service connection. jobName: # string. Required. Job name. #isMultibranchJob: false # boolean. Job is of multibranch pipeline type. Default: false. #multibranchPipelineBranch: # string. Required when isMultibranchJob = true. Multibranch pipeline branch. #captureConsole: true # boolean. Capture console output and wait for completion. Default: true. #capturePipeline: true # boolean. Optional. Use when captureConsole = true. Capture pipeline output and wait for pipeline completion. Default: true. # Advanced #isParameterizedJob: false # boolean. Alias: parameterizedJob. Parameterized job. Default: false. #jobParameters: # string. Optional. Use when parameterizedJob = true. Job parameters. # YAML Syntax is not supported in TFS 2018. # Use the classic designer to add and configure tasks. # See the following Inputs section for details on the inputs that this task supports. Входные данные
serverEndpoint — Подключение службы Jenkins
string . Обязательный.
Указывает подключение службы для экземпляра Jenkins. Щелкните ссылку Управление, чтобы создать подключение к службе Jenkins.
serverEndpoint — Конечная точка службы Jenkins
string . Обязательный.
Указывает подключение службы для экземпляра Jenkins. Щелкните ссылку Управление, чтобы создать подключение к службе Jenkins.
jobName — Имя задания
string . Обязательный.
Имя задания Jenkins для постановки в очередь. Оно должно точно соответствовать имени задания на сервере Jenkins.
isMultibranchJob — Задание имеет тип конвейера multibranch
boolean . Значение по умолчанию: false .
Это задание является многоуровневый конвейер. Если указано, добавьте соответствующее имя ветви. Для этих входных данных требуется подключаемый модуль Team Foundation Server для Jenkins версии 5.3.4 или более поздней версии.
multibranchPipelineBranch — Ветвь многоуровневого конвейера
string . Требуется, если isMultibranchJob = true .
Помещает это задание конвейера в очередь в указанную ветвь. Для этих входных данных требуется подключаемый модуль Team Foundation Server для Jenkins версии 5.3.4 или более поздней версии.
captureConsole — Сбор выходных данных консоли и ожидание завершения
boolean . Значение по умолчанию: true .
Если он указан, эти входные данные захватывают выходные данные консоли сборки Jenkins, ожидают завершения сборки Jenkins и завершатся успехом или сбоем на основе результата сборки Jenkins. В противном случае, когда задание Jenkins помещется в очередь, эта задача успешно завершается, не дожидаясь выполнения сборки Jenkins.
capturePipeline — Сбор выходных данных конвейера и ожидание завершения конвейера
boolean . Необязательный элемент. Используйте при captureConsole = true . Значение по умолчанию: true .
Если этот параметр указан, эта задача фиксирует полные выходные данные консоли конвейера сборки Jenkins, ожидает завершения полного конвейера сборки Jenkins и завершается успешно или сбоем на основе результата конвейера сборки Jenkins. В противном случае после завершения первого задания Jenkins эта задача успешно завершается, не дожидаясь выполнения полного конвейера сборки Jenkins.
isParameterizedJob — Параметризованное задание
Входной псевдоним: parameterizedJob . boolean . Значение по умолчанию: false .
Указывает, принимает ли задание Jenkins параметры. Используйте эти входные данные, даже если используются все значения параметров по умолчанию и параметры фактически не указаны.
jobParameters — Параметры задания
string . Необязательный элемент. Используйте при parameterizedJob = true .
Задает параметры задания с по одному на строку в формате = .
Чтобы задать для параметра пустое значение, которое удобно для переопределения значения по умолчанию, оставьте значение параметра. Например, укажите parameterName= .
Поддерживаются переменные. Например, чтобы задать commitId значение параметра для ИД фиксации Git сборки, можно использовать: commitId=$(Build.SourceVersion) . Дополнительные сведения см. в документации по переменным.
Поддерживаемые типы параметров Jenkins:
failOnUnstableResult — Сбой при нестабильном результате
boolean . Значение по умолчанию: false .
Указывает строгость определения успешности или следует ли рассматривать нестабильное состояние как сбой. Значение false — для нестрогая версия, а true — для строгой версии. Если задано значение true , нестабильный результат сборки рассматривается как сбой. В противном случае нестабильный результат считается успешным.
retryCount — Количество повторных попыток для неудачного подключения
string . Значение по умолчанию: 3 .
Указывает количество повторных попыток подключения при сбое или ошибке подключения.
delayBetweenRetries — Время между повторными попытками
string . Значение по умолчанию: 60 .
Указывает время между повторными попытками подключения при возникновении ошибки. Значение указывается в секундах.
Параметры управления задачами
Помимо входных данных, все задачи имеют параметры управления. Дополнительные сведения см. в разделе Параметры управления и общие свойства задачи.
Выходные переменные
Эта задача определяет следующие выходные переменные, которые можно использовать в нисходящих шагах, заданиях и этапах.
JENKINS_JOB_ID
Идентификатор экземпляра задания Jenkins, помещенного в очередь этой задачей. Используйте эту переменную в задаче Jenkins Download Artifacts, чтобы скачать артефакты для конкретного экземпляра задания.
Комментарии
Эта задача используется для постановки задания в очередь на сервере Jenkins.
Подключаемый модуль Team Foundation Server
Подключаемый модуль Team Foundation Server (версии 5.2.0 или более поздней) можно использовать для автоматического сбора файлов из рабочей области Jenkins и их загрузки в сборку.
Чтобы настроить его, выполните приведенные далее действия.
- Установите подключаемый модуль Team Foundation Server на сервере Jenkins.
- На сервере Jenkins для каждого задания, из которых вы хотите получить результаты, добавьте действие Сбор результатов для Azure Pipelines/TFS после сборки, а затем настройте его с помощью одной или нескольких пар типа результата и шаблона включения файла.
- В задании очереди Jenkins задача сборки включает выходные данные консоли Сбор и ожидает завершения для сбора результатов из задания корневого уровня или сбор выходных данных конвейера и ожидает завершения конвейера , чтобы собрать результаты из всех заданий конвейера.
Результаты будут загружены в $(Build.StagingDirectory)/jenkinsResults/Job Name/team-results.zip и извлечены в это расположение. Каждый набор типов результатов, собранных подключаемым модулем, будет находиться в каталоге team-results $(Build.StagingDirectory)/jenkinsResults/Job Name/team-results/ResultType/. Это каталог, в котором результаты сборки могут публиковаться подчиненными задачами (например, Опубликовать результаты тестирования и Опубликовать результаты покрытия кода).
Требования
| Требование | Описание |
|---|---|
| Типы конвейеров | YAML, классическая сборка, классический выпуск |
| Выполняется в | Агент, DeploymentGroup |
| Требования | Нет |
| Capabilities | Эта задача не удовлетворяет требованиям для последующих задач в задании. |
| Ограничения команд | Любой |
| Устанавливаемые переменные | Любой |
| Версия агента | 2.144.0 или более поздней версии |
| Категория задач | Сборка |
| Требование | Описание |
|---|---|
| Типы конвейеров | YAML, классическая сборка, классический выпуск |
| Выполняется в | Агент, DeploymentGroup |
| Требования | Нет |
| Capabilities | Эта задача не удовлетворяет требованиям для последующих задач в задании. |
| Ограничения команд | Любой |
| Устанавливаемые переменные | Любой |
| Версия агента | Все поддерживаемые версии агента. |
| Категория задач | Сборка |
Делаем Jenkins Pipeline: шаг за шагом
Привет! Если ты обратил внимание на этот материал, то значит ты начинаешь разбираться в мире Jenkins. Самым сложным в любом деле является начало. На первом этапе окружает много незнакомых и непонятных терминов, сложно понять логику процесса и последовательность действий. Кажется, что это какая-то магия. Чтобы первые шаги были чуточку легче, я опишу простой пример, который можно использовать в качестве основы для реальных задач.
Я буду отталкиваться от того что у тебя уже установлен Jenkins. Установка Jenkins’а неплохо описана и показана в сети. Мы же будем смотреть на то, как создается Jenkins Pipeline или труба (конвейер) Jenkins.
Что вообще такое Jenkins? Jenkins — это крутая программа, которая реализует практики DevOps. Практики DevOps, в свою очередь, это логичные действия, которые позволяют повысить качество создаваемых продуктов. Под «качеством» будем понимать сразу много преимуществ – уменьшение количества ошибок в продукте, снижение Time-to-Market, повышение пользовательской лояльности и т.д.
Jenkins является «конвейером» поставки ПО от среды разработки в промышленную среду. «Конвейер», конечно же, условный. Jenkins выполняет шаг за шагом простейшие операции над кодом словно это автомобильный завод, на котором ваш фольксваген или форд движется по цехам и проходит разные этапы превращения металла в автомобиль. Такой «конвейер» в Jenkins называют Pipeline.
О DevOps и его практиках
DevOps, грубо говоря, регламентирует «завод» и «конвейер» на нём.
Одной из практик DevOps является CI/CD/CDP. Эта практика описывает шаги «конвейера».
CI (Continuous Integration, непрерывная интеграция) – начальная стадия «конвейера» по сборке кода и загрузке собранного ПО в среду разработки.
CD (Continuous delivery, непрерывная поставка) – является продолжением CI. В этой практике производится автоматизированное развертывание на тестовую среду продукта и разнообразные тесты над ним.
CDP (Continuous Deployment, непрерывное развертывание) – поставка результатов работы CI и CD практик в промышленную среду.
Jenkins, в свою очередь, может реализовать CI/CD/CDP на практике.
Описание примера
Теперь, имея представление что такое Jenkins и для чего он нужен, сделаем тестовую трубу, которая реализует в очень урезанном виде CI/CD практику.
В качестве разворачиваемого продукта будем использовать SSIS-пакет. SSIS (SQL Server Integration Services) – это инструмент создания решений по интеграции и преобразованию данных. То есть решение по переносу данных из одного источника в другой с возможностью преобразования этих данных в процессе переноса.
Подобных примеров в сети я почти не встречал, поэтому убью сразу двух зайцев – построю трубу Jenkins на интересном примере из моей практики. Принцип создания труб одинаковый, поэтому вы сможете применить пример из статьи для своих целей.
Чтобы было ещё интереснее, сделаем задачу со звёздочкой – в одном SSIS-проекте будет сразу несколько SSIS-пакетов.
Опишу шаги, которые будет делать труба:
1) Чекаут из Git (в моём случае Bitbucket)
2) Сборка SSIS-проекта
3) Развертывание собранного файла проекта в среду разработки.
Мой подопытный SSIS-кролик выглядит следующим образом:
Внутри проекта «AUDIT_Import_ALL» находится четыре SSIS-пакета с расширением «.dtsx». Если этот проект собрать, то получится один файл с именем «AUDIT_Import_ALL» и расширением «.ispac». Данный файл предназначен для развертывания проекта в MS SQL Server.
Подготовительные шаги
Проект «AUDIT_Import_ALL» загружен в Bitbucket. В репозиторий проекта я добавлю папку, содержащую Jenkinsfile.
Jenkinsfile – это простой текстовый файл с кодом на языке Groovy, который используется для конфигурации трубы Jenkins.
Теперь я создам тестовую трубу в самом Jenkins. Для этого на главной странице пространства Jenkins нажимаю «New Item», далее выбираю Pipeline и задаю имя.
После нажатия «ОК», открывается окно с настройками. Не будем подробно останавливаться на этом окне. Для тестового примера мне никакие настройки здесь не нужны, кроме раздела с расширенными настройками. А именно, окно настройки «Pipeline».
В нём я свяжу Jenkinsfile, который находится в Bitbucket, с только что созданной трубой Jenkins. Для этого в пункте «Definition» выбираем «Pipeline script from SCM». Этим пунктом я сообщаю Jenkins что мой Jenkinsfile лежит в SCM (source control management – система контроля версий).
На следующем шаге я выбираю SCM, где лежит мой файл. В моём случае это Git (Bitbucket). Далее я прописываю путь до репозитория в SSH формате (возможно и в HTTPS) и указываю учетные данные в поле «Credentials» (или добавляю новую учетную запись через кнопку «Add»).
Jenkinsfile лежит в master-ветке репозитория в Bitbucket, поэтому я не трогаю пункт «Branch Specifier (blank for ‘any’)». Так же, не трогаю следующие два пункта. А вот пункт «Script Path» мне необходимо поменять, потому что по умолчанию Jenkins будет искать Jenkinsfile в корне репозитория. Отдельная папка нужна затем, что файлов для работы Jenkins-трубы может быть несколько и содержать их в корне проекта будет просто неудобно.
Jenkins SSIS стенд
Хочу затронуть архитектурное решение моего Jenkins-стенда. Для тех, кто не будет строить DevOps для SSIS, можно перейти сразу к следующему разделу.
Архитектурно Jenkins строится по принципу master-slave. Есть один ведущий узел, который управляет множеством ведомых. У меня уже была развернута master-нода Jenkins. К ней я подключил slave-ноду, которая была создана под задачу DevOps SSIS. На этом сервере находится программа SSISBuild.exe, предоставляемая Microsoft как раз для наших нужд. SSISBuild предназначена для удаленной сборки SSIS-проектов и не требует установленной Visual Studio или среды выполнения SSIS.
Сервер, куда я буду развертывать SSIS-проект, содержит установленный MS SQL Server с установленной службой Integration Services. На этом сервере установлена вторая программа для DevOps SSIS – SSISDeploy.exe. SSISDeploy предназначена для развертывания файлов проектов (файлов с расширением ispac).
Более подробную информацию о SSISBuild и SSISDeploy вы сможете найти по ссылке.
Jenkinsfile
Итак, труба настроена, связь с Bitbucket установлена, необходимые сервера на связи. Осталось совсем чуть-чуть до запуска. Разберем Jenkinsfile чтобы понимать, как будут происходить те шаги, которые я описал в начале статьи.
Наиболее фундаментальной частью конвейера является «step». По сути, шаги говорят Jenkins, что делать, и служат базовым строительным блоком для синтаксиса конвейеров.
Все операции с конвейером должны быть заключены в блок «pipeline»:
Блок «pipeline» содержит разделы. Первым разделом является «agent». Раздел «agent» указывает, где будет выполняться труба Jenkins. Раздел должен быть определен на верхнем уровне внутри блока «pipeline».
В моём случае конвейер будет работать на сервере TestNode:
Раздел «options» позволяет настраивать параметры конвейера непосредственно из Jenkinsfile. Эти параметры также можно задавать в графическом интерфейсе Jenkins.
Раздел «parameters» задает список параметров, которые пользователь должен предоставить при запуске трубы. Заданные пользователем значения становятся доступными для шагов конвейера через объект params. Я создам два булевых параметра, с помощью которых можно будет управлять запуском шагов конвейера:
parameters < booleanParam(defaultValue: true, description: 'Build SSIS', name: 'BUILD') booleanParam(defaultValue: false, description: 'Deploy SSIS', name: 'DEPLOY') >
Раздел «environment» определяет глобальные и локальные (в пределах конкретного «step») переменные в Jenkinsfile. Глобальные переменные удобно использовать для подстановки статических значений:
environment < SSISBuildPath="C:\\SSIS_DEV_OPS\\SSISBuild.exe" SSISDeployPath="C:\\SSIS_DEV_OPS\\ssisdeploy.exe" SOLUTION = "AUDIT_Import_ALL\\AUDIT_Import_ALL.dtproj" >
Раздел «stages» является местом, где будет происходить основная часть работы конвейера. Раздел делится на этапы, которые содержат описание шагов. У меня будет три этапа:
stages < // Извлекаем проект из Bitbucket stage('Checkout') < >// Собираем проект. Получаем на выходе пакетный файл AUDIT_Import_ALL.ispac stage(‘Build’) < >// Загружаем архив с проектом на удаленный сервер. Деплоим его на MS SQL Server stage(‘Deploy’) < >>
Теперь рассмотрим шаги на каждом этапе.
Раздел «post» определяет дополнительные действия, которые будут выполняться после завершения работы основного кода конвейера или этапа (в зависимости где стоит post).
На этом мой блок «pipeline» в Jenkinsfile заканчивается. Далее располагается метод «PrintStage», который встречался на этапах Build и Deploy:
Запуск конвейера
Теперь всё готово к запуску. Открываю окно нашего конвейера и нажимаю кнопку «Собрать с параметрами».
Откроется окно с параметрами, которые я определил в разделе «parameters». Выбираю этапы, которые хочу запустить и нажимаю «собрать».
Далее, труба начинает собираться и если всё сделано правильно, то Jenkins нарисует красивую картинку:
Как добавить учетную запись в Jenkins
Для этого на главной странице вашего пространства нажмите кнопку «Credentials», далее выбрать «Folder».
Наведите курсор на пункт «Global credentials (unrestricted)» и у вас появится «галочка» для вызова выпадающего списка. Нажмите на неё. Всплывет маленькое окошко «Add credentials» — нажимайте!
Здесь вы можете задать вашу учетную запись. В моём примере с учетной записью WinRM, я использовал «Secret text» для хранения пароля.
По итогу мы сделали трубу, которая собирает и деплоит SSIS-пакеты на MS SQL Server. Данный пример является учебным , но его можно взять за основу и доработать под ваши задачи. Например, если вы делаете веб-приложение на ASP.NET, то вместо ssisdeploy можно использовать webdeploy. По аналогии можно добавить шаги с разнообразными тестами, созданием release notes, загрузкой дистрибутива в централизованное хранилище и т.д.
Какие преимущества даёт Jenkins? Он автоматизирует многие рутинные процессы, связанные с разработкой программного обеспечения. Например, запуск трубы с прохождение различных тестов при коммите в нужную ветку в Bitbucket. Такой подход уменьшит количество ошибок. Применение Jenkins объединяет процессы сборки, тестирования и внедрения и создает четко выстроенный подход к созданию продукта.
Буду рад, если моя статья была кому-то полезна.
Если у вас остались вопросы, оставляйте их в комментариях – я обязательно отвечу.
Как называется задача в jenkins
В чём разница между системным администратором и системным инженером? Как связаны DevOps и Agile? Как и для чего используются такие инструменты как Docker и Jenkins? Где искать помощь начинающему DevOps-cпециалисту и какие ресурсы читать? Разбираемся вместе со старшим системным инженером Виктором Ворониным.
В этом году Виктор празднует профессиональный юбилей – 20 лет работы в IT-сфере. Cейчас он работает старшим системным инженером в рязанском офисе EPAM. А еще помогает в профессиональном развитии нескольким специалистам компании, выполняя роль их ресурсного менеджера, участвует в организации рязанского DevOps-комьюнити и помогает обучать начинающих специалистов в тренинг-центре.
Об особенностях работы по методологии DevOps, специфике входа в профессию, задачах и инструментах системного инженера – в рассказе Виктора.
Задачи DevOps-инженеров
Devops-специалисты или просто Devops-ы, как чаще всего нас называют, участвуют почти во всех стадиях жизненного цикла продукта, начиная с разработки. DevOps – это не название должности, а методология. Идея, заложенная в её основу – сократить время, за которое программный продукт дойдет до конечного пользователя. Так что все программисты, разрабатывающие программный продукт, немножко DevOps-инженеры.
Когда в проект заходят разработчики и начинают писать программу, они советуются с Devops-ами о том, в каком окружении будет работать код. DevOps-инженеры предоставляют эту информацию и корректируют моменты, которые связаны с конкретной спецификой окружения. После того, как работа программиста закончена, и код написан, Devops должен довести его до клиента: организовать компеляцию, сборку, тестирование, развертывание на тестовых окружениях. В процессе этой части работы специалист вникает в процессы ручного и автоматизированного тестирования. Таким образом, Devops участвует во всех стадиях жизненного цикла проекта и знает чуть больше остальных участников.
А еще в специальности много программирования. В задачи Devops-инженера входит написание большого количества кода. Но этот код пишется не на классических языках, а на скриптовых, например, Python, GoLang или Bash.
Роли специалистов в среде DevOps
DevOps – это слияние слов Development and Operations, разработка и функционирование. Соответственно, Devops-специалист может иметь уклон на поддержку разработки. В этом случае он обеспечивает разработчикам информацию о платформе: компеляцию, сборку продукта, тестирование и так далее. А есть специалисты с уклоном в Operations, то есть, в работу самого продукта. Они отвечают за развертывание продукта в различных средах, стабильность работы, наличие необходимых ресурсов для работы приложения. Но это разделение в компании не фиксируется официально, руководители просто знают кто к чему тяготеет. Вообще предполагается, что Devops должен одинаково ориентироваться в двух сферах.
Разница между системным администратором и системным инженером
Чтобы разобраться, почему системный администратор – не системный инженер, нужно уточнить откуда берутся DevOps-ы. Если открыть Google и поискать IT-курсы, то большинство из них будет связано с разработкой или тестированием. Курсы DevOps сейчас найти можно, но они будут в меньшинстве, а где-то 2 года назад их почти не было. Сейчас в EPAM мы активно набираем даже начинающих специалистов на бесплатное обучение по DevOps. Обучение полноценного, серьезного Devops-специалиста – это сложная задача. Правильно будет сказать, что лучшие DevOps-инженеры получаются либо из системных администраторов, которым интересно программирование и применение автоматизации к задачам, либо из программистов, которые не только писали код, но и пытались настроить окружение, чтобы он правильно работал. Поэтому большинство системных инженеров, учитывая, что это направление молодое, пришло из системных администраторов и программистов.
О сочетании методологий DevOps и Agile на проекте
DevOps и Agile связывает то, что их часто используют вместе. Сами по себе они разные, поэтому могут существовать и отдельно друг от друга. Цель Agile – это постепенное внедрение изменений, разделение процесса разработки на небольшие этапы. По результатам каждого из этапов раз в две — три недели мы получаем код, который может быть доставлен клиенту. А DevOps создана для того, чтобы максимально быстро доставлять код. Код можно внедрять по Agile-методологии без DevOps или в DevOps.
Применение DevOps-методологии в рабочем процессе становится важным, когда возрастает количество разработчиков на проекте, и его трудоёмкость. Если ты единственный разработчик и код хранишь правильно, знаешь, где и какие изменения внесены, то можешь спокойно его разрабатывать и продавать без DevOps. Здесь DevOps внедрять рано и избыточно. Но в большой команде работают десятки разработчиков и десятки тестировщиков. В таком случае без DevOps будет сложно, потому что есть большое количество окружений. Код лучше разрабатывать так, чтобы изменения разных разработчиков не конфликтовали и проходили максимально быстро или по максимально эффективному пути.
CI/CD как часть DevOps
CI/CD – это концепции DevOps, которые расшифровываются, как Continuous Integration и Continuous Delivery.
Continuous Integration заключается в том, что, изменения, которые разработчики вносят в код, должны как можно чаще попадать в общий репозиторий. В таком режиме командам максимально удобно работать. Разработчик сразу видит изменения, внесенные коллегами и в соответствии с ними корректирует или разрабатывает свой код. По идеальной методологии CI разработчики размещают часть написанного кода раз в день – это считается необходимым минимумом. Но в реальности возможны разные варианты: как 30 раз в день, так и раз в неделю. Последние 2 года на моём проекте CI построен не в классическом плане. Я мог коммитить код в репозитории до 10 раз в день и больше. Это происходило в отдельных обособленных ветках и разделённых задачах. Каждые мои 20 коммитов в день приводили к компиляции, тестированию и выдаче результата, о том, насколько код нормален.
Continuous Delivery – это вторая часть процесса, доставка кода в виде работающего приложения клиенту. В идеальной DevOps-структуре считается, что протестированная часть кода сразу попадает к клиенту на рабочее приложение. Я пока на практике подобного не встречал, но, говорят, что такие гиганты, как Netflix, так и работают.
Рассказывая о CI/CD, также важно отдельно упомянуть Pipeline. В переводе это слово означает «труба» или «трубопровод». В Devops-мире так называют процесс, по которому обрабатывается ПО как раз, чтобы пройти CI-цикл или CD-цикл. Например, разработчик пишет Java-приложение. При проверке его работоспособности, приложение компилируется, проходит модульные тесты, собирается, запускается и автотестируется – так выглядит CI-цикл для этого приложения. Эти операции собираются и каждая представляет собой отдельный шаг Pipeline-а. А вместе они представляют своебразную трубу, через которое пролетело приложение. Если на одной из стадий возникла проблема, мы это увидим. Если приложение прошло весь Pipeline, значит оно считается рабочим.
Контейнеризация, виртуализация и Docker
Виртуализация, контейнеризация и Docker сокращают накладные расходы на запуск приложения, помогая отказаться, например, от разных операционных систем.
Контейнер – это механизм, который позволяет использовать максимальную часть техники для запуска конкретных приложений, а не для обслуживания операционных систем или чего-то подобного. Он представляет собой легковесную структуру, которая содержит в себе приложения и системные библиотеки. Сделав виртуальным физический сервер, на котором работает одно приложение, можно запустить одновременно 10. Если поставить там ещё и Docker, то максимальное число увеличится до 20. Контейнеры хорошо сочетаются с DevOps, потому что обновить приложение «бесшовно» для клиента гораздо проще, чем на физическом сервере. Сейчас огромная часть программ, например Gmail, работает так, а пользователи об этом даже не догадываются.
Docker – самое популярное, но не единственное средство для запуска приложений в контейнерах. Это программное обеспечение больше подходит для работы с операционной системой Linuх. Полноценный Docker под Windows еще разрабатывается, и в качестве широкоиспользованного продукта пока что не существует. Поэтому пока специалист, знающий Linux имеет больше возможностей, чем DevOps, знающий только Windows.
Использование Jenkins в Devops—инфраструктуре
DevOps-инфраструктура часто строится вокруг центрального компонента, который обеспечивает CI/CD-процессы. Таких систем множество, но самая популярная из них – Jenkins. Это один из самых старых инструментов, из-за чего для него уже существует огромное количество плагинов. Поскольку он бесплатный, начинающий DevOps может им воспользоваться без ограничений, поэтому большинство новичков в DevOps видели или знают, что такое Jenkins. Недостаток этой бесплатной системы в том, что, некому предъявить претензии. если она работет плохо – приходится искать решение проблемы самостоятельно. Как раз поэтому у Jenkins и появились платные конкуренты, которые предоставляют поддержку. Практически все крупные игроки IT рынка предлагают подобные программы: TeamCity, GitLab CI, Bitbucket CI, Azure CI, AWS CI.
DevOps-инфраструктура работает, как конструктор. В Jenkins много инструментов для тестирования, сборки, проверки кода. Для хранения исходного кода к Jenkins можно добавить GitLab, а можно и собственный Git-сервер. Затем нужно выбрать сборщик. Можно запускать его на Jenkins, прикрутить к нему исполнители, на котоых будет проходить сборка. Далее требуется хранилище для артефактов, то есть, того, что получилось в результате сборки кода. При сборе Java-приложения в итоге получается JAR-файл, для Windows – exe-файл, или dll. К Jenkins возможно также прикрутить Nexus или Artifactory, в которые попадут файлы, полученные после сборки. Так в итоге собирается CI-процесс, из инструментов, которые более удобны в использовании.
О сложных задачах и поиске решения
Последний сложный кейс на проекте возник буквально 3 недели назад, когда я должен был приспособить для Azure open-source решение, которое было реализовано для облачного провайдера AWS. Я адаптировал его, что помогло команде с развертыванием окружения и одновременным запуском 150 серверов в облаке Microsoft Azure. Благодаря этому время запуска сократилось с 4,5 часов до 30 минут.
В нестандартных ситуациях в EPAM помогает система юнитов, подразделений. То есть, мы стараемся объединять в сотрудников подразделения с одинаковой экспертизой. DevOps-ы общаются друг с другом, и более опытные сотрудники помогают новичкам, как ресурсные менеджеры. Первый человек, к которому можно придти – это коллега в юните. Далее следует отправиться к DevOps-практике – это все российские DevOps-ы в EPAM. Если никто не смог помочь и там, можно пойти в центр компетенций DevOps – это объединение DevOps-ов EPAM по всему миру.
Если говорить про начинающего специалиста, который пока в нашей компании не работает, но хочет быть DevOps-инженером, то можно проконсультироваться на форумах, к примеру, попросить совет на GitHub или GitLab. Проекты, выложенные на этих сайтах доступны любому зарегестированному пользователю. Там есть раздел «проблемы», куда можно написать и получить решение или обсудить задачу с другими людьми. Мы часто так делаем, обращаясь на этом ресурсе к тем, кто обладает наибольшим опытом. Такого понятия, как глобальное мировое DevOps-комьюнити нет, но часто ПО разрабатывает большое количество энтузиастов, которые готовы на GitHub или других форумах безвозмездно отвечать на вопросы.
Ресурсы для начинающих DevOps-инженеров
Сначала начинающему DevOps-инженеру можно смело заходить на такой ресурс, как Habr и читать там DevOps-раздел. Затем стоит поискать обучающие видео на YouTube. С хорошим английским можно пользоваться такими ресурсами, как PluralSight и Linux Academy. С учетом того, что DevOps состоит из большого количества проектов с открытым кодом, ищите бесплатную информацию в виде подкастов и статей. Основная часть из них, конечно, на английском языке, но на русском тоже много материалов. Также можно пройти по крупным игрокам (Microsoft, Google, Oracle) и посмотреть, что есть у них. Компания Microsoft недавно поняла, что людей нужно обучать использованию своих продуктов и сделала много тренингов. По Azure Cloud материалы бесплатные и доступны на русском и английском языках. Если раньше компании просили за тренинги огромные деньги, то сейчас они существуют в свободном доступе, потому что конкуренция стала высокой, и необходимо активно привлекать людей в свой продукт.
Как резюме, начинайте с Хабра и YouTube. Выбирайте интересные материалы по DevOps и читайте все, что есть в них по ссылкам. Смотрите видео, которое выкладывают официальные источники и DevOps-энтузиасты.