Нужны-ли контейнеры (Docker) в Azure Service Fabric
От: Stalker. Австралия  
Дата: 06.11.18 06:13
Оценка:
Довольно много документации на тему контейнеров в Azure Service Fabric (микросервисная архитектура), но от меня ускользают конкретные примеры того, где они лучше, чем просто сервисы.
Пока единственное четкое различие какое я нашел — это управление ресурсами, т.е. контейнеру я могу указать сколько именно ресурсов он может потребить, а обычному сервису такие установки недоступны.
В документации упор делается на "самодостаточность" контейнеров, типа он имеет все необходимые файлы и зависимости. Кто-нибудь может преивести конкретный пример, где это-бы имело значение в сравнении с сервисами? Какие-такие зависимости могут поломаться при деплойменте сервиса без контейнера в Service Fabric?
Существуют-ли еще какие-то плюсы?
Re: Нужны-ли контейнеры (Docker) в Azure Service Fabric
От: Artem Korneev США https://www.linkedin.com/in/artemkorneev/
Дата: 09.01.19 20:40
Оценка:
Здравствуйте, Stalker., Вы писали:

S> Какие-такие зависимости могут поломаться при деплойменте сервиса без контейнера в Service Fabric?


Azure Service Fabric это технология, основанная на контейнерах. Там, правда, не Docker, а похожий по функционалу контейнерный движок от MS.
Т.е. вы не сможете задеплоить что-либо на Azure Service Fabric без контейнера. Там все это сделано прозрачно, но когда вы делаете деплоймент, то там все упаковывается в контейнер и выкладывается на кластер Azure Service Fabric.

Я последний год не следил за новостями от ASF, но если зашла речь о докере, то это наверняка просто поддержка докеровских контейнеров, т.е. дают выбор — контейнеризация от MS или докер. Варианта без контейнеров там нет.
Преимущества контейнеров от ASF в лучшей чем у докера "плотности" размещения сервисов, но пока MS раскачивалась с продвижением ASF, Docker стал стандартом де-факто, поэтому могли добавить его поддержку.

Внутри MS оно (ASF) существовало за несколько лет до выпуска в массы (~2014?..), под названием "Windows Fabric". Но почему-то протормозили с продвижением в массы и нишу успел занять Docker.

S> Кто-нибудь может преивести конкретный пример, где это-бы имело значение в сравнении с сервисами?


Azure Service Fabric это технология кластеризации, т.е. простой пример — оно раскидывает экземпляры сервиса по нодам кластера прозрачно для вас. Предоставляет дашбоард для мониторинга "здоровья" кластера, и т.д.
С уважением, Artem Korneev.
Отредактировано 10.01.2019 17:10 Artem Korneev . Предыдущая версия .
Re[2]: Нужны-ли контейнеры (Docker) в Azure Service Fabric
От: Sharov Россия  
Дата: 10.01.19 10:26
Оценка:
Здравствуйте, Artem Korneev, Вы писали:

AK>Варианта без контейнером там нет.


А почему?
Кодом людям нужно помогать!
Re[3]: Нужны-ли контейнеры (Docker) в Azure Service Fabric
От: Ночной Смотрящий Россия  
Дата: 10.01.19 10:35
Оценка: 6 (1)
Здравствуйте, Sharov, Вы писали:

AK>>Варианта без контейнером там нет.

S>А почему?

А потому что суть SF в автоматическом разворачивании нужного количества нод. Альтернативой контейнеру только полный образ, но это сильно более тяжелое решение.
Re[3]: Нужны-ли контейнеры (Docker) в Azure Service Fabric
От: Artem Korneev США https://www.linkedin.com/in/artemkorneev/
Дата: 10.01.19 17:09
Оценка:
Здравствуйте, Sharov, Вы писали:

AK>>Варианта без контейнеров там нет.

S>А почему?

Ну наверное потому, что Azure Service Fabric это контейнерный движок для кластеризации.
С уважением, Artem Korneev.
Re[2]: Нужны-ли контейнеры (Docker) в Azure Service Fabric
От: Stalker. Австралия  
Дата: 13.01.19 23:30
Оценка: +1
Здравствуйте, Artem Korneev, Вы писали:

AK>Т.е. вы не сможете задеплоить что-либо на Azure Service Fabric без контейнера. Там все это сделано прозрачно, но когда вы делаете деплоймент, то там все упаковывается в контейнер и выкладывается на кластер Azure Service Fabric.


AK>Я последний год не следил за новостями от ASF, но если зашла речь о докере, то это наверняка просто поддержка докеровских контейнеров, т.е. дают выбор — контейнеризация от MS или докер. Варианта без контейнеров там нет.


в документации вообще-то написано что без явного использования контейнеров приложение хостится в процессе:

In addition to making it easy to provide all of your application's dependencies it needs to run in different computing environments, security and resource isolation are important benefits of using containers with Service Fabric--which otherwise runs services in a process.

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-containers-overview
Re[3]: Нужны-ли контейнеры (Docker) в Azure Service Fabric
От: Artem Korneev США https://www.linkedin.com/in/artemkorneev/
Дата: 15.01.19 21:43
Оценка:
Здравствуйте, Stalker., Вы писали:

