ок, как решить, какой образ взять за базовый?

любой )

можешь взять самый редко меняющийся

или самый тяжелый по размеру

наиболее "сложный", может?

у меня, например, проект на CUDA. Базовый весит до 5ГиБ

наиболее "сложный", может?

или сложный с точки зрения повторения

у меня, например, проект на CUDA. Базовый весит до 5ГиБ

Я думал только у менч 3.4 гб образ это овердохера

Проклятая нода

А прикинь по 2 мбиту это грузить ?

А прикинь по 2 мбиту это грузить ?

Сутки челик качал по адсл инету

Допустим я в контейнере скачиваю архив с исходниками чего-либо для сборки. Является ли хорошей практикой удалять файл с архивом после его распаковки или пусть валяется, некритично?

Допустим я в контейнере скачиваю архив с исходниками чего-либо для сборки. Является ли хорошей практикой удалять файл с архивом после его распаковки или пусть валяется, некритично?

Лучше удалить

Я думал только у менч 3.4 гб образ это овердохера

25гб hortonworks песочница для локальной разработки у нашей команды. ха-ха(на самом деле не смешно, да)

Как понять, какие команды имеет смысл в один блок RUN объединять, а какие - нет?

если вы хотите что-то добавить, а потом это удалить, то это нужно делать в одном ране. Например, вы поставили стопиццот дев-библиотек, систему сборки и еще, собрали свой бинарник, а потом решили удалить билд-окружение. Вот положить это все в три разных рана не прокатит. Придется сделать что-то вроде: RUN apk add g++ make && make && apk del g++ make

если вы хотите что-то добавить, а потом это удалить, то это нужно делать в одном ране. Например, вы поставили стопиццот дев-библиотек, систему сборки и еще, собрали свой бинарник, а потом решили удалить билд-окружение. Вот положить это все в три разных рана не прокатит. Придется сделать что-то вроде: RUN apk add g++ make && make && apk del g++ make

А мы же можем при установке через apk виртуальные группы пакетов создавать, чтобы потом грохнуть их разом?

А мы же можем при установке через apk виртуальные группы пакетов создавать, чтобы потом грохнуть их разом?

да

а еще проще не париться и делать мультистейдж билд

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

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

Если я ставлю тот же nginx в одной стадии, в следующую его не так просто перенести, так как его файлы в разных папках лежат и нужно знать все папки, чтобы аккуратно перенести. Как с этим борются?

Если я ставлю тот же nginx в одной стадии, в следующую его не так просто перенести, так как его файлы в разных папках лежат и нужно знать все папки, чтобы аккуратно перенести. Как с этим борются?

сделать пакет )

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

COPY --from=builder /build /app

в остальном - никакой ценности компоновать стопицот команд в один RUN нет

А как же ограничение по слоям вроде 127 максимально можно. Люди разные сейчас начнут ран == команда

COPY --from=builder /build /app

?‍♂️

"так как его файлы в разных папках лежат и нужно знать все папки, чтобы аккуратно перенести."

/build может иметь какую угодно структуру

А как же ограничение по слоям вроде 127 максимально можно. Люди разные сейчас начнут ран == команда

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

Да

/build может иметь какую угодно структуру

это слишком сложно для коллег ))))

можно COPY --from=builder /build /

они, вероятно, не умеют кастомные пути для установки того же nginx

и при прочих равных реально проще собрать deb-rpm-anyelse пакет

передать его и установить

я бы предполчел написать Makefile со вменяемой install целью, где можно задать DESTDIR и PREFIX

?

в билд образе: make install DESTDIR=/build

прям по-девопс-овски

и потом просто копировать билд в рут

как сделать, чтобы entrypoint мог и содержать переменную окружения, и принимать параметры?

выше писали. В принципе можно передать переменныю, но это не очень идея

дискуссия была вокруг https://t.me/docker_ru/134173

фактически оказалось, что много нюансов и иногда можно )

так не работает: ENTRYPOINT ["/${IMAGE_WORKDIR}/script"] так работает: ENTRYPOINT "/${IMAGE_WORKDIR}/script" (при условии, что IMAGE_WORKDIR это ENV) но есть одно но: во втором случае нельзя передавать аргументы при ране

так не работает: ENTRYPOINT ["/${IMAGE_WORKDIR}/script"] так работает: ENTRYPOINT "/${IMAGE_WORKDIR}/script" (при условии, что IMAGE_WORKDIR это ENV) но есть одно но: во втором случае нельзя передавать аргументы при ране

а ты sh используй

так не работает: ENTRYPOINT ["/${IMAGE_WORKDIR}/script"] так работает: ENTRYPOINT "/${IMAGE_WORKDIR}/script" (при условии, что IMAGE_WORKDIR это ENV) но есть одно но: во втором случае нельзя передавать аргументы при ране

ENTRYPOINT ["sh","-c","/${IMAGE_WORKDIR}/script"]

а потом нужно придумать способ подклеить аргументы

но это наверняка можно сделать через что-то типа @$

ну либо на крайний случай - в энтрипойнт определить энтрипойнт.сш скрипт

я думаю, что у тебя достаточно странная просьба, поэтому многие скажут, что это не нужно #странное

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

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

а контейнер - типа сборище скриптов?

почему не билдить два образа, отличающиеся энтрипойнтом?

юзкейсы воркдира разные, иногда это папка, которую нужно сервить вебсервером, иногда это папка из которой запускается бинарник

Драсти, есть проблема, контейнер докер с нгинксом не коннектится с контейнером gunicorn, вроде все по гайду делал, а не работает, что я не так настроил? https://gist.github.com/Mastermind-U/dad7dae08ef40e4915d8494a8f3d3796

Драсти, есть проблема, контейнер докер с нгинксом не коннектится с контейнером gunicorn, вроде все по гайду делал, а не работает, что я не так настроил? https://gist.github.com/Mastermind-U/dad7dae08ef40e4915d8494a8f3d3796

docker ps проверь, все ли контейнеры работают

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

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

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

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

а какими обычно инструментами чаще всего в конторах пользуются? docker fabric, докер компосе?

пусть вам лучше ответят ребята у кого реальный есть опыт с докером, правильнее, сказать энтерпрайз опыт. у меня в анамнезе за 5 лет ни одной, мать её, конторы где был бы докер в проде :(

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

на текущем месте работы будет openshift. сейчас готовимся к внедрению.

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

а все это сделать на fabric не реально?

а все это сделать на fabric не реально?

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

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

а я думаю проще java -jar app

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

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

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

номад для оркестрации задач, в моем случае запуска контейнеров, передеплоя, автоскейлинга, и сервис дискавери. Дженкинс как инструмент сбора контейнера и деплоя в номад кластер. верхнеуровнево пайплайн такой - мерж в мастер запускает сборку контейнера в Дженкинс, оттуда ансиблом деплой в кластер номада, старая версия крутится пока новая не запустится и хелсчеки не покажут ок статус.