ProHoster > блог > адміністраванне > Bare-Metal Provisioning сваімі рукамі, або Аўтаматычная падрыхтоўка сервераў з нуля

Bare-Metal Provisioning сваімі рукамі, або Аўтаматычная падрыхтоўка сервераў з нуля

Прывітанне, я Дзяніс і адно з маіх напрамкаў дзейнасці - распрацоўка інфраструктурных рашэнняў у X5. Сёння жадаў бы падзяліцца з вамі аб тым, як можна на базе агульнадаступных прылад разгарнуць аўтаматычную сістэму падрыхтоўкі сервераў. На мой погляд, гэтае цікавае, простае і гнуткае рашэнне.

Bare-Metal Provisioning сваімі рукамі, або Аўтаматычная падрыхтоўка сервераў з нуля

Пад падрыхтоўкай разумеецца: зрабіць з новага сервера са скрынкі, цалкам наладжаны сервер з а.з. Linux або c гіпервізарам ESXi (разліванне сервераў Windows у дадзеным артыкуле не абмяркоўваецца).

тэрміны:

  • серверы - серверы, якія неабходна наладзіць.
  • інсталл-сервер - асноўны сервер, які забяспечвае ўвесь працэс падрыхтоўкі па сетцы.

Навошта патрэбная аўтаматызацыя?

Дапушчальны, ёсць задача: масава падрыхтоўваць сервера з нуля, у піку - 30 у дзень. Сервера розных вытворцаў і мадэляў, на іх могуць усталёўвацца розныя АС, можа быць ці адсутнічаць гіпервізор.

Якія аперацыі ўваходзяць у працэс наладкі (без аўтаматызацыі):

  • падлучыць клавіятуру, мыш, манітор да сервера;
  • наладзіць BIOS, RAID, IPMI;
  • абнавіць прашыўкі кампанентаў;
  • разгарнуць выяву файлавай сістэмы (або ўсталяваць гіпервізор і скапіяваць віртуальныя машыны);

Заўвага. Як варыянт, дэплой АС магчымы праз усталёўку з файлам аўтаадказаў. Але гэта ня будзе абмяркоўвацца ў артыкуле. Хаця ніжэй вы ўбачыце, што дадаць гэты функцыянал нескладана.

  • наладзіць параметры АС (hostname, IP, іншае).

Пры дадзеным падыходзе выконваюцца аднолькавыя наладкі паслядоўна на кожным серверы. Эфектыўнасць такой працы вельмі нізкая.

Сутнасць аўтаматызацыі - выключыць удзел чалавека з працэсу падрыхтоўкі сервера. Максімальна, наколькі гэта магчыма.

Дзякуючы аўтаматызацыі скарачаецца час прастою паміж аперацыямі і з'яўляецца магчымасць падрыхтаваць некалькі сервераў адначасова. Таксама моцна змяншаецца верагоднасць узнікнення памылак з-за чалавечага фактару.

Bare-Metal Provisioning сваімі рукамі, або Аўтаматычная падрыхтоўка сервераў з нуля

Як адбываецца аўтаматычная настройка сервераў?

Разбяром усе этапы дэталёва.

У вас ёсць linux-сервер, які вы карыстаецеся ў якасці PXE інсталл-сервера. На ім устаноўлены і настроены службы: DHCP, TFTP.

Такім чынам, загружаны сервер (які неабходна наладзіць) па PXE. Успомнім, як гэта працуе:

  • На серверы абрана загрузка па сетцы.
  • Сервер загружае PXE-ROM сеткавай карты і звяртаецца да інсталл-сервера па DHCP для атрымання сеткавага адрасу.
  • DHCP інсталл-сервера выдае адрас, а таксама інструкцыю аб далейшай загрузцы праз PXE.
  • Сервер загружае сеткавы загрузнік з усталёўнік-сервера па PXE, наступная загрузка адбываецца паводле канфігурацыйнага файла PXE.
  • Адбываецца загрузка на аснове атрыманых параметраў (ядро, initramfs, кропкі мантавання, выява squashfs і іншае).

Заўвага. У артыкуле прыводзіцца апісанне загрузкі па PXE праз BIOS mode. У наш час вытворцамі актыўна ўкараняецца UEFI bootmode. Для PXE адрозненне будзе ў канфігурацыі DHCP-сервера і наяўнасці дадатковага загрузніка.

Разгледзім прыклад канфігурацыі PXE-сервера (меню pxelinux).

