MiksIr
miksir@home:~$
На самом деле не о Vagrant , а о том, где живут файлы, php и база.
Вводные:
- Гетерогенный парк машин разработчиков - маки, винда, линукс
- Мобильность актуальна в последнюю очередь
- Ресурсы машины важны: для разработчиков то не очень, но есть еще фронт, у которых может быть запущена куча тяжелого софта, виртуалок для тестирования и прочее.
Условно варианты я разбиваю по взаимному местоположению php+nginx и базы.
Файлы лежат на клиенте, ибо иначе получим тормоза IDE и кучу проблем при ошибках сетки и т.п.
А. Все на сервере.
Б. Все на клиенте.
В. PHP+nginx на клиенте, база на сервере
Те преимущества и недостатки, которые я вижу
А. Все на сервере.
Вводные:
- Гетерогенный парк машин разработчиков - маки, винда, линукс
- Мобильность актуальна в последнюю очередь
- Ресурсы машины важны: для разработчиков то не очень, но есть еще фронт, у которых может быть запущена куча тяжелого софта, виртуалок для тестирования и прочее.
Условно варианты я разбиваю по взаимному местоположению php+nginx и базы.
Файлы лежат на клиенте, ибо иначе получим тормоза IDE и кучу проблем при ошибках сетки и т.п.
А. Все на сервере.
Б. Все на клиенте.
В. PHP+nginx на клиенте, база на сервере
Те преимущества и недостатки, которые я вижу
А. Все на сервере.
+ Почти не жрет ресурсов клиента
+ Легко управляется конфигурация (в крайнем случае даже не требует менеджера конфигурации, ибо один конфиг на всех)
+ Администратор может добраться до файлов разработчика (редко, но случается, типа "забыл закомитить")
- Не мобильно
- Проблемы синхронизации.
Вот эти проблемы синхронизации такая приличная ложка дегтя. Варианты
Б. Все на клиенте.+ Легко управляется конфигурация (в крайнем случае даже не требует менеджера конфигурации, ибо один конфиг на всех)
+ Администратор может добраться до файлов разработчика (редко, но случается, типа "забыл закомитить")
- Не мобильно
- Проблемы синхронизации.
Вот эти проблемы синхронизации такая приличная ложка дегтя. Варианты
1. монтируем с сервера
В общем все вот эти минусы приводят к тому, что я ищу другие варианты сейчас.+ работаем с одной копией данных и на клиенте и на сервере
- проблемы с клиентом могут приводить к проблемам на сервере, например, блокировка процессов. Возможно тут нужно смотреть другие решения по сетевым файловым системам
2. Синхронизируем средствами IDE или иными однонаправленными (хотя им доверия меньше)- проблемы с клиентом могут приводить к проблемам на сервере, например, блокировка процессов. Возможно тут нужно смотреть другие решения по сетевым файловым системам
+ нет проблем с блокировками из первого способа
- возможные рассинхронизации и задержки синхронизации
- проблема со средствами сборки и прочим - или ставить на клиента (не удобно из-за гетерогенности, а значит сложности поддержания конфигурации) или получать собранную версию на сервере и как-то забирать на клиент руками(?)... муторно.
3. Как вариант - двусторонняя синхронизация- возможные рассинхронизации и задержки синхронизации
- проблема со средствами сборки и прочим - или ставить на клиента (не удобно из-за гетерогенности, а значит сложности поддержания конфигурации) или получать собранную версию на сервере и как-то забирать на клиент руками(?)... муторно.
+ нет проблем с системами сборки, можно запускать на сервере
- все минусы рассинхронизации + потенциальные конфликты
- так и не нашел вменяемого гетерогенного решения реалтайм двусторонней синхронизации
- все минусы рассинхронизации + потенциальные конфликты
- так и не нашел вменяемого гетерогенного решения реалтайм двусторонней синхронизации
+ Мобильно
+ Все системы сборки работают хоть и внутри контейнера, но с одной копией данных
+ Относительно легко поддерживать конфигурацию (или vagrant или просто linux box + менеджер конфигурации)
* Чуточку сложнее мантейнить базу (иногда нужно работать с реальными дампами данных - т.е. написать их заливку во все контейнеры - решаемо, по-этому и не минус)
- Ресурсы клиента. Если мы хотим резвую базу на больших выборках - достаточно много ресурсов.
Для того, что бы решить минус Б, берем вариант В
В. PHP+nginx на клиенте, база на сервере+ Все системы сборки работают хоть и внутри контейнера, но с одной копией данных
+ Относительно легко поддерживать конфигурацию (или vagrant или просто linux box + менеджер конфигурации)
* Чуточку сложнее мантейнить базу (иногда нужно работать с реальными дампами данных - т.е. написать их заливку во все контейнеры - решаемо, по-этому и не минус)
- Ресурсы клиента. Если мы хотим резвую базу на больших выборках - достаточно много ресурсов.
Для того, что бы решить минус Б, берем вариант В
+ Все плюсы Б кроме мобильности
+ Жрет мало ресурсов (но жрет)
- Мобильность (раз уж перешли на контейнеры - неплохо бы)
И вроде В вариант подходит, но мысль получить мобильность в перспективе приводит к гибкому контейнеру, который определяет - где он, и или запускает базу, или нет. А если идти дальше, то этот же контейнер может работать и на сервере, подцепляя локальные файлы по самбе или т.п.+ Жрет мало ресурсов (но жрет)
- Мобильность (раз уж перешли на контейнеры - неплохо бы)
В общем к чему этот пост. Обобщение мыслей и сбор плюсов/минусов, которые я упустил.
