Иногда перед запуском контейнеров в Docker Compose хочется выполнить какой-нибудь скрипт или просто набор команд. У данной задачи может быть много различных решений. Предлагаю одно из них, когда перед запуском основных контейнеров запускается какой-то малюсенький c оболочкой, например, sh.

С помощью такого трюка можно запустить какие-то миграции для БД или залить туда какой-то дамп с данными или схемой, сгенерировать какой-нибудь конфиг, создать нужные директории или просто что-то записать, если по какой-то причине вам это надо сделать именно там (куда же без костылей). Для того, чтобы не тащить внешние скрипты, выполним всё прямо в command первого контейнера.

Удобно для этого взять busybox, потому что там много всего есть и он маленький. Но можно обойтись и голым alpine.

services:
 init-nginx:
  image: alpine
  command: ["/bin/sh", "-c", "echo 'server { listen 80; root /usr/share/nginx/html; }' > /config/nginx.conf && echo 'Compose Exec' > /html/index.html"]
  volumes:
   - nginx_config:/config
   - nginx_html:/html

 nginx:
  image: nginx:latest
  volumes:
   - nginx_config:/etc/nginx/conf.d
   - nginx_html:/usr/share/nginx/html
  ports:
   - "8080:80"
  depends_on:
   init-nginx:
    condition: service_completed_successfully

volumes:
 nginx_config:
 nginx_html:

Прямо в compose файле создали конфигурацию Nginx и добавили статическую страничку. Вместо длинной строки command можно записать более наглядно:

  entrypoint: /bin/sh
  command:
   - "-c"
   - |
    echo 'server { listen 80; root /usr/share/nginx/html; }' > /config/nginx.conf
    echo 'Compose Exec' > /html/index.html

Если что-то пойдёт не так и команда не будет выполнена успешно, то второй контейнер не запустится из-за condition: service_completed_successfully.

Если надо что-то сделать на самом хосте перед запуском контейнеров, то просто через volumes подключаем директорию хоста и делаем там всё, что нам надо.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#docker #devops

На прошлой неделе был на конференции Deckhouse Conf. Это не рекламная публикация, у меня её никто не заказывал. Моё посещение было самостоятельным. Публиковал рекламу о событии на канале и сам записался. Ничего о себе особо не указывал, оставил обычную заявку. Мне её подтвердили, так что съездил. Событие было интересное, поэтому решил поделиться с вами некоторыми новыми для себя вещами.

🟢 Конференция в первую очередь была посвящена программному продукту Deckhouse. А точнее экосистеме, которая состоит из множества компонентов. Основные - Kubernetes Platform и Virtualization Platform. Конференция в основном была посвящена Kubernetes и всему, что с ним связано.

Deckhouse Platform представлена в том числе в бесплатной редакции Community Edition с открытым исходным кодом. Развернуть и использовать можно без ограничений в рамках возможностей этой версии. Не знаю, насколько эта версия в реальности функциональна. Не нашёл табличку со сравнением Enterprise и Community. По картинкам и техническому описанию всё выглядит очень красиво. Много своих разработок, о которых технический директор продукта больше часа рассказывал.

🔥 В рамках построения своей платформы Флант полностью переписали мониторинг Prometheus на C++, чтобы снизить нагрузку, которую он создаёт. По словами разработчиков он потребляет до 10 раз меньше памяти, чем обычный Prometheus и до 3 раз эффективней, чем VictoriaMetrics. Что значит эффективней, не знаю. Проект назвали Prom++, он open source, попробовать может каждый. У него полная совместимость с оригинальным Prometheus, так что можно просто заменить один на другой и попробовать. Очень интересный продукт. Если он реально полностью совместим и в 10 раз легче, то не вижу причин его не использовать.

🔴 На замену Ingress в Kubernetes разработали новый инструмент Gateway API. Самый популярный бесплатный Ingress Controller, или один из самых популярных, Ingress Nginx не будет его поддерживать. Планов по развитию бесплатной версии нет. Вроде как там что-то новое появилось, но я не уточнял. Так что сейчас использовать бесплатный Ingress Nginx большого смысла нет.

