Jenkins руководство

Hudson — инструмент непрерывной интеграции. написанный на Java. Запускается в контейнере сервлетов. таких как Apache Tomcat или GlassFish. Поддерживает инструментарий для работы с разными системами контроля версий, включая CVS. Subversion. Mercurial. Git и Clearcase. может собирать проекты Apache Ant и Apache Maven. а также исполнять shell-скрипты и команды Windows.
Основной разработчик Hudson — Косукэ Кавагути — ранее работал в Sun Microsystems и в 2010 году. после поглощения Sun компанией Oracle. основал компанию InfraDNA, нацеленную на коммерческую поддержку инструмента. В феврале 2011 года Кавагути ответвил проект, дав ему наименование Jenkins, в ответ на отказ корпорации Oracle передать права на торговую марку Hudson. В мае 2011 года Oracle отказалась от контроля над проектом и наименованием, предложив целиком передать разработку инструмента под управление Eclipse Foundation .
Сборка проектов может быть назначена на разные события, например, производиться по расписанию, используя механизм подобный cron. либо стартовать когда другая сборка уже собрана, либо при запросе определённого URL .
Последние годы Hudson стал популярной альтернативой CruiseControl и другим программам для сборки с открытым исходным кодом. На состоявшейся в мае 2008 года конференции JavaOne приложение стало лауреатом Duke’s Choice Award в категории «Решения для разработчиков». Компания Sun Microsystems объявила о коммерческой поддержке инструмента в августе 2009 года .
По состоянию на конец 2010 года Hudson выпускался под лицензией MIT .

Это фрагмент статьи Jenkins свободной энциклопедии Википедия. В Википедии приведен список авторов.

На сайте ru.wikipedia.org к статье Jenkins за последние 30 дней обращались 431 раз. (по состоянию на: 20.05.2014 г.)

Изображения о Jenkins

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

Если к вам уже приходили с вопросом «Где можно получить свежую сборку?», то вы прекрасно понимаете, зачем нужна автоматизация сборки и распространения. Никто не хочет тратить лишнее время на.

Дек042012 24 комментариев Написал Tatyana.

Continuous integration или непрерывная интеграция - это практика создания автоматизированной сборки проекта. Хотя это и звучит как-то заковыристо, но это т

В предыдущих постах я описал свой переход от флагово-хукового тестирования к Jenkins под Windows и последующим развертыванием виртуальной машины с WinXP для Selenium-тестов. История получилась в 4х частях, многое не нужно, и от этого её трудно использовать. В этом посте я постараюсь кратко, но целостно описать процесс развертывания системы Selenium-тестирования, запускаемого из Jenkins с использованием универсального средства переносимых виртуальных машин Vagrant с провайдером VirtualBox и образом Ubuntu desktop для запуска тестов в Chrome и Firefox.

Блог о мастерклассах Марка Дженкинса в Екатеринбурге и Москве (Россия) которые прошли в октябре 2009 года This blog is about Mark Jenkins workshops in Russia 2009 - Yekaterinburg & Moscow

Инструкция по настройке Jenkins CI на Mac OS X для сборки Android- и iOS-приложений Phonegap/Cordova и размещения их в TestFlight/HockeyApp

Intel IT Galaxy – Сообщество IT-профессионалов. Обсуждение информационных технологий.

Настройка среды непрерывного развертывания с помощью Jenkins

Для организации непрерывного развертывания важно правильно настроить среду. Она определяет эффективность системы DevOps и то, что можно делать в процессе непрерывного развертывания.

Эта статья содержит информацию о платформе Jenkins и демонстрирует:

• как настроить среду непрерывного развертывания с помощью Jenkins;
• применять эти знания в рамках среды непрерывного развертывания;
• реализовать среду непрерывного развертывания с помощью Jenkins.

Эта статья предназначена для программистов, работающих над непрерывным развертыванием или непрерывным автоматическим тестированием ПО. Чтобы выполнить инструкции этой статьи, читатель должен быть знаком:

• с разработкой сценариев;
• процессом разработки программного обеспечения.

• Требуется среда Java Runtime Environment (JRE) 1.6 или более поздняя версия
• Загрузите Jenkins.war

