Comments 14
Прочитав статью сразу вопрос - актив директори+груповые политики для автоматической установки нужного ПО штатными средствами винды в корпоративной среде не рассматривали? Зачем городить скрипты и сторонние инструменты если майкрософт очень как давно все для этого сделала?
Отличный вопрос! Вы абсолютно правы — GPO + AD действительно базовое решение, и мы начали именно с него. Но в реальных условиях столкнулись с ограничениями: когда нужно не просто установить ПО, а поддерживать актуальные версии, оперативно откатывать обновления при конфликтах или гибко настраивать параметры установки для разных отделов, Chocolatey оказался незаменим.
Мы не отказывались от GPO полностью, он все еще используется для задач вроде установки браузеров/ридеров и прочего ПО, где не требуется строгий контроль версий и тягомотная установка (как в той же 1С).
Для нас, для меня лично, Chocolatey закрыл те сценарии, где штатных средств недостаточно или они требуют слишком много ручной работы. Как и было сказано в конце статьи, я обязательно рассмотрю Nexus для контроля версий, для доработки нынешней системы, так как на практике это оказалось в разы удобнее для большого количества машин.
Если у Вас есть подобный опыт, но он был реализован через GPO - буду рад, если Вы поделитесь!
Я, конечно, не знаю: как у вас в организации оно реально устроено; но в примере из статьи фичи Chocolatey не то что не используются, а скорее даже сломаны.
Каждое приложение стоило бы собрать в отдельный пакет с реальной версией этого ПО. А buh-software сделать метапакетом - который сам по себе ничего не содержит, кроме списка зависимостей от других пакетов.
Вместе с choco ставятся модули powershell где реализована и установка из msi, и создание ярлыков с дополнительной "магией" для, например, автоматического удаления этих ярлыков при удалении пакета. Вы же и штатную автоматизацию не использовали, и явно обновление и удаление не заскриптовали.
Не очень понятно: что вы хотите получить от Nexus? - в файловом nuget-репозитории точно так же рядом прекрасно сосуществуют разные версии одного пакета.
Спасибо за комментарий! Вы абсолютно правы в своей критике. Полностью признаю, мой подход в статье далёк от идеала и не использует все возможности Chocolatey.
Каждое приложение стоило бы собрать в отдельный пакет с реальной версией этого ПО
Действительно, каждое приложение должно быть отдельным пакетом с версионированием, в статье данный момент действительно упущен.
Вместе с choco ставятся модули powershell где реализована и установка из msi, и создание ярлыков с дополнительной "магией"
Полностью согласен, в статье подобное не реализовано. Постараюсь углубиться в тему и внести правки.
Не очень понятно: что вы хотите получить от Nexus?
Это один из вариантов реализации моего решения не с сетевой папки. Как и было сказано в начале, мой способ не подходит для массовой работы с пакетами из-за низкой скорости.
Моё решение помогло справиться с задачей, но в силу первого опыта работы с Chocolatey и сжатых сроков - действительно вышло не самым "правильным".
Большое спасибо Вам за подробный разбор и правильную критику! Если вы можете подсказать какие-то аналоги Nexus (мне нужен именно отдельный сервер) - буду крайне признателен за помощь!
Пакеты chocolatey крохотные — там же только скрипт установки и xml с метаданными. Уверен, что скорость низкая из-за файловай шары на которой лежат непосредственно дистрибутивы. Т.е. скорее всего всё упирается в производительность сети.
Тут можно пойти разными путями:
Закидать проблему ресурсами: проапгрейдить файловый сервер/сеть или поднять ещё несколько таких же, распределив по ним нагрузку.
Оптимизировать особо тормозные дистрибутивы — в некоторых случаях скопировать дистрибутив и установить с локального (RAM)диска получается в разы быстрее, чем запускать установку напрямую из сетевой шары.
Попробовать p2p технологии: штатный виндовый BranchCashe умеет прозрачно тянуть данные не с центрального сервера, а в том числе и с таких же соседних клиентов. Нужно поднастроить и сервер, и клиенты, и порты открыть, но дальше оно само прозрачно заработает без правки скриптов/пакетов. Либо попробовать изобрести велосипед и в скрипте инсталляции качать дистрибутивы каким-нибудь пиринговым клиентом.
Спасибо за интересные мысли, обязательно приму к сведению!
Закидать проблему ресурсами: проапгрейдить файловый сервер/сеть или поднять ещё несколько таких же, распределив по ним нагрузку.
Полностью согласен - это было бы идеальным решением. Апгрейд присутствует в планах закупок. Сейчас направляем бюджеты на более критичные системы, которые почему-то никто не трогал много лет.
Оптимизировать особо тормозные дистрибутивы
Пока спасает развёртывание по отделам. Благо, парк в 100 машин закупается не каждую неделю, есть время до конца года перевести дух, продумать более грамотную систему заливки. Ваш совет обязательно приму к сведению, есть пара тормознутых.
Попробовать p2p технологии: штатный виндовый BranchCashe умеет прозрачно тянуть данные не с центрального сервера, а в том числе и с таких же соседних клиентов.
Очень заинтересовал ваш совет, обязательно углублюсь в теорию, попробую потестировать, как нагрузка чуть отойдет.
А заливали вы новые компы через что? Кмк тут ccm подошёл бы идеально.
виндозавры наконец открыли для себя менеджер пакетов
да давно уже
тут скорее вопрос - почему choco вместо нативного winget, у которого к тому же есть DSC
Это применимо в случае с win11? Потому ято там не добраться до рабочего стола без учётки майкрософт
Chocolatey + PowerShell: как развернуть софт на 100 ПК за час