Непрерывная поставка: CI Tools Setup

Это вторая статья в серии «Непрерывная доставка». Мы продолжим то, что оставили в разделе Введение в концепции и инструменты . Целью этой статьи является локальная настройка сервера Jenkins с помощью автоматического и повторяемого процесса со всеми артефактами, хранящимися в репозитории GIT. Для этого потребуются такие инструменты, как VirtualBox и Vagrant . Это также потребует регистрации в Docker . В отличие от предыдущей статьи, в которой содержалась только общая информация, в этой статье мы должны запачкать руки и следовать примерам.

Что нам нужно для того, чтобы сервер Jenkins был запущен и работал локально? Нам нужна виртуальная машина или доступный сервер, операционная система установлена ​​и настроена, Jenkins установлена ​​и настроена. Поскольку все, что мы делаем, должно быть надежным и повторяемым, нам также понадобится система контроля версий. Примеры в этой статье будут использовать GitHub в качестве VCS.

Для примеров, приведенных в этой статье, требуется следующее программное обеспечение: VirtualBox , Vagrant , Docker , учетная запись GitHub и GIT-клиент (мы используем TortoiseGIT, но любой другой должен это делать). Пожалуйста, обратитесь к вышеупомянутым сайтам для инструкций по установке.

Весь код из этой статьи можно найти в репозитории TechnologyConversationsCD GitHub.

Vagrant: виртуальная машина с операционной системой

Мы создадим машину VirtualBox . Сам процесс будет сделан с Vagrant.

Vagrant — это инструмент для создания среды. Хотя его можно использовать для создания полноценной среды, мы будем использовать его только для создания виртуальной машины с сервером Ubuntu. Процесс очень прост. Создайте файл с именем Vagrantfile. Содержимое этого файла должно быть:

Полный исходный код можно найти в Vagrantfile .

Ключевая строка начинается с config. *. Он указывает, какой сервер мы хотели бы установить. Проще всего использовать одну из уже созданных коробок из Vagrant Cloud Service . Для этой статьи я выбрал стандартную 64-битную версию Ubuntu 12.04 LTS под названием «hashicorp / точный 64».

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

Когда запускается с первого раза, загрузка коробки занимает некоторое время. После этого создание виртуальных машин будет практически мгновенным. Отныне мы можем войти в нашу новую виртуальную машину Ubuntu. По умолчанию IP-адрес 127.0.0.1:2222 с именем пользователя и паролем vagrant / vagrant. Запустите ваш любимый SSH-клиент ( Putty всегда хороший выбор) и поиграйтесь с вашим новым сервером.

После этого мы приступим к настройке Docker.

Докер: Дженкинс сервер

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

Давайте создадим Ubuntu контейнер с Jenkins. Для этого нам нужно создать Dockerfile со следующим содержимым:

Полный исходный код можно найти в Dockerfile .

Docker использует свой собственный предметно-ориентированный язык (DSL), который довольно прост. Я кратко пройдусь по инструкциям, использованным в приведенном выше файле. Для получения подробной информации, пожалуйста, обратитесь к документации Docker .

• FROM : инструкция FROM устанавливает базовый образ для последующих инструкций. В нашем случае базовый образ — это Ubuntu, который можно найти в общедоступном хранилище Docker. Мы создадим эту базу и настроим сервер Jenkins.
• ПОДДЕРЖКА : Имя и адрес электронной почты автора. Цель чисто информационная.
• RUN : инструкция RUN выполнит любую команду в новом слое поверх текущего изображения и зафиксирует результаты. Он имеет несколько форм. Тот, который мы используем, просто выполняет команды оболочки, как они написаны.
• ADD : инструкция ADD скопирует новые файлы и добавит их в файловую систему контейнера.
• ENTRYPOINT : ENTRYPOINT помогает вам настроить контейнер, который вы можете запускать как исполняемый файл. То есть, когда вы указываете ENTRYPOINT, весь контейнер запускается так, как если бы он был только этим исполняемым файлом. В нашем случае мы говорим Docker запустить WAR-файл Jenkins.
• EXPOSE : инструкции EXPOSE информируют Docker о том, что контейнер будет прослушивать указанные сетевые порты во время выполнения. Поскольку Jenkins использует порт 8080, мы должны предоставить его процессам, выполняющимся вне контейнера.

Следующим шагом является отправка только что созданного файла в репозиторий GitHub и настройка Docker на сборку контейнера каждый раз, когда мы меняем содержимое этого файла. В остальной части статьи предполагается, что читатель зарегистрирован в Docker.

Перейдите в свой профиль Docker, выберите «Авторизованные сервисы», затем «Перейти к приложению». Нажав «+ Добавить»> «Добавить надежную (исходную) сборку», мы можем добавить соединение из Docker к нашему репозиторию GitHub. Пожалуйста, следуйте инструкциям на экране для остальных шагов.

