спасибо. А я правильно думаю что базу данных лучше нативно в систему ставить? не в контейнере. Производительность лучше.

Нет, не важно. Главное, что это должен быть отдельный контейнер

Либо если масштабируетесь, то базы вынести вообще на отдельный узел

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

Спасибо за помощь!

Добрый вечер. Есть связь между 2 контейнерами в 2 композ-файлах через external_link. Волнует вопрос: могу ли я как-то однозначно определить наименование контейнера А для использования его в контейнере Б в external_link?

Добрый вечер. Есть связь между 2 контейнерами в 2 композ-файлах через external_link. Волнует вопрос: могу ли я как-то однозначно определить наименование контейнера А для использования его в контейнере Б в external_link?

Да

Да

Поделитесь?

Ну, дока по докер компоуз

Вариантов три

1. container name 2. Alias 3. Зафиксировать айпи

Да, 3 можно сделать

1. container name 2. Alias 3. Зафиксировать айпи

1 не помог, нетворк у всех общий

1. Значит что-то делаете не так

1 не помог, нетворк у всех общий

Если есть связь между двумя контейнерами в двух разных docker-compose файлах через external_link то данный факт уже говорит о том что есть какой то однозначный способ общения между этими двумя контейнерами. Для однозначного определения имени контейнера используется директива (неожиданно) container_name для четкого указания имени контейнера и дальнейшего его использования в корыстных целях в одугих местах конфигурационного файла, можно попробовать указать его в external_link например, лично не проверял, но уверен что начать поиски лучше всего отсюда

Подскажите, как более правильно собирать контейнер для дев и прод окружения ? Например, в случае PHP, для дев разработки нужно установить xdebug и выключить opcache в конфигах, для прода xdebug не устанавливать и включить opcache Пока на ум приходит : 1. Перенос таких вот вещей в отдельный sh скрипт 2. Это будут совсем разные Dockerfile для прода и дев.

Подскажите, как более правильно собирать контейнер для дев и прод окружения ? Например, в случае PHP, для дев разработки нужно установить xdebug и выключить opcache в конфигах, для прода xdebug не устанавливать и включить opcache Пока на ум приходит : 1. Перенос таких вот вещей в отдельный sh скрипт 2. Это будут совсем разные Dockerfile для прода и дев.

Оба варианта возможны

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

Можно завести отдельный дев образ

И в from передавать что нужно

В дев образе есть xdebug и выключен opcache

Остальная-то часть сборки не отличается

Зачем копипастить

Можно один докерфпйл

Через arg передать dev/prod - на выходе два образа, с общими слоями

Не совсем удобно иногда, у тебя может быть 3 проекта на пыхе например

Где dev от prod отличается всегда одинаково

Опкешем и xdebug'ом

Тогда проще завести dev образ

А если один и прибавления не ожидается, то да, аргумент вариант

Не совсем удобно иногда, у тебя может быть 3 проекта на пыхе например

И что?

И в каждом докерфайле у тебя будет написано одно и то же

Договорись, что у тебя структура проектов одна

Типо исходники - в src. И все. Один докерфайл на три проекта готов

А тут не всегда получится, могут например модули отличаться и подобные вещи

У меня структура одна, отличия дева от прода одни

А вот докерфайлы таки разные

У меня структура одна, отличия дева от прода одни

Сильно разные?

Ну, строк на 40 диффа есть точно

Ну, т.е. в один докер файл не свести? Ну, будет тогда два докерфайла: общий для прода и общий для дева

Не, я про другое

Для прода у каждого проекта разные

И достаточно хорошо разные

Ааа

Разные зависимости тянутся, разные вещи собираются

Ну, ок. И их не свести к одному? Даже через флаги, передаваемые через build args?

А вот дев часть, у всех одинакова - xdebug и ещё пара мелочей

Разные зависимости тянутся, разные вещи собираются

И что? Пайтонщиков это не останавливает. requirements.txt и полетели

Ну, ок. И их не свести к одному? Даже через флаги, передаваемые через build args?

В теории можно, но будет банально неудобно

Ну, ты понимаешь, про что я.

В теории можно, но будет банально неудобно

Ну, да, надо смотреть по месту

Ага, вообще в питоне просто запуск setup.py

А там все написано

Но там все из одного места

Условно все сильно зависит от того насколько часто ты хочешь перекатиться на новую версию пыха в одно действие

А в пхп бандлы через композер, модули через pecl, а что-то странное вообще собирать надо

А в пхп бандлы через композер, модули через pecl, а что-то странное вообще собирать надо

Говно, а не язык

Ну, это не языка в общем-то проблема

Ну, это не языка в общем-то проблема

На самом деле - его

Ибо язык это не только спека на синтаксис, но и экосистема

Скорее тех же людей, что язык пилят)

Ибо язык это не только спека на синтаксис, но и экосистема

Да, согласен

Говно, а не язык

где бы ты был , если бы не это "говно" =) но вообще экосистема php она такая, потому что слишком много Си под капотом, в котором conan только недавно появился и нормальной практики пакетостроения не было

В питоне тоже си под капотом

И нет таких проблем

А питон ещё и старше

То есть дело и не в том, когда что появилось

В питоне тоже си под капотом

о дааа =) расскажи это какой нибудь "либе" которая собирается с каким нибудь CUDA или просто любому пакету который является биндингом к чему нибудь специфическому =) проблем со сборками "питонячих пакетов", если они зависят от Сишных вещей, навалом, особенно если вы какой нибудь начинающий датасотонист =)

где бы ты был , если бы не это "говно" =) но вообще экосистема php она такая, потому что слишком много Си под капотом, в котором conan только недавно появился и нормальной практики пакетостроения не было

И что? Писать в машинных кодах опять ?

Проблемы сборки отдельных модулей - это проблемы сборки именно отдельных модулей, а не процесса вообще

И что? Писать в машинных кодах опять ?

чё к чему это заявление?

о дааа =) расскажи это какой нибудь "либе" которая собирается с каким нибудь CUDA или просто любому пакету который является биндингом к чему нибудь специфическому =) проблем со сборками "питонячих пакетов", если они зависят от Сишных вещей, навалом, особенно если вы какой нибудь начинающий датасотонист =)

Не отрицаю

чё к чему это заявление?

К тому, что зачем нас тащить в прошлое?

Можно и ходить жопой вперёд, но это не значит, что процесс ходьбы кривой

Это значит, что кто-то ходит криво

о дааа =) расскажи это какой нибудь "либе" которая собирается с каким нибудь CUDA или просто любому пакету который является биндингом к чему нибудь специфическому =) проблем со сборками "питонячих пакетов", если они зависят от Сишных вещей, навалом, особенно если вы какой нибудь начинающий датасотонист =)

А ещё сейчас проблема с конфликтами версий модулей в пайтоне

И что? Писать в машинных кодах опять ?

да нет, для начала просто перестать называть "говном" вещи, которые сделаны людьми гораздо более умными чем ты =)

К тому, что зачем нас тащить в прошлое?

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

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

Я не спорю. Пускай дальше кормит. Без меня. То то же баду переходит на голанг с пыха

Собственно некоторые вещи в языках вполне такое наследие просюисхождения

Php вон означал personal home page

=) а где кстати такое крутое мясцо подают? как на апатарке? ;)

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

=) а где кстати такое крутое мясцо подают? как на апатарке? ;)

Рига

Найдете место сами? Если нет - скину ссылку в личку

Я не спорю. Пускай дальше кормит. Без меня. То то же баду переходит на голанг с пыха

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

Как и js имеет проблемы, у которых ноги растут из того, что это создавалось быстренько прототип набросать насколько помню

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