https://habr.com/ru/company/southbridge/blog/329138/

потому что смержилось криво. Я ж повторюсь - все зависит от того, что в ЭНТРИПОЙНТ

Ясно

вообще проще было бы, если эти идиоты CMD SH синтаксис выпили б к чертям

и нужно четко понимать в чем разница между "program", "-c", "argument" и "program", "-c argument"

(оно парсится по-разному)

Да уж. Докер прикольный конечно, но столько в нём непознанного :)

Пойду почитаю про ENTRYPOINT

Ребята, всем привет. Запутался уже в докеризации PHP приложения. Уж больно много вариков предлагают. 1.Контейнер NGINX + Контейнер PHP-FPM как FastCGI + Код 2.Контейнер NGINX + Контейнер PHP-FPM + Контейнер с кодом, volume которого юзается в nginx + php 3.Один единственный контейнер, куда запихнули NGINX + PHP-FPM, которые запускаются внутри контейнера под супервизором (мдакаю) Мог херню сморозить, но в просторах интернетов реально много всяких способов и это жуть... По-моему с нодой или голангом таких проблем вообще нет, 1 контейнер на все приложение еп

Ребята, всем привет. Запутался уже в докеризации PHP приложения. Уж больно много вариков предлагают. 1.Контейнер NGINX + Контейнер PHP-FPM как FastCGI + Код 2.Контейнер NGINX + Контейнер PHP-FPM + Контейнер с кодом, volume которого юзается в nginx + php 3.Один единственный контейнер, куда запихнули NGINX + PHP-FPM, которые запускаются внутри контейнера под супервизором (мдакаю) Мог херню сморозить, но в просторах интернетов реально много всяких способов и это жуть... По-моему с нодой или голангом таких проблем вообще нет, 1 контейнер на все приложение еп

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

Ребята, всем привет. Запутался уже в докеризации PHP приложения. Уж больно много вариков предлагают. 1.Контейнер NGINX + Контейнер PHP-FPM как FastCGI + Код 2.Контейнер NGINX + Контейнер PHP-FPM + Контейнер с кодом, volume которого юзается в nginx + php 3.Один единственный контейнер, куда запихнули NGINX + PHP-FPM, которые запускаются внутри контейнера под супервизором (мдакаю) Мог херню сморозить, но в просторах интернетов реально много всяких способов и это жуть... По-моему с нодой или голангом таких проблем вообще нет, 1 контейнер на все приложение еп

Если у вас проект на php, то берите первый вариант. Не надо все пихать в один контейнер.

Ребята, всем привет. Запутался уже в докеризации PHP приложения. Уж больно много вариков предлагают. 1.Контейнер NGINX + Контейнер PHP-FPM как FastCGI + Код 2.Контейнер NGINX + Контейнер PHP-FPM + Контейнер с кодом, volume которого юзается в nginx + php 3.Один единственный контейнер, куда запихнули NGINX + PHP-FPM, которые запускаются внутри контейнера под супервизором (мдакаю) Мог херню сморозить, но в просторах интернетов реально много всяких способов и это жуть... По-моему с нодой или голангом таких проблем вообще нет, 1 контейнер на все приложение еп

контейнеры это же про изоляцию процессов. и про совместимость и повторяемость в разных средах. про удобство выкатки (с учетом что есть оркестратор). исходите из этих тезисов.

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

А если это не этап разработки, то лучше копировать код в nginx и php-fpm контейнеры и обойтись без workspace контейнера или также монтировать код с отдельного ?

А если это не этап разработки, то лучше копировать код в nginx и php-fpm контейнеры и обойтись без workspace контейнера или также монтировать код с отдельного ?

Например на стейдже или проде

Код через Волюм просто пробрасываешь в контейнер

Код через Волюм просто пробрасываешь в контейнер

т.е. это криво, если локально собрать все пхп зависимости композером, статику нодой, скопировать при сборке это в nginx и php-fpm, запушить эти образы в репо и обновить сервисы на стедже?

Код через Волюм просто пробрасываешь в контейнер

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

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

а в вольюме просто git checkout и готово

но тоже костыль

понял, спасибо коллеги

Всем привет. Мужики у меня такая ситуация. Есть короче контейнер который работает на базе image которая весит под 10 ГБ, так уж получилось что не было возможность сделать volume для него. Так вот вопрос. Могу ли я как-то оставить работать контейнер, но удалить этот image ?

ну, очевидно, этих команд нет в контейнере

Всем привет. Мужики у меня такая ситуация. Есть короче контейнер который работает на базе image которая весит под 10 ГБ, так уж получилось что не было возможность сделать volume для него. Так вот вопрос. Могу ли я как-то оставить работать контейнер, но удалить этот image ?

нет

нет

Блин ...

нет

А чилд как убить ?

в смысле?

В смысле есть напрмер node и из него создалось image которая работает в контейнере

Пишет что unused но удалить не дает ... Типо это чилд того image который работает сейчас

полный путь до бинарника пропиши

