У меня есть веб-инфраструктура на основе Linux, которая состоит из 15 виртуальных машин и более 50 различных сервисов. Он полностью контролируется шеф-поваром. Большинство сервисов разрабатываются внутри компании.
Обычно текущий процесс развертывания запускается сценарием оболочки. Система сборки (смесь Python и сценариев оболочки) упаковывает службы как .deb файлы и помещает эти пакеты в репо. Это работает apt-get update на всех 15 узлах, потому что стандартный Chef apt только поваренная книга работает apt-get один раз в день и мы точно не хотим бегать apt-get update безусловно по каждому chef-client проснуться. Система сборки перезагружается chef-client наконец, демоны на всех 15 узлах (нам нужен этот шаг из-за природы pull Chef).
Текущий процесс имеет ряд недостатков, которые мы хотим устранить. Во-первых, это асинхронно, потому что сценарий развертывания не проверяет chef-client журналы после перезапуска, поэтому мы даже не знаем, было ли развертывание успешным. Он даже не ждет, пока клиенты Chef завершат цикл. Во-вторых, мы определенно не хотим заставлять chef-client перезапускается на всех узлах, потому что обычно мы развертываем только небольшое количество пакетов. И в-третьих, я не совсем уверен, что использую chef-client поскольку развертывание является законным, возможно, мы просто делаем это неправильно с самого начала. Пожалуйста, поделитесь своими мыслями / опытом.
Что касается отчетов об успехах / неудачах, вам нужно Повар который сообщает об успехе / неудаче в некую центральную точку агрегирования.
Я не думаю, что вам нужно перезапускать клиент - должно быть достаточно «chef-client --once». Кроме того, на вашем месте я создам пакет данных, в котором пакеты, которые необходимо развернуть, отмечены и основаны на запусках apt-get на данных этого пакета.