Comments 10
А что скажете на счёт Rancher?
Он еще определённо сырой, НО ужасно перспективный судя по их репозиторий и активности. Мы начали его использовать для дев окружения, работает стабильно, интересная идея с каталогом готовых стеков (в том числе есть и Kubernetes), но многих вещей не хватает — тома, бекапы (интеграция с convoy), более гибкий service discovery, более гибкий acl, больше авторизаций).
Но да, хотелось бы еще реальные мнения послушать...
Но да, хотелось бы еще реальные мнения послушать...
Я вот тоже гоняю в тестовом режиме. Rancher мне не кажется сырым, чего я не могу сказать про RancherOS… По функциональности он по-моему всё равно на голову выше swarm, с которого я начал эксперименты ещё год назад и который очень вряд ли куда-то разовьётся, так как ограничен Docker Daemon API интерфейсом.
но многих вещей не хватает — тома, бекапы (интеграция с convoy)Это — docs.rancher.com/rancher/rancher-services/storage-service?
более гибкий service discoveryА чего именно Вам не хватает?
более гибкий acl, больше авторизацийЭто да… А кто предоставляет более гибкий acl?
Безусловно Rancher со swarm'ом не идет ни в какое сравнение. У ранчера отличное API и есть CLI утилиты. И идея иметь параллельный docker-compose и rancher-compose — тоже отличная идея (в отличии от того же Kubernetes).
Да, но там всего лишь 2 провайдера, glusterfs (который боязно применять в продакшене) и nfs который тормознутый даже для dev (плюс избыточно). А вот если настроить на хосте convoy с каким-то бекендом, то ранчер по сути не видет это все хозяйство и управлять volumes можно только в консоли хостов. Но подвижки в этом направлении в ранчере идут. Надеюсь вызреет что-то )
Встроенных провайдеров много — это однозначно плюс, но хардкод
К примеру lb.project1.dev.domain.com -> LB разбрасывает запросы на другие стеки (один проект но разные ветки/девелоперы) -> nginx.prj1_user1.dev.domain.com, nginx.prj1_user2.dev.domain.com и тд. Сейчас, чтобы сделать это нужно у каждого nginx сервиса открыть порт на хосте (иначе DNS запись не создать), потом пойти в LB сервис и загнать каждый стек девелопера под правило по хостнейму. Можно использовать alias'ы, чтобы прописывать более удобные DNS, но опять же это возможность отредактировать только первый уровень хостнейма.
Ну безусловный лидер в этой области Amazon ECS с их амазоновскими полиси. Для ранчера конечно такого монстра не нужно, но GitHub провайдер и разграничений на уровне environments явно маловато (например, разные клиенты, но один прод env).
Это — docs.rancher.com/rancher/rancher-services/storage-service?
Да, но там всего лишь 2 провайдера, glusterfs (который боязно применять в продакшене) и nfs который тормознутый даже для dev (плюс избыточно). А вот если настроить на хосте convoy с каким-то бекендом, то ранчер по сути не видет это все хозяйство и управлять volumes можно только в консоли хостов. Но подвижки в этом направлении в ранчере идут. Надеюсь вызреет что-то )
более гибкий service discovery
А чего именно Вам не хватает?
Встроенных провайдеров много — это однозначно плюс, но хардкод
<service>.<stack>.<env>.<domain>К примеру lb.project1.dev.domain.com -> LB разбрасывает запросы на другие стеки (один проект но разные ветки/девелоперы) -> nginx.prj1_user1.dev.domain.com, nginx.prj1_user2.dev.domain.com и тд. Сейчас, чтобы сделать это нужно у каждого nginx сервиса открыть порт на хосте (иначе DNS запись не создать), потом пойти в LB сервис и загнать каждый стек девелопера под правило по хостнейму. Можно использовать alias'ы, чтобы прописывать более удобные DNS, но опять же это возможность отредактировать только первый уровень хостнейма.
Это да… А кто предоставляет более гибкий acl?
Ну безусловный лидер в этой области Amazon ECS с их амазоновскими полиси. Для ранчера конечно такого монстра не нужно, но GitHub провайдер и разграничений на уровне environments явно маловато (например, разные клиенты, но один прод env).
Могу сказать насчёт ранчера пару вещей.
Проблемы с IPSec. Не смотря на все заявления о том, что воздействие минимальное, наблюдаем, что порядка нескольких процентов трафика через manageable network тормозятся. Да так, что nginx кричит матом. Делаешь host network у контейнеров — всё ок. Либо дело в их встроенном load balancer'e, который простой как квадрат и основан на HAProxy, либо в сетевом стеке ранчера (что более вероятно).
Еще часто ранчеру сносит башню при апгрейде контейнеров приложения. Он просто не может выкачать новый образ контейнера и впадает в бесконечный цикл. Но тут может быть дело в самом докере, хотя до ранчера никогда такого не наблюдал. Помогает только ребут всего хоста. Даже перезапуск докер демона не помогает.
Из плюсов:
Благодаря как раз таки автоматическим LB из коробки, позволяет весьма прилично экономить на железе, работая через spotinst.com (это который для амазоновских спот инстов)
Удобный мониторинг и полуавтоматический zero-downtime апгрейд сервисов из коробки.
Никаких плясок с бубном при поднятии ранчера — сами агенты и основной мастер работают как докер контейнеры, т.е. система сама в себе и запускается с двух команд.
Надеюсь, не помрёт со временем.
Проблемы с IPSec. Не смотря на все заявления о том, что воздействие минимальное, наблюдаем, что порядка нескольких процентов трафика через manageable network тормозятся. Да так, что nginx кричит матом. Делаешь host network у контейнеров — всё ок. Либо дело в их встроенном load balancer'e, который простой как квадрат и основан на HAProxy, либо в сетевом стеке ранчера (что более вероятно).
Еще часто ранчеру сносит башню при апгрейде контейнеров приложения. Он просто не может выкачать новый образ контейнера и впадает в бесконечный цикл. Но тут может быть дело в самом докере, хотя до ранчера никогда такого не наблюдал. Помогает только ребут всего хоста. Даже перезапуск докер демона не помогает.
Из плюсов:
Благодаря как раз таки автоматическим LB из коробки, позволяет весьма прилично экономить на железе, работая через spotinst.com (это который для амазоновских спот инстов)
Удобный мониторинг и полуавтоматический zero-downtime апгрейд сервисов из коробки.
Никаких плясок с бубном при поднятии ранчера — сами агенты и основной мастер работают как докер контейнеры, т.е. система сама в себе и запускается с двух команд.
Надеюсь, не помрёт со временем.
Да, IPSec имеет свои плюсы и минусы… А что кричит Nginx? (мне просто для случая если у меня такое начнётся… ибо у меня ненагруженные внутренние сервисы с Nginx вроде бы работают хорошо пока)
Апгрейд контейнеров — это да, чудесато начиная от "продуманности" интерфейса, и заканчивая управляемостью и наблюдаемостью сего чудного процесса. У меня тоже случался вечный цикл обновления из-за падающего образа, к сожалению, даже откатить нельзя, пришлось пересоздавать контейнер с нуля. Но в целом, если настроил, то уже не падало у меня ни разу, так что я пока что всё равно доволен Rancher'ом и тоже очень надеюсь, что проект разовьётся и багов станет поменьше.
Апгрейд контейнеров — это да, чудесато начиная от "продуманности" интерфейса, и заканчивая управляемостью и наблюдаемостью сего чудного процесса. У меня тоже случался вечный цикл обновления из-за падающего образа, к сожалению, даже откатить нельзя, пришлось пересоздавать контейнер с нуля. Но в целом, если настроил, то уже не падало у меня ни разу, так что я пока что всё равно доволен Rancher'ом и тоже очень надеюсь, что проект разовьётся и багов станет поменьше.
Это же перевод
А Nomad не пробовали? Интересны отзывы.
Tutum уже месяц как Docker Cloud.
Sign up to leave a comment.
Контейнеры: Поиски «магического фреймворка» и почему им стал Kubernetes