SZ
Мы find очень много что делаем. Никогда не подводил ) бывают сложности с использованием, т.к у утилиты 100500 аргументов. Но в справке все описано
ну можно седом обрабатывать и брать нужжный аргумент из аутпута
Size: a a a
2020 January 02
SZ
Ну, у вас интерпретатор существует в рамках одного блока RUN
а
SZ
GG
Если переходим к следующему RUN - это эквивалентно выключению контейнера
GG
И созданию его заново
GG
Соответственно, среда сбрасывается.
GG
Какие решения ? Да все плохо. В конце-концов, можно все собирать или снаружи докера, а внутрь передавать окончательный артефакт
GG
Или использовать multistage dockerfile
SZ
Какие решения ? Да все плохо. В конце-концов, можно все собирать или снаружи докера, а внутрь передавать окончательный артефакт
абсолютно отвратительно 0/10
SZ
Или использовать multistage dockerfile
так, я недавно во всей теме докеризации, можно подробней об этом?
GG
так, я недавно во всей теме докеризации, можно подробней об этом?
Ну, это способ написания докерфайла вида
FROM ubuntu as base
Blablbla
# здесь какая-то сборка со стопицот слоев
FROM scratch as final
COPY --from=base /artifact /opt
# здесь перекидывает между разными образами нужные файлы
# Профит !
FROM ubuntu as base
Blablbla
# здесь какая-то сборка со стопицот слоев
FROM scratch as final
COPY --from=base /artifact /opt
# здесь перекидывает между разными образами нужные файлы
# Профит !
GG
В результате конечный образ с минимумом слоев и минимального размера. Плюс докер использует свой кэш для сборок
SZ
аааа, погуглю
SZ
про кэш да, удобно и хорошо
GG
Ну, к сожалению - это не панацея
GG
Докер сравнивает только по хэш сумме команды из докерфайла и зависимых файлпх
GG
Т.е. если в докерфайле что-то типа RUN wget http://very-often.changing.org, то нужно извращаться, чтобы докер понял, что команда возвращает новый результат (((
SZ
угу, эт я знаю
SZ
так, ну раз так, то буду советоваться сейчас, как сделать оптимальней