Я работал с командой, которая раньше устанавливала все приложения и службы HTTP, например Apache или Кот в каталог '/ srv'. Я подозреваю, что в основном для того, чтобы установленные службы были максимально отделены от ОС. В своих проектах я сохранил эту практику. Однако со временем все больше и больше казалось, что это может быть не очень хорошая идея: это мешает вам использовать распространение определенные пакеты (у них была очень плохая репутация в этой команде, поэтому в основном все устанавливались индивидуально), и я заметил, что у меня возникли некоторые проблемы при попытке использовать уже доступные поваренные книги.
Так что в последнее время у меня возникло искушение переключиться на использование пакетов для конкретных дистрибутивов вместо того, чтобы пытаться создавать собственные установки, которые вписываются в эту структуру каталогов. Мне было интересно, могу ли я что-нибудь упустить из виду. Есть ли на самом деле какая-либо веская причина помещать все в каталог '/ srv' или какая-либо веская причина не использовать специальные пакеты для распространения?
Что мне сейчас нужно в моем стеке: nginx, Tomcat (Oracle JDK) и MongoDB.
FHS-совместимый путь для установки стороннего программного обеспечения /srv, но /opt. Проверьте Вот и Вот.
Что касается использования предварительно скомпилированных пакетов, у вас есть два варианта:
Если вам нужно обслуживать всего 5-10 машин, поместите все под /opt выполнимо, но если у вас будет ферма, насчитывающая более пары сотен, вы будете Делая это неправильно ™
На мой взгляд, профессиональный способ сделать это - использовать предварительно скомпилированные пакеты, предоставленные поставщиком, если нет веской причины не делать этого.
я так не думаю /srv когда-либо была хорошей идеей. На этот случай есть /usr/local или /opt каталог, а /srv предназначен для конкретных данных сайта, которые обслуживаются системой.
Это определено стандартом File System Heararchy Standard, имейте в виду, что не во всех дистрибутивах ему соответствует 100%. FHS предлагает следующее:
/srv - Данные для конкретного сайта, которые обслуживаются системой./opt - Дополнительные пакеты прикладного программного обеспечения.Что касается пакетов для конкретных дистрибутивов, вы обычно должны использовать их, если нет веской причины не делать этого. Поддерживать все в актуальном состоянии и следить за тем, чтобы у вас были последние исправления, может быть слишком сложно поддерживать, и это может подвергнуть систему дополнительным рискам безопасности. Даже в тех случаях, когда менеджер пакетов вашего дистрибутива Linux предоставляет более старую, чем необходимо, версию, вы обычно можете найти поддерживаемые сообществом репозитории для более новых версий определенных пакетов, которые было бы легче поддерживать, чем ваши собственные пакеты. Обычно это происходит с более популярными пакетами, такими как nginx в таких дистрибутивах, как CentOS (личный опыт).
Что бы я оставил в /srv вместо этого (имейте в виду, что это личные предпочтения):
/srv/http/example.com)/srv/ftp/example.com)/srv/mail/example.com/user)Это помогает мне сохранить /srv/ организованы с помощью обычно управляемых данных, в то время как большинство дистрибутивов хранят эти файлы в /var, Я использую это, чтобы иметь одинаковую структуру каталогов для общих данных сайта в разных дистрибутивах.
Этот конкретный пример, перенацеливание каждого пакета на / srv, хотя и является формой обеспечения занятости, кажется исключительно близоруким и непродуктивным с точки зрения бизнеса (где продуктивность означает повышение удобства использования / прибыльности / безопасности / и т. Д. Рабочей среды, которую обслуживают эти приложения) .
Если вы можете жить с тем, что пакет дистрибутива делает с вашей системой, тогда вы используете разработку и тестирование, которую команда, которая производит пакет, вложила в него сейчас. и с обновлениями. Если вы не можете жить с тем, что пакет дистрибутива делает с вашей системой, тогда найдите другой пакет или убедите / подбадривайте / изводите группу разработчиков, чтобы они делали что-то «по-своему» (или, по крайней мере, упростите выполнение «по-своему» ) или инкапсулируйте его в виртуальную машину. Или приложите минимальные усилия, необходимые для устранения реальной / предполагаемой проблемы, и чертовски автоматизируйте подготовку и управление конфигурацией с помощью вашего любимого набора инструментов. Перефразируя Дейкстру, простота и повторяемость являются предпосылками надежности.