DevOps *

С каждым новым спринтом кажется, что ты просто двигаешь тикеты по доске?
Не только тебе. Когда задачи теряют смысл, проект буксует, а мотивация тает где-то между дейликом и очередными «небольшими изменениями — вот здесь, здесь и здесь», возникает закономерный вопрос: где же те самые большие задачи, в которых хочется быть? Где простор для роста, свободы и влияния?

Если честно, мы знаем ответ. Но ведь так неинтересно! Поэтому мы нарисовали комикс о том, как карьерный тупик трёх IT-специалистов — разработчика, аналитика и DevOps-инженера — внезапно превращается в портал, за которым их ждут испытания: Legacy-Хаос, техдолг и поток данных, грозящий поглотить всё живое. Чтобы пройти их, героям понадобятся не суперсилы, а кое-что куда важнее: автоматизация, гибкие подходы и возможность делать то, что имеет значение. Погружаемся в комикс — и проверим, что будет, если карьерным мечтам действительно дать пространство для развития.

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

Когда нужна полноценная среда для CI/CD, но нет времени на развёртывание инфраструктуры с нуля, контейнеризированный GitLab становится быстрым и удобным решением. В этой статье покажем, как развернуть локальный GitLab и GitLab Runner через Docker и Docker Compose, избежать распространённых ошибок на старте и настроить базовый пайплайн за минимальное время.

Всё началось с того, что в 2024 году мне в руки попал интересный экземпляр мини-ПК ( Характеристики: Процессор Intel N100 / RAM 16 GB / SSD 500 GB.) решив, что раз уж основная рабочая лошадка у меня уже есть, этот мики-ПК предстоит переделать в мини-сервер и приспособить к мои pet-проектам. Заказал себе 1Гбит интернет, белый IP адрес и ушел творить.

Первая моя задумка с треком провалилась, т.к изначально я разместил на нем Gitlab Server, NextCloud и пару своих приложений. «Жужжал» он не по-детски, я взаправду подумал, что в какой-то момент он просто отлетит к своим небесным производителям.

В Kubernetes важно правильно настроить StorageClass, чтобы эффективно использовать место для хранения данных приложений. Выбирать StorageClass по умолчанию можно вручную, но такой способ часто приводит к ошибкам и усложняет работу. В статье расскажем, почему ручной способ — не самый удобный, и покажем подход, который реализовали в Deckhouse. Он помогает проще и надёжнее управлять хранением данных.

Пишу про полезные материалы про IT, и собираю свой ламповый нетворкинг тут - https://t.me/+434aQiGpZtAyNTU6. Присоединяйтесь!

Оглавление.

Poetry вместо pip, Ruff вместо flake8, FastAPI вместо ручной документации. Что реально упрощает жизнь Python-разработчику сегодня — на примерах и с реальными конфигами.

Когда я был маленьким и глупым, в своей домашней лаборатории я развернул kuber‑barick — его возможностей хватало на баловство с нейронками и обучением крутить поды, но при попытке поднять второй (например, для стейджинга) всё упёрлось в дефицит железа. Решил перейти на более автоматный подход: наткнулся на Talos и Cluster API (CAPI).

Процесс DevOps включает несколько ключевых этапов: разработку, сборку, тестирование и выпуск в продуктивную среду. После тестирования важно пометить артефакт (например, образ Docker) в доверенное хранилище, чтобы каждый пользователь мог быть уверен в подлинности загруженного контента.

Проект Notary, спонсируемый Docker, обеспечивает высокий уровень доверия к цифровому контенту с помощью криптографических подписей. Он гарантирует, что контент не изменен без одобрения автора и что его происхождение подтверждено.

Notary позволяет системам, таким как Docker Enterprise Edition (EE) с Docker Content Trust, устанавливать политику использования только подписанного контента при развертывании. Это делает Notary важным элементом безопасной цепочки поставок Docker, интегрируя безопасность на всех этапах работы.

Давайте посмотрим подробнее, как работает Notary и как его можно использовать на практике.

В феврале мы запустили спецпроект «Честные вакансии: DevOps Middle» — это серия вебинаров с экспертами из BigTech-компаний. Эта статья — краткий конспект вебинаров с экспертами Инфосистемы Джет, K2 Cloud, ЛАНИТ и AvitoTech. В ней мы постарались ответить на ключевые вопросы — требования к DevOps-инженерам, особенности работы, советы по собеседованиям и полезные ресурсы.

Я устал писать бойлерплейт и базовые стили. В итоге заставил ИИ делать это за меня. Результаты, размышления и откровения — внутри.

Мы — команда студентов из ИТМО, которая прошла путь от хакатонов до продуктовой разработки. На собственном опыте расскажем, как выстроили инфраструктуру, способную масштабироваться, переживать сбои и не стоить, как полкоманды в найме.

Когда вы только начинаете делать стартап, инфраструктура кажется чем-то второстепенным. Важнее MVP, фичи, дизайн, пичдек. Но в какой-то момент всё внезапно перестаёт помещаться на одном сервере, руками деплоить становится больно, SSL не обновляется, а продакшн падает из-за перегрузки или забытого docker-compose up.

Kubernetes? Слишком сложно, долго и дорого. Монолит? Неудобно масштабировать. Мы искали третий путь — и нашли его.

Введение в MLflow: настройка и запуск

Привет, Хабр! Я Александр Кузьмичёв, специалист по анализу данных и машинному обучению в ПГК Диджитал. Мы в компании занимаемся разработкой цифровых продуктов для железнодорожных грузоперевозок. Ранее я рассказывал о том, как открытая платформа MLflow помогает нам в работе.