🟡 Несмотря на наличие развитых отказоустойчивых сетевых хранилищ для данных и протоколов их доставки, локальные диски остаются вне конкуренции по производительности и отклику. Особенно при использовании современных NVMe дисков. Для Deckhouse написан свой оператор для управления локальными хранилищами с использованием технологии LVM. Для отказоустойчивости можно добавить DRBD.

Вроде всё, что можно в формате короткой заметки написать. Было интересно. Я с Kubernetes вообще не работаю, хотя и знаю его. Могу развернуть и использовать. Знаю основные сущности и принцип работы. Тут за один день получил все обновлённые знания по разным темам: какой CNI-плагин что умеет и что лучше выбрать, как cilium доставляет пакеты в обход стандартной маршрутизации linux с использованием iptables (они всё ещё актуальны в кубере), как решаются вопросы с размещением statefull приложений, из чего состоит типовой кластер Kubernetes, какие актуальны ingress контроллеры и что они умеют, и т.д.

#devops #kuber

Каждый практикующий линуксоид хотя бы раз в жизни сталкивался с OOM Killer, который просто приходит и грохает какое-нибудь приложение. Чаще всего от этого страдают СУБД, так как они обычно самые жирные по потреблению памяти.

Небольшая инструкция на тему того, что делать, если на сервере кончается память и к вам приходит OOM Killer.

1️⃣ Первым делом я бы проверил системные логи на тему работы OOM Killer. Если у вас включены текстовые логи syslog, то сделать это проще всего так:

# grep -i Killed /var/log/syslog

Если текстовых логов нет, не знаю, как быстро посмотреть. Я всегда включаю текстовые логи. Надо запускать journalctl и там через поиск искать то же самое. Я всегда забываю горячие клавиши, которые управляют результатами поиска, поэтому предпочитаю текстовые логи.

Может так получиться, что у вас уже давно время от времени прибиваются разные процессы, но заметили вы это только тогда, когда прибили то, что не умеет само подниматься.

2️⃣ Запускаем батю-скрипт на bash, который построит красивую табличку по приоритетным целям для OOM Killer:



printf 'PID\tOOM Score\tOOM Adj\tCommand\n'
while read -r pid comm; do [ -f /proc/$pid/oom_score ] && [ $(cat /proc/$pid/oom_score) != 0 ] && printf '%d\t%d\t\t%d\t%s\n' "$pid" "$(cat /proc/$pid/oom_score)" "$(cat /proc/$pid/oom_score_adj)" "$comm"; done < <(ps -e -o pid= -o comm=) | sort -k 2nr

Этот скрипт гуляет по комментариям и статьям. Я как-то заморочился и вроде бы нашёл автора, но не уверен, что это именно он. Однострочник только выглядит страшно. Если его записать с форматированием, то там простая структура. Её удобно взять за основу для формирования любых табличек с использованием ps и различных метрик. Может заморочусь и сделаю подборку из прикладных вещей, типа потребления памяти, сетевых соединений и т.д.

3️⃣ Теперь мы знаем, кого прибивает наш киллер, и видим в табличке OOM Score и OOM Adjustment. Чем выше первое значение, тем больше шансов, что процесс будет прибит. Если стоит 0, то не будет прибит никогда. Кто-то может подумать, что хорошо бы сделать нужному процессу Score 0, но это плохая идея. Если процесс течёт по памяти, то тупо виртуалка зависнет. Обычно так не делают. Второе значение - поправочный коэффициент для управления Score. Чем ниже этот коэффициент, в том числе с минусовыми значениями, тем меньше шансов, что OOM Killer убьёт нужный процесс.

Система этих очков и коэффициентов замороченная. Большого смысла в ней разбираться нет. Главное выставить приоритеты так, чтобы нужный вам процесс имел приоритет на убийство ниже остальных.

