DevOps

🚀 Docker за 30 секунд - поймёт даже новичок Docker кажется сложным, пока не разложишь его на 5 элементов 👇 1. Docker Client Это то, с чем ты работаешь каждый день: команды build, push, pull, run 2. Docker Host + Daemon “Мозг” Docker на машине - хранит образы - запускает контейнеры - управляет всем процессом 3. Docker Registry Хранилище образов (например: MySQL, NGINX, Redis) Ты либо скачиваешь оттуда, либо пушишь свои 4. Images vs Containers - Image - это шаблон - Container - это запущенный image 5. Как всё работает вместе - build → создаешь image - push → отправляешь в registry - pull → скачиваешь image - run → запускаешь container 💡 Вся магия Docker - это просто поток: Client → Daemon → Registry → Container Если понимаешь этот flow - понимаешь Docker. Именно это спрашивают на собеседованиях. #devops #docker #linux https://www.youtube.com/shorts/y0dNbPCZI6E 🖥 Полезные Linux ресурсы 🚀 Max @DevOPSitsec

🚀 9 стратегий деплоя, которые реально используют в DevOps Современные команды выбирают стратегию релиза не «по привычке», а исходя из риска, бюджета и требований к uptime. Вот база, которую нужно понимать: 1⃣ Recreate Deployment Старую версию полностью останавливают, потом запускают новую ➝ Плюсы: просто, нет конфликтов ➝ Минусы: есть downtime ➝ Когда использовать: внутренние сервисы, простые системы 2⃣ Rolling Deployment Обновление происходит постепенно, по инстансам ➝ Плюсы: без даунтайма, плавный rollout ➝ Минусы: одновременно работают разные версии ➝ Где используется: Kubernetes, Docker 3⃣ Blue-Green Deployment Два окружения: старое (Blue) и новое (Green) Переключение трафика происходит мгновенно ➝ Плюсы: быстрый rollback, безопасный релиз ➝ Минусы: дорого, сложнее с базой 4⃣ Canary Deployment Сначала выкатываешь на небольшой % пользователей ➝ Плюсы: раннее обнаружение проблем ➝ Минусы: сложная маршрутизация и мониторинг ➝ Используют: Google, Netflix 5⃣ Shadow Deployment Продакшн-трафик дублируется на новую версию ➝ Плюсы: тест на реальных данных без риска ➝ Минусы: дорого по ресурсам 6⃣ A/B Testing Разным пользователям показываются разные версии ➝ Плюсы: решения на основе данных ➝ Минусы: сложная аналитика ➝ Цель: метрики, конверсии, поведение 7⃣ Feature Toggles (Flags) Функция уже в проде, но скрыта за флагом ➝ Плюсы: мгновенное включение/выключение ➝ Минусы: усложняет код 8⃣ Immutable Deployment Не обновляешь сервер - создаёшь новый ➝ Плюсы: стабильность, нет «дрейфа конфигурации» ➝ Минусы: дольше и дороже 9⃣ Serverless Deployment Код выполняется по запросу, без серверов ➝ Плюсы: авто-скейлинг, платишь за использование ➝ Минусы: cold start, зависимость от провайдера 🧠 Вывод: Нет «лучшей» стратегии Есть подходящая под твою систему - хочешь безопасность → Blue-Green / Canary - хочешь простоту → Rolling - хочешь контроль → Feature Flags 🔥 Сильные команды комбинируют несколько подходов сразу

🚨 В открытом GitHub утекло 29 миллионов секретов за прошлый год Пароли. API-ключи. Токены. И почти всегда это происходит по одной причине, разработчик просто не заметил. Есть бесплатный инструмент, который ловит такие вещи ДО релиза. Называется Trivy. Одна команда и он проверяет весь твой стек: контейнеры, код, Kubernetes, cloud - всё сразу. • Без платных тарифов • Без продажников • Без “enterprise only” Просто запускаешь и получаешь отчёт. Что он находит: → уязвимости во всех зависимостях и пакетах → пароли, API-ключи и секреты в коде → ошибки конфигурации в cloud и контейнерах → проблемы с лицензиями → полный список всего, что ты деплоишь brew install trivy trivy image your-app:latest Две строки и у тебя полный security-аудит. https://github.com/aquasecurity/trivy

