Обновления системы для многих серверов

У нас много серверов, и мы все еще хотим обновить их все. На самом деле любой из системных администраторов переходит с сервера на сервер и делает aptitude update && aptitude upgrade- это все равно не круто.

Сейчас я ищу решение, которое все еще лучше и очень умно. Может ли марионетка сделать эту работу? Как ты делаешь это?

Вы можете использовать execтип, такой как:

exec { "upgrade_packages":
    command => "apt-get upgrade -q=2",
    path    => "/usr/local/bin/:/bin/:/usr/bin/",
    # path  => [ "/usr/local/bin/", "/bin/" ],  # alternative syntax
}

Если честно, я не пробовал сам, но я думаю, что вам просто нужно создать новый модуль, который включает такое определение exec.

Команда apt-get upgradeявляется интерактивной. Чтобы он работал тихо, вы можете добавить опцию, -q=2как показано выше.

если все ваши хосты - debian, вы можете попробовать пакет unattended-upgrades.

http://packages.debian.org/sid/unattended-upgrades

Здесь мы использовали puppet для управления нашими виртуальными машинами Debian, с помощью puppet мы можем включать и управлять конфигурациями unnate round-upgrade на всех серверах.

В последнее время наша команда тестирует mcollective tool для запуска команд на всех серверах, но для использования mcollective ruby ​​необходимы навыки.

[с] Гуто

Я бы порекомендовал пойти на Puppet, facter и mCollective.

mCollective - это очень хороший фреймворк, в котором вы можете запускать команды на нескольких хостах (в параллелях), используя facter в качестве фильтра.

Добавьте к этому локальный прокси / кеш, и вы будете хорошо настроены для управления серверами.

Используйте инструмент, предназначенный для запуска одной команды на нескольких серверах. И под этим я не подразумеваю наличие терминалов kazillion, открытых с помощью Terminator или ClusterSSH, но вместо этого наличие одного терминала для сервера управления, на котором запущен инструмент, подходящий для данной работы.

Я бы порекомендовал func, Salt или mCollective в этом контексте. Если у вас уже есть Puppet, выберите mCollective (он прекрасно интегрируется в Puppet). Если вы этого не сделаете, и у вас есть старый Python на ваших машинах, вам может понравиться func. Если у вас Python по-новому, попробуйте Salt. Все эти инструменты запускают команду, указанную в командной строке, асинхронно, что намного веселее, чем последовательный цикл ssh или даже выполнение одних и тех же команд aptitude в многочисленных окнах Terminator для множества серверов.

Вы определенно полюбите соль .

Поэтому я думаю, что есть много вещей, которые способствуют хорошему решению:

• Пропускная способность
• Простота администрирования
• Подробная регистрация на случай, если что-то испортится.

Пропускная способность : в основном мне приходят на ум две альтернативы для экономии пропускной способности:

• Настройка зеркала Debian и настройка всех ваших клиентов для использования этого зеркала, см. Http://www.debian.org/mirror/ для получения дополнительной информации. (Я бы порекомендовал это)
• Настройка прокси (apt-cacher, apt-proxy или Squid) и увеличение кеша, чтобы все ваши клиенты могли получить прибыль от этого кеша

Администрирование : я настроил бы параллельную оболочку, такую ​​как PDSH , PSSH , GNU Parallel и выполнил команду на всех клиентах, если бы я тестировал команду ранее на примере компьютера. Тогда не очень вероятно, что он может потерпеть неудачу на всех остальных. В качестве альтернативы вы можете рассмотреть работу cron на всех клиентах, но тогда она может произойти автоматически, поэтому я бы предпочел первое решение.

Если вы беспокоитесь об одновременности обновлений, вы можете запланировать свои команды с at

Ведение журнала : Как и в случае параллельных оболочек, у вас есть возможность перенаправить вывод, я бы скомбинировал stderr и stdout и записал его в файл журнала.

Мой собственный параллельный ssh-упаковщик: classh - альтернатива различным Parallel и кластерным ssh-инструментам.

Вам может понравиться это лучше или вы можете ненавидеть это. Есть только три причины, по которым я упоминаю это здесь:

• Его очень просто установить и использовать: один файл .py без внешних зависимостей, кроме стандартных библиотек Python 2.5.
• Это чрезвычайно надежно в своих пределах. Я использую его каждый рабочий день, часто почти 100 раз в день и обычно на сборах от сотен до нескольких тысяч целей на команду. (Я тестировал его в целевых списках более чем 25 тысяч серверов одновременно). Он никогда не сбегал, не завершался и не давал мне неопределенного поведения. (Единственные ограничения, относящиеся к ограничениям subprocess.communicate()метода Python - таким образом, вы можете получить захват только около 64 КБ стандартного вывода и, например, отдельно до 64 КБ stderr; также любой удаленный процесс, который пытается прочитать с его стандартного ввода, просто остановится пока локальный подпроцесс ssh не будет уничтожен, автоматически обработкой таймаута classh )

