Привет! ?
Продолжаю прошлый пост, где мы остановились на объединении сети трех проектов в одну. А дальше нужно было настроить связность 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 | #техшортики

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

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

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

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

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

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

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

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

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

В бытность мою молодую, когда я управлял сетью вместе с моим старшим, во всех смыслах, товарищем, была у нас такая тема — держать на столе свой свитч (коммутатор). В нем были настроены порты в разные 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 | #инциденты

? Приветосы! Что по задачам за последнее время?

Основная движуха в этом спринте была связана с написанием плана общей платформы.

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

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

В итоге у меня получился довольно обширный роадмап на приличное количество человеко-часов. И даже интересно. Меня вообще реально драйвит то, что я делаю на работе — поддержка и оптимизация вот этого “живого организма”. И я пишу это даже без клоунского смайлика.

География рулит! У нас есть джоба, которая выкачивает бекап продовой базы данных, обезличивает его и раскатывает на дев-окружение. Сократил время выполнения джобы на 40% просто переместив s3-бакет географически ближе к серверам.

Еще поковырялся с запуском Python+Selenium тестов в контейнере, с отчетиками в Gitlab-е (через junit артефкат). Вот хз, как будто бы отчеты в Allure выглядят нагляднее. Но их еще надо куда-то складывать в отдельное место, а junit отлично парсится самим Гитлабом. Скоро буду вкорячивать их запуск в общий пайплайн деплоя.

Осталось неделю поработать до отпуска, жду. Там еще и микрофон клевый должен приехать. А у вас что на неделе было интересного?

И да, хороших выходных!

IaaS, PaaS и SaaS

Ты, наверное, часто слышал эти термины, но задавался вопросом «чем они отличаются»? А еще это иногда спрашивают на собесах.

IaaS (Infrastructure as a Service) — это когда ты арендуешь виртуальные машины, сети, хранилища и другие инфраструктурные ресурсы. Например, AWS EC2, Google Compute Engine или Microsoft Azure VMs. Всё делаем сами, кроме установки и покупки железного оборудования. Для тех кто хочет полный контроль над своей инфраструктурой. Ты сам настраиваешь серверы, сеть, устанавливаешь операционную систему и всё программное обеспечение. Это как арендовать пустую квартиру: стены есть, но всю мебель ты выбираешь сам.

PaaS (Platform as a Service) — это уже платформа для разработки и развертывания приложений, где провайдер управляет инфраструктурой и ОС за тебя. Ты пишешь только код, настройка инфраструктуры автоматическая (грубо говоря, ты даже не знаешь на какой инфраструктуре это запускается). Они же — Serverless Computing. Например AWS Lambda, Google App Engine, Heroku и Microsoft Azure App Services. Для разработчиков, которым нужно только писать и запускать код, не заморачиваясь с серверной частью. Можно поэкономить на девопсах. Представь, что тебе дали уже обставленную квартиру: ты можешь сразу начать жить, не думая о покупке мебели.

SaaS (Software as a Service) — это уже готовое ПО, обычно доступное онлайн. Типичные примеры — Slack, Google Workspace, Microsoft Office 365. Доступность из любого места, где есть интернет. Отсутствие затрат (временных и финансовых) на поддержку и настройку — платим только за сам сервис. Это как снять квартиру на Airbnb: все уже готово к твоему приезду, просто бери и пользуйся.

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

Хэллоу-хэллоу! Очередной пост про то, чем я занимался на работе.

Буквально пару постов назад рассказывал про Infisical как альтернативу Vault-у, вот собственно теперь я внедрил его в CI/CD пайплайн. Как раз обещал принести инфы про внедрение в процесс доставки.

Во-первых, создал проект в Infisical, в нем три “окружения”: dev, prod, test. В каждом окружении лежат переменные со своими значениями — очевидно, что в produciton и в development разные токены, названия баз данных и пароли.