4️⃣ Прежде чем менять коэффициенты, идём в свои приложения и настраиваем в них потребление памяти, чтобы она на сервере не кончалась. Настраиваем мониторинг, если его нет. Чаще всего этого будет достаточно и трогать параметры OOM Killer не придётся.

5️⃣ Если используемые вами приложения не имеют своих настроек по потреблению памяти, то настроить их и поведение OOM Killer можно с помощью Systemd. У меня была отдельная заметка по этой теме. Там ничего сложного.

6️⃣ Когда всё настроили и хотите посмотреть, как себя поведёт система, если вдруг памяти не останется, то займите её всю чем-нибудь. Например, утилитой stress. Или просто в консоли запустите:

# python3 -c 'a="a"*1073741824; input()'

Заняли 1GB памяти. Подберите своё значение, чтобы памяти не осталось (2147483648 - 2GB, 3221225472 - 3GB и т.д.). После этого можно воспользоваться магической командой, про одну из которых я недавно писал:

# echo f > /proc/sysrq-trigger

Она принудительно вызывает OOM Killer. Пример, конечно, так себе, потому что OOM Killer скорее всего грохнет запущенную команду (хотя в моих тестах первым умер systemd). Чтобы этого избежать, надо дать ей низкий Score:

# echo -16 > /proc/$(pgrep python3)/oom_adj

Ещё раз вызываем киллера и смотрим, кого он прибьёт:

# echo f > /proc/sysrq-trigger
# grep -i Killed /var/log/syslog

У меня systemd умер первым.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#terminal #linux

Утром писал о том, что нравятся текстовые логи в том числе потому, что привык их грепать. А в journalctl искать не так удобно. После этого задумался, как удобнее всего погрепать логи systemd.

Пошёл по самому простому пути и посмотрел man:

# man journalctl

Оказывается, есть ключ -g или --grep, который делает примерно то же самое, что и утилита grep. Из всего журнала выводит строки с нужным тебе выражением. Поддерживает в том числе регулярки.

Причём этот параметр там был не всегда. Я точно знаю, что раньше не было. Зашёл на сервер с Centos 7 и проверил:

# journalctl --grep ovpn
journalctl: unrecognized option '--grep'

Ключ появился в каком-то обновлении.

На самом деле очень удобно. Я решил сделать об этом заметку и не кидать сюда другие команды journalctl, чтобы не размывать тему. Просто запомните, если не знали, что с помощью journalctl можно грепать логи. А так как он ищет по всему системному логу, который может быть очень большим, это удобнее, чем смотреть по разным файлам syslog или как-то их объединять, чтобы охватить бОльший период.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#systemd #logs

Последнее время слушал много различных интервью на тему работы и найма в IT. Не знаю, зачем мне это надо. Сам по найму работать уже не планирую. По крайней мере если жизнь не заставит. Добровольного желания нет, но кто знает, как сложится. В общем, мне это не надо, но зачем-то слушаю. Просто интересно.

Обратил внимание, что многие отмечают низкий уровень владения базой у соискателей. То есть человек, к примеру, разработчик, может не первый год писать код, но при этом не понимать, как работает служба DNS. Какой-нибудь новичок devops, по крайней мере так себя позиционирующий, может не знать, как работает маршрутизация или TLS шифрование. Сертификаты добавлять научился, а как всё это функционирует, не понимает.

Запомнился один вопрос, на котором по словам интервьюера, уже даже не помню, кого именно, заваливается чуть ли не половина кандидатов на должность devops инженера.

❓ Какой самый минимальный Dockerfile может быть?

Если бы меня спросили, мог бы растеряться, потому что создавать свои контейнеры почти не приходится. Даже и не помню, когда это делал последний раз. Обычно используешь уже готовое и только добавляешь параметры к запуску или подключаешь конфигурации. Но когда слушал, интуитивно в голове дал правильный ответ.

FROM scratch

или

FROM alpine

То есть просто использование какого-то базового образа. В таком виде это уже контейнер с минимальным объёмом Dockerfile.