S>в документации вообще-то написано что без явного использования контейнеров приложение хостится в процессе:


Ну тут я не в курсе, что имеется в виду.
Если создавать приложение в Visual Studio с установленным Azure Service Fabric SDK, то сервис для ASF создается по шаблону, сразу с контейнером. И при сборке/отладке оно автоматически упаковывается в их контейнерный формат.
С уважением, Artem Korneev.
Re: Нужны-ли контейнеры (Docker) в Azure Service Fabric
От: Михаил Романов Удмуртия https://mihailromanov.wordpress.com/
Дата: 25.01.19 08:42
Оценка: 14 (2)
Здравствуйте, Stalker., Вы писали:

S>Довольно много документации на тему контейнеров в Azure Service Fabric (микросервисная архитектура), но от меня ускользают конкретные примеры того, где они лучше, чем просто сервисы.

S>Пока единственное четкое различие какое я нашел — это управление ресурсами, т.е. контейнеру я могу указать сколько именно ресурсов он может потребить, а обычному сервису такие установки недоступны.
Откровенно говоря, я тоже не до конца понимаю, почему так усиленно хватаются за контейнеры.

S>В документации упор делается на "самодостаточность" контейнеров, типа он имеет все необходимые файлы и зависимости. Кто-нибудь может преивести конкретный пример, где это-бы имело значение в сравнении с сервисами? Какие-такие зависимости могут поломаться при деплойменте сервиса без контейнера в Service Fabric?

S>Существуют-ли еще какие-то плюсы?
Из обсуждений с коллегами и чтения разных источников я для себя вынес следующее:
1. Упрощение развертывания сервисов в разнородной среде (это про самодостаточность). Т.е. если у вас для всех сервисов требуется одно и то же окружение (одна версия фреймворка, один набор установленных системных и third-party продуктов, ...), то для вас этот пункт не актуален.
А вот зато когда для части сервисов нужно одно, для другой — немного отличное, для третьей — вообще что-то свое... вот тогда контейнеры позволят вам на одной машине развернуть любые сервисы — каждый со своим окружением.

2. Идентичность сред (тоже про самодостаточность). Т.е. как минимум в теории (а коллеги говорят, что у них эта схема вполне работает на практике) вы используете одни и те же образы на Dev-, Test-, Stage-, Prod-, ... окружениях. И у вас уже нет проблемы, что окружение на Prod и на Test — разное. И как следствие принцип "у меня на машине всё работает" легко переносится на все остальные стенды.

3. Дополнительный уровень изоляции. Вот тут я пишу вообще голую теории, потому что не вдавался в подробности. Но суть в том, что если злоумышленник через некий бэкдор в вашем коде, смог, например, внедрить на машину, где развернут сервис свой исполнимый код и запустить его, то в случае контейнера он всё равно окажется в изолированном окружении и навредить сможет только одному экземпляру сервиса. Остальные продолжат работать, как и работали.

4. Отдельный, специфичный для Docker момент (у других систем это не обязательно будет, хотя какие есть системы контейнеризации кроме Docker сейчас, я не знаю) — образы создаются на базе других образов. Т.е. можно иметь целое "дерево" образов с общим "корнем" — это тоже заметно упрощает поддержку идентичности

Другое дело, что и минус на текущий момент хватает.
1. Контейнер жрет заметно больше ресурсов, чем обычный процесс. Причем, в процессе эксплуатации начинают всплывать, например, такие моменты: чем длиннее цепочка образов на базе которой создан текущий запущенный экземпляр, тем больше накладных расходов. Я сам не проверял, но коллеги говорят, что если взамен цепочки из нескольких образов сделать один образ (одной операцией compose), то разница в потреблении будет заметна просто на глаз. А это значит, больше число запущенных экземпляров на 1 физическую машину.
2. У Windows контейнеров (я имею в виду Docker for Windows, то что говорят о неких не-Docker контейнерах в Windows — увы, я не нашел никакой толком информации о них. Такое ощущение, что публичного API для них просто нет) есть куча проблем, которые, я надеюсь, есть следствие их относительной молодости. Например, я так и не смог добиться нормального "проброса сети" из контейнера в хостовую ОС. Т.е. не меняя настройки просто запускаю/останавливаю экземпляры контейнера — связь с приложением в контейнере, то есть, то нету. Причем никакой вразумительной диагностики тоже нет...
Я искренне полагал, что это лично мое неумение, но опять же поговорив с коллегами, узнал, ситуация считается чуть ли не нормой (причем, как я понял она не связана с Windows только). И считается вполне себе решением поднять экземпляр контейнера, проверить, что связи нет, грохнуть и поднять заново...
Re[2]: Нужны-ли контейнеры (Docker) в Azure Service Fabric
От: Vetal_ca Канада http://vetal.ca
Дата: 28.01.19 17:01
Оценка: 10 (1)
Здравствуйте, Михаил Романов, Вы писали:

МР>Другое дело, что и минус на текущий момент хватает.

МР>1. Контейнер жрет заметно больше ресурсов, чем обычный процесс. Причем, в процессе эксплуатации начинают всплывать, например, такие моменты: чем длиннее цепочка образов на базе которой создан текущий запущенный экземпляр, тем больше накладных расходов. Я сам не проверял, но коллеги говорят, что если взамен цепочки из нескольких образов сделать один образ (одной операцией compose), то разница в потреблении будет заметна просто на глаз. А это значит, больше число запущенных экземпляров на 1 физическую машину.


Памяти больше ест? Или размер image больше?
Памяти и ресурсов должно есть ровно столько же.


МР>2. У Windows контейнеров (я имею в виду Docker for Windows, то что говорят о неких не-Docker контейнерах в Windows — увы, я не нашел никакой толком информации о них. Такое ощущение, что публичного API для них просто нет) есть куча проблем, которые, я надеюсь, есть следствие их относительной молодости. Например, я так и не смог добиться нормального "проброса сети" из контейнера в хостовую ОС. Т.е. не меняя настройки просто запускаю/останавливаю экземпляры контейнера — связь с приложением в контейнере, то есть, то нету. Причем никакой вразумительной диагностики тоже нет...

МР>Я искренне полагал, что это лично мое неумение, но опять же поговорив с коллегами, узнал, ситуация считается чуть ли не нормой (причем, как я понял она не связана с Windows только). И считается вполне себе решением поднять экземпляр контейнера, проверить, что связи нет, грохнуть и поднять заново...

У старых версий по крайней мере, полгода-год назад, на Comunity Edition все еще была куча проблем с сетью (HNS data, lifetime overlaps и т.п.)

Без проблем чтобы, нужно использовать Windows Core с версии 1709 и выше. И EE docker edition

Для каждой версии свой базовый Image: https://hub.docker.com/_/microsoft-windows-servercore
Re[2]: Нужны-ли контейнеры (Docker) в Azure Service Fabric
От: Ночной Смотрящий Россия  
Дата: 29.01.19 12:25
Оценка:
Здравствуйте, Михаил Романов, Вы писали:

МР>Откровенно говоря, я тоже не до конца понимаю, почему так усиленно хватаются за контейнеры.


Потому что serverless. Если в классической модели ты вынужден париться по поводу того как это все будет распологаться на виртуалках, то с контейнером ты просто просишь инфраструктуру запустить контейнер. А как и каким образом оно залезет и будет жить в виртуалках — забота инфраструктуры.
Если же тебя окружение вообще не парит, зато заботит оверхед по сравнению с голым процессом, то и контейнеры тоже не нужны. Вместо них есть более легковесные решения типа Amazon Lambda или Azure Function.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[2]: Нужны-ли контейнеры (Docker) в Azure Service Fabric
От: Gollum Россия  
Дата: 25.03.19 14:37
Оценка:
Здравствуйте, Artem Korneev, Вы писали:

S>> Какие-такие зависимости могут поломаться при деплойменте сервиса без контейнера в Service Fabric?


AK>Azure Service Fabric это технология, основанная на контейнерах. Там, правда, не Docker, а похожий по функционалу контейнерный движок от MS.


Там docker для windows

AK>Т.е. вы не сможете задеплоить что-либо на Azure Service Fabric без контейнера. Там все это сделано прозрачно, но когда вы делаете деплоймент, то там все упаковывается в контейнер и выкладывается на кластер Azure Service Fabric.


Это не так, никакого контейнера там не создается (если вы не выбрали container host)
Eugene Agafonov on the .NET

Re[4]: Нужны-ли контейнеры (Docker) в Azure Service Fabric
От: Gollum Россия  
Дата: 25.03.19 14:38
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Sharov, Вы писали:


AK>>>Варианта без контейнером там нет.

S>>А почему?

НС>А потому что суть SF в автоматическом разворачивании нужного количества нод. Альтернативой контейнеру только полный образ, но это сильно более тяжелое решение.


SF не занимается автоматическим масштабированием нод. В Azure SF работает поверх vm scale set, т.е. виртуальных машин. SF может оркестрировать процессы без контейнеров.
Eugene Agafonov on the .NET

Re[4]: Нужны-ли контейнеры (Docker) в Azure Service Fabric
От: Gollum Россия  
Дата: 25.03.19 14:39
Оценка:
Здравствуйте, Artem Korneev, Вы писали:

AK>Здравствуйте, Sharov, Вы писали:


AK>>>Варианта без контейнеров там нет.

S>>А почему?

AK>Ну наверное потому, что Azure Service Fabric это контейнерный движок для кластеризации.


Контейнеры обязательны только в SF Mesh, обычный SF не требует контейнеризации, хотя и поддерживает ее.
Eugene Agafonov on the .NET

 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.