Файл pxelinux.cfg/default:

default menu.c32
prompt 0
timeout 100
menu title X5 PXE Boot Menu
LABEL InstallServer Menu
	MENU LABEL InstallServer
	KERNEL menu.c32
	APPEND pxelinux.cfg/installserver
LABEL VMware Menu
	MENU LABEL VMware ESXi Install
	KERNEL menu.c32
	APPEND pxelinux.cfg/vmware
LABEL toolkit // меню по умолчанию
	MENU LABEL Linux Scripting Toolkits
	MENU default
	KERNEL menu.c32
	APPEND pxelinux.cfg/toolkit // переход на следующее меню

Файл pxelinux.cfg/toolkit:

prompt 0
timeout 100
menu title X5 PXE Boot Menu
label mainmenu
    menu label ^Return to Main Menu
    kernel menu.c32
    append pxelinux.cfg/default
label x5toolkit-auto // по умолчанию — автоматический режим
        menu label x5 toolkit autoinstall
        menu default
        kernel toolkit/tkcustom-kernel
        append initrd=toolkit/tk-initramfs.gz quiet net.ifnames=0 biosdevname=0 nfs_toolkit_ip=192.168.200.1 nfs_toolkit_path=tftpboot/toolkit nfs_toolkit_script=scripts/mount.sh script_cmd=master-install.sh CMDIS2=”…”
label x5toolkit-shell // для отладки - консоль
        menu label x5 toolkit shell
        kernel toolkit/tkcustom-kernel
        append initrd=toolkit/tkcustom-initramfs.gz quiet net.ifnames=0 biosdevname=0 nfs_toolkit_ip=192.168.200.1 nfs_toolkit_path=tftpboot/toolkit nfs_toolkit_script=scripts/mount.sh script_cmd=/bin/bash CMDIS2=”…”

Ядро і initramfs на дадзеным этапе - гэта прамежкавы linux-выява, з дапамогай якога і будзе адбывацца асноўная падрыхтоўка і налада сервера.

Як вы бачыце, загрузнік перадае шмат параметраў ядру. Частка гэтых параметраў выкарыстоўваецца самім ядром. А некаторыя мы можам выкарыстоўваць для сваіх мэт. Пра гэта будзе расказана далей, а пакуль можна проста запомніць, што ўсе перададзеныя параметры будуць даступныя ў прамежкавым linux-выяве праз /proc/cmdline.

Дзе іх узяць, ядро ​​і initramfs?
За аснову, можна абраць любы linux-дыстрыбутыў. На што зважаем пры выбары:

  • загрузная выява павінна быць універсальным (наяўнасць драйвераў, магчымасці ўсталёўкі дадатковых утыліт);
  • хутчэй за ўсё, запатрабуецца кастамізаваць initramfs.

Як гэта зроблена ў нашым рашэнні для X5? У якасці асновы абраны CentOS 7. Правернем наступны трук: падрыхтуем будучую структуру выявы, спакуем яе ў архіў і створым initramfs, усярэдзіне якога будзе наш архіў файлавай сістэмы. Пры загрузцы выявы архіў будзе разгортвацца ў ствараную частку tmpfs. Такім чынам мы атрымаем мінімальны, пры гэтым паўнавартасны live-выява linux са ўсімі неабходнымі ўтылітамі, які складаецца ўсяго з двух файлаў: vmkernel і initramfs. 

#создаем директории: 

mkdir -p /tftpboot/toolkit/CustomTK/rootfs /tftpboot/toolkit/CustomTK/initramfs/bin

#подготавливаем структуру:

yum groups -y install "Minimal Install" --installroot=/tftpboot/toolkit/CustomTK/rootfs/
yum -y install nfs-utils mariadb ntpdate mtools syslinux mdadm tbb libgomp efibootmgr dosfstools net-tools pciutils openssl make ipmitool OpenIPMI-modalias rng-tools --installroot=/tftpboot/toolkit/CustomTK/rootfs/
yum -y remove biosdevname --installroot=/tftpboot/toolkit/CustomTK/rootfs/

# подготавливаем initramfs:

wget https://busybox.net/downloads/binaries/1.31.0-defconfig-multiarch-musl/busybox-x86_64 -O /tftpboot/toolkit/CustomTK/initramfs/bin/busybox
chmod a+x /tftpboot/toolkit/CustomTK/initramfs/bin/busybox
cp /tftpboot/toolkit/CustomTK/rootfs/boot/vmlinuz-3.10.0-957.el7.x86_64 /tftpboot/toolkit/tkcustom-kernel