🔥 Полезная подборка каналов только код, практика и самые передовые инструменты, которые используют разработчики прямо сейчас.👇 🖥 ИИ: t.me/ai_machinelearning_big_data 🖥 Python: t.me/pythonl 🖥 Linux: t.me/linuxacademiya 🖥 C++ t.me/cpluspluc 🖥 Docker: t.me/DevopsDocker 🖥 Хакинг: t.me/linuxkalii 🖥 Devops: t.me/DevOPSitsec 👣 Golang: t.me/Golang_google 🖥 Аналитика: t.me/data_analysis_ml 🖥 Javascript: t.me/javascriptv 🖥 C#: t.me/csharp_ci 🖥 Java: t.me/javatg 🖥 Базы данных: t.me/sqlhub 👣 Rust: t.me/rust_code 🤖 Технологии: t.me/vistehno 💰 Экономика и инвестиции в ИИ t.me/financeStable 💼 Актуальные вакансии: t.me/addlist/_zyy_jQ_QUsyM2Vi 🖥Подборка по Golang: https://t.me/addlist/MUtJEeJSxeY2YTFi ⚡️ Лучшие ИИ ресурсы: https://t.me/addlist/2Ls-snqEeytkMDgy Max ИИ: https://max.ru/ai_machinelearning_big_data Max Ml: https://max.ru/vistehno Max python: https://max.ru/pythonl Max Go: https://max.ru/Golang_google Max Linux: https://max.ru/linuxkalii Max Java: https://max.ru/javatg Max Sql: https://max.ru/sqlhub Max Devops: https://max.ru/DevOPSitsec Анализ данных: https://max.ru/data_analysis_ml C++ : https://max.ru/cpluspluc C#: https://max.ru/csharp_ci 🖥 Chatgpt бот в тг: t.me/Chatgpturbobot 📚 Бесплатные ит-книги: https://t.me/addlist/HwywK4fErd8wYzQy

💀 Эта ошибка убила тысячи — и ты совершаешь её каждый день Во время Второй мировой войны аналитики ВВС США изучали повреждения бомбардировщиков, вернувшихся с миссий. Они отмечали, куда чаще всего попадали пули: - крылья - хвост - фюзеляж Вывод казался очевидным: 👉 усиливаем броню там, где больше всего попаданий Но один человек сказал: «Вы делаете всё наоборот» Его звали Абрахам Вальд — молодой статистик. И он увидел то, что остальные игнорировали. 💥 Главная мысль, которая всё изменила: Вы анализируете только выживших. А где данные о самолётах, которые не вернулись? Именно их и не хватает. Вальд сделал гениально простой вывод: 👉 если самолёт вернулся с дырками в крыльях — значит, туда *можно* попадать и выжить 👉 а вот туда, где дырок нет — попадание, скорее всего, фатально То есть: - двигатель - кабина пилота - топливная система — это и есть настоящие слабые места. Просто мы их не видим. Потому что такие самолёты не возвращаются. ⚡️ Армия изменила стратегию. Усилили не «самые пробитые места», а самые незаметные. Результат — тысячи спасённых жизней. 🧠 Так появилась концепция: ошибка выжившего (survivorship bias) Когда мы делаем выводы только по тем, кто «дошёл до финала» — и игнорируем всех, кто не дошёл. 📊 Интересные факты: - Вальд работал в секретной группе Statistical Research Group - Его подход применяли в авиации, баллистике и логистике - Он делал выводы из отсутствующих данных, а не только из имеющихся 💡 Где это ломает мышление сегодня: - стартапы — «делай как Uber» - инвестиции — «копируй успешных» - карьера — «вот путь топ-разработчика» - AI — «смотри на лучшие кейсы» 👉 Самое опасное: мы учимся только на успехах и почти никогда — на невидимых провалах 📌 Вывод: самые важные данные — это те, которых у тебя нет И именно они часто определяют реальность. #thinking #ai #business #startup

Современный DevOps строится на этих инструментах 👇 🔁 Git • Источник правды для кода 🐳 Docker • Упаковка приложений в контейнеры ☸️ Kubernetes • Надежный запуск и управление контейнерами 🧰 Terraform • Инфраструктура как код ⚙️ Jenkins • Автоматизация CI 🦊 GitLab • Управление кодом и CI/CD 🔁 CircleCI • Быстрые CI/CD пайплайны 🚀 Argo CD • GitOps-деплой в Kubernetes 🐙 GitHub Actions • Автоматизация рабочих процессов 🧩 Tekton • Kubernetes-нативный CI/CD 🐍 Ansible • Управление конфигурациями 🔐 HashiCorp Vault • Хранение и защита секретов 🔑 External Secrets • Синхронизация секретов в Kubernetes 📊 Prometheus • Метрики и алерты 📈 Grafana • Визуализация метрик 🐶 Datadog • Мониторинг облачной инфраструктуры 🔍 ELK Stack • Анализ логов 🧭 OpenTelemetry • Стандарт наблюдаемости 🛡️ Istio • Управление сетевым трафиком 🌐 NGINX • Ingress и reverse-proxy 🚦 Traefik • Современная маршрутизация в облаке ⛵ Helm • Пакетный менеджер для Kubernetes ☁️ AWS • Облачная платформа 🔵 Azure • Облачная платформа 🟢 Google Cloud Platform • Облачные сервисы С какими из этих инструментов вы работаете каждый день? Если что-то важное пропустили — добавляйте в комментариях 👇

