Мой опыт в области DevOps сосредоточен вокруг нужд компании, занимающейся разработкой платформы для интеграции с маркетплейсами Ozon, Wilberries, Tmall, Яндекс.Маркет и Goods.

Kubernetes

Изначально инфраструктура компании базировалась на Docker Compose / Docker Swarm , но в определённый момент появились основания для перевода её на Kubernetes. Есть опыт разворачивания кластеров с использованием Kubespray и K3s .

С появлением кластера у нас возник ряд проблем, в частности, с локальной разработкой. Я пробовал организовать её на основе локальных миникластеров ( kind , minikube ) с утилитами вроде Tilt и Skaffold , но, в итоге, по ряду причин вернулся к Compose.

В то же время, упаковка приложений в Helm-чарты в некоторой степени упростила управление ими в облаке. Для решения вопроса воспроизводимости конфигурации кластера на уровне приложений я пробовал Helmfile и провайдером Helm к Terraform , и остановился на последнем.

CI/CD

В области CI/CD мой опыт ограничен GitLab и Drone . На каждый проект, который предополагалось использовать в production, был настроен пайплайн, включающий в себя прогон кода через линтеры и запуск всех тестов, сборку нового Docker-образа приложения и разворачивание этого образа на staging и, в дальнейшем, на production серверах. Для хранения образов использовался встроенный реестр GitLab. Dockerfile’ы оптимизировались для сборки production образа.

Drone я заинтересовался, когда обнаружил, что GitLab’овские воркеры могут без проблем выжирать по 10Гб ОЗУ на один воркер. Но в какой-то момент появилась возможность дёшево перенести GitLab на отдельный сервер с кучей ОЗУ, так что вариант с Drone утратил актуальность.

FaaS

Возможность иметь сервер FaaS-сервис в собственном кластере открывает интересные архитектурные возможности. OpenFaaS оказался отличным вариантом, под который довольно просто писать функции. Правда, локально (без кластера) он разворачивается через раз, но внутренний сервер для разработки решил вопрос.

Nix

Другая интересная идея, которой я занимаюсь последнее время — декларативно-конфигурируемые дистрибутивы Linux для использования их в качестве базовых систем, которые не (так) страшно обновлять. К таковым, на сегодняшний день, серьёзно можно отнести только NixOS (не Guix ). Я поддерживаю конфигурацию своей системы в репозитории , но было бы интересно попробовать эту систему для более масштабных задач.

(см. также раздел по Linux в системном администрировании )

---

Иллюстрация

• Заглавная надпись: логотип AWS . Я иногда ориентируюсь на их решения в области веб-сервисов, когда прорабатываю вопросы инфраструктуры. Жаль, что порой их цены оставляют желать лучшего.

• Визуализация инфраструктуры в виде «парящих коробок»: вероятно, я решил сделать что-то подобное просматривая страницы ELK и Vault . Логотипы возле слоёв говорят сами за себя: HCL-скриптами обеспечиваем конфигурации машин ( Terraform ), плейбуками — конфигурации систем ( Ansible ), ресурсами — кластеров ( Kubernetes ), чартами — приложений ( Helm ). Стоит отметить, что порой границы между слоями не такие уж и строгие: к примеру, как упоминалось выше, Terraform’овские HCL-скрипты вполне могут описывать и конфигурацию Kubernetes-кластеров на уровне Helm-чартов.

• Логотипы на слое Helm: чартами можно относительно безболезненно развернуть в кластере и маршрутизатор с автоматическим TLS ( Traefik ), и хранилище секретов с авторотацией ключей ( Vault ), и фичастую среду для контроля исходного кода ( GitLab ), и навертеть на всё метрики для Prometheus .