Comments 30
Что-то это выглядит так, как если бы вы писали свой собственный провижнинг. Казалось бы, почему не взять готовый?
Ну не знаю там, скажем, когда передо мной встала задача повторяемо разворачивать что-то на малинке, я взял cloud-init.
Bash тоже интересный и вполне рабочий инструмент, на котором можно создавать проекты.
Но зачем?
Вопрос на который каждый находит ответ сам.
Например, для меня было важно, чтобы можно было передать команду, что конфигурирует машину к которой никто не имеет или не будет иметь доступа, кроме физического (air-gapped environment).
Зачем изобретать велосипед, если лучше потратить время на изучение Ansible?
Ansible - хороший инструмент, который я уже начал изучать, и который собираюсь использовать в ближайшее время.
Но
в данной статье не преследуется цель создать аналог новый Fabric или Ansible, но на чистом Bash. Тут я делюсь, своими заметками о том, что Bash тоже интересный и вполне рабочий инструмент, на котором можно создавать проекты.
Ansible не удобен в отладке. Во всём остальном хорош
Следующим этапом начните изучать ansible, и делайте вот это все через него.
Странно, что вы пропустили его как решение для вашей задачи.
Но требует предварительной установки Python на машину (если ею не управляют через SSH)
Принципиально можно понять это возражение, если речь идёт об air-gapped environment без SSH. С другой стороны, если можно притащить через прокси сборщик Bash-скриптов, можно и контейнер с Ansible и Python, да хоть с чем, главное, чтобы с него SSH-соединение было.
Велосипеды - это интересно, но в итоге они всё же проигрывают известным системам при наращивании масштаба. Если же упороться и сделать прохождение этапа только в случае необходимости и с проверкой результата (существует ли файл? Есть ли .lock файл, сигнализирующий об успешном прохождении этапа?), то выучить Ansible просто быстрее.
Поэтому я и не рассматривал ситуации с использованием SSH, так как эта ниша давно занята известными решениями.
Про air-gapped environment вы заметили верно. Иногда мне приходится работать с оборудованием, что после настройки не будет иметь доступа в интернет вообще и SSH на них если и настраивается, но работает только в локальной сети для экстренных случаев.
С готовой Linux системы где есть всё всё всё,-Подготовьте образ утилитой dd if=/dev/sda of=/mnt/linux_whereFullmycomponents.img
Потом на чистый комп ...грузимся с диска и dd if=/mnt/linux_whereFullmycomponents.img of=/dev/sda
Это(набрать команду) сделает даже эникейщик...Пьете кофе ...возвращаетесь ..система полностью готова к использованию.(возможно потребуется набрать dracut -fv (если совсем железо чуждое))
Да вот ещё ..., а кто будет загрузчик настраивать? Сетевые устройства тоже будут другие.
Скажите честно, что вы ни разу так не делали ...
Не понимаю про какой загрузчик вы говорите...в случае того метода..загрузочная запись MBR GPT UEFI всё попадает..сетевые устройства настроить всё же прозе чем...посмотрите ,что у меня в образе(200gb файл)
Centos7 x64 Субд Oracle 11.2.01(ещё тот квест её поднять) Всё для Pos систем.Драйвера сканеров весов фискальнх регистраторов.Прога для работы с егаисом програ для работы с меркурием сервисы для алкогольных деклараций..Linux окружение для работы с Рутокеном .Окружение для работы с Терминалами сбора данных Программный фискальный регистратор(Это для Украины),Сама ИС.Докер с образом IBM DB2 Express. edition.Desctop окружение Desktop Viber telegram Chrome Mozila.Virtual box c образом винды для росийского егаиса. Всякие утилиты для диагностики...ВЫ это полмесяца вручную ставить будите и не представляю скрипты чтоб это все установить махом.Всё это не используется еа рабочем месте в один момент..но образ единый и подстаивается уже под рабочее место.А так пока всё это час ставится...я занимаюсь своими делами.Linux если знает оборудование в ядре (естественно оно ставится на разное железо) ,то поднимается...можно запустить в режиме rescue и доставить драйвера
Grub загрузчик. Там часто идёт привязка к UUID дисков + могут понадобиться дополнительные драйвера для загрузки ядра.
А скриптами нельзя чтоли всё установить? Я свой арч со всем окружением одним скриптом в виртуалке ставлю
Нет проблем с grub . Когда Вы дублируете dd байт в байт диски UUID(Это ж не аппаратная состовляющая) также дублируется и становится такой же на всех разделах соотвтственно первоначальной системе.Вы получаете полностью копию первоначального диска(При этом размер второго может быть больше). в ядре втором могли быть проблемы если два диска копии поставить на систему(У них одинаковый UUID)...но уже с 3 kernel оно разруливалось(Приоритет монтирования был диска с которго грузится ОС).
Я делаю это с 2007 года и уже наверное более 1000 копий было сделано(мной и командой)...Этот способ реально удобен...а вот когда уже этот "монстр" поднялся...уже скриптами настроечными можно его кастомизировать.(мы так и делам)...А для виртуалки тоже есть соотвтествующий образ...
Тоже лет десять назад делал так бэкапы разделов.
Только я еще предварительно все пустое место файловой системы заполнял нулями, а потом гзипил файлы разделов. Восстановление, соответственно через "zcat img.gz > /dev/sda". Тогда простота метода без необходимости ставить коммерческие программы а-ля "акронис труъ имэйдж" поражала мощью linux.
С повсеместным внедрением UEFI всё уже не так радужно, загрузчик теперь надо чинить через efibootmgr. Еще rEFInd довольно универсальная штука, если только не виснет по неведомой причине.
Рекомендую попробовать Nix или Guix. Можно даже десктопом. Всё что нужно настраивается в файлике конфигурации, развертывается одной командой и обеспечивает воспроизводимость сборки.
Вот пример конфига для NixOS https://nixos.wiki/wiki/NixOS#Declarative_Configuration
Вот пример конфига для GuixOS https://guix.gnu.org/en/manual/en/html_node/Using-the-Configuration-System.html#Using-the-Configuration-System
Все, что вы делаете - лучше сделать через ansible, вдобавок будет гораздо более совместимо с разными дистрибутивами и разными пакетными менеджерами.
Кстати, по вашему велосипеду. Непонятно, зачем вы делаете server.sh и desktop.sh именно контатенацией других скриптов. Гораздо красивее было бы запаковать все ваши инсталл скрипты в поддиректорию, а в server.sh и desktop.sh просто прописать вызов внешних скриптов через source или обычные запуски внешних процессов
файл server.sh
library/install-wireshark.sh
library/install-tmux.sh
library/install-docker.shИли даже создать из них список и обрабатывать в цикле, с проверкой статуса каждого и суммарным итогом.
В результате, просто заглянув в server.sh будет видно список действий
Непонятно, зачем вы делаете server.sh и desktop.sh именно контатенацией других скриптов.
Целью было генерировать отдельный единый файл скрипта. И распространять его примерно так же как делает это https://www.anaconda.com в виде Аnaconda3.sh
Никаких SSH и оркестрации, только bash и хардкор.
Гораздо красивее было бы запаковать все ваши инсталл скрипты в поддиректорию, а в server.sh и desktop.sh просто прописать вызов внешних скриптов через source или обычные запуски внешних процессов
файл server.sh
Во-первых, мы для красоты создаём поддиректорию scripts:
Создадим папку scripts и все скрипты будем хранить там
Если посмотреть мой итоговый проект, то там предусмотрена команда run для запуска скриптов или готовых сборок через source
Или даже создать из них список и обрабатывать в цикле, с проверкой статуса каждого и суммарным итогом.
Это мы тут и сделали:
# Цикл по всем скриптам в папке
for i in $SCRIPTS_DIRECTORY/*.sh; do
[ -e "$i" ] || continue
script_name=$(basename "$i")
_checklist+="$script_name $script_name off "
doneВ самом же проекте добавлено легирование, проверка статуса выполнения скрипта, обработка ошибок и многое другое.
Согласен с предыдущими комментаторами по поводу Ansible. Есть уже готовые проекты для этих целей, которые можно взять за основу, например https://github.com/pigmonkey/spark и https://github.com/raphiz/my-arch-setup. У меня есть https://github.com/shimarulin/workstation для арча и https://github.com/shimarulin/workstation-config для убунты (последний давно не обновлялся, но там можно посмотреть настройку Gnome 3, на арче я гном не использовал)
Изучив вопрос. А далее настроив некоторые для себя сценарии Ansible. Я теперь только через Ansible и Terraform настраиваю удалённые машины. Но для desktop машины - это до сих пор достаточно кривой, как мне кажется вариант. Не сильно лучше и прозрачнее представленного мной решения.
В комментариях дали наводку на NixOS. Перехожу на неё, через годик узнаем насколько она действительно хороша.
а также покажу магию bash
Магии я не увидел, только небезопасный сценарий.
Рекомендую, вам, еще годик попрактиковаться, желательно с серверами за которые вы несете большую ответственность, где за любой простой вам прилетит нагоняй. А потом попробуйте еще раз пересмотреть эту статью и написать новую, проведя работу над ошибками.
Ансибл придумали для того, чтобы не изобретать вот такие костыли. Автор знает про ансибл, но вместо него продолжает бессмысленно тратить время на костыли. Да.... но нет
Настраиваем любой Linux под себя одной командой