• Выполните команду java -jar jenkins.war

• разверните jenkins.war в контейнер Tomcat

Jenkins – это инструмент непрерывной интеграции, который чаще всего используется для разработки программного обеспечения. Это среда автоматизации, которая выполняет повторяющиеся задания. Jenkins может выполнять и контролировать выполнение команд на удаленных системах, а также всего того, что можно выполнить из командной строки. С помощью вспомогательных плагинов Jenkins объединяет электронную почту, TestNG и другие инструменты.

После установки (см. врезку) доступ к Jenkins осуществляется через браузер по адресу: http://yourjenkinsmasterhost:8080 .

Дженкинс поддерживает режим ведущий-ведомый. Работа по сборке проектов делегируется нескольким ведомым узлам. Это позволяет размещать в одной установке Jenkins большое число проектов или создавать разные среды для сборки-тестирования.

Прежде чем использовать среду Jenkins, ее необходимо настроить. В этой статье мы покажем, как настроить режим ведущий-ведомый, установить плагины, настроить проекты и управлять переменными и свойствами.

Сначала установим Jenkins на ведущей машине (Linux или Windows ), а затем с помощью ведущей машины Jenkins настроим ведомые машины (Windows или Linux).

Ведущая машина Jenkins

Система управления и настройки или запуска заданий Jenkins.

Ведомые машины Jenkins

Машины, которые выполняют задания под управлением ведущей машины.

Ведомые машины используются, когда ведущая машина перегружена или для выполнения задания нужна машина другого типа.

В Jenkins есть встроенный клиент SSH, который используется для взаимодействия с удаленным sshd и с агентом ведомой машины. Существует несколько способов для связи между ведущей и ведомыми машинами:

• для ведомых машин UNIX используется SSH. На ведомых машинах требуются только SSH и JRE;
• для Windows используется Distributed Component Object Model (DCOM);
• когда ведущая машина не может «видеть» ведомые, используется отдельное соединение через сокет и Java Web Start.

Чтобы установить ведущую машину Linux, введите команды из листинга 1.

Чтобы установить ведущую машину Windows, введите команды из листинга 2.

После выполнения команд откройте страницу http://<hostname>:8080/ и выберите пункт Manage Jenkins > Install as Windows Service > Install .

Откройте http://<JenkinsMasterHost>:8080/ > Manage Jenkins > Manage Node > New Node и настройте параметры ведомой машины в соответствии с параметрами хоста. Ведущая машина Jenkins установит Jenkins на ведомые машины.

Для ведомых машин Windows имеется дополнительная команда:

Имя ключа реестра, определяющего службу, – <serviceKey>. <service display name > (отображаемое имя службы) — это метка, которая идентифицирует службу в интерфейсе администратора.

Плагины – это еще одна важная особенность Jenkins. В настоящее время Jenkins поддерживает более 1000 плагинов. Эти плагины можно разделить на категории (плагины для управления исходным кодом, для создания отчетов, для создания инструментов и т.п.). С помощью плагинов можно контролировать, развертывать или настраивать различные задания в Jenkins. Чтобы управлять плагинами, откройте страницу https://JenkinsMasterHost:8080 и выберите Manage Jenkins > Manage Plugins. Имеются четыре вкладки:

• Updates. установленные плагины, для которых есть обновления;
• Available: плагины, доступные для установки;
• Installed: установленные плагины;
• Advanced: управление плагинами.

Установка плагинов через Интернет

Когда у ведущей машины Jenkins есть доступ в Интернет, плагины устанавливаются легко. Выберите плагины для установки на вкладке Available. Удалять плагины можно на вкладке Installed. Чтобы удалить плагины, нажмите кнопку uninstall .

Ручная установка плагинов