За сборкой нашего нового контейнера можно следить на странице Docker статуса сборки. После этого (активный статус) вновь созданный контейнер готов к использованию. Я назвал мой контейнерный репозиторий vfarcic / cd_jenkins. Он установлен для публичного доступа, поэтому каждый может его использовать. Остальная часть статьи будет использовать этот контейнер Docker. Если вы следовали инструкциям и создали свои собственные, измените vfarcic / cd_jenkins на имя, которое вы использовали.

На данный момент у нас есть виртуальная машина, созданная с помощью VirtualBox и Vagrant. На этой виртуальной машине установлена ​​только ОС Ubuntu. С другой стороны, мы создали докер-контейнер с сервером Jenkins. Этот контейнер можно использовать практически на любой машине, где он нам нужен. Это может быть физический сервер, виртуальная машина, ноутбук и т. Д.

Виртуальная машина с сервером Jenkins

Следующий шаг — совместное использование Ubuntu VM и Jenkins. Для этого мы должны вернуться к нашему Vagrantfile и указать, что мы хотим, чтобы наш контейнер устанавливался и запускался при каждом запуске виртуальной машины. Vagrant поддерживает разных провайдеров.

Поставщики в Vagrant позволяют автоматически устанавливать программное обеспечение, изменять конфигурации и многое другое на компьютере как часть процесса vagrant up. Основным поставщиком являются сценарии оболочки. Для простых проектов они работают нормально. Однако сценарии оболочки очень быстро становятся громоздкими. Для этой цели Vagrant поддерживает Ansible, CFEngine, Chef, Puppet, Salt и Docker. Как вы, наверное, догадались, мы продолжим использовать Docker. Я призываю вас изучить все остальное.

Модифицированный Vagrantfile выглядит следующим образом:

Мы добавили две новые инструкции. Первый — предоставление. Он сообщает Vagrant, что нужно использовать Docker Provider, запустить только что созданный нами контейнер (vfarcic / cd_jenkins) и предоставить ему аргумент -p, указывающий, что вся связь с контейнером через порт 8080 Jenkins должна быть перенаправлена ​​на 46153.

Теперь у нас есть Jenkins, работающий на порте 46153. Чтобы сделать этот порт видимым вне Vagrant, нам нужно снова переадресовать этот порт, используя сетевую инструкцию.

Чтобы применить изменения, которые мы только что внесли в уже работающую виртуальную машину, выполните следующее:

При перезагрузке мы перезагружаем виртуальную машину. Provision указывает vagrant включить инициализацию (в данном случае с Docker). Перед выполнением инструкций Docker Vagrant установит Docker, если он не существует (как в случае с нашим сервером Ubuntu).

Это большой момент! Откройте http: // localhost: 4567 в своем любимом браузере и начните использовать только что созданный сервер Jenkins.

Резюме

Хотя на первый взгляд весь процесс может показаться сложным, с небольшой практикой он очень прост и интуитивно понятен. В результате мы имеем виртуальную машину, которую можно легко создавать, уничтожать, умножать, распространять и т. Д. (Дополнительную информацию см. В документации Vagrant). Эта виртуальная машина поставляется с контейнером Docker под управлением Jenkins. Докер не зависит от Vagrant и такой же контейнер можно поставить на любой другой компьютер. Обычной практикой является использование Vagrant в качестве инструмента для создания машин разработки, используемых локально. Как только мы закончим с машиной, она может быть приостановлена ​​(и позже возобновлена) или уничтожена (и позже воссоздана). В некоторых случаях Vagrant используется и в производственной среде. Однако более оптимальным является использование только Docker без издержек, которые имеет виртуальная машина. Один сервер может запускать несколько контейнеров Docker без необходимости использования отдельных виртуальных машин с отдельными операционными системами.

Мы хранили два небольших файла в нашем репозитории GitHub (Vagrantfile и Dockerfile). С их помощью мы можем воссоздать один и тот же процесс столько раз, сколько необходимо. Что еще более важно, наличие редактируемых текстовых файлов позволит нам легко построить поверх этой статьи и расширить наше решение.

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

До публикации следующей статьи я призываю вас изучить Vagrant и Docker более подробно.

А как насчет Трэвиса и других решений?

В предыдущей статье я обещал, что мы будем работать как с Дженкинсом, так и с Тревисом, но я даже не упомянул последнее. Это потому, что мы будем использовать облачный сервер Travis, который уже установлен, и все, что для этого требуется, — это регистрация. Цель этой серии — показать, как настроить серверы и потоки непрерывной интеграции (а затем и непрерывного развертывания и доставки). В зависимости от ваших потребностей, вы можете настроить его самостоятельно (как мы только что сделали с Jenkins) или использовать уже установленное облачное решение. Мы продолжим использовать Jenkins в качестве примера локально настроенного сервера, а Travis — в качестве одного из множества облачных решений. Это не означает, что не существует облачного решения Jenkins и что Travis не может быть установлен локально. Мы также рассмотрим эти варианты.

С момента публикации предыдущей статьи я получил предложения по нескольким альтернативным облачным решениям CI / CD. Начиная со следующей статьи, я увеличу наш стек до нескольких других облачных решений, кроме Travis.