1.2, Аноним (2), 00:20, 08/06/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –7 +/– |
Объясните почему бы просто не запускать каждое приложение в докере?
| |
|
2.3, Грусть (?), 00:35, 08/06/2018 [^] [^^] [^^^] [ответить]
| +7 +/– |
Докер - это ещё одно недоразумение. Почему бы просто не запускать приложения?
| |
|
|
4.13, combiner (?), 07:10, 08/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Кто мешает запускать php приложения на deb-based distro, с разными php-fpm одновременно?
| |
4.14, ryoken (ok), 07:36, 08/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Потому что разные версии того же пхп могут конфликтовать
Кстати, давно про дыры в пыхе тут новостей не было. Перешли на дыры сразу в процах :D
| |
4.20, XXX (??), 09:40, 08/06/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
Кто мешает запускать php приложения на gentoo-based distro, с разными php-fpm одновременно? (c)
| |
4.22, нах (?), 10:51, 08/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
не могут - если у вас руки не из задницы. pear/pecl/структура управляющих файлов в php сделаны еще реальными бородатыми программистами, которые - умели.
Вот что вы не умеете ничего кроме apt install (а "приложение" написано на php 5.0.2) - это я легко поверю.
| |
|
|
|
3.11, Аноним (2), 03:24, 08/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
Я так понимаю главное тут - изоляция, потому что остальное nginx итак вроде умеет.
Ну и Docker/LXC/LXD отлично с изоляцией справляются.
| |
|
4.17, qrKot (?), 09:03, 08/06/2018 [^] [^^] [^^^] [ответить]
| +4 +/– |
Хреново докер с изоляцией справляется, если честно...
Докер - он про деплой/доставку, изоляция не про докер.
| |
|
|
2.6, KonstantinB (ok), 01:07, 08/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
Например, не для каждого проекта оправдано дублировать каждое запущенное приложение несколькими инстансами с балансировкой.
Если же запущен всего один инстанс приложения, с докером без даунтайма при обновлении не обойтись.
Ну и не каждое приложение можно написать (переписать) в соответствии с методологией 12 factor. А без этого докер больше мешает, чем помогает, проще обойтись тем же LXC.
| |
|
3.10, freehck (ok), 03:24, 08/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Если же запущен всего один инстанс приложения, с докером без даунтайма при обновлении не обойтись.
Это неправда. Обновление происходит так: мы поднимаем контейнер из нового образа, дожидаемся, пока он полностью прогрузится, и тогда уже гасим старый.
По поводу остального согласен.
| |
|
4.12, KonstantinB (ok), 04:54, 08/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Обновление происходит так: мы поднимаем контейнер из нового образа, дожидаемся, пока он полностью прогрузится, и тогда уже гасим старый.
Не, ну так, конечно, можно, в стиле "fastcgi php до появления php-fpm".
Но тут есть две проблемы.
1) дроп соединений, ожидающих ответа от первого контейнера в момент переключения. Тут можно выкрутиться конструкцией вида "добавляем в конфиг балансировщика второй контейнер, метим первый как down, дожидаемся, пока первый закончит обработку всех соединений, прибиваем первый", но как-то сложновато получается.
2) если приложение - древний монолит, могут возникнуть проблемы с конкурентным доступом к ресурсам из обоих контейнеров. Это, конечно, из разряда "не программируйте так", но если бы все хорошо программировали...
| |
|
5.21, Анонимус2 (?), 10:31, 08/06/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
>если приложение - древний монолит
То unit ему тем более никак не поможет
| |
|
6.30, KonstantinB (ok), 02:37, 09/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
Самому по себе - да.
На практике же типичная подобная ситуация: есть, скажем, древний PHP-шный монолит из дерьма и палок, как-то работающий, но для развития непригодный, потому параллельно начинается разработка новых сервисов и постепенный перенос старой функциональности из монолита в код новых сервисов, которые, допустим, разрабатываются на python и go. Вот тут Unit оказывается очень удобен.
| |
|
5.33, freehck (ok), 09:17, 18/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> Обновление происходит так: мы поднимаем контейнер из нового образа, дожидаемся, пока он полностью прогрузится, и тогда уже гасим старый.
> Не, ну так, конечно, можно, в стиле "fastcgi php до появления php-fpm".
Да нет, тут тот же самый php-fpm, только он раскидан по нескольким контейнерам/машинам/нодам. В каждом контейнере, по идее, висит воркер, который дожидается соединений. И да, тот же php-fpm туда впихнуть -- да пожалуйста, было бы желание.
> 1) дроп соединений, ожидающих ответа от первого контейнера в момент переключения. Тут
> можно выкрутиться конструкцией вида "добавляем в конфиг балансировщика второй контейнер,
> метим первый как down, дожидаемся, пока первый закончит обработку всех соединений,
> прибиваем первый", но как-то сложновато получается.
Нет, ну почему же. Дроп соединений делать не нужно. Процедуру вырубания контейнера надо описать корректно, чтобы он дожидался завершения текущих соединений и не принимал новых. По части "не принимал новых" -- тут конечно же надо балансировщик. Но исправление конфига -- опять же, чересчур. Не надо описывать воркеры в конфиге. Надо, чтобы балансировщик узнавал о воркерах через service discovery. Zookeeper/etcd в помощь.
> 2) если приложение - древний монолит, могут возникнуть проблемы с конкурентным доступом
> к ресурсам из обоих контейнеров. Это, конечно, из разряда "не программируйте
> так", но если бы все хорошо программировали...
Да, обычно приходится много чего переписать, чтобы обеспечить бесперебойную работу. Ну, что поделать. Есть игрушки "на коленке", когда нужно сделать быстро. А есть игрушки "на экспорт", когда нужно сделать надёжно.
| |
|
|
3.18, qrKot (?), 09:06, 08/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Например, не для каждого проекта оправдано дублировать каждое запущенное приложение несколькими
> инстансами с балансировкой.
2 инстанса - оправдано для каждого, хотя бы в целях фейловера... Балансировка - уже не везде, согласен.
> Если же запущен всего один инстанс приложения, с докером без даунтайма при
> обновлении не обойтись.
Вот это неправда ваша. Да и не докером единым, k8s есть еще тот же.
> Ну и не каждое приложение можно написать (переписать) в соответствии с методологией
> 12 factor.
Каждое серверное - можно.
> А без этого докер больше мешает, чем помогает, проще обойтись тем же LXC.
А вот LXC - вообще НЕ средство доставки приложения.
| |
|
2.19, Аноним (-), 09:08, 08/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Наверно потому что докер - хипстерское баловство? По-моему уже все наигрались с ним.
| |
|
3.23, нах (?), 10:53, 08/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Наверно потому что докер - хипстерское баловство? По-моему уже все наигрались с
> ним.
куда ты [from] с подводной-то лодки денешься? (с ужасом глядя в docker ps на системе, установленной подрядчиками)
| |
3.25, Аноним (25), 16:09, 08/06/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
Деплой в течение минуты, ограничения ресурсов, изоляция хоть и не уровня полноценной виртуализации, зато и потребление ресурсов гораздо ниже. Что вы предлагаете в качестве альтернативны когда дело касается динамического старта/остановки большого количества инстансов?
| |
|
4.29, Аноним (-), 22:03, 08/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Большое количество инстансов требуется очень редко. Там, где это требуется - пишутся свои in-house решения заточенные исключительно под собственные потребности компаний. И лишь в крайне узкой нише между этими двумя - и есть истинное призвание докера. Однако хипстота его использует вообще везде, даже на хоумпейджах. Один очень настойчиво пытался к нам на небольшой проект затащить потому что это, типа, в тренде. Тимлид посадил его разбирать легаси проект в качестве выправительной для мозгов меры.
| |
|
|
|
|
2.7, KonstantinB (ok), 01:14, 08/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
> не понял, он аналог uwsgi и gunicorn?
В каком-то смысле - да, только сразу для кучи разных языков, со своими райтаймами/библиотеками/SAPI (в зависимости от) для каждого из них.
Технически работает через shared memory, что дает прирост производительности: не надо парсить никакие протоколы, просто меняемся указателями на структуры в памяти.
| |
2.24, нах (?), 10:58, 08/06/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
> не понял, он аналог uwsgi и gunicorn?
скорее, попытка показать их авторам "как правильно". Вероятно, мертворожденная.
| |
2.32, denis0 (?), 09:00, 09/06/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
https://www.youtube.com/watch?v=GK6xAOVRTcg - видео со Стачки в Ульяновске в этом году. Релиз 1.0 случился где-то через неделю после этого видео.
Идеи в Unit очень мощные.
offtop: задним числом понял, зачем некоторые до сих пор пользуют Apache в качестве appserver - единообразное конфигурирование для разных ЯП.
| |
|
1.26, Аноним (-), 18:59, 08/06/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
А что это такое? Если что я не "специалист".
Это система изоляции? Тогда как она может якобы поддерживать языки?
При компиляции они хотят -dev файлы от языков, хмм.. это аналог операционной системы?
Что-то типа Wine в очень широком смысле?
Операционая система без излишеств и есть "сервер приложений". А это что?
| |
1.27, Аноним (-), 20:03, 08/06/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
аналог скорее uwsgi (так как uwsgi тоже поддерживает большое количество языков)
| |
|