К прошлому посту вы, мои дорогие подписчики, поставили кучу реакций с чуваком с ноутом, чтобы я накидал информации про настройки ansible. Там в комментариях, кстати, были крутые советы из раздела безопасности.

Так вот, ansible.cfg — это файл с различными настройками для Ansible. По умолчанию Ansible будет искать этот файл в разных местах.

Если мы храним наши ansible-плейбуки в git-репозитории и прокатываем их автоматизированно, с помощью CI-системы (Jenkins, Gitlab CI, etc), то мы можем хранить конфиг-файл прямо в корне нашего репозитория.

С помощью команды ansible-config init --disabled > ansible.cfg можно сгенерить файл со всеми настройками, но в закомментированном виде.

Конфиг описывается в ini-формате и разбит на категории, вроде [defaults]. Все эти настройки можно так же передать программе через переменные окружения, типа ANSIBLE_PIPELINING=True

Вот пример моего ansible.cfg файла:

[defaults]
host_key_checking=False
pipelining = True
strategy = free
callbacks_enabled = timer, profile_roles
forks = 40
deprecation_warnings=False
stdout_callback = yaml

[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=60s
retries=3

- host_key_checking - отвечает за проверку host keys. ⚠️ Небезопасно, используйте с осторожностью. (ну, я должен это написать)
- pipelining - ansible поднимает ssh-сессию для каждой команды. Pipelining позволяет протолкнуть сразу несколько команд через одну сессию. Это существенно может ускорить выполнение заданий, но разработчики предупреждают, что это может вызывать проблемы, если на серверах включен requiretty в /etc/sudoers.
- strategy - стратегия выполнения тасок. free позволяет выполнять таски на разных хостах асинхронно. Например у тебя есть task1, task2, task3. По умолчанию Ansible будет ждать, пока task1 завершится на всех хостах.
- callbacks_enabled - включает различные callback плагины. Например, для отображения времени выполнения тасок.
- forks - указываем максимальное количество параллельных подключений. По умолчанию - 5, что довольно мало. Увеличение этого числа сильно ускоряет выполнение плейбуков на больших инвентори, но и увеличивает нагрузку на процессор.
- deprecation_warnings - отключаем различные уведомления о deprecated функционале.
- stdout_callback = yaml - помогает лучше отформатировать вывод ошибок и дебаг-команд. Подробнее.
- Под группой [ssh_connection] содержатся различные настройки для SSH-подключений, примерно такие же какие мы можем указать в ssh-config файле.

Так же в переменных окружения я передаю:
- ANSIBLE_VAULT_PASSWORD_FILE: '/tmp/vault.pass' - путь к файлу, где лежит пароль от ansible-vault. Мы же не храним его в репозитории, а прокидываем в среду исполнения извне (например из Gitlab Variables или Infisical).
- ANSIBLE_DISPLAY_OK_HOSTS: 'False' и ANSIBLE_DISPLAY_SKIPPED_HOSTS: 'False', чтобы не выводить информацию об ОК- и SKIPPED-хостах, зачем этот мусор...

В общем и целом, использование ansible.cfg — это довольно удобный способ указать глобальные настройки при работе с репозиторием несколькими инженерами или с помощью систем автоматизации.

А какие еще полезные маст-хев настройки для Ansible вы знаете? Делитесь в комментариях! 👇

этогик | youtube | пост в блоге | #техшортики

Когда компьютер оберегает мою психику от работы. Спасибо.

(да, мак просто удалил Docker Desktop с компа)

Хэллоу, друзья! Вот и прошла первая полноценная неделя после праздников, и я спешу поделиться с вами традиционной ретроспективой о том, чем я занимался в это время. А скорее даже побомбить. Потому что задница горит нещадно.

И вот почему. Решили мы немного срезать косты (сократить затраты) на хранение бекапов: переехать из AWS s3 в Backblaze B2. Они обещают /5 стоимость по сравнению с s3.

Ты такой переделываешь свои скрипты, которые заливают дампы баз данных через s3cmd на новые эндпоинты. А потом в логах скриптов видишь странные 429 и 503 ошибки с информацией Slow Down. Воу-воу-воу, рейт-лимиты на загрузку? Ну, может я их спамлю? Да нет, вот сегодня ночью 11-гиговый бекап подзавис на 43-ей части файла (большие файлы разбиваются на небольшие части).

А еще у меня есть HBase, снапшоты таблиц которого я тоже бекаплю. И там есть таблицы по 2-9TB. Особенность в том, что эти бекапы я могу экспортировать распределенно, одновременно с большого количества машин. Вот тут тоже всё работает нестабильно. К этому еще добавляется странный способ учета количества объектов.. Но видимо я привык к s3. А поддержка что? Поддержка делает так ¯\_(ツ)_/¯.

А вторая задача: соединить три инфрастркутуры между собой. Я уже даже писал об этом, там я настраивал VPN через VPNCloud. Но работало это не очень стабильно. Сейчас вспомнил молодость и решил поковыряться с Strongswan и IPSec. Сложность в том, что нужно учитывать особенности маршрутизации трафика в Яндекс Облаке, и то что на "другой" стороне находится железный сервер, на котором крутятся виртуалки. То есть надо и с iptables поковыряться. Тут вроде бомбления меньше, просто много моментов, которые надо учитывать. Да и раньше я настраивал ipsec-и на Mikrotik-ах, а теперь надо на Ubuntu-машинах.

Но вообще там что-то странное с маршрутизацией. Вроде настраиваешь все по ихней инструкции, а когда смотришь mtr, видишь задублированный gateway-хост, причем на одном из дублей почти 100% потерь. 🤯 Если ты настраивал vpn между яндексом и внешней инфрастркутурой — напиши в комменты плз с помощью чего, и с чем столкнулся.

upd: поддержка ответила, что это нормально, и это особенность оверлей сети. и потери на этом хопе - тоже норма и особенность и не должны вызывать проблемы с маршрутизацией.

В общем вот такая неделька получилась. А у вас что интересного за первые две недели года было?

Хорошая статья про бест-практисы CI/CD, с примерами и довольно подробным описанием.

👉 https://habr.com/ru/companies/nixys/articles/841174/

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

этогик | youtube | #нашел

Мой день изнутри: работа, отдых и что хочется улучшить

Привет, друзья! Хочу поделиться тем, как усредненно проходит мой рабочий день и что хочется в этом году улучшить в расписании.

Утро
Просыпаюсь около 8 утра, но утро проходит не так продуктивно, как хотелось бы. Часто слишком много времени уходит на телефон — вроде хочется “разбудить мозг”, а в итоге только теряю время.

Прогулка с собакой, и, если успеваю, завтрак, обычно не плотный — утром аппетита нет.

Рабочий день начинается около 9 часов: проверяю почту/слак, смотрю основной дашборд мониторинга, чтобы понять всё ли хорошо с проектом. Набрасываю в Todoist план на день. Стараюсь запланировать день так, чтобы к вечеру список дел оказался пустым. (спойлер, получается редко)

В 9:30 — ежедневный синк-митинг(10-20 минут), где мы делимся с командой тем, чем занимались вчера, обсуждаем текущие задачи, есть ли блокеры, вопросы. Раз в две недели, после окончания спринта, проводится более длинная встреча — ретроспектива, где обсуждаются итоги спринта.

Дальше начинается самое продуктивное время, когда никто не отвлекает и можно сфокусированно работать над текущими задачами. Главное — не заниматься "полезной прокрастинацией" (могу рассказать, что это за мерзкая штуковина) — с этим частично помогает планирование дня.

Обед
В период между 13:30 и 15:30, в зависимости от встреч в календаре, стараюсь заняться обедом. Обычно на приготовление и употребление уходит около часа, иногда больше, особенно, если сначала надо сходить в магазин.

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

Вечер: баланс между проектами и отдыхом
Вечером все зависит от настроения и планов, но обычно получается так, что после 18 часов уже нет энергии сфокусированно работать. Здесь стараюсь заниматься полезными нерабочими делами:
- Личные проекты, например, Телеграм-канал, работа над блогом, консультации
- Может быть немного спорта: сквош, скалолазание
- Просто расслабиться: поиграть в консоль, сходить в бар, бильярд, ресторан
Ужин обычно приходится на это время.

Что хочется улучшить:
- Просыпаться раньше, и не залипать в телефон по утрам. Таким образом добавить 1-2 часа рабочего времени. Надо и ложиться спать раньше, но оно того стоит.
- Сократить время на обед. Тут помогает оптимизация: закупаться больше, заранее и более спланированно. Готовить на несколько дней вперед.
- Меньше "думать". Тут проблема в том, что несмотря на ~4 часа сфокусированной работы, ты ДУМАЕШЬ о работе намного дольше. Это сильно нагружает мозг и забирает энергию. Здесь поможет более строгое планирование, работа с календарем и принудительное закрывание крышки ноутбука.

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

этогик | youtube | #шортики

Привет! Давно не виделись.

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

Началось всё с того, что в рабочее время периодически стали срабатывать алерты о недоступности сервиса извне. Мониторинг нагрузки на процессор и оперативную память не показывал ничего необычного. Но потом взгляд упал на график сетевых интерфейсов сервера (server00), а там пики по upload доходили до 1 гигабита. Сам интерфейс на сервере, на минуточку, гигабитный. Причём это были не просто кратковременные всплески, а “полки” на 10–300 секунд.

Конечно же, нужно было выяснить, куда выгружаются такие объёмы трафика. Так как проблема возникала кратковременно и не постоянно, я добавил в crontab сбор статистики через iftop каждую минуту. Примерно так:

iftop -P -n -t -L 50 -s 50 > $LOG_DIR/iftop_log_$timestamp.txt

Так я собирал каждую минуту статистику по трафику за 50 секунд. В этих логах увидел следующую картину:

server00:14301  => 242MB
server01:51918  <= 2.28MB
......
server00:14301  => 224MB
server03:44242  <= 2.14MB

server00:14301 отправил за 50 секунд 242мб трафика на server01:51918
server00 — это проблемная машина, server01 — машина с сопутствующими сервисами. На порту 14301 запущен бекенд.

Что за порты?

Когда ОС устанавливает TCP-соединение, она открывает у себя source-port из динамического диапазона, чтобы “поймать” обратный трафик и передать его нужному приложению. Подробнее про это можно посмотреть, например, здесь.

Логика следующая: какой-то процесс на server02 инициировал TCP-соединение с порта 51918 на server00 порт 14301. Затем уже бэкенд через это соединение налил гигабит данных на динамический порт server01. И так было с серверами 01–05.

Я понял направление трафика, теперь нужно выяснить, какое приложение его запрашивает на той стороне.

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

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

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

Только устроился на работу, делаешь всё очень медленно, не понимаешь что происходит вокруг? С такой проблемой часто приходят ко мне в личку.

👉 Спойлер: это нормально.

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

Почему тебя не уволят завтра?
Компании невыгодно брать людей просто так. Найм — дорогой процесс:
- За тебя уже заплатили: работой рекрутеров, рекрутингового агенства, АТС-ок, временем сотрудников на собеседования и онбординги
- Работодатель понимает, что ты не будешь приносить пользу сразу. Первые месяцы — это адаптация.
- Никто не ждёт, что ты за неделю разберёшься во всём и будешь на уровне сотрудников, которые год работают.

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

Ты не медленный — ты новичок, а это не одно и то же. Через месяц-два ты будешь работать быстрее и увереннее. Главное — не стесняться задавать вопросы и не загоняться, если что-то не получается.

Небольшие советы:
- Декомпозируй задачу: иногда задача может ставиться очень абстрактно, и ты даже не знаешь с какого угла к ней подступиться. Не хватайся за все подряд и разбей задачу на более мелкие и понятные участки. Если не понятно куда двигаться — уточняй у коллег. Хуже будет только если ты просидишь до дедлайна без какого либо результата: "Ой, ну я искал гуглил читал, но так и не получилось".
- Вытекает из прошлого — доводи задачи до результата. Даже если что-то не успел, подытожь то, что готово, сделай документацию, опиши что не получилось и почему. Прими это к сведению при дальнейшем планировании.
- Не перерабатывай: очевидное желание, поработать ночью или на выходных, если не успеваешь в дедлайны. Это плохо: тебе не заплатят, это не оценят, менталочка пострадает. Лучше обсудить это с руководством, декомпозировать задачу и перепланировать. Это нормальная культура сейчас, время бесплатных переработок уже давно кончилось.
- Еще раз: разговаривай. Спрашивай советов и проси помощи у коллег.

этогик | youtube | #шортики

Что там случилось у Яндекса 30 марта?

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

Подробности об инциденте можно почитать тут.

У Яндекс Облака есть 3 зоны доступности, они же регионы, они же дата-центры — мы можем выбирать в каких дата-центрах создавать наши ресурсы: виртуальные машины, кубер-кластеры и тому подобное.

И вот в воскресенье полностью отключается электричество в одном из дата-центров. Всё сетевое оборудование, серверы, дисковые хранилища — отключены. Только спустя 8 часов первые виртуальные машины начали включаться.

Этот инцидент повлиял на работу большого количества компания, которые, видимо, так или иначе были завязаны на этот дата-центр Яндекс Облака.

Какие инструменты и подходы предлагаются облачными провайдерами и могут быть использованы, чтобы избежать даунтаймов в случае выхода из строя ЦЕЛОГО ДАТА-ЦЕНТРА?

Этот спич не о том, что НУЖНО использовать, а о том какие варианты есть и что может рекомендоваться. Дальше нужно думать, потому что разные подходы используются в разных ситуациях.

Основное правило: не хранить все яйца в одной корзине. Вылет одного дата-центра не должен ронять продакшен.

Мы можем задублировать наше приложение на несколько машин в разных дата-центрах, если позволяет архитектура. Затем используем балансировщики.

Чаще они - балансировщики - есть двух типов: network (NLB)— работают обычно на 4 уровне OSI, и application (ALB) — на 7 уровне. Мы нацеливаем балансировщик на группу наших виртуальных машин и он сам проверяет доступность целевых сервисов. Если сервис недоступен, машина автоматически (и очень быстро) выходит из ротации.

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

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

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

А что там с оркестрацией контейнеров? Конечно же Кубер. Managed-сервисы у облачных провайдеров снимают с нас огромное количество головной боли: хочешь тебе — control-plane в трех регионах сразу, хочешь автоматическое создание дополнительных воркер-нод при увеличении нагрузки. Это не учитывая, что Кубер сам по себе следит за состоянием нод и переносит нагрузку на рабочие.

Касательно infrastructure-as-code подхода: здорово бы иметь возможность восстановить инфраструктуру без особых ручных действий. Хотя бы без ручного ввода команд на серверах. Чтобы вот пустую машину превратить в продакшен-сервис после запуска терраформа, плейбука и деплой-пайплайна.

Ситуация еще хуже: пожар в дата-центре. Редкость, но бывает. Вот история раз, вот история два.
Данные безвозвратно утеряны. Чтобы избежать стоит хранить дополнительные бекапы в независимом от облачного провайдера месте. Например, у другого провайдера.

Это первое, что пришло в голову, о чем захотелось рассказать. Делитесь своим мнениям в комментариях про подходы, и про инцидент в целом. Только не пишите, мол "олимпиадники опять не справились".

В общем очень жду пост-мортема по этому воскресному инциденту, чтобы почитать о причинах.

upd: пост-мортем опубликован 👉 https://status.yandex.cloud/ru/incidents/1129

этогик | youtube | #техшортики

Когда создал тикет о замене вылетевшего диска, а в ответ:

We have cleaned the drive connector and all drives seem to be working

Как я использую Ansible для управления инфраструктурой?

Хотел кратко рассказать именно про свой опыт, который уже несколько лет проверяется на инфрастркутуре в 80+ серверов и виртуалок.

Начал писать пост для телеги и понял, что немного (много) вываливается за рамки поста. Решил загрузить в блог (помните, есть такой у меня), там лучше читается.

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

Будет супер-интересно почитать о том, как вы управляете вашей инфрастркутурой — речь именно про настройку серверов и виртуалок, установку софта, конфигурирование сервисов, настройку пользователей и так далее. Welcome в комментарии!

👉 https://etogeek.dev/posts/ansible-iac/

этогик | youtube | #техшортики #блог

Я прямо нутром чую, что этот пост будет из разряда "а ты че, не знал?". Но, думаю, раз я не знал, то много кто еще тоже.

Нашел одну тулзу для удобного управления локальным файлом /etc/hosts.

В общем, в последнее время мне довольно часто надо модифицировать /etc/hosts, чтобы подменять там доменные записи или создавать новые. И меня дико задолбало делать это в терминале.

Оказалось, что есть софтина, в которой можно насоздавать отдельных блоков с хостами, а потом "включать" их при необходимости в основной hosts-файл.

👉 https://github.com/oldj/SwitchHosts

Там есть еще всякие фичи, типа интеграций для Raycast и Alfred, или например импорт hosts-записей c URL.

Заодно напомню про список софта, которым я пользуюсь:
👉 Ссылка на Гитхаб

этогик | youtube | #софт

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

Был проект состоящий из десятка systemd-сервисов, стал проект состоящий из десятка контейнеров.

В таких задачах нужно много всего переработать: Dockerfile-ы написать оптимальные, compose для локальной разработки запилить, nginx-конфиги переделать, придумать что делать с файлами, которые не хранятся в репе (ну такой statefull), пайплайны переписать... а потом в процессе еще натыкаешься на легаси-особенности, про которые вообще никто из текущей команды не в курсе. Зато в проекте начинаешь шарить.

Ах да, мониторинги еще на все повесить. Dev/Prod окружения. Конфигурация приложения. Сбор логов контейнеров. Healthcheck-и. Наверное что-то упустил.

Получается, что вроде как типичная и максимально стереотипная девупсерская задача "контейнеризировать проект" на самом деле включает в себя огромную комплексную работу. Потому что простой COPY . . и CMD python3 main.py в реальном мире встречается крайне редко. Особенно если при изначальном проектировании проекта никто не думал про контейнеры и 12-факторов.

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

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

Привет! В ответ на прошлый пост мне в чате задали классный вопрос — как вообще девопс(инженер) взаимодействует с командой разработкой, и нужно ли лезть в код?

Хочу немного поделиться мыслями на эту тему.

Кажется, моя любимая фраза, когда дела касается объяснения каких-то процессов и ответа на вопросы "как принято", "как обычно делается" — это it depends... (зависит от)

И действительно так. Большинство того, что мы читаем в книгах и чему учимся на курсах — это "сферический девопс в вакууме", некое усредненное состояние индустрии.

В целом — везде используют какой-то инструмент для CI/CD, везде будет какой-то мониторинг, управление инфраструктурой и так далее.
Но уже посмотрев на ситуацию глубже на месте, будет видно, что вот здесь 10 лет назад автоматизацию написали на Bash, а в этой компании одновременно несколько систем мониторинга, в третьей — релизы автоматически выкатываются, а в четвертой нужно ждать аппрува от Васи Петрова. И тому подобное. Везде. Всё. По-разному.

Возвращаясь к вопросу из комментария про взаимодействие с командой. Я бы сказал, что тут зависит от того насколько коллеги вовлечены в продукт и вообще в изменения. Бывают люди, которые работают как на заводе — пришел, сделал задачу из Жиры, которую описал начальник, ушел. А бывает наоборот — готовы помочь, сковырнуть говна легаси немного, посоздавать задач в беклог, поменять приоритеты. Учитывая, что я отношу себя ко вторым, мне проще с такими людьми взаимодействовать. Благо, у нас в команде такие есть.

В моем случае я правил код, где понимал, как. Иногда спрашивал совета у ребят, но в целом делал все сам. Обычно, если могу сделать сам — делаю. Зачем лишний раз тормозить процесс? А мог бы перекинуть таску на коллегу и заблокировать процесс. Зато "мяч не на моей стороне". Не, это не мой вариант.

Иронично, что проблемы возникали в основном во фронтенде, там со структурой файлов и директорий был швах, конечно.

А что касаемо кодовой базы — структуру репозитория нужно понимать, как минимум если ты отвечаешь за автоматизацию релизов (CI/CD). Если тебе нужно писать Dockerfile - тебе как минимум нужно понимать, где что в репозитории лежит. А если это еще и монорепа на несколько сервисов...

В ситуации с отдельными репозиториями под каждый проект и сервис хорошей идеей будет создание шаблонов. Чтобы микросервисы были максимально похожи друг на друга: одинаковые фреймворки, структура файлов и директорий, универсальный пайплайн, конфигурация сервиса, мониторинг через service discovery...

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

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

И вот в этот момент и появляется самый настоящий DevOps — не роль, не человек, а культура совместной ответственности за продукт.

этогик | youtube

На прошлой неделе добавлял в CI-пайплайн новые этапы и решил заодно поразбираться немного с кэшированием в GitLab CI.

Зачем оно в целом нужно? Например у нас при создании Merge Request запускается этап, который запускает python-тесты. Или, например, проверяет соберется ли фронтенд. И в этих этапах мы ставим какие-то зависимости. Такие пайплайны запускаются на каждый чих коммит, и зачем нам тратить на это время, трафик, ресурсы? Давай закэшируем зависимости между пайплайнами.

Для этого в гитлабцах мы используем cache:. Нам нужно указать, что будет являться "ключом" кэша. В нашем случае неплохой идеей (на мой текущий взгляд) будет указание самого файла в качестве ключа. То есть, если файл с зависимостями изменился — кэш инвалидировался. До сих пор считаем, что кэш действителен.

Вот пример для Python (это в случае pip. Когда переедем на uv, напишу дополнительно):

variables:
  PIP_CACHE_DIR: ".cache/pip/"
cache:
  key:
    files:
      - requirements.txt
  paths:
    - .cache/pip

А вот для npm:

cache:
  key:
    files:
      - package-lock.json
  paths:
    - ./node_modules/

Ну и в общем куча примеров как всегда есть в официальной доке.

Особенности, которые стоит держать в голове:

- Где будет храниться этот кэш?
В моем случае я использую self-hosted Gitlab Runner-ы, которые запускаются в контейнерах внутри Swarm. То есть я не знаю заранее на какой машине запустится сборочный контейнер. Следовательно кэш должен быть доступен с каждой машины.

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

Директория для кэша монтируется в каждый контейнер, это указывается в конфиге раннера:

[runners.docker]
volumes = ["/var/lib/gitlab-runner/cache:/cache"]

- Ошибка при использовании кэша в npm.
Кэш собрали в одном сборочном контейнере. Подключили в другой — ругается

The local cache artifact in was not been generated on this machine

Ну конечно, хостнейм у каждого контейнера разный.
Добавил переменную NX_REJECT_UNKNOWN_LOCAL_CACHE: 0.

- Использование локальных прокси для пакетных менеджеров.
Очевидно, что скачивать зависимости из локальной сети быстрее, чем скачивать их из интернета. Вон, DockerHub вообще лимиты имеет.
Я дополнительно создал в Nexus, который развернут рядом, прокси-репозитории под используемые менеджеры и добавил их в CI-пайплайн:
Для Python (pip):

- pip install --index-url https://nexus.corp.com/repository/python/simple/ -r requirements.txt

npm:

- npm config set registry https://nexus.corp.com/repository/npm-proxy/

yarn:

- npm config set registry https://nexus.corp.com/repository/npm-proxy/
- echo 'yarn-offline-mirror ".yarn-cache/"' >> .yarnrc
- echo 'yarn-offline-mirror-pruning true' >> .yarnrc

- Cleanup.
Нужно настроить какую-нибудь ротацию кэша, а то так забудешь, а потом no space left.
Я сделал find /var/lib/gitlab-runner/cache/ -type f -mtime +7 -delete, но пока не уверен, что оно работает как надо.

В общем, если пайплайны запускается часто, а зависимости меняются редко - кэш и локальные прокси прям must have.

этогик | youtube | #техшортики

Deckhouse User Community meetup #2
21 августа | Москва

«Флант» приглашает на второй Deckhouse User Community meetup. Три доклада от практиков:

→ управление узлами кластера на всём их жизненном цикле с командой Deckhouse Core;
→ построение платформы обучения K8s на DKP CE с коллегами из КРОКа;
→ автоматизация архитектурного контроля и подход Architecture as Code с экспертами «ДОМ.РФ Технологии».

Регистрируйтесь, если интересны реальные кейсы работы с Kubernetes-платформами.

Одной из недавних задач, которую решал был перенос базы данных PostgreSQL на другой хост. Ну и одновременно с обновлением версии.

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

А что делать, чтобы поменьше лежать? Для этого правильной практикой является настройка логической репликации. Это когда на хосте источнике настраивается "публикация", а на целевом хосте настраивается "подписка".
Затем подписчик начинает тянуть транзакции из публикации: INSERT, UPDATE, DELETE, TRUNCATE. Сначала переливает уже имеющиеся данные(это может быть долго), затем в реальном времени - свежие изменения. Добавилась новая строка — подписчик перетянет ее к себе.

В идеальном сценарии переезд выглядит так:
- заранее настраиваем репликацию и ждем синхронизации
- убеждаемся, что базы синхронны (SELECT * FROM pg_stat_subscription;)
- выключаем нагрузку на основную базу
- ждем секунды, чтобы последние данные отсинхронились на целевой хост
- снимаем дамп sequences (порядковые номера автоинкрементных полей, например id), ресторим его на целевую базу
- переключаем приложение на новую базу
Даунтайм сокращается до считанных минут, а если все заскриптовать - даже секунд.

Уже не раз такое делал, но вот сейчас наткнулся на особенность, что репликация по умолчанию не может передавать обновления строк для таблиц, в которых нет Primary Key.

То есть первый раз оно перельет данные, а вот UPDATE/DELETE новые не сможет. Ну потому что Постгрес типа умный, он не будет передавать строку целиком, а попытается обновить конкретные поля. А тут нет уникального идентификатора строки и привязаться не к чему.

Для таких таблиц нужно включать режим IDENTITY FULL: ALTER TABLE my_table REPLICA IDENTITY FULL;. Данных будет передаваться больше, но тогда обходится проблема таблиц без PK. Но репликацию надо запускать сначала, потому что после включения FULL полетят только свежие данные

Век живи - век учись. Вот хороший гайд для настройки логической репликации: ссылка.

этогик | youtube | #техшортики

Время пятничной истории.

Есть у меня в инфраструктуре кластер Hadoop на 50 серверов. Управляется он централизованно с мастер-сервера: команды для запуска вводятся на одном сервере, затем приложение смотрит в файл slaves, в котором перечислены все остальные машины, ходит по ним и запускает.

И вот я решил обновить Hadoop до актуальной версии. С переходом через мажорную версию: 2.x.x -> 3.x.x. Увеличение мажорной версии обычно означает некие очень крупные изменения, зачастую ломающие обратную совместимость. Конечно же мы наткнулись на изменения портов по которым общаются сервисы, побомбили с нескольких новых параметров, но в целом запустили кластер без особых сложностей.

Только вот сервисы на зависимых машинах перестали запускаться автоматически, пришлось вручную (скриптом, конечно, но самодельным) запускать. Пара часов технического траблшутинга не дала особого результата, зато результат показал поиск по changelog-у Hadoop-а.

Разработчики в 3.0.0 переименовали файл slaves в файл workers. Обратной совместимости, то есть чтения дополнительного старого файла, никто не оставил.

Вот так проблемы при обновлениях могут подкрадываться с неожиданной стороны. Мораль: читайте release notes (ага, конечно...)

этогик | youtube | #техшортики