как докер считает совпадают ли COPY слои? по last modified или хеши считает?

For the ADD and COPY instructions, the contents of the file(s) in the image are examined and a checksum is calculated for each file. The last-modified and last-accessed times of the file(s) are not considered in these checksums. During the cache lookup, the checksum is compared against the checksum in the existing images. If anything has changed in the file(s), such as the contents and metadata, then the cache is invalidated.

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

файл не менялся с прошлого года

Может ты на сборке что то в контексте делаешь и изменяешь его

это как? после чекаута гит-репы что-то меняю в папке типа? вроде нет... поищу

А какой кейс то?

Ребята, подскажите пожалуйста Ознакомился частично с базовыми докер-понятиями: dockerfile, docker-compose, image, container, dockerhub Предположим есть проджект: nginx + django some app + postgres для django-app есть репо на гите Я пишу докерфайл для джанго приложения Пишу docker-compose для сборки в целом И дальше у меня начинаются вопросы: Где хранить докер-файл и docker-compose.yml? Хранить папке поекта (и, соответственно, в гит-репо)? Я правильно понимаю, что конечный алгоритм запуска подготовленного мной "docker+git приложения" (условно) должен выглядеть примерно так? : делаем git clone репо в проекте находим docker-compose запускаем приложение через docker-compose up Извиняюсь за нотку нубячества и заранее благодарен

Ребята, подскажите пожалуйста Ознакомился частично с базовыми докер-понятиями: dockerfile, docker-compose, image, container, dockerhub Предположим есть проджект: nginx + django some app + postgres для django-app есть репо на гите Я пишу докерфайл для джанго приложения Пишу docker-compose для сборки в целом И дальше у меня начинаются вопросы: Где хранить докер-файл и docker-compose.yml? Хранить папке поекта (и, соответственно, в гит-репо)? Я правильно понимаю, что конечный алгоритм запуска подготовленного мной "docker+git приложения" (условно) должен выглядеть примерно так? : делаем git clone репо в проекте находим docker-compose запускаем приложение через docker-compose up Извиняюсь за нотку нубячества и заранее благодарен

docker-compose.yml, Dockerfile хранишь в репе, env файл вне репы

Ребята, подскажите пожалуйста Ознакомился частично с базовыми докер-понятиями: dockerfile, docker-compose, image, container, dockerhub Предположим есть проджект: nginx + django some app + postgres для django-app есть репо на гите Я пишу докерфайл для джанго приложения Пишу docker-compose для сборки в целом И дальше у меня начинаются вопросы: Где хранить докер-файл и docker-compose.yml? Хранить папке поекта (и, соответственно, в гит-репо)? Я правильно понимаю, что конечный алгоритм запуска подготовленного мной "docker+git приложения" (условно) должен выглядеть примерно так? : делаем git clone репо в проекте находим docker-compose запускаем приложение через docker-compose up Извиняюсь за нотку нубячества и заранее благодарен

запуск делается именно так как описал

Спасибо большое!

если гитлаб, то env-файл не особо нужен. Можно хранить в энвах репозитория и подставлять во время CI

Ребята, подскажите пожалуйста Ознакомился частично с базовыми докер-понятиями: dockerfile, docker-compose, image, container, dockerhub Предположим есть проджект: nginx + django some app + postgres для django-app есть репо на гите Я пишу докерфайл для джанго приложения Пишу docker-compose для сборки в целом И дальше у меня начинаются вопросы: Где хранить докер-файл и docker-compose.yml? Хранить папке поекта (и, соответственно, в гит-репо)? Я правильно понимаю, что конечный алгоритм запуска подготовленного мной "docker+git приложения" (условно) должен выглядеть примерно так? : делаем git clone репо в проекте находим docker-compose запускаем приложение через docker-compose up Извиняюсь за нотку нубячества и заранее благодарен

зависит от того чем ты занимаешься и чего хочешь, есть 2 основных подхода 1-ый это который ты описал когда докерфайлы хранятся внутри репозитория с проектом 2-ой это когда докерфайлы хранятся в отдельном репозитории и сохраняются оттуда 1-ый способ удобен когда разработчики сами следят за своим проектом и т.п. 2-ой способ удобнее когда людей занимающихся докером мало, а проектов много , так их удобней менеджить и ревьюить

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

зависит от того чем ты занимаешься и чего хочешь, есть 2 основных подхода 1-ый это который ты описал когда докерфайлы хранятся внутри репозитория с проектом 2-ой это когда докерфайлы хранятся в отдельном репозитории и сохраняются оттуда 1-ый способ удобен когда разработчики сами следят за своим проектом и т.п. 2-ой способ удобнее когда людей занимающихся докером мало, а проектов много , так их удобней менеджить и ревьюить

