Назад | Перейти на главную страницу

Linux - поддержка версии пакета на нескольких серверах

Проблема: Если я сегодня разверну server1, все установленные пакеты будут основаны на текущих исходных версиях. Если я завтра открою server2, все установленные пакеты будут основаны на исходных версиях, кроме этого времени, в пределах 24-часовой разницы между server1 и server2, исходные версии некоторых пакетов могут измениться. Таким образом, мы получаем рассинхронизацию серверов server1 и server2 относительно установленных версий пакетов.

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

Пример. server1 заблокирован сегодня. В рамках процесса привязки я запускаю следующие команды:

yum update --downloadonly --downloaddir=/path/to/my/repo/base/v1

yum update --enablerepo=mybaserepo

Что это сделает, так это сбросит все обороты в минуту на основе текущих исходных версий (снимок). Это позволяет мне размещать пакеты RPM из «mybaserepo», поэтому, когда я обновляю другие серверы, они могут получать пакеты RPM непосредственно из моего репо, не беспокоясь о том, что исходящие пакеты пакетов больше не доступны.

Я думал о внедрении ежемесячного цикла обновления, поэтому версия 1 была сделана 5.1.2013, а теперь это 6.1.13. Я думал о цикле процесса вот что:

И этот цикл повторяется ежемесячно. На мой взгляд, эта стратегия решает две проблемы:

  1. Постоянно обновляемые серверы, чтобы гарантировать, что апстрим-патчи устанавливаются постоянно
  2. Не распространять новые версии пакетов без первого тестирования (в течение 30 дней) на сервере моментальных снимков

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

  1. Создайте собственное репо (rsync - официальное зеркало centos)
  2. Обновляйте репо только тогда, когда вы хотите получать новые обновления для всех своих серверов.
  3. Направляйте свои серверы только на локальное репо.

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

Ответ yoonix - хороший способ инвестировать в проактивные обновления, которые, как мы все знаем, это то, что мы должен делать. Но также хорошо знать, как фактически являются. :) Одна вещь, которую я мог бы порекомендовать, - это задание cron, которое будет делать что-то вроде этого наброска кода (не проверено):

#!/bin/bash

email="monitoring@example.com"
sshuser="monitoringuser"
servers=$(cat my-servers.txt)
when=$(date '+%Y%m%d-%H%M%S')

for server in servers; do 
    ssh $sshuser@$server 'rpm -qa |sort' > server-$server-rpmqa-$when.txt
done

diffreport=diff-rpmqa-$when.txt

diff -u server-*-rpmqa-$when.txt > $diffreport

mail -a $diffreport -s "Package diff report for $when" $email

Вы можете увидеть, как было бы полезно запускать 'rpm -Va' периодически (может быть, раз в неделю?) И рассылать его, чтобы проверить трояны, дрейф конфигурации и т. Д.

Конечно, такие сценарии будут создавать «отчеты», которые действительно могут прочитать только высокотехнологичные люди, так что вы можете рассмотреть возможность использования вместо этого инструмента. Как вы уже, наверное, ожидаете, моя компания, Программное обеспечение Metafor, делает именно такой инструмент! :)