# создаем /tftpboot/toolkit/CustomTK/initramfs/init (ниже содержание скрипта):

#!/bin/busybox sh
/bin/busybox --install /bin
mkdir -p /dev /proc /sys /var/run /newroot
mount -t proc proc /proc
mount -o mode=0755 -t devtmpfs devtmpfs /dev
mkdir -p /dev/pts /dev/shm /dev/mapper /dev/vc
mount -t devpts -o gid=5,mode=620 devpts /dev/pts
mount -t sysfs sysfs /sys
mount -t tmpfs -o size=4000m tmpfs /newroot
echo -n "Extracting rootfs... "
xz -d -c -f rootfs.tar.xz | tar -x -f - -C /newroot
echo "done"
mkdir -p /newroot/dev /newroot/proc /newroot/sys
mount --move /sys  /newroot/sys
mount --move /proc /newroot/proc
mount --move /dev  /newroot/dev
exec switch_root /newroot /sbin/init

# упаковываем rootfs и initramfs:

cd /tftpboot/toolkit/CustomTK/rootfs
tar cJf /tftpboot/toolkit/CustomTK/initramfs/rootfs.tar.xz --exclude ./proc --exclude ./sys --exclude ./dev .
cd /tftpboot/toolkit/CustomTK/initramfs
find . -print0 | cpio --null -ov --format=newc | gzip -9 > /tftpboot/toolkit/tkcustom-initramfs-new.gz

Такім чынам, мы ўказалі ядро ​​і initramfs, якія павінны быць загружаны. У выніку на дадзеным этапе, загрузіўшы прамежкавая выява linux па PXE, мы атрымаем кансоль АС.

Выдатна, але зараз трэба перадаць кіраванне нашай "аўтаматызацыі".

Гэта можна зрабіць так.

Выкажам здагадку, пасля загрузкі выявы мы плануем перадаваць кіраванне ў скрыпт mount.sh.
Уключым скрыпт mount.sh у аўтазапуск. Для гэтага запатрабуецца мадыфікаваць initramfs:

  • распакаваць initramfs (калі выкарыстоўваем вышэйпрыведзены варыянт initramfs, гэта не патрабуецца)
  • уключыць у аўтазагрузку код, які будзе аналізаваць перадаваныя параметры праз /proc/cmdline і перадаваць кіраванне далей;
  • запакаваць initramfs.

Заўвага. У выпадку з X5 toolkit кіраванне загрузкі перадаецца ў скрыпт /opt/x5/toolkit/bin/hook.sh с помощью override.conf в getty tty1 (ExecStart=…)

Такім чынам, загружаецца выява, у якім у аўтазапуску стартуе скрыпт mount.sh. Далей скрыпт mount.sh падчас выкананні аналізуе перададзеныя параметры (script_cmd=) і запускае неабходную праграму/скрыпт.

label toolkit-аўтаматычны
kernel …
append … nfs_toolkit_script=scripts/mount.sh script_cmd=master-install.sh

label toolkit-абалонка
kernel …
append … nfs_toolkit_script=scripts/mount.sh script_cmd=/bin/bash

Bare-Metal Provisioning сваімі рукамі, або Аўтаматычная падрыхтоўка сервераў з нуля

Тут у левай частцы - меню PXE, у правай - схема перадачы кіравання.

З перадачай кіравання мы разабраліся. У залежнасці ад выбару PXE-меню запускаецца альбо скрыпт аўтаналадкі, альбо кансоль для адладкі.

У выпадку аўтаматычнай наладкі мантуюцца неабходныя дырэкторыі з інсталл-сервера, у якіх прысутнічаюць:

  • скрыпты;
  • захаваныя шаблоны BIOS/UEFI розных сервераў;
  • прашыўкі;
  • утыліты для сервераў;
  • логі.

Далей скрыпт mount.sh перадае кіраванне скрыпту master-install.sh з дырэкторыі са скрыптамі.

