Скрипт для поиска распухших логов докера
В который раз уже сталкиваюсь с этой ситуацией. Субботнее утро, хочется немного попрокрастинировать (что при загрузке 60-70 часов в неделю просто жизненно необходимо) и тут начинают сыпаться алерты - заканчивается место на диске одного из рабочих серверов. Как всегда запускаем в tmux команду sudo ncdu -x / и ждём. Пришлось ждать минут 40, так как количество файлов на хосте действительно велико, в основном за счёт кешей npm и node modules. И опять ожидаемо обнаружилось, что несколько сотен гигабайт съели логи новых докер контейнеров, запущенных разработчиками на хосте разработки.
Про минимализм, докер, home assistant и ресурсы
Предупрежу на берегу - сейчас будет ворчание старого пер... винтажного газогенератора. Кто не переваривает всю эту "траву, которая раньше была зеленее" - проходите мимо. :)
В мире есть мало вещей, которые меня выводят из себя. И одна из таких вещей - расточительность в отношении ресурсов. Для того, чтобы всем было понятно, представьте, как какой-нибудь олигарх публично жалуется на жизнь, мол, как ему тяжко стало жить! И теперь он в месяц зарабатывает не 20 миллионов, а только 15. В IT мире примерно то же самое. За последние несколько лет индустрия шагнула далеко вперёд и у бизнеса появилась возможность заткнуть любую дыру деньгами или, как ещё говорят - "закидать железом". Ну и что, что наше приложение обрабатывает за секунду не миллион запросов, а только 100 тысяч - давайте просто купим 10 серверов вместо одного и всё будет ок! Да, зачастую это разумный подход и действительно - проще оплатить аренду более жирной виртуалки, чем платить пару месяцев зарплату всему отделу, который это будет оптимизировать. Но на этих принципах выросло уже целое поколение разработчиков и целая куча продуктов, которые иногда у меня вызывают недоумение. Помнится, в конце 90-х годов шикарной домашней машиной считался Pentium MMX на 166 мегагерц с 32мб оперативной памяти и жёстким диском хорошо, если на 1гб. Сейчас долбаные полоумные часы несут на борту куда более мощное железо. А тогда на этих машинах играли, смотрели кино, слушали музыку, редактировали документы, программировали в конце-концов и вполне успешно!
Теги: админское, docker, minimalism, smarthome, подгорание
Контейнер-пустышка для overlayed сетей docker swarm
В эфире рубрика "Костыли и Велосипеды".
Не так давно добрались мои руки до docker swarm. Только не нужно напоминать о том, что docker на грани банкротства, а кубернетес правит миром окрестрации контейнеров. Подробно объяснять, что это такое, я не буду. И так достаточно много статей и документации на эту тему. По сравнению с kubernetes, swarm намного легче и проще в обращении, не требует установки и практически не требует настройки и, что удобно, позволяет пользоваться почти теми же docker-compose файлами с минимальными изменениями для деплоя. Если контейнеров немного, то городить кластер на kubernetes не имеет смысла, swarm для этого вполне подойдёт.
О правильной остановке внешних дисков и победившей контейнеризации
Надо оставить тут заметку, чтобы не потерять. Возникла у меня проблема - накрылась в очередной раз от периодических отключений питания и отсутствия бесперебойника файловая система на домашнем сервере. Можно было конечно восстанавливать её работоспособность, но объективно было пора переходить на новую. Так как сервер в своё время стоял под телевизором и какое-то время выполнял роль ТВ приставки с Kodi и прочей мультимедией, то на сервере было много всего лишнего, поэтому наиболее идеологически верным было поставить всё с нуля и перенести лишь необходимое. До этого я пользовался proxmox, но уже давно мне не нужны были честные виртуальные машины (а когда они будут нужны, проще на рабочей машине поднять виртуалку в VirtualBox), а все необходимые мне сервисы я давно перенёс в докер.
Теги: админское, docker, hardware, linux, soft
Как уменьшить размер контейнера с python проектом
Для многих небольших микросервисов и проектов я использую python. В то же время контейнеры с python внутри не отличаются компактностью. Сегодня на примере одного проекта попробую проиллюстрировать, как избавить контейнер от лишнего веса.
Теги: админское, containers, docker, python
Отправка логов с OpenWRT/LEDE в syslog и обработка событий
Вдогонку к статье о syslog-ng решил сделать дополнение о том, как завернуть логи с OpenWRT и настроить реакцию на соответствие какому-нибудь фильтру. Дома у меня есть два Xiaomi MiWifi 3G (оказалось крайне доступным и достойным по характеристикам устройством), три штуки Netgear WNR3500L, которые в текущий момент работают в качестве гигабитных свичей в разных частях квартиры и Nexx 3020 для экспериментов. Одним словом, правило для сохранения логов должно быть общее для всех этих устройств, чтобы не писать шесть отдельных конфигурационных файлов. Начать я решил со своего основного Xiaomi роутера с хостнеймом gw01, на котором стоит OpenWRT 18.06.
Теги: админское, docker, logging
Про централизованный сбор логов
За последнее время случилось несколько событий, которые привели меня к необходимости централизованного сбора логов в своей домашней сети.
Что и зачем собирать?
- Периодически ночью отваливается интернет от билайна, хотелось бы видеть, что в этот момент происходит с роутером.
- Есть десяток IoT устройств, построенных на ESP8266, которые с прошивкой ESPEasy умеют отправлять логи по сети.
- Жена на новый год подарила управляемый гигабитный коммутатор, почему бы не снимать логи и с него, если уж будет такая возможность?
- Есть сервер умного дома, работающий на отдельной OrangePI Zero.
- Есть около полутора десятков докер и lxc контейнеров с различными службами и pet-проектами, в том числе и этот блог.
Хотелось бы хранить все эти логи в одном месте, чтобы облегчить их анализ, ротацию, архивирование и бекап. Как обрабатывать подобную информацию - это уже отдельная задача, но для начала эту информацию нужно собрать.
Теги: админское, docker, logging
Ready for production
- Ты видишь контейнер?
- Вижу.
- И я вижу. А его нет!
Достаточно давно я заметил где-то фразу о том, что "docker is ready for production". С тех пор периодически вспоминаю её, каждый раз, когда сталкиваюсь с какими-либо проблемами разного масштаба, связанными с докером. Не поймите меня неправильно, мне нравится эта технология, но для меня странным остаётся тот набор детских заболеваний, которыми этот продукт страдает во вполне зрелом возрасте. Так же не понимаю этого дикого ажиотажа вокруг именно докера, когда всё что нужно и не нужно, пытаются затолкнуть в контейнер, не взирая на то, насколько это удобно и целесообразно в текущей ситуации. Создаётся впечатление, что во-первых, раньше не было никакой контейнеризации в принципе - ни jails на BSD, ни OpenVZ и LXC на линуксе, а во-вторых - и сейчас нет никаких иных технологий, кроме докера - ни snap/flatpack (да-да, иксовые приложения для десктопа тоже пытаются завернуть в докер), ни virtualenv для пайтона - ничего подобного, ни пакетов, ни средств вроде puppet/ansible. Конечно, у докера есть удобные средства доставки, с этим никто не спорит, но не понятно, почему выстрелил в своё время именно он, что его сделало таким "модным, стильным, молодёжным". Скажем, OpenVZ мне нравился откровенно больше, чем LXC, но и тем и другим я пользовался задолго до того, как появился докер. Что помешало обрасти средствами доставки и прочими плюшечками тому же OpenVZ? Отсутствие нативной поддержки в ядре?