Назад | Перейти на главную страницу

Отправляйте команды пробуждения на более крупный сервер с обратного прокси-сервера в Google Cloud Run

Вот моя установка. У меня есть большой сервер, работающий на 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). Так . . . Я не уверен насчет этого.

Я слишком много думаю об этом?

Я отлично умею усложнять ненужные вещи. Я слишком много думаю об этом? Есть ли решение попроще?