Дрэва скрыптоў (парадак іх запуску) выглядае прыкладна так:

  • master-install
  • sharefunctions (агульныя функцыі)
  • info (вывад інфармацыі)
  • models (усталёўка параметраў усталёўкі на аснове мадэлі сервера)
  • prepare_utils (усталёўка неабходных утыліт)
  • fwupdate (абнаўленне прашывак)
  • diag (элементарная дыягностыка)
  • biosconf (настройка биоса/уефи)
  • clockfix (настройка часу на мат. плаце)
  • srmconf (настройка інтэрфейсу выдаленага інтэрфейсу)
  • raidconf (настройка лагічных тамоў)

адзін з:

  • preinstall (перадача кіравання ўсталёўніку АС ці гіпервізара, напрыклад ESXi)
  • merged-install (непасрэдны старт распакавання выявы)

Цяпер мы ведаем:

  • як загружаць сервер па PXE;
  • як перадаць кіраванне ва ўласны скрыпт.


Працягнем. Сталі актуальнымі наступныя пытанні:

  • Як ідэнтыфікаваць сервер, які мы рыхтуем?
  • Якімі ўтылітамі і як канфігураваць сервер?
  • Як атрымаць наладкі для канкрэтнага сервера?

Як ідэнтыфікаваць сервер, які мы рыхтуем?

Гэта проста - DMI:

dmidecode –s system-product-name
dmidecode –s system-manufacturer
dmidecode –s system-serial-number

Тут ёсць усё, што трэба: вендар, мадэль, серыйны нумар. Калі вы не ўпэўненыя, што гэтая інфармацыя прадстаўлена ва ўсіх серверах, можаце ідэнтыфікаваць іх па MAC-адрасу. Або абодвума спосабамі адначасова, калі вендары сервераў розныя і на некаторых мадэлях інфармацыя аб серыйным нумары проста адсутнічае.

На аснове атрыманай інфармацыі мантуюцца сеткавыя тэчкі з усталёў-сервера і падгружаецца ўсё неабходнае (утыліты, прашыўкі і іншае).

Якімі ўтылітамі і як канфігураваць сервер?

Прывяду ўтыліты для linux для некаторых вытворцаў. Усе ўтыліты даступныя на афіцыйных сайтах вендараў.

Bare-Metal Provisioning сваімі рукамі, або Аўтаматычная падрыхтоўка сервераў з нуля

З прашыўкамі, я думаю, усё зразумела. Звычайна яны пастаўляюцца ў выглядзе спакаваных выкананых файлаў. Выконваны файл кантралюе працэс абнаўлення прашыўкі і паведамляе код звароту.

BIOS і IPMI звычайна наладжваюцца праз шаблоны. Пры неабходнасці шаблон можна рэдагаваць перад самай загрузкай.

Утыліты RAID у некаторых вендараў таксама могуць наладжваць па шаблоне. Калі гэта не так, то давядзецца напісаць сцэнар наладкі.

Парадак налады RAID часцей за ўсё наступны:

  • Запытваем бягучую канфігурацыю.
  • Калі ўжо ёсць лагічныя масівы - сціраны.
  • Глядзім, якія фізічныя дыскі прысутнічаюць і колькі іх.
  • Ствараем новы лагічны масіў. Перапыняем працэс у выпадку памылкі.

Як атрымаць наладкі для канкрэтнага сервера?

Выкажам здагадку, налады ўсіх сервераў будуць захоўвацца на інсталл-серверы. У такім разе, каб адказаць на наша пытанне, трэба спачатку вырашыць: якім чынам перадаваць налады ва ўсталеў-сервер.

На першую пару суцэль можна абыйсціся тэкставымі файламі. (У будучыні можна выкарыстоўваць тэкставы файл як рэзервовы спосаб перадачы настроек).

Можна "расшарыць" тэкставы файл на інсталл-серверы. І дадаць яго мантаванне ў скрыпт mount.sh.

Радкі будуць, напрыклад, такога віду:

<серыйны нумар> <імя хаста> <падсетка>

Гэтыя радкі будуць перадавацца ў файл інжынерам з яго працоўнай машыны. І далей пры наладзе сервера параметры для пэўнага сервера будуць прачытаныя з файла.

Але, у даляглядзе, лепш, задзейнічаць БД для захоўвання налад, станаў і часопісаў усталёвак сервераў.

Вядома, адной БД не абыйсціся, і запатрабуецца стварыць кліенцкую частку, з дапамогай якой будуць перадавацца налады ў базу. Рэалізаваць гэта складаней, у параўнанні з тэкставым файлам, але, насамрэч, усё не так цяжка, як здаецца. Мінімальную версію кліента, які будзе проста перадаваць дадзеныя ў БД, цалкам пасільна напісаць самому. А паляпшаць кліенцкую праграму ў далейшым можна будзе і ў вольным рэжыме (справаздачы, друк этыкетак, адпраўка апавяшчэнняў і іншае, што прыйдзе ў галаву).

