Как сказали выше можно сделать другое имя пакета. Или использовать пиннинг при помощи модуля apt.
При добавлении репозитория при помощи apt::source указать приоритет для каждого.
@0neS для того чтобы PTR была соответсвующей- да. Если мы говорим о A записи в DNS, то не обязательно, прописываете верные имена в /etc/hostname /etc/hosts и в DNS, этого будет достаточно.
@bk0011m, объясните зачем синкать если в 95% случаев ребята из Барнаула работают только со своим контентом ?
Человек с DFS предложил здравую идею, в nix подобное тоже можно провернуть при помощь bind маунт пойнтов.
У эллиптикса есть API на пайтон. doc.reverbrain.com/elliptics:api-python.
В целом я вас понял, решения не совсем подходят, просто предполагал что нужен постоянный доступ к полному объему данных.
Ну вы либо блокируете воркер на nginx либо блокируете воркера на вашем бэкенде php-fpm.
Я полагаю что быстрее и выгоднее будет делать ресайз на nginx (возможно даже на втором крутящемся локально), чем таскать на бэкенд, инициализировать там php, ресайзить картинку и тащить её обратно.
Теоретически unix socket имеет меньший оверхед "в работе" по сравнению с tcpsockets. Тоесть, опять же теоретически, должно работать быстрее.
Директива keepalive несколько нивелирует эту проблему (оверхед подключения).
В свою очередь с unix socket при настройках по умолчанию велика вероятность отхватить большее количество проблем (частые ошибки вроде resource temporaily unavailable), они решаються тюнингом как fpm так и накручиваем systcl (вроде somaxconn / backlog).
Лично для меня выбор tcp сокет, так как он более универсален, и приложение проще масштабировать в экстренных ситуациях (добавили новый backend сервер, докинули в upstream и все)
А вы что тестить то собрались может раскажите ? )
Вобщем случае приложения собранные под винды и под nix это абсолютно разные приложения.
Да и очень часто приложения собранные под одним дистрибутивом могут не завестись под другим. Версии glibc там и все такое.
Что у вас за чудо приложение которое без особых допилов собирается и работает на всех ОС и при этом вам не хватает 15 linux дистрибов что у них есть ? %)
@MarcusAurelius круто, подскажите пожалуйста вот что...
Представьте что у человека через год будет 1ПБ данных для хранения, которым нужно обеспечить сохранность.
Как вы предлагаете ему с zfs обеспечить горизонтальное масштабирование ?
Самому реализовывать механизмы шардирования на уровне приложения ?
Как реализовывать хотя бы отложенную репликацию как это сделано во всяких там монгах и mysql ?
Как обеспечить обязательную запись в 2 копии при поступлении контента и отложенную запись в 3ю ?
Как обеспечить _доступность_ (читай прозрачный доступ хотя бы к одной копии) к примеру минимум 3х копий данных и периодически проверять их целостность и синхронизировать после возникновения проблем с доступностью той или иной реплики ?
Вот подскажите, зачем этот геморой, если данные проблемы решаются (перекладываются) при использовании нормального object storage.
Или у вас предубеждения какие то по работе с HTTP интерфейсами ?
Я так понял у автора не стоит ограничения в виде POSIX filesystem.
На счет "файловые системы для этого и делали", я бы не был так категоричен, все зависит от характера вашей работы с ФС, если данные пишутся в режииме append only, иногда, "ручная" имплементация объектов хранения (читай блобов) может работать быстрее чем ФС. (поиск и добавление объектов).
@buloshnik простите но вы что то не то читали. nginx тут вобще не причем, он просто доставляет сгенерированный статический HTML от сервиса его производящего, конечному пользователю.
В одном случае у вас php-fpm и протокол взаимодействия между ним и nginx будет FCGI.
В другом случае у вас будет отдельный веб сервер, который будет при помощи модуля интерпретировать код (точно также по факту как и fpm) и отдавать сгенерированный HTML nginx'у но в этот раз по протоколу HTTP.
Так что совет господина @stavinsky было очень здравым. @stavinsky про бету это Вы серьезно ? У них ситуация как с nginx'ом до первой версии :). Яндекс впилил докер в качестве виртуализации в cocaine, а это многого стоит :)
А еще его в проде используют baidu и mailgun :) Так что бета бете рознь.
При добавлении репозитория при помощи apt::source указать приоритет для каждого.