# echo 'from alpine' > Dockerfile
# docker build -t docker-minimal
# docker run docker-minimal

Контейнер запустится и сразу завершится, так как он пустой, у него нет команды на выполнение. Можно добавить что-то простое для выполнения:

FROM alpine
CMD ["sh", "-c", "echo 'Hello from Container!'"]

Контейнер после запуска напишет в консоль фразу и завершится.

Написал я это всё к тому, что на рынке очень много соискателей, которые не обладают базовыми знаниями. Чтобы выделиться среди них, изучайте базу – Linux, сети, Ansible, Docker. А потом уже всё остальное. Причём вся эта база представлена очень обширно на базе бесплатных материалов.

Я некоторые базовые вещи изучал уже имея несколько лет рабочего стажа. Просто некогда было системно учиться. Уже не помню, был ли у меня Linux в институте. Администрирования вроде не было. Я вышел из института Windows администратором, а дальше всему обучился сам. Учился неправильно и несистемно, хотя пока семьи не было, было время для этого. Рекомендую его использовать с пользой. Когда появятся дети, свободного времени будет намного меньше. Лучше сразу на курсы пойти, желательно очные, и максимально сжато и ёмко изучить какую-то тему.

#совет

Давно смотрел видео на тему прохождения современных собеседований. Особого значения не придал, потому что считал, что она больше актуальна для программистов. Но вчера как-то активно начали обсуждать и в контексте нашей профессии то же самое. Я вспомнил про этот ролик.

⇨ 100% способ взломать найм / Паровозик собеседований

Сразу скажу, что автора не знаю, не слежу за ним и его деятельностью. Видел только этот ролик, который показался любопытным и запомнился.

Автор делает акцент на том, что современные собеседования превратились вещь в себе, которая оторвана от реальной работы. К собеседованиям приходится отдельно готовиться, как к экзаменам, чтобы просто попасть на работу и заниматься там совершенно другими делами, про которые на собеседованиях почти не спрашивают. Есть даже курсы для обучения прохождения собеседований.

Он предложил способ для сотрудников, как упростить свой приём на работу и побыстрее пройти собеседования без больших усилий. Нужно объединиться в группу и отправить первого человека на разведку. Он запоминает вопросы и передаёт их остальным участникам. Потом идёт второй, уточняет вопросы. Когда становится понятен набор вопросов тот, кто реально хочет туда устроиться, готовит ответы и идёт на собеседование. Вероятность его пройти сильно увеличивается.

Получается такая кооперация, когда те, кому реально не нужна работа, просто идут на разведку, а тот, кто уже хочет устроиться, идёт позже. В целом, рабочая метода. К тому же просто полезно, даже если у тебя есть работа, иногда ходить на собеседования, чтобы понимать, на что ты можешь рассчитывать в другом месте. Это помогает держать свой доход в рынке, общаться по зарплате с работодателем и не бояться увольнения.

Автор анонсирует свои чаты, где можно найти помощников для "паровозика". Я в эти группы не ходил, не знаю, что там.

Такая вот необычная идея. Видео короткое, на 11 минут, можно глянуть.

#найм

Случайно заметил, что одна из моих старых статей имеет очень большое количество просмотров. Не обращал на это внимание. Это статья про программы, которые использую в работе. Я её первый раз написал в 2018, потом в 2020 обновил. Потом переключился на Telegram канал и практически перестал актуализировать старые материалы. Очень хлопотно и трудоёмко. Всё постоянно меняется.

И вот решил обновить в очередной раз, раз уж люди её читают:

⇨ Мои программы для системного администрирования

Не хотелось удалять старое содержимое, несмотря на то, что многие описанные ранее программы уже не использую. Адаптировал, как мог, что-то удалив, а что-то добавив. Посмотрите, может вам будет интересно.

Всё, что описано в статье, публиковалось на канале в разное время. Но тут постарался всё собрать в единый материал. Из-за большого разбега по датам написания, повествование немного рваное.

#статья

