DevOps Star (Звезда Девопса)

5 вариантов генерации конфигурационных файлов Shell-скриптами Подготовка конфигурационных файлов из шаблонов — весьма распространённая задача системного администрирования. Решать её можно разными способами, каждый из которых хорош по-своему, здесь же мы рассмотрим, как это сделать с помощью Shell-скриптов. https://habr.com/ru/companies/ruvds/articles/843048/ #devops #девопс 👉 @devops_star

Kargo Это платформа следующего поколения для организации непрерывной доставки и оркестрации жизненного цикла приложений для Kubernetes. Она основывается на принципах GitOps и интегрируется с существующими технологиями, такими как Argo CD, чтобы упростить и автоматизировать поэтапный выпуск изменений на различных этапах жизненного цикла приложения. https://github.com/akuity/kargo #devops #девопс 👉 @devops_star

DevOpsConf 2026: Фабрика инженерных решений 2–3 апреля, Москва. Главное событие для инженеров по автоматизации разработки, надежности и эксплуатации, архитекторов, системных администраторов, технических лидеров и ИТ-директоров. В этом году всё иначе - мы пересобрали привычный лекторий → в конструкторское бюро решений на DevOpsConf. Над чем работаем: 🔹 Работа с наследием (легаси). Поток для тех, кому достался "черный ящик" без документации. Командная игра "Почини сломанную систему на скорость" + воркшоп по анализу древнего кода с помощью ИИ. 🔹 Наблюдаемость без паники. От метрик до архитектуры и борьбы с ложными алертами. 🔹 Как говорить с госорганами и бизнесом. Про 152-ФЗ, ФСТЭК и ГОСТы для инженеров, а также мастер-классы по питчингу решений для руководства. Форматы: воркшопы, кейс‑игры, разбор инцидентов, экспертная зона. 👉 Изучить всю программу и забронировать билеты: https://tglink.io/1f958ac1bb8daf?erid=2W5zFJSpNj3 #реклама О рекламодателе

Технологический стек Netflix - CI/CD Pipeline Эта статья основана на материалах многих инженерных блогов Netflix и проектов с открытым исходным кодом. Планирование: Netflix Engineering использует JIRA для планирования и Confluence для документирования. Код: Java - основной язык программирования для сервисов бэкенда, другие языки используются для различных задач. Сборка: Для сборки в основном используется Gradle, а для поддержки различных вариантов использования создаются плагины Gradle. Упаковка: Пакет и зависимости упаковываются в машинный образ Amazon (AMI) для выпуска. Тестирование: Тестирование подчеркивает ориентацию продакшен-культуры на создание хаос-инструментов. Развертывание: Для развертывания Netflix использует самостоятельно созданный Spinnaker. Мониторинг: Метрики мониторинга централизованы в Atlas, а для выявления аномалий используется Kayenta. Отчет об инцидентах: Инциденты рассылаются в соответствии с приоритетом, а для их обработки используется PagerDuty. #devops #девопс 👉 @devops_star

Топ 4 лучших типа сервисов Kubernetes в одной диаграмме. 🔹 ClusterIP ClusterIP - это стандартный и наиболее распространенный тип службы. Kubernetes назначает сервису ClusterIP внутренний IP-адрес кластера. Это делает службу доступной только в пределах кластера. 🔹 NodePort Это позволяет вывести сервис за пределы кластера, добавив общекластерный порт поверх ClusterIP. Мы можем запросить сервис по NodeIP:NodePort. 🔹 LoadBalancer Этот способ раскрывает сервис извне, используя балансировщик нагрузки облачного провайдера. 🔹 ExternalName Сопоставляет службу с доменным именем. Обычно это используется для создания службы в Kubernetes для представления внешней базы данных. #devops #девопс 👉 @devops_star

Как определить состояние контейнера Docker? 1. Проверить статус всех контейнеров:

   docker ps -a
   

Эта команда выводит список всех контейнеров, их идентификаторы, имена, статус и время работы. В колонке "STATUS" можно увидеть текущее состояние контейнера, например: - Up X hours — контейнер работает. - Exited (code) — контейнер завершил работу с определённым кодом выхода. 2. Проверить состояние конкретного контейнера: Используйте команду docker inspect, чтобы получить подробную информацию о состоянии контейнера:

   docker inspect <container_id>
   

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

   docker inspect -f '{{.State.Status}}' <container_id>
   

Возможные статусы: - running — контейнер запущен. - exited — контейнер завершил работу. - paused — контейнер приостановлен. - restarting — контейнер перезапускается. 3. Проверить логи контейнера: Чтобы увидеть последние действия контейнера, можно просмотреть его логи:

   docker logs <container_id>
   

