AstraSerg
и редиректит на https с http сам
Это фишка новых браузеров: если они один раз видели доменное имя за https, они всегда будут редиректить на него.
Юрий
Это фишка новых браузеров: если они один раз видели доменное имя за https, они всегда будут редиректить на него.
Не будут если HSTS-заголовки не настроены. Если были настроены - будет редиректить согласно указанным в них правилам.
Alexey
Это фишка новых браузеров: если они один раз видели доменное имя за https, они всегда будут редиректить на него.
https там отродясь не было, это локальный домен. Более того, в хранилище ключей тоже про него ни слова нету
AstraSerg
https там отродясь не было, это локальный домен. Более того, в хранилище ключей тоже про него ни слова нету
Тогда может быть только одно объяснение: шайтан у вас в хроме завелся :)
AstraSerg
Попробуйте фаерфокс, шайтаны лис боятся :)
Alexey
Попробуйте фаерфокс, шайтаны лис боятся :)
Не боятся. Ларчик просто открывался... Оставлю для потомков https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/
Roman
непонятно только зачем...
Anonymous
@mr0bot будет жить. Поприветствуем!
mr
Привет, начинаю разбиратся с докером. У меня есть несколько проектов на django и nginx. Как сделать правильно образ django+python? Делать Dockerfile и каждый раз docker build? Или под каждий проект делать свой образ и грузить на docker hub? Или можно как-то сделать образ и чтоб он постоянно ставил все пакети с requirements сам?
AstraSerg
Привет, начинаю разбиратся с докером. У меня есть несколько проектов на django и nginx. Как сделать правильно образ django+python? Делать Dockerfile и каждый раз docker build? Или под каждий проект делать свой образ и грузить на docker hub? Или можно как-то сделать образ и чтоб он постоянно ставил все пакети с requirements сам?
Добрый день. Тут сколько людей, столько и мнений. ИМХО, имеет смысл использовать официальный образ джанги https://hub.docker.com/_/django/ и использовать его как базовый. и кстати, вместо docker hub можете поднять приватный репозиторий.
AstraSerg
Спасибо за информацию. Думаю наверняка есть официальный образ джанги.
mr
каждый раз когда что?
Каждый раз для нового проекта
AstraSerg
Думаю они отказались в пользу образа питона
да, странно... Тогда можно неофициальный юзать (вот например 150+ звёзд https://hub.docker.com/r/dockerfiles/django-uwsgi-nginx/ ) или свой сделать.
AstraSerg
Каждый раз для нового проекта
Имеет смысл пересобирать, если проект требует изменений. Но можно использовать скомпилинный заранее как базовый для новых проектов
Aleksei
А когда я скажем ставлю новые пакеты?
Если они уникальны для проекта, то и образ у него свой
mr
Ок. Спасибо
AstraSerg
А когда я скажем ставлю новые пакеты?
Скажем так: если эти пакеты вам нужны во всех проектах, имеет смысл установить их в базовый образ. Если проект требует какой-то особенный пакет (как написал Алексей уникальный), то ставьте его про создании проекта
AstraSerg
Спасибр
Да не за что. Вообще мой совет похож на "Хорошее - это, хорошо, а плохое - плохо" :) Ведь очевидно вроде всё...
Anonymous
@isudakoff будет жить. Поприветствуем!
Anonymous
@n00b1k будет жить. Поприветствуем!
Anonymous
Anonymous
Подскжите какие ошибки есть
Aleksey
какой эффект хотели досттингуть таким подходом ?
Aleksey
зачем там много RUN ?
Aleksey
почему download вместо ADD ?
Anonymous
Кто-нибудь прокидывал nvidia gpu в контейнер с кудой?
Anonymous
@svyatkss будет жить. Поприветствуем!
Anonymous
@shokfake будет жить. Поприветствуем!
AstraSerg
Run, run, run. Let's run :) Песня такая есть к the doors если кто не в курсе:)
bama^boy
Подскжите какие ошибки есть
# ***** CLEANUP ***** RUN rm -rf /nginx-${VER_NGINX} RUN rm -rf /${NGINX_DEVEL_KIT} RUN rm -rf master.zip не имеет смысла, т.к. каждая инструкция - новый слой, слои мерджатся, т.е. эти команды еще больше раздувают результирующий образ
bama^boy
Подскжите какие ошибки есть
рекомендую посмотреть на https://github.com/docker-library/php/blob/85af0c14e3f23689f0851d3164ab3b630e7f016f/7.2/stretch/fpm/Dockerfile в качестве примера
Roman
Jevgeni
оверхед по сравнению с тем чтобы вообще не чистить?
Не совсем. Я так понимаю, что товарищ указал на три отдельные инструкции RUN, вместо одной в стиле "RUN rm -rf /nginx-${VER_NGINX} && rm -rf /${NGINX_DEVEL_KIT} && rm -rf master.zip"
Roman
Не совсем. Я так понимаю, что товарищ указал на три отдельные инструкции RUN, вместо одной в стиле "RUN rm -rf /nginx-${VER_NGINX} && rm -rf /${NGINX_DEVEL_KIT} && rm -rf master.zip"
не совсем. эти 3 инструкции надо мало того что вместе писать. их надо писать вместе со строками, которые их добавляли
Roman
то есть обычно это все один большой run
Jevgeni
Таки если по фен-шую, то да. Но не обязательно
Roman
а чо ж не обязательно, если удаление ничего не даст
Roman
оно все останется в предыдущих слоях
bama^boy
bama^boy
bama^boy
116MB vs 132MB
bama^boy
~14% overhead
Jevgeni
оно все останется в предыдущих слоях
И снова всё на поверхности. Ушел читать ман
Anonymous
@ArtemDvoryadkin будет жить. Поприветствуем!
Artem
Всем привет, возможно странный вопрос, но все же. У меня идет запуск докера компоса. Но в одном сервисе запускается bash скрипт, после выполнения он запускает в фоне jar и выходит. Компос после того как скрипт выполнился завершает процесс и контейнер исчезает из docker ps. Как сделать что бы после выполнения баш скрипта и запуска в фоне jar выполнение контейнра продолжелось?
Artem
он запускается через nope тоесть работает в фоне.
Roman
попробуй запускать через exec
Roman
тогда твой jar заменит оболочку
Artem
У меня в вdockefile делает последним следующее RUN bash deploy_tron.sh
Artem
внутри скрипта деплоя запускаются jar и они начинают работать, но только потом скрип заканчивается и все убивается если запускается через compose. Если делать это через запуск контейнера то проблем нету все работает
Artem
мне нужно что бы при запуске через композитора копонент не убивался после отработки баш скрипта
Vitalii
мне нужно что бы при запуске через композитора копонент не убивался после отработки баш скрипта
Не важно через что ты запускаешь контейнер. Важно чтобы в контейнере жил процесс. Твой jar должен быть основным процессом в контейнере с pid 1 и не должен запускаться в фоне. Тогда пока жив твой jar и будет жить твой контейнер.
Vitalii
мне нужно что бы при запуске через композитора копонент не убивался после отработки баш скрипта
Вангую, что твой баш скрипт собирает этот самый jar и потом запускает его в фоне. Так работало на обычной виртуалке, но у контейнеров другая идеология - на один контейнер один процесс. В итоге собирай свой jar в инструкция Dockerfile и делай его запуск в контейнере основным процессом. Либо собирай jar вне контейнера, копируй в контейнер и снова запускай контейнер с jar-ом. Вариантов много.
Artem
да вангуешь верно, тем запускать после скрипта была, но думал есть более простое решение.
Artem
Сейчас попробую отпишусь
Artem
если вызвать sleep команду баша вроде работет )
Artem
еще потестирую )
Artem
Еще дурацкий вопрос. Вот контейнер работает, процесс запущен. Но мне нужно посмотреть логи работы как это сделать? Если я подключусь через аттач то поподу в запущенный процесс, а мне нужно баш запустить.
Владимир
Как-то так?
Artem
docker -it exec <container-id> bash
docker exec -it <container-id> bash , да супер это работает. Благодарю!
Artem
docker logs -f contname
другое нужно было , но то что так можно то же спасибо не знал ))
Vitalii
другое нужно было , но то что так можно то же спасибо не знал ))
Обычно приложения пишут логи в stdout и смотреть их можно так как я показал:) но если вы пишите в папочку в контейнере то это работать не будет
Artem
да там в папку, но то что можно посмотреть консоль это классано, не знал что можно. ) спасибо
Владимир
Ещё есть такая штука как ctop. Там тоже можно stdout(не только) запущенных контейнеров просмотреть.
Andrey
да там в папку, но то что можно посмотреть консоль это классано, не знал что можно. ) спасибо
вообще то правильно докеризованное приложение, ничего не пишет внутрь себя, тем более логи
Jürgen
Если уж хотим логи то надо правильно драйвер настроить и пушить в елку например