этогик // DevOps, Productivity, Career

🎉 Сегодня обновился до версии 0.3.2. Еще в прошлой версии микросервис "спина" начал пятисотить. Говорят, фиксится патчем "спорт". Надо будет проверить.

День рождения — это не просто дата, а повод для рефлексии. Мыслей много: вспоминаешь, чего достиг. Планируешь, что делать дальше, и думаешь о том, что могло бы быть иначе.

Но хватит про лирику. Давайте о том, что важно.

В какой-то момент, сидя на работе, ты можешь подумать: "Пора расти дальше. А что делать-то?" Какое направление выбрать для развития? Что учить? Как практиковаться? Идти на курсы?

Первое, что нужно сделать, — самое простое и правильное: пообщаться с руководством. Да, просто спроси у начальника, тимлида или опытного коллеги: "Что мне сделать, чтобы продвинуться по карьере?".

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

И знаете что? Буквально с этого дня мне начали давать материалы для изучения. Так я и переключился на новый трек развития. Старт был жёсткий, по-бразильски, но увлекательный. Куча настроенных свитчей, командировки по России. Не знаю, где был бы сейчас, если бы тогда выбрал другой путь.

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

А вот если на работе коллегам глубоко наплевать на тебя, то придется брать всё в свои руки:
- Анализировать рынок и свои интересы. Какие навыки востребованы? Какие из них тебе интересны?
- Найти ментора, который поможет тебе с выбором направления для развития, даст "волшебный пинок".
- Учиться: курсы, вебинары, конференции — сейчас доступ к информации огромен. Главное — практиковаться.
- Нетворкинг и коммьюнити помогает "вариться в одном котле" с единомышленниками.

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

Всё, убежал тестить баги новой версии.

Бу, испугались? Не бойтесь, это же я. Боролся с творческим кризисом и высокой загрузкой.

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

Ребята на бекенде хотят переезжать поисковым движком с Solr на Elasticsearch. Вот, готовил для них тестовые кластеры. Деплой и настройку, конечно же, сделал с помощью любимого Ansible. Кластеры по пять нод: три с ролями master+data, две — data.
По итогу поисковый индекс будет собираться на одном "сборочном" кластере, потом в виде снапшотов сохраняться на hdfs (распределенная файловая система), а затем уже деплоиться на дев и прод окружения.

Еще настраивал мониторинг SSL-сертификатов с помощью VictoriaMetrics, blackbox exporter и alertmanager. Работать-то оно работает. Я это делаю в рамках попыток отказаться от Zabbix, чтобы не дублировать инструменты. И как будто алертинг выглядит как-то более топорно в alertmanager-е. Он еще и выплевывает алерты заново при рестарте сервиса.

Так же сейчас занимаюсь переездом двух больших серверов от одного хостера к другому. Причины — меньше денег за бóльшие ресурсы, территориальная близость к другим серверам.
А при переезде выявляется много моментов, которые не описаны в Ansible (подход infrastructure as code), и бэклог пополняется задачками. Цель-то у IaaC подхода — целевое состояние системы описано в виде кода, и оно легко воспроизводимо. Грубо говоря: пустой сервер превращается в рабочий по нажатию одной кнопки.

А у вас что интересного происходило за это время?
Кто-нибудь работу поменял? Может быть повысил свой грейд? Изучил какой-нибудь классный инструмент? Грохнул прод-базу? Сделал rm -rf /?
Поделитесь в комментариях!

#ретро

Привет! В канале за последнее время прибавилось огромное количество подписчиков — привет вам всем, спасибо, что читаете, и спасибо за вашу поддержку 👯‍♂️

Решил собрать небольшой дайджест крутых и полезных постов из этого канала.
Старички, ставьте чувака с ноутом 👨‍💻, если помните эти посты!

🟢 Как работают процессы в Linux
🟢 Как работает оперативная память и swap
🟢 Out of Memory (OOM)
🟢 SLI, SLO и SLA — в чем разница?
🟢 Как подставить переменные в файл в пайплайне?

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

Из крупного за последнее время: поднял self-hosted Gitlab, куда мы переехали из GitHub. Думал еще насчет Gitea как более легким сервисом для хранения кода, но Gitlab является более перспективным, с возможностью в будущем использовать встроенные инструменты (CI к примеру).

Какие подводные камни есть вообще у бесплатного Гитлаба?
- В Merge Request нельзя поставить несколько reviewers. Это платная фича.
- Нет блокировки Merge Request, если нет Approve.
- Dependabot — чисто Microsoft-овский инструмент, эндемик Гитхаба

