Это не немой вопрос вообще. это - на самом деле хороший вопрос.
Моя информация может устареть, но в более ранних версиях домашних Операционных систем (Win98 - WinXP) версия IIS (или Персональный веб-сервер на более старой ОС), который поставлется с операционной системой, ограничена меньшим количеством соединений (10 последнее, которое я знал), так, чтобы один правила, размещая веб-сайт, который, как ожидают, получит больше чем 10 пользователей за один раз в несерверной операционной системе.
Проверьте этот FAQ:
http://www.iisanswers.com/IISFAQ.htm
Однако в маленькой среде рабочей группы, размещая Ваш веб-сайт по клиентской операционной системе по сравнению с серверной операционной системой возможность.
*Редактирование - Добавленный *
Я не уверен, что Ваши планы - являетесь ли Вы планированием хостинга сайта к внешнему миру, внутренний веб-сайт компании (Интранет) или небольшой веб-сайт рабочей группы.
На основе основного характера этого вопроса (даже при том, что это - хороший вопрос), если бы Вы надеетесь размещать общедоступный сайт, я сильно поощрил бы Вас идти с хостинговой компанией. Одни только стычки безопасности из установки и поддержания Вашего собственного сервиса являются чем-то, что требует, чтобы много экспертных знаний сделало правильно. Я делал веб-программирование с тех пор приблизительно 1997, и я не предпринял бы его сам. Это - совершенно другой набор навыков для поддержания безопасной среды.
И Марионетка и Шеф-повар могут сделать то, что Вы хотите очень хорошо. Ваше лучшее будет, чтобы начать делать то, что Вы пытаетесь сделать и решить, которые оснащают Вас как лучшее. Я думаю большие вопросы, которые Вам, должно быть, придется задать:
Вы хотите DSL? - Рецепты шеф-повара записаны в рубине, у марионетки есть DSL. Хорош ли DSL, или плохим выбором является одно из самых больших различий между шеф-поваром и марионеткой. Ссылка, которую Вы отправили на сравнение консалтинга битового поля, имеет некоторые хорошие комментарии об этом, необходимо читать, если Вы уже не имеете. Я также нашел это сообщение в блоге полезным, удостоверьтесь, что Вы читаете комментарии также.
Вы знаете рубин? - Если Вы не знаете, рубин, начинающий с шеф-поваром, может быть более твердым или потребовать больших инвестиций времени, так как необходимо выучить новый язык. У марионетки есть его собственный язык, который легок начать с. При запуске с марионеточных 2.6 декларации могут быть записаны в рубине также.
В Мосту С открытым исходным кодом в 2009, у них была панель авторов и представителей шеф-повара, марионетки, bcfg2, cfengine, и automateit, который можно наблюдать на bliptv, который имеет 1,75 часа дискуссии об утилитах управления конфигурацией.
Opscode/Chef говорит о различии между ним и марионеткой в их FAQ также.
Я думаю Ваш не знание, что правильные вопросы спросить могли бы произойти от Вас не имеющий слишком много опыта, работающего ни с одним из них, после того как Вы начинаете использовать их, Вы начнете видеть различия между ними. Я предложил бы идти с некоторыми реальными проблемами, которые Вы решите с шеф-поваром или марионеткой, затем начать пытаться решить их и видеть то, что Вы любите/не любите о них. С Opscode/Chef они предлагают размещенное решение, что можно настроить 5 узлов бесплатно для начала работы.
Полное раскрытие, мы не используем ни один из них, хотя мы оценили их внутренне при попытке выбрать систему управления конфигурацией. Не считайте меня экспертом по какой любой из них, в конце концов.
И так далее. Но можно ответить на эти вопросы очень легко сами: настройте их! Подъем образца и выполнения является несколькими часами Вашего времени для каждого продукта, и полагая, что независимо от того, что Вы используете, это для будет, вероятно, использоваться в течение долгого времени, время определенно стоит того. Мало того, что можно получить ощущение того, как они обрабатывают платформу определенные вещи (т.е. Debian, базирующийся и склонный, базирующийся об/мин и конфетка), но это определенно поможет Вам получить ощущение приложений.
Следует иметь в виду также, что все функции в мире не восполнят трудный интерфейс, плюс, он может выставить проблемы, которые характерны для Вашей инфраструктуры - т.е. что происходит, если файлы конфигурации обновляются в другом порядке, чем ожидалось?
Таким образом, это - мой совет; Шеф-повар и Марионетка не все, что трудный получить один сервер и один или два клиента устанавливает и даст Вам собственный опыт на обоих. Плюс, если Вы начинаете настраивать его и понимаете, что это - огромная боль, у Вас уже будет знание перед согласием на него.
Вышеупомянутое является определенно хорошей инструкцией, мне также нравится задавать эти общие вопросы каждый раз, когда я рассматриваю новую стороннюю зависимость.
Они - хорошие индикаторы полного успеха проекта и могут несколько предсказать продолжительность жизни.
Если существуют люди на Вашем проекте, у которых уже есть опыт с Марионеткой, то я предлагаю, чтобы Вы просто использовали Марионетку.
Шеф-повар и Марионетка довольно подобны, и оба проекта одинаково высококачественны. Если у Вас есть доступ к людям, у которых уже есть Марионеточный опыт, просто используйте Марионетку.
Попытайтесь найти людей, которые использовали или Шеф-повара или Марионетку больше нескольких месяцев и спрашивают их об их событиях.
Позвольте мне сначала сказать - если вы не используете Puppet или Chef; нет неправильного ответа. Любой из них будет намного лучше, чем то, что вы делаете сейчас.
Как руководитель, я сделал выбор в пользу Puppet для своей команды. Если бы я был командой только из себя, я бы выбрал Chef. И вот почему:
Я, безусловно, специализируюсь на системном администрировании, но в программировании. Это то, ради чего я ходил в школу, и я не привыкать писать полные приложения (а не только скрипты). Хотя я не знал Ruby, я хотел бы знать, и Chef был бы отличным предлогом, чтобы изучить оба.
Однако в моей команде полно системных администраторов, практически не имеющих опыта программирования, за исключением случайных сценариев оболочки. . Для них создание марионеточного модуля во многом похоже на написание файла конфигурации. Это' декларативен, нет итераторов, и в целом он более удобен для администратора.
Команды, в которых полно разработчиков, выполняющих действия системного администратора, обычно предпочитают Chef. Поскольку DSL Puppet является декларативным, порядок (даже внутри отдельных файлов) не имеет значения, и это расстраивает многих, привыкших к более типичному языку программирования.
Я также слышал много раз, что Chef гораздо более дружественен к облаку. чем Puppet, но в прошлом году Puppet сделала акцент на этом в своем продукте Puppet Enterprise. Я не могу судить по опыту использования облачных возможностей любого из продуктов.
Из-за этих качеств сложился стереотип (и часто он верен), что Puppet будет более распространенным на предприятии на физических машинах, где Chef управляет стартапами в облаке. Конечно, есть исключения, но что я? «Я видел», безусловно, подтверждает этот стереотип.
Если это команда из одного человека, то оцените оба и выберите тот, который вам нравится. Однако, если, как и я, у вас есть команда людей, убедитесь, что вы ставите потребности своей команды в приоритет над любыми личными предпочтениями, это спасет вас позже, когда вы попытаетесь получить поддержку.
Для меня это тесно связано с традициями конкретного сообщества. Исторически Chef был ближе к ребятам из RubyOnRails. Также большая часть популярности Chef в сообществе ROR, потому что Engineyard построила свою инфраструктуру поверх Chef.