60 минут, чтобы оптимизировать Redis для высоких нагрузок Selectel приглашает на практический вебинар, где разберут целостный инженерный подход к оптимизации Redis под high-load — от памяти и клиентских запросов до мониторинга и нагрузочного тестирования. Покажут, как настройки и паттерны использования Redis влияют на вытеснение ключей, p95/p99 задержки и стабильность системы. 📅 26 марта, 12:00 📍 Онлайн 👥 Для инженеров DevOps и DBA, бэкенд-разработчиков, системных администраторов и архитекторов 👉Смотрите полную программу и регистрируйтесь: https://slc.tl/mo6d5 Чтобы не пропустить вебинар и узнавать о других событиях и бесплатных курсах Selectel, подписывайтесь на @selectel_events Реклама. АО "Селектел". erid:2W5zFHrJUoK

☸️ Kubernetes - сложность изучения 🔥 • Легко Pods Deployments Services (ClusterIP) Основы YAML • Чуть сложнее ReplicaSets и масштабирование Ingress ConfigMaps и Secrets Namespaces • Средне Helm Probes (Liveness / Readiness) Resource Limits и Requests HPA (автомасштабирование) Rolling Updates и Rollbacks • Сложно RBAC Сетевые механизмы Kubernetes (CNI) StatefulSets GitOps (ArgoCD / Flux) • Очень сложно CRD (Custom Resource Definitions) Внутреннее устройство Kubernetes (API Server, etcd, Scheduler) • Экстремально сложно Написание собственных Operators Создание собственного Scheduler

erid: 2VtzqvLUR9f Выбирать хардовое обучение вслепую — так себе затея. Качественное обучение требует времени и сил, поэтому перед тем как вписываться, важно заглянуть «под капот». В ИнженеркаТех открыты демо-доступы к флагманским инженерным программам. Вы можете зайти на платформу, оценить технический уровень материалов и получить знания с 1 урока. Выбирайте свое направление, тестируйте и делайте осознанный выбор: 1️⃣ DevOps инженер: интенсив по проектированию и автоматизации инфраструктуры 5 модулей плотной практики. Проходим путь от CI/CD (GitHub Actions) и IaC (Terraform, Terragrunt) до работы с YandexCloud и деплоя в Kubernetes. В финале — настройка мониторинга (Loki, Prometheus) и автомасштабирования (HPA). Каждая тема закрепляется домашкой с ревью. 👉 Забрать демо-доступ к курсу - https://inzhenerka.tech/devops 2️⃣ Разработка модулей ядра Linux (Linux Kernel developer) Глубокое погружение в системное программирование. Разбираем архитектуру ядра Linux, пишем простейшие модули, разрабатываем и регистрируем драйверы для символьных и блочных устройств. Отдельный фокус на управление памятью, работу с / proc и решение проблем конкуренции (семафоры, мьютексы). 👉 Забрать демо-доступ к курсу - https://inzhenerka.tech/linux_drivers 3️⃣ Разработка на C под Linux (Системный разработчик) Фундаментальная база по созданию системных приложений. Работаем с файловой системой, низкоуровневым вводом-выводом, статическими и динамическими библиотеками. Изучаем все виды IPC (очереди сообщений, shared memory, сигналы), учимся работать с сокетами, потоками и писать демонов. 👉 Забрать демо-доступ к курсу – https://inzhenerka.tech/linux_developer_c Реклама. ООО "Инженеркатех" ИНН: 9715483673

