Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Docker, Openstack... Поможет ли?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Приветствую.
Я уже давненько занимаюсь сетями и виртуализацией на базе VmWare и прочих Xen’ов.
И возник вопрос: может ли как-то системы на базе гипервизоров заменить Docker или OpenStack?
Примерные задачи, которые приходится решать:
1. Разворачивание сетевой инфраструктуры, допустим, 5 машин, разные сервисы (от баз данных до VoIP серверов) с разным количеством сетевых карт, сеть на базе гипервизора. Т.е. вся внутренняя сеть видна только гипервизору, внешний канал просто воткнут в сетевую карту хоста и внешние же адреса могут использовать виртуальные машины (не обязательно все виртуальные машины имеют внешние адреса, а могут ходить в интернет через NAT, построенный во внутренней сети).
2. Задача попроще — просто разворачивать виртуальные машины и раздавать им разные внешние адреса (я немного почитал про сети в Докере — там можно мапить какие-то внешние порты контейнера на порты хоста, но этого часто мало, в идеале — пробрасывать сразу весь контейнер на адрес, отличный от основного адреса хоста).

Собственно, вопросы: может ли мне как-то помочь в этих вопросах как Docker, так и OpenStack? Вопрос самообразования ради, чтобы быть, так сказать в курсе новинок, а то уже начинаю чувствовать себя немного динозавром. Ну или пните в правильные статьи :)

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
1. Разворачивание сетевой инфраструктуры, допустим, 5 машин, разные сервисы (от баз данных до VoIP серверов) с разным количеством сетевых карт, сеть на базе гипервизора. Т.е. вся внутренняя сеть видна только гипервизору, внешний канал просто воткнут в сетевую карту хоста и внешние же адреса могут использовать виртуальные машины (не обязательно все виртуальные машины имеют внешние адреса, а могут ходить в интернет через NAT, построенный во внутренней сети).

С некоторой натяжкой, но попал в точку с одной из возможных (пожалуй, наиболее распространенных) референсных топологий сети в Openstack.

Спотреть примеры можно тут — docs.openstack.org/...example_architecture.html и тут — docs.mirantis.com/...l#choose-network-topology

2. Задача попроще — просто разворачивать виртуальные машины и раздавать им разные внешние адреса (я немного почитал про сети в Докере — там можно мапить какие-то внешние порты контейнера на порты хоста, но этого часто мало, в идеале — пробрасывать сразу весь контейнер на адрес, отличный от основного адреса хоста).

В Openstack «внешние адреса» опеределяются под термином «floating IP». Опять-же, в референсной структуре сети в Openstack у каждого инстанса (клиентской VM) есть свой внутренний IP (из внутренней сети, как инстансы могут сообщаться друг с другом), так и есть возможность назначить floating ip из пула «внешних» адресов.

Если есть опыт работы с AWS, то понять будет проще, сопоставив сетевую модель там и в Openstack.

Насчет Docker’овской сети советов уже надавали, туториалов накидали. Главное понять — для виртуализаци чего тебе нужны эти возможности. Ибо Openstack даст тебе возможность построить полноценное собственное облако, но нужно понимать, что оверхед по ресурсам будет (ибо помимо собственно виртуалок нужно еще содержать немалое количество сервисов самого Openstack). Докер же — даст минимальный оверхед (1-2%), но предназачен несколько для иных задач, ибо это не полноценная (точнее, не «полная») виртуализация.

приветствую.

1. начну с docs.docker.com/articles/networking,

допустим, 5 машин, разные сервисы
в терминах докера можно рассматривать как 5 контейнеров которые просто горизонтально деплоить на новые/доступные хосты. Можно все на те-же
5 машин
развернуть 5ть «копий» сервисов. Появилась мысль, возможно как-то и сам попробую произвести замеры производительности от распараллеливания... Вопрос пользовательских данных через монтированные «Емкости (Volumes)» насколько это все удобно...

2. не рассматривайте Доекровый контейнер как целый Линукс, а просто как одно приложение, то будет проще. Ну а профитов много: изолированные райнтаймы приложений, удобный деплой или мастер/слейв синхронизации, проще с конфигурациями. Это имхо знакомство, Докер в продакшене пока не разворачивал, а за ОпенСтек вовсе ничего сказать не могу, абстрактно — инфраструктура своих облаков.

Точного ответа на вопросы у меня нет, но рекомендую, мне понравились идеи и реализации. А концепт контейнеров рассматривается уже не только в рамках докера, см: www.opencontainers.org

Вот и я пытаюсь понять, можно ли это использовать. Я придерживаюсь идеи 1 задача — 1 сервер. Вот потому и пытаюсь смотреть на Докер в рамках этой концепции. Если получится сделать что-то типа 5 серверов — 5 задач, но в режиме, когда все распараллелены между всеми и есть вариант high-aviability — вообще хорошо станет :)

Сервисы на докере так и строятся, 1 контейнер = один процесс (хотя можно напихать сколько влезет). И работаем с контейнерами как с простыми линукс процессами. Можно например использовать докер контейнера просто как джобы, а можно запускать и в режиме демонов. Фактически и сеть то контейнеру нужна только в случае если этого требует задача.

Сетевые вещи устроены несколько не так, как например инстансы веб-сервисов. И опыт с вебом (явой, дотнетом етц) никак не применим к сетевым вещам.
Посему совет:

От понятия «сервер» нужно уходить в понятие «сервис», тогда Докер станет как раз нужным инструментом
Заканчивается строго на простейшей задаче, когда одному сервису (например iSCSI) нужны jumbo-frame, а другому они противопоказаны.
Аналогично при задаче повысить скорость прокачки по FTP или NFS размножение оного демона не поможет от слова никак.

Можно попробовать создавать группы серверов подходящие под определенный вид сервисов. И деплоить контейнеры на подходящие ноды.

Можно, но контейнеры тут выглядят лишней сущностью. Разве что для секьюрити, но оно тоже сильно условно, т.к. есть куча более старых и простых методов.
Докер (да и текущие реализации OpenStack) хороши в случае, когда нужно быстро деплоить много более-менее одинаковых сетапов, но изначальная настройка каждого сервиса по времени будет существенно дольше, чем его установка в составе операционки ее методами. А при необходимости отстройки по перфомансу под конкретное железо после развертывания может вообще ничего не дать, если вариантов относительно много.

Да, в таком случае возможно лучше взять просто lxc. И работать как с полной виртуализацией.

Невозможно не использовать полную виртуализацию, при этом желая работать с полной виртуализации.

Да, lxc концептуально предоставляет большую свободу, чем docker, но при желании вырваться из юзерспейса, вы все так же будете скованы.

Никто и не говорит что контейнеры могут нам заменить виртуализацию. Просто надо смотреть на конкретные задачи, и думать, какой инструмент будет более приемлем. Серебряной пули нет ©

если коротко
1. Такая возможность как бы есть, но — только если разворачивать докер уже в вирт машине и группировать по сервисам ( voip сервис на одной вирт машине + разбить компоненты — сам сервис, бд, вэб ). Как понятно это гемморой, который не стоит усилий — потому несколько размазывается основной плюс — переносимость.
2. Если ты про форвардинг — то нет.

Docker немного не корректно сравнивать с системами полной виртуализации. Docker нужен для изоляции отдельно взятых процессов. Там немного другие принципы и идеи. Например контейнер не должен хранить состояния и какие либо пользовательские данные. Но думаю все описанное можно без проблем на нем сделать. Как писали ниже, coreos и kubernetes поможет решить большинство проблем.

Например контейнер не должен хранить состояния и какие либо пользовательские данные.
очень даже может, особенно если он data container.

не должен => не желательно, что убедительно не показано.

я и не собирался никого убеждать

зачем писать неправду тогда?

Во первых где я писал неправду? Во вторых это интернет, я тут могу писать все что хочу.

Разворачивание сетевой инфраструктуры, допустим, 5 машин, разные сервисы
так инфраструктуры или сервисов?
OpenStack — это IaaS
Docker — это элемент PaaS

В том то и вопрос, что не хочется привязываться к терминам, а понять, что есть что без marketing bullshit.

не хочется привязываться к терминам
читать книжки, не зная букв? удачи :-)

Вопрос не в этом. Я знаю, что есть термины, и знаю, что разница между этими штуками довольно размыта. Потому как IaaS очень легко может превратиться в PaaS

OpenVZ раньше часто спасал в таких случаях. Но это было во время владения собственными серверами. Сейчас, когда все уходят в «облака», пусть об этом заботится облачный провайдер.

Но если надо строить собственное облако из 3-х и больше физических машин, то стоит посмотреть на OpenStack.

OpenVZ — это примерно тот же уровень абстракции, что и гипервизор. Вот поэтому пытаюсь разобраться с этой штукой.

Нет, это как раз ближе к Docker ибо и VZ, и Docker (и LXC) — контейнеры.

Но концептуальные цели у Docker и OpenVZ — разные, и зачастую OpenVZ преподносят именно как более легковесную альтернативу полной виртуализации.

Скажу только по докеру.
1) Докер — это не совсем тот кейс который, вы описали. Вернее, оно то, можно развернуть, но будет из костылей и подпорок.
2)Сеть в докере — это отдельная история. Вернее истории как таковой особо нет. Есть разные отдельные проекты, которые призваны облегчить работу с сетью в докере, например: weave или pipework. Сами же докеровцы который месяц убеждают людей в issue трекере, что static IP в контейнерах не нужны:) Но, есть подвижки в сторону libnetwork, может что-то из этого выйдет.

Можно упомянуть всякие кубернетисы, CoreOS и т.д., но это уже целые наборы инструментов, их надо рассматривать отдельно.

Советую вам пройти туториалы по докеру, поиграться, что бы понять, что заменить то, что вы описали это задача не докера, имхо!

Спасибо, попробую посмотреть туториалы.

static IP в контейнерах не нужны
Ну как бы DNS есть.

есть, а еще есть такой костыль gist.github.com/...djuk/bd92b5beba2719054dfe
Но я(и не только я), хочу статический ИПшник внутри, как было раньше, и это как бы никому не мешало.

пробрасывать сразу весь контейнер на адрес, отличный от основного адреса хоста

Смотря что вы под «отличный от основного адреса хоста» имете в виду. Если у вас на хосте несколько адресов, и вы хотите положить все порты докеровского контейнера на него, то сделать это просто.
Вообще, субъективно управление сетевыми интерфейсами в докере довольно мутное и неудобное, например для изменения параметров байдингов и проброски нужно стартовать новый контейнер.

Не совсем так. Я размышляю в знакомых аналогиях. Т.е. как бы адрес гипервизора + адреса машин.

Підписатись на коментарі