Это так, что первое вспомнилось. А еще Гитлаб идет как bundle, еще называется Omnibus — единый инстанс, который содержит в себе кучу других сервисов, например PostgreSQL, Redis, Gitaly... И кушает это добро довольно много ресурсов. Например после импорта нескольких репозиториев без особой нагрузки сервис жрал около 8Gb оперативки и пару vCPU. Путем применения несложных рекомендаций удалось снизить использование памяти до 3Gb.

Гитлаб я разворачивал на отдельной виртуальной машине. И хорошей практикой считается использовать git через SSH. 22 порт на виртуалке занят под SSHd, gitlab тоже хочет 22-ой использовать. Что делать?
Ну варианта два: либо вешать git на другой порт, либо ssh на другой порт. В первом случае нужно пользователям прописывать другой порт в git, в другом - менять настройки подключения к серверу. Выбрал второй.

Благо в настройках можно указать отдельное доменное имя для ssh-репозиториев, так как входная точка через https у меня — это Nginx reverse proxy перед виртуальной машиной:

external_url 'https://gitlab.company.tld' <- на Nginx
gitlab_rails['gitlab_ssh_host'] = 'gitlab.tld' <- на виртуалку

Импорт из Github прошел вполне успешно: удалось в автоматизированном режиме перетащить все PR-ы, коммиты, Issues и другую мишуру. Было только странно, как маленький репозиторий (1к коммитов, штук 300 ПРов) импортился 5 часов, а большой репозиторий улетел за 45 минут. Кстати, был у меня старенький постик Как перенести git-репозиторий в другое хранилище.

Github Actions мы не использовали(почти), поэтому также нужно было перенастроить все Jenkins-джобы, чтобы они смотрели на новые репозитории. Тут проблем особых не было — все джобы описаны в одном месте в виде кода (jenkins-job-builder).

Вот так и переехали в Gitlab. А чем вы занимались в последние дни на работе? Велкам в комменты.

Ну, и хорошей пятницы!

Декомпозиция — очень важный навык, который отличает новичка, от опытного специалиста. Его можно еще описать известной фразой: «Глаза боятся — руки делают».

У тебя бывало, что ты не знаешь как подступиться к большой задаче? Что от объема предстоящей работы опускаются руки? Это совершенно нормально.

Нужно просто каждый вечер принимать простой советский...

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

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

Почему?
Наш мозг действительно боится сложных задач. Зачем их делать, если можно заняться чем-то маленьким и простым, или, что еще легче — залипнуть в Reels?

Значит нужно помочь самим себе — снизить сопротивление, чтобы было проще приступать к задачам.

Атомарная задача — это задача, которую можно начать делать прямо сейчас и сделать за один подход. Мы ее записываем начиная с инфинитива (Сделать, Настроить, Описать, Сходить), и дальше кратко и понятно описываем следующее действие (Создать пользователя vasya на сервере). Так мозгу тоже будет проще погрузиться в контекст и не отвлекаться на вспоминание.
(про это рассказывает Тим Урбан, а в СНГ это популяризировал Максим Дорофеев)

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

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

Так что если задача кажется слишком большой — помни, что любое дело можно сделать, если разбить его на простые и понятные шаги.

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

Так, ну что. Всем привет!

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

А вот заметили ли вы ошибку на этой схеме? Пишите в комментариях, что с ней не так.

upd: ответ в комментах

Компьютерные сети — это очень частый пункт во многих вакансиях, будь то разработчик, инженер поддержки, тестировщик. Сети знать нужно — в современном IT всё взаимодействует через сеть: HTTP, ноды в кластере Kubernetes, контейнеры на одном или разных хостах, мобильные приложения.

В этом видео я рассказываю про основные базовые моменты о компьютерных сетях: модель OSI/ISO и стек TCP/IP, IP и MAC адресы, NAT, DNS.

Желаю приятного просмотра, и не забудьте подписаться!

🎞 Ссылка на Youtube-видео (можно смело на x1.5)

этогик | youtube | #видео

Привет! На днях разворачивал self-hosted Gitlab и нужно было настроить запуск Gitlab Runner в Swarm-кластере. Ну, чтобы под каждый этап пайплайна поднимался динамический контейнер.

Полноценной инструкции не нашел, к тому же Gitlab недавно поменяли Registration Token на Authentication Token. В общем, собрал все в одну инструкцию и выложил на свой сайт, чтобы оно проиндексировалось поисковиками :)

👉 https://etogeek.dev/posts/gitlab-runner-swarm-cluster/

Комментарии приветствуются!

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

Привет! 👋
Продолжаю прошлый пост, где мы остановились на объединении сети трех проектов в одну. А дальше нужно было настроить связность DNS. Вот какая ситуация была:

- В первом проекте есть свой DNS сервер, который "держит" одну приватную зону (несуществующая в паблике). Все остальные запросы форвардятся на DNS-ы хостера.

