Не помешало бы уточнить две вещи:
– какая ОС будет на серверах;
– требуется ли единоразовая однотипная настройка, или и дальнейшее поддержание идентичности (постоянное / периодическое).
По акронису посоветую только документацию почитать.
В свете добавленных пояснений можно для первичной раскатки можно посмотреть ghost4unix прост как ситцевые трусы.
Кстати, если хостер даёт что-то наподобие heztner'овского resque-шелла, то можно куда-нибудь положить пожатый bzip-ом образ диска (перед установкой лучше всё забить нулями, чтобы лучше ужало), потом примонтироваться через nfs или sshfs, после чего этот образ спокойно залить на жёсткий диск. Получится байт к байту, дёшево и сердито.
Ну или просто файлуху в tar.gz закатать, развернуть на сервере и сделать grub-intall из chroot-а, если переносим линух.
Думал о варианте с архивированием и переносом данных. С первого взгляда кажется весьма резонным и простым.
Однако как себя поведет система, если я буду переписывать критические файлы, скажем, для ядра?
Однако как себя поведет система, если я буду переписывать критические файлы, скажем, для ядра?
А не надо их переписывать. Бутнулись, перемонтировали корень в ro, начали заливать образ на диск. Главное прибить все лишние процессы, которым нужны какие-то данные. По-хорошему это должно делаться в single mode, либо с LiveCD/Аварийного шелла.
Значит отдельный раздел boot и отдельный раздел с минисистемой (аналог rescue). Правим в бут вариант загрузки по умолчанию, ребутимся в минисистему, разворачиваем обновления для основной. Так максимально безопасно.
О сетевой загрузке не думали, кстати?
Вот ещё вариант: ставим голую систему, раскурочиваем initrd, туда заливаем скрипт, который форматит раздел, выкачивает образ и заливает его туда же, после чего монтирует корнем и продолжает загрузку, как ни в чём не бывало. Собираем initrd обратно, кладём в /boot рядом с ядром, правим настройки груба. После каждого ребута получаем новенькую систему в самой актуальной версии.
в пакетах собирается софт mysql/nginx/php etc
что касается конфигов, то тут подход следующий:
есть некий стандартный крнфиг — для всех серверов
есть включаемые конфиги для каждого сервера индивидуально
конфигуратор, который генерит необходимый конфиг индивидуально для каждого сервера в соответствии с его ролью
у нас сл роли серверов: (БД, WEB, Script, Memcache, Storage)
конфиги генерятся на основании шаблонов
в общем все сложно. объяснить на пальцах не так просто,
за то при развертывании нового сервера делается два-три действия,
— устанавливается ось дистанционно
— заливаются и устанавливаются паккаджи
— заливаются скрипты и запускается конфигуратор.
и все дело в шляпе — сервер в бою!!!
не такой уж он великий как кажется,
во первых — пакет не один ну и обновления не так часто.
настроил проект и все как часы… без сбоев.
нет особого смысла каждую пятницу перелазить на новый билд РНР или мускуля.
смысл пакетов — быстро клонировать софт, добавить новый сервер в систему минимальными действиями.
если в проекте до десятка серверов, то возможна такая схема излишне, но если их число приближается к сотне,
то сами подумайте сколько времени нужно будет на установку нужного софта из портов+ наложить спец патчи, + развернуть нестандартные экстеншены + что-то еще пересобрать…
Простой
