Если вы включаете докер не в начале, значит вы вообще не поняли, зачем он нужен. Даже в минимальном приближении не поняли.
Я не знаю что вы имеете ввиду под «началом» и спорить не буду. Я написал, что с docker знаком уже больше 3х лет, и с вашей стороны говорить, что я ничего не понимаю — это грубо.
В нем описано все, что необходимо сделать, чтобы работало так, как оно работало у разработчика.
Разработчики должны писать качественный код приложения. Думать как написать модульный, чистый код. Думать над версионированием, следить за коммитами и чтобы ничего не попало в git репозитории, делать тщательное ревью кода. У них огромная поляна работы в которой использование docker никак не поможет!
Да? Вы уверены в этом? И версия JRE/NodeJS точно совпадает с тем, что тестировали QA?
Это работа CI. Он делает git fetch, прогоняет тесты и билдит проект. Можно сделать так чтобы он паковал результаты работы в docker образ и запускаться в контейнере если вы хотите
Действительно, где это видано доки читать в 2019 году.
Так хотелось бы что бы docker-compose делал еще кофе по утрам.
Я люблю читать тех информацию и применять ее в реальных проектах. Docker-compose это инструмент для запуска docker контейнеров, мне жалко тратить время на инструмент который я смогу применить в ограниченном круге, к тому же у него есть свои косяки и свое видение как должен выглядеть yml и как запускать контейнеры.
Ну тут очевидно виноват докер.
Нет, просто docker имеет низкий порог вхождения и к сожалению люди пишут криво
docker load
И эту процедуру нужно постоянно делать при каждом деплое?
Но используют ansible, который бажный раз в 50 больше, чем сам докер когда либо был
Ansible не тащит какой либо экосистемы на сервер, ему нужен только ssh и python интерпретатор. Бага в Ansible может привести только к тому что на серваке что то не запустится во время проигрывания плейбука.
Как баги в Ansible пересекаются с багами в docker — не пойму
Я бы еще предложил не навязывать разработчикам всякие package.json.
Может вы имели ввиду package-lock.json? Если да то package-lock.json необходим в nodejs так как ссылается на точные коммиты кода.
Как там вам собирать по 5-10 разных проектов с разными зависимостями и бинарными либами
Соболезную вам в таком случае, ни разу не поддерживал 5 — 10 проектов одновременно да и тем более с разным стеком технологий
CI это процесс который связан только с исходным кодом, конфигурацией приложения (к какой бд подключиться, на каком порте запуститься, и тп), unit тестами
CD связан с доставкой артефактов сделанных CI на конечные сервера. Он ничего не знает про GIT, как его собирали из исходников. У него есть просто артефакты, и сервера на которых нужно запустить этот артефакт
В зависимости от приложения выбираешь метод распространения.
Нет, процесс как раз один и тот же, результат в tar.
по завершению CI зачем куда-то в архив писать?
Чтобы можно было потом запустить его либо на чистой системе, либо промежуточным этапом собрать докер образ с нужным окружением и запихнуть туда tar
Серверные приложения намного удобнее распространять через docker или vagrant или другие способы изоляции (как раз сохранение окружения)
БД это тоже серверное приложение, однако, позвольте спросить, она только в докере распространяется?
Postgresql можно запустить на чистом метале или… упаковать в докер образ
Приложение не отделимо от окружения, а окружение от работоспособности софта, скидывать бинарник который чёрт знает от чего зависит, или сорцы которые чёрт знает как собирать, просто быть самому себе злым буратино.
1. Сорцы в tar не будут, там готовые оттесченые артефакты
2. тарболы можно также организовать как и докер образы.
3. политику кто может загружать тарболл, ее можно настроить также как и в докер репозитории (если не лучше)
Я хочу написать отдельную статью про использования ансибла, как доставляю артефакты и запускаю сервисы) Впечатления отличные, вопрос только в понимаи как пишутся плейбуки, как делать reusable блоки чтобы не было копипаста. Из задач сейчас: сборка докер образов на машине где будет запускаться докер контейнер, запуск инфраструктуры типа бд, nginx, nexus.
Как минимум, автор не очень-то слышал про scm (ansible, salt, chef, puppet).
Я опечатался, нужно было написать docker pull. Использую ansible, был опыт работы с Chef и его кукбуками с рецептами. Infrastructure as code мне знакомо
Да, точнее не придумаешь :) Эту мысль нужно было подчернуть в статье но я поспешил и думал что это очевидно, своей поспешностью я только запутал Вас. Да, есть место где лежат готовые артефакты, результат сборки проекта. Их можно смело брать упраковывать в любую технологию, все должно работать
Как я понял, он предлагает заменить некоторую цепочку действий CI-сервера ручной загрузкой tar.gz в артифакторий с локальной машины, а потом делать docker из этого архива.
CI нужен, это как бот который реагирует на пуши и запускает сборки и заливает артефакт. Он не должен знать про docker…
Как я понял, он предлагает заменить некоторую цепочку действий CI-сервера ручной загрузкой tar.gz в артифакторий с локальной машины, а потом делать docker из этого архива.
Да, делать docker образ и добавлять туда артефакт простым скачиванием (не git clone, не компиляция, не прогон юнит тестов). На этапе сборки мне должно быть без разницы как этот артефакт оказался в бинарном репозитории, я просто априори знаю что это протестированный артефакт готовый к работе (иначе его не смогут запушить в репозиторий).
Этот артефакт могут пушить как разработчики так и наш CI который по коммитам сам будет собирать и заливать артефакт…
Ну то есть вместо 'а давайте CI и CD отдекаплим через артифактори' у вас вышло 'давайте избавимся от докера' :))))
Похоже что к сожалению так, поторопился с завершением статьи :)
Версионированием занимается CI-сервер, он и ставит таги. Базируясь на хэше коммита, например, или на semver. Более того, он может добавлять какие-то переменные или чистить конфиги при создании образа. Он же пишет тестировщику, что и откуда брать для тестирования.
Сколько раз я слышал эту мысль, не пересчитать… Давайте не будем затрагивать тему версионирования и кто должен проставлять теги. Это все сугубо индивидуально, и холивар еще тот
А чтобы не забыть, повесить липкий листочке на монитор? И рядом инструкцию, что именно надо оттуда вытереть, и эта инструкция постоянно дописывается каждым разработчиком.
Я не понимаю в чем даже докер вам поможет если проект будет собран с зашитыми настройками
Да, этот сторонний инструмент называется CI-сервер, и все перечисленное он готов делать за вас. Даже тарбол из гит-коммита создавать будет сам, только не понятно зачем. И после этого комментария я перестал понимать, какую проблему вы решаете.
Я решаю проблему чтобы можно было запустить проект и в докере и просто на сервер где уже есть окружение. Чтобы у DevOps был выбор, как он хочет запустить сервис. Понравится ли вам если вы все будете устанавливать в докер контейнерах?
Ну вот видите, Вы признаёте, что все эти продукты «намного проще» запускать в докере, а не устанавливать самостоятельно. Так почему же тогда вы не считаете здравым упростить аналогичным образом запуск своего собственного проекта, и хотите чтобы вместо этого юзеры устанавливали его сами из tar.gz?
Это моя первая статья, я не все учел. В следующий раз не буду торопиться опубликовать) У читателей сложилось мнение что я предлагаю отказаться от докера… это совсем не так.
Я предложил чтобы CI не навязывал докер или подобные вещи.
Как верно заметил rustler2009 я хочу чтобы CI был отделен от CD. Чтобы CI публиковал только артефакты (бинарники, скрипты, jar'ки и тп), а дальше DevOps занимается доставкой этих артефактов. Они могут упаковать артефакт в любой докер образ, запихнуть в kubernetes, зафигачить в какой нибудь docker swarm.
Не пойму, о чём вы спорить изволите, Docker image это tar-файлы и есть. Приправленные JSON-ом и с некоторыми соглашениями, но tar-Файлы.
Согласен
Ещё одна причина, хоть и менее важная — упростить запуск. Если в случае одного бинарника юзерам достаточно просто скачать, установить/обновить и запустить его, то в случае tar.gz с проектом на ноде — всё становится несколько сложнее, а докер решает и эту проблему
таким образом вы заставляете пользователей запускать ваш софт только в докере. если это обычный питон скрипт или стандартное node js приложение, зачем мне нужен докер если у меня стоит последний python иили lts версия node?
Зачем оборачивать в докер образ если все и так будет нормально работать без беготни с докером? Почему вы в артефакторий заливаете а не в докер репозиторий? Предлагаете некоторый софт запускать в докере а некоторый чисто на системе потому что он меньше требует окружения?
Вы сейчас говорите вещи которые не связаны с CI и где хранить артефакты. Я тоже запускаю в докере м postgresql, и gitlab поднимал, и mongo, и apache kafka с zookeeper. Все это намного проще развернуть чем устанавливать на голую систему. Но эта статья совершенно не об этом…
Как вы версионируете свои тарболы? Ну вот создали вы fix_new_new\ (1).tar.gz, а ваш коллега создал точно такой же, и потер ваш. Через неделю у вас уже полная каша в репозитории, никто не знает какой тарбол уже тестировали, а какой еще нет, какой где установлен, из какого коммита создан какой тарбол.
Точно так же как и docker образы. Коллега не перезатерет тарбол если в репозитории поставить политику «Allow redeploy». А как вы узнаете из какого коммита был создан docker образ интересно?
А еще оказалось, что коллега туда залил конфиги девовские. Ошибся, с кем не бывает. И потом, когда это залили на прод, у вас прод стал ходить к дев базе. Нормально, да?
Конфиг можно перезатереть когда делаешь docker образ из тарбола.
Через три недели вы решили, что у вас три сайта, и каждый должен ходить к двум другим. Приходит к вам тестировщик, и спрашивает, что ему делать — сайт1 требует библиотеки одной версии, а сайт2 — другой. А еще к нему приходил менеджер и сказал сайт3 взять годовой давности, потому что полгода назад там сделали фикс и поломали совместимость с сайтом2. Что вы ему ответите?
На каждый тарбол у меня будет собственный докер образ, проблемы с зависимостями не будет. Сайты будут работать в докер контейнерах, просто образы будут создаваться не из git репозитория проекта, а сторонним инструментом будет подгружаться тарбол, будет нужный образ, можно будет перезатереть конфиги и тп.
Нет, не верно. Докер это просто один из кирпичиков, удобный, но не обязательный. Я отстаиваю, что сборки проекта должны быть автоматизированными, повторяемыми, и работать одинаково и на машине разработчика, и у тестировщиков, и в проде.
А причем тут докер образы тогда? Сборки проекта можно и нужно делать в контейнерах, я тоже так считаю.
Конечно же, касается — использование контейнеров обеспечивает повторяемость сборки, т.к. мы имеем возможность всегда повторить сборку в точно таком же окружении.
CI может делать сборку изолированно в контейнере и результат работы (артефакты) заливать как tar.gz в репозиторий. В чем проблема?
CI нужен, он триггерит события по пушам, это важный этап, я ни в коем случае не говорю что CI не нужен и давайте заливать tar.gz руками. CI это просто «бот» который реагирует на пуши в VCS. Вы настаиваете на том чтобы CI пушил именно докер образы, верно?
Рад за вас что у вас CI/CD работает как надо, все тестируется, запускается без проблем! Какую билд систему используете? jenkins? circle? gitab? В чем запускаете процесс сборки, в контейнерах или на хостах? А кешируется какими то внутрненними директивами? А как воркеры настраивали? А docker репозиторий как поднимали, свой?
Это всё-равно не решает ту проблему, о которой я говорил в первом пункте: мы знаем кто залил, но не что — разработчик может вручную подкорректировать архив перед заливанием, или его рабочая среда как-то повлияла на сборку, но узнать об этом мы не можем — а что и как делал CI при подготовке релиза отлично известно.
Все просто, я предлагаю пушить только сам проект не смешивая его ни с чем, вы отстаиваете что нужно пушить проект только в докер образе. Верно?
Извините, но меня как-то не очень волнует Ваш личный опыт. Из популярных CI-сервисов и CircleCI и Travis по умолчанию запускают сборку только в контейнерах, из популярных CI установленных на своих серверах GitLab CI тоже использует контейнеры
Во первых, как работает CI процесс (travis, drone ci, concourse ci), мне без разницы, это никак не касается собранных артефактов и в этой статье вопрос не об этом.
Тесты пишет много кто, и Вам тоже стоит.
Дело не во мне, я как раз люблю писать через TDD, думать чистыми функциями и композировать их как угодно. Дело в доставке артефактов на сервера где будет крутиться софт который разрабатывается. Ваш CI пайплайн может «забыть» запустить тесты или часть тестов, его пишут люди и частенько коряво
Я не знаю что вы имеете ввиду под «началом» и спорить не буду. Я написал, что с docker знаком уже больше 3х лет, и с вашей стороны говорить, что я ничего не понимаю — это грубо.
Разработчики должны писать качественный код приложения. Думать как написать модульный, чистый код. Думать над версионированием, следить за коммитами и чтобы ничего не попало в git репозитории, делать тщательное ревью кода. У них огромная поляна работы в которой использование docker никак не поможет!
Это работа CI. Он делает git fetch, прогоняет тесты и билдит проект. Можно сделать так чтобы он паковал результаты работы в docker образ и запускаться в контейнере если вы хотите
Я люблю читать тех информацию и применять ее в реальных проектах. Docker-compose это инструмент для запуска docker контейнеров, мне жалко тратить время на инструмент который я смогу применить в ограниченном круге, к тому же у него есть свои косяки и свое видение как должен выглядеть yml и как запускать контейнеры.
Нет, просто docker имеет низкий порог вхождения и к сожалению люди пишут криво
И эту процедуру нужно постоянно делать при каждом деплое?
Ansible не тащит какой либо экосистемы на сервер, ему нужен только ssh и python интерпретатор. Бага в Ansible может привести только к тому что на серваке что то не запустится во время проигрывания плейбука.
Как баги в Ansible пересекаются с багами в docker — не пойму
Может вы имели ввиду package-lock.json? Если да то package-lock.json необходим в nodejs так как ссылается на точные коммиты кода.
Соболезную вам в таком случае, ни разу не поддерживал 5 — 10 проектов одновременно да и тем более с разным стеком технологий
CD связан с доставкой артефактов сделанных CI на конечные сервера. Он ничего не знает про GIT, как его собирали из исходников. У него есть просто артефакты, и сервера на которых нужно запустить этот артефакт
Нет, процесс как раз один и тот же, результат в tar.
Чтобы можно было потом запустить его либо на чистой системе, либо промежуточным этапом собрать докер образ с нужным окружением и запихнуть туда tar
БД это тоже серверное приложение, однако, позвольте спросить, она только в докере распространяется?
Postgresql можно запустить на чистом метале или… упаковать в докер образ
1. Сорцы в tar не будут, там готовые оттесченые артефакты
2. тарболы можно также организовать как и докер образы.
3. политику кто может загружать тарболл, ее можно настроить также как и в докер репозитории (если не лучше)
Я опечатался, нужно было написать docker pull. Использую ansible, был опыт работы с Chef и его кукбуками с рецептами. Infrastructure as code мне знакомо
CI нужен, это как бот который реагирует на пуши и запускает сборки и заливает артефакт. Он не должен знать про docker…
Да, делать docker образ и добавлять туда артефакт простым скачиванием (не git clone, не компиляция, не прогон юнит тестов). На этапе сборки мне должно быть без разницы как этот артефакт оказался в бинарном репозитории, я просто априори знаю что это протестированный артефакт готовый к работе (иначе его не смогут запушить в репозиторий).
Этот артефакт могут пушить как разработчики так и наш CI который по коммитам сам будет собирать и заливать артефакт…
Похоже что к сожалению так, поторопился с завершением статьи :)
Сколько раз я слышал эту мысль, не пересчитать… Давайте не будем затрагивать тему версионирования и кто должен проставлять теги. Это все сугубо индивидуально, и холивар еще тот
Я решаю проблему чтобы можно было запустить проект и в докере и просто на сервер где уже есть окружение. Чтобы у DevOps был выбор, как он хочет запустить сервис. Понравится ли вам если вы все будете устанавливать в докер контейнерах?
Это моя первая статья, я не все учел. В следующий раз не буду торопиться опубликовать) У читателей сложилось мнение что я предлагаю отказаться от докера… это совсем не так.
Я предложил чтобы CI не навязывал докер или подобные вещи.
Как верно заметил rustler2009 я хочу чтобы CI был отделен от CD. Чтобы CI публиковал только артефакты (бинарники, скрипты, jar'ки и тп), а дальше DevOps занимается доставкой этих артефактов. Они могут упаковать артефакт в любой докер образ, запихнуть в kubernetes, зафигачить в какой нибудь docker swarm.
Согласен
таким образом вы заставляете пользователей запускать ваш софт только в докере. если это обычный питон скрипт или стандартное node js приложение, зачем мне нужен докер если у меня стоит последний python иили lts версия node?
Зачем оборачивать в докер образ если все и так будет нормально работать без беготни с докером? Почему вы в артефакторий заливаете а не в докер репозиторий? Предлагаете некоторый софт запускать в докере а некоторый чисто на системе потому что он меньше требует окружения?
Точно так же как и docker образы. Коллега не перезатерет тарбол если в репозитории поставить политику «Allow redeploy». А как вы узнаете из какого коммита был создан docker образ интересно?
Конфиг можно перезатереть когда делаешь docker образ из тарбола.
На каждый тарбол у меня будет собственный докер образ, проблемы с зависимостями не будет. Сайты будут работать в докер контейнерах, просто образы будут создаваться не из git репозитория проекта, а сторонним инструментом будет подгружаться тарбол, будет нужный образ, можно будет перезатереть конфиги и тп.
А причем тут докер образы тогда? Сборки проекта можно и нужно делать в контейнерах, я тоже так считаю.
CI может делать сборку изолированно в контейнере и результат работы (артефакты) заливать как tar.gz в репозиторий. В чем проблема?
CI нужен, он триггерит события по пушам, это важный этап, я ни в коем случае не говорю что CI не нужен и давайте заливать tar.gz руками. CI это просто «бот» который реагирует на пуши в VCS. Вы настаиваете на том чтобы CI пушил именно докер образы, верно?
Все просто, я предлагаю пушить только сам проект не смешивая его ни с чем, вы отстаиваете что нужно пушить проект только в докер образе. Верно?
Во первых, как работает CI процесс (travis, drone ci, concourse ci), мне без разницы, это никак не касается собранных артефактов и в этой статье вопрос не об этом.
Дело не во мне, я как раз люблю писать через TDD, думать чистыми функциями и композировать их как угодно. Дело в доставке артефактов на сервера где будет крутиться софт который разрабатывается. Ваш CI пайплайн может «забыть» запустить тесты или часть тестов, его пишут люди и частенько коряво