Зрабіўшы вызначаны запыт у базу і паказаўшы серыйны нумар сервера, атрымаем неабходныя параметры для налады сервера.

Плюс, нам не запатрабуецца прыдумляць блакаванні для адначасовага доступу, як у выпадку з тэкставым файлам.

Часопіс наладкі можам на ўсіх этапах пісаць у БД і працэс усталёўкі кантраляваць праз падзеі і сцягі этапаў падрыхтоўкі.

Цяпер мы ведаем, як:

  • загружаць сервер па PXE;
  • перадаваць кіраванне нашаму скрыпту;
  • ідэнтыфікаваць сервер, які трэба падрыхтаваць, па серыйным нумары;
  • канфігураваць сервер адпаведнымі ўтылітамі;
  • перадаваць наладкі ў БД інсталл-сервера з дапамогай кліенцкай часткі.

Высветлілі, якім чынам:

  • усталёўваны сервер атрымлівае неабходныя налады з БД;
  • увесь прагрэс падрыхтоўкі фіксуецца ў БД (лагі, падзеі, сцягі этапаў).

Што наконт розных тыпаў усталёўванага ПЗ? Як усталяваць гіпервізар, скапіяваць ВМ і наладзіць усё гэта?

У выпадку разгортвання выявы файлавай сістэмы (linux) на жалеза ўсё даволі проста:

  • Пасля налады ўсіх кампанентаў сервера, разгортваем выяву.
  • Усталеўваны загрузнік grub.
  • Які робіцца chroot і наладжваем усё што неабходна.

Як перадаць кіраванне ўсталёўніку АС (на прыкладзе ESXi).

  • Які арганізуецца перадачу кіравання з нашага скрыпту ўсталёўніку гіпервізара па файле аўтаадказаў (kickstart):
  • Выдаляем бягучыя раздзелы на дыску.
  • Ствараем раздзел памерам 500MB.
  • Пазначаем яго як загрузны.
  • Фарматуем у FAT32.
  • Капіяваны на яго ў корань усталявальныя файлы ESXi.
  • Усталеўваны syslinux.
  • Капіяваны syslinux.cfg у /syslinux/

default esxi
prompt 1
timeout 50
label esxi
kernel mboot.c32
append -c boot.cfg

  • Капіяваны mboot.c32 у /syslinux.
  • У boot.cfg павінна быць kernelopt=ks=ftp:// /ks_esxi.cfg
  • Перазагружаем сервер.

Пасля перазагрузкі сервера з яго цвёрдай кружэлкі загрузіцца ўсталёўнік ESXi. Усе неабходныя файлы ўсталёўшчыка загрузяцца ў памяць і далей пачнецца ўсталёўка ESXi, паводле паказанага файла аўтаадказаў.

Прывяду тут некалькі радкоў з файла аўтаадказаў ks_esxi.cfg:

%firstboot --interpreter=busybox
…
# получаем серийный номер

SYSSN=$(esxcli hardware platform get | grep Serial | awk -F " " '{print $3}')

# получаем IP

IPADDRT=$(esxcli network ip interface ipv4 get | grep vmk0 | awk -F " " '{print $2}')
LAST_OCTET=$(echo $IPADDRT | awk -F'.' '{print $4}')

# подключаем NFS инсталл-сервера

esxcli storage nfs add -H is -s /srv/nfs_share -v nfsshare1

# копируем временные настройки ssh, для использования ssh-клиента

mv /etc/ssh /etc/ssh.tmp
cp -R /vmfs/volumes/nfsshare1/ssh /etc/
chmod go-r /etc/ssh/ssh_host_rsa_key

# копируем ovftool, для развертывания ВМ сейчас, плюс возможно пригодится позже

cp -R /vmfs/volumes/nfsshare1/ovftool /vmfs/volumes/datastore1/

# развертываем ВМ

/vmfs/volumes/datastore1/ovftool/tools/ovftool --acceptAllEulas --noSSLVerify --datastore=datastore1 --name=VM1 /vmfs/volumes/nfsshare1/VM_T/VM1.ova vi://root:[email protected]
/vmfs/volumes/datastore1/ovftool/tools/ovftool --acceptAllEulas --noSSLVerify --datastore=datastore1 --name=VM2 /vmfs/volumes/nfsshare1/VM_T/VM2.ova vi://root:[email protected]