В этой серии статей я хотел бы поделиться с вами увлекательным путешествием в мир MLflow, Optuna, AutoML и развёртывания моделей с помощью MLflow.

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

Сегодня официально выпустили очередную версию Kubernetes — 1.33. Собрали все 64 изменения в одном материале. Из основных нововведений: упорядоченное удаление ресурсов в пространстве имён на основе логических зависимостей и соображений безопасности, декларативная валидация для нативных API-типов, расширение механизма CredentialProvider, доступ подов к информации о топологии кластера, изменение алгоритма выдержки CrashLoopBackOff, обязательная аутентификация при извлечении private-образов из репозиториев и многое другое.

Piklema Predictive — российская компания, разрабатывающая решения для оптимизации горного производства через анализ данных диспетчеризации, цифровые советчики, MES-систем и планирования. За 4 года сотрудничества AvantIT выполнил три миграции их инфраструктуры между облаками (Azure → AWS → GCP → Azure), внедрил Kubernetes и настроил мониторинг, что позволило клиентам Piklema снизить затраты на производство на 15–20%.

Проблема:

Piklema столкнулась с двумя критичными ограничениями. Во-первых, их инфраструктура на Docker Compose не обеспечивала отказоустойчивость, требуемую промышленными заказчиками. Во-вторых, зависимость от грантов вынуждала ежегодно менять облачного провайдера, что приводило к ручным миграциям длительностью до 2 месяцев. Отсутствие мониторинга усугубляло риски: о нехватке ресурсов (например, места на диске) узнавали только после сбоев.

Цель проекта:

Создать гибкую, отказоустойчивую инфраструктуру, которую относительно просто переносить между облаками при завершении гранта. Она должна...

DevOps‑метрики — это количественные показатели, которые позволяют оценить эффективность, производительность и общее состояние DevOps‑процессов. Они предлагают аналитический взгляд на конвейер поставки программного обеспечения, позволяя командам разработчиков выявлять проблемные места, повышать производительность и принимать решения на основе реальных данных.

В этой статье мы поговорим о важности мониторинга DevOps‑метрик и о том, что именно нужно отслеживать. От широко известных метрик, которые приобрели статус стандартных благодаря DORA (DevOps Research and Assessment), до других важных индикаторов — мы предлагаем вашему вниманию исчерпывающее руководство, которое поможет вам измерить и оптимизировать ваши DevOps‑практики.

История Kubernetes

 7 июня 2014 года был выпущен первый выпуск Kubernetes

Kubernetes позволяет разработчикам самостоятельно разворачивать приложения, а системным администраторам, автоматически отслеживая
и перемещая эти приложения в случае аварийного сбоя оборудования

Kubernetes на греческом языке означает «кормчий» или «рулевой» (лицо, держащее рулевое колесо корабля).

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

Процедура развертывания приложений через Kubernetes всегда одинаковая, независимо от того, содержит ли кластер всего несколько узлов или тысячи. Размер кластера не имеет никакого значения. Дополнительные узлы кластера просто представляют собой дополнительный объем ресурсов, доступных для развернутых приложений.

 Основные понятия в Kubernetes

 Кластер – это несколько серверов, где нужно развернуть наше приложение.

Под (pod) – минимальный элемент развертывания в Kubernetes, который состоит из одного или нескольких контейнеров, работающих на одном компьютере. Контейнеры внутри пода работают по одному IP-адресу
и могут обмениваться информацией через доступную в контейнере директорию (том, volumes).

Сервисы (Service) – соединяет поды, которые объединяются в группы
с постоянным IP-адресом и балансирует нагрузку между ними.

У меня была задача, сделать reverse proxy, который будет проксировать трафик и для определённых доменов выпускать новые сертификаты налету, а для некоторых нужно просто автоматически выпустить сертификат.

Для такой задачи идеально подходит Caddy.

Уже на этой неделе, 25 апреля в пятницу, в Екатеринбурге пройдет DUMP — одна из самых масштабных ИТ-конференций на Урале. В этом году у нас 11 тематических секций, включая новенькую TechLead, отдельный трек для круглых столов и воркшоп от Андрея Цветциха. Рассказываем детальнее о программе: 

Backend — пройдет в двух параллельных треках. Будет больше докладов, Андрей Цветцих проведет воркшоп «Паттерны асинхронного взаимодействия в распределённых системах», Юля Волкова поможет справиться со страхом триггеров, а Максим Стаценко покажет, как сделать максимально дешёвый Statefull процессинг с 1кк RPSа. Также обсудим за круглым столом, кто должен исправлять срочные баги, если работа над проектом уже закончилась...

Про информационную безопасность Kubernetes-кластеров много пишут с позиции специалистов ИБ. Но полезно взглянуть на эту тему глазами обычных пользователей K8s — инженеров и разработчиков. Тех, кто много работает со своими приложениями в подах, но не управляет служебными частями кластера.

Большинство стандартов безопасности описывает лучшие практики настройки управляющих компонентов — control plane. Нечасто встречаются рекомендации по грамотной настройке рабочих единиц — подов. В статье попробуем восполнить этот пробел. Выполним обзор источников, рассмотрим хорошие практики работы с образами. Изучим, как ограничить привилегии контейнера и почему это важно. Поговорим о инструментах автоматической проверки манифестов и разберем примеры GItlab CI пайпланов.