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

У нас є багато серверів і все ще хочемо їх оновити. Дійсний спосіб полягає в тому, що будь-який із системних адміністраторів переходить від сервера до сервера і робить 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, ви можете спробувати пакет без нагляду.

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

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

Останнім часом наша команда тестує інструмент mcollective для запуску команд на всіх серверах, але для використання навичок mcollective ruby ​​потрібно.

[s] Гуто

Я б порекомендував поїхати на лялечку, фактор та mCollective.

mCollective - це дуже приємна рамка, де можна виконувати команди над низкою хостів (паралельно), використовуючи facter як фільтр.

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

Використовуйте інструмент, який створений для запуску однієї команди на декількох серверах. І під цим я не маю на увазі відкриття терміналів kazillion, відкритих разом з Terminator або ClusterSSH, а натомість мати єдиний термінал на сервері управління, на якому працює інструмент, придатний для роботи.

Я б рекомендував функцію, сіль та mCollective у цьому контексті. Якщо у вас вже є лялька, перейдіть на mCollective (він чудово інтегрується в лялечку). Якщо у вас немає, а у вас на старих машинах старий Python, ви можете насолоджуватися функцією. Якщо ви Python у новому, спробуйте Salt. Усі ці інструменти виконують асинхронно команду, вказану в командному рядку, що набагато веселіше, ніж послідовний цикл ssh або навіть виконання тих самих команд на придатність у незрозумілих вікнах Термінатора на незмінних серверах.

Ви обов'язково полюбите Сіль .

Тож я думаю, що є багато речей, які сприяють гарному вирішенню:

• Пропускна здатність
• Простота введення
• Детальний журнал у випадку, якщо щось викручується.

Пропускна здатність : В основному, у мене на увазі дві альтернативи для збереження пропускної здатності:

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

Адміністрація : Я хотів би налаштувати паралельну оболонку як PDSH , PSSH , GNU Parallel і видає команду на всіх клієнтів, якщо я тестував команду раніше на прикладі машини. Тоді не дуже ймовірно, що це може вийти з ладу на всіх інших. Крім того, ви можете розглянути питання про роботу cron для всіх клієнтів, але тоді воно може вийти з ладу автоматично, тому я вважаю за краще перше рішення.

Якщо ви турбуєтесь про одночасність оновлень, ви можете запланувати свої команди at

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

Моя власна паралельна обгортка ssh: classh - це альтернатива різним інструментам паралельних і кластерних ssh.

Вам це може подобатися краще, або ви можете його ненавидіти. Тут я згадую лише три причини:

• Вкрай просто встановити та використовувати: один .py-файл без зовнішніх залежностей, ніж стандартні бібліотеки Python 2.5.
• Це надзвичайно надійно в своїх межах. Я використовую його кожен робочий день, часто майже 100 разів на день і зазвичай на колекції від сотень до кількох тисяч цілей на команду. (Я перевіряв його на цільових списках із понад 25 тис. Серверів одночасно). Він ніколи не пробігав, не міг завершити або не дав мені жодної невизначеної поведінки. (Єдині обмеження, пов'язані з subprocess.communicate()методом Python --- тому ви можете отримати лише 64K stdout і, наприклад, до 64K stderr; також будь-який віддалений процес, який намагається прочитати зі свого stdin, просто зупиниться доти, поки локальний ssh-підрозділ не буде вбитий, автоматично за допомогою тайм- аута обробки класу

• Написати спеціальний сценарій в 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.

можна використовувати Тканину . Тканина - це бібліотека і інструмент командного рядка Python (2.5-2.7) для впорядкування використання SSH для розгортання додатків або системного адміністрування.

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

Або

Використовуйте кластер ssh

Або

ПСШ

Ще одне рішення, якщо всі ваші хости працюють під керуванням 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"

Будь-яке інше оновлення проводиться вручну, використовуючи екран або все, що є найбільш підходящим, оскільки це може потребувати вручну втручання під час оновлення.