[MODX/Laravel] DevDocker - удобная разработка под Linux

Всем приветики, в общем ни для кого не секрет что докер — это шикарная магическая штука и где то там его активно используют но не в modx конечно, где код до сих пор пишут в браузере. В общем 4 года я был в поиске оптимального решения как правильно и удобно вести разработку проектов (раньше на MODX, сейчас на фреймворках) и в итоге могу точно заявить, что я нашел идеальное решение! Под катом я расскажу все что я пробовал за 4 года и минусы каждого решения, ну а не терпеливые могут просто посмотреть видео сборки, которая решает их все или перейти сразу к гитхабу:

Видео

GitHub



Проблематика и личный опыт


Храним все на сервере

Есть такая штука в phpStorm как синхронизация локальных файлов с файлами на сервере
File->New project from Existings File
и да, вполне удобная штука если вынести ядро modx локально, выкачивать только asset'ы и cor'ы компонентов, с помощью этого способа я разрабатывал сайты почти 1.5 года и вот какие проблемы меня поджидали

  1. Невозможность использовать ресурсы своей машины, хотя их значительно больше чем на сервере, особенно актуально когда нужно единоразово спарсить большой объем данных
  2. Медленная работа всего что только можно: сохранение файла = его загрузка на сервер, да, пусть это миллисекунды, но сплюсуйте все эти миллисекунды и получите очень не хилую задержку
  3. Зависимость от удаленного сервера: тут все очевидно — нет интернета — работа стоит, проблемы у хостера — работа стоит, закончилось место — работа стоит и еще десятки минусов
  4. И самое главное — это генерируемые файлы: да, в modx не много файлов генерируются самим движком, но однако бывает, что это необходимо сделать, например прикрутить элементарный композер и вот тут наша удаленная синхронизация превращается в настоящий ад, пакеты нужно устанавливать и на удаленном сервере отдельно и на локальной машине отдельно, любые генерируемые на сервере файлы нужно выкачивать вручную и т.д. думаю вытекающие проблемы для всех тут очевидны
P.s. но в целом я иногда до сих пор использую этот метод, например когда клиент залетный и нужно поправить что то на пару часиков, поставил скачиваться проект, пока бутерброды делал, все скачалось и не надо в браузере редактировать, можно работать в своем окружении, да и 1.5 года я как то справлялся, в общем не самый плохой метод

Поднимаем свой локальный сервер

Ну тут все просто когда проектов 10 и все сложно когда их 50 или они все разные, берем ручки, запасаемся мануалами, устанавливаем php-fpm, nginx, модули для php, mysql все это дело настраиваем один раз, разворачиваем пару проектов, смотрим какие части динамические из конфигов и что лучше всего разделить на разные includ'ы и все это дело настраиваем второй раз.

За время которое я использовал это решение я пришел вот к такой структуре настройки:

php и php-fpm стартуют от моего юзера чтобы не было проблем с правами, nginx смотрит в папку ~/Work/config где я через обычный редактор прописываю свой конфиг для каждого проекта, а в ~/Work/hosts лежит ссылка на /etc/hosts где я ручками прописываю домены (да, хостс доступен для записи от обычного пользователя) и вот какие проблемы это порадило:

  1. Невозможность актализировать hosts, через пару месяцев работы hosts полон десятками не нужных сайтов которых у меня уже давно нет локально, выглядит все это сумбурно и некрасиво
  2. Невозможность актуализировать конфиги, папка config разрастается десятками файлов где фиг пойми что из этого нужно, а что нет
  3. Для разных проектов нужны разные технологии из за чего домашняя машина обрастает всевозможными редисами, мемкешами, и другими сервисами которые в нужны были для запуска пары залетных проектов
  4. Локальный mysql обрастает десятками БД которые уже не нужны, и со временем начинают сыпаться
  5. Сложность передачи проекта другому человеку: когда у меня появились ребята которые мне помогали с работой мне было им довольно сложно объяснить как это все настроить у себя, да и не двеопсы они чтобы во всем этом разбираться
Ну и в целом не очень хочется делать из домашней машины полноценный сервер

Привет, Docker


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

  1. nginx конфиги как надо было писать для каждого проекта так и надо, просто теперь они более структурированные
  2. В hosts все также надо было добавлять записи
  3. Команды довольно длинные и сложные
Но, только у докера я увидел огромную перспективу на автоматизацию, ведь действительно, когда у тебя один проект — один сервер — один набор сервисов автоматизировать можно что угодно, и вот собственно предлагаю свой вариант автоматизации, которым пользуюсь уже не один месяц!

