поставь на нем nginx и проксируй с добавлением хидера

так и есть сейчас

но как проксировать запрос ИЗ бэка

без реквеста НА бэк

ищи по ключевым словам transparent proxy

Я ответ знаю, но вот как то нет желания за вас работать, простите

не знаешь значит, просто выебываешься

ищи по ключевым словам transparent proxy

лол

http://docs.telerik.com/fiddler/KnowledgeBase/FiddlerScript/ModifyRequestOrResponse

http://docs.telerik.com/fiddler/KnowledgeBase/FiddlerScript/ModifyRequestOrResponse

от это уже по делу, спасибо :)

по сути тебе нужен прокси который на лету изменяет http request

да

их довольно много первично поставь с gui так думаю будет проще протестить

потом можешь через консоль все настроить

www.charlesproxy.com

вот тоже не плохой вариант

есть еще 1 вариант) если у тебя принимающий сервер твой

то можешь на нем настроить проброс хедеров с определенного ip

если что можешь в личку стукануть подскажу.

одну интересную мысль подкинул

спасибо еще раз

В общем есть задача: Есть backend часть на php(symfony 2), все зависимости подтягиваются через composer работает в связке с mysql, отдает все данные через nginx+php-fpm Есть frontend(angular), все зависимости через bower, сборка через gulp, на dev машине gulp чекает все изменения и авторелойдит через browser-sync Необходимо 1) на дев машине, что бы при изменении исходников можно было моментально просматривать изменения в идеале(авторелоад browser-sync) 2) на тестовом сервере все собиралось, прогонялись тесты делался билд имеджей и отправлялся в hub 3) на продакшене брался имедж ставился пробрасывались папки к логам, загружаемым файлам и к бд, сорсы не доступны для изменения из вне контейнера

кто нить что нить подобное творил?

всем привет. странно. бывает у кого не срабатывает ONBUILD COPY . /usr/src/app к примеру команда ? собираю образ. запускаю его. попадаю в bash а в /usr/src/app пусто

да если убрать ONBUILD то все ок

ты пишешь в my_new_image зависимость от FROM my_image_with_onbuild и не срабатывает COPY, который описан в my_image_with_onbuild ?

как ты сделал текст красным?

красный

обрами обратной кавычкой текст

красный?

о да!

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 будет хорошо удобно масштабироваться

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