Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Разработка информационных систем Новый топик    Ответить
 Как можно отмасштабировать такую архитектуру?  [new]
manking
Member

Откуда:
Сообщений: 210
Добрый день.

Сейчас есть 1 продуктивный сервер linux, где запущены 2 контейнера докер которые
по 80 порту принимают запросы от балансировщика nginx.
На этом же сервере поднята mongodB база к которой обращаются контейнеры. Контейнеры используют общую папку хоста /datas
Входят в общую docker сеть. И mongodb и nginx тоже docker контейнеры.

Загрузка оборудования растёт (использование процессора), полгода назад была в среднем 4%, сейчас 22%
(провисаний и тормозов пока нет).
В какую сторону нужно смотреть чтобы в дальнейшем добавить новые сервера и обеспечить высокую
доступность системы при многократном росте запросов?
То есть как такую архитектуру можно будет отмасштабировать в дальнейшем наиболее простым способом?
Правильно ли понимаю что это связано с оркестровка контейнеров? Нужно понять на чём следует сосредоточить обучение.
22 янв 19, 22:20    [21791619]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38039
manking
балансировщика nginx.

изучить инструменты что сейчас есть.
Например, как можно включать балансировщик на одном порту и одной машине? Между чем и чем он распределяет?
2. Создать тестовый стенд и повысить нагрузку.
22 янв 19, 23:14    [21791649]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
kolobok0
Member

Откуда:
Сообщений: 1919
manking,

один из вариантов - запустить оркестратор(сварм, ранчер и т.п.), и в него регистрировать новые станции(можно и "облака") с docker-ами. сами оркестраторы могут работать так-же в контейнерах.

с уважением
(круглый)
23 янв 19, 00:26    [21791682]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
alex55555
Member

Откуда:
Сообщений: 1976
Кстати, что за хрень этот докер? На их сайте одна вода, сплошной рекламный бред и никакой сути. Понял, что это очередной заход на тему виртуализации под очередным эмулятором, но на сколько это понимание правильно? Чем эта вся виртуаль лучше вмвари или вообще какого-нибудь qemu? По простому - нахрена нужен этот докер?
23 янв 19, 15:35    [21792326]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38039
alex55555,
Стильно, молодежно, хайп))))
23 янв 19, 15:41    [21792340]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7525
alex55555
Кстати, что за хрень этот докер? На их сайте одна вода, сплошной рекламный бред и никакой сути. Понял, что это очередной заход на тему виртуализации под очередным эмулятором, но на сколько это понимание правильно? Чем эта вся виртуаль лучше вмвари или вообще какого-нибудь qemu? По простому - нахрена нужен этот докер?

это не вертуализация, это контейнер

еще один уровен безопасности/найстройко-независимости от Host ОС

по сравнению с VM Ware, контейнер не содержит ОС, просто переадресует обращения к ф-циям OS к Host OS. Т.е. более легковестный.

Профит: приложения более изолированы, чем при запуске просто в Host OS; приложения в контейнерах конфигурируются раздельно, что упрощает администрирование Host OS.

В общем, упрощает администрирование и, соответственно, deploy приложений.

IMHO & AFAIK
23 янв 19, 16:08    [21792377]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38039
Leonid Kudryavtsev
В общем, упрощает администрирование
не логично. Надо сто конфигов и переменных среды.
23 янв 19, 16:15    [21792387]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7525
Petro123
Leonid Kudryavtsev
В общем, упрощает администрирование
не логично. Надо сто конфигов и переменных среды.

???

В момент сборки проекта все включается внутрь docker-образа
Админ только docker-образ запускает.

IMHO & AFAIK
23 янв 19, 16:23    [21792400]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7525
если я правильно помню, docker даже сам новые версии образа из репозитория скачивает
(или не скачивает, тогда приходилось руками старые версии на диске сервера грохать ))) )
23 янв 19, 16:25    [21792405]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38039
Leonid Kudryavtsev,
У меня логи в разных местах. Что значит включает при разработке?
23 янв 19, 16:29    [21792418]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7525
Petro123
Что значит "включает при разработке?"

