Кто не заберет свои деньги из этого банка? А кто заберет свои деньги из этого банка? Я не знаю, почему есть те, кто не заберет.
Не очень понял эту мысль. Мне, как клиенту банка, на самом деле все равно где и как банк хранит мои данные. Хранение финансовых данных «не в облаках» никаких гарантий мне не дает.
Если банк соблюдает все регламенты и стандарты, то пусть хранит данные где хочет.
Но дело здесь в принципе. Если сделать бакенд вдвое легче (а AsmBB более чем вдвое легче эквивалента на PHP) то при прочих равных вы сможете обслуживать за те же деньги вдвое больше посетителей. Ну или сэкономить половину бюджета. А половина, иногда может быть много миллионов. Не так ли?
Мне кажется, это ошибочное предположение, что основная часть бюджета тратится на вычислительные ресурсы. Основные затраты — это разработка и сопровождение.
Конечно, если проект написан раз и навсегда, и больше в нем на 100% нет никаких синтаксических и логических ошибок, то да — бюджет будет тратиться только на ресурсы сервера. Но я в природе таких проектов еще не встречал :)
Ваш запрос подойдет для предложенной задачи только при условии «t1.service_id = 1».
Если же нужно найти последние цены по всем видам услуг — то не подойдет :)
Возможно описать настройку Vagrant одним файлом используя Chef?
Методика использования Chef основана на использовании cookbook'ов — готовых наборов рецептов. Поэтому настройка сервера так или иначе будет размазана по этим рецептам.
Какую методику можно переменить что бы быть уверенным в том что Chef-кофиг не протухнет будет актуальным?
В описанном мной подходе как раз используется менеджер зависимостей «librarian», который фиксирует версии cookbook'ов в lock-файле. Версия самого Chef также фиксируется с помощью плагина (это описано в начале статьи).
Есть успешный и комфортный опыт использования Chef для развертывания, как рабочего окружения так и локального на Vagrant?
В нашей команде мы разворачиваем и dev и prod, см. комментарий.
Можно использовать альтернативный подход: для популярных пакетов использовать Chef cookbooks, а специфические вещи настраивать с помощью shell-скриптов (Vagrant поддерживает запуск нескольких provisioner'ов последовательно).
Суть вкратце такова: конфиги production-сервера хранятся в отдельном репозитории, который просто подключается в основной репозиторий проекта. Это позволяет разделить конфиги между разработчиками и системными администраторами.
Если необходимости в таком разделении нет, то можно настройки production-сервера добавить в ".chef/nodes" и немного поправить пути в скрипте «deploy.sh».
Да, вы правы, можно делать provision с помощью shell-скриптов.
Но для сложных конфигураций это может оказаться сложнее, так как Chef из коробки обеспечивает идемпотентность и имеет наборы готовых рецептов для всех популярных пакетов. То есть банально меньше кода получается :)
Не вижу особой разницы в сложности между Puppet/Ansible/Chef.
Описанный мною сценарий мы успешно применяем в командной разработке, при этом разработчикам не нужно разбираться в рецептах Chef, за них это сделал тимлид. Максимум нужно понимать настройки в JSON-файле и уметь делать «vagrant up» :)
А чем не подошел deployment-сервер в шторме, описанный в разделе «Настройка каталога проекта»? Сохраняемые файлы автоматически выгружаются в виртуалку, достаточно оперативно получается.
Homestead проще, но не дает такого контроля. Грубо говоря, Homestead — это черный ящик. Предложенный же вариант позволяет самому выбрать, какие пакеты будут установлены, какие конфиги они будут использовать. И все это будет прозрачно для всех членов команды.
Да, поэтому я описал два варианта хранения проекта в виртуальной машине: в общем каталоге или в домашнем каталоге пользователя приложения (в разделе «Настройка каталога проекта»).
Возможно, я неправильно сформулировал вопрос.
Правильно ли я понял, что код приложения вынужден учитывать все возможные «схемы» документа? Если это так, то вместо одноразовых миграций мы получаем переусложнение основного кода приложения.
Не очень понял эту мысль. Мне, как клиенту банка, на самом деле все равно где и как банк хранит мои данные. Хранение финансовых данных «не в облаках» никаких гарантий мне не дает.
Если банк соблюдает все регламенты и стандарты, то пусть хранит данные где хочет.
Что вы хотели этим сказать?
Мне кажется, это ошибочное предположение, что основная часть бюджета тратится на вычислительные ресурсы. Основные затраты — это разработка и сопровождение.
Конечно, если проект написан раз и навсегда, и больше в нем на 100% нет никаких синтаксических и логических ошибок, то да — бюджет будет тратиться только на ресурсы сервера. Но я в природе таких проектов еще не встречал :)
Если же нужно найти последние цены по всем видам услуг — то не подойдет :)
В описанном мной подходе как раз используется менеджер зависимостей «librarian», который фиксирует версии cookbook'ов в lock-файле. Версия самого Chef также фиксируется с помощью плагина (это описано в начале статьи).
В нашей команде мы разворачиваем и dev и prod, см. комментарий.
Суть вкратце такова: конфиги production-сервера хранятся в отдельном репозитории, который просто подключается в основной репозиторий проекта. Это позволяет разделить конфиги между разработчиками и системными администраторами.
Если необходимости в таком разделении нет, то можно настройки production-сервера добавить в ".chef/nodes" и немного поправить пути в скрипте «deploy.sh».
Но для сложных конфигураций это может оказаться сложнее, так как Chef из коробки обеспечивает идемпотентность и имеет наборы готовых рецептов для всех популярных пакетов. То есть банально меньше кода получается :)
Описанный мною сценарий мы успешно применяем в командной разработке, при этом разработчикам не нужно разбираться в рецептах Chef, за них это сделал тимлид. Максимум нужно понимать настройки в JSON-файле и уметь делать «vagrant up» :)
Правда, перед этим приходится делать «git reset --hard && git clean -fd».
Правильно ли я понял, что код приложения вынужден учитывать все возможные «схемы» документа? Если это так, то вместо одноразовых миграций мы получаем переусложнение основного кода приложения.
Можно уточнить, почему пропадает проблема миграции данных?