DevDocker


Что он делает? Какие проблемы решает? Ну начнем по порядку, он автоматически добавляет записи в hosts, автоматически разворачивает modx/laravel и базу данных, и для каждого проекта разворачивает свое окружение, вот малый список проблем который он решает:

  1. Добавление записей в hosts
  2. Автоматическая генерация nginx файлов
  3. Одинаковая внутренняя структура файлов, что позволяет не заморачиваться по поводу конфигурирования config.core.php
  4. Одинаковые доступы к БД для каждого проекта, что позволяет не искать нужную базу данных и доступы к ней каждый раз
  5. Удобный деплой (да, его можно развернуть на сервере одной командой и все будет точно также работать как и у вас на локальной машине, только извне)
  6. Упрощение команд через Makefile, все максимально просто и понятно
  7. Одну и ту же сборку можно использовать как для старых проектов, так и для новых (просто закидываем старый проект в app и не соглашаемся на развертывание системы при init)
  8. Быстрое разворачивание новых проектов
И это наверное лишь малая часть того что становится удобнее, по крайне мере я нашел в этом настоящий кайф, советую просто попробовать, docker упрощает работу, а DevDocker позволяет вам абсолютно не задумываться
Pavel Zarubin
21 апреля 2020, 02:12
modx.pro
8
913
+27
Поблагодарить автора Отправить деньги

Комментарии: 48

Alexander V
21 апреля 2020, 03:53
+1
Чем Ansible не устроил? По-моему докер явно лишнее звено в этом стеке.
    Pavel Zarubin
    21 апреля 2020, 08:30
    0
    А какую конкретно проблему из описанных мною должен решить ansible? Я не вникал подробно в него, но у нас на работе ansible управляет конфиграциями laravel/yii, как я понимаю, его хорошо использовать когда годами поддерживаешь один и тот же проект, один раз настроил ansible и переключаешься между продом и девом, но он не решит проблему когда у тебя 20 проектов на 20 разными железяками, 20 разными БД и с 10ю разными сервисами, разве нет? Ведь на каждой железке своя структура директорий и для каждого проекта его придется конфигурировать отдельно, поправь, если я не прав
      Alexander V
      21 апреля 2020, 08:35
      0
      Это управление конфигурациями. Не важно сколько сервисов или серверов.
        Pavel Zarubin
        21 апреля 2020, 08:38
        0
        Я знаю что это, ну т.е. для каждого проекта мне нужно создать несколько видов конфигурации, так?)) И как это решает хоть одну из описанных мною проблем?) DevDocker наоборот избавляет вообще от написания каких либо конфигурации вплоть до config.core.php, а ты предлагаешь вместо одной конфигурации писать и хранить их по несколько штук для каждого из окружений
          Alexander V
          21 апреля 2020, 08:42
          0
          Один раз написал сценарии и пользуйся. Я давным-давно как-то выкладывал. В упрощенном виде это выглядит примерно так.
            Pavel Zarubin
            21 апреля 2020, 08:45
            0
            Один раз для каждого проекта и каждой железяки я правильно понимаю?) Еще раз, это не решает ни одну из описанных в статье проблем, мне в принципе не нравится писать конфигурации и для 50 проектов писать 100 конфигов (Prod/Dev для каждого) не самое веселое занятие
              Alexander V
              21 апреля 2020, 08:46
              0
              Похоже вы плохо понимаете, что такое Ansible. Не надо 100 раз ничего писать.
                Pavel Zarubin
                21 апреля 2020, 08:49
                0
                Так объясни в чем я не прав, еще раз, есть 50 проектов, все 50 проектов нужно переносить между локальной машиной и сервером, у всех 50 проектов 50 разных баз данных, 50 разных технологий и 50 разных серверов на разных ОС семейства Linux, как я с помощью ansible смогу не писать конфигурации или написать их один раз для всех проектов сразу, подскажешь?
                  Alexander V
                  21 апреля 2020, 08:53
                  0
                  Так же, как обычный сайт переносится между хостингами. Rsync, mysqldump. Всё это есть.
                    Pavel Zarubin
                    21 апреля 2020, 09:04
                    0
                    Ладно, беру последнюю попытку объяснить проблему ansible в моем случае:

                    Хорошо, друг, забудем про 50 проектов и 50 бд, предположим один проект, на локальной машине, у меня проекты храняться в ~/Work/AnyName на машине клиента в /var/www/other на машине клиента есть и активно используется redis у меня его нет. Так вот чтобы перенести обычный сайт, мне нужно:

                    1. Развернуть redis у себя
                    2. Поменять все пути в config.core.php
                    3. Поменять доступы к БД
                    Ansible может сделать так чтобы я этого не делал? И если да, то как, поделишься?
                      Alexander V
                      21 апреля 2020, 09:12
                      0
                      Может. В чем проблема? Создается БД, реквизиты передаются в шаблоны или напрямую в файлы крнфигурации. Работать со строками Ansible умеет.
                      Pavel Zarubin
                      21 апреля 2020, 09:14
                      0
                      Проблема в том, что в этом случае мне сначала надо написать для ansible инструкции конкретно для этого проекта, а только потом удобно швырять проект туда-обратно
                      Alexander V
                      21 апреля 2020, 09:17
                      0
                      Ладно. Делай по-своему. Я не навязываю. Частенько просто попадается треш от любителей докера. Которые считают своим долгом для каждого сайта поднять сервер MySQL.
                      Pavel Zarubin
                      21 апреля 2020, 09:25
                      0
                      Ну вот же! То о чем я говорю:

                      Части которые тебе нужно каждый раз для каждого проекта менять i.imgur.com/keHUXYA.png знать пользователя и БД, расположение папок и т.д., я уже молчу что из примера выше тебе нужно будет еще и redis у себя развернуть и еще миллион телодвижений сделать, в общем безсмысленный диалог, давай его заканчивать, ты останешься при своем мнение, я при своем)
