Одна команда — и сервер настроен. Я больше не лезу вручную и не повторяю одно и то же десятки раз. Внутри рассказано о том, как Ansible помогает автоматизировать задачи, от настроек до деплоя.

За последний год AI встраивается буквально во всё. Ещё недавно его приходилось отдельно запускать. Теперь он встроен везде. Даже те, кто не ставил себе отдельные плагины, уже взаимодействуют с AI каждый день. Он вшит в SaaS-продукты и работает в фоне. Иногда так, что пользователь об этом вообще не знает.

Вот здесь и появляется первый важный вопрос: Что происходит с твоими данными?

Все мы с этим сталкивались: вроде бы сервис работает, графики зелёные, ресурсы свободны — а пользователи всё равно жалуются. Открываешь мониторинг — CPU в порядке, память не забита, места на диске полно. А люди продолжают писать: «У вас тормозит». Знакомо?
Давайте разберёмся, как настроить мониторинг так, чтобы проблемы ловились сразу — ещё до того, как начнут ломиться сообщения в поддержку.

Если ты пишешь Dockerfile, скорее всего, он работает. Но вопрос не в том, работает ли. Вопрос в другом: будет ли он работать через неделю, на другом сервере, в CI/CD, на чужом железе — и будет ли это безопасно?

Как запускать пайплайн только для нужных веток, хранить секреты в безопасности и управлять окружениями — просто, наглядно, с примерами. Если вы уже настроили первый workflow — самое время сделать его умнее 🚀

Часть 2: Настройка GitHub Actions и GitLab CI – первый workflow и деплой

В первой статье мы разобрались с основами CI/CD: что это такое, зачем нужно и какие инструменты существуют. Теперь пришло время перейти от теории к практике – создадим наши первые рабочие CI/CD-конвейеры на GitHub Actions и GitLab CI.

Часть 1: Основы CI/CD – что это и зачем нужно; обзор GitHub Actions и GitLab CI

В последние годы вы, вероятно, слышали слова "DevOps", "CI", "CD", возможно, даже "GitHub Actions" или "GitLab CI". Но что это всё значит на практике? Нужно ли быть сеньором DevOps-инженером, чтобы с этим разобраться?