да, оно за cloudfront

Да все пашет. Это Росчтототам наверное заблочил опять

Слушайте, у меня близкий вопрос. А как тогда ребилдить модули для того же нпма или пипа, когда поменялись packages.json /requirements.txt ?

Типа если он из кеша берет слой.

Если меняется пакадж - все следующие слои будет ребилдится

Если ты пакадж копируешь (а как еще ты узнаешь что ставить?)

А если зависимости глубже и у тебя нет завязки на версию в пакадже (как у нас) - перед пакаджем еще копировать разрезолвенные зависимости как отдельный файл

Чет не въехал

То есть он проверяет и мд5 файликов которые мы копируем внутрь имиджа ? И если он поменялся, ниже билд пойдет ?

Не проверяет

Просто COPY всегда новый образ собирает

Тогда это бестолковая херь

А есть вариант ребилдить пекежжи тока в случае изменения файла ?

хотя не, чот я запутался

это ADD вроде новый образ делает. и то не всегда :)

Кто-то тут,мягко говоря,не прав

Да, сверяется хеш при каждом копировании

Не слушай диванных докероводов

Да, сверяется хеш при каждом копировании

да-да, всё так. я ошибся

Не слушай диванных докероводов

окай гай ) вобще этот вариант крутой. получается если они не менялись, мы в билд просто строчкой ниже положим новый код и все. нада замутить !

бинго!

А еще если много разных имаджей с похожей базой - между ними можно расшарить общий кеш и еще уменьшить время билда ;)

ах блядь

вот теперь я вспомнил почему у нас оно не работало :(

и почему не всё так просто с тем чтоб собрать все зависимости и почему мы их собираем предварительно :(

пичаль

кстати

если у нас COPY $PROJECT_NAME /var/www/$PROJECT_NAME

если $PROJECT_NAME поменялся, будет новый слой, так?

у нас просто 4 имаджа с такой конструкцией, в целом если для каждого имаджа такой слой будет кешироваться, то срать

кеш слоев все равно будет

короче, перефразирую. У меня сейчас есть COPY $PROJECT_NAME /var/www/$PROJECT_NAME. Если я сделаю COPY $PROJECT_NAME/foo /var/www/$PROJECT_NAME/foo COPY $PROJECT_NAME /var/www/$PROJECT_NAME оно первый copy закеширует?

пемеренные окружения они в твоем мире

потому что /foo меняется очень редко

а докер их видит уже разрезолвинными

ага, норм

а с двумя COPY?

каждый копи - отдельный слой

ну я вон там выше пример привёл

тоесть у меня папка с проектом в среднем весит 50 мегабайт

из них 45 мегабайт это зависимости

вынести их из папки это очень страшный геморой

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

в теории можно ещё один ADD добавить, в котором эту папочку выпиливать

и потом уже копировать

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

и тут обсуждали тоже

почитай статьи вышедшие после 1,10

Вначале нужно COPY Gemfile* и делать install, а затем делать COPY проекта. Тогда кэш с зависимостями будет нормально работать.

Вначале нужно COPY Gemfile* и делать install, а затем делать COPY проекта. Тогда кэш с зависимостями будет нормально работать.

я не буду делать внутри имаджа bundle install

по огромному ряду причин

Например?

во-первых, зависимости уже установлены, их поставили перед тем как гонять тесты

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

У вас разработчики при разработке всегда ставят гемы внутрь проекта?

@dd_bb видимо у вас есть логика того что должно быть в докерфайле и что дожно быть в слоях.

я свои имаджи вообще всегда в один слой сливаю

@dd_bb видимо у вас есть логика того что должно быть в докерфайле и что дожно быть в слоях.

мне идеально чтоб в докерфайлах уже ничего никто не ставил и делал только copy

И потом пересобираешь по часу?

и пока видится мне она похожа на "против течения"

У вас разработчики при разработке всегда ставят гемы внутрь проекта?

вопроса не понял

И потом пересобираешь по часу?

ты не прав, собираются быстро очень , засчет того что слови в билдере остаются

а вот итоговый слой получается очень компактным если все равильно седлать

ну да, если в одном слое поставить gcc потом собрать приложение потом удалить gcc

то на выходе скваша будет мало

ERROR: S client not available

ну да, если в одном слое поставить gcc потом собрать приложение потом удалить gcc

я это делаю в разных слоях

но скваш собирает в один

да да я помню принцип

вопроса не понял

Я имею ввиду как и почему там оказываются зависимости. Но видимо я не очень понял ваш workflow.

сквашь молодец в этом отношении

Я имею ввиду как и почему там оказываются зависимости. Но видимо я не очень понял ваш workflow.

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

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

а вот итоговый слой получается очень компактным если все равильно седлать

Как правильно делать?

есть один проект который core, который используется в бандлере в некоторых других

Как правильно делать?

squash

squash

https://github.com/goldmann/docker-squash https://github.com/goldmann/docker-squash/issues/96#issuecomment-222153029

проекты == продукты

для каждого продукта по успешной CI сборке делается имадж

кароче каждый * как хочет

как может

как умеет

так может как умеет же

так нет же, может правильно , но не умеет)

Поцоны, а у вас dockerhub сегодня нормально работает?

У меня чот таймауты валятся

видимо локальная проблема, отбой

кто-нибудь сталкивался с проблемой, что когда настраиваешь devicemapper с thin pool, то перестает работать таб в командах докера?

ох

а это точно связано между собой ?

я по этому туториалу настраивала https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/

кто-нибудь сталкивался с проблемой, что когда настраиваешь devicemapper с thin pool, то перестает работать таб в командах докера?

Начало охуительной истории! Вспоминается история с багом в драйвере ядра, а проявлялось тоже из-за какой-то мелочи

devicemapper с thin pool вообще идея так себе его использовать

это же самый последний вариант

? мне показалось, что нормально должно получиться.

Overlay лучше всего

А вот если для volume то может и норм

А сеть случайно не ipv6 only? А то гитхаб не умеет в ipv6 :(