Как вы использовали Buildroot в DevOps-контексте?

Да ты посмотри, какая тема интересная! Buildroot — это ж, блядь, как конструктор для взрослых дядек, которые устали от этих ваших готовых дистрибутивов, где половину софта никогда не используешь, а он место жрёт, как не в себя.

Контекст, если по-простому: Нужно было собирать прошивки для кучи умных железок на ARM (термостаты, датчики, хуй пойми что ещё) и делать такие микроскопические образы для Docker, чтобы Go-приложения в них жили. Типа FROM scratch, только чтоб всё под контролем было, а не тянуть за собой целый Debian ради одного бинаря.

1. Всё по-взрослому, инфраструктура как код: Вся эта движуха с компиляцией была описана так, что любой новый чувак в команде мог просто клонить репу и не ебаться с вопросами «а где тут библиотеку для левой пятки доставить?». Всё лежало в Git: и настройки, и наши костыли-патчи.

• Как это в папках выглядело:

  buildroot-iot-firmware/
  ├── board/company/device/  # Тут наши кривые ручки: скрипты, заплатки для ядра, всякая хуйня после сборки
  │   ├── patches/linux/     # Патчи, потому что вангуевое ядро иногда нихуя не работает как надо
  │   ├── post-build.sh      # Скрипт, который после сборки всё лишнее выпиливает
  │   └── rootfs-overlay/    # Наши файлы, которые просто кладутся поверх готовой системы
  ├── configs/               # Готовые конфиги под разные девайсы. Нажал одну кнопку — получил прошивку для конкретной железяки.
  │   └── device_rpi4_defconfig
  ├── external.desc          # Описание наших внешних пакетов
  ├── external.mk            # А это как их собирать
  └── package/               # А вот тут наши собственные пакеты, которых в Buildroot отродясь не было
      └── my-agent/          # Например, наш агент для сбора метрик
          ├── Config.in      # Описание для менюшки
          ├── my-agent.mk    # Инструкция по сборке
          └── S99myagent     # Скрипт, чтобы он запускался при старте

2. Запускаем в CI/CD (GitLab CI), чтобы руки не марать:

build_firmware:
  stage: build
  image: debian:bookworm
  script:
    - apt-get update && apt-get install -y build-essential libncurses-dev
    - wget https://buildroot.org/downloads/buildroot-2023.02.tar.xz
    - tar xf buildroot-2023.02.tar.xz
    - cp configs/device_rpi4_defconfig buildroot-2023.02/.config
    - cd buildroot-2023.02
    - make BR2_EXTERNAL=../ board/company/device/linux-rebuild -j$(nproc)
    - make -j$(nproc)
  artifacts:
    paths:
      - buildroot-2023.02/output/images/sdcard.img

Суть в чём: нажимаешь кнопку в гите — и через полчаса тебе готовый образ sdcard.img валяется в артефактах. Красота, ёпта! А ещё можно было на QEMU потестировать, если архитектура поддерживалась, прежде чем на реальное железо ливать.

3. Главные фишки, без которых нихуя не работает:

• Воспроизводимость, мать её: Это святое. Я фиксировал конкретные версии всего: и самого Buildroot, и наших надстроек. А ещё была локальная папка dl/ — кеш всех исходников. Чтобы если какой-то китайский сайт с библиотеками ляжет, наша сборка не накрылась бы медным тазом. Доверия ебать ноль к интернету в момент сборки.
• Ужимали всё до предела: Сидишь в menuconfig и выключаешь всё, что шевелится. Нужна консоль? Оставляем busybox. А этот gdb, perl и прочая мартышлюшка? Нахуй! Ставили musl вместо glibc — система ещё на пару мегабайт худее становилась.
• Безопасность: В тех самых post-build скриптах выпиливали дефолтные учётки, убивали ненужные демоны. Чтобы на устройстве не оставалось открытых дверей для всяких пидарасов шерстяных.
• Конфиги под контролем: Использовал make savedefconfig — он выплёвывает минимальный конфиг, только наши изменения. Этот файл коммитился в git. Приходит новый чувак, смотрит diff между версиями и сразу видит, что поменялось: «А, в этой версии добавили поддержку Wi-Fi модуля». Удобно, блядь!

Итог: Получился конвейер, который по тегу в гите штамповал готовый образ, заточенный под конкретную железяку. Ничего лишнего, всё своё. Для устройств, где каждый килобайт флешки на счету, — идеально. Ёперный театр, а не инструмент.