- В двух других проектах DNS работает на уровне облачного ресурса. Там тоже есть свои приватные зоны. Например у Яндекс Облака облачный DNS-сервер всегда живет на ip-адресе .2 внутри подсети.

Что делаю:
- В первом проекте стоит Bind9, там настраиваю forwarding запросов к определенной зоне через другой DNS-сервер:

zone "coolproject" {
    type forward;
    forward only;
    forwarders { 10.131.0.2; };
};

Тут у меня возникли ошибки связанные с проверкой DNSSEC, поэтому при доверии между серверами можно добавить: validate-except {"coolproject";};

- На других проектах я пошел прямо по инструкции от Яндекса:
Там нужно поднять CoreDNS на одной из машин, аналогично настроить forwarding и прописать новый DNS-сервер в настройки DHCP внутренней сети.

  bestproject {
    forward . 10.40.10.1 10.40.10.2
    cache 30
  }

  . {
    forward . 10.131.0.2
    cache 30
  }

Не стоит надеяться на стабильность облака, отклоняться от инструкции и создавать только одну виртуалку под DNS. Делайте две через балансировщик как и советуют в инструкции.

Чтобы не гонять все DNS запросы через VPN, я настраиваю Split-DNS. Для этого у меня уже есть инструкция под Open VPN + Tunnelblick. Добавляю туда новые зоны и раздаю юзерам новый профиль.

Вот так вот получилось.

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

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

Сейчас у меня начался большой проект по объединению инфраструктур трех проектов в одну. Я уже упоминал это, вот могу рассказать подробности.
Есть три проекта, которые хостятся в разных местах, используют разные стеки, разные инструменты CI/CD, тесты, линтеры. В связи с появившейся необходимостью разработчикам переключаться между разными проектами появилась потребность в упрощении и приведении к общему виду всей этой истории.

Сейчас работа, конечно, больше админская, а не девупсерская. Начинаю с общего сетевого контура, VPN и DNS. Там в одном месте — 70 bare-metal серверов, в другом — виртуалки в AWS, в третьем — виртуалки в Яндексе.

Большой плюс, что хостер железных серверов позволяет объединить их в vSwitch и добавить VLAN между ними. Собственно, закидываем все машины в один влан, рисуем таблицу ip-адресов, настраиваем их (Ansible-ом, конечно), добавляем в нужных местах разрешающие правила в iptables и внутренняя сетка есть. (не забываем про least privilege подход)

У облачных провайдеров приватная сеть между виртуалками — это само собой разумеющееся удовольствие, поэтому надо придумать как объединить эти сети между собой. Ну, надо поднять VPN-туннельчики и настроить маршрутизацию. Солидный вариант — StrongSwan и ipsec. Через чур солидный. Иду в сторону VpnCloud, с ним уже работал, настраивается простым yml-иком, шифрует, поддерживает mesh.

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

Окей, впн-ноды знают про существование "новых" подсетей, а как научить остальные машины? С облачными инстансами проще — у ресурса Virtual Private Cloud (облачные сети) есть функционал Routing Tables (таблицы маршрутизации). В них указываю, что трафик до определенных подсетей должен ходить через местную впн-ноду. PROFIT.

А вот на bare-metal серверах у каждого свой "шлюз по умолчанию" (он же default gateway), там нужно прописать маршруты прямо в netplan. Ansible в зубы, и обновляю конфиг.

Довольно длинный пост выходит, и это я еще опускаю проблемы с пересечением адресаций подсетей в разных проектах, и с тем, что я узнал про routing tables в VPC вообще не сразу. А я про DNS и VPN не рассказал.
Если интересно, то напишу следующим постом 👋

А чем вы занимались в последние пару недель?

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

Пум-пум-пум, новый видос подъехал!

Рассказываю про подход Infrastructure as Code и в общем про GitOps.

Приятного просмотра! Можно смело на х1.5

👉 https://youtu.be/UtthkktV_ck

этогик | youtube | #видео

Привет! Давно не постил ничего, как будто даже пропал! Рассказываю что происходило за последнее время.

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

Затем я начал писать тексты для новых видео, а то что это я не снимаю ничего. Даже хотел в прошлую субботу отснять видео! И тут бах - в субботу ночью ломается кондиционер, а за окном днем +40°. Это смэрт, температура в квартире в течение ближайших часов поднимается до ~32° и единственное о чем можешь думать — как перестать потеть и чтобы собака не померла. Кондей нам починили только в среду, поэтому видос буду снимать на этих выходных.

Рабочие задачи начались с исследования self-hosted Mattermost как замены Slack-у. Много просмотренных записей конференций, о том как других компании его готовят; тестирование импорта истории из Slack. Вопросов много - объединения воркспейсов, аутентификация пользователей, пуш-уведомления, проивзодительность..