• Очень просто написать собственный скрипт на Python, чтобы использовать classh.py в качестве модуля. Так что очень легко написать что-то вроде:

  
      !#/bin/env python
      import classh
      job = classh.SSHJobMan(cmd, targets)
      job.start()
      while not job.done():
          completed = job.poll()
          for i in completed:
              # do something with the classh.JobRecord object referenced by i
      # done
  
  
  # You can optionally do post-processing on the dictionary of JobRecords here
  #  keyed off the target strings (hostnames)    
  </code></pre>
  

Это все, что нужно сделать. Например, во вложенном цикле завершения вы можете собрать список всех тех, кто возвратил определенное состояние выхода или выполнить поиск определенных сообщений об ошибках, и настроить последующие задания для их обработки. (Задания будут выполняться одновременно, по умолчанию 100 заданий в любое время, пока каждое из них не будет завершено; поэтому простая команда на нескольких сотнях хостов обычно выполняется за несколько секунд и очень сложный сценарий оболочки в одной длинной командной строке. скажем, пятьдесят строк или около того ... может выполнить более нескольких тысяч хостов за 10 минут ... около 10 тыс. хостов в час в моей среде, причем многие из них расположены межконтинентально).

Так что это может быть чем-то, что вы можете использовать как специальную меру, пока у вас не будет реализована конфигурация марионеток и проведено хорошее тестирование ... и она также пригодится для проведения небольших специальных опросов ваших хостов, чтобы увидеть, какие из них отклоняются от ваших стандартов в различные маленькие способы.

Ответ с использованием exec довольно полезен.

Однако, согласно руководству apt-get, не рекомендуется использовать -q = 2 таким образом (хотя я использовал его годами без проблем)

-q, --quiet
       Quiet; produces output suitable for logging, omitting progress indicators. More q's will produce more quiet up to a maximum of 2. You can also use -q=# to set the
       quiet level, overriding the configuration file. Note that quiet level 2 implies -y, you should never use -qq without a no-action modifier such as -d, --print-uris or
       -s as APT may decided to do something you did not expect. Configuration Item: quiet.

Я годами использовал скрипт самостоятельно, запустив apt-get следующим образом:

ssh example.org "apt-get update && apt-get -y upgrade && apt-get -y dist-upgrade && apt-get clean"

Такие вещи, как кукольный и другие инструменты, о которых упоминали люди, наверняка могут сработать, но кажется, что это излишне, потому что просто имитирует несколько команд, набранных человеком. Я верю в использование простейшего инструмента для конкретной работы, в этом случае bash-скрипт настолько же прост, насколько это возможно без потери функциональности.

В течение многих лет я успешно обновлял и устанавливал пакеты, используя apt-dater . Это легкий и эффективный инструмент для удаленного управления пакетами. Он использует screen, sudoи ssh.
Для управления пакетами apt-dater может быть более простым решением, чем инструменты управления конфигурацией.
apt-dater удобен для централизованного управления пакетами в различных вариантах GNU / Linux, таких как Debian и CentOS.

Вы можете использовать ткань . Fabric - это библиотека Python (2.5-2.7) и инструмент командной строки для оптимизации использования SSH для развертывания приложений или задач системного администрирования.

используйте webmin ,,, и используйте его функцию кластера webmin, в которой вы можете добавить все системы в одну консоль webmin и выполнить любую команду или управлять всеми из них из одного места.

Или

Используйте кластер SSH

Или

PSSH

Другое решение, если на всех ваших хостах запущен Debian (или его производные), это использовать пакет cron-apt . Но, как указано в документации, необходимо соблюдать осторожность.

В настоящее время я использую cron-apt на дюжине серверов для автоматического и автоматического обновления всех обновлений безопасности. Чтобы избежать нежелательных обновлений, я использую cron-apt только на серверах, на которых работает стабильный дистрибутив Debian, и я конфигурирую свои источники apt, поэтому использую имя дистрибутива wheezy , а не его псевдоним (стабильный).

Конкретная конфигурация cron-apt, которую я использую, сведена в один файл действий: /etc/cron-apt/action.d/5-install

dist-upgrade -y -o APT::Get::Show-Upgraded=true -o Dir::Etc::SourceList=/etc/apt/sources.list.d/security.list -o Dir::Etc::SourceParts="/dev/null"

Любое другое обновление выполняется вручную, с использованием экрана или чего-либо более подходящего, так как это может потребовать ручного вмешательства во время обновления.