Это поможет понять, что происходило с контейнером, особенно если он неожиданно завершил работу. #devops #девопс 👉 @devops_star

Molecule Проект Molecule предназначен для помощи в разработке и тестировании ролей Ansible. Molecule обеспечивает поддержку тестирования с несколькими экземплярами, операционными системами и дистрибутивами, провайдерами виртуализации, тестовыми фреймворками и сценариями тестирования. Molecule поощряет подход, который приводит к последовательному развитию ролей, которые хорошо написаны, легко понимаются и поддерживаются. https://github.com/ansible/molecule 👉 @devops_star

KubeSkoop KubeSkoop — это инструмент диагностики сетей Kubernetes для различных CNI плагинов и провайдеров IAAS. KubeSkoop автоматически строит граф сетевого трафика Pod в кластере Kubernetes, осуществляет мониторинг и анализ критических путей ядра с помощью eBPF, чтобы решать большинство сетевых проблем кластера Kubernetes. https://github.com/alibaba/kubeskoop 👉 @devops_star

🚀 Подборка полезных IT каналов в Max Системное администрирование, DevOps 📌 https://max.ru/i_odmin Все для системного администратора https://max.ru/bash_srv Bash Советы https://max.ru/sysadminof Книги для админов, полезные материалы https://max.ru/i_odmin_book Библиотека Системного Администратора https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др. 1C разработка 📌 https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С Программирование C++📌 https://max.ru/cpp_lib Библиотека C/C++ разработчика Программирование Python 📌 https://max.ru/python_of Python академия. https://max.ru/BookPython Библиотека Python разработчика Java разработка 📌 https://max.ru/bookjava Библиотека Java разработчика GitHub Сообщество 📌 https://max.ru/githublib Интересное из GitHub Базы данных (Data Base) 📌 https://max.ru/database_info Все про базы данных Фронтенд разработка 📌 https://max.ru/frontend_1 Подборки для frontend разработчиков Библиотеки 📌 https://max.ru/programmist_of Книги по программированию https://max.ru/proglb Библиотека программиста https://max.ru/bfbook Книги для программистов Программирование 📌 https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT https://max.ru/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻 Шутки программистов 📌 https://max.ru/itumor Шутки программистов Защита, взлом, безопасность 📌 https://max.ru/thehaking Канал о кибербезопасности https://max.ru/xakkep_1 Хакер Free Книги, статьи для дизайнеров 📌 https://max.ru/odesigners Статьи, книги для дизайнеров Математика 📌 https://max.ru/Pomatematike Канал по математике https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике Вакансии 📌 https://max.ru/progjob Вакансии в IT Мир технологий 📌 https://max.ru/mir_teh Канал для любознательных Бонус 📌 https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга https://max.ru/mockva_life Свежие новости Москвы

Чем отличается COPY от ADD в Dockerfile? Инструкция COPY копируют файлы и директории с хостовой машины внутрь контейнера, инструкция ADD копирует файлы и директории с хостовой машины внутрь контейнера и может распаковывать .tar архивы. 👉 @devops_star

