http://prntscr.com/cesel1

O_o

У кого-то со зрением беда

У кого-то со зрением беда

Нет, просто один на нативном, второй на кроссплатформенном.

не знал.

Хах

Хах

Твой ник у меня красный, кстати говоря.

версия для мака и для винды видимо имеет разные расцветки

а для мака так там ещё и две их

Версия для мака и версия для винды?

я знаю что есть версия для мака, а что за версия для винды такая?

tdesktop

но он и под линукс тоже

Это в линуксовой версии синий

обычная версия для винды https://s.mail.ru/6HyM/A946VeqLo

так что-ли?

ну так это типа monospace, не? зачем красным непонятно

привет. я понимаю насколько это глупый вопрос здесь, но все же. у меня есть приложение, которое запускается через docker-compose и смотрит в мир через nginx. подскажите как лучше всего делать zero downtime deployment?

привет. я понимаю насколько это глупый вопрос здесь, но все же. у меня есть приложение, которое запускается через docker-compose и смотрит в мир через nginx. подскажите как лучше всего делать zero downtime deployment?

https://docs.quay.io/solution/zero-downtime-deployments.html

спасибо

постигаю докер на вин10 по этой и http://michal.karzynski.pl/blog/2015/04/19/packaging-django-applications-as-docker-container-images/ и при выполнении docker build -t ... image создает но в конце выдает SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories. при выполнении docker run --publish=8001:8000 ... выдает standard_init_linux.go:175: exec user process caused "no such file or directory" подробных логов не вижу в чем проблема понять не могу

я бы посоветовал uwsgi для Django всё-таки

я бы посоветовал uwsgi для Django всё-таки

в смысле вместо gunicorn (что в уроке) пользовать uwsgi?

ну, мне больше uwsgi нравится, да

в тестах он побыстрее

сам всегда использовал gunicorn, но у меня не было нагруженных проектов поэтому и проблем не было

но проблема вроде не в этом)

оба решения нормальные

но лично я гуникорном не пользовался

так что тут не смогу помочь

сам всегда использовал gunicorn, но у меня не было нагруженных проектов поэтому и проблем не было

uwsgi быстрее и стабильнее под нагрузкой. Это показывали на pycon spb в прошлом году. Под реальной большой нагрузкой gunicron валится просто

видимо, там ошибка в том, что гуникорну подложили какой-то путь, которого нет

https://docs.djangoproject.com/en/1.10/howto/deployment/wsgi/gunicorn/

uwsgi быстрее и стабильнее под нагрузкой. Это показывали на pycon spb в прошлом году. Под реальной большой нагрузкой gunicron валится просто

я вот не уверен насчёт aiohttp

возможно, его под uwsgi не запустить

или запустить, но не будет смысла

но конкретно для Django лучше бы uwsgi - тут я уверен

я вот не уверен насчёт aiohttp

тестировали сравнение django runserver / django uwsgi / django + gunicron. Первым с дистанции сошел runserver (неудивительно), вторым - gunicron

есть фреймворк aiohttp

вроде как его только на gunicorn'е можно запустить

он на базе asyncio

да, там свой воркер под него. в случае wsgi приложения uwsgi сильно быстрее gunicorn.

вот было бы интересно сравнить django + uwsgi и aiohttp + gunicorn

ну да, собственно, так и посоветовал выше

вот было бы интересно сравнить django + uwsgi и aiohttp + gunicorn

aio выиграет, по очевидным причинам

ну, а насколько

aiohttp + uwsgi (experimental!) http://uwsgi-docs.readthedocs.io/en/latest/asyncio.html

и вот там ещё какие-то джанго-каналы делают

ну, а насколько

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

ну, если уж честно - мне больше всего от Django нужна админка и миграции

когда такое в приличном виде появится на aiohttp - можно будет подумать о тестовых проектах на нём

ну, если уж честно - мне больше всего от Django нужна админка и миграции

тебе нужна админка и миграции, а так же: * ORM * templates * auth/registration

и раутинг

а так все верно

да в общем-то просто админка и миграция, можно и без остального

всё равно на js теперь модно всё делать

а если уж нужно быстро - ORM выкидывают первым

в идеале даже админка на базе couchbase

да в общем-то просто админка и миграция, можно и без остального

проблема в том, что админке без ОРМ не будет

тогда можно без миграций

и миграции без ОРМ - тоже не будет

я думаю о том, что вот взять бы этот aiohttp, взять couchbase и где-нибудь админку

все шаблоны и роутинг на стороне js

авторизация через https://jwt.io/#libraries

Couchbase будет хорошо удобно масштабироваться

Couchbase будет хорошо удобно масштабироваться

плохо она масштабируется, увы

врут? http://www.couchbase.com/fr/couchbase-server/scalability

а так вообще в облаке было бы удобно запускать

врут? http://www.couchbase.com/fr/couchbase-server/scalability

эксперимент показал, что врут. А вообще тестировать надо все конечно

я очень плохо понимаю концепцию документо-ориентированных хранилищ, KVS и SQL мне всегда хватало

с PostgreSQL всё отлично за исключением момента с мультимастером - 3+ серверами

я хочу писать сразу на все серверы и чтобы потом всё синхронизировалось

и чтобы на всех серверах всё дублировалось, чтобы я мог легко добавлять ноды и удалять их

бизнес-данные они структурированы, так что в любом случае, какая-либо структура будет, в этом смысле разницы NoSQL-SQL не будет

та же админка с чётким набором полей по каждой сущности

и чтобы на всех серверах всё дублировалось, чтобы я мог легко добавлять ноды и удалять их

CAP-теорема сильно против слов "легко добавлять мастера"

очень сильно

с PostgreSQL всё отлично за исключением момента с мультимастером - 3+ серверами

Это смотрели? https://habrahabr.ru/post/301370/

Как по мне, так не плохой "proof of concept"