-
Notifications
You must be signed in to change notification settings - Fork 91
Добавляет упаковку в контейнер #391
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
66ac0eb
to
b4a4681
Compare
Наверное всё хорошо, я не настоящий сварщик) Заметил, что:
Я вообще засомневался, что докер нужно к этой репе прикручивать, поскольку нам нужны полные nginx-кофиги (приватная репка), которые наверное не стоит светить, не уверен. |
Наверное нам официальный образ не подойдёт (он не поддерживает brotli) и нужно взять уже готовый с brotli, например такой. Ну или изготовить в процессе сборки свой такой же) |
В дальнейшем предполагается использовать этот контейнер на продовом сервере? |
Приветик. Да. Сейчас оно немного разобрано (мне надо завести бротли в Debian :) План примерно такой: собрать контейнер в gha и дальше запускать где-то :) |
А Alpine не устраивает? Для него есть пакет - https://pkgs.alpinelinux.org/package/edge/main/x86/nginx-mod-http-brotli. В Debian тоже есть - https://packages.debian.org/sid/libnginx-mod-http-brotli-filter |
7161578
to
e216c8f
Compare
0f16611
to
95ee788
Compare
@pepelsbey Я сделяль вторую версию с бротли и блекджеком. Дальше можно думать как сие деплоить |
Модуль с brotli нужно ещё подключить и настроить. Можно жать на лету, но я бы предложил использовать раздачу заранее подготовленных brotli и gzip архивов. После сборки в папке со статикой создать brotli-архивы (тут прорекламирую свою утилиту web compressor), затем настроить nginx на раздачу этих архивов: load_module modules/ngx_http_brotli_static_module.so;
http {
server {
brotli_static on;
}
} |
Там уже настроено. Контейнер вытаскивает приватный репозиторий с конфигами. Именно поэтому там странные ssh маунты внутри ) |
Хорошо, но я всё равно настаиваю на статике – зачем сжимать на каждый запрос, если это можно сделать один раз заранее. |
Сжатие на каждый запрос более гибкое. Можно положить на сервер что-то мимо сборки, если нужно. Или использовать этот образ для других проектов. Ну и в целом цена сжатия на лету небольшая, вроде. |
Динамическое сжатие хорошо применять, где есть генерация на лету html, rss, xml или json. Ничего из этого в проекте нет. А так можно создать архивы с максимальной степенью сжатия. |
Правильно ли я понимаю, что сжатие происходит в момент сборки контейнера, когда он забирает весь контент, и неважно, что там вообще? |
Да, но можно настроить какие именно файлы сжимать и какой должен быть минимальный размер файла (как правило, файлы меньше 1Кб становятся только больше). |
Ну тогда такая стратегия кажется адекватной. Лишь бы она не слишком замедляла скорость сборки (и не повышала бы его цену) из-за слишком высокого сжатия) |
Я согласна. Сборковое сжатие имеет смысл. Однако я бы кушала слоника по частям и сначала допинала докер идентичный текущему сетапу. Дальше можно отдельно подумать про производительность и порешать проблемы которые есть (я предположу что сейчас почти никаких нет) И вот только после того можно заняться творчеством и выкрутить перформанс на максимум. Думаю что первым шагом для этого было бы хорошо посмотреть конфиг/наличие CDN. Так как CDN отвечает за самое агрессивное кеширование. Ну и дальше поиграть c http заголовками, посмотреть оптимизирован ли SSL и что-то вынести на этап сборки |
Синьора ответ 😎 Согласен! |
Co-authored-by: monochromer <[email protected]>
Запаковывает приложение в контейнер. Работает в одном из двух режимов - локальный тест (без сертификатов) или прод сборка (предполагается что сертификаты есть на машине где запускается контейнер)
Чтобы потестировать можно сделать так
Запустите команду
docker build -t <имя_контейнера> --build-arg NGINX_CONF=nginx.local.conf .
Запустите
docker run -p 8080:80 <имя_контейнера>
.Проверьте результат на localhost:8080