я вроде писал:

"В момент сборки проекта все включается внутрь docker-образа"

Разработали, выложили в SVN, запустили сборку в Jenken, Jenken собрал docker образы и выложил в репозиторий, остановили/запустили docker образ на host'е, профит.

Что использовалось для контроля/деплоя конфигов, я не помню. Было что-то отдельное от Jenken. Но за конфиги отвечали DevOps'ы, я с этим не сталкивался.

Какие-то проблемы с аттачем локальных файловых систем переодически были (PostgreSQL в docker'е с базой храняшейся локально на диске сервера /не сетевом/). Это было как-то криво настроено. Логи хранились в Amazon S3, как они туда попадали - не знаю, это DevOps'ы настраивали ))).
23 янв 19, 17:05    [21792471]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38039
Leonid Kudryavtsev,
ОК
Я к тому что раньше был кластер, балансировщик и топология сети для горизонтального масштабирования.
Теперь докер образы, которые я лично затрудняюсь встроить в существующую систему.
Imho
23 янв 19, 17:10    [21792478]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
kolobok0
Member

Откуда:
Сообщений: 1919
alex55555
...Чем эта вся виртуаль лучше вмвари...


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

например в контейнере вы можете запустить скрипт1, в другом контейнере - скрипт2, в третьем - скрипт3. С точки зрения изоляции - они будут полностью изолированы от внешнего мира(по умолчанию, всё равно есть ресурсы которые шаряться - понятно), а вот с точки зрения слоёв софта - то он с большой вероятностью будет юзаться по многу раз.

т.к. контейнеры изолированы и любые окна во внешний мир имеют описательный(текстовое описание) - то снижаются требования на среду юзанья таких контейнеров.

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

есть оркестраторы которые позволяют жанглировать и управлять такими контейнерами (нагрузкой, отказоустойчивостью, распределением и прочей шнягой).

как то так

удачи вам
(круглый)
24 янв 19, 00:29    [21792739]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4659
alex55555
Кстати, что за хрень этот докер? На их сайте одна вода, сплошной рекламный бред и никакой сути. Понял, что это очередной заход на тему виртуализации под очередным эмулятором, но на сколько это понимание правильно? Чем эта вся виртуаль лучше вмвари или вообще какого-нибудь qemu? По простому - нахрена нужен этот докер?


Он нужен для того чтобы сказать

docker run hello-world


И опа, все заработало!
Сейчас многие вендоры выкладывают на docker.hub свои приложения обернутые в docker, которые работают "из коробки".
Очень удобно при разработке, для развертывания dev-окружения.
На продакшене, как обычно, "есть нюансы".

<:o)
24 янв 19, 09:00    [21792859]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38039
mad_nazgul
"есть нюансы"
вот имено. Докеры, как и микросервисы еще не настолько распространены чтобы повлиять на IT. Да и на данный топик тоже. Вон, автор молчит. Значит просто в игрушки поигрался.. докерами.
24 янв 19, 09:59    [21792932]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
alex55555
Member

Откуда:
Сообщений: 1976
mad_nazgul
Он нужен для того чтобы сказать

docker run hello-world


И опа, все заработало!

Не, так не получится, потому что install.exe + <Enter> выходит короче.
mad_nazgul
Сейчас многие вендоры выкладывают на docker.hub свои приложения обернутые в docker, которые работают "из коробки".

Но сам докер же надо устанавливать. Значит опять install.exe короче. Плюс существуют portable.exe.

kolobok0
докер контейнер - эмуляция только слоя. слой может ссылаться на другие слои. т.е. внутри докера может быть набор слоёв для разных задач, при этом слои могут использоваться в разных задачах.

Софт дёргает осёвый API плюс свои либы, которые тоже ось должна загрузить. Значит докер не может сделать много слоёв, потому что слой осёвого API один. Перехватывать вызовы API докер, видимо, может. Но ещё слои городить - непонятно как.
kolobok0
например в контейнере вы можете запустить скрипт1, в другом контейнере - скрипт2, в третьем - скрипт3. С точки зрения изоляции - они будут полностью изолированы от внешнего мира