Также прикрутил использование Infisical для хранения всяких токенов и паролей для Ansible-плейбуков, которые у меня автоматически запускаются.

Еще занимаюсь объединением серверов и виртуалок в разных инфраструктурах (дата-центр с bare-metal серверами, разные облачные провайдеры) в единый сетевой контур. Это в рамках довольно большого проекта по объединению инфраструктур нескольких проектов, создании некой общей платформы, чтобы разработчикам не приходилось изучать заново как сделано что-то в соседнем проекте - просто берешь и погроммируешь, а пайплайны похожие все и запускаются одинаково.

А в мире, вон, авиакомпании и крупнейшие энтерпрайзы "встают", потому что антивирус CrowdStrike выпустил свежий патч, который вызывает BSOD(синий экран смерти) на Windows-компьютерах

А у вас что происходило за последние недели?

#ретро

Интересный доклад про SpringBoot и DevOps. Особенно мне была интересна часть про оптимизацию сборки контейнеров. SpringBoot это популярный фреймворк для Java.

Тут предлагается использовать встроенный в фреймфорк механизм слоев для более тонкого кэширования содержимого jar-файла.

Ну и всякое другое, например про buildpacks, проперти springboot, миграции.

👉 https://www.youtube.com/watch?v=QrH4UFA8Rlw

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

Как Витька Чеснок вез Леху Штыря положил сеть компании

В бытность мою молодую, когда я управлял сетью вместе с моим старшим, во всех смыслах, товарищем, была у нас такая тема — держать на столе свой свитч (коммутатор). В нем были настроены порты в разные VLAN, чтобы можно было быстро попасть в нужный, просто переткнув свой ПК в другой порт.
VLAN — это когда коммутатор изолирует кадры на втором уровне TCP/IP друг от друга на основе определенной метки, которая указывается в каждом кадре. От VLAN-а зависела IP-подсеть на DHCP-сервере и, соответственно, настройки firewall на сетевом оборудовании.

И вот однажды мы переезжали нашим отделом из одного кабинета в другой. Я уже подрубил свой комп, сижу работаю. Витя всё ковыряется с проводами. Кто-то шарящий уже может догадаться, что произошло дальше. А дальше начинает лагать сеть. О том, что это “не только у меня” я понял по прибежавшему коллеге из отдела техподдержки. Позвонить он мне не мог, сеть же лагает. Да, частенько они прибегали раньше алертов мониторинга.

Я был в процессе поиска неисправностей, когда все, внезапно, заработало снова. Виктор в этот момент решил переключить свой удлинитель в другую 220-розетку. Через пару минут лаги начались снова.

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

«Дядь Вить, это твоя розетка».

По итогу выяснилось, что один из портов на его свитче — trunk на все vlan-ы, он подключался в сетевую розетку — был зеркалирован на другой порт, в который Витя подключил свой ПК. Грубо говоря, один порт, через который могли проходить все VLAN-ы, дублировался на другой. А в случае, когда MAC-адреса пересекались, сеть начинала бесконечно пересылать данные между этими портами, вызывая "шторм" кадров. Когда Витя переключал удлинитель, это временно разрывало петлю, но как только питание восстанавливалось, всё начиналось заново.

Мораль: иногда самые большие проблемы возникают из-за самых маленьких ошибок. Зачастую человеческих. Не даром говорят, что в модели OSI/ISO есть восьмой уровень — пользователь.

p.s. STP не сработал, почему не помню. А STP — это протокол специально для защиты от петель на втором уровне.

А кто знает, какой механизм используется для защиты от петель (бесконечно путешествующих по кругу пакетов) на третьем уровне?

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

У Яндекс Облака (1 июня) в новом дата-центре отвечающим за зону доступности ru-central1-d произошел инцидент, связанный с электропитанием.

Для клиентов это выглядело как перезагрузка части виртуальных машин (Compute Cloud). Также наблюдалась недоступность сетевых дисков, используемых в этих виртуальных машинах. К тому же, перезагрузка виртуалок выполнялась неприлично долго.

Инцидент длился около полутора часов до восстановления основной работы и около 7 часов суммарно. По информации Яндекс Облака, это было связано с электропитанием в дата-центре.

Сегодня Яндекс Облако опубликовало отчет об инциденте:

👉 Отчет об инциденте

Интересное чтиво, рекомендую.

Мораль: нужно делать мультизональное резервирование нагрузки. Простыми словами, создавать реплики наших сервисов в двух и более зонах доступности (дата-центрах). В таком случае выход из строя одного ДЦ не приведет к отказу сервиса.

этогик | youtube | #инциденты