Если у ведущей машины Jenkins нет доступа в Интернет, плагины можно установить вручную. Найдите плагин. который нужно установить, и сохраните загруженный файл *.hpi/*.jpi в каталоге $JENKINS_HOME/plugins. Перезапустите Jenkins, чтобы включить плагины.

Jenkins поддерживает четыре типа проектов: проекты произвольного типа, экспертные, с несколькими конфигурациями и внешние задачи. Проект произвольного типа – это центральный элемент Jenkins. Его можно объединить в системе управления исходным кодом (SCM) с любой системой сборки. А также использовать для других целей, помимо сборки программного обеспечения.

Чтобы создать проект, откройте страницу https://JenkinsMasterHost:8080. выберите New Item и укажите имя (Item name ) и тип (Type ) проекта.

На странице настройки проекта имя проекта также называется Project name. Элементы могут быть четырех типов. Можно также выбрать copy existing item (скопировать существующий элемент), как показано на рисунке 1. Нажмите кнопку ОК. чтобы открыть страницу настройки проекта.

На странице настройки содержится следующая информация:

Project name: имя проекта; при его изменении также изменяется имя элемента;

Description: описание задачи;

Strategy: стратегия журналирования, количество журналов;

Parameterized: определение переменных проекта. Существуют переменные разного типа (параметр файла, параметр текста, параметр строки и т.д.);

Where: ограничивает область исполнения проекта;

Advance configuration: дополнительные спецификации для управления способом сборки проекта.

Плагины, выбранные для установки, влияют на категории и функции, которые будут доступны в проекте. Вот некоторые возможные категории и функции:

• Source code management. инструмент управления исходным кодом;
• Build triggers. метод запуска сборки;
• Build. сборка – это наиболее важная часть проекта. Укажите точные действия по запуску проекта. Обычно это команды DOS для Windows или Shell для Linux;
• Post-build actions: действия, выполняемые после сборки. Как правило, это отправка сообщений электронной почты, запуск других сборок или публикация отчетов о результатах.

После завершения настройки нажмите кнопку Save. Сохраненный проект находится в списке на странице https://JenkinsMasterHost:8080Jenkins > All.

Jenkins позволяет запускать сборку проекта вручную или автоматически. Существуют различные механизмы запуска сборки. Если выбрать автоматическую сборку, то при настройке проекта можно определить значение параметра Build Triggers. Возможные варианты:

• сборка проекта после сборки других проектов: после настройки проекта можно определить, нужно ли после этого проекта собирать другие проекты. Выберите этот вариант, если проект зависит от других проектов;
• дистанционный запуск сборки (например, из сценария): сборка проекта запускается из другой системы или из другого узла. Например, сборку проекта можно вызвать по электронной почте или направить запрос на сборку из сценария;
• периодическая сборка: создание графика периодической сборки проектов в соответствии с конфигурацией;
• опрос SCM: этот вариант собирает проект путем внесения изменений в исходный код. В этом случае указывают, как часто Jenkins должен опрашивать систему управления версиями. При наличии изменений исходного кода выполняется сборка проекта.

Ведомая машина — это компьютер, который берет на себя часть работы по сборке проектов. Распределение задач осуществляется автоматически.

Точное распределение зависит от настройки каждого проекта. Если для проекта заданы ограничения на место исполнения (Restrict where this project can run ), то он будет работать только на указанном компьютере. Другие проекты могут свободно перемещаться между ведомыми машинами – все зависит от конфигурации.

В настоящее время Jenkins реализует следующие стратегии распределения проектов:

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

В глобальных свойствах настраиваются переменные среды (определение имени и значения свойств) или местоположение инструментов: откройте страницу http://<JenkinsMasterHost>:8080 и выберите Manage Jenkins > configuration. Эти свойства можно использовать во всех проектах Jenkins.

В проектах можно ссылаться на переменные среды. Выберите поле Environment variables и определите имя (name ) и значение (value ) переменных, как показано на рисунке 3.

Установите флажок Tool Locations. Выберите имя инструмента из раскрывающегося списка и укажите каталог для него. Инструменты можно вызывать в проектах.

Локальные свойства проекта

Локальные свойства доступны только в рамках проекта. При настройке проекта выберите вариант This build is parameterized. как показано на рисунке 5. Он позволяет добавлять параметры в виде пар имя-значение. Такие параметры можно использовать как локальные свойства проекта.

Цель непрерывного развертывания – обеспечить эффективный и высококачественный процесс разработки, испытания, развертывания и запуска программного обеспечения в производство. При непрерывном развертывании каждое изменение в любой части системы программного обеспечения (на уровне инфраструктуры, приложения или настройки данных) постоянно переносится в производственную среду посредством специального конвейера развертывания.

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

• разработчик вносит изменения в код;
• инструменты управления исходным кодом выполняют сборку;
• производится автоматическое тестирование;
• сборка устанавливается.

Процесс непрерывного развертывания показан на рисунке 6. В назначенное время стартует первый проект в Jenkins.

Проект 1 Первая задача в рамках этого проекта – загрузить исходный код из инструмента управления исходным кодом, такого как IBM® Rational Team Concert™. Если проект дает сбой, рассылаются уведомления по электронной почте, и все остальные проекты останавливаются. Если проект оказывается успешным, запускается следующий проект. Проект 2 IBM® Security AppScan® анализирует исходный код, загруженный из проекта 1, на наличие проблем безопасности. Проект 3 После завершения работы AppScan начинается сборка проекта. Проект 4 После успешной сборки устанавливается следующий проект, который собирается в среде Build Verification Test (BVT). Проект 5 Выполняются BVT-тесты в среде BVT. Если BVT-тест проходит, Jenkins начинает установку сборки одновременно в среде разработки и в среде тестирования (проекты 6 и 7). Проект 6 Выполняется установка сборок в средах разработки и рассылаются уведомления по электронной почте. Проект установки сборок в средах разработки готовит среды, так чтобы разработчики могли решать свои задачи по интеграции или разработке. Проект 7 Установка сборок в среды тестирования. Установив сборку в среду тестирования, Jenkins запускает проект 8 по выполнению теста Functional Verification Test (FVT). Проект 8 FVT – это список из множества автоматических тестов. После прогона FVT сборка устанавливается в производственные среды (проект 8). Проект 9 Производственные среды могут быть установлены на локальных серверах ваших клиентов, в облаке или на IBM® Softlayer®. Доступ к ним предоставляется как внутренним, так и внешним пользователям.

Процесс непрерывного развертывания показан на рисунке 6. После успешного завершения проекта запускается следующий проект. Если проект дает сбой, то процесс заканчивается, и подписчикам рассылаются электронные уведомления.

В левой части рисунка 7 показан традиционный процесс развертывания. Разработчик фиксирует набор изменений на сервере управления исходным кодом, например, Rational Team Concert (RTC), затем сервер сборки выполняет сборку.

В правой части рисунка 7 показан процесс непрерывного развертывания. После добавления Jenkins появляется ведущая машина Jenkins. На этом сервере установлен Rational Team Concert buildtoolkit. Ведущая часть Jenkins устанавливается в плагин Rational Team Concert. Она использует buildtoolkit для загрузки исходного кода из Rational Team Concert и запускает buildtoolkit для выполнения сборки. Проекты AppScan и BVT также работают на ведущей машине Jenkins. Среды разработки, тестирования и производства играют роль ведомых машин Jenkins. Ими управляет ведущая машина Jenkins, и они выполняют проекты по установке. Тестовые среды выполняют проект функционального тестирования.

Примечание.
Задачи проще отслеживать, если связать проекты с компьютерами, так как разные машины играют разные роли.

Теперь вы знаете, как настроить среду непрерывного развертывания с помощью Jenkins. Эта среда помогает автоматически распределять работу, что экономит драгоценное время разработчиков и тестеров. Она также помогает выявить любые проблемы или дефекты на ранних этапах процесса.

• Загрузите пробную версию AppScan Security .
• Попробуйте Rational Team Concert .
• Оцените продукты IBM наиболее подходящим для себя способом: загрузите пробную версию продукта, поработайте с ним в Интернете или используйте продукт в облачной среде.
• Попробуйте службы IBM DevOps для Bluemix .

• Примите участие в деятельности DevOps для масс – сообщества ИТ специалистов, интересующихся DevOps.

Установка Jenkins в Linux

В какой-то момент практически любому серьёзному разработчику приходится столкнуться с таким явлением как непрерывная интеграция (Continuous Integration). Одним из средств для организации CI является Jenkins — форк Hudson. Давайте же установим его и произведём самую базовую настройку.

Я приведу примером установку на Debian 7. Эта статья подойдёт для установки на многие дистрибутивы debian-семейства. В других некоторые моменты будут отличаться из-за отличия системы управления пакетами.

• В наличии имеется машина с дистрибутивом семейства Debian
• Имеются права root на этой машине
• 1 или более ГБ оперативной памяти
  Вообще, рекомендации по объёму оперативной памяти сильно расхожи. Кто-то рекомендует объём «с запасом» для больших проектов от 16 гигабайт, а кто-то обходится и 512 мегабайтами. Я лично остановился на объёме в 1 гигабайт в качестве стартовой точки, так как Jeknins написан на Java, а софт на этом языке очень любит кушать память.

Лично я выполняю весь процесс установки от пользователя root, но так как такая практика не рекомендуется, то можно просто предварять команды sudo. Либо же можно ступить на тёмную сторону силы и сделать, например, sudo - i .

Для начала добавим PGP-ключ репозитория и сам репозиторий в нашу систему:

После установки он автоматически запускается и можно сразу переходить в веб-интерфейс, который располагается на порту 8080 вашего сервера. Как вы можете заметить, он открыт внешнему миру и никак не защищён. Самое время настроить аутентификацию и права доступа.

Здесь нужно определить, как вы хотите аутентифицироваться в системе: через учётные записи, которые хранятся в самом Jenkins или через внешний сервис (Bitbucket, Github, и т.п.). Если вы планируете использовать внешний сервис — нужно поставить его плагин. В случае с Bitbucket, это плагин «Bitbucket OAuth Plugin». Если нет — просто пропустите установку плагина и читайте дальше.

Для установки плагина перейдите в «Manage Jenkins» — «Manage Plugins» — «Available» и выберите нужный плагин. Рекомендую воспользоваться фильтром для быстрого поиска.

Нажимаем «Download now and install after restart» для чистой установки плагина с перезапуском. В появившемся окне установки включаем галочку «Restart Jenkins when installation is complete and no jobs are running» и ждём установки с перезагрузкой. Страница должна сама обновиться. После установки можно возвращаться на главную страницу и продолжать настройки.

Наш Jeknins всё ещё доступен первому зашедшему, о чём предупреждает нас сообщением

Unsecured Jenkins allows anyone on the network to launch processes on your behalf. Consider at least enabling authentication to discourage misuse.

Поэтому давайте настроим права доступа и механизм входа в систему. Для этого нам нужно снова перейти в «Manage Jenkins», а там нажать кнопку «Setup Security» в правом верхнем углу. В появившемся окне настроек включаем настройки безопасности галочкой «Enable security». Далее нам нужно выбрать, каким способом будет происходить аутентификация пользователей. По умолчанию доступны несколько способов. Нас интересует «Jenkins’ own user database», если мы хотим входить с данными, которые хранятся в самом Jenkins или «Bitbucket OAuth Plugin», если мы хотим входить через Bitbucket.

Здесь особо ничего настраивать не нужно. Разве что, возможно, стоит запретить регистрацию пользователей сняв галку «Allow users to sign up».

Для этого же способа нам потребуется сходить в настройки своего аккаунта Bitbucket и зарегистрировать приложение. Для этого заходим на страницу своего аккаунта, нажимаем «Manage account» и переходим в раздел «OAuth». Здесь добавляем приложение кнопкой «Add consumer». После чего получаем «Key», который прописываем в «Client ID» и «Secret», который копируем в «Client Secret».

После того как мы настроили вход, нужно закрыть доступ посторонним людям. Для этого можно использовать несколько способов, самым простым из которых будет «Matrix-based security». Здесь главное сделать две вещи:

• Выставить пользователю «Anonymous» доступ к действию «Read» в категории «View», иначе Jenkins может работать некорректно
• Вместе с этим сразу же, не сохраняя перед этим настройки, создать пользователя, под которым в дальнейшем будет происходить управление системой, иначе после применения этих настроек, вы не сможете зайти в интерфейс Jenkins. Если вы аутентифицируетесь через внешний сервис — укажите имя пользователя на этом сервисе

Перепроверьте настройки и нажимайте кнопку «Save».

После сохранения настроек вы попадёте либо в форму входа, либо будете перенаправлены на внешний сервис аутентификации.

Jenkins направит вас на форму входа. У вас же ещё нет пользователя, поэтому удалите лишнее из адреса и перейдите в корень веб-интерфейса — вам будет показана форма создания пользователя.

В случае с Bitbucket или другим внешним сервисом нет необходимости регистрации, поэтому вам нужно будет лишь подтвердить на этом сервисе, что вы доверяете приложению. После этого вы вернётесь в систему уже полноправным администратором (если, конечно, выставили такие права своей учётной записи).

Если вы ошиблись при настройке прав доступа и Jenkins не пустил вас в систему, не пугайтесь. Можно выключить защиту в конфиге:

Использование Jenkins: удачи и неудачи

Описание: Принято считать, что Jenkins – это инструмент для непрерывной интеграции, и чаще всего этот инструмент рассматривают именно в таком ключе. Но, в реальности, Jenkins стоит рассматривать как настраиваемую платформу. Большое число «плагинов» и свободное определение настроек проекта позволяет использовать Jenkins в таких сценариях, для которых он изначально и не был задуман. Мы (в компании ZeroTurnaround) используем Jenkins как для сборки, непрерывной интеграции и координации выпуска новых версий продукта, так и для распространения кода между репозиториями, как замену cron-а, для мониторинга серверов и т.д. В этом докладе я хотел бы поделиться успехами и неудачами в использовании Jenkins при разработке не самых обычных продуктов, особенно в плане тестирования.

Тип выступления: Доклад (50 минут)

Порядка 10 лет опыта разработки Java приложений. Работал ведущим разработчиком и лидером команды разработчиков в Swedbank. С 2010 работает в ZeroTurnaround и отвечает за разработку продукта JRebel. Антон также является лидером Estonian JUG и соорганизатором большого сообщества разработчиков в Таллине – Devclub.eu.

Три способа поднять Jenkins CI для ваших автотестов

Заметка, в которой я решил поделиться знаниями в организации CI для автотестов. Такая задача возникает практически на каждом проекте, так как автоматизация без CI сервера - это как хлеб без масла. Я уже писал про Travis CI. теперь посмотрим на Jenkins.

Основным источником информации относительно Jenkins является официальный сайт jenkins-ci.org .

Я покажу три способа запуска Jenkins CI и дам определенные советы и пояснения относительно каждого способа. Для тех же, кто не знаком с CI процессом и Jenkins, советую посмотреть видео .

Итак, начнем с самого простого.

Способ 1: Запустить Jenkins war в консоли

Самый простой и банальный способ - скачать jenkins.war и запустить его, как простое java приложение. Для этого нужно открыть консоль cmd Windows или terminal Unix и набрать команду:

После того как выполните данную команду в вашей системе запустится jetty сервер; если в вашей консоли появилась надпись типа jenkins is fully configured and running, значит вы смело можете открывать браузер и по стандартному пути

у вас появится главная страница Jenkins.

Данный способ является самым простым и самым ненадежным. Ни в коем случае не используйте его в production. Если вы закроете консоль, то ваш CI сервер свалится, информация о созданных job и установленные плагины сохранятся, вы сможете зайти на хост и снова запустить сервер таким способом, но вот захотите ли вы это делать часто - это вопрос. Данный способ больше подходит для демонстрационных случаев, либо как временная мера.

Способ 2: Запустить Jenkins на Tomcat

Самый распространенный и надежный способ - настроить Tomcat сервер и запустить Jenkins как стандартное web приложение.

Скачиваем Tomcat 7 и распаковываем его в удобное для вас место. Если у вас Windows - это скорее будет корень раздела C. Проще всего сделать TOMCAT_HOME в глобальных переменных, дабы иметь доступ к Tomcat в консоли.

После того, как вы скачали Tomcat, нужно скопировать скачанный jenkins.war по пути:

Затем перейти в папку $/bin

В этой папке вам нужно найти скрипт под названием catalina.bat либо catalina.sh. Далее нужно запустить этот скрипт. Для Unix это выглядит так:

После этого вы увидите в консоли вывод типа:

Теперь можете смело открывать в браузере

Если вы делаете это в первый раз, то, возможно, придется немного подождать перед тем, как Jenkins станет доступен. Обычно это занимает меньше минуты.

Как я уже говорил, это самый распространенный способ и самый надежный. Большинство java web приложений работает на Tomcat. К тому же, в случае какого-либо падения вы сможете посмотреть лог файл Tomcat и разобраться, в чем же дело. В своей практике мне приходилось разбираться один раз, да и то Tomcat упал только из-за того, что закончилось место на диске.

Способ 3: Использовать Docker контейнер

Docker. ну куда же без него! Сейчас контейнеры набирают огромную популярность. Могу смело заявить, что в какой-то степени - это тренд. Если вы не знакомы с этой технологией, настоятельно рекомендую почитать и посмотреть на этого "зверька".

Для запуска докер контейнера у вас на компьютере должен быть предустановлен Docker. Установку смотреть здесь .

Теперь можем спокойно запускать наш контейнер.

В результате выполнения этой команды Docker скачает контейнер и запустит его. Внутри контейнера находится Tomcat с предустановленным Jenkins CI. Вот и все, с Docker эта процедура выглядит очень просто.

Данный способ мало в чем уступает способу с Tomcat, так как внутри контейнера находится такой же Tomcat сервер. Единственный недостаток - это то, что при падении или остановке вашего контейнера вы потеряете всю информацию. Чтобы избежать таких печальных последствий, советую детально почитать документ и запускать контейнер такой вот командой:

Таким образом все содержимое папки jenkins_home будет сохранено на вашей host машине и потери данных не произойдет.

На этом у меня все, подписывайтесь на блог в социальных сетях и через имейл. В следующий раз я покажу как подключать и настраивать слейвы к Jenkins CI. До встреч.

Знакомство с jenkins

23 сентября 2014 г.

Бороздя просторы интернет-форумов, посвящённых сетевым технологиям, я услышал упоминание о неком Jenkins. Расспросы форумчан ответа не принесли, а лишь сильнее запутали — каждый говорил о своём. Кто-то утверждал, что это система для постоянного контроля запущенных в системе процессов. Кто-то — что это средство мониторинга ресурсоёмких скриптов. А кто-то — и вовсе утверждал, что это набор плагинов с рутинными функциями для server-side скриптов. Туману нагнали порядочно.

И тогда я решил самостоятельно поискать ответ на вопрос. Вооружившись своим любимым google nexus 7 и кружечкой кофе, я засел за поисковик. Первым делом выяснилось, что создатель сего продукта ранее работал в Sun Microsystems, что автоматически означало использование Java на определённых этапах работы. Также выяснилось, что Jenkins – ответвление от Hudson. Все эти общие слова мало проясняли ситуацию. Оставалось попробовать самому и понять, нужно ли мне это.
Давайте по шагам разберёмся, как использовать jenkins в работе. По большому счёту, это набор утилит для автоматизации множества процессов — от пересборки ОС на сервере до обеспечения непрерывного контакта с облачными файлохранилищами. Например, он может отслеживать работу cron — при сбое в обслуживании авария будет автоматически устранена в соответствии с директивами отслеживания.
Начало работы

Вся работа ведётся через сервер Jelastic. Зарегистрируйтесь там и в личном кабинете нажмите “Create environment”. Выберите используемый сервер и подождите, пока окружение будет создаваться.

Пока это происходит, откройте официальную страницу Jenkins и скачайте по ссылке в правом верхнем углу последнее обновление Jenkins.war.

К этому времени на Jelastic уже всё должно быть готово. Найдите кнопку “Upload archive” и загрузите скачанный файл. Если у вас на одном сервере будет работать несколько приложений, то нужно будет разнести их в отдельные папки (на каждый URL по одной). В противном случае оставьте ROOT.

Теперь сохраните и нажмите рядом с именем созданного окружения значок «Открыть в браузере». Всё, теперь у вас есть свой Дженкинс.

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

Обратите внимание — для работы Jenkins у вашего хостера должен быть свой сервер API. К сожалению, это довольно редкая услуга, на территории России есть только два таких хостера. Обязательно свяжитесь с техподдержкой и уточните этот момент перед настройкой сервера.