кто знает нормальный блин пример docker-compose конфиг для ларки для дева

кто знает нормальный блин пример docker-compose конфиг для ларки для дева

да их много в сети

да их много в сети

они однозначно простые или сделанные хреново

а какой тебе нужен?

а какой тебе нужен?

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

щас скину тебе пример

version: '3' services: frontend: build: docker/frontend depends_on: - backend volumes: - .:/app ports: - "3000:3000" - "3001:3001" command: npm run watch networks: - frontend backend: build: . depends_on: - db - smtp volumes: - .:/app command: ./artisan serve --host=0.0.0.0 --port=8080 networks: - frontend - backend db: image: mysql:5 env_file: docker/mysql/local.env networks: - backend smtp: build: docker/smtp ports: - "1080:1080" networks: - backend networks: frontend: backend:

version: '3' services: frontend: build: docker/frontend depends_on: - backend volumes: - .:/app ports: - "3000:3000" - "3001:3001" command: npm run watch networks: - frontend backend: build: . depends_on: - db - smtp volumes: - .:/app command: ./artisan serve --host=0.0.0.0 --port=8080 networks: - frontend - backend db: image: mysql:5 env_file: docker/mysql/local.env networks: - backend smtp: build: docker/smtp ports: - "1080:1080" networks: - backend networks: frontend: backend:

а не лучше ли phpfpm + nginx или это дело вкуса ? а composer install мне конектится типа по ssh и запускать ?

а не лучше ли phpfpm + nginx или это дело вкуса ? а composer install мне конектится типа по ssh и запускать ?

да, собственно, если нужен nginx - ставишь. а так в нём нет нужды.

да, собственно, если нужен nginx - ставишь. а так в нём нет нужды.

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

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

да, так и есть

тебе зачем ещё какие-то права в изолированном контейнере? я хз

тебе зачем ещё какие-то права в изолированном контейнере? я хз

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

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

я скорее про то когда юзается phpfpm

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

ты сначало зарегал свой Api класс под именем yandex-geocoding как синглтон, а потом зарегал еще. правильно там где регаешь как синглтон первым параметром Api::class а уже в алисе первым параметром Api::class а вторым нужный альяс (определись какой)

я скорее про то когда юзается phpfpm

мб, мб..

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

кто входит на сайт?

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

добавь рута в группу www-data

version: '3' services: frontend: build: docker/frontend depends_on: - backend volumes: - .:/app ports: - "3000:3000" - "3001:3001" command: npm run watch networks: - frontend backend: build: . depends_on: - db - smtp volumes: - .:/app command: ./artisan serve --host=0.0.0.0 --port=8080 networks: - frontend - backend db: image: mysql:5 env_file: docker/mysql/local.env networks: - backend smtp: build: docker/smtp ports: - "1080:1080" networks: - backend networks: frontend: backend:

а можешь пример Dockerfile для бекенда показать ?

добавь рута в группу www-data

просто почему создается от рута)

а можешь пример Dockerfile для бекенда показать ?

FROM php:7.1 RUN apt-get update # Core RUN apt-get install -y unzip git RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer # Debug RUN apt-get install -y mysql-client RUN docker-php-ext-install pdo_mysql mysqli WORKDIR /app

FROM php:7.1 RUN apt-get update # Core RUN apt-get install -y unzip git RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer # Debug RUN apt-get install -y mysql-client RUN docker-php-ext-install pdo_mysql mysqli WORKDIR /app

ниче что я так вопросов задаю многовато вроде в чем разница если я укажу workdir в docker-compose.yml и Dockerfile

ничего. тем более, что я не эксперт )

"в чем разница если я укажу workdir в docker-compose.yml и Dockerfile" лучше открой доку, я не помню, в чём именно отличие

вроде, оба значения нужны

Dockerfile собирается один раз, к слову

поэтому в двух местах указывается

вангую, он обращался к релейшну, который возвращал коллекцию

угадал)

Кто как сделал бы историю изменения сущности? Есть условный Item с несколькими полями типа id, title, text. Как бы вы стали хранить историю изменения этих данных?

Кто как сделал бы историю изменения сущности? Есть условный Item с несколькими полями типа id, title, text. Как бы вы стали хранить историю изменения этих данных?

https://github.com/spatie/laravel-event-projector

сам ещё не юзал, но вроде как подходит под кейс

Кто как сделал бы историю изменения сущности? Есть условный Item с несколькими полями типа id, title, text. Как бы вы стали хранить историю изменения этих данных?

а для чего это надо?

ок, я бы попробовал парсить миграции :D

а для чего это надо?

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

а как хранить - это да, большой вопрос )

Кто как сделал бы историю изменения сущности? Есть условный Item с несколькими полями типа id, title, text. Как бы вы стали хранить историю изменения этих данных?

