Загадки DevOpsa

Kubernetes: почему это безопасно?

О кубере складывают легенды, поют ему оды и обсуждают в каждой курилке.

И не зря! Кубер намного безопаснее виртуалок и вот почему:

Здесь только жесткая последовательность

Если в манифесте не выдан доступ к секрету — приложение его не получит. Никогда. А вот в мире виртуалок кто-то мог «случайно» залезть на сервер и подглядеть.

Вся сетевая политика описана кодом

Ты видишь, кто с кем может говорить. Попробуй сделать это на куче виртуалок с iptables!

Здесь секреты — это объекты

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

Подам по умолчанию нельзя просто так взять и стать рутом

SecurityContext и AppArmor делают жизнь хакера очень сложной))

Да, Kubernetes сложный. Но его сложность — это и есть его защита. Она заставляет тебя думать о безопасности на этапе дизайна, а не уже в момент инцидента🔫

Вы как, часто обращаетесь с куберу? Хочется услышать примеры ваших практик)

#kubernetes #security #devsecops #containerization

Давайте знакомиться! 🏃

Привет! Меня зовут Вова и вот уже 13 лет я девоплю Девопс и управляю командой микро-девопсов.

Сейчас я работаю в Магнит.Тех, развиваю личный бренд и тягаю железо — как на работе, так и в зале🦾

Зачем вы здесь?

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

Еще я менторю ребят, если у них вдруг возникают проблемы.

Так что можешь написать мне в личку и мы быстро раскидаем все недоразумения.

Пожар, пожар

Вспомнил тут свою историю, как 5 лет назад я ДВАЖДЫ тушил один тот же инцидент. Запарился я тогда знатно, но вынес для себя несколько уроков:

1. Автоматизируйте реакцию на такие инциденты.
2. Напиши правило для мониторинга, которое предупредит о нем заранее.
3. Исправь коренную причину проблемы в коде или конфиге, что не париться вновь.

Разреши себе не тушить, а строить систему ПЖТ!

Часто ли вы тушите пожары или больше любите наблюдать за сией катастрофой?))

#devops #burnout #automation #productivity

Я вижу, вижу...

Как хреново работает твое приложение без Observability)

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

Для прокачки таких проектов, я всегда использую мою любимую обсервабилити-связку:

- Метрики (Prometheus)

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

- Визуализация (Grafana)

Берет сухие цифры из Прометеуса и рисует из них красивые и понятные дашборды.

Логи (Loki / Vector / ELK)

В них записано всё, что «наговорило» приложение в процессе работы. Упало? Идем сюда и читаем, какие ошибки оно кричало перед смертью. Loki — от ребят из Grafana, умеет умно и быстро искать по логам без боли в голове.

Алертинг (Grafana Alerting / Alertmanager)

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

Трассировка (Jaeger, Tempo) — а это уже магия высшего пилотажа

Позволяет проследить путь ОДНОГО запроса через все микросервисы. Где он задержался? Кто его тормозил? База данных или соседний сервис? Jaeger покажет это как на ладони, красиво и наглядно.

Синтетический мониторинг (Blackbox)

Он постоянно «щупает» наши эндпоинты снаружи: доступен ли сайт? Отвечает ли он быстро? А тот критический API-метод? Короче, хорошая штука.

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

А что сейчас используете вы?)

#devops #observability #monitoring #grafana #prometheus #logging #tracing

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

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

Можно знать Kubernetes от и до, но если ты не можешь объяснить тестировщику, почему упала его среда — ты не девопс. Ты просто сисадмин в облаке🤒

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

А как у вас с софтами?)

#devops #automation #IAC #цифровая_трансформация #инфраструктура_как_код

Так всё-таки: в облако или сидим в подвале с серверами?

На канале очень много новеньких, поэтому затрону одну из больных тем многих компаний — куда лучше мигрировать?😢

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

Сейчас вариантов переезда не так много, но могу посоветовать парочку:

1️⃣Yandex Cloud — минимум головной боли с локализацией данных, всё «по месту», но придётся привыкнуть. Наша команда как раз переехала туда, а как мы это сделали, можете посмотреть тут → https://www.youtube.com/watch?v=Jnxes7WVbHo

2️⃣Selectel — пока одна их крупнейших облачных платформ, но работают в основном только с корпами.

3️⃣Cloud.ru — слышал о нем немного, но вроде по свойствам тоже неплох.

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

Главное — просчитайте финансы: подписку, обучение команды, миграцию и поддержку.

А вы уже мигрировали?
🔥 — да, теперь минус 150 проблем
😢 — ещё не осилили, но надеемся

