Pavel Zarubin

Pavel Zarubin

С нами с 07 сентября 2016; Место в рейтинге пользователей: #13
Pavel Zarubin
7 часов назад
0
Ну я не работаю уже с MODX в целом) По этому да, у нас есть и девопсы и аналитики и тестировщики и нет CMS, только фреймворки :)

В CMS докер — это абсолютно не нужный оверкилл, сайты на CMS как правило так часто не дорабатываются, они не зависят от внешних пакетов, а доработки в основном такого размера, что минусы докера никогда не окупятся сэкономленным временем от его использования
Pavel Zarubin
Сегодня в 10:51
0
все таки это не виртуальная машина, а виртуальный контейнер и внутри его нет операционной
Это так, но гораздо легче для понимания воспринимать докер как виртуальную машину, он монтирует внутреннюю файловую систему и интернет интерфейс во внешнюю и/или наоборот, что позволяет заниматься разработкой извне

То как знать какая именно внутри файловая система? Какие там есть директории и так далее.
А тут уже как настроите и какую ОС выберете

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

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

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

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

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

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

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

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

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

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

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

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

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

При этом выпилить что то одно хотя бы даже временно естественно не вариант, т.к. все ломается. Без докера мне пришлось бы настраивать у себя MongoDB и PostgreSQL, разбираться как это сделать и тратить возможно ни один час просто чтобы развернуть проект, хотя работа, которую я должен сделать вообще никак не связана ни с монгой, ни с постгрессом
Pavel Zarubin
Сегодня в 01:34
+2
В modx как уже сказали докер ни к чему, вот ситуации когда докер — необходимость, а не привелегия:

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

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

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

