Девчонка из IT
1.72K subscribers
112 photos
21 links
Будни backend разработчика 🧡
Download Telegram
Всё, ребята, привела в порядок свои цифровые каракули, теперь рассказываю!

Мне понравился первый доклад из 4х, поэтому расскажу про него.
Называется Kubernetes Governance as a Code, или Как содержать кластеры в чистоте и порядке. Максим Чудновский. Сбертех.

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

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

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

K8s предоставляет автоматизацию применения политик с помощью Admission Controller’ов.

1. Validation Admission
Валидирует сущности кубера при создании. Если сущность не удовлетворяет политикам и стандартам - возвращает ошибку.

2. Mutation Admission
Исправляет ошибки пользователя за него.

3. Operators
Это управление функциональным доменом в рамках кластера. Если у приложения сложное развертывание, можно инкапсулировать эту сложность в оператор.

———
У нас кластер маленький, команд мало, автоматизации сейчас нет, поэтому я теперь во всех чатах умничаю, что нам нужны адмишен контроллеры 🤣 Хочу чтобы всё красиво, автоматизированно
👍11🔥5👏3🌭1
Для больших кластеров в которых живёт множество команд, такой автоматизации может быть недостаточно. Разным командам требуется разный профиль использования кубера, сервис меша. Появляется огромное количество веб хуков, которые применяются к большому числу объектов в кластере и начинают конфликтовать.
Тем более оказывается что в k8s веб хуки исполняются по алфавиту)))

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

Например, реализуется один Mutation Webhook Server, который обрабатывает все мутации. В него встраивается оператор, который принимает шаблон-описание политики и триггер (признак, по которому определяется, к каким объектам применить политику). Триггером может быть лейбл, анноташка и т.д.
Таким образом всё что идёт в кластер приводится в целевое состояние, соответствующее требованиям, которые на кластер возлагаются.

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

Коротко скажу, что они реализовали сущности:

1. Generic Sidecar Injector - тут всё понятно

2. Generic Mutation Manager - мутирует все сущности по заданному шаблону с заданным тригером

3. Generic Validation Manager - содержит два типа валидаций - внутренние и внешние. Внутренние валидируют yaml’ы, сгенерированные Kubelatte, чтобы не было yaml-инъекций. Внешние проверяют то, что пользователь загружает в Kubelatte

4. Generic Creation Manager - генерирует группу ресурсов по запросу клиента. Например, когда множество команд ходит на какой-то внешний ресурс и каждой команде приходится настраивать gateway и открывать трафик на этот ресурс через Service Mesh
👍7🔥4👏3🌭1
Что ещё было на конфе:

• Доклад Единое рабочее пространство администратора, или Когда закончилось место на панели вкладок - ребята из Сбера рассказали каким инструментом пользуются администраторы для контроля АС, работы с инцидентами и так далее. Для меня эта тема пока-что мимо.

Разделение на dev/master-ветки при деплое на стенды: паттерн или антипаттерн? - Семён Киреков из МТС рассказал про ситуации, которые могут возникнуть если использовать dev/master ветки. Вместо них он предлагает использовать trunk-based development с feature flags. Доклад получился холиварный, имхо примеры были надуманные, как-будто разработчик с закрытыми глазами пользуется гитом))

Как мы в Сбере предоставляем техническую поддержку сотрудникам. Дмитрий из Сбера рассказал, как построили сервис, оказывающий тех. поддержку для 250к сотрудников. Тема тоже мимо меня)
👍9🔥4👏3🌭1
Всем привет!
Возвращаюсь в канал и начну с топовой истории)
Вчера к нам на собеседование пришёл кандидат, который решил воспользоваться Chat GPT 🤣
Пруфов нет, но все признаки на лицо

Вводная: по резюме 5 лет опыта, работал в известных больших компаниях на высоконагруженных проектах с блекджеком и корутинами)))

