проблема начинается с базами данных в контейнере

и всякий кэш когда ты хранил в файлах потом перенастроил в redis

в redis збс оно в ram

но если ram не хватает и надо юзать файлы то их монтировать только в контейнер

и получае теже проблемы io

поэтому приходится костылять

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

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

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

ну пока нет проблемы зачем ее себе предумывать ?)

У меня просто на всех проектах примерно одинаковое окружение

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

ну пока нет проблемы зачем ее себе предумывать ?)

Учиться же нужно

если что докупишь сервервак воткнешь ноду в куб и збс

если что докупишь сервервак воткнешь ноду в куб и збс

Мне до куба ещё дорасти нужно))

я для dev делаю контейнер workspace

в нем храню окружение разраба

типо composer, yarn и прочие тулзы

чтобы на хост машину их не ставить

типо composer, yarn и прочие тулзы

У тебя получается композер отдельно от php-fpm контейнера?

тогда docker-compose run workspace composer install например обновит зависимости

типо да

Какие в докере проблемы с IO

чтобы на хост машину их не ставить

а почему не в контейнере с пхп? На продакшене же тоже композер нужен

в php-fpm контейнер только php-fpm

Там нативно все

а почему не в контейнере с пхп? На продакшене же тоже композер нужен

зачем?

Мне показалось это неудобным, так как нужно чтобы он был таким же как и php-fpm полностью для установки зависимостей всяких

зачем на проде composer или yarn ?

эти инструменты на этапе сборки нужны

зачем?

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

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

ты обновляешь зависимости на ci

а потом деплоишь контейнер на прод со всеми нужными файлами

Уже не так делают. Делают FROM composer там install потом копируют

То же самое с npm

ты обновляешь зависимости на ci

значит у меня странные представления об этом =\

FROM может быть несколько

И не надо на CI ставить композер

в докер файле это не обязательно делать

у тебя есть грубо говоря папка с бэкендом

Это multistage build?

Это multistage build?

Да

так ci может докер environment поднимать

и там уже будет композер

тот же workspace контейнер

ты обновляешь зависимости на ci

Ты там не планируешь по деплою видос записать? Уже давно идею накинул)

и через docker-compose run workspace composer install —prefer-dist

Не знаю что такое workspace контейнер

Ты там не планируешь по деплою видос записать? Уже давно идею накинул)

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

А, ну можно и так

в workspace можно тулзы хранить для разработки

на проде composer, yarn, webpack не нужно

Мы так тоже на деве делаем, но для прода хотелось бы просто build сделать и не париться по возможности

Но то вкусовщина

так и делай билд

а потом результат билда /dist

вносишь в контейнер фронта где nginx

from nginx COPY /dist /var/www

Ну я понимаю о чем ты

и этот контейнер пушиш в registry

а на проде просто куб увидев новый контейнер

сам перезапустит контейнеры

@KuvshinovEE кстати я щас подумал, что если обновлять зависимости на продакшене при наличии нескольких контейнеров одного типа - может получиться, что на разных контейнерах будут разные зависимости :D

да можно

Ну разные есть способы, вот multistage build можно вместо этого юзать

поэтому существуют бесшовные обновления и "шовные"

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

а на этапе разработки

ты просто docker-compose run workspace npm run dev

ERROR: S client not available

который стартует webpack с hotreload и пробрасывает порт

либо в отдельный dev контейнер где висит такой процесс и в композе порт прокидываешь

ну это чисто имхо

Кубернетес я бы мне кажется не трогал для начала

На сворме кластер попроще поднять да и тот же docker-compose юзать для деплоя можно. А потом когда придет понимание почему сворм не нравится можно и кубернетес :)

ну да это дело вкуса я по продакшену тоже не особо эксперт на контейнерах)

но для разработки очень прикольная штука

дев разработка может вестись в контейнерах например

ci может тоже на контейнерах поднимать окружение для сборки проекта, результат сборки может быть разный и этот результат потом деплоиться по нужным окружениям

а деплоится это может кучей разных способов 1. контейнеры 2. сборка в архив и на фаил сервер, и разворачивание скриптами на каждом сервере и переключение(симлинками например) 3. сборка в .deb .rpm пакет и на всех серверах подключенный репозиторий и билд это залить новую версию пакета в репозиторий

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

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

Ты там не планируешь по деплою видос записать? Уже давно идею накинул)

планирую но лень, хочу некоторые вещи обкатать

планирую но лень, хочу некоторые вещи обкатать

Я вот тоже теорию уже понимаю, но на практике ещё не попробовал, могу статтей накинуть если надо, уже много в закладках

потому что деплой сильно зависит от системы постановки задач о том что такое проект (проект это один сайт, проект это несколько сайто, проекто это фронтенд одно сайта и тд у всех по разному) от того как это разбито в системе постановки задач, а соответственно от того как ставятся задачи далее это все зависит от жизненого цикла задачи (backlog, todo, design, dev, review, test, deploy примерные этапы у всех они разные и по разному называются) и деплой бывает на разные окружения, деплой на production окружение это релиз например, у кого то не бывает промежуточных сборок и там куча своих нюсансов. далее сильно зависит как идет выливка, 1 релиз одна задача или 1 релиз куча задач тут тоже есть разновидности в релизе по одной задаче они выклдываются или сразу все кучей

ну далее исходя их всей этой ... надо выбирать инструменты

Мне надо будет наверное дефолтный сетап делать php + postgres + крон + демон и супервайзор с ним, ну и само собой установка зависимостей и прогон тестов

еще есть dev окружения и тд

Мне надо будет наверное дефолтный сетап делать php + postgres + крон + демон и супервайзор с ним, ну и само собой установка зависимостей и прогон тестов

+ react

но сильно все зависит от способа постановки задач и разделения на проектов

может быть mono repository

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

+ react

Да, но это у меня отдельный репозиторий, соответственно идёт как другой проект, ну и не реакт а vue)

или микросервисы на бэкенде

ну там сборка в обоих случаях одинакова

npm run build и дальше заводится шарманка webpack

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

Ну если монореп с фронтом вместе то немного не понимаю - при любом коммите с изменениями только бекенда - фронт всё равно будет пересобираться?

мне кажется это меньшая из зол)

Или можно как то разделять, узнать затронуты ли файлы фронта?

мне кажется это меньшая из зол)

Ну хз, кэш юзеров будет сбрасываться

Не круто