Pavel Zarubin

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

Вообще чтобы в продакшене железобетонно держать контейнеры есть такая штука как kubernetes, на ней многие хостеры строят например хостинги) И не факт что ваш хостер не хранит ваши файлы в контейнерах)
Раньше — да, распространенное мнение было, но не сейчас, например у нас в компании наш продакшн лежит в контейнерах под управлением kubernetes, правда и наш продакшн настраивал не Павел Зарубин, а опытные девопсы, по этому конкретно за свою сборку могу говорить только за себя, что пока что инцидентов по ней не было, но это вовсе не значит что не стоит использовать докер на продакшене

А как себя ведёт БД в докере на production?

Отлично себя ведет, пока инцидентов не было)

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

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

И в этом случае, если контейнер Docker с БД упадёт, то все данные до последнего сохранённого дампа тоже пропадут?

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

Я сейчас так поступаю: залетным клиентам я настраиваю статический сервер и прощаюсь с ними навсегда, только этот статический сервер все равно смотрит на докер конфиги, чтобы в случае чего я мог забрать именно ту конфигурацию, которая в данный момент у клиента парой кликов, а вот клиенты которые на поддержке и в вечно активной разработке находятся на моем сервере где кроме докера ничего больше не установлено и крутятся в контейнерах, это позволяет за секунды делать деплой, да и если что то случится мы с ними все равно на связи, но повторюсь, за три месяца инцидентов у меня не было)
Вот например один из таких сайтов в контейнере: yugsn.ru/

А еще есть вот это, и это тоже бесплатно) modstore.pro/packages/ecommerce/selectfilters

Ну вот же! То о чем я говорю:

Части которые тебе нужно каждый раз для каждого проекта менять i.imgur.com/keHUXYA.png знать пользователя и БД, расположение папок и т.д., я уже молчу что из примера выше тебе нужно будет еще и redis у себя развернуть и еще миллион телодвижений сделать, в общем безсмысленный диалог, давай его заканчивать, ты останешься при своем мнение, я при своем)

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

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

В случае если проект уже существующий, то просто закидываем его в папку app заменяем modx.sql на свой пишем make init отказываемся от инициализации нового проекта и все точно также просто работает

Проблема в том, что в этом случае мне сначала надо написать для ansible инструкции конкретно для этого проекта, а только потом удобно швырять проект туда-обратно

Ладно, беру последнюю попытку объяснить проблему ansible в моем случае:

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

1. Развернуть redis у себя
2. Поменять все пути в config.core.php
3. Поменять доступы к БД

Ansible может сделать так чтобы я этого не делал? И если да, то как, поделишься?

Так объясни в чем я не прав, еще раз, есть 50 проектов, все 50 проектов нужно переносить между локальной машиной и сервером, у всех 50 проектов 50 разных баз данных, 50 разных технологий и 50 разных серверов на разных ОС семейства Linux, как я с помощью ansible смогу не писать конфигурации или написать их один раз для всех проектов сразу, подскажешь?

Один раз для каждого проекта и каждой железяки я правильно понимаю?) Еще раз, это не решает ни одну из описанных в статье проблем, мне в принципе не нравится писать конфигурации и для 50 проектов писать 100 конфигов (Prod/Dev для каждого) не самое веселое занятие

Я знаю что это, ну т.е. для каждого проекта мне нужно создать несколько видов конфигурации, так?)) И как это решает хоть одну из описанных мною проблем?) DevDocker наоборот избавляет вообще от написания каких либо конфигурации вплоть до config.core.php, а ты предлагаешь вместо одной конфигурации писать и хранить их по несколько штук для каждого из окружений

А какую конкретно проблему из описанных мною должен решить ansible? Я не вникал подробно в него, но у нас на работе ansible управляет конфиграциями laravel/yii, как я понимаю, его хорошо использовать когда годами поддерживаешь один и тот же проект, один раз настроил ansible и переключаешься между продом и девом, но он не решит проблему когда у тебя 20 проектов на 20 разными железяками, 20 разными БД и с 10ю разными сервисами, разве нет? Ведь на каждой железке своя структура директорий и для каждого проекта его придется конфигурировать отдельно, поправь, если я не прав