Скрипты запускаются в среде исполнения, это и есть изоляция. Её часто называют "песочница". То есть и здесь особых отличий пока нет.
kolobok0
т.к. контейнеры изолированы и любые окна во внешний мир имеют описательный(текстовое описание) - то снижаются требования на среду юзанья таких контейнеров.

Среда всегда идентична. В смысле предоставляет стандартный API и набор ресурсов. Требования к среде предъявлять можно, но API от этого не изменится.
kolobok0
ну например есть у вас контейнер по компиляции софта - прорубили окошечко выхлопу билдовки во внешний мир - диск, то это уже боевая компиляция. если запустили без такого окошечка - то сборка в тестовом режиме. чиссо как пример

Вот здесь вы, похоже, ближе к сути, но об этом чуть дальше.

Leonid Kudryavtsev
Профит: приложения более изолированы, чем при запуске просто в Host OS; приложения в контейнерах конфигурируются раздельно, что упрощает администрирование Host OS.


В общем что я понял:

В массовых осях до сих пор не реализован давно известный механизм перехватчиков, то есть при вызове осёвых функций вызов оборачивается во внешнюю процедуру, которая делает с вызовом что хочет (перехватывает его и лечит как ей вздумается). И вот, похоже, докер этот перехват реализовал вне осей. То есть понятно, что в рекламе пишут про администрирование, конфигурирование и прочий бред, который, к сожалению, многие повторяют, но суть не в администрировании с конфигурированием, а в перехвате. Не будь управляемого перехвата - нафиг докер не нужен. Пока, как я понимаю, они реализовали примитивный перехват, то есть тупо ограничения по небольшому списку известных ресурсов, например - диск, сеть, память. Но в широком смысле перехват - это полный контроль над всем. Перехватчик имеет входные параметры вызова API и может их подкручивать как хочет, потом отдаёт параметры API, ось возвращает результат и этот результат перехватчик опять крутит/вертит как хочет. Но докер реализован узко, то есть нет возможности писать свои перехватчики, а всё настраивается текстом, что гарантирует отсутствие гибкости и ориентацию лишь на убогое ограничение только стандартных ресурсов.

Ну и совсем маленькая проблемка - под каждую ось нужно ваять свой докер, что затратно, особенно с учётом версий осей. Вот в Java внутри программа имеет свой гарантированный и не зависящий от осей набор API, а в докере - всё зависит от оси. Проснулся Билли Гейтс не с той ноги и поменял API - всё, докер сдох, надо переписывать (точнее - сдохло приложение, зависящее от изменённого API). А Java приложение будет работать, потому что у него неизменный API. Поэтому полная виртуализация выгоднее в плане администрирования - нет зависимости от плохих снов Билли Гейтса, можно на 95-й винде и через тысячу лет работать.
24 янв 19, 15:59    [21793562]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
kolobok0
Member

Откуда:
Сообщений: 1919
alex55555
...Софт дёргает осёвый API....
Скрипты запускаются...
Среда всегда идентична....
...они реализовали примитивный перехват... Но докер реализован узко...
...А Java приложение будет работать..


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

представьте себе, что скрипт1 ставит вам одну версию библиотеки, в скрипт2 другую версию. Вопрос, что достанеться скрипту3? С контейнерами этого в принципе не может быть, от слова совсем. В каждом конкретном случае будет юзаться только то, что заказал программист. Т.е. ваша песочница резко уступает контейнерам. Ышо один пример: предположим скрипт1 - тест софта. После теста(авто) Ваша БД находиться НЕ в точке "зэрро". Как минимум Вы будете прогонять анду, либо очистку и заново загрузку в БД начальных данных. Надо говорить, что в контейнерном мире надо просто .... запустить контейнер с первичным образом и всё...

Если в понимание "среды" вы вкладываете некое API - то вы правы. А вот (как пример выше) некие ресурсы сохраняющие стэйт состояние - то увы и ах не всё так просто...