если уж хардкорить то слушать изменения update и писать куда-то изменения

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

подключить вебхук при мерже новых миграций в проект?

ну да, у меня тут больше вопрос куда писать изменения. Делать доп таблицу с дублированием полей, так себе идея. Если добавить поля то надо будет перепиливать много всего

подключить вебхук при мерже новых миграций в проект?

при чем тут вообще миграции?

при чем тут вообще миграции?

ну, обычно, просто так не меняются схемы

ну, обычно, просто так не меняются схемы

речь не о схеме, а о истории изменений сущности

а, пардон тогда

Кто как сделал бы историю изменения сущности? Есть условный Item с несколькими полями типа id, title, text. Как бы вы стали хранить историю изменения этих данных?

string:event, json:before, json:after

просто в этой же модели хранить?

string:event, json:before, json:after

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

Кто как сделал бы историю изменения сущности? Есть условный Item с несколькими полями типа id, title, text. Как бы вы стали хранить историю изменения этих данных?

Event Sourcing :) но можно тупо в качестве лога

Кто как сделал бы историю изменения сущности? Есть условный Item с несколькими полями типа id, title, text. Как бы вы стали хранить историю изменения этих данных?

Обсервер

Event Sourcing :) но можно тупо в качестве лога

+1

да ну бля, сам момент то отследить легко, мне именно как хранить изменения лучше всего

просто в этой же модели хранить?

нет отдельную таблицу таких пакетов несколько уже есть. гугли model versioning (history)

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

В базе данных

я же кинул уже пакет выше

ты смотрел?

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

тогда точно ES

я же кинул уже пакет выше

ну он именно про ивенты, а не про хранение

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

Что мешает тебе писать все вышеперечисленное так, как ты хочешь?

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

Что мешает тебе писать все вышеперечисленное так, как ты хочешь?

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

Я чет не пойму в чем проблема

ERROR: S client not available

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

просто инфы ради

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

У тебя есть несколько полей, как ты их ещё запишешь ?‍♂

тогда у него не возникало бы подобных вопросов

ок, добавляем в модель Item новое поле foo_bar, значит надо добавлять и в доп таблицу это и перепиливать (возможно) ивент

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

Тут это не при чем

Тут это не при чем

очень даже причем

ок, добавляем в модель Item новое поле foo_bar, значит надо добавлять и в доп таблицу это и перепиливать (возможно) ивент

Ок храни в жсоне

я сам писал как то, nаблица такая была { Schema::create('entities_history', function (Blueprint $table) { $table->increments('id'); $table->unsignedInteger('initiator_user_id')->nullable(); $table->unsignedInteger('masked_user_id')->nullable(); $table->morphs('entity'); $table->string('event'); $table->json('before')->nullable(); $table->json('after')->nullable(); $table->timestamp('executed_at'); });

очень даже причем

Он про способ хранения а не про организацию

я сам писал как то, nаблица такая была { Schema::create('entities_history', function (Blueprint $table) { $table->increments('id'); $table->unsignedInteger('initiator_user_id')->nullable(); $table->unsignedInteger('masked_user_id')->nullable(); $table->morphs('entity'); $table->string('event'); $table->json('before')->nullable(); $table->json('after')->nullable(); $table->timestamp('executed_at'); });

спс

все, можно расходиться)

ну он именно про ивенты, а не про хранение

https://docs.spatie.be/laravel-event-projector/v1/handling-events/preparing-events

спс

такой треш. тебе всего 3 поля надо: field_name, old_value, new_value

вот будет у тебя моделька с парой полей text да еще какой нить json в придачу

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

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

можно хранить n последних

вообще нашел пару пакетов, щас изучаю

спс

я уже понял в общем то)

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

тебе зачем ещё какие-то права в изолированном контейнере? я хз

а то что vendor потом будет создан от рута при composer install не смущает ?

точнее не сущностей в строк в таблице

а то что vendor потом будет создан от рута при composer install не смущает ?

не смущает

пусть там хоть трэш будет в контейнере, вообще похер

это dev, а не prod

именно поэтому подход с правильными агрегатами и ES сильно круче. но ладно... там надо и опыт какой-никакой иметь и скилл

если сильно страшно, что может что-то случиться в контейнере, то вот: You can disable plugins and scripts during package installation or updates with the following syntax so only Composer's code, and no third party code, will execute: composer install --no-plugins --no-scripts ... composer update --no-plugins --no-scripts ...

это dev, а не prod

а допустим если проект стянут с гита, backend же не запустится так как нету еще vendor, нужно перед этим запустить composer install нужно комментить строку command.... и потом запускать контейнер и зависимости ставить ,а потом обратно раскомментировать command ? или как по другому