🚨 Kubernetes v1.36 официально выходит 22 апреля 2026 года. Вот 6 ключевых обновлений, к которым стоит подготовить свои кластеры: 👇 1⃣ HPA Scale-to-Zero (включено по умолчанию) - Функция HPAScaleToZero выходит из alpha после того, как находилась там с версии v1.16. - Теперь можно безопасно указывать minReplicas: 0. - Это серьёзно снижает расходы для неактивных staging-окружений и batch-пайплайнов. 2⃣ Эфемерные Service Account токены для pull образов - Заменяют долгоживущие статические секреты для доступа к приватным registry. - Используются краткоживущие токены Service Account с автоматической ротацией. - Учетные данные теперь привязаны к идентичности конкретного pod, что значительно снижает риск утечек. 3⃣ Более умный выбор pod’ов в HPA - Исправлена проблема, когда HPA считал метрики устаревших или orphan-pod’ов. - Новая логика учитывает только pod’ы, управляемые целевой workload. - Автоскейлинг становится более предсказуемым и стабильным. 4⃣ Удаление режима kube-proxy IPVS - Режим IPVS был deprecated в v1.35 и теперь будет полностью удалён. - Пора переходить на iptables (backend nftables) или eBPF-proxy (например Cilium). - Лучше запланировать миграцию заранее, чтобы обновление не сломало сетевой стек. 5⃣ Завершение эпохи Ingress NGINX и переход на Gateway API - Сообщество постепенно отказывается от Ingress NGINX. - Gateway API становится новым стандартом управления трафиком. - Появляется нативная маршрутизация между namespace без набора кастомных annotations. 6⃣ Переход на containerd 2.x - Версия v1.36, вероятно, станет последней, поддерживающей старые версии containerd (например **1.6.x**). - Экосистема Kubernetes полностью выравнивается под containerd 2.x. - Обновите runtime заранее, чтобы избежать breaking changes в следующих релизах.

🖥 20 Linux-команд, которые должен знать каждый разработчик: 1. ls — показать файлы и директории 2. cd — перейти в другую директорию 3. pwd — показать путь текущей директории 4. mkdir — создать новую директорию 5. rm — удалить файл или директорию 6. cp — скопировать файл или директорию 7. mv — переместить или переименовать файл 8. touch — создать новый файл 9. cat — вывести содержимое файла 10. nano — открыть файл в терминальном редакторе 11. grep — искать текст внутри файлов 12. find — найти файлы и директории 13. chmod — изменить права доступа к файлу 14. chown — изменить владельца файла 15. df -h — проверить свободное место на диске 16. top — посмотреть запущенные процессы 17. ps aux — показать список активных процессов 18. kill — завершить процесс 19. history — показать историю команд 20. clear — очистить экран терминала https://www.youtube.com/shorts/pdqho8kGKCI 🖥 Полезные Linux ресурсы 🚀 Max

🐳 Docker Layer Caching Trick Многие Docker-сборки занимают 5–10 минут даже если вы изменили одну строку кода. Причина - неправильный порядок инструкций в Dockerfile. 🚫 Плохой Dockerfile COPY . /app RUN npm install RUN npm run build Если меняется любой файл в коде → слой COPY . меняется. Docker сбрасывает кэш и заново запускает: • npm install • build Даже если зависимости не менялись. ⏳ В итоге - каждая сборка почти с нуля. ✅ Правильный Dockerfile COPY package*.json /app RUN npm install COPY . /app RUN npm run build Теперь Docker работает умнее: если изменился только код: • слой npm install берётся из кэша • пересобирается только build ⚡ Время сборки До - ~10 минут После - ~30 секунд 📌 Золотое правило Dockerfile Сначала кладём то, что редко меняется: • package.json • package-lock.json • requirements.txt • go.mod А часто меняющееся - в конце: • исходный код • конфиги • assets 🚀 Результат • быстрее сборки Docker • быстрее CI/CD • быстрее деплой Иногда достаточно просто поменять порядок строк в Dockerfile. 🎯Полезные DEVOPS ресурсы 🚀 Max Docker в телеграм

HyperDrive — GitOps-платформа для инфраструктуры разработки Основная идея: описываете целевую конфигурацию инфраструктуры через код → система приводит ее в желаемое состояние → получаете self-service и автоматическое создание нужных сред (четвергов) То есть вместо ручной настройки: — шаблоны окружений — воспроизводимые среды — все состояние в Git 24 марта будет демо архитектуры платформы: регистрация

