DevOps *

Всем привет!

В первой части мы в общих чертах посмотрели на различия GitHub Actions и GitLab, а также начали разбирать структуру файла .gitlab-ci.yml.

В этой части продолжим разбираться с параметрами и особенностями конфигурации: триггеры, job’ы, артефакты и многое другое.

Не понимаете, «что тут происходит»? Рекомендую начать с первой части:: по ссылке.

Если вам интересны подобные материалы, подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков, полезными инструментами и практическими примерами из реальных проектов. А прямо сейчас у нас там ещё и проходит новогодний розыгрыш.

Каждый второй заказчик приходит с запросом «нам нужен AI‑агент». На вопрос «а что именно он должен делать?» обычно следует пауза и что‑то вроде «ну, чтобы как ChatGPT, но наш, и чтобы работал».

Окей.

Проблема в том, что между «чат‑ботом с GPT» и «AI‑агентом» — пропасть размером примерно в полгода разработки и массу седых волос. И нет, дело не в том, что агент — это какая‑то магия. Дело в том, что это инженерная система со своей архитектурой, компонентами и подводными камнями.

Эта статья — попытка разложить по полочкам, из чего состоит AI‑агент. Без маркетингового булшита про «революцию в бизнесе» и «цифровую трансформацию». Просто архитектура, компоненты, код, грабли.

Предположим, вам необходимо мигрировать ваш кластер k8s в другой vlan или просто сменить ip адреса. Насколько это необходимо каждый решает сам. Будем считать, что перенос нагрузки ямлами на другой кластер затруднён или у кластера специфические настройки.

В качестве начальных условий: кластер on prem с root доступом на узлы, установлен через kubeadm или kubespray, в качестве cni calico. В нашем случае под ногами ubuntu в качестве системы. Если у вас кластер установлен the hard way , то статья вам не нужна, вы сами всё умеете.

В какой-то момент своей жизни, я стал понимать, что мне все сложнее справляться с информационным давлением. О чем речь? Что за давление? Может вы заметили, что сейчас, как говорится, «из каждого утюга» льется большой поток информации, которую стало не просто фильтровать. И далее по списку: социальные сети, мессенджеры, email почта, банковские приложения, реклама, интернет журналы, телевизор, ютуб, короткие ролики (да, это стоит выделить отдельно), звонки с телефона, СМС, музыка, фильмы, подкасты, радио, куча подписок (и это отдельно).  Если вы трейдер или как то связаны с рынком, то еще и это. Может еще что упустил , но суть в общем в том, что очень много источников информации, которые требуют нашего внимания. Что же делать?

Привет, Хабр. Меня зовут Никита Лепёхин. Я DevOps-инженер в СберЗдоровье — MedTech-компании №1 в России.

Многие компании пользуются GitLab в качестве инструмента CI/CD. Но при использовании бесплатной Community-версии он не даёт достаточную наблюдаемость всех запускаемых пайплайнов. Поэтому актуальной задачей становится поиск инструмента для анализа GitLab CI/CD. Наш выбор для её решения — Apache DevLake.

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

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

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

Технический долг это не только «плохой код». Это любая работа, которую нужно сделать сейчас, чтобы избежать больших затрат в будущем.

Привет, Хабр. Расскажу, как за 10 часов написал self-hosted аналог ngrok на Go.

Проблема

Нужно протестировать вебхук от Т-Банк/Telegram/любого внешнего сервиса. Запускаешь ngrok — не работает. Россия заблокирована. Каждый раз VPN, а с ним становится недоступна часть внутренних ресурсов. В какой-то момент решил написать своё.

Разворачивать приложения в облаке должно быть просто. Но на деле - всё наоборот. Вместо “вжух-вжух и в продакшн” получаем вечер с документацией, пляски с параметрами Terraform и постоянную проверку, правильно ли связались ресурсы.

В статье разберемся, как от использования UI консоли приходят к Terraform, и как OpenIDE позволяет вернуть легкость UI консоли при работе с Terraform.

Привет, Хабр! Я Даниил Салман, техлид по контейнеризации. Эта статья написана по мотивам моего доклада для конференции DevOops. Разберёмся, как сделать такую ML-«песочницу», где Data Scientist пишет код, а всё остальное (установка драйверов, выделение ресурсов, деплой и тренировка модели, сбор метрик) уже настроено на бэкенде. Написали максимально просто и доступно, чтобы понять смог даже человек с минимальным погружением в тему. Идеи из этой статьи можно применять в любой инфраструктуре — важно лишь понимать основы: как работает k8s-кластер, Docker и python-фреймворки. Итак, поехали!