В разное время у меня на канале были обзоры программ, а точнее веб сервисов, для хранения и совместного использования паролей. Решил для удобства объединить их в одну статью-подборку для публикации на сайте. Там будут ссылки на сами проекты и на их обсуждение в канале.

⇨ ТОП бесплатных программ для совместного хранения паролей

В обзоре только программы, которые можно развернуть у себя, и у которых есть бесплатная версия. Плюс, вроде бы все они open source. Сейчас список выглядит вот так:

▪️Bitwarden
▪️Vaultwarden
▪️Bearpass
▪️Psono
▪️Passbolt
▪️KeePassXC
▪️Padloc
▪️Syspass
▪️TeamPass

Все программы обозревались на канале, так что при желании можно посмотреть и заметку, и комментарии к ней. Обращаю внимание на единственную отечественную программу Bearpass. Отдельно отмечу, что Syspass давно не развивалась, а TeamPass политизирована с призывами донатить известно куда. Не стал их убирать для полноты картины, чтобы всё в одном месте было.

#password #подборка #статья

Есть общая рекомендация по использованию дисков в Linux – сначала создать раздел на диске, а потом использовать его по назначению. Даже если у вас будет один раздел на весь диск, сделайте его. То есть использовать не /dev/sdb, а сделать на нём раздел, например с помощью cfdisk /dev/sdb, а потом уже использовать /dev/sdb1.

Какой-то одной явной причины делать именно так нет, и чаще всего всё будет в порядке даже без разделов, но в некоторых ситуациях могут возникать проблемы. Я опишу некоторые из них.

Один читатель жаловался на то, что у него после перезагрузки разваливался рейд mdadm, хотя создавался без ошибок. Он выяснил, что есть версии BIOS, которые пишут какую-то информацию в начало диска и тем самым затирают метаданные mdadm. После того, как он создал разделы и собрал массив из них, он перестал разваливаться. Подозреваю, что это какая-то древняя версия BIOS, но тем не менее, случай реальный.

Ещё один случай от подписчика. У него коллега всегда использовал, как в текущей рекомендации, разделы. Как-то раз на сервере, где не им был добавлен в работу и использовался новый диск без разделов, он его по ошибке отредактировал, так как добавив другой новый диск ожидал именно его увидеть пустым, без разделов. По факту он ошибся, но если бы работающие диски были с разделами, этой ошибки бы не возникло.

В примере выше ошибся человек, но может ошибиться и программа. Некоторый софт считает диски без таблицы разделов неинициализированным или неиспользующимися и может предложить соответствующие действия с ним, которые могут привести к потере данных. Это больше относится к каким-то графическим приложениям нежели консольным. Также актуально, если диск будут куда-то переносить. Новая система может посчитать его неинициализированным.

В стародавние времена утилиты lsblk и blkid некорректно показывали информацию об идентификаторах, типах файловой системы на дисках без разделов.

Вся эта история тянется из прошлого. Как я уже сказал, сейчас возможно проблем и не будет, но тем не менее, лучше перестраховываться и создавать разделы. Я сам одно время не парился и если использовался весь диск, раздел не создавал. Потом узнал эту информацию и стал перестраховываться. Всегда создаю разделы, просто на всякий случай.

#совет #linux

Подниму одну дискуссионную тему по поводу мониторинга. Я в разное время уже упоминал, что практикую такой подход, что на какие-то важные события делаю оповещения об успешном завершении, а не только об ошибках. И другим рекомендую так делать.

Это в основном относится к бэкапам и к их проверке. Подобные оповещения страхуют от ситуаций, когда всё сломалось, а оповещения по какой-то причине не работают. Обычно утром я проверяю почту, вижу там оповещения об успехе и спокойно себя чувствую весь день. Пример, как это выглядит у меня в почте, можно посмотреть на картинке снизу. Там не всё, а только то, что по слову Success вывел с список. Писем больше, раскиданы по папкам проектов в ящике.