🧠 В этот раз DOOM запустили не на калькуляторе и не на холодильнике. А на живых человеческих нейронах. Стартап Cortical Labs вырастил около 200 000 нейронов и подключил их к системе, которая передавала им сигналы из игры в виде электрических импульсов. Нейроны «видели» происходящее через паттерны стимуляции и в ответ генерировали сигналы, которые интерпретировались как игровые действия - движение, поворот, выстрел. По сути, биологическая нейросеть стала контроллером для DOOM. Это уже не просто мем «запустили DOOM на всём подряд». Это момент, когда биология и вычисления реально начинают пересекаться. Кажется, человечество слишком буквально восприняло идею “organic computing” 😬 🎯Полезные DEVOPS ресурсы 🚀 Max

Контроль секретов — иллюзия или управляемый процесс? Пароли, API-ключи, сертификаты и токены часто хранятся фрагментировано — в Git, CI/CD, Docker-образах и конфигурациях. Они не ротируются годами, остаются после смены сотрудников и попадают в историю коммитов. В итоге — риск утечки и сложности на аудите. На вебинаре Deckhouse и Ximi Lab покажем, как выстроить процесс работы с секретами, чтобы соответствовать п. 5.15 ГОСТ Р 56939-2024 в рамках РБПО.

В ходе вебинара: • Поговорим о требованиях по безопасной работе с секретами. • Разберём риски хранения секретов в Git, CI/CD и Docker-образах. • Покажем, как выявлять секреты в репозиториях и пайплайнах с помощью TRON ASOC и реализовать безопасную работу с секретами в Deckhouse Stronghold.

А также вас ждет демо работы платформ и разбор кейсов. 🎁 Участники получат чек-лист по работе с секретами. 19 марта в 12:00, онлайн 👉 Зарегистрироваться Реклама. АО "ФЛАНТ". ИНН 7723661439.

Языки программирования и их «самая ненавистная» фича - по мнению разработчиков • 🐍 Python - отступы ломают всё • 🖥️ BASIC - ощущается болезненно устаревшим • 📊 Visual Basic - очень быстро превращается в хаос • 🟨 JavaScript - странное и непредсказуемое поведение • 🐘 PHP - хаос из-за непоследовательных названий функций • 💎 Ruby - слишком много скрытой «магии» • 🎵 Groovy - используют в основном ради Gradle • ☕ Java - слишком много шаблонного кода • 🟣 C# - болезненные конфликты версий • 🐹 Go - бесконечные строки обработки ошибок • 🐦 Swift - частые ломающие обновления • 🅺 Kotlin - долгие компиляции • 🎯 Dart - существует из-за Flutter • 🧮 Fortran - синтаксис как из прошлого века • 🔧 C - опасное неопределённое поведение • 🍎 Objective-C - повсюду квадратные скобки • 🔺 Scala - переусложнённая система типов • ⚡ Zig - ручная работа с памятью • 🐪 Perl - написал один раз - потом сам не прочитаешь • 🚀 C++ - кошмарные ошибки шаблонов • 🦀 Rust - вечная борьба с borrow checker • ⚙️ Assembly - нулевая безопасность С чем согласен, а что - просто мем? 😄

Контейнерный образ — это база любого релиза ❤️ Но когда версии, доступы и безопасность пущены на самотек, команда увязает в «починке доставки» и отвлекается от развития продукта. На вебинаре вместе с экспертом Cloud․ru вы:

▶️рассмотрите контур артефактов и разберёте, где он чаще всего ломается; ▶️научитесь загружать Docker-образы, версионировать и управлять ими в Evolution Artifact Registry; ▶️настроите приватный доступ к репозиториям и разграничение прав; ▶️включите сканирование на уязвимости и примените политики безопасности; ▶️разберете, как поддерживать порядок в реестре: политики удаления и жизненный цикл.

Вебинар будет полезен backend-разработчикам, DevOps-инженерам (сборка/доставка), архитекторам (инфраструктура/безопасность), техлидам и руководителям команд для ускорения релизов и снижения рисков ошибок. 👉Зарегистрироваться👈

✔️ Карпати только что оценил все профессии в США по уровню воздействия AI. Он собрал данные по 342 профессиям, которые охватывают около 143 миллионов рабочих мест, и попросил LLM оценить каждую по шкале от 0 до 10. Результаты: средний показатель по всем профессиям - 5.3 / 10 разработчики ПО - 8–9 кровельщики - 0–1 медицинские транскрибаторы - 10 / 10 Картина выглядит довольно очевидной. Если ваша работа проходит за экраном, риск автоматизации почти 99%. Если она требует работы руками и взаимодействия с непредсказуемой средой, вы в гораздо большей безопасности. И это уже не просто предположения. Это данные. https://karpathy.ai/jobs/ 🎯Полезные Мл-ресурсы 🚀 Max