DevOps *

Хей, Хабр! Секреты — это такая щекотливая тема, из‑за которой у безопасников начинаются нервные подёргивания глаза. Вроде бы «просто пароль» или «просто токен», но в 2025 году мы уже знаем, что просто в безопасности — это верная дорога к утечкам и ночным обкаткам плана B. В этой статье поговорим, как правильно хранить секреты в Docker‑контейнерах и окрестностях, а заодно разберёмся, чем могут помочь Docker Secrets, HashiCorp Vault и компания.

Привет дорогие Хабровчане! В данной статье хочу поделиться с вами опытом создания сервиса предоставляющего услуги контейнерного хостинга, в процессе работы над которым я узнал много нового, для себя, в этой области. Хочу поделиться с вами и постараюсь сделать так, чтобы вы не были разочарованы если дочитаете до конца.

Изначально, на этапе планирования, была задача строить инфраструктуру вокруг Kubernetes, но сейчас пришли к тому, что сервис работает на Docker, управляется через docker compose файлы и Docker-API. В настоящее время без режима Swarm. Почему так получилось и какие проблемы приходится решать не используя Kubernetes я вам сейчас расскажу.

Во первых, как минимум, сразу напрашивается вопрос, почему без режима Swarm, ведь горизонтальное масштабирование не лишнее? Режим swarm пока не используется, так как в настоящее время мы располагаем только одним сервером и если вдруг сервер перестанет отвечать, то всё равно все реплики перестанут работать, поэтому и смысла от них нет. Однако, естественно (надеюсь) это не постоянная ситуация, поэтому всегда держали в голове режим Swarm и не включали того, что не будет работать в Swarm, чтобы потом было легче мигрировать.

Почему не использовали Kubernetes? Ответ прост, но принять решение было не просто. На момент начала разработки у меня совсем не было опыта работы с ним, да и сейчас пока нет, только в теории. Плюс из интернета я так и не понял, чем он конкретно круче Swarm кроме того, что он может работать с гораздо большим количеством контейнеров. Так как, чтобы это проверить, нужно столько ресурсов скольки у меня пока что нет, я решил двигаться в сторону Swarm, а когда появятся ресурсы и спрос, а главное понимание зачем это нужно, то уже возможно переписывать на Kubernetes.

В этом обзоре мы представляем новые проекты CNCF, которые помогут в разработке и управлении облачными приложениями. Узнайте о последних обновлениях в категориях Runtime и App Definition & Development.

В статье мы рассматриваем новые проекты, добавленные в песочницу CNCF в 2024 году в категории Orchestration & Management. В обзоре расскажем о HAMi, Kmesh и других инициативах, которые меняют подход к оркестрации и управлению контейнерами.

Подготовили обзор новых проектов, добавленных в песочницу CNCF в 2024 году в категории Provisioning и Observability & Analysis. В статье читайте об инструментах, которые изменят подход к облачным технологиям.

Часто на первом проекте кажется, что самое сложное позади: приложение готово, осталось только показать его миру. Но что, если сервер под угрозой?

В этой статье — простая и проверенная инструкция по настройке безопасного сервера для вашего первого fullstack-приложения. От SSH до SSL и двухфакторной аутентификации — рассказываю, как я защитил свой SaaS-проект Transcribator.

Сегодня мы с радостью объявляем о новом релизе GitLab 17.7 с новой пользовательской ролью Planner, правилами автоматического разрешения уязвимостей, списками разрешённых интеграций инстанса, пользовательским интерфейсом для ротации токенов доступа и многими другими фичами!

Сегодня я расскажу, как можно создать собственную систему репутации с Telegram на Python. Решение будет легким и красивым, обещаю.

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

Представьте: пятница, вечер, вы уже мысленно с бокалом чего-то крепкого и вкусного наслаждаетесь прокрастинацией. Ничего не предвещало беды, но жизни любого администратора наступает момент, когда нужно поиграть в игру "Угадай на каком этаже пропал интернет". И что бы победить непредсказуемость сетевых устройств, умные люди придумали Grafana для визуализации различных метрик, и различные экспортеры этих метрик. В данной статье рассмотрим экспортёр метрик MKTXP, который настраивается в 2 кнопки.

