Вот моя установка. У меня есть большой сервер, работающий на Google Cloud Compute. Перед ним работает обратный прокси-сервер в Google Cloud Run (в настоящее время nginx). Чтобы сэкономить на расходах, у меня есть задание cron, запущенное на большом сервере, которое отключает его после 15 минут бездействия между прокси и сервером.
Однако у меня возникли проблемы с поиском хорошего способа надежно «разбудить» большой сервер из контейнера Cloud Run. У меня было несколько идей, но у каждой есть недостатки.
Команда пробуждения в точке входа
Моей первой мыслью было добавить команду пробуждения к моему entrypoint.sh
. Каждый раз, когда к контейнеру обращаются, он отправляет команду, чтобы разбудить более крупный сервер.
Однако, хотя экземпляры Cloud Run не должны быть постоянными, я попытался кэшировать некоторые данные в тестовом экземпляре и получить к ним доступ позже. Я не уверен, каков «официальный» срок службы контейнеров, но я все еще мог получить доступ к этим кэшированным данным почти через час. Итак, полагаться на команду пробуждения, которая запускается при запуске контейнера, ненадежно.
OpenResty и os.execute
Я был почти уверен, что это решение. OpenResty - это разновидность nginx с расширениями, которые позволяют запускать скрипты LUA внутри вашего nginx.conf
файлы. Итак, я мог бы сделать что-то вроде этого:
server {
listen 8080;
server_name localhost;
location / {
proxy_pass_header Authorization;
proxy_pass http://10.168.0.2;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
content_by_lua_block {
os.execute("/bin/bash /start.sh")
}
}
Мой start.sh
тогда что-то вроде этого:
#!/bin/bash
diff=$(expr $(date +%s) - $(cat /last_request_time.txt))
if [[ $diff -gt 900 ]]
then
gcloud -q --no-user-output-enabled --verbosity=none compute instances start <instance> --zone=<zone> --project=<project> &
echo $(date +%s) > /last_request_time.txt
fi
Я пытаюсь избежать ненужной отправки команд пробуждения с КАЖДЫМ запросом к моему обратному прокси (отсюда и last_request_time.txt
файл в моем start.sh
). Это казалось хорошим решением.
Что ж, оказывается, вы не можете сделать и то, и другое. У вас может быть конечная точка, которая запускает сценарии LUA или размещает запросы страниц / прокси, но это не позволит вам запускать сценарий с каждым запросом на соединение. Бу.
cron Job или цикл в точке входа
Я всегда мог иметь свой start.sh
сценарий сверху запускается каждую минуту как задание cron или в while
цикл в моем сценарии точки входа. Теоретически это могло бы сработать, но я не уверен, что это будет держать контейнер в активном состоянии (что противоречит цели Cloud Run). Так . . . Я не уверен насчет этого.
Я слишком много думаю об этом?
Я отлично умею усложнять ненужные вещи. Я слишком много думаю об этом? Есть ли решение попроще?