Разработка сервисов с интеграцией в AWS быстро упирается в компромиссы: либо работать с реальным облаком и платить за каждый эксперимент, либо замокать инфраструктуру и надеяться, что в продакшене всё «взлетит». В статье показано, как с помощью .NET Aspire и LocalStack выстроить полноценное локальное AWS-окружение — с S3, CDK и реальной оркестрацией — так, чтобы один и тот же код без условностей работал и локально, и в проде.

Когда мы впервые увидели AI-чаты, это выглядело впечатляюще. Они писали код, помогали с документацией, объясняли архитектурные решения.

Это было хорошо. Но довольно быстро стало понятно главное:

Всем привет!

Так вышло, что в месте, где я преподаю и занимаюсь менторством стажёров, начался переход с GitHub-репозиториев на GitLab, развёрнутый на собственных серверах. Пока что перенесли не все проекты, но даже этого оказалось достаточно, чтобы у стажёров возникло немало вопросов — особенно в части настройки CI/CD-процессов.

Формально CI/CD в GitHub и GitLab решают одну и ту же задачу, но на практике подходы, терминология и детали конфигурации отличаются. Из-за этого попытки «сделать как в GitHub Actions» часто приводят к путанице и ошибкам.

У меня уже есть статья про CI/CD и workflow, но она целиком посвящена GitHub Actions. Чтобы сократить количество вопросов, разночтений и бессонных ночей у стажёров, я решил написать отдельную статью про CI/CD именно в GitLab — с учётом его особенностей и типичных подводных камней.

Если вам интересны подобные материалы, подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков, полезными инструментами и практическими примерами из реальных проектов. А прямо сейчас у нас там ещё и проходит новогодний розыгрыш.

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

Согласитесь, что встретить Новый год рядом с семьёй и друзьями - намного приятнее, чем сидеть за ноутбуком в 02:40 и с квадратными глазами разбираться, почему “что-то там легло”, а доступ к нужным секретам остался только у одного человека… который как раз в этот момент режет оливье и не слышит телефон.

Ниже я делюсь своим чеклистом из 8 пунктов. Он помогает спокойно уйти в праздники и не проводить их в обнимку с ноутом. А после прочтения, в комментах, обязательно поделитесь что бы вы еще добавили.

В статье подробно разбираем, как устроен CSI (Container Storage Interface), как проходит жизненный цикл тома от PVC до удаления и что на самом деле делают sidecar-контейнеры и драйверы.

Мы ожидали увидеть очередную «легкую» модель для телефонов, а нашли hidden gem, который генерирует учебные материалы лучше, чем модели в 100 раз больше. Подробный разбор с JSON‑ами, промптами и сравнением.

В начале 2010-х в профессиональном сообществе разработчиков и архитекторов распределенных систем широко обсуждалась идея, что мир баз данных вступает в новую эру. На фоне успехов крупных интернет-сервисов термин BASE начал использоваться как противопоставление классическому ACID. Хайп вокруг NoSQL, CAP-теоремы и масштабируемых систем породил лозунги вроде «SQL умер», «ACID — для банков, а мы делаем веб», «eventual consistency — это нормально».

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

Что же произошло? Была ли «битва ACID и BASE» реальным технологическим разломом или лишь отражала ограничения своего времени? 

В этой статье мы разберём, как возникли ACID и BASE, почему BASE быстро стал популярен и что на самом деле означает тезис «победил ACID» в 2020-е годы.

Привет! С вами Максим Бурцев, руководитель отдела мониторинга в Купере. Пусть название отдела не вводит вас в заблуждение: мы занимаемся не только мониторингом, но и остальными процессами, которые связаны с инцидентами. До, во время и даже после того, как проблемы решены. Сегодня хочу поделиться опытом внедрения нетривиальных инструментов и методов, которые сделали наши процессы удобными, понятными и эффективными.

Мы доверили ИИ первым реагировать на критические инциденты в продакшене. Это сократило время реакции, но одна его галлюцинация едва не отправила весь кластер в ребут...

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

Меня зовут Дима Синявский, я SRE-инженер в Ви.Tech — это IT-дочка ВсеИнструменты.ру. В этот раз я решил помочь вам посмотреть на свою работу в отношении надежности. Особенно полезно будет тем, у кого официально нет SR-инженеров в штате.

"У нас нет SRE" – не значит "у нас нет надёжности". Даже без SRE-инженера ваша команда уже что-то делает для надёжности.

Покажу, как увидеть уже существующие у вас практики и понять, куда двигаться дальше.