Полагаю, каждый разработчик рано или поздно приходит к мысли о том, что ему есть, что рассказать и чем поделиться. Кто-то даже начинает это делать в том или ином формате. И, конечно, хочется сказать спасибо всем тем, кто отвечает на вопросы на stackoverflow, пишет статьи или делает еще какой-либо контент. Однако быть автором труд весьма специфичный, всегда есть риск, что твой контент не будет полезен или даже интересен. За несколько лет мною было написано около пары десятков статей, а также было начато несколько своих проектов, но все это выглядит на первый взгляд как «работа в стол».

Однако, порефлексировав, я понял, что вся работа, которая не дает ожидаемого результата не напрасна. Как минимум - это опыт, а опыт штука полезная. Никогда не угадаешь, что тебе может пригодится в будущем. К тому же не стоит сбрасывать со счетов накопительный эффект общей массы знаний. Звучит довольно туманно, поэтому приведу пример. Разработка показала мне, как можно копить фрагментированные кусочки знаний долгое время, которые в определенный момент могут сложится в полную картину, а ты будешь удивляться, как не понимал чего-то раньше.

Так о чем это я? Я буду делать личный блог или сайт, на самом деле еще не знаю во что это выльется. Но как показал опрос в моем TG канале, у ребят, как и у меня, есть интерес к тому, как можно сделать и использовать блог, чтобы он приносил тебе пользу в каком-либо виде. Если дело пойдет, то здесь будет целая арка статей. Приступим!

И снова здравствуйте! Продолжаем наш цикл статей о методах сбора данных (Прошлые статьи здесь и здесь). В данной (третьей) статье опубликована сжатая аналитика по двум технологиям сбора на Linux Endpoint на основе проработки наших продуктов по лог-менеджменту и сбору событий.

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

Представьте, что у вас есть Vault и нужно перенести данные из него в другое хранилище. Например, из одного закрытого контура в другой на обычной флешке. Или из одного backend storage в другой. Причём перенести нужно безопасно, не расшифровывая данные в процессе и не раскрывая секреты. В этой статье мы расскажем, как решаем такие задачи в Deckhouse Stronghold — нашем решении для управления жизненным циклом секретов.

Хабр, привет! Я Максим, технический директор в компании Амвера и в этой статье я хотел бы поделиться опытом развертывания кластера kubernetes у облачного провайдера, который под капотом использует OpenStack. В этой статья я хочу пошагово рассказать про путь развертывания, подсветив те места, которые вызвали у меня затруднения.

Привет! Меня зовут Даниил Донецков, я DevOps-инженер в KTS.

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

Мы решили проблему с помощью сервиса Firezone, и в этой статье я хочу поделиться нашим опытом. Сегодня я расскажу о том, как DevOps-юнит KTS:

- внедрил виртуальную сеть в существующую инфраструктуру, состоящую из двух k8s-кластеров и нескольких ВМ в разных облаках;

- обеспечил бесперебойный доступ для более чем 150 сотрудников к веб-сервисам.

Привет, Хабр! Меня зовут Натали Дуботолкова, я старший инженер по разработке безопасного программного обеспечения в Basis. Хочу рассказать о том, как мы задумались над интеграцией работы безопасников непосредственно в процесс разработки и к чему это привело, а также о том, какие методы и инструменты использовали в ходе интеграции и используем сейчас.

Современные распределённые системы требуют надёжных, безопасных и масштабируемых способов управления сетевым взаимодействием между сервисами. Технологии Service Mesh, такие как Istio, предоставляют набор инструментов для решения этих задач. Недавно в экосистеме Istio появилась новая архитектура — Ambient Mesh, предлагающая альтернативный подход к реализации сетевых функций. В данной статье мы рассмотрим, чем отличаются классический Service Mesh и Ambient Mesh в контексте Istio, а также их преимущества и недостатки.

Привет! Меня зовут Антон Бурмаков, я QA Lead в КОРУСе. Со мной Герман Вавилин ( @Decayron85) из команды DevOps. Сегодня расскажем, как мы запараллелили смоук-тесты после мердж-реквестов, встроив их CI/CD и избавились от необходимости поддерживать множество окружений. 

Что в материале: 

Сложности при работе со stateful-приложениями в Kubernetes знакомы многим. Недавно инженеры LinkedIn поделились своим подходом к их решению: они написали собственный Stateful Workload Operator, который базируется на пяти кастомных ресурсах. На сегодня кластеры компании со stateful-системами полностью переведены на новый оператор. Теперь владельцы систем могут сосредоточиться на управлении ими, не думая о сложностях эксплуатации. Под катом — перевод статьи, которую тепло приняли в сообществе.