Поскольку я продолжаю загружать обновленные версии своих кулинарных книг на сервер шеф-повара, мне приходится задаться вопросом, есть ли ограничение на количество версий, которые может хранить поварский сервер поваренных книг.
Это то, о чем я должен вообще беспокоиться, или это не проблема? Очевидно, что меня здесь не беспокоит дисковое пространство.
Я не думаю, что на этот вопрос будет хороший ответ. Я бы сказал, что вы не хотите строить свой рабочий процесс вокруг этой проблемы и определенно не хотите удалять кулинарные книги при каждой загрузке.
Периодическая сборка мусора (один или два раза в год), вероятно, является хорошей идеей, но она будет сильно зависеть от того, как вы структурируете свои кулинарные книги и их зависимости, а также от того, насколько вы `` напрягаете '' решатель депо (gecode или molinillo), который вы с использованием.
Если вы не видите медленное решение деплоя, то в этом нет необходимости. Если вы видите медленное решение деплоя, вам следует серьезно подумать об этом.
Если у вас большой сайт с десятками людей, которые вносят свой вклад в сотни кулинарных книг, и вы не собираете мусор старые, устаревшие версии кулинарных книг в течение многих лет, а некоторые из ваших популярных кулинарных книг имеют сотни или тысячи версий, хранящихся на сервере ... Наверное, полезно будет об этом подумать.
Если вы просто собираетесь, и это в основном ваша команда и несколько десятков кулинарных книг, и у вас есть максимум несколько десятков версий, то это вряд ли станет проблемой.
Если вы где-то посередине ... может быть?
ДОБАВЛЕНО (8 октября 2016 г.): Еще одна проблема, которую следует учитывать, заключается в том, что при большом количестве версий кулинарных книг иногда депсолвер становится «слишком умным», выбирая очень старые версии кулинарных книг, о которых вы забыли, но которые позволяют ему удовлетворять все его ограничения. Я только недавно столкнулся с этим с двумя кулинарными книгами, у которых были конфликтующие ограничения (dovecot хотел ohai ~> 3.0, а chef_nginx хотел ohai ~> 4.0), чтобы решить эту проблему, depsolver услужливо понизил мою кулинарную книгу-оболочку до версии, которая была настолько старой, что я использовал uw-imapd вместо dovecot , который снял ограничение ohai с dovecot и порадовал депсолвер, в то же время меня очень огорчило, потому что Ubuntu уже много лет даже не поставляет uw-imapd. Один из способов справиться с этим - более четко ограничивать кулинарные книги последними версиями с помощью контактов. Вы также можете просто выгрузить эти неиспользуемые версии со своего chef-сервера, чтобы они не были доступны для депсолтинга.
Менее технический ответ можно получить, если взглянуть на ваш вопрос с «точки зрения принципа единой ответственности».
Я имею в виду: в любой хорошей системе каждый компонент должен четко нести ответственность.
Теперь вы можете спросить себя: обязан ли ваш шеф-сервер действовать как инструмент управления исходным кодом?
Я имею в виду: есть такие инструменты, как git, SVN, ... вы называете их, которые существуют исключительно для того, чтобы разрешить управление версией текстовых файлов.
Вы хотите, чтобы ваш шеф-повар тоже делал это? или было бы лучше сделать управление версиями ваших «текстовых файлов конфигурации», используя другую инфраструктуру ?!
Так что это зависит от вашего рабочего процесса. В экосистеме Chef используются два решателя ограничений версий: Chef Server всегда использует gecode (также известный как depsolver), файлы политик всегда используют molinillo, а Berkshelf может использовать любой из них в зависимости от конфигурации. Gecode может начать задыхаться, когда вы попадете в несколько тысяч общих версий, плавающих вокруг, но это сильно зависит от того, насколько вы хорошо разбираетесь в хорошо сформированных ограничениях версий зависимостей. Molinillo намного лучше в этом отношении, но это означает либо использование berks apply для блокировки всех ваших сред, либо использование файлов политик (т.е. не позволяйте Chef Server пытаться запустить решение по ограничению для всей вселенной).