Ага, понял Но смысл один и тот же получается, из которого, я надеюсь, я делаю правильные выводы: 1) Весь проект надо все равно держать в формате гит-репо; (а не предподготовленного образа с предустановленным окружением) 2) Так или иначе должны быть сохранены dockerfile(s) и docker-compose.yml 3) Процесс запуска заключается в клонировании файловой структуры из загруженного репо в контейнер, пробросе портов, запуске сервисов etc - это все должен покрывать docker-compose

3 пункт не такой

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

https://docs.docker.com/compose/django/

а. тут обратный пример

Я джангу у себя так упаковываю: FROM python:3.6 RUN apt-get update \ && apt-get install -y --no-install-recommends \ postgresql-client ssh git \ && rm -rf /var/lib/apt/lists/* VOLUME ["/articles"] WORKDIR /usr/src/app COPY requirements.txt ./ RUN pip3 install --upgrade pip && pip3 install -r requirements.txt COPY . . EXPOSE 8000 ENTRYPOINT ["/bin/sh", "./run.sh"]

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

Спасибо большое!

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

Я извиняюсь, кажется остался таки один вопрос :) Почему, например, не используется такой вариант: докер-файл в котором на основе образа, например, python3; помимо прочих дефолтных операций производится git clone, pip3 install -r requirements.txt и сопутствующие созданию окружения команды. Ну и все, как всегда, обернуто в docker-compose с дефолтными сервисами Это, получается, почти как у вас, если я правильно понимаю, только за исключением одного момента: вам не нужно заботиться о том, чтобы чтобы свежая версия была загружена где-нибудь на localhost, возиться с путями (ну вдруг какие-то ограничения появятся), все что вам нужно будет, по идее - docker, docker-compose, и dockerfile основного проекта и docker-compose.yml, и вы сможете собрать этот образ заново где угодно. Если я правильно понимаю :)

Я извиняюсь, кажется остался таки один вопрос :) Почему, например, не используется такой вариант: докер-файл в котором на основе образа, например, python3; помимо прочих дефолтных операций производится git clone, pip3 install -r requirements.txt и сопутствующие созданию окружения команды. Ну и все, как всегда, обернуто в docker-compose с дефолтными сервисами Это, получается, почти как у вас, если я правильно понимаю, только за исключением одного момента: вам не нужно заботиться о том, чтобы чтобы свежая версия была загружена где-нибудь на localhost, возиться с путями (ну вдруг какие-то ограничения появятся), все что вам нужно будет, по идее - docker, docker-compose, и dockerfile основного проекта и docker-compose.yml, и вы сможете собрать этот образ заново где угодно. Если я правильно понимаю :)

если ты билдишь через раннер, то там отпадает нужда в git clone. раннер сам тебе все подготовит. Если ты билдишь локально, то тем более клонировать ничего не надо. Ну и в регистри хранить по имени ветки/хэшу коммита/как угодно.

Там и так не надо возиться с путями. docker build -t <registry image url>:<tag> .

вопрос свежести версий как-то вторичен. Есть, например, 3 ветки, для каждой ветки будет свой образ называться свежим

Пошел читать дальше, спасибо :)

Пошел читать дальше, спасибо :)

В чем код-то храните? битбакет/гитлаб/гитхаб/Etc?

Github/публичный

Github/публичный

Может, мои данные устарели, но CI еще пару месяцев назад был платным. Так что подсказать ничего не смогу. На гитлабе бесплатный. Даже на официальном сайте

Так бы там можно было вписать, что при пуше в ветку надо собирать образ. (Регистри на гитлабе, кстати, тоже есть)

> вам не нужно заботиться о том, чтобы чтобы свежая версия была загружена где-нибудь на localhost, возиться с путями (ну вдруг какие-то ограничения появятся) Это уже задача CI. не надо это делать вручную со своего компа, так как чревато человеческими ошибками.

Может, мои данные устарели, но CI еще пару месяцев назад был платным. Так что подсказать ничего не смогу. На гитлабе бесплатный. Даже на официальном сайте

На будущее - зафиксировал, но пока сфокусируюсь на самом docker, боюсь уйти в глубокую прокрастинацию. ))

Шкурные борыги борыжат шкурами на рынке instagram ?

я что то запутался в сути вашей рекламы

и почём шкуры ?

если куплю две шкуры то что мне с ними делать?

Купил вот одну шкуру в икее, в гостинную, так она в итоге на балконе лежит

Не рекомендую

тоже думаю что шкуры это лишний пылесборник и пользы от шкуры как с козла молока

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

Еще интересно что такое эскорт шкуры? Типа как выездная химчистка которая приезжает к вам и чистит шкуры за вас у вас дома? Наверное если есть спрос то предложение не заставит себя ждать

Removed msg from Serega nice. Reason: new user + external link

Еще интересно что такое эскорт шкуры? Типа как выездная химчистка которая приезжает к вам и чистит шкуры за вас у вас дома? Наверное если есть спрос то предложение не заставит себя ждать

Или "шкура на выезд". Когда сдал свою в химчистку, и тут узнаешь что через полчаса придут гости. А твля шукра задавала стиль всей комнате. И всё, надо срочно замену положить

Или "шкура на выезд". Когда сдал свою в химчистку, и тут узнаешь что через полчаса придут гости. А твля шукра задавала стиль всей комнате. И всё, надо срочно замену положить

Точняк, без "шкуры на выезд" такую проблему как "неожиданные гости" стопудова не решить))) нужно держать марку, так как гости могут прибыть со своими шкурами и если их шкуры будут круче чем шкура в твоей комнате то наверное ты будешь не такой крутой в тусовке "шкуроманов". Интересно как у этих ребят называются их чатики :) Шкурофилы, шкуроманы, шкурнятники, шкурята, шкурники, шкурчишки?

Наверное мне просто не дано понять этих любителей шкур, у меня другие интересы наверное ) Коллеги, кто нибудь использует TeamCity для сборки docker образов?

Наверное мне просто не дано понять этих любителей шкур, у меня другие интересы наверное ) Коллеги, кто нибудь использует TeamCity для сборки docker образов?

Я в гитлабе перешёл с докерового билдера на project kaniko, собирает в разы быстрее докера

Я в гитлабе перешёл с докерового билдера на project kaniko, собирает в разы быстрее докера

gitlab крутая штука, но у меня загвоздка с TeamCity

ERROR: S client not available

gitlab крутая штука, но у меня загвоздка с TeamCity

а в чем проблем собирать через kaniko в teamcity?

а в чем проблем собирать через kaniko в teamcity?

Собственно проблем собрать через kaniko нет, вопрос не в инструментарии для сборки, а в том как устроить процесс в TeamCity

Собственно проблем собрать через kaniko нет, вопрос не в инструментарии для сборки, а в том как устроить процесс в TeamCity

так вот kaniko у меня в 2-3 раза быстрей и собирает, по сравнению с докером

так вот kaniko у меня в 2-3 раза быстрей и собирает, по сравнению с докером

А вы используете приватный реестр docker образов?

А вы используете приватный реестр docker образов?

да

да

А TeamCity?

плюс kaniko в том что можно обойтись без костылей в виде docker in docker, т.к ему для работы не нужен докер демон

https://docs.gitlab.com/ee/ci/docker/using_kaniko.html

думаю этот кейс можно и под teamcity адаптировать

думаю этот кейс можно и под teamcity адаптировать

У меня задачка с bitbucket и github, к сожелению gitlab в схеме отсутствует. В общем вопрос как раз по агенту teamcity и использование docker-compose из агента тимсити

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

ну плюс оптимизировать сам dockerfile

по тимсити к сожалению ни чем помочь не смогу

думаю этот кейс можно и под teamcity адаптировать

Проект использует docker-compose, не swarm, не kub8, простой docker-compose для запуска сервисов, на сервере запущен сервис teamcity-agent с docker внутри, вопрос в том как правильно его использовать для выполнения команд в запущенных сервисах, например docker-compose exec web nginx -s reload с помощью teamcity-agent ?

можно через docker attach цепляться напрямую в контейнер и выполнять там нужные комманды

можно через docker attach цепляться напрямую в контейнер и выполнять там нужные комманды

Дело в том что известно только название сервиса, название контейнера в моем случае не очень удобно

Дело в том что известно только название сервиса, название контейнера в моем случае не очень удобно

аттачить можно и по имени сервиса из композа

аттачить можно и по имени сервиса из композа

Получается что необходимо смотнировать директории сервисов в контейнер teamcity-agent и этого будет достаточно что бы запустить docker-compose exec web nginx -s reload , верно?

через docker attach ты подключаешь к той консоли в которой запускаешь контейнеры stdin от контейнера

а nginx -s reload лучше через docker exec делать

а nginx -s reload лучше через docker exec делать

дело в том что название контейнера в последних версиях докер стали с такими длинными хэшами в конце названия, а имя сервиса мне известно изначально и его не нужно угадывать в моем случае

дело в том что название контейнера в последних версиях докер стали с такими длинными хэшами в конце названия, а имя сервиса мне известно изначально и его не нужно угадывать в моем случае

композ обновить до последней версии и все будет как раньше

композ обновить до последней версии и все будет как раньше

вот оно как, понял, спасибо, попробую