В основном докер решает такие проблемы в мире PHP, все что он делает по сути — это запускает на вашей машине — виртуальную и конфигурирует ее в соответствии с проектом, это настолько облегчает как разработку, так и деплой, что люди сознательно идут на уменьшение производительности храня продакшен в контейнерах
Pavel Zarubin
21 февраля 2020, 13:21
+3
И на ларавел ты не напишешь быстрее аналог дерева ресурсов.
Я бы поспорил, особенно учитывая что есть великое множество готовых библиотек (например кстати только у нее звезд на гитхабе почти столько же сколько у modx'a), нужно всего лишь добавить каждой модели parent_id и rank (если нужна сортировка), а на фронте есть великое множество библиотек для работы с деревом, которые на вход принимают один и тот же json и можно менять буквально одной строчкой кода

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

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

Но да ладно, это все действительно имхо
Pavel Zarubin
21 февраля 2020, 12:26
+2
Ну во первых я не сравнивал modx с ларавелом, я буквально говорю:
«CMS — для быстрого создания сайта, но процесс расширения ресурсов вручную настолько времязатратен в modx что за то же время можно половину своей админки на Laravel написать», подразумевая что написать свою админку в laravel далеко не быстрая задача, и такие времязатраты в CMS не допустимы и именно по этому modx именно «приучает» хранить все в ресурсах и не делать свои модели под разные сущности, а унифицировать их через id шаблона, что откровенно очень плохая практика
Pavel Zarubin
21 февраля 2020, 10:56
+1
Действительно))) Больше же нигде такого нет)))
Pavel Zarubin
21 февраля 2020, 09:45
+3
Учит — учит, а делает он это требованием совершать большое количество однотипных действий для расширения модели, создания интерфейса на extjs и т.д., Эта проблема бы конечно же решилась если бы вместо фреда выпустили бы конструктор новых типов ресурсов и хотя бы основных моделей, особенно учитывая то, что это не сложная задача но трудоемкая, но видимо сами разработчики modx'a изначально предполагали что хранить все надо в ресурсах, и это же подтверждает наличие настройки форм позволяющее для каждого шаблона сделать свою конфигурацию полей.
А сейчас, по факту, пока я буду расширять класс modResource под каждую свою модель я на том же ларавеле за это время половину админки напишу
Pavel Zarubin
24 января 2020, 00:07
+1
А так, было время я тоже говорил что на modx можно сделать что угодно, что нет никаких ограничений и вообще зачем фреймворки, есть же MODX, он же чуть ли не фреймворк и ни капли не устарел, но все мы потом вырастаем, учимся программировать по настоящему и понимаем что для реальных задач, нужны реальные решения, а не игрушечные
Pavel Zarubin
24 января 2020, 00:03
+4
Неужели на нем можно делать только интернет-магазины и он больше ни на что не годится
На самом деле даже интернет — магазин более-менее достойный ты врятли сделаешь, элементарное отсутствие очередей без которых любому интернет — магазину тяжко, перегруженная БД ненужными полями и таблицами, устаревший и медленный код, отсутствие нормально реализованных событий, кэширования и т.д.
Да, это PHP и все можно прикрутить, да, можно много логик переписать или дописать, но зачем, когда есть фреймворки где за тебя уже продумали большую часть моментов и реализовали это быстро и хорошо?
А что на счет CRM, вам повезет если бизнес загнется или поймет что ваше самописанное решение не нужно, но если все же нет и придется масштабировать под реальные потребности бизнеса, я не завидую тому, кто будет этим заниматься
Pavel Zarubin
24 декабря 2019, 03:54
+1
И еще, все таки динамические компоненты лучше изменять через метод onAvalible (как я описывал тут: modx.pro/howto/15248) т.к. это позволяет работать например с пришедшими данными (record). Взять твою же галку «индивидуальный расчет» она действительно нужна на всех типах доставки? Все таки подозреваю что нужна она только на доставке с определенными классом обработчиком, что собственно и позволяет реализовать onAvalible
Pavel Zarubin
24 декабря 2019, 03:49
+1
Хреново так делать, во первых ты перезаписываешь метод полностью, а если обновится минишоп и добавятся новые поля что делать будешь? Во вторых зачем прописывать одни и те же поля если у родителя они уже прописаны? В общем сначала всегда вызывается родительский метод getFields а уже потом производится работы с массивов который вернул этот метод
Pavel Zarubin
18 декабря 2019, 00:37
+1
Ну во первых где тут краудфандинг, а во вторых честно говоря не знаю ни одну компанию в живую которая работала бы с главпунктом, видимо по этому еще никто компонент и не написал. Чаще всего компоненты пишутся не из разряда «А чтобы написать», а из разряда «Меня попросили написать это, почему бы не оформить и не продавать вдобавок», тут вам не ВП, даже если компонент будет популярен с продаж вы врятли разбогатеете
Pavel Zarubin
17 декабря 2019, 16:03
0
Нет, заходите в плагин msPNNotify в события и там в правой колонке есть приоритет, попробуйте поиграться с ним задать положительное/отрицательное значение
Pavel Zarubin
17 декабря 2019, 15:52
0
У меня такое было один раз, поиграйтесь с приоритетами плагина
Pavel Zarubin
16 декабря 2019, 16:16
0
Не знаю) Попробуйте с инкогнито) Поднял тестовый, на нем тоже все ок

s20760.h10.modhost.pro/manager/
s20760
JeKS3eJ9BCQi
Pavel Zarubin
16 декабря 2019, 16:10
0
Кэш браузера пробовали очищать? Еще раз проверил, у меня все работает
Pavel Zarubin
16 декабря 2019, 13:15
0
А я откуда знаю как в вашем случае в switch вытянуть город? В компоненте идет стандартный чанк где уже показано как вытянуть текущий выбранный город github.com/pavel-one/multiSite/blob/master/core/components/multisite/elements/chunks/city.tpl

А конкретнее в чанк приходит массив городов cities и массив текущего города исходя из урла current_city, распечатывайте их оба, смотрите как вам вытянуть в ваших условиях