LINUX.ORG.RU
ФорумAdmin

Динамическая подмена контейнера: оркестрация/без неё, и стоит ли вообще оно свеч

 ,


0

4

Есть небольшой скорее теоретический вопрос, связанный c Docker.

Опишу кратко нынешнюю схему домашнего сервера, на котором крутятся личные и фриланс-проекты: на нём стоит Docker, внутри много контейнеров, и в одном из них - CI/CD система (в данном случае Drone CI, но это непринципиально). Она пересобирает контейнеры по пушу в репозиторий, останавливает старые контейнеры, запускает новые.

Это временной лаг. Небольшой, конечно, но всё равно не нравится.

При этом все контейнеры висят в своих сетях, контейнеры, в которых находится веб-приложение, подсоединяются также к nginx proxy (в данном случае это готовый образ), который их реверсит, а также перегенерирует сертификаты Let's Encrypt.

Соответственно, оптимальный механизм мне видится следующим. Новая пачка контейнеров поднимается (вопрос еще и в том, чтобы без конфликтов со старыми), nginx proxy перецепляет роут на них, старые контейнеры тушатся и удаляются.

Абсолютно точно так умеет Kubernetes и прочие средства оркестрации. Но они все же для другого, оркестрация на один сервер, серьезно? Потому вопрос в том, можно ли это сделать без оркестрации, собственными силами Docker, и если да - то как?

Абсолютно точно так умеет Kubernetes и прочие средства оркестрации. Но они все же для другого, оркестрация на один сервер, серьезно?

Чому бы и нi?

anonymous
()
Ответ на: комментарий от anonymous

Ну это выглядит как неоправданное использование ресурсов - раз. Нынешний сервер даже в его минимальные системные требования не влезает (min 4GB RAM, а у меня всего два, и в целом на десяток Django-приложений этого хватает) - два.

squizduos
() автор топика

Абсолютно точно так умеет Kubernetes

На самом деле нет. Kubernetes сам по себе умеет только половину из того, что ты хочешь: следить за состоянием контейнеров, вести список живых и делать rolling upgrade. Встроенная балансировка нагрузки там тупая. Вот эту логику —

nginx proxy перецепляет роут на них

— ты бы делал отдельным компонентом-прослойкой между k8s и Nginx, которая должна связаться с apiserver’ом, вычитать оттуда список живых подов и динамически переконфигурировать Nginx. К счастью, он уже написан.

Так вот, если первые три пункта ты, может быть, и накостылишь на голом докере вручную, то прослойку между этой вундервафлей и Nginx тебе придётся натурально писать руками заново.

Поэтому бери кубер и впихивай его в свои 2G рамы. В качестве примера минимального кластера посмотри в сторону minikube --vm-driver=none (caveat emptor: minikube создаёт кластер без контроля доступа со смотрящим наружу apiserver’ом, поэтому он годится только как proof of concept).

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Ещё можно посмотреть в сторону service mesh’ей (Envoy, Istio, …), но это ещё более тяжеловесная хрень, чем сам кубер.

intelfx ★★★★★
()

Нжиникс умеет во-первых проверку живых апстримов во-вторых рест апи для руления ими, так что накостылять то что ты хочешь запросто можно, если есть уже работающая инфраструктура то это скорее всего будет быстрее развертки кубов с нуля.

ya-betmen ★★★★★
()

FYI: кубер сам по себе много ресурсов не кушает. Но вот хватит ли под это все 2GB RAM — сомнительно.

sphericalhorse ★★★★★
()

docker swarm умеет в rolling update. Также можно посмотреть в сторону регистрации активных endpoint-ов (контейнеров) сервиса в каком-нибудь consul. Но в целом задача для кубера, конечно. Поднять однонодовый кластер через kubeadm или упоминавшийся выше minikube проблем нет, но он будет сам по себе кушать около 1 гб памяти. (Как минимум один kube-apiserver жрет 500м+).

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.