Когда пришёл на свою первую работу DevOps, столкнулся с полной неконсистентностью управления серверами. Разработчики работали на разных машинах, заходили друг к другу на серверы, мешали друг другу, деплой был ручной, чувствительные данные местами лежали в репозиториях. Начал с отдельного тестового сервера с публичным IP: подключил GitHub Runner и сделал автосборку проектов из test-ветки. Затем убрал необходимость прямого доступа разработчиков к серверу через Telegram-бота: в нём появились логи сборки, адреса и порты сервисов, просмотр контейнеров, управление перезапуском, удалением и повторным развёртыванием проектов. Основой стала единая культура, по которой каждый проект обязан иметь docker-compose.yaml, а бот уже по нему находил контейнеры и управлял ими. Отдельно закрыл вопрос безопасности: бот работал не от root и не из docker-группы, а от ограниченного пользователя с точечно разрешёнными sudo-командами. После этого вынес чувствительные данные из репозиториев, ввёл .env.example и генерацию рабочих .env на сервере, сначала через простое хранилище секретов, позже через БД с шифрованием. Для маршрутизации и тестовых доменов ушёл от ручного nginx-конфига в сторону Traefik с автоматической привязкой доменов и SSL. В итоге получил управляемую тестовую среду с автодеплоем, централизованным управлением контейнерами, доменами и логами, без прямого доступа разработчиков к серверу.

Если будет интересно, разберу отдельно кейс с поднятием продакшен кластера Kubernetes. И подключение его к CI/CD с генерацией helm чартов из .env.example и docker-compose.