Потому что если они через вольюмы говорят они автоматически не переносимы

Угу

угу

:)

да, да, да... это аргумент. Надо подумать че делать.

ассерты генери на стадии docker build и храни в контейнере

всегда так делаю

ок, а как же в ситуации когда несколько php-fpm понадобиться? Они ведь тоже могут не на одной тачке жить?

или это уже не проблемы докера и надо решать своими силами?

тебе и понадобиться несколько php-fpm. У тебя уже в контейнере должно быть готовое приложение

со всей статикой

кэшами для доктрины и прочего

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

как такое решается?

о, это хороший вопрос. Ждал его

можешь воспользоваться aws s3 ?

пользовательская статика должна быть отдельной

и персистентной

это не про докер

а, понял

да, я читал. Хм... интересненько это все. У меня есть закладка в системе на эту тему. Так что вот и займусь реализацией. Так, про код - все билдить и распихивать по контейнерам?

хм... но вот опять же. Есть проект, у него настроено CI, в процессе CI у меня уже создаеться не один контейнер с кодом, а два (или больше). Их хранить в одном репо с разными тегами или под каждый контейнер отдельный репо?

Это уже чисто из опыта тех, кто знает как удобно :)

вообщем, идеально так. ты docke pull your/app отключешь интернет и docker run

и у тебя должен завестись контейнер

эм... у меня их 4 должно завестись.

ну база и мемкеш не в счет, ок... 2 должно стартовать nginx + php-fpm

ну тогда docker-compose up

соответственно pull надо двух контейнеров делать. Верно?

да

А вот как организовать их хранение? в одном репо или в разных?

главное что бы контейнер просто запустился, не меняя ничего в себе

лучше в разных

с тэгами может быть гемор

Это чат про аниме?

А про докер, всё верно

будут монстры типа latest-nginx latest-app latest-app2

Замьючу полжалуй, как-то много месседжей

хм... и то верно.

репа с кодом у тебя может быть одна просто в ней может быть много docker-файлов

о, это хороший вопрос. Ждал его

Смотри, у меня в начале моего пути возникла такая проблема. 1. делаю клон и СКВ 2. далее надо сделать билд. Это значит что мне через контейнер с php нужно запустить composer install так как там проверяются зависимости. Соответствено файлы проекта должны лежать на хост машине, а делаю композер инсталл и потом снова пересоздаю контейнер с пхп в который уже копирую код... так получается?

репа с кодом у тебя может быть одна просто в ней может быть много docker-файлов

сейчас так и есть.

да, всю логику по сбору контейнера прячь в Dockerfile

то есть сперва я делаю что-то типа docker run --rm php:latest composer install а потом docker build ...

ээ..

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

git pull origin master docker build docker run

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

и все в докер файле поместиться. Так, понял. Пойду попробую собрать это все. В голове прям переворот сознаний :)

git pull origin master docker build docker run

Спасибо тебе! Невероятно помог :)

и тебе спасибо

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

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

ну вот у меня в логике это было учтено. У меня есть что-то типа собственного s3 для статики и своим API на отдельном домене. Оно расчитано на хранение картинок и отдачу их с хитрыми параметрами. Так что вроде пока у меня все гладко. Осталось завернуть это и посмотреть что вышло :)

Зачем тогда ты делаешь фигню?

аргументируй

Тогда смысла шарить код - 0. И твои аргументы не очень

почему смысла шарить код 0? Аргументируй.

Потому что ты решаешь проблемы выше, которые решать не надо методом которым это делать не нужно

почему смысла шарить код 0? Аргументируй.

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

Ну не коммитить же код, блин

Образ надо собирать на сборке

угу, плюсую

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

Хочу освоить технологию чтобы расширить свою область знаний и навыков.

Тогда прими докервей а не плоди килотонны фигни

Вот. Какой докервей?

И в 6 раз мне повторить? Ты ж регулярно от него отказываешся

ERROR: S client not available

Людям свойственно учиться :)

Виталий, а можешь в двух словах сказать, зачем тебе в итоге нужно шарить код между 2 контейнерами?

Я услышал от Ярослава мнение выше - что надо взять приложение и разделить его на статику и бизнес логику и каждую из этих частей поместить в имаджи на стадии их сборки

Да, хорошая идея

Ну и, собственно, я это тебе предлагаю уже месяц почти

И тут мы напарыааемся на огромный недостаток yii, в котором ассеты не могут быть сгенерены заранее

Т.к. они генерятся лениво

отруби ассеты и юзай статику

делов то

И тут мы напарыааемся на огромный недостаток yii, в котором ассеты не могут быть сгенерены заранее

у меня тоже проект на yii2

На этапе билда эту ленность не зафорсить?

Коллеги, спасибо всем. Я задал достаточно много вопросов и получил от всех много ответов. Но вот я понял docker-way и теперь увидел все ошибки моей архитектуры. Еще раз всем спасибо :)

Обещаю не выносить код в общий контейнер :)

На этапе билда эту ленность не зафорсить?

Ну впринципе можно вручную перечислить все ассеты и написать 10 строчек кода которые все опубликуют

Но правильный совет дали выше - хочешь идти самым сложным и правильным путем - отказывайся от встроенного менеджера ассетов, и переходи на npm/bower/webpack

Потом остается избавиться от yii, и правильная архитектура готова :)

а на что менять yii?

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

Потом остается избавиться от yii, и правильная архитектура готова :)

Ладно это шутка ?

Ладно это шутка ?

фух. У вас ии какой версии?

Ассетами управлять вполуручную вполне реально

фух. У вас ии какой версии?

От первой до второй. Но они не в докере.

Можно еще разработчиков заменить и тогда точно правильная архитектура готова и приде конец страданиям :) Так в любом проекте... меняешь весь стек, от сервера и технологий до людей и вроде все должно стать лучше :)

Ну прастити, кто тут у нас хочет сделать максимально сложно и грамотно ? ?

Ассетами управлять вполуручную вполне реально

напиши потом решение которое придумали с ассетами. Так как у меня проекта на 2-й версии и я уже тоже задумался из-за docker-way про ассеты... которые в этот вэй никак не вписываются

Ну прастити, кто тут у нас хочет сделать максимально сложно и грамотно ? ?

мне пока нравится, то что мне вправляют мозг и я начинаю думать иначе. Это невероятное ощущение :) Ты уже не как все те холопы которые пихают в один контейнер и супервизор и уже на него nginx, php-fpm, db, memcached и все это в продакшен.

Еще раз спасибо всем кто принимает участие :)

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

ахаха :) выше обсуждали. Это вариант для поиграться и для небольшого продакшена.

Ой да ладно большие продакшены для миллионов пользователей были еще задолго до докера, и не умерли как то

ахаха :) выше обсуждали. Это вариант для поиграться и для небольшого продакшена.

а что такое большой? :)

небольшой - это там где не нужно масштабирование.