Прямо в лоб по цепочке передам
у вас в конечном образе файловая система с вашими десятью бинарниками. Решайте кто из них энтрипойнт и пусть он разбирается кого и как вызывать и какие у него самого для этого параметры
Anton
Anton
причем этот подход касается не только 10-го образа, но и 2-го и 3-го и т.д.
Roman
Понял, спасибо
Roman
Буду разбираться
Александр
Добрый день, подскажите пожалуйста , куда смотреть -- хочу почитать про ключи , запуска ? Или может это просто ключи называется. Т.е. тип docker run -t -i . В частности конечно интересует -d(но это вроде дебаг мод) и -p
Дмитрий
-d daemon -p port. Dockee help не достаточно?
Александр
Да что-то про -p это я лиханул.
central
Roman
Как понять, какие команды имеет смысл в один блок RUN объединять, а какие - нет?
George
очень просто
George
Если у тебя команда 1 создает 10ГиБ файл, а команда 2 его удаляет, то их надо в один RUN. Иначе у тебя образ вырастет на 10ГиБ
George
это относится ко всяким pip install, apt, apk add и прочим, кто кэш формирует
George
в остальном - никакой ценности компоновать стопицот команд в один RUN нет
Roman
То есть нужно экономить на размере промежуточных слоев
George
желательно
Roman
Допустим мне нужно использовать фунциональность нескольких образов. Как понять, какой из них должен быть родительским?
Roman
Ок, сейчас есть multistage-сборки. А как раньше это решалось?
George
Ок, сейчас есть multistage-сборки. А как раньше это решалось?
когда-то давным-давно можно было наследоваться от двух образов, но это шляпа. По понятным причинам
George
Допустим мне нужно использовать фунциональность нескольких образов. Как понять, какой из них должен быть родительским?
например? писать самому докерфайл, очевидно
George
несомненно
Roman
например? писать самому докерфайл, очевидно
Самому, это понятно. Но хочется же воспользоваться готовыми решениями по максимуму. Например, мне нужны образы nginx и .netcore-sdk. Я могу выбрать один из них, а функциональность другого самому воспроизвести в докерфайле. Но меня, как разработчика, смущает низкая повторная используемость
George
это естественно
George
потому что ты не можешь две файловые системы надежно смержить
Roman
и как быть?
George
никак. Думать своей головой
George
писать свои докерфайлы
George
если совсем тяжело - ну, используй какую-нибудь шаблонизацию
George
можешь собирать докерфайлы - ансиблом (просто устанавливая нужный софт внутри контейнера и потом его коммитя)
Maksim
можешь собирать докерфайлы - ансиблом (просто устанавливая нужный софт внутри контейнера и потом его коммитя)
Это же неправильно, мне тут говорили)
George
нет, не ансиблом снаружи, а внутри докерфайла делаешь ансибл чего-то там )
Roman
Не зря же они в принципе написаны.
Roman
А так можно было бы самому писать с нуля, и зачем тогда готовые?
George
потому что вендор необязательно хорошо шарит в докере
George
и вообще докерхаб помойка
Roman
большинство шарят, думаю
George
ну, да, действительно, а чего шарить-то.... отличный подход, блин
Roman
то есть смерджить несколько готовых образов эффективно никак нельзя?
George
😡
George
Исключение - если у тебя программа + зависимости эффективно отделена (например, как в случае голанга)
Roman
ок, как решить, какой образ взять за базовый?
George
любой )
George
можешь взять самый редко меняющийся
George
или самый тяжелый по размеру
Roman
наиболее "сложный", может?
George
у меня, например, проект на CUDA. Базовый весит до 5ГиБ
Дмитрий
у меня, например, проект на CUDA. Базовый весит до 5ГиБ
Я думал только у менч 3.4 гб образ это овердохера
Дмитрий
Проклятая нода
George
А прикинь по 2 мбиту это грузить ?
Alexey
Roman
Допустим я в контейнере скачиваю архив с исходниками чего-либо для сборки. Является ли хорошей практикой удалять файл с архивом после его распаковки или пусть валяется, некритично?
George
Yakov
Я думал только у менч 3.4 гб образ это овердохера
25гб hortonworks песочница для локальной разработки у нашей команды. ха-ха(на самом деле не смешно, да)
Anton
Как понять, какие команды имеет смысл в один блок RUN объединять, а какие - нет?
если вы хотите что-то добавить, а потом это удалить, то это нужно делать в одном ране.
Например, вы поставили стопиццот дев-библиотек, систему сборки и еще, собрали свой бинарник, а потом решили удалить билд-окружение. Вот положить это все в три разных рана не прокатит.
Придется сделать что-то вроде:
RUN apk add g++ make && make && apk del g++ make
Roman
если вы хотите что-то добавить, а потом это удалить, то это нужно делать в одном ране.
Например, вы поставили стопиццот дев-библиотек, систему сборки и еще, собрали свой бинарник, а потом решили удалить билд-окружение. Вот положить это все в три разных рана не прокатит.
Придется сделать что-то вроде:
RUN apk add g++ make && make && apk del g++ make
А мы же можем при установке через apk виртуальные группы пакетов создавать, чтобы потом грохнуть их разом?
George
а еще проще не париться и делать мультистейдж билд
George
главное придумать способ артефакты качественно передавать со стадии на стадию (можно через пакеты деб, или апк, например)
Roman
главное придумать способ артефакты качественно передавать со стадии на стадию (можно через пакеты деб, или апк, например)
Если я ставлю тот же nginx в одной стадии, в следующую его не так просто перенести, так как его файлы в разных папках лежат и нужно знать все папки, чтобы аккуратно перенести. Как с этим борются?
George
Anton
главное придумать способ артефакты качественно передавать со стадии на стадию (можно через пакеты деб, или апк, например)
COPY --from=builder /build /app
Andrey
в остальном - никакой ценности компоновать стопицот команд в один RUN нет
А как же ограничение по слоям вроде 127 максимально можно. Люди разные сейчас начнут ран == команда
George
"так как его файлы в разных папках лежат и нужно знать все папки, чтобы аккуратно перенести."
Anton
/build может иметь какую угодно структуру
George
А как же ограничение по слоям вроде 127 максимально можно. Люди разные сейчас начнут ран == команда
ну, согласен, сильно дробить не стоить. Но и сильно запариваться, если нет кейса с удалением файлов - не вижу смысла
Andrey
Да
Anton
можно COPY --from=builder /build /
George
они, вероятно, не умеют кастомные пути для установки того же nginx