Во-вторых, в образ контейнера, в котором у меня выполняется пайплайн, я установил Infisical CLI и добавил в Jenkins глобально токен для доступа. Вот токен для доступа я передаю через переменную окружения в jenkins-агента, и тот может ходить в Infisical.
К сожалению пока приходится использовать service token с ограниченным и неизменяемым доступом (для смены прав, нужно перегенерить токен). Жду, когда сделают логин из CLI через Machine Identity, оно более гибкое.

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

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

Есть еще классная опция, чтобы не использовать .env файл в целом: забирать конфигурацию из Infisical прямо из кода. У них есть SDK для различных языков программирования, которые позволяют при запуске приложения обращаться к сервису и забирать значения нужных переменных.

Некоторые значения переменных у меня динамические, например APP_SLOT_PORT=655${SLOT} . В свою очередь переменная SLOT задается как параметр в Jenkins и лежит в окружении раннера. Infisical не умеет рендерить такие штуки из текущего shell-окружения во время export-а. Поэтому приходится дополнительно прогонять envsubst по .env файлу. Про способы подстановки переменных я писал тут.

Вооот, а у вас что интересного делается?

? Почему MTU равно 1500 байтам?

Размер MTU (Maximum Transmission Unit) для Ethernet-кадра составляет 1500 байт. На первый взгляд, это число кажется необычным: оно не является степенью двойки и выглядит подозрительно "десятично-округленным". Но почему так произошло? А компьютерам вроде немного все равно на десятичные числа.

Размер заголовка Ethernet составляет 36 байт, и в сумме с MTU это дает 1536 байт, или 12288 бит. Для передачи такого объема данных на скорости 3 Мб/сек потребуется ровно 2^12 микросекунд. Все потому, что компьютер Xerox Alto, для которого изначально был изобретен Ethernet, работал на частоте 3 МГц. Благодаря этому, интерфейс мог прямо записывать биты в память Alto с той же скоростью, с которой они поступали, что позволяло экономить на дорогостоящих тогда дополнительных чипах и буферизации.

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

Удивительно, как многие стандарты, которые мы сегодня воспринимаем как должное, формировались из-за экономии на специфическом, уже редко используемом оборудовании тех времён.

Этот пост — перевод, вот оригинал.

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

Так-так, к слову об интересных задачах.

На прошлой неделе я изучал сервисы для хранения конфигураций, токенов, паролей и других чувствительных данных. Остановился на данный момент на Infisical, как более простой альтернативе Hashicorp Vault, потому что прямо сейчас мне не нужны HA и все эти seal/unseal. Внедрять в пайплайн это буду только на следующей неделе. Там и расскажу.

А вот на этой пришлось разобраться как поднять тестовый AD FS чтобы разработчики могли интегрировать Single Sign-On аутентификацию.

Главная загвоздка в том, что AD FS (Active Directory Federation Services) — это чисто Microsoft-овское поделие. То есть для него буквально нужно поднять Windows Server и установить на него сервис AD FS.

Если что, с Windows Server я раньше работал на уровне создания учетных записей в Users and Computers.

Но AD FS не может работать сам по себе, ему нужен домен контроллер, а значит нужно дополнительно поднять Active Directory. С AD я решил не рисковать и поднял managed сервис в AWS. Все равно это тестово и не на долго. Жаль, что его нельзя поставить на паузу, чтобы он по ночам деньги не жрал.

А для AD FS поднял отдельный инстанс, ввел его в домен и начал устанавливать сам сервис. Случился затык. По умолчанию в AWS Directory Service (AD) админ-пользователь не имеет прав Domain Admin, и установить AD FS через wizard нельзя. Приходится создавать отдельный контейнер, сервисную учетку, делать магию с правами и уже потом ставить сервис через powershell. Ах да, еще сертификат нужно не забыть сделать.

В общем, лучшей оказалась инструкция от Google Cloud (вдруг интересно будет).

Такие дела, SSO вполне успешно заработал, теперь жду разработчиков, чтобы их подсаппортить с интеграцией. Оказалось довольно интересно.

А что у вас было классного на неделе из задач? Напишите в комментариях ?