Чем отличается CMD от ENTRYPOINT в Dockerfile? Инструкции CMD и ENTRYPOINT выполняются в момент запуска контейнера, тольо инструкция CMD позволяет переопределить передаваемые команде аргументы. Пример 1. CMD: Опишем сборку образа в Dockerfile. FROM alpine CMD ["ping", "8.8.8.8"] В инструкцию CMD передаются 2 аргумента. Выполним сборку образа docker build -t test . и запустим контейнер. $ docker run test PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: seq=0 ttl=43 time=32.976 ms 64 bytes from 8.8.8.8: seq=1 ttl=43 time=31.998 ms 64 bytes from 8.8.8.8: seq=2 ttl=43 time=31.843 ms --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 31.708/33.316/36.823 ms Теперь передадим 2 новых аргумента для запуска контейнера. $ docker run test traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 46 byte packets 1 172.17.0.1 (172.17.0.1) 0.017 ms 0.016 ms 0.009 ms 2 192.168.168.1 (192.168.168.1) 0.996 ms 1.553 ms 2.069 ms 3 * * * 4 lag-2-435.bgw01.samara.ertelecom.ru (85.113.62.125) 1.454 ms 1.427 ms 1.984 ms 5 172.68.8.3 (172.68.8.3) 19.685 ms 15.722 ms 15.565 ms 6 172.68.8.2 (172.68.8.2) 15.846 ms 22.696 ms 35.093 ms 7 one.one.one.one (1.1.1.1) 17.439 ms 17.670 ms 24.202 ms ping заменен на traceroute, IP адрес заменен на 1.1.1.1. Пример 2. ENTRYPOINT: Опишем сборку образа в Dockerfile. FROM alpine ENTRYPOINT ["ping", "8.8.8.8"] В инструкцию ENTRYPOINT передаются 2 аргумента. Выполним сборку образа docker build -t test . и запустим контейнер. $ docker run test2 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: seq=0 ttl=43 time=36.189 ms 64 bytes from 8.8.8.8: seq=1 ttl=43 time=44.120 ms 64 bytes from 8.8.8.8: seq=2 ttl=43 time=44.584 ms ^C --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 36.189/41.631/44.584 ms Теперь передадим изменим один из аргументов для запуска контейнера. $ docker run test2 ping 1.1.1.1 BusyBox v1.31.1 () multi-call binary. Usage: ping [OPTIONS] HOST Send ICMP ECHO_REQUEST packets to network hosts -4,-6 Force IP or IPv6 name resolution -c CNT Send only CNT pings -s SIZE Send SIZE data bytes in packets (default 56) -i SECS Interval -A Ping as soon as reply is recevied -t TTL Set TTL -I IFACE/IP Source interface or IP address -W SEC Seconds to wait for the first response (default 10) (after all -c CNT packets are sent) -w SEC Seconds until ping exits (default:infinite) (can exit earlier with -c CNT) -q Quiet, only display output at start and when finished -p HEXBYTE Pattern to use for payload Как видим, аргумент передать контейнеру нельзя. 👉 @devops_star

ContainerSSH SSH-сервер, запускающий контейнеры в Kubernetes и Docker https://github.com/ContainerSSH/ContainerSSH 👉 @devops_star

Какие инструкции есть у Dockerfile? FROM Задаёт базовый (родительский) образ. LABEL. Описывает метаданные. Например — сведения о том, кто создал и поддерживает образ. ENV Устанавливает постоянные переменные среды. RUN. Выполняет команду и создаёт слой образа. Используется для установки в контейнер пакетов. COPY. Копирует в контейнер файлы и директории. ADD. Копирует файлы и директории в контейнер, может распаковывать локальные .tar-файлы. CMD Описывает команду с аргументами, которую нужно выполнить когда контейнер будет запущен. Аргументы могут быть переопределены при запуске контейнера. В файле может присутствовать лишь одна инструкция CMD. WORKDIR. Задаёт рабочую директорию для следующей инструкции. ARG Задаёт переменные для передачи Docker во время сборки образа. ENTRYPOINT Предоставляет команду с аргументами для вызова во время выполнения контейнера. Аргументы не переопределяются. EXPOSE Указывает на необходимость открыть порт. VOLUME Создаёт точку монтирования для работы с постоянным хранилищем. 👉 @devops_star

Mount — ещё один способ уменьшения размера Docker-образа Делюсь лайфхаком по уменьшению размеров Docker-образов. Как-то нам попалась на поддержку и развитие CRM-система, написанная на Ruby. Пришли со словами: предыдущий разработчик не передал исходный код, но систему нужно развивать. Я уверен, что по условиям контракта передавали исходный код, но заказчики всегда относятся попустительски: им присылают архив на почту, а они потом стирают старое барахло, чтобы ящик почистить. Так вот, зайдя на продакшен-сервер, я нашел развернутую платформу, да ещё и с .git папочкой. Ура, у меня были исходники с историей (она потом мне ни разу не понадобилась). Загрузил в нашу репу исходники, поизучал. В ходе контракта нужно было изменить деплой с rsync на контейнеризацию и перетащить все на Alt Linux (или Astra, уже не помню). Обновили Ruby-пакеты (gems), обновили под них код и написали Dockerfile. Первая сборка была удручающей: образ в 2Гб. Это нормальный размер, если ты собираешь образ с Torch и другой ML-штуковиной, но CRM - нет. В результате дальнейших действий, удалось сократить размер образа до 200Мб. https://habr.com/ru/articles/851384/ 👉 @devops_star