Господа, добрый день, подскажите новичку как правильно организовать Есть на локальной машине виртуальный домен test.api.local под ним на апаче крутится апишка. Теперь я пытаюсь из другого сервиса из докера контейнера достучаться до этой апишки соответственно когда я пингую этот test.api.local из контейнера, то он стучится на 127.0.0.1, и как я понимаю, он стучится внутри контейнера сам на себя, а не на мою реальную машину. Как мне обьяснить ему что test.api.local это не он сам, а указать ему путь до реальной машины?

Сначала мне показалось, что я понял о чём идёт речь, но потом запутался и понял что ничего не понял

Господа, добрый день, подскажите новичку как правильно организовать Есть на локальной машине виртуальный домен test.api.local под ним на апаче крутится апишка. Теперь я пытаюсь из другого сервиса из докера контейнера достучаться до этой апишки соответственно когда я пингую этот test.api.local из контейнера, то он стучится на 127.0.0.1, и как я понимаю, он стучится внутри контейнера сам на себя, а не на мою реальную машину. Как мне обьяснить ему что test.api.local это не он сам, а указать ему путь до реальной машины?

Что

Можно по-человечески плз

Что куда и как хочешь чтоб было

сорянчик :( на физ машине есть виртуальный домен test.api.local хочу из докер контейнера в него постучаться для физ машины этот домен доступен по 127.0.0.1:80 (там сидит апачь) Как мне контейнеру обьяснить что test.api.local это не внутри контейнера, а снаружи на физическое машине?

Из докер контейнера достучаться по доменному имени на физ машину :)

Доменное имя у тебя в хостс типо создано?)

ну да :)

Ну красава

Ты наркоман ,но если я всё правильно понял..то контейнер не знает о твоём имени и не может знать. И вообще зачем так?

Сильная херня

Дайте две

Ты наркоман ,но если я всё правильно понял..то контейнер не знает о твоём имени и не может знать. И вообще зачем так?

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

из ваших фраз я понял что так не надо насиловать мозг да ?:)

Ну пусть по ip обращается

Так себе кейс)))

просто завернуть апи в другой контейнер и все?

Ну пусть по ip обращается

по айпи физ машины внутри реальной сети?

по айпи физ машины внутри реальной сети?

Может и так ... либо в хотс контейнера пропиши...ну зачем так?

Еще, вроде, можно через json передавать параметры локальных днс серверов докеру. Вот не знаю, можно ли ему таким образом скармливать конкретные днс записи

Может и так ... либо в хотс контейнера пропиши...ну зачем так?

не не подумайте я не извращенец, я только учусь :)

И ещё то же самое вроде параметром можно передавать

Купи в эту сторону

Цель обращаться из контейнера по днс к хосту?

Просто твой контейнер ничего не знает о том что там у тебя ещё локально стоит

По имени по крайней мере

По ip должно работать

Не по loopback-ip ессно)

Да, запись в хост контейнера с указанием доменного имени на физ айпишник реальной машины помог, спасибо :) Пойду дальше изучать чудесный мир контейнеризации :)

Цель обращаться из контейнера по днс к хосту?

просто учусь работать с докером, какие примеры в голове появляються то и пытаюсь сделать :)

Да, запись в хост контейнера с указанием доменного имени на физ айпишник реальной машины помог, спасибо :) Пойду дальше изучать чудесный мир контейнеризации :)

Это понятно...изврат!

Это понятно...изврат!

я все щас перенесу в контейнеры и пойду тыкать в нетворки :)

Спасибо ещё раз за помощь, ребят.

давай так

я все щас перенесу в контейнеры и пойду тыкать в нетворки :)

в композ потыкай

Это ты уже не контейнеры изучаешь а обычную инфраструктуру

Не в ту степь тебя унесло

Днс, нетворкинг и всё это вот такое же как и везде, в виртуализации обычной например

Днс, нетворкинг и всё это вот такое же как и везде, в виртуализации обычной например

вообще везде. ну пусть тестит

Ты же не будешь его учить и направлять

Добрый день. Появилась задача захостить несколько десятков сайтов на django. Хочу запихнуть их в docker, т.к. зависимости у некоторых сайтов сильно отличаются + некоторым нужна устаревшая версия питона, в стандартных репах ее нет. Нормально ли для каждого сайта делать свой образ с зависимостями?

Да

Да

А они не много будут места на диске жрать?

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

Да, если у тебя будет 1-2 слоя отличаться, то только они будут дополнительное место занимать

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

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

Можешь сделать один большой

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

Кеш при сборке, при хранении образа одинаковые слои не повторяются

Кеш при сборке, при хранении образа одинаковые слои не повторяются

Да

Да ему один подойдет большой

Нах пладить из-за одной библиотеки

Сейчас будет сидеть добавлять по 1 2 ...

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

один большой на все случаи жизни?

один большой на все случаи жизни?

Мне кажется, что так говорить некорректно

один большой на все случаи жизни?

Пффф, не так, под твои сайтики

У тебя различие в чем в либах ?

Версиях питона ?