Прошло более двух лет с тех пор, как я впервые написал о том, как мы объединили контейнеры Docker и Jenkins для создания недолговечных сред сборки для многих серверных программ Riot Games. На сегодняшний день в этой серии семь статей, и мы также получили много отзывов, сообщений, технических идей, советов и историй о том, как использовать контейнеры для выполнения всевозможных интересных вещей. В мире технологий два года — это большой срок. Серия хоть и полезная, но уже устарела. Многие из последних гаджетов Docker отсутствуют. Вместо того, чтобы писать целую новую серию блогов, я решил вернуться и обновить свой первоначальный пост. Вы можете найти полную серию постобновлений здесь:
-
Part I: Thinking Inside the Container(глубоко подумать о контейнерах)
-
Part II: Putting Jenkins in a Docker Container(Поместите Дженкинса в контейнер Docker)
-
Part III: Docker & Jenkins: Data That Persists(Докер и Дженкинс: постоянные данные)
-
Part V: Taking Control of Your Docker Image(Управляйте своим изображением Docker)
-
Part VI: Building with Jenkins Inside an Ephemeral Docker Container(Сборка с Jenkins во временном контейнере Docker)
-
Part VII: Tutorial: Building with Jenkins Inside an Ephemeral Docker Container(Учебник: сборка с помощью Jenkins во временном контейнере Docker)
-
Part VIII: DockerCon Talk and the Story So Far(выступление на DockerCon и текущая история)
Сегодня я хочу поделиться тем, чему мы в Riot научились за два года использования Docker и Jenkins. Для тех, кто знаком, я также подробно опишу все обновления и изменения, которые я сделал для этой серии, а также изменения контейнера Docker и Jenkins.
экосистема разработчиков
Еще в 2016 году, когда я впервые взялся за перо, было не очень удобно устанавливать Docker и использовать его на рабочем столе. В то время Docker Toolbox был лучшим инструментом для настройки рабочего стола. Этот инструмент настраивает Virtualbox на рабочем столе и запускает Docker на виртуальной машине Linux. Docker предоставляет творческое клиентское приложение под названием Docker Machine для создания и управления виртуальными машинами (и некоторых других, если хотите). Эта установка работает хорошо, но очень тяжеловесна.
Docker теперь предоставляет собственные установщики для Windows и OSX. Хотя гипервизоры теперь более локализованы и не требуют Virtualbox, они по-прежнему полагаются на решение в стиле гипервизора. В качестве бонуса Docker для Windows может работать в режиме «собственного окна», что позволяет контейнерам Windows Docker извлекать выгоду из совместной разработки Microsoft. Оба решения похожи на интегрированные настольные клиенты, которые значительно упрощают работу с Docker благодаря удобным меню и параметрам настроек на основе графического интерфейса. Я обновил серию блогов, чтобы отразить эти дополнения, что, в свою очередь, упрощает объяснение того, как начать работу!
ИЗМЕНЕНИЯ ДОКЕРА
В 2016 году версия Docker была около 1.10, а Docker composer практически не поддерживает Windows. Наше развертывание также зависит от версии Docker Swarm 0.3.0. Docker 1.12, анонсированный на DockerCon в конце того же года, ознаменовал серьезную эволюцию. За эти два года в Docker было внесено слишком много изменений, чтобы вдаваться в подробности, но некоторые из них повлияли на руководство.
DOCKER VOLUMES
Вероятно, самым важным изменением в Docker является добавление Docker Volumes. В версии 1.10 Docker вам по-прежнему необходимо создать «контейнер данных Docker» для инкапсуляции постоянства хранилища, если вы не хотите монтировать данные с хоста. Это создает полупостоянный том в Docker, из которого другие контейнеры могут подключаться и обмениваться данными. Это удобно, но сопряжено с некоторым риском, потому что, если вы хотите поддерживать хранилище, по крайней мере один контейнер должен указывать на тома внутри контейнера данных. Это делает не идеальным использование такой настройки на рабочем хосте Docker, на самом деле мы используем эту настройку только в локальной среде разработки в Jenkins.
С введением настоящей поддержки томов вы можете создавать, называть и управлять томами, которые могут быть независимыми от контейнеров или образов с множеством интегрированных команд. Тома существуют до тех пор, пока вы намеренно не удалите их с хоста Docker, и они даже интегрированы с подключаемыми модулями хранилища для поддержки общих томов данных в кластерах (если вы того пожелаете). Я обновил свой блог об устранении громоздких контейнеров томов данных и определении и создании томов Docker для хранения данных. Я думаю, вы найдете этот подход более интуитивным. На самом деле, многие из вас писали и оставляли отзывы о том, что такой переход давно необходим.
ты сможешьздесьПодробнее о Docker Volumes и их различные функции хранения.
DOCKER NETWORKS
Во времена Docker в 2016 году, до Docker 1.12, для того, чтобы два контейнера могли взаимодействовать друг с другом, требовалось вручную идентифицировать открытые ими порты, знать IP-адрес хоста Docker или использовать ссылку Docker, которая была действительна на том же хосте. В исходном руководстве я предложил получить ваш IP-адрес для установки виртуальной машины с поддержкой Docker и передать его нескольким сценариям, чтобы ваша установка Jenkins могла изменять такие вещи, как NGINX и внутренние конфигурации. Это делает такие вещи, как «localhost», почти невозможными для ссылки на простой DNS. Это также означает, что мы должны соединить два контейнера с помощью контейнеров, чтобы они могли легко найти друг друга.
Сегодня Docker представил сеть Docker. С появлением Docker на Mac и Windows узлы Docker теперь используют только локальный IP-адрес машины; ссылки на контейнеры считаются устаревшими и устаревшими. Как и тома, сети можно создавать, называть и поддерживать независимо, без каких-либо контейнеров или образов. Контейнеры могут подключаться к сети, и даже самый простой Docker обеспечивает обнаружение сервисов и предоставляет доступ ко всем контейнерам в сети через DNS.
Это позволило нам полностью переосмыслить многие аспекты туториала и локальной настройки Jenkins. Чтобы Jenkins и NGINX могли общаться друг с другом, я отказался от ссылок на контейнеры и вместо этого поместил их в сеть Docker. Точно так же я перенастроил параметры сборочных докеров в конфигурации Jenkins, чтобы они были подключены к одной сети, и мастер Jenkins можно было легко найти.
Вся установка теперь автономна и больше не требует предоставления IP-адреса. Мы также можем исключить громоздкие сценарии запуска для переименования полей в конфигурации Jenkins.
Новые функции обширны и работают во всем кластере Docker Swarm, позволяя легко объединять контейнеры между хостами. ты сможешьздесьУзнайте больше о сетевых функциях Docker.
DOCKER COMPOSE
Многие изменения также были замечены в Docker Compose. В дополнение к полной поддержке томов и сетей, он также получает полную встроенную поддержку Windows. Это означает, что теперь я почти исключительно использую Docker composer для запуска на своем рабочем столе при создании мультиконтейнерных приложений. Compose делает имена очень простыми и создает несколько сетей, томов и «сервисов» (многоконтейнерные приложения). Документ спецификации также претерпел некоторые изменения и теперь находится в версии 3. Вы обнаружите, что я полностью принял последнюю версию Docker Composer, и соответствующие файлы конфигурации были обновлены.
ты сможешьздесьУзнайте больше о последних изменениях в Compose.
DOCKER PROXYING
С таким количеством изменений в Docker и переключением на собственную установку Docker возникла проблема. Чтобы установка Jenkins динамически создавала ведомые устройства сборки, чтобы они вели себя как контейнеры Docker, она должна взаимодействовать с Docker на рабочем столе системы, как если бы это был хост Docker. По иронии судьбы, когда хост Docker работает на виртуальной машине внутри Virtualbox, это довольно просто, поскольку он имеет собственный локальный IP-адрес и может быть настроен для небезопасного прослушивания порта 2375 или порта 2376 с сертификатом TLS. Старые учебники позволяют вам получить эти сертификаты и безопасно взаимодействовать с этим терминалом.
Теперь Dockerhost не выставляет себя в общедоступный Интернет из соображений безопасности, и это изменение усложняет настройку разработки Jenkins и создает уникальные проблемы для Windows и Mac. В OSX я решил сделать это, используяsocat, решает проблему, открывая файл сокета Docker на порту 2375 в сети Docker (который по-прежнему не предоставляет этот файл для общедоступной сети). Это значительно упрощает обмен конфигурацией с Jenkins. Этот трюк не работает в Windows, потому что там нет файла сокета Docker. Поэтому я решил открыть открытый порт 2375 только в Windows. Технически это означает, что конфигурация Windows в этом руководстве менее безопасна, чем OSX.
ты будешьПредыдущий урокПодробное пошаговое руководство по этим изменениям можно найти в Jenkins, где установка Jenkins полностью оптимизирована для специальных случаев использования.
Другие изменения DOCKER
Как видите, Docker сильно изменился за два года. В этой серии руководств вы найдете множество мелких деталей, таких как параметры времени сборки Docker, метки и другие небольшие настройки, отраженные в файлах Docker. Есть много замечательных новых функций, но они не полностью меняют характер учебника, поэтому я оставлю их вам, чтобы вы сами их открыли.
ДЖЕНКИНС меняется
Как и в случае с Докером, время Дженкинса неуклонно движется вперед. Когда я пишу этот урок, Jenkins 2 только что вышел в свет. Плагин Docker проходит очень раннюю итерацию, кодовая база разветвляется наЕще один плагин для Docker.. В конечном итоге Jenkins по-прежнему работает так же, как и два года назад, однако в настройке, конфигурации и настройках Jenkins Dockerfile было внесено множество изменений, которые позволяют взаимодействовать с хостом Docker и создавать подчиненные устройства.
Версия ДЖЕНКИНС
В этом руководстве теперь используется Jenkins v2.112 (последняя версия на момент написания). Большинство критических изменений содержится в пошаговом руководстве по Dockerfile, которое демонстрирует, как Cloudbees настраивает файлы Docker, такие как базовый контейнер ОС, переменные, представленные в файлах докеров Jenkins, параметры запуска и Java, а также сценарии.
DOCKER PLUGIN(S)
Самое большое изменение в этой области связано с плагинами для динамического разветвления контейнеров Docker с сервера при сборке. В 2016 году, когда я заканчивал серию своих блогов, еще один плагин Docker только что вышел в свет как форк плагина Docker. Этот плагин постоянно улучшался и рождались новые версии, в то время как исходный плагин Docker не менялся примерно год. Плагин Docker был только недавно возрожден разработчиками Cloudbees, и теперь оба плагина имеют очень разные конфигурации. Я провел обширное тестирование, и оба работают хорошо. Возможно, плагин Docker легче настроить в этом руководстве, поэтому он выделен на протяжении всего руководства.
Независимо от того, какой плагин вы используете, я бы посоветовал отказаться от настройки подключения SSH, о которой я писал в 2016 году. Вместо этого оба плагина предоставляют другой способ использования обратного соединения JNLP с Jenkins, что значительно повысит скорость и производительность. Кроме того, это упрощает настройку и настройку специальных сборок. Поэтому это руководство было обновлено, чтобы исключить метод подключения SSH и придерживаться более простого метода.
Итак, какой плагин выбрать в конце концов?В 2016 году мне начал нравиться другой плагин Docker, потому что, когда дело доходит до Jenkins, мне всегда нравится плагин в разработке. Недавно, благодаря поддержке Cloudbees для плагина Docker, который, как я подозреваю, является, вероятно, лучшим долгосрочным использованием, наше следующее обновление будет сосредоточено на последней версии.
Больше извлеченных уроков
Два года — это долгий срок для решения проблем с эксплуатацией больших и сложных систем, таких как развертывание Riot Jenkins. Скорее всего, я забуду все мелочи, которым мы научились на этом пути. Тем не менее, я думаю, что здесь есть несколько важных уроков, о которых стоит упомянуть.
масштаб
Наш кластер Jenkins растет с момента публикации первой статьи. Во время написания предыдущей статьи я полагал, что описанная нами установка Docker Jenkins определяла около 1000–2000 заданий с пиковыми значениями 120–200 заданий в час. Теперь наши серверы могут обрабатывать в среднем 200-400 заданий в час, с пиковым значением около 600 и более 7000 заданных заданий.
Это, конечно, сильно нагружает систему. Мы по-прежнему используем версию 0.15 плагина Docker на этом сервере (которую мы обновим позже), но нам нужно выполнить несколько раундов ограничения экземпляров в контейнере. Наши пользователи начинают очень хорошо разбираться в Jenkins и будут создавать несколько процессов, позволяя 5, 10 или даже 20 контейнерам одновременно обрабатывать транзакции параллельно. Старые версии плагина не могут справиться со всеми этими ситуациями, особенно при использовании SSH. Мы обнаружили, что от 5 до 10 экземпляров среды непосредственной сборки были лучшей конфигурацией для нашего варианта использования.
среда сборки
За два года, когда мы использовали эту настройку, наши пользователи создали около 240 уникальных сред сборки с более чем 7000 заданий. После обучения, обучения, бесед и отзывов это число сократилось примерно до 150-180 человек. Мы обнаружили, что многие люди создают уникальные среды, когда на самом деле могут использовать общие настройки, такие как разработка программного обеспечения на Java или Go. Мы продолжаем выступать за слияния. Мы обнаружили, что в различных командах Riot большинство различных настроек по-прежнему существуют в сообществах разработчиков Python и NPM и в основном состоят из настроек управления пакетами и среды.
В качестве службы мира мы предоставляем услуги базовой сборки для различных операционных систем (Alpine, Ubuntu и Centos), поэтому команды, использующие наши инструменты, могут работать вместе со своими менеджерами пакетов. В дополнение к этому мы также предоставляем варианты использования ведомых устройств Python, Java и Go, а также базовый набор служебных скриптов. Мы усвоили важный урок, что обновление этих систем на самом деле довольно болезненно. Когда Дженкинс переключается на использование Java
Версия 1.8 была обязательной, когда нам нужно было обновить среду сборки всех в течение нескольких дней, в течение которых сборки многих команд не работали. Это никогда не подходящее время для команд с основными услугами.
После обновления мы выступали за минимальное количество содержимого в базовой среде сборки. Мы начали использовать множество предустановленных скриптов и инструментов, а также устанавливать или устанавливать их в контейнеры во время выполнения с помощью простой загрузки с сервера. Во многих случаях мы переносили утилиту в библиотеку Groovy, которая совместно использовала конвейер Jenkins (помещение кода в среду было самым простым/быстрым вариантом).
JENKINS PIPELINE
Из 7000 заданий в нашей конфигурации Docker Jenkins почти 4400 являются заданиями конвейера Jenkins. Мы использовали функциональность глобальной библиотеки Pipeline Jenkins для создания набора общих функций конвейера. Большинство этих пользовательских библиотек упрощают взаимодействие с различными хранилищами артефактов и системами Riot. Некоторые просто упрощают использование каналов, сводя к минимуму синтаксис и используя обычные значения по умолчанию. Вскоре я напишу в блоге о наших универсальных функциях.
Основная причина, по которой количество рабочих мест в Pipeline выросло как на дрожжах, заключается в том, что мы начали создавать то, что я называю «непрерывная доставка как услуга». Большая часть внутреннего программного стека Riot была интегрирована в сервисы Java или Go, большинство из которых используют одну и ту же программную библиотеку ядра. Поэтому мы попросили команду поместить в репозиторий кода простой Jenkinsfile, содержащий только данные конфигурации для этих сборок. Мы используем общую библиотеку Jenkins для использования этих файлов и общий конвейер для создания нашего программного обеспечения. Таким образом, для создания команд с этими фреймворками инженеры по сборке не нужны. На самом деле командам не нужно писать единый сценарий сборки для выпуска своего программного обеспечения, потому что даже их работа по развертыванию автоматизирована. Подробнее об этом введении будет в будущем блоге!