Про минимализм, докер, home assistant и ресурсы
Предупрежу на берегу - сейчас будет ворчание старого пер... винтажного газогенератора. Кто не переваривает всю эту "траву, которая раньше была зеленее" - проходите мимо. :)
В мире есть мало вещей, которые меня выводят из себя. И одна из таких вещей - расточительность в отношении ресурсов. Для того, чтобы всем было понятно, представьте, как какой-нибудь олигарх публично жалуется на жизнь, мол, как ему тяжко стало жить! И теперь он в месяц зарабатывает не 20 миллионов, а только 15. В IT мире примерно то же самое. За последние несколько лет индустрия шагнула далеко вперёд и у бизнеса появилась возможность заткнуть любую дыру деньгами или, как ещё говорят - "закидать железом". Ну и что, что наше приложение обрабатывает за секунду не миллион запросов, а только 100 тысяч - давайте просто купим 10 серверов вместо одного и всё будет ок! Да, зачастую это разумный подход и действительно - проще оплатить аренду более жирной виртуалки, чем платить пару месяцев зарплату всему отделу, который это будет оптимизировать. Но на этих принципах выросло уже целое поколение разработчиков и целая куча продуктов, которые иногда у меня вызывают недоумение. Помнится, в конце 90-х годов шикарной домашней машиной считался Pentium MMX на 166 мегагерц с 32мб оперативной памяти и жёстким диском хорошо, если на 1гб. Сейчас долбаные полоумные часы несут на борту куда более мощное железо. А тогда на этих машинах играли, смотрели кино, слушали музыку, редактировали документы, программировали в конце-концов и вполне успешно!
Сейчас программистам видите ли, 16Гб оперативной памяти - это мало. А вот 32Гб - это хорошо! Да что ж вы с ней делаете такое? Жрёте что ли? Я свой дистрибутив линукса собирал, на котором проработал 5 лет. Так вот он после старта кушал 140 МЕГАбайт оперативной памяти. А если нужно, то загружался вместе со всеми потрохами, туевой хучей утилит, графическим окружением и прочей мешурой в 1.2гб оперативной памяти, а с отсавшимся куском вполне мог работать.
Да, я понимаю - лексический анализатор, да, я понимаю, линтеры/шминтеры, кеши/хэши, поддержка миллиона различных тем подсветки синтаксиса, шрифты с лигатурами... Но что мы должны получить на выходе? Код. Да, он стал сложнее, да его стало больше. Но ждать по 4 минуты, пока стартанёт очередное исчадие ада от интелиджи - это нормально, а вот если у нас скроллинг не идеально плавный - так это фи! Если у нас линтер как-то не так работает - это фу! Если у нас не ретина - это ниже нашего достоинства и "работать нормально невозможно - глаза режет". А уж если это трансфлект... Какие все стали нежные, аж бомбит! Пока ваша интеллиджи стартует, я быстрее грепом найду нужные места и вимом всё поправлю. Да, не в каждом случае, но когда человек для того, чтобы изменить в двух строках пару символов ждёт по 4-5 минут загрузки какого-нибудь PHP Storm - это прямо огонь! И это ведь не только касается окружения разработки, это и принципов каcается. Возьмите node.js - там наверное для того, чтобы сложить 2+2 будет десяток библиотек одна другой толще и ещё с несколькими сотнями мегабайт зависимостей. Зачастую вместо того, чтобы написать метод в десяток строк, человек импортирует библиотеку, в которой данный метод - это один процент функционала. А другой товарищ для того, чтобы как-то аггрегировать параметры запуска и сборки приложения на php, написал Makefile, искренне считая, что это правильно. И потом в консоли набирал make build, make run, make test... А что не так? Работает ведь! Ну конечно, работает. Только вот почему не использовать скрипт на shell для этого (заметьте, даже не на bash) с кейсом? Просто если это будет мейкфайл и мне предложено воткнуть это в контейнер, то автоматически мне придётся тянуть за этим одним файлом в контейнер gcc, cpp, множество зависимостей и контейнер вместо 150мб будет занимать более 500мб. Очень рационально.
Или например, когда девушка на работе для того, чтобы построить простейшее REST API использует Flask... Спасибо конечно, что не Django! Наверное просто потому что Джанго для настройки требует дополнительных телодвижений. А так - увидели на stack overflow или ещё где-то, копипаст и в продакшен. Ок, не стал ничего говорить, ибо переделывать было некогда. Но при этом всём поверх flask ещё использовали aiohttp, хотя конкретно для целей REST API можно было обойтись легко и голым aiohttp - зачем был импортирован фласк - я так и не понял. Шобы было! Но это по незнанию и неопытности. Простим девушку. Надо будет потом как-то мягко намекнуть, мол, смотри как можно быстро просто и красиво сделать!
Насчёт докера - это отдельная песня. Докер пихают везде и всюду. Где нужно и где не нужно. Потому что модно/стильно/молодёжно. Это как раз из оперы "все будут с моста прыгать - и ты прыгнешь?" - вот большинство и прыгает. Есть, скажем, системы для управления умным домом. Сначала я жил на Majordomo, потом решил попробовать Home Asisstant. Первая больше для домохозяек и простых смертных - всё можно натыкать мышью, но несколько старомодна. Вторая - как раз более современно выглядит и имеет три варианта установки. Самая пожалуй, популярная называется HASSIO - это контейнер с самим Home Assistant и вокруг всё обмазано контейнерами:
homeassistant/amd64-hassio-supervisor
homeassistant/amd64-hassio-multicast:2
homeassistant/amd64-hassio-cli:25
homeassistant/amd64-hassio-audio:14
homeassistant/amd64-hassio-dns:9
А почему только пять? Почему не десять? Почему в конце-концов ради этого не поднять полностью kubernetes? Причём supervisor - это отдельный контейнер, который позволяет устанавливать расширения в виде других контейнеров. Т.е. каждый плагин, каждая интеграция - это отдельный контейнер, Карл! При этом часть этих контейнеров можно заменить чекаутом нужного функционала с гитхаба в отдельную папку и добавлением конфига. Причём всё это рекомендовано ставить на пишку. С докером вместе естесственно. Причём в мануалах ещё часто фигурирует отдельный контейнер с portainer'ом (это web интерфейс для управления другими контейнерами) для тех, у кого не нашлось 10 минут, чтобы разобраться, как пишется docker help в терминале. Да, ок, я понимаю - попытка сделать установку частей проще. Но зачем, если сама система и так не на домохозяек рассчитана? Предположим, я ставлю в докере по мануалу HASSIO, но затем мне всё-равно нужно понять, что такое yaml, прочитать километр документации, посмотреть несколько десятков примеров и обучающих видео, чтобы у меня что-то взлетело. А потом люди приходят в канал в телеграме и спрашивают - а куда это у меня улетает по 700мб места за сутки? Ну так если у тебя два десятка контейнеров с непонятным барахлом, а по дефолту в докере логротейт на логи контейнера не включен - ничего удивительного в этом нет. А вот если бы сначала разобраться в том, как это работает, но похоже, это излишнее усложнение жизни. Ладно, это половина беды. Для ESP8266 и ESP32 кажется, тоже есть прошивка ESP Home, которая позволяет легко и просто девайсы на этой прошивке интегрировать с системой управления умным домом. Идея богатая и разумная. Но контейнер, который поддерживает эту интеграцию, весит 1.3Гб! У меня majordomo вместе с mysql базой, с операционной системой, со всеми потрохами, бекапами, интеграцией и логами весили 1.7Гб! Да и вообще - всё это крутилось на Orange Pi Zero c 256мб оперативной памяти и был достаточный запас по производительности. При попытке поставить на эту же конфигурацию HASSIO, он с докером на пару при старте съедал всю оперативную память, OOM Killer терялся, не зная, кого убить и в итоге пишка зависала наглухо - ей не хватало оперативной памяти даже на то, чтобы открыть новую SSH сессию. Когда рассказал об этом на форуме, меня спрашивали - это где это я такой девайс нашёл с 256мб оперативной памяти? Да я о таком количестве мегабайт оперативки раньше и мечтать не смел! Сейчас же на новой расберри 8Гб. ВОСЕМЬ, КАРЛ!!! В общем, плюнул на всё, снёс HASSIO, поставил HomeAssistant в virtualenv - всё прекрасно и шустро работать и опять же, есть запас по производительности. Вот зачем было это всё обмазывать докером? Почему нельзя установку дополнительного функционала реализовать в форме установки плагинов, как это например сделано в том же Majordomo и множестве других программных продуктов?
Хотел я интегрировать сяомишные датчики температуры и влажности. Выяснилось, что в зависимостях у плагина модуль bluepy, который тянет за собой ещё пару сотен мегабайт библиотек. За вечер написал на шелле тулзу, которая используя утилиты из стандартного пакета bluez и mosquitto_pub получает данные и отправляет куда надо. Зависимостей - меньше, чем на мегабайт.
Пытался сделать интеграцию с телевизором LG, ей зачем-то в исходниках понадобился numpy и ещё много всякого интересного, что она собирала с использованием python-dev. Это я уже собирал на 512мб плате. И что вы думаете - через каких-то полчаса сборки машина зависла наглухо - опять таки скушана вся оперативная память под завязку. Пришлось отправлять в ребут по-плохому. Пока ещё не знаю, как с этим разобраться. Вот для чего блин, там понадобился numpy? Там же чисто общение с REST API WebOS. Пришлось свернуть весь мир в архив, закинуть на одну из пишек, что стоят под octoprint и запустить сборку там. Все 4 ядра в потолок, CPUTemp: 84 градуса... Ох и нелёгкая это работа для PI - собирать numpy. Собрал - 36 минут. Судя по коду (при беглом осмотре) - похоже, использовались только структуры данных из numpy. Я конечно не специалист, но неужели нельзя было как-то обойтись без всего этого огромного сарая, если нам нужны только структуры данных? Этой библиотекой пользуются в НАСА, чтобы производить научные рассчёты, но нет - мы будем использовать её для того, чтобы общаться с апишкой телевизора! Гениально! И такое на каждом шагу, аж бесит!
Для тех, кому уровней абстракции маловато, существует ещё HASSOS - это вообще образ операционной системы, где всё по дефолту закрыто для простого пользователя и потом любые попытки на этом обрубке запустить рядом что-то ещё приводят к ряду проблем и сложностей. Внутри конечно же, докер с теми же контейнерами, но в хост систему получить шелл я да же и не знаю, можно ли вообще без особых извращений. Один товарищ хотел интеграции с нашими устройствами и это не удалось сделать, поскольку у него стояла HASSOS.
Следующий логический уровень абстракции в системах управления умного дома - нанять горничную 24/7. Матрёна, позакрой-ка ставни, барин почивать изволит!
Откуда у людей вообще эта тяга к использованию карьерных самосвалов для вылазки в булочную за хлебом, которая находится за углом? Посмотрите, как прекрасно сделан тот же busybox, KolibriOS в конце-концов! Разве это не удивительно? Что это, если не произведения искусства? Да, свои велосипеды это плохо, но в булочную лучше на велосипеде, чем на самосвале.
Теги: админское, docker, minimalism, smarthome, подгорание