Комментарии 22
Может вам было проще Ansible использовать?
Может вам было проще Ansible использовать?
Ansible работает в операционной системе. А ее еще нет, только железка.
Все равно пришлось бы делать универсальный pxe-live образ, скрипты для взаимодействия с различными подсистемами и прочее.
Плюс, Ansible, вроде, появился в 2012. А я начал работать над моим решением приблизительно в это же время.
Это очень низкокачественные продукты. Все они выросли из феерически убогих скриптов быдлоадминов. Лучше руками сделать. Надежнее.
Вы решили на личности перейти?
Я не только досконально когда-то знал cobbler и Foreman, но я даже консультировал основателя последнего — мой бывший сосед. Там такой трэш на руби внутри, что вам не снилось.
Вообще, это одна из стадий взросления инженера — перестать из всего официального делать себе авторитеты. Вот вам и я на личности перешел.
А то не знаю, может вам и RHEL качественным кажется)))) Я не удивлюсь уже.
Небольшая демонстрация формана:
#!/bin/bash
# This script will allow you to run tfm-stories
# while foreman can still use webpack-3 for the normal build.
#
# It is here temporarily until the migration to webpack-4 will be done.
if [ "$NODE_ENV" = "production" ]; then
exit 0
fi
cd ./node_modules/@theforeman/stories
npm installОт каждой строчки волосы дыбом встают. Это я еще самый короткий файл выбрал. Там люди писали — они даже не знают, что логи в линуксе в файл не пишут — это нарушает single responsibility, за это отвечает rsyslog.
Я думаю, преимущества нашего решения:
1) В целом небольшая база кодовая база. Все решение вполне может поддерживать один человек. В любое время можно добавить новый функционал.
2) Из доступных продуктов не все могут обеспечивать полный перечень необходимых функций (обновление прошивок, настройка ilo/idrac, прочее).
Картинка ниже — это уже маркетинговый буллщит:
И обновление Firmware ко многим пройдет с нетривиальными действиями.
Например, через WinPE и запуска своего набора прошивальщиков firmware.
Конечно, здесь речь не идет о поддержке абсолютно любого железа. В начале статьи указано, что решение придется адаптировать под каждый новый сервер (новый вендор или новая модель с отличающимся функционалом). Как правило, это не чаще раза в год.
Вы пытаетесь в пару сотен строк описать 30% бизнеса хостеров (бареметалл-хостеров). Как инсайдер говорю вам — там бездна. Чтобы сервера работали в режиме "заказал/установил/получил" нужны десятки тысяч строк кода (и это без учёта различий в моделях).
Потому что у вас там будет миллион нюансов настроек биосов сетевух, странных настроек драков, особенностей загрузки, порядка следования дисков на хвадварных/софтварных рейдах (никогда не пробовали загрузить сервер с диска № 112 так, чтобы граб не запутался где находится его миррор?). Это мы ещё не трогаем lifecycle management (прошивки, апдейты фирмварь и биосов) и т.д.
Конечно, здесь речь не идет о поддержке абсолютно любого железа. Скорее о 4-5 вендорах, не более 10 моделей на каждого вендора.
Согласен, если говорить о поддержке гораздо более широкого перечня моделей и более широкого набора конечных образов систем, скорее всего, нужно будет смотреть в другую сторону.
Но данное решение хорошо вписывается в текущие потребности.
Х5 вроде как небедная контора, а инфраструктура как у школьного хостинга.
Рейды какие-то, пхе…
- Вы можете использовать grub вместо syslinux там же в PXE — открывает вам килотонны возможностей. Сможете делать rd.brake в дракуте, чтобы на пре-пивоте тормозить установку, диктовать дополнительные репо, делать иерархическое меню и вот это вот всё.
- Параметры не надо читать скриптами — это очень плохая практика. Вам надо написать %addon, втащить его в update.img и читать параметры с инклудов — в таком случае люди при установке смогут подправить что-то, если захотят через обычное меню Анаконды. В таком случае вы сможете на результирущем кикстарте после установки видеть параметры, если что пошло не по сценарию.
С этой темой тяжело начать из-за говнокода RHEL, но если соберетесь, я покажу как сделать. - У вас перегружен kickstart. Не надо там логику писать. Нужно подекларативнее немного подходить. Создайте аккуратно директорию, которая тоже войдет в update.img, в ней положите все свои скрипты (без шабангов и вызовов — только чтобы объявляли функции). И уже из кикстарта дергайте эти функции. Тогда все будет выглядеть наглядно. Например:
source /tmp/install/scripts/setup.toolset.sh
# Все эти функции ниже объявились при сурсе setup.toolset.sh
connectivity.check
utils.set_hostname
utils.set_motd
utils.set_product_file
repos.install epel satellite baseos
log.error "some message"А сам setup.toolset.sh:
source /tmp/install/scripts/inc/logging.sh
source /tmp/install/scripts/inc/connectivity.sh
source /tmp/install/scripts/inc/disk.sh
source /tmp/install/scripts/inc/utils.sh
source /tmp/install/scripts/inc/packages.sh
source /tmp/install/scripts/inc/bitwarden.sh
source /tmp/install/scripts/inc/ansible.shПример одного из перечисленных скриптов:
function log.error() { logger -t "ISO Builder" -- "$@"; echo "[ERROR] $@"; }
function log.warning() { logger -t "ISO Builder" -- "$@"; echo "[WARNING] $@"; }
function log.notice() { logger -t "ISO Builder" -- "$@"; echo "[NOTICE] $@"; }
function log.info() { logger -t "ISO Builder" -- "$@"; echo "[INFO] $@"; }
function log.debug() { if $debug; then echo "[DEBUG] $@"; fi }Ну и мелкое замечание:
настроить BIOS
BIOS не существует. Вот уже лет 20 никто его в глаза не видел. Это UEFI в режиме обратной совместимости :-)
бареметал — это основа для частного облака. Другой вопрос, что крупные вендоры вроде Cisco предлагают достаточно хорошие решения для бутстрапа.
Вот эпичная статья от КРОКа на эту тему https://habr.com/ru/company/croc/blog/472406/
Bare-Metal Provisioning своими руками, или Автоматическая подготовка серверов с нуля