DevToys DevToys помогает в ежедневных задачах разработки, предлагая набор небольших инструментов, предназначенных для быстрого выполнения конкретных задач. Нет необходимости использовать множество ненадежных сайтов для простого декодирования текста или сжатия изображения. С помощью функции Smart Detection приложение интуитивно выбирает лучший инструмент для данных, находящихся в буфере обмена. DevToys 2.0 включает 30 инструментов по умолчанию: Конвертеры: JSON <> YAML, Дата, Числовые системы и т.д. Кодировщики/Декодировщики: HTML, URL, Base64, GZip, JWT, QR-код и т.д. Форматтеры: JSON, SQL, XML и т.д. Генераторы: Хэш и Контрольная сумма, Lorem Ipsum, Пароли и т.д. Инструменты для графики: Симулятор цветовой слепоты, Сжатие PNG/JPEG и т.д. Тестеры: JSONPath, RegEx, XML и т.д. Текстовые утилиты: Предварительный просмотр Markdown, Сравнение текста, Анализ и утилиты... https://github.com/DevToys-app/DevToys 👉 @devops_star

Основы Docker: контейнеризация, Dockerfile и Docker Compose. Часть 2 Меня зовут Толя, я лидер компетенции Java в Цифровом СИБУРе. Наш прошлый материал о Docker собрал классный фидбэк, поэтому мы решили развить тему и подготовить ещё несколько статей, двигаясь от простого к сложному. В этом материале речь пойдёт о том, что помогает избежать конфликтов зависимостей и проблем с изоляцией, возникающих при запуске нескольких приложений на одном сервере. Для решения этих задач используются технологии контейнеризации, которые позволяют создавать изолированные окружения для приложений, устраняя проблемы совместимости и упрощая процесс развёртывания. Рассмотрим, как работает контейнеризация и какие инструменты помогают сделать её максимально эффективной. https://habr.com/ru/companies/sibur_official/articles/846350/ 👉 @devops_star

Введение в Docker и Kubernetes: основы контейнерных технологий. Часть 1 Docker и Kubernetes — два инструмента, которые прочно вошли в арсенал современных разработчиков. Хотите разобраться в основах контейнеризации и оркестрации? Наша статья поможет вам в этом, раскрывая ключевые концепции и принципы работы этих технологий. https://habr.com/ru/companies/sibur_official/articles/826964/ 👉 @devops_star

🚀 Ищем Kubernetes Platform Engineer (Middle+/ Senior) в 2ГИС В команде Infrastructure & Operations мы строим внутреннюю PaaS-платформу для Data Services: PostgreSQL, Redis, Kafka, ClickHouse. Наша цель — сделать DBaaS и DS self-service, надёжной и стандартизированной частью платформы для десятков продуктовых команд. Что будешь делать: • Развивать PaaS на базе Kubernetes • Автоматизировать lifecycle DS (deploy, scale, backup, restore) • Строить DBaaS (начинаем с PostgreSQL) • Внедрять GitOps, IaC и платформенные стандарты Наш стек Kubernetes, GitLab CI/CD, Terraform, Ansible, ELK, Vault, S3. Ищем инженера, который понимает Kubernetes как платформу, работал со stateful-нагрузками и тюнил PostgreSQL. Удалёнка или офис. Белая зарплата, ДМС, обучение и конференции — всё по-взрослому. 👉Откликайся Другие инженерные инсайты от 2ГИС →в Telegram-канале RnD

Как мы ищем деградации на нодах в кластерах Kubernetes Меня зовут Станислав Егоркин, я инженер юнита IaaS департамента разработки Infrastructure в Авито. В этой статье я расскажу про инструмент, который мы используем для обнаружения деградаций на нодах в кластерах Kubernetes, а также покажу дашборд, где мы наблюдаем за состоянием всех наших нод. Причины деградаций на нодах Инфраструктура Авито — это тысячи bare-metal серверов, большая часть из которых объединена в десятки Kubernetes-кластеров. Понятно, что в таких масштабах отказ отдельных кубонод — событие регулярное. Причины могут быть разные: от поломки планки памяти до возникновения проблем с container runtime. Хорошо, если нода отказала полностью, тогда Kubernetes сам обработает отказ, и рабочая нагрузка пострадает минимально. Хуже, когда деградация частичная. В этом случае нода может долго находиться в плохом состоянии, заставляя «страдать» все сервисы, которые оказались запущены на ней. Обычно события в этом случае развиваются следующим образом: кто-то из разработчиков замечает деградацию своего микросервиса, локализовывает ее до ноды и приходит к нам. Мы диагностируем и прочиниваем ноду. Однако некоторые проблемы встречались на разных нодах снова и снова. И каждый раз они требовали нашего вмешательства. https://habr.com/ru/companies/avito/articles/847466/ 👉 @devops_star

Шпаргалка по командам Docker 👉 @devops_star