Такая тема хорошо работает, когда оповещений немного. Буквально 3-5, может 7. Если больше, то уже теряется смысл, так как легко что-то пропустить. У меня их уже много стало. И тут мне видятся 2 решения проблемы:

1️⃣ Убрать всё лишнее или как-то скомбинировать уведомления, чтобы их снова стало мало. Это не всегда возможно.
2️⃣ Сделать какую-то аналитику по почте. Например, собрать все такие письма в отдельный ящик и там считать количество в день или считать письма с различным содержимым. Можно как-то на дашборд графаны это вывести в красные/зелёные плитки, но опять же, теряется смысл, так как в эти дашборды никто постоянно не смотрит.

Городить аналитику по почте не хочется. Это надо какие-то костыли писать, которые будут по imap в ящик ходить. В целом, это не сказать, что сильно сложно. Тот же curl умеет ходить по imap и делать всё, что угодно. Но всё равно не очень хочется с этим связываться. Сейчас эти оповещения отправляются штатно различными программами, которые это умеют делать: Veeam, Proxmox и т.д.

Может кто-то уже решал такие задачи и есть простые идеи. Вы вообще шлёт себе успешные уведомления? Я честно говоря особо не видел у других этих тем. Обычно настраивают о неудачах, что видится логичным с точки зрения отсечения лишних отвлекающих уведомлений. Но есть определённый риск проспать проблему, с чем лично я сам сталкивался и не раз. Например, Veeam терял доступ к MSSQL и тупо не запускались его службы. Соответственно, он ничего не слал. Мониторинг службы на хосте то ли не был настроен, то ли не работал, то ли был отключен, уже не помню. Заметил случайно, что бэкапы не делаются несколько дней. А в почте был привычный молчок, как-будто всё в порядке.

#мониторинг

На канале было опубликовано много всевозможных прикладных bash скриптов, которые я сам постоянно использую. У меня они все в отдельном репозитории лежат. Решил их собрать для вашего удобства в отдельную публикацию.

▪️lynis.sh - проверка системы с помощью lynis и выгрузка результатов в Zabbix
▪️vps-audit.sh - аудит безопасности сервера
▪️dir_size.sh - определяет размер директорий и записывает результат вместе с датой замеров в файл
▪️postgres.sh - отдельные консольные команды postgresql сервера для использования в своих скриптах (pg_dump, createdb, reindexdb, vacuumdb и т.д.)
▪️copy-last.day.sh - передача с помощью rsync с одного сервера на другой бэкапы прошлого дня, более старые не трогает, забирает файлы со стороны стороннего сервера, а не исходного, где лежат файлы
▪️tg_mon.py - следит за заданными строками в лог файле и шлёт уведомления в telegram, когда их видит
▪️dates.sh - заготовка под работу с датами в скриптах
▪️copy-mysql-table.sh - копирование отдельной таблицы базы данных с одного сервера на другой
▪️wget-speedtest.sh - загружает интернет канал загрузкой данных с публичных Looking Glass
▪️findmnt.sh - проверка существования точки монтирования
▪️ps_mem.py - использование оперативной памяти программами (не процессами)
▪️check_nginx_running.sh - анализ работы веб сервера Nginx для экспорта в логи или мониторинг
▪️contry-block.sh - блокировка стран с помощью ipset и iptables
▪️mysql-stat.sh - оптимизация конфигурации MySQL сервера под имеющуюся оперативную память
🔥topdiskconsumer.sh - очень удобная статистика по занимаемому месту
▪️swap.sh - использование swap процессами
▪️trash.sh - самостоятельная реализация корзины при удалении файлов

📌 Софт для работы со скриптами:

◽️Rundeck - веб интерфейс для централизованного управления работой скриптов на серверах.
◽️Cronicle - система планирования и управления задачами серверов. Условно его можно назвать продвинутым Cron с веб интерфейсом.
◽️Task - утилита, написанная на Gо, которая умеет запускать задачи на основе конфигурации в формате yaml. Более простая и функциональная замена утилите make.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#script #подборка