Как понять, что вы уже зрелый?

Формула проста: голос становится грубее, взгляды — увереннее, а ниже не возникает проблем... с автоматизацией и мониторингом😏

Это я к чему? Зрелым может быть не только человек или помидор с грядки, но и проекты и их DevOps. Как раз с последним мы будем разбираться в течение следующей недели.

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

Решил поделиться и с вами! Переходите по ссылке и быстренько забирайте пока горячий)

Если есть вопросы — велком в комментарии, буду рад пообщаться и обсудить детали)

Девопс — это когда ты не просто «кнопкожмур», а главный заводила в цифровом цирке 🤡

Со всеми этими CI/CD, кубернетесами и прочими страшными словами, которые на самом деле просто хотят, чтобы их любили))

Девопс-специалисты — это те, кто впихивает невпихуемое в процесс и делает так, чтобы все не просто работало, а летало и радовало всех вокруг👋

- Хочешь автотесты?

Девопс уже несется с криком «А давайте вот так!» — и внезапно оказывается, что разработчики и тестировщики больше не воюют, а вместе придумывают, как запилить тест, который не падает от чихания.

- Нужен мок-сервер?

Девопс уже рисует схемы на салфетке и орет «Я знаю, как это сделать!».

- Гит-флоу похож на войну кланов?

Девопс берет молоток (ну, или `git rebase -i`) и наводит порядок.

- Мониторинги?

Это же не просто «чтобы алерты орали», а прозрачность — чтобы каждый, от тимлида до стажёра, видел, где тормозит и почему.

- Финансы утекают в облако, как вода в песок?

Финопс врывается с графиками и кричит «Стоп! Давайте оптимизируем!» — и вот ты уже экономишь, даже не заметив.

- Джира — это ад?

Девопс достаёт метрики и говорит менеджеру: «Смотри, вот где у нас пробка, вот где люди горят, а вот где можно сделать красиво».

Но самое главное — девопс это про культуру изменений. Не про «ой, давайте не трогать, а то сломается», а про «давйте попробуем — а если сломается, починим»🤓

И если тебе кажется, что твой проект тонет в хаосе, а релизы проходят как квест на выживание — welcome в мой телеграм!

Подписывайся, все обсудим и никого не осудим ❤️

Ночь, а в общем чате уже кипят споры: наш сервис после очередного апгрейда железа три раза падал за неделю, и главный вопрос «куда переезжать?» висит в воздухе (точнее, в чатике "полуночники").

Саша утверждает, что нам нужен AWS — дорогой, но проверенный вариант. Ира мечтает о GCP, хотя с документацией там полный мрак...

Я же предложил гибридный вариант: часть нагрузки — в облако, часть — оставить на старом ЦОДе, чтобы проверить, что рухнет первым))
В полпервого мы в голосовых распределяли фронт в AWS, бэкенд в GCP (там оказалось чуть сложнее с IAM, но быстро поправили), а база осталась в руме до следующей итерации миграции.

Утром, допивая леденящий душу кофе, мы увидели — фронтенд ожил в ЕС‑регионе за 10 минут, бэкенд «встал» после пары правок, а база даже не пикнула!

Вывод простой: не бойтесь пробовать что-то новое и выбирать то, что необходимо сейчас для решения проблемы.

А какой вариант используете вы?

❤️ - AWS
🌚 - GCP
🙏🏻 - божьи силы..

Представим, что час ночи, а продакшен вышел из строя🫠

Что делать в таких случаях? Расскажу вам кратко:

1. Оцените масштаб проблемы с помощью команд kubectl get pods и df -h.

2. При необходимости выполните откат релиза командой helm rollback или git revert.

3. Если вносятся срочные правки, обязательно зафиксируйте их в репозитории.

По возможности проведите базовую диагностику зависимостей и базы данных!

Утром организуйте постмортем — зафиксируйте корни произошедшего и доработайте процесс реагирования.

И как говорил мой коллега "Любой кризис – это новые возможности, поэтому рушим все тут на*рен"👍

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

Уже 13 лет я колдую над приложениями и помогаю им выдерживать все тягости современного мира. И да, у меня есть страсть автоматизировать всё подряд.

Что вы увидите в этом канале?
🔵Полезная польза: чек-листы, шаблоны и просто советы для упрощения работы;
🔵Реальные кейсы: как мы за ночь возвращали рабочий сервис после апгрейда Kubernetes
🔵Факапы и немного лайвстайла — куда без этого)

Давайте знакомиться, что ли — пишите в комментариях, откуда вы!👋

Channel created