если вдаваться в механику реализации, то мир докеров-контейнеров работает благодаря "именованию ресурсов" в системе. Т.е. каждый контейнер юзает только свой экземпляр ресурсов(загрузка ресурсов, если совпадает - происходит из одного образа - тем самым нет загрузки образа в систему по сетке). Т.к. окружение необходимое к использованию описывается текстом, то наступает тот момент когда понимаешь что чтобы запустить у конечного пользователя инстанц продукта достаточно (в некоторых случаях) только нотепад :)

по поводу работы явы-какавы...что нужно чтоб ваша ява-какава взлетела на чистом линуксе? А Вы уверены, что Ваш код работающий у разработчика на машине запуститься с пол-пинка у клиента? И т.д.. А вот для контейнеров - это повседневная хрень. Например разработчик параллельно в своей ветке барахтается и после пуша "автоматом" получается контейнер который может юзать любой загрузив его версию. Автоматика пропихивает далее - делает уже инстанц всего продукта, который может автоматом развернуться на стенде, для прогона тестов. Заметьте - фаза изменения окружения(бд, фс, конфиги всевозможные и прочий хлам) уезжает прям в руки разработчика. Т.е. никому не надо будет спустя пол-года(или даже неделю) бегать от разработчика к разработчику и собирать все эти изменения...

это маленькие нюансы(те что пришли на ум, их гораздо-гораздо больше) и плюсики которые делают "практически всё" на автомате, снижают требования к разработчикам, детектируют траблы в месте их возникновения, уменьшают телодвижения, снижают себестоимость... но можно конечно же пафосно нажимать кнопки со всей значимостью - кому, что собственно...но имхо - контейнеры удачная хрень в мире IT.

удачи вам
(круглый)
ЗЫ
Надеюсь поделился своими наблюдашками по плюшкам этой технологии.
24 янв 19, 22:03    [21793828]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38039
kolobok0
что нужно чтоб ваша ява-какава взлетела на чистом линуксе?

kolobok0
после пуша "автоматом" получается контейнер который может юзать любой
как вы все любите кнопу Автомат.)))
Вы видели серьезное приложение в докере? Например Оракле?
Как то искал. Нет такого.
А что стало с компонентной моделью кирпичиками SOA?
Что стало с докером сильверлайт который запускай где хочешь. Хоть на Ослике хоть на десктопе.
...Каждые 5 лет выходят попытки сделать кнопку Автомат.
25 янв 19, 07:32    [21793894]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38039
Кстати, как с реестром, COM, драйверами, принтерами, рабочим столом в докерах. Все внутри докера?
25 янв 19, 07:35    [21793895]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
kolobok0
Member

Откуда:
Сообщений: 1919
Petro123
...как вы все любите...Вы видели серьезное приложение в докере? Например Оракле?...Каждые 5 лет выходят ....


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

по поводу оракле....оно?
докерхаб
даже какие то словени по поводу официальных выпусков от автора....хз...

всё человечество стремиться к уменьшению затрат на разработку софта. что в этом плохого? я конечно-же за ассемблер(я на нём отдыхаю, когда создаю что нить) - но с точки зрения пром. разработки = страдает вершина "График" в пресловутом треугольнике КГБ.

удачи вам
(круглый)
ЗЫ
Почему-то люди которые поверхностно знают об технологии докер-контейнер хотят постоянно засунуть в контейнер целый продукт. Это большое заблуждение и глупость... Смысла в этом мало.
ЗЫ ЗЫ
По поводу форточек. Вот явно не скажу. Хотя зная что такое реестр, ком, драйвера, принтера и прочая лабуда - вообще не понял в чём глубина вопроса. реестр - в конечном итоге это файл и? Ну изолирован может(или не может - как захотеть запустить контейнер). COM - то вообще не в ту степь(читай определение что такое ком у ДэйлРоджерсона, если не попутал автора, "Основы COM"). COM это ТЕХНОЛОГИЯ и от языка, платформы и прочей шняги вообще не зависит. Принтера - что с принтерами у вас не так? имеется ввиду порты что-ли? По портам не скажу, не юзал. Но думаю виртуализация выше чем драйвера оси. Рабочий стол - хз. Ну наверное если запустите в режиме терминала, то отображалку увидите. И???
25 янв 19, 10:07    [21793960]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38039
kolobok0
по поводу оракле....оно?
докерхаб
спасибо. Спрашивал в java ветке, никто не дал ссыль).
Или у нас у java одно, а у MS похоже сво контейнеры?) :0