# получаем строку с настройками нашего сервера

ssh root@is "mysql -h'192.168.0.1' -D'servers' -u'user' -p'secretpassword' -e "SELECT ... WHERE servers.serial='$SYSSN'"" | grep -v ^$ | sed 's/NULL//g' > /tmp/servers
...
# генерируем скрипт настройки сети

echo '#!/bin/sh' > /vmfs/volumes/datastore1/netconf.sh
echo "esxcli network ip interface ipv4 set -i=vmk0 -t=static --ipv4=$IPADDR --netmask=$S_SUB || exit 1" >> /vmfs/volumes/datastore1/netconf.sh
echo "esxcli network ip route ipv4 add -g=$S_GW -n=default || exit 1" >> /vmfs/volumes/datastore1/netconf.sh
chmod a+x /vmfs/volumes/datastore1/netconf.sh

# задаем параметр guestinfo.esxihost.id, указываем в нем серийный номер

echo "guestinfo.esxihost.id = "$SYSSN"" >> /vmfs/volumes/datastore1/VM1/VM1.vmx
echo "guestinfo.esxihost.id = "$SYSSN"" >> /vmfs/volumes/datastore1/VM2/VM2.vmx
...
# обновляем информацию в базе

SYSNAME=$(esxcli hardware platform get | grep Product | sed 's/Product Name://' | sed 's/^ *//')
UUID=$(vim-cmd hostsvc/hostsummary | grep uuid | sed 's/ //g;s/,$//' | sed 's/^uuid="//;s/"$//')
ssh root@is "mysql -D'servers' -u'user' -p'secretpassword' -e "UPDATE servers ... SET ... WHERE servers.serial='$SYSSN'""
ssh root@is "mysql -D'servers' -u'user' -p'secretpassword' -e "INSERT INTO events ...""

# возвращаем настройки SSH

rm -rf /etc/ssh
mv /etc/ssh.tmp /etc/ssh

# настраиваем сеть и перезагружаемся

esxcli system hostname set --fqdn=esx-${G_NICK}.x5.ru
/vmfs/volumes/datastore1/netconf.sh
reboot

На гэтым этапе ўстаноўлены і настроены гіпервізор, скапіяваны віртуальныя машыны.

Як зараз наладзіць віртуальныя машыны?

Мы крыху схітравалі: падчас усталёўкі задалі параметр guestinfo.esxihost.id = "$SYSSN" у файле VM1.vmx, паказалі ў ім серыйны нумар фізічнага сервера.

Цяпер пасля старту віртуальная машына (з усталяваным пакетам vmware-tools) можа атрымаць доступ да гэтага параметру:

ESXI_SN=$(vmtoolsd --cmd "info-get guestinfo.esxihost.id")

Гэта значыць ВМ здолее ідэнтыфікаваць сябе (яна ведае серыйны нумар фізічнага хаста), зрабіць запыт да БД усталёўнік-сервера і атрымаць параметры, якія трэба наладзіць. Гэта ўсё афармляецца ў скрыпт, які павінен быць запушчаны аўтаматам пры старце guestos vm (але аднойчы: RunOnce).

Цяпер мы ведаем, як:

  • загружаць сервер па PXE;
  • перадаваць кіраванне нашаму скрыпту;
  • ідэнтыфікаваць сервер, які трэба падрыхтаваць, па серыйным нумары;
  • канфігураваць сервер адпаведнымі ўтылітамі;
  • перадаваць налады ў БД інсталл-сервера з дапамогай кліенцкай часткі;
  • наладжваць розныя тыпы П.А., у тым ліку разгортваць гіпервізор esxi і наладжваць віртуальныя машыны (і ўсё аўтаматычна).

Высветлілі, якім чынам:

  • усталёўваны сервер атрымлівае неабходныя налады з БД;
  • увесь прагрэс падрыхтоўкі фіксуецца ў БД (лагі, падзеі, сцягі этапаў).


Вынік:

Мяркую, унікальнасць дадзенага рашэння ў гнуткасці, прастаце, яго магчымасцях і ўніверсальнасці.

Напішыце, калі ласка, у каментарах, што вы думаеце.

Крыніца: habr.com

Дадаць каментар