Вам нужно приджойнить таблицу msProductFile по аналогии с другими

Для этого в pdoResources существует такой параметр как limit, также можно выводить через pdoPage для пагинации

Ну я не работаю уже с MODX в целом) По этому да, у нас есть и девопсы и аналитики и тестировщики и нет CMS, только фреймворки :)

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

все таки это не виртуальная машина, а виртуальный контейнер и внутри его нет операционной

Это так, но гораздо легче для понимания воспринимать докер как виртуальную машину, он монтирует внутреннюю файловую систему и интернет интерфейс во внешнюю и/или наоборот, что позволяет заниматься разработкой извне

То как знать какая именно внутри файловая система? Какие там есть директории и так далее.

А тут уже как настроите и какую ОС выберете

Тоесть при запуске этого образа развернется полноценная операционная система? Со своей файловой системой, своими демонами, процессами и так далее?

Именно, при том, частой практикой является своя ОС под каждый модуль, т.е. например nginx + php-fpm в одном контейнере, mysql в другом, redis в третьем

У меня есть возможность подключится к виртуальной ubuntu

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

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

Да, если они не смонтированы извне

У меня есть возможность подключится к виртуальной ubuntu? по ssh или как либо по другому?

да, через интерфейс докера docker exec

И как тогда работают контейнеры с базами данных

У любой базы данных есть физические файлы) Вот их и монтируют

придется очень долго и нудно конфигурировать

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

то их файловые системы хоть и схожи но не идентичны

Да, но в целом это забота девопсов, ну или вас, если вы собрались делать свой собственный и не повторимый образ, в любом случае «наружу» торчат только файлы проекта, иногда конфигурации nginx/apache и файлы баз данных

например пути прописаны /usr/bin и содержаться команды для оболочки bash

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

от имени какого пользователя это все работает?

Опять же, как настроит разработчик, но чаще всего от виртуального рута, вам нужно прокинуть собственного пользователя в виртуальный рут, для этого существует команда docker login, это делается один раз

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

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

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

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

Или вот из недавнего и реальной практики:

В проекте логи хранятся в MongoDB,
Новая часть проекта в PostgreSQL,
А старая часть проекта в Mysql

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

В modx как уже сказали докер ни к чему, вот ситуации когда докер — необходимость, а не привелегия:

1) Вам присылают проект, а у него конфигурация писалась на nginx, а у вас на машине развернут апач или наоборот, без докера вам придется переписывать конфиги под свой сервер, а конфиги бывают ой какие не простые

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

3) У вас на машине php7.1, а в проекте который вам прислали в одном из пакетов минимальная версия php — 7.3, опять же вам нужно доустанавливать 7.3 на свою машину со всеми модулями только чтобы развернуть этот проект

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

И на ларавел ты не напишешь быстрее аналог дерева ресурсов.

Я бы поспорил, особенно учитывая что есть великое множество готовых библиотек (например кстати только у нее звезд на гитхабе почти столько же сколько у modx'a), нужно всего лишь добавить каждой модели parent_id и rank (если нужна сортировка), а на фронте есть великое множество библиотек для работы с деревом, которые на вход принимают один и тот же json и можно менять буквально одной строчкой кода

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

Я бы с радостью посмотрел на эти готовые пакеты, либо мы говорим о разном, либо ты не видел тот же билдер в октябре и не представляешь о чем я говорю (кстати билдер, это первое что приводят в пример защитники октября, и к сожалению — это единственное его преимущество, все еще возникает вопрос зачем?)

Такая возможность есть, но она не является обязательной

Обязательной не является, но было бы гораздо удобнее если бы являлась и была удобно реализована)

Но да ладно, это все действительно имхо

Ну во первых я не сравнивал modx с ларавелом, я буквально говорю:
«CMS — для быстрого создания сайта, но процесс расширения ресурсов вручную настолько времязатратен в modx что за то же время можно половину своей админки на Laravel написать», подразумевая что написать свою админку в laravel далеко не быстрая задача, и такие времязатраты в CMS не допустимы и именно по этому modx именно «приучает» хранить все в ресурсах и не делать свои модели под разные сущности, а унифицировать их через id шаблона, что откровенно очень плохая практика

Действительно))) Больше же нигде такого нет)))