kolobok0
всё человечество стремиться к уменьшению затрат
ну дак пока не получается. Выше пример силверлайта, SOA, COM, флэша.
Все универсальное с одной кнопой не выходит.
25 янв 19, 11:32    [21794085]     Ответить | Цитировать Сообщить модератору
 Re: Как можно отмасштабировать такую архитектуру?  [new]
alex55555
Member

Откуда:
Сообщений: 1976
kolobok0
"слой" в контейнере это не только вертикальное масштабирование но и горизонтальное. ну например один слой - чистая ось. второй слой - тулзы. третий слой - MySql. Третий слой - ваше приложение со всеми баш командами по заведению юзвера, созданию каталогов, доп. инсталяции требуемых библиотек. Так вот каждый такой слой - уникален и детектируется докером при загрузке.

И как же докер что-то детектирует? Как он вообще работает? Подменяет осёвые вызовы в коде своими? То есть именно как перехватчик?
kolobok0
представьте себе, что скрипт1 ставит вам одну версию библиотеки, в скрипт2 другую версию. Вопрос, что достанеться скрипту3?

Не могу представить. Скрипт исполняется, он ничего не ставит. Поэтому непонятно, чего будет нехватать третьему скрипту.
kolobok0
В каждом конкретном случае будет юзаться только то, что заказал программист. Т.е. ваша песочница резко уступает контейнерам.

Опять не понял. Моя песочница конфигурится как мне надо, так в чём отличие от "того, что заказал программист"?
kolobok0
Ышо один пример: предположим скрипт1 - тест софта. После теста(авто) Ваша БД находиться НЕ в точке "зэрро". Как минимум Вы будете прогонять анду, либо очистку и заново загрузку в БД начальных данных. Надо говорить, что в контейнерном мире надо просто .... запустить контейнер с первичным образом и всё...

Как бэ что-то вроде trim all tables есть в большинстве базёшек (правда в разном виде). Ну и можно просто опустить БД и заменить её файл с данными. А ещё можно БД в памяти делать - убил процесс и всё с нуля.
kolobok0
если вдаваться в механику реализации, то мир докеров-контейнеров работает благодаря "именованию ресурсов" в системе. Т.е. каждый контейнер юзает только свой экземпляр ресурсов(загрузка ресурсов, если совпадает - происходит из одного образа - тем самым нет загрузки образа в систему по сетке)

Ну то есть при перехвате обращения к диску происходит проверка - что и откуда данной софтине разрешено читать/писать.
kolobok0
по поводу работы явы-какавы...что нужно чтоб ваша ява-какава взлетела на чистом линуксе?

Нужно что бы кто-то установил на линухе JVM. Всё. Больше ничего не нужно. Правда в комплекте не идёт БД, её нужно поднимать отдельно. Да, в этой части идея взять всё необходимое и отдать заказчику в контейнере, выглядит интересно. Но есть нюансы. Это всё работает для простых софтин, типа калькулятора с блокнотом. А вот чуть сложнее, типа одноце хотя бы? Там нет необходимости убивать все данные пользователей и загружать систему с нуля. Даже за такую необходимость в некоторых местах могут просто расстреливать. И что тогда?

Плюс докер - это десктоп. А надо веб. И что тогда?
kolobok0
Надеюсь поделился своими наблюдашками по плюшкам этой технологии.

Давайте попробуем. Но пока вижу нишу докера именно для чего-то простенького, типа блокнота с базой данных. А вот ещё проще - уже portable. А если сложнее - докер лишний.
25 янв 19, 16:53    [21794461]     Ответить | Цитировать Сообщить модератору
Все форумы / Разработка информационных систем Ответить