Pavel Zarubin
21 апреля 2020, 09:21
+2
Судя из обсуждения выше многие просто не понимают для чего это решение, ну чукча не писатель и не девопс, чукча программист, по этому попытаюсь еще раз объяснить для чего:

Начало:
Клонируем сборку локально, пишем make init выбираем modx, соглашаемся на инициализацию нового проекта и просто работаем
Деплой:
Перекидываем папку с проектом на сервер, пишем make init отказываемся от инициализации нового проекта и все, на сервере у нас все точно также работает, ничего устанавливать не надо, никакие базы данных создавать или менять конфиги также не надо не зависимо от того в какую папку вы положили проект локально или на сервере

В случае если проект уже существующий, то просто закидываем его в папку app заменяем modx.sql на свой пишем make init отказываемся от инициализации нового проекта и все точно также просто работает
    Евгений Шеронов
    21 апреля 2020, 16:59
    0
    Для разработки прям то что надо.

    А как себя ведёт БД в докере на production?
    Пока только видел, что так совсем не стоит делать по ряду причин.
    И в этом случае, если контейнер Docker с БД упадёт, то все данные до последнего сохранённого дампа тоже пропадут?
      Pavel Zarubin
      21 апреля 2020, 17:17
      +2
      А как себя ведёт БД в докере на production?
      Отлично себя ведет, пока инцидентов не было)

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

      И в этом случае, если контейнер Docker с БД упадёт, то все данные до последнего сохранённого дампа тоже пропадут?
      Нет конечно, дамп при down контейнера делается на тот случай, чтобы вы могли полностью удалить папку с bd и пересобрать контейнер, а так вся активная БД монтируется в папку ./bd которая появляется после первой сборки контейнеров

      Я сейчас так поступаю: залетным клиентам я настраиваю статический сервер и прощаюсь с ними навсегда, только этот статический сервер все равно смотрит на докер конфиги, чтобы в случае чего я мог забрать именно ту конфигурацию, которая в данный момент у клиента парой кликов, а вот клиенты которые на поддержке и в вечно активной разработке находятся на моем сервере где кроме докера ничего больше не установлено и крутятся в контейнерах, это позволяет за секунды делать деплой, да и если что то случится мы с ними все равно на связи, но повторюсь, за три месяца инцидентов у меня не было)
      Вот например один из таких сайтов в контейнере: yugsn.ru/
        Pavel Zarubin
        21 апреля 2020, 17:22
        0
        Пока только видел, что так совсем не стоит делать по ряду причин.
        Вообще чтобы в продакшене железобетонно держать контейнеры есть такая штука как kubernetes, на ней многие хостеры строят например хостинги) И не факт что ваш хостер не хранит ваши файлы в контейнерах)
        Раньше — да, распространенное мнение было, но не сейчас, например у нас в компании наш продакшн лежит в контейнерах под управлением kubernetes, правда и наш продакшн настраивал не Павел Зарубин, а опытные девопсы, по этому конкретно за свою сборку могу говорить только за себя, что пока что инцидентов по ней не было, но это вовсе не значит что не стоит использовать докер на продакшене
          Pavel Zarubin
          21 апреля 2020, 17:27
          0
          А как себя ведёт БД в докере на production
          К слову и без всяких виртуализаций на статичном mysql у меня бывало что сыпалась какая то из табличек и из за этого ложился вообще весь mysql наглухо, особенно это часто наблюдается на modx с включенными БД сессиями (по умолчанию) и бешаной посещаемостью
        Anton Erin
        21 апреля 2020, 17:28
        0
        Здравствуйте.
        Можете уточнить, пожалуйста, что означает данная цитата?
        автоматически разворачивает modx/laravel и базу данных
        Уже давно мечтаю о связке MODX с Laravel, чтобы использовать возможности MODX (чанки, сниппеты, админка) и Ларки (Eloquent, Carbon, Blade) вместе.
          Pavel Zarubin
          21 апреля 2020, 17:37
          +1
          Добрый, она означает что при инициализации дает выбрать что разворачивать modx или laravel и на основе этого подставляет нужные БД и генерирует конфиги, посмотрите видео, там в целом все понятно.

          Уже давно мечтаю о связке MODX с Laravel
          Когда начинал знакомится с laravel пробовал это сделать, работает, но получается монстр франкенштейна)) Без изменений ядра совершенно безсмысленное и трудоемкое занятие, в итоге ушел в полностью в laravel и yii, с modx'ом меня связывает пара клиентов, мои компоненты и офигенное сообщество)
            Anton Erin
            22 апреля 2020, 14:17
            0
            монстр франкенштейна
            Это не так. Просто ознакомьтесь с Evo 2.0 на компонентах Laravel и шаблонизатором Blade. Работает просто супер! Разработка — одно удовольствие!
              Павел Голубев
              22 апреля 2020, 14:29
              0
              Ну будем честны, это уже не Modx, а абсолютно другая CMS со схожей идеологией.
                Anton Erin
                22 апреля 2020, 14:36
                0
                Не совсем так!
                Хочешь работать по-старому «как раньше»? Пожалуйста!
                Хочешь использовать функции Blade и Laravel — пожалуйста!
                Хочешь в Blade использовать тэги, чанки и сниппеты Evolution — пожалуйста!
                Тот же родной MODX с очень большой перспективой.

                Я имею в виду именно Evo 2.0 (где от MODX осталось всё), а не October CMS.
                  Pavel Zarubin
                  22 апреля 2020, 15:07
                  +1
                  где от MODX осталось всё
                  смешно)))

                  Тут уже не раз обсуждался форк modx revo, но давай повторим:
                  Смотри, объясню тебе проблематику почему так невозможно сделать в Revo

                  1) Поломаешь всю совместимость с существующими компонентами, а переписывать свои компоненты никто не ринется, т.к. больше половины разработчиков уже потерялось
                  2) Оставлять старую админку? Но многие не довольны ExtJS, да и ExtJS 3.4 устарел, получается что нужно писать новую админку, но если писать новую админку, то даже те, кто захотят перенести свои компоненты — никогда не согласятся это сделать если еще и фронт надо будет переписывать
                  3) Предположим что мы решили написать новую админку на условном VUE и Rest api, идем дальше, что делаем с кодом в браузере? Такую же систему что и октября, где код можно и в файлах и браузере писать, ну ок.
                  4) Что делаем с системой событий? Их слишком много, они слишком нагружают систему и слишком не грамотно реализованы? Переписываем на событийную модель laravel выпилив половину не нужных событий? Ок
                  5) Система прав в Revo реализована плохо, не безопасно и тормознуто, тоже переписываем?

                  Так и что у нас от MODX то осталось в итоге? ТВ поля и пару синтаксических сахаров? Ну и получаем мы в лучшем случае Evo 2.0

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

                  Я бы привел как хороший пример Evo 2.0, но увы нет, они как были отшельниками modx 10 лет назад, так ими и остались, комьюнити никакущее, серьезных компонентов типо minishop2 как не было, так и нет, и это при том, что у них есть офигенный бэкграунд, 10 лет назад (или 13, уже не помню) они решили делать революцию и идти в ногу со временем выпуская сначала свои доработанные сборки modx evo, а потом и совсем отделившись, друг, напомню, они шли к тому что есть у них сейчас больше 10 лет и все равно остались на задворках сайтостроительства имее рок-н-рольский бэкграунд и откусив не малую часть тогдашнего сообщества. Как бы не было грустно, но дайте modx спокойно уже умереть
                    Pavel Zarubin
                    22 апреля 2020, 15:16
                    +1
                    С колокльни комментатора очень легко судить, «ну сделайте мне форк, а вдруг взлетит как октябрь», а вдруг будет востребованно, а я вот например как разработчик не хочу вкладывать силы и душу в проект минимум на пол года, а скорее год. Сейчас не золотой век CMS, CMS все меньше кому то нужны уже даже в России, за пределами России я уже вообще молчу, тут бы дожить существующим CMS спокойно, а новые в принципе обречены на провал какие бы хорошие они не были. Да даже взять тот же мегапопулярный октябрь, зайди, посмотри насколько тухло у них в сообществе, посмотри на баги и детские болезни которые никто не спешит править, и это учитывая то, что октябрь на данный момент наверное для всего интернета считается самой прогрессивной CMS
                Pavel Zarubin
                22 апреля 2020, 14:50
                0
                Просто ознакомьтесь с Evo 2.0
                Я знаком, так же как и с автором

                Только вот Evo 2.0 это не MODX, а скорее Lumen с синтаксическим сахаром под MODX, прочитайте внимательно мой комментарий, цитирую

                Без изменений ядра

                А в Evo осталась только идеология от modx, которая будем честны также уже давно устарела

                И собственно именно по этому Evolution избавился от приставки «Modx» и давненько уже себя позиционирует как совершенно другая CMS
                  Anton Erin
                  22 апреля 2020, 15:03
                  0
                  Но согласитесь, что тот же Lumen с синтаксическим сахаром под MODX приятен удобен в разработке!
                  Почему бы не сделать подобное под Revo?

                  Да, не надо весь фреймворк со всеми компонентами тащить в Revo. Будет вообще сказка и вообще — большой рывок.
                    Pavel Zarubin
                    22 апреля 2020, 15:08
                    0
                    Я выше описал почему нет
            Дима Сайт
            22 апреля 2020, 19:24
            0
            Приветствую!
            Во-первых, спасибо за пост. Всегда интересно узнать какой у кого техпроцесс. Мы используем почти 10 лет метод, который в посте описан как «Храним все на сервере» и признаться честно, первые 3 из 4-х недостатков относятся все же не к организации рабочего процесса, а к хостингу проекта:
            1. У меня многоядерный комп, много памяти, ssd и все такое, но хостинг наших всегда был и остается лучше (к слову, modhost очень хорош, но мы работаем на выделенном сервере, и он эволюционирует со временем, как и рабочие станции разработчиков
            2.… сплюсуйте все эти миллисекунды и получите очень не хилую задержку //только при первой загрузке когда много файлов улетает на сервер, а после, ну правда, за время переключения из phpstorm в браузер и нажатия F5 там уже всегда все прилетает (и нет, я не слоупок, переключаюсь по ALT+TAB и все такое)
            3. "… нет интернета — работа стоит" //… секунд 30 пока переключаешься на мобильный интернет, в 21м веке-то. "… проблемы у хостера — работа стоит, закончилось место — работа стоит" // в этих случаях, «Хьюстон у нас ПРОДАКШН СТОИТ» — так что это все же нельзя считать за минус организации рабочего процесса, как мне кажется, если недостаточно хороший хостинг и все валится вот так, то все равно проект уедет на достаточно хороший хостинг или загнется) в любом случае эти проблемы отпадут.
            "… и еще десятки минусов" // а какие еще могут под этот пункт подходить?

            По последнему пункту минусов хранения всего на сервере "4. И самое главное — это генерируемые файлы..." у меня вопросов нет, неудобства встречаются. Разве что, в нашей практике не приходится выкачивать генерируемые файлы, т.к. если они генерируемые, зачем может понадобится править их на локалке? Правятся конфиги или какие-то шаблоны, по которым они генерятся (тот же конфиг composer: исправил, залил, локально запустил и там запустил, готово)
              Дима Сайт
              22 апреля 2020, 19:32
              0
              Я вот только одного не пойму: какой смысл постоянно наводить тоску по поводу текущего состояния и развития modx revo? Ну да, хотелось бы быстрее, активнее, и т.п., но развитие есть, обновления 2 раза в год, но ведь система не становится хуже, почему при любом поводе уважаемые члены сообщества не воздерживаются поддержания упаднических настроений) Вот и в этом посте уже в первых строках автор «отвешивает колкости» в сторону modx и невзначай сообщает, что больше с modx не работает.

              Зачем? Это же к сути поста и крутости предлагаемых решений описанных проблем вообще никаким боком…
                Pavel Zarubin
                23 апреля 2020, 00:31
                +1
                какой смысл постоянно наводить тоску по поводу текущего состояния и развития modx revo
                Я не навожу тоску, просто объяснил человеку почему идея с форком заранее мертва, от этого мне абсолютно не тоскливо

                но развитие есть
                Смешно, оставлю без комментариев

                почему при любом поводе уважаемые члены сообщества не воздерживаются поддержания упаднических настроений
                Потому что все, в том числе и я, считают modx лучшей из CMS по сей день, и от этого в несколько раз грустнее потому что она остается актуальной даже отстав от всего мира разработки лет на 10

                Вот и в этом посте уже в первых строках автор «отвешивает колкости»
                Каюсь, не очень красиво получилось, наверное. Но я и в жизни не самый позитивный парень

                Зачем?
                Да за тем, что это не нормально и нужно что то менять, возможно каждая такая колкость и сподвигла людей на обсуждение (которое к слову началось сегодня) в группе контрибьютеров о форке. И хотя я и считаю что форк мертворожденная идея, но это единственная возможность сделать хоть что — то, 3я версия не решит ни одну из проблем
                  Дима Сайт
                  23 апреля 2020, 13:19
                  0
                  Потому что все, в том числе и я, считают modx лучшей из CMS по сей день
                  Вот это плюсану, за остальные пояснения — спасибо :)
                Pavel Zarubin
                23 апреля 2020, 00:25
                0
                На самом деле последней каплей для меня стал как раз последний пункт, элементарно, если организовывать нормальное логирование при разработке (а не такое как в modx) то работать на сервере становится невозможно, в нормальной разработке люди делают так:
                tail -f log.log
                И слушают логи только по отдельной части разрабатываемого модуля, а зачастую это несколько логов одновременно, посмотрел бы я как бы ты это делал на сервере когда таких частей надо слушать сразу 4 например.
                Ну и + ко всему генерируются не обязательно логи или служебные файлы, иногда генерируются php модели, да в том же modExtra при билде xml схемы генерируются модели, которые в случае с серверной разработкой нужно выкачивать при каждом изменении
                Иван Климчук
                23 апреля 2020, 00:11
                0
                Хехе. Те же детские болезни, что у меня в начале. Возня с hosts и nginx-proxy.
                Я решил эту проблему, подняв вместо nginx-прокси Traefik, который отвечает за резолвинг локальных доменов, причем он умеет в нормальный https и позволяет декларативно прописывать домены прямо в docker-compose.yml. А чтобы не возиться с хостами, я сделал локальную доменную зону через dnsmasq.
                В ближайшее время выкрою время и допишу парочку своих заметок на эту тему.
                А вот насчет того, что креды у БД везде одинаковы, это все же небезопасно, даже если крутится в контейнерах.
                  Иван Климчук
                  23 апреля 2020, 00:22
                  0
                  Глянул в код, вынужден ругаться.

                  docker system prune -a и прочее — это ж если какие другие окружения на докер подняты, грохнет все к херам. Нельзя так, даже если очень хочется. Я б за нож взялся, случись у меня такое. Хоть это и makefile для удобства, но я бы ограничивал бы его областью конкретного окружения, то есть управлять только тем, что описано в docker-compose.

                  Делать дампы БД, когда в docker есть data-volumes, которые в случае с mysql работают просто как часики (чего не скажешь о postgress) — выглядит крайне крипово. Они сторят файлы БД на локальной машине, сам сервер — в контейнере. При перезапуске данные всегда на месте. Тем более, что конфиги ты через них уже пробрасываешь.

                  Остальное уже придирки. Инструмент задачу решает — уже хорошо.
                    Pavel Zarubin
                    23 апреля 2020, 00:43
                    0
                    это ж если какие другие окружения на докер подняты, грохнет все к херам
                    Если окружения настроены так, что гроханье контейнеров чем то способно навредить — это неправильно настроенные окружения, да и эта рекомендация к тем, у кого возникают элементарные вопросы, а они скорее всего только начинают пробовать докер, чего то серьезного в контейнерах у них в принципе быть не может, те кто понимают что делают до этого пункта даже не дойдут. Я с самого начала своей активности в сообществе взял для себя правило объяснять и показывать для тех, кто вообще не видел ни разу в жизни таких подходов/методов/кода/способов, по этому и решения проблем координальные, я искрине считаю что те, кто уже использует докер если и будут использовать мою сборку, то скорее всего просто форкнут и перенастроят для себя

                    Делать дампы БД, когда в docker есть data-volumes, которые в случае с mysql работают просто как часики (чего не скажешь о postgress) — выглядит крайне крипово
                    Перестраховка, не более, которая позволяет грохнуть папку db в любой момент пересобрать контейнер полностью и сохранить все данные, с текущей скоростью SSD/NVME даже с тяжелыми БД операция дампа происходит довольно быстро, так почему бы не перестраховаться лишний раз?

                    Они сторят файлы БД на локальной машине, сам сервер — в контейнере. При перезапуске данные всегда на месте. Тем более, что конфиги ты через них уже пробрасываешь.
                    Я знаю как работает мой конфиг, спасибо )))
                    Pavel Zarubin
                    23 апреля 2020, 00:35
                    0
                    Traefik
                    Не слышал, почитаю, спасибо

                    dnsmasq
                    Я его тоже использую, в том случае если нужно зарезолвить динамические поддомены, например, но полностью переходить на него не вижу смысла, hosts с 90% задач справляется на ура

                    https
                    Есть в планах прикрутить генерируемые самоподписанные сертификаты, чтобы и локальное окружение было на https

                    это все же небезопасно, даже если крутится в контейнерах
                    Почему? Бд слушает обращения только с локальной стороны, а если у кого то есть доступ к локалке, то бд уже вскрыта потому что любой php проект хранит доступы к бд прямо в коде
                      Иван Климчук
                      23 апреля 2020, 01:09
                      0
                      Зная, что у тебя везде доступы одинаковы, ничего не мешает, утилизируя уязвимость код на php (а они в общем-то могут быть), узнать креды подключения БД и получить полный доступ над системой, а то и всеми твоими проектами сразу. А ты эту информацию уже публично раскрыл. Технически да, они изолированы внутри, но если это продакшен, то лучше так не делать.
                        Pavel Zarubin
                        23 апреля 2020, 09:11
                        0
                        Ваня, ну придирка же)) Если кто то может выполнить php код извне у меня на сервере то ему не составит труда сделать скандир и просто отыскать файл с доступами к бд, по этому ну хватит уже, я долго думал перед тем как использовать одинаковые доступы к бд везде, нет ни одного фактора который говорил бы что это не безопасно
                          Иван Климчук
                          23 апреля 2020, 09:47
                          0
                          Ты можешь воспринимать это как придирку, твое право. И это твоя система, ты за нее в ответе. В то же время ты сам упоминал, что у вас есть окружения, которые настраивали матерые devops, на k8s и прочем непотребстве и там все намного серьезнее и аккуратнее и ведь неспроста это так, согласись?
                          Я по стечению обстоятельств тимлидствую ещё и над несколькими девопсами и мои рекомендации и замечания основаны на определенном практическом опыте этих людей.
                            Pavel Zarubin
                            23 апреля 2020, 10:02
                            0
                            Ты можешь воспринимать это как придирку, твое право.
                            Я просто хочу услышать хоть один способ как человек может вскрыть БД зная даже ее доступы извне не вскрыв при этом локалку) А если человек вскрывает локалку, он по любому получает все пароли от БД т.к. в php они храняться в открытом виде и никого это не парит. Ты же понимаешь что это невозможно?)

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

                            ведь неспроста это так, согласись
                            Не спроста, но у нас извини меня 40 миллионов пользователей и посещаемость 400 хостов в секунду и это только по веб части, еще есть api часть которую используют IOS/Android приложения, но какая там нагрузка знать не в моей юрисдикции.
                            Или ты предлагаешь рассказывать людям работающим на modx как построить контейнеры способные держать 400 хостов в секунду в течении месяцев без перебоев?
                              Сергей Шлоков
                              23 апреля 2020, 12:37
                              +2
                              Или ты предлагаешь рассказывать людям работающим на modx как построить контейнеры способные держать 400 хостов в секунду в течении месяцев без перебоев?
                              Ну началось. То золотой век CMS прошел, то MODX плохой, потому что не может держать 400 запросов в секунду. Ну вечером в пятницу под пару кружек пенноого чая ещё сойдёт, но вроде серъёзные разработчики собрались, а разговоры как у прыщавых подростков.
                              Количество CMS множится, ибо инструментов стало столько, что народ начал придумывать что-то своё в различных комбинациях. Зайди на хабр, удивишься. Конкуренция растёт, поэтому популярность таких мамонтов как WP, Joomla, Drupal и остальных снижается. Вот и весь секрет.

                              А пенять на MODX, что он не может работать в высоконагруженной системе, это уж какой-то лужапук. Ну не предназначен он для этого. Высоконагруженные системы — это отдельный мир. Ты удивишься, но тот же Laravel имеет невысокие показатели среди других фреймворков по RPS (request per second). Зачем развотить холиварные темы?

                              А статья интересная, плюсанул. Пытаюсь побороть себя поставить на локалку с Windows основной вэб стек (Linux, MySQL, NGINX, PHP) в контейнере. Но времени нет.
                                Pavel Zarubin
                                23 апреля 2020, 14:23
                                0
                                MODX плохой, потому что не может держать 400 запросов в секунду
                                Я такого не говорил, не надо переворачивать с ног на голову, я сказал что у нас на проде опытные девопсы делают все сложнее не потому что так нужно делать всем или мой способ не безопасный, а потому что у нас система высоконагруженная и отвал ее хотя бы на 5 минут — это отвал 120 тысяч хитов, по этому собственно у нас на проде «все по другому»

                                Я не путаю горячее с мягким и вовсе не говорю что modx должен держать 400 запросов в секунду

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

                                Ты удивишься, но тот же Laravel имеет невысокие показатели среди других фреймворков
                                Ну началось, мерить скорость фреймворков — себя не уважать, фреймворки — это конструкторы ядра и тебе ничего не мешает взять любой модуль который тебя не устраиват и заменить его на что угодно, у того же Laravel есть люмен с минимальным функционалом, если тебе не хочется тянуть кучу не нужных модулей, а уж там точно нечему тормозить
                                  Сергей Шлоков
                                  23 апреля 2020, 17:08
                                  +1
                                  Я такого не говорил,
                                  Ну не говорил так не говорил.

                                  Сейчас не золотой век CMS, CMS все меньше кому то нужны уже даже в России, за пределами России я уже вообще молчу, тут бы дожить существующим CMS спокойно, а новые в принципе обречены на провал какие бы хорошие они не были.
                                  и
                                  Я не слежу за количеством CMS
                                  Это 2 соседних комментария. Наверно и тут можно выкрутиться, что там имел ввиду не это, а тут не то.

                                  Ну началось, мерить скорость фреймворков — себя не уважать
                                  Вон оно чё, Михалыч. Т.е. когда выбирают фреймворк под высокопосещаемый сайт, кидают кости или смотрят у кого строк в коде больше. Ух уж эти подлые манипуляторы. ))

                                  у того же Laravel есть люмен
                                  Я понимаю о чём ты говоришь. Но с формальной точки зрения Lumen — это не Laravel. Это микрофреймворк от того же автора. А я говорил именно о популярном Laravel.

                                  Ладно, забей, далеко уже ушли от темы.
                                    Pavel Zarubin
                                    23 апреля 2020, 17:18
                                    0
                                    Это 2 соседних комментария. Наверно и тут можно выкрутиться, что там имел ввиду не это, а тут не то.
                                    То что CMS все меньше кому то нужны никак не говорит об их колличестве, я за количеством CMS не слежу, за-то прекрасно слежу за вакансиями, и если раньше только за пределами СНГ было сложно найти работу на CMS, то сейчас и в СНГ все меньше вакансий на CMS и все больше вакансий на фреймворках от этого и от вышеперечисленных факторов такой вывод

                                    Т.е. когда выбирают фреймворк под высокопосещаемый сайт,
                                    Ого, кто то выбирает каждый раз разный фреймворк? Не завидую я этим людям. Обычно берут то что хорошо знают или то, у чего перспективы на долгое развитие, это, фреймворк, он создан для того, чтобы на нем делали что угодно и какой угодно производительности не вводя никаких ограничений, я сейчас говорю про PHP фреймворки, а не про гибриды по типу Spiral
                    Yurij Finiv
                    23 апреля 2020, 14:33
                    0
                    Давно планировал связать с MODX но как-то руки не доходили, спасибо большое.
                      Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
                      48