После всех вопросов чел зависал секунд на 5-10, у него подёргивалось плечо, делал уточнения "правильно ли я понял, что вы спрашиваете ...."
И начинал отвечать в стиле "... обладает характеристиками и используется для предоставления ...."
Потом я чуть не упала, когда мы попросили перечислить сущности k8s, и он сказал - под, репликационные наборы (это типа ReplicaSet) 🤪
Затем мы решили перейти к секции с кодом, кандидат перепутал = и ==, не знал что такое юникод, запутался в ООП.

Я читала о том, что на некоторых курсах начинающих разработчиков учат врать в резюме, но сама столкнулась впервые. Шок-контент 😨
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥31🤡18🤣14😱7🌚4👎2👍1
Всем привет!

Коллега посоветовал классную книгу, «Фундаментальный подход к программной архитектуре» (обложку покажу в каментах), в ней описаны различные подходы к проектированию архитектуры, паттерны, антипаттерны и приёмы, виды архитектуры и др.
Одна из глав книги посвящена такому понятию как записи архитектурных решений (Architecture Decision Record, ADR). Это созвучно с тем, что мы сейчас реализуем у себя в команде разработки, поэтому очень хочу рассказать)

Architecture Decision Record - это текстовый файл, который создаётся для описания конкретного архитектурного решения. Мы у себя используем .md файлы и храним их в Git. Есть и другие инструменты и форматы, например, страница в вики вашей компании.
Файл должен быть лаконичным, и содержать разделы, о которых я расскажу ниже.

1️⃣ Название - короткое описание архитектурного решения, должно быть информативным и понятным, чтобы быстро ориентироваться, о чём эта запись
2️⃣ Статуc ADR - на какой стадии находится данное арх. решение: принято, или ещё обсуждается (Request For Comments, RFC), а может заменено новым ADR
3️⃣ Контекст - ситуация, которая привела к созданию ADR и принятию решения
4️⃣ Решение - сама суть архитектурного решения и его полное обоснование. Важно уделить особое внимание именно обоснованию решения, ответить на вопрос «почему». Этот момент является ключевым и самым полезным (имхо) в документировании архитектуры
5️⃣ Последствия - описание того, что влечёт за собой принятое архитектурное решение. Какие плюсы и минусы у него есть, их анализ
6️⃣⭐️ Альтернативы - опциональный раздел, в котором сосредоточены альтернативные решения указанной проблемы, и причины, по которым эти решения не были приняты командой
7️⃣ ⭐️ Комплаенс - в книге рекомендуется включать этот раздел в свои ADR. Это описание, каким образом контролировать соблюдение требований данного арх. решения, должно ли это контролироваться вручную или можно автоматизировать. У нас пока такого раздела нет
8️⃣⭐️ Примечания - также опциональный раздел для указания автора, дат утверждения и замены, лиц, участвующих в принятии и утверждении данного решнеия и т. д.
9️⃣
🔟 Вы великолепны 🤪😂

Вы спросите меня, зачем всё это нужно? И я вам отвечу)))

🌟 Это эффективный способ документировать архитектуру - всё в одном месте, можно наблюдать инкремент, описаны альтарнативы, + и -
🌟 Не приходится проводить повторные R&D, потому что результаты предыдущих архитектурных дилемм записаны, оформлены, подведены итоги
🌟 Чуть полегче онбордить новых разработчиков/внедрять иннерсорс, когда приходят с «а почему», можно прислать ссылку на «а потому» и вопрос исчерпан (но естественно пересмотр архитектуры и принятых решений должен быть)
🌟 Можно унифицировать подход к архитектуре микросервисов и тем самым снизить эксплуатационные издержки на поддержку

Приземлю на конкретику. Если вы приходите в сервисы и не понимаете

🟢 почему условный Вася воткнул тут кафку, а не обошёлся рестом
🟣 почему решили использовать gRPC, а не десериализовать json’ы до талого))
🔵 почему используется именно эта библиотека для генерации PDF
🟡 зачем тут Camunda прости господи)))
🟢 почему эту интеграцию реализовали из г… теми ресурсами, которые были доступны на тот момент 🥲
🟣 почему все сервисы развёрнуты в k8s, а один стоит на виндовой тачке в другом контуре

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

Расскажите, знаете про такой инструмент? Практикуете?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥27👍1210👏2