На моей нынешней позиции мы определяем непрерывные сборки интеграции для всех наших проектов в Dockerfile Анкет Для нас Docker предоставляет набор гарантий, которые идеально подходят для CI.
- Сборки Docker воспроизводимы.
- Docker доступен на каждой крупной ОС.
- Docker производит универсальные артефакты.
Сборки воспроизводимы повсюду
Стандартная сборка Jenkins работает непосредственно по системе. Это ничто против Дженкинса, но если вы просто строите необработанный узел, у основного экземпляра будет расхождения. Это может быть патч безопасности, библиотечные версии или даже версии ОС. Для нас бегун может быть Ubuntu или OSX. Это означает, что устаревшие местные пакеты вызывают сбои сборки. Не поймите меня неправильно, это худший сценарий. В худшем случае всегда случается в DevOps.
Идеальное состояние нашей сборки — «воспроизводимое состояние». Успешная сборка, которая является повторным, должно добиться успеха с тем же результатом. Сборка, которая меняется между пробежками того же самоубийства, означает, что кто -то где -то запутался. Наиболее то, что вы не зависите от построения версий … Я не говорю, что у нас была такая проблема, но у нас была такая проблема.
Красота Docker Builds, они неизбежны, если вы не пытаетесь очень сильно, например, не разжигание версий. Шаги в Dockerfile Беги в одном и том же порядке каждый раз. Замечательно.
Самая большая благо — это система, которая запускает сборку, не нужно заботиться о том, какой язык или пакеты являются потребностями в сборке. Docker Build Randles, которые через Dockerfile Вместо этого в охватывающей ОС. Нет никаких приемов для создания виртуальных сред, как в Python. Нет условий гонки, в которых пакеты установлены различными сборками. Все самостоятельно и намного быстрее, чем вращение свежей выделенной виртуальной машины.
Яркий вопрос, который можно задать: «Почему бы не использовать уже встроенные среды Docker Runner, которые CI Solutions, такие как Jenkins, поддерживают?» Да, это решение, но оно не решает другую проблему.
Запустить сборки В любом месте
Запуск сборки в любом месте — это мечта, преследуемая многими разработчиками. Если мы гарантируем, что если сборка работает в системе DEV, будет работать в производстве, это золото. Docker — это решение проблемы. Сборка Docker, которая работает на Windows, будет работать на Mac. Конечно, это хитрость, если вы слишком усердно посмотрите на человека за занавеской (виртуальная машина работает Linux). Разработчики обычно не заботятся об этом. Когда сборка и ее тесты преуспевают на их машине, но терпят неудачу на коробке сборки, они по праву расстроены. Так почему бы не позволить им запустить тот же процесс на своей машине, который использует ящик Jenkins?
Эта портативность обеспечивает надежные сборки и повышение производительности разработчиков. Файлы трубопроводов Jenkins в лучшем случае непрозрачны, поэтому мы не ожидаем, что разработчики будут изучать синтаксис. DevOps также не хочет писать новый файл Jenkins для каждого проекта. Скорее, мы призываем каждую команду писать свой проект Dockerfile Анкет После того, как горб докерфобии преодолен, команды станут более продуктивными, поскольку они не ждут DevOps для их изменений в сборке. Им даже не нужно запускать свои дженкинс, чтобы увидеть, потерпит ли это. Меньше отходов в целом.
Как боковой анекдот, я объяснил эту систему сборки своим другу. Он реализовал это на новой службе, над которой работала, над которой работала, выполняя сборку AWS Codebuild. По разным причинам Codebuild не было лучшим решением, поэтому он перенес все в Circleci. Общий процесс занял у него 45 минут, потому что все сценарии сборки были в Dockerfile S уже. Я не говорю, что вы не можете двигаться так быстро с обычными системами сборки, но стоит отметить.
Docker как артефакты
Докеры — отличный универсальный артефакт для систем сборки. Связано с Запустить сборки Где угодно Вы можете развернуть Dockers практически везде. Это своего рода точка зрения докеров. Что еще интереснее, мы можем использовать Dockers в качестве хранилища для библиотек.
Мы немного экспериментировали с этим за последний год. Каждая библиотека построена с использованием Docker, как описано выше. Полученное изображение никогда не используется в одиночку, так как сам Docker является хранилищем этого артефакта. Затем, когда другие сборки Docker нуждаются в библиотеке, мы импортируем эту зависимость вверх по течению, используя многоэтапные сборки Docker.
FROM cool-java-lib:2.0.0 as lib FROM openjdk as builder RUN mkdir /app WORKDIR /app COPY --from lib mavencache/* mavencache/* COPY ./src/* /app/src RUN mvn build
Это не идеальное решение, так как это требует, чтобы мы все еще подталкиваем библиотеку к репо Nexus для локальной разработки. В целом, это не рекомендация. Это то, что нужно учитывать, если у вас есть проблемы с репо внешними библиотеками, и вы хотите ограничить зависимости только репозитором Docker во время сборки.
Недостатки
Существуют недостатки в использовании сборки Docker для CI. Большой — это использование самого докера. Контейнеры — это отличные вещи, но они могут быть тяжелее, чем кэшированная библиотека. В некотором смысле это не может быть правдой на уровне хранилища, поскольку мы можем повторно использовать слои. Вы не можете сделать это в Maven Repos. Это кэширование требует хорошего знания о том, как работают слои Docker.
Интимное понимание того, как использовать Docker для создания программного обеспечения, является входным барьером для разработчиков. Докеры часто кажутся этой волшебной технологией, которую сообщество DevOs DevOps. Из -за этого есть гораздо более первоначальная работа, чтобы привести к скорости Dockers Dockers, но хвост, как правило, намного лучше в нашем опыте.
Реальность
Мы использовали Docker Builds, подобные этой, большую часть года, и это сделало жизнь намного проще. У каждого есть гораздо лучшее представление о том, как строятся проекты и что именно пошло не так. Это для всех? Нет, ничего нет. Это работает для нашего варианта использования, поскольку мы в значительной степени полагаемся на системы оркестровки контейнеров и имеем такой опыт. В случаях, когда мы не используем контейнеры для запуска системы, нам нужно обустроить этот стиль сборки. Это меньшинство наших услуг, и преимущества пока великолепны. Как и все в DevOps, у нас будет другая философия за 6 месяцев.
Оригинал: «https://dev.to/kaikeru/continuous-integration-builds-using-docker-1ifa»