Комментарии 27
Очень странное решение, переехать с кубера на компос...
У ребят ни нагрузок, ни задач, ни людей под кубер.
Всё правильно сделали.
Кубер хорошо работает если брать его в облаках, самому же поднимать на голом железе то еще удовольствие, да и стабильность куда ниже.
А вот использовать облака не всегда есть возможность, некоторые клиенты приходят с запросом на определенный хостинг или даже ОС
В облаках есть, собственно, облако, если нет задачи быть независимым от облака - можно и без k8s обойтись. А вот на своем железе самому предоставлять сервисы, когда уже под куб написаны операторы - вот это гемор еще тот. Поэтому как раз на bare metal альтернатив кубу сегодня, по сути, нет. А стабильность напрямую зависит от сотабильности железа, от качества инфраструктуры.
Потом стали искать решение для деплоя в dev‑окружение.
Главное, что нам требовалось, — чтобы каждая ветка был доступна по своему адресу и получала сертификат для https.
Может я неверно понял задачу, но генерацию и обновление SSL сертификатов можно отдать отдельному сервису, причем только на выходе в инет. В локалке общение по http.
Например: в раутере (pfSense) сервис обновления сертификатов.
Да вообще можно просто тупо выписать один wildcard сертификат для всех дев, типа *.test.company.com и генерить локальные урл для тест енвов или хоть для каждой бренчи типа myfeature.test.company.com, и один отдельный сертификат для прод. И все.
Да, у нас сейчас и есть wildcard, от letsencrypt. Но кроме выдачи сертефиката, traefik еще и динамический роутинг дает, смотрит на labels контейнеров и направляет на них трафик.
Ну и еще вот в одном проекте стояла задача, когда нужно было выделить разные поддомены, например by.myfeature.test.company.com . wildcard бы отвалился, но traefik самостоятельно выдал обычный letsencrypt сертефикат
>> Docker Compose не дает возможности ограничить потребление ресурсов в рамках одного контейнера.
https://docs.docker.com/compose/compose-file/compose-file-v3/#resources
Это не работает без swarm
If you want to set resource constraints on non swarm deployments, use
https://docs.docker.com/compose/compose-file/compose-file-v2/#cpu-and-other-resources
Только с v2, но он же устаревший
v1 EOL, v2 только год как в GA вышел: https://www.docker.com/blog/announcing-compose-v2-general-availability/
в вашем docker-compose.yaml из статьи не увидел ничего из за чего нельзя бы было поменять version на 2 и пользоваться спокойно cpu_count & mem_limit из ссылки Романа.
с каким-то обновлением начало работать даже в v3
А ещё тот же самый docker-compose.yml можно скормить в Swarm без изменений.
@dev_family, а зачем нужно было использовать два бинарника на гоу, если тоже самое вроде как можно сделать внутри gitlab-ci.yml без использования утилиты taskfile.dev? И второй вопрос с миграциями БД: как решено то, что некоторые миграции могут сломать работающее приложение? Если такой же процесс деплоя (как в dev) настроен и на проде, то это не очень безопасно. Хотя если процесс деплоя на дев и на прод сильно различаются (например, используют разные инструменты), то это тоже не хорошо.
а зачем нужно было использовать два бинарника на гоу, если тоже самое вроде как можно сделать внутри gitlab-ci.yml без использования утилиты taskfile.dev
Каким образом?
И второй вопрос с миграциями БД: как решено то, что некоторые миграции могут сломать работающее приложение?
Ну это не проблема инструмента деплоя. А вообще если миграция развернулась на деве, то развернется и на проде. Схема базы одинаковая. Не помню с этим никаких проблем
Хотя если процесс деплоя на дев и на прод сильно различаются (например, используют разные инструменты), то это тоже не хорошо.
Инструменты действительно разные, но в целом суть похожа. На проде первичная настройка идет в ручном режиме. Далее уже рабочее приложение обновляется через ci/cd . Это не занимает на самом деле много времени, при этом дает гибкость.
Каким образом?
Если деплой ограничивается docker, можно на целевой машинке выставить порт dockerd наружу и указать джобе для деплоя DOCKER_HOST (технически docker это ведь тоже клиент и сервер). Плюс в том, что на минималках все это настраивается за 5 секунд. Вопросы безопасности для такого решения хорошо описаны в сети и можно городить любой огород в зависимости от ваших потребностей.
Либо, раз у вас gitlab, то можно запустить gitlab-runner на машинках куда собираетесь деплоить - он подтянет артефакты. Остальное решается скриптом для джобы в десяток строчек на bash (и gomplate если нравятся гошные шаблоны).
Ну или по классике: Ansible, Terraform и т.п.
Писать свое может быть полезно, если надо например потренировать команду, чтобы ребята лучше разобрались в нюансах предметной области или языке. Но делать законченное продакшн решение это проект и это дорого, если подходить к вопросу серьезно. Вы это ни когда не окупите. Пользуйтесь готовым.
Но делать законченное продакшн решение это проект и это дорого,
Да, согласен. Но у нас решение получилось чисто под наши задачи, и только для тестового окружения. Работает уже 9 месяцев, без проблем) периодически что-то туда дописываем.
в десяток строчек на bash
Думаю строчек было бы больше. Либо разбивать на множество скриптов. Поднять деплой, очистить, склонировать базу данных, создать базу данных для нового деплоя, крон задачи. Да и крон пришлось бы тогда в системе использовать либо еще что-то изобретать.
А так у нас супер легкий клиент, который почти ничего не делает, и сервер который все умеет, собранный в один бинарник. Внутри него и крон и работа с бд. Не вижу никакого преимущества в скриптах перед этим...
Вообще, за идею я взял кубер как раз. Где есть клиент (kubectl), который по http доставляет конфигурацию на сервер, а он уже с ней работает
Значит вам просто пока не нужен Кубер. На Docker compose можно реализовать плавное обновление приложения без простоя. Прочитайте про стратегии деплоя в этом окружении и как они реализуются.
Вообще, когда сложность приложения и требования к стабильности увеличиваются - docker compose превращается в ад. Но думаю к тому времени у Вас появятся деньги на DevOps специалиста.
Честно говоря, я так и не понял, чем не подошел docker swarm
В процессе мы выяснили, что Kubernetes не подходит для всех наших задач и потребностей. Его поддержка требовала больших дополнительных усилий и времени, а также значительного количества вычислительных ресурсов.
о чем идет речь ? Какие такие значительные ресурсы требует Kubernetes ?
Для надежной работы кластера Kubernetes, требуется минимум 3 ноды, у нас была только одна.
вы не поверите, для надежной работы любого кластера нужно больше одной ноды и записывать это в минус кубику как то странно
Устав бороться с постоянными проблемами и сложностью Kubernetes, стали искать альтернативу. Рассматривали Swarm и другие решения, но ничего лучше чем Docker Compose не нашли. На нем и остановились.
из статьи так и не понял в чем заключалась сложность. У вас был managed k8s или сами поднимали на bare metal ? Если сами и без экспертов - то зачем, если managed то какие сложности ? И да, docker compose ни разу не альтернатива kubernetes. Абсолютно разные продукты с разными решаемыми задачами и возможностями
Быстрое развитие Kubernetes и сложности, связанные с его обновлением.
ну никто же не заставляет быть on the edge и обновляться каждые полгода. В группе по kubernetes люди иногда пишут что до сих пор используют 1.13
Как и написано в статье, кубер поднимался через microk8s. Для дева можно было бы перейти на managed, но это дополнительные деньги. А клиенты многие приходят с требованиями по хостингу/ос . Там нет возможности взять managed решение.
По поводу ресурсов. После перехода с кубера нагрузка упала в 2 раза. Может дело в microk8s, а может в самом кубере.
вы не поверите, для надежной работы любого кластера нужно больше одной ноды
Дело в том, что для 95% клиентов кластер то и не нужен, 4/8 сервер справляется с нагрузкой. И на одной ноде компоуз работает без проблем, с кубером постоянно проблемы были. То крон зависнет намертво, то еще что-то.
ну никто же не заставляет
А потом выясняется, что есть проблемы с безопасностью. Например, по такому пути :10255/pods кубер светил env переменные и другие данные подов. Да и в целом, вносятся изменения, которые облегчают жизнь.
И да, docker compose ни разу не альтернатива kubernetes.
Согласен, но базовая задача управление контейнерами докера, чем оба инструмента и занимаются. Конечно, кубер это комбайн с кучей функций, которых лишен компоуз. Но не всем они нужны. Ну и в целом, чем система проще, тем она надежнее)
Дело в том, что для 95% клиентов кластер то и не нужен, 4/8 сервер справляется с нагрузкой.
Т.е. клиентам плевать на доступность их сервисов. А когда сервер выходит из строя, например сгорела мать/проц/диски. Что клиенты делают ?
Ну точно так же из строя может выйти облачный managed сервис. Или если развернуть кубер руками, взять 3 ноды, то и все 3 могут сгореть, в одном большом пожаре.
По факту, современные сервера очень надежные, и просто так из строя не выходят, возможно в очень редких случаях.
Ключевое же в такой ситуации сохранить именно данные (бд и файлы), но это уже другая большая тема. К тому же куберу обычно базу разворачивают отдельно. Точно так же можно сделать и для компоуза.
Публикации
Миграция из Kubernetes в Docker Compose