DIY 베어 메탈 프로비저닝 또는 처음부터 서버 자동 준비

안녕하세요, 저는 Denis입니다. 제 활동 분야 중 하나는 X5에서 인프라 솔루션 개발입니다. 오늘 저는 공개적으로 사용 가능한 도구를 기반으로 자동 서버 준비 시스템을 배포하는 방법을 여러분과 공유하고 싶습니다. 제 생각에는 이것은 흥미롭고 간단하며 유연한 솔루션입니다.

준비란 새 서버를 OS가 포함된 완전히 구성된 서버로 바꾸는 것을 의미합니다. Linux 또는 ESXi 하이퍼바이저 사용(Windows 서버 배포는 이 문서에서 논의되지 않음)

약관:

• 서버 – 구성해야 하는 서버입니다.
• 설치 서버는 네트워크를 통해 준비 과정 전체를 제공하는 메인 서버입니다.

자동화가 필요한 이유는 무엇입니까?

작업이 있다고 가정해 보겠습니다. 서버를 처음부터 최대로 하루에 30개까지 대규모로 준비하는 것입니다. 다양한 제조업체 및 모델의 서버, 다양한 운영 체제가 설치될 수 있으며 하이퍼바이저가 있을 수도 있고 없을 수도 있습니다.

설정 프로세스에는 어떤 작업이 포함됩니까(자동화 없음):

• 키보드, 마우스, 모니터를 서버에 연결합니다.
• BIOS, RAID, IPMI 구성;
• 구성 요소 펌웨어 업데이트;
• 파일 시스템 이미지 배포(또는 하이퍼바이저 설치 및 가상 머신 복사)

메모. 또는 자동 응답 파일을 이용한 설치를 통해 OS 배포가 가능합니다. 그러나 이 기사에서는 이에 대해 논의하지 않을 것입니다. 아래에서 이 기능을 추가하는 것이 어렵지 않다는 것을 알 수 있습니다.

• OS 매개변수(호스트 이름, IP 등)를 구성합니다.

이 접근 방식을 사용하면 각 서버에서 동일한 설정이 순차적으로 수행됩니다. 그러한 작업의 효율성은 매우 낮습니다.

자동화의 핵심은 서버 준비 과정에서 사람의 개입을 없애는 것입니다. 가능한 한 많이.

자동화를 통해 작업 간 가동 중지 시간을 줄이고 여러 서버를 동시에 프로비저닝할 수 있습니다. 인적 요인으로 인한 오류 가능성도 크게 줄어듭니다.

서버는 어떻게 자동으로 구성되나요?

모든 단계를 자세히 분석해 보겠습니다.

PXE 설치 서버로 사용하는 Linux 서버가 있습니다. DHCP, TFTP 서비스가 설치 및 구성됩니다.

따라서 구성이 필요한 서버를 PXE를 통해 부팅합니다. 그것이 어떻게 작동하는지 기억해 봅시다:

• 서버에서 네트워크 부팅이 선택되었습니다.
• 서버는 네트워크 카드의 PXE-ROM을 로드하고 DHCP를 통해 설치 서버에 접속하여 네트워크 주소를 얻습니다.
• DHCP 설치 서버는 주소와 PXE를 통한 추가 다운로드에 대한 지침을 발행합니다.
• 서버는 PXE를 통해 설치 서버에서 네트워크 부트로더를 로드하며, PXE 구성 파일에 따라 추가 로드가 발생합니다.
• 부팅은 수신된 매개변수(커널, initramfs, 마운트 지점, squashfs 이미지 등)를 기반으로 발생합니다.

메모. 이 문서에서는 BIOS 모드를 통해 PXE를 통해 부팅하는 방법을 설명합니다. 현재 제조업체에서는 UEFI 부팅 모드를 적극적으로 구현하고 있습니다. 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 이미지이며, 이를 통해 서버의 주요 준비 및 구성이 수행됩니다.

보시다시피 부트로더는 많은 매개변수를 커널에 전달합니다. 이러한 매개변수 중 일부는 커널 자체에서 사용됩니다. 그리고 우리는 우리 자신의 목적을 위해 일부를 사용할 수 있습니다. 이에 대해서는 나중에 논의하겠지만 지금은 전달된 모든 매개변수를 /proc/cmdline을 통해 중간 Linux 이미지에서 사용할 수 있다는 점만 기억하면 됩니다.

커널과 initramfs는 어디서 구할 수 있나요?
기본적으로 모든 Linux 배포판을 선택할 수 있습니다. 선택할 때 주의할 점은 다음과 같습니다.

• 부팅 이미지는 범용이어야 합니다(드라이버 가용성, 추가 유틸리티 설치 기능).
• 아마도 initramfs를 사용자 정의해야 할 것입니다.

X5용 솔루션에서는 이것이 어떻게 수행됩니까? CentOS 7이 기본으로 선택되었습니다. 다음 트릭을 시도해 보겠습니다. 미래의 이미지 구조를 준비하고 이를 아카이브에 압축한 다음 initramfs를 생성합니다. 그 안에 파일 시스템 아카이브가 있을 것입니다. 이미지를 로드하면 아카이브가 생성된 tmpfs 파티션으로 확장됩니다. 이렇게 하면 vmkernel과 initramfs라는 두 개의 파일로만 구성된 필수 유틸리티가 모두 포함된 최소한의 본격적인 라이브 Linux 이미지를 얻을 수 있습니다.

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

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를 지정했습니다. 결과적으로 이 단계에서는 PXE를 통해 중간 Linux 이미지를 로드하여 OS 콘솔을 받게 됩니다.

좋습니다. 하지만 이제 제어권을 "자동화"로 전환해야 합니다.

이렇게 할 수 있습니다.

이미지를 로드한 후 mount.sh 스크립트로 제어권을 이전할 계획이라고 가정해 보겠습니다.
자동 실행에 mount.sh 스크립트를 포함시켜 보겠습니다. 이렇게 하려면 initramfs를 수정해야 합니다.

• unpack initramfs(위의 initramfs 옵션을 사용하는 경우에는 필요하지 않음)
• /proc/cmdline을 통해 전달된 매개변수를 분석하고 제어를 추가로 전송하는 코드를 시작에 포함합니다.
• initramfs를 팩하세요.

메모. X5 툴킷의 경우 로딩 제어가 스크립트로 전송됩니다. /opt/x5/toolkit/bin/hook.sh с помощью override.conf в getty tty1 (ExecStart=…)

따라서 자동 실행 시 mount.sh 스크립트가 시작되는 이미지가 로드됩니다. 다음으로, mount.sh 스크립트는 실행 중에 전달된 매개변수(script_cmd=)를 분석하고 필요한 프로그램/스크립트를 시작합니다.

라벨 툴킷-자동
핵심...
추가... nfs_toolkit_script=scripts/mount.sh script_cmd=master-install.sh

라벨 툴킷-껍질
핵심...
추가... nfs_toolkit_script=scripts/mount.sh script_cmd=/bin/bash

여기 왼쪽에는 PXE 메뉴가 있고 오른쪽에는 제어 전송 다이어그램이 있습니다.

우리는 통제권 이전을 알아냈습니다. PXE 메뉴 선택에 따라 자동 구성 스크립트 또는 디버깅 콘솔이 시작됩니다.

자동 구성의 경우 다음을 포함하는 필수 디렉터리가 설치 서버에서 마운트됩니다.

• 스크립트;
• 다양한 서버에 대한 저장된 BIOS/UEFI 템플릿;
• 펌웨어;
• 서버 유틸리티;
• 로그

다음으로 mount.sh 스크립트는 스크립트 디렉터리에서 master-install.sh 스크립트로 제어를 전송합니다.

스크립트 트리(실행 순서)는 다음과 같습니다.

• 마스터 설치
• sharefunctions(공유 함수)
• info(정보 출력)
• 모델(서버 모델을 기반으로 설치 매개변수 설정)
• prepare_utils(필요한 유틸리티 설치)
• fwupdate(펌웨어 업데이트)
• diag(기본 진단)
• biosconf(BIOS/UEFI 설정)
• clockfix(마더보드의 시간 설정)
• srmconf(원격 인터페이스 인터페이스 구성)
• raidconf(논리 볼륨 구성)

다음 중 하나:

• 사전 설치(OS 또는 ESXi와 같은 하이퍼바이저 설치 프로그램으로 제어권 이전)
• 병합 설치(이미지 압축 풀기 즉시 시작)

이제 우리는 다음을 알고 있습니다.

• PXE를 통해 서버를 부팅하는 방법
• 자신의 스크립트로 제어권을 전송하는 방법.

계속합시다. 다음 질문이 관련성이 있게 되었습니다.

• 우리가 준비하고 있는 서버를 어떻게 식별하나요?
• 어떤 유틸리티와 서버를 구성하는 방법은 무엇입니까?
• 특정 서버에 대한 설정을 가져오는 방법은 무엇입니까?

우리가 준비하고 있는 서버를 어떻게 식별하나요?

간단합니다 - DMI:

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

공급업체, 모델, 일련번호 등 필요한 모든 것이 여기에 있습니다. 이 정보가 모든 서버에 있는지 확실하지 않은 경우 MAC 주소로 식별할 수 있습니다. 또는 두 가지 방법을 동시에 사용하는 경우 서버 공급업체가 다르고 일부 모델에서는 일련 번호에 대한 정보가 없습니다.

수신된 정보를 기반으로 설치 서버에서 네트워크 폴더가 마운트되고 필요한 모든 것(유틸리티, 펌웨어 등)이 로드됩니다.

어떤 유틸리티와 서버를 구성하는 방법은 무엇입니까?

일부 제조업체에 Linux용 유틸리티를 제공하겠습니다. 모든 유틸리티는 공급업체의 공식 웹사이트에서 사용할 수 있습니다.

펌웨어를 사용하면 모든 것이 명확하다고 생각합니다. 일반적으로 패키지된 실행 파일 형태로 제공됩니다. 실행 파일은 펌웨어 업데이트 프로세스를 제어하고 반환 코드를 보고합니다.

BIOS 및 IPMI는 일반적으로 템플릿을 통해 구성됩니다. 필요한 경우 다운로드하기 전에 템플릿을 편집할 수 있습니다.

일부 공급업체의 RAID 유틸리티도 템플릿을 사용하여 구성할 수 있습니다. 그렇지 않은 경우 구성 스크립트를 작성해야 합니다.

RAID 설정 절차는 대부분 다음과 같습니다.

• 현재 구성을 요청합니다.
• 이미 논리 배열이 있는 경우 이를 지웁니다.
• 어떤 물리 디스크가 있고 몇 개가 있는지 살펴보겠습니다.
• 새 논리 배열을 만듭니다. 오류가 발생하면 프로세스가 중단됩니다.

특정 서버에 대한 설정을 가져오는 방법은 무엇입니까?

모든 서버의 설정이 설치 서버에 저장된다고 가정해 보겠습니다. 이 경우 질문에 대답하려면 먼저 설정을 설치 서버로 전송하는 방법을 결정해야 합니다.

처음에는 텍스트 파일로 작업할 수 있습니다. (나중에 설정 전송을 위한 대체 방법으로 텍스트 파일을 사용할 수 있습니다.)

설치 서버에서 텍스트 파일을 "공유"할 수 있습니다. 그리고 mount.sh 스크립트에 마운트를 추가하세요.

예를 들어 행은 다음과 같습니다.

<일련번호> <호스트 이름> <서브넷>

이 줄은 엔지니어가 작업 기계에서 파일로 전송됩니다. 그런 다음 서버를 설정할 때 특정 서버에 대한 매개변수를 파일에서 읽습니다.

그러나 장기적으로는 데이터베이스를 사용하여 서버 설치의 설정, 상태 및 로그를 저장하는 것이 좋습니다.

물론 데이터베이스만으로는 충분하지 않으며 설정이 데이터베이스로 전송되는 클라이언트 부분을 만들어야 합니다. 텍스트 파일에 비해 구현하기가 더 어렵지만 실제로 모든 것이 보이는 것만 큼 어렵지는 않습니다. 단순히 데이터를 데이터베이스로 직접 전송하는 최소 버전의 클라이언트를 작성하는 것이 가능합니다. 그리고 앞으로는 무료 모드(보고서, 라벨 인쇄, 알림 전송 등 떠오르는 기능)에서 클라이언트 프로그램을 개선하는 것이 가능할 것입니다.

데이터베이스에 특정 요청을 하고 서버 일련 번호를 지정하면 서버 구성에 필요한 매개변수를 받게 됩니다.

게다가 텍스트 파일의 경우처럼 동시 액세스를 위해 잠금 장치를 마련할 필요도 없습니다.

모든 단계에서 데이터베이스에 구성 로그를 기록하고 준비 단계의 이벤트 및 플래그를 통해 설치 프로세스를 제어할 수 있습니다.

이제 우리는 방법을 알고 있습니다:

• PXE를 통해 서버를 부팅합니다.
• 제어권을 스크립트로 전송합니다.
• 일련 번호로 준비해야 하는 서버를 식별합니다.
• 적절한 유틸리티를 사용하여 서버를 구성합니다.
• 클라이언트 부분을 사용하여 설정을 설치 서버 데이터베이스로 전송합니다.

우리는 방법을 알아냈습니다:

• 설치된 서버는 데이터베이스로부터 필요한 설정을 받습니다.
• 모든 준비 진행 상황은 데이터베이스(로그, 이벤트, 단계 플래그)에 기록됩니다.

설치하는 다양한 유형의 소프트웨어는 어떻습니까? 하이퍼바이저를 설치하고, VM을 복사하고, 모두 구성하는 방법은 무엇입니까?

파일 시스템 이미지(Linux)를 하드웨어에 배포하는 경우 모든 것이 매우 간단합니다.

• 모든 서버 구성 요소를 설정한 후 이미지를 배포합니다.
• grub 부트로더를 설치합니다.
• 우리는 필요한 모든 것을 루트로 설정하고 구성합니다.

OS 설치 프로그램으로 제어권을 전송하는 방법(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

이 단계에서는 하이퍼바이저가 설치 및 구성되고 가상 머신이 복사됩니다.

지금 가상 머신을 구성하는 방법은 무엇입니까?

우리는 약간의 속임수를 썼습니다. 설치 중에 VM1.vmx 파일에 guestinfo.esxihost.id = "$SYSSN" 매개 변수를 설정하고 그 안에 물리적 서버의 일련 번호를 표시했습니다.

이제 시작 후 가상 머신(vmware-tools 패키지가 설치된)은 이 매개변수에 액세스할 수 있습니다.

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

즉, VM은 자신을 식별하고(물리적 호스트의 일련 번호를 알고 있음) 설치 서버 데이터베이스에 요청하고 구성해야 하는 매개변수를 수신할 수 있습니다. 이것은 모두 guestos vm이 시작될 때 자동으로 시작되어야 하는 스크립트로 컴파일됩니다(그러나 한 번: RunOnce).

이제 우리는 방법을 알고 있습니다:

• PXE를 통해 서버를 부팅합니다.
• 제어권을 스크립트로 전송합니다.
• 일련 번호로 준비해야 하는 서버를 식별합니다.
• 적절한 유틸리티를 사용하여 서버를 구성합니다.
• 클라이언트 부분을 사용하여 설정을 설치 서버 데이터베이스로 전송합니다.
• esxi 하이퍼바이저 배포, 가상 머신 구성 등 다양한 유형의 소프트웨어를 구성합니다(모두 자동으로).

우리는 방법을 알아냈습니다:

• 설치된 서버는 데이터베이스로부터 필요한 설정을 받습니다.
• 모든 준비 진행 상황은 데이터베이스(로그, 이벤트, 단계 플래그)에 기록됩니다.

하단 라인 :

저는 이 솔루션의 독창성은 유연성, 단순성, 기능 및 다양성에 있다고 믿습니다.

여러분의 생각을 댓글로 적어주세요.

출처 : habr.com