Как перенаправить URL-адрес администратора блога Ghost без изменения адреса API?

Question

Платформа блога Ghost имеет параметр, позволяющий изменить местоположение входа в административную панель (которое начинается с: https://whateveryoursiteis.com/ghost). Методологию / документацию для изменения этого параметра можно найти здесь: https://docs.ghost.org/concepts/config/#admin-url

Однако - при использовании описанной выше методологии URL-адрес API, который используется для поиска и т. Д., Также изменяется, что означает, что все запросы к API-призраку будут также перенаправляться в альтернативный домен (не только для доступа администратора).

Мой вопрос - каков наилучший способ добиться перенаправления URL-адреса администратора на другой домен / протокол, при этом оставляя неизменным URL-адрес API, используемый Ghost?

Дополнительные сведения.

Мы запускаем ghost поверх GKE (Google Kubernetes Engine) на входе в несколько регионов, что позволяет нам выгружать нашу базу данных CloudSQL в файл SQLite, а затем встраивать эту базу данных в наши рабочие контейнеры Docker, которыезатем развертываются на разных узлах Kubernetes, с которыми работает балансировщик нагрузки GCE-Ingress.

Поскольку нам нужно перестраивать эту базу данных / контейнер при изменении содержимого (а не только при изменении кода), нам нужен отдельный URL-адрес администратора, поддерживаемый Cloud SQL, где мы можем сохранять / изменять наши данные, что затем вызывает перестроение принаш конвейер Ci через Ghost Webhooks.

Еще один связанный с этим вопрос может быть:

Можно ли использовать стандартные перенаправления призраков (созданные с помощью: https://docs.ghost.org/concepts/redirects/) для перенаправления администратораURL панели (т.е.https://whateveryoursiteis.com/ghost) в другой домен (т. Е. https://youradminsite.com/ghost)?

Другой связанный вопрос GKE / GCE-Ingress:

Можно ли создать 301 перенаправлениеизначально использовать Kuberentes GCE-Ingress на GKE без добавления контейнера nGinx и т. д.- Я попытаюсь ответить, когда найду ответы на эти вопросы (при условии, что кто-то не побьет меня!).

Answer 1

OK.Так что, как выясняется, команда Ghost в настоящее время настроена так, чтобы указывать соединения API на URL администратора.Поэтому, если вы измените свой URL-адрес администратора, ожидайте, что ваши клиенты попытаются подключиться к этому URL-адресу.

Я собираюсь повысить вероятность их разделения в виде запроса функции на форумах-призраках (как только явыйти из-под ада перед запуском текущего проекта).

Вот официальный ответ Ghost:

То, что называется «официальным изображением докера», - это не то, что мы какподдержка команды Ghost.

API действительно размещаются по тому же URL-адресу, что и администратор, и это не является ошибкой.Представление опций конфигурации для каждого хоста экземпляра API Ghost было бы функцией и должно обсуждаться в первую очередь на нашем форуме ? Я думаю, что это хорошая идея, чтобы иметь возможность обслуживать API с разных хостов, но это не то, что в наши приоритеты в данный момент.

Если вам требуется более детальная обработка сайта администратора, вы можете представить их на уровне прокси и, например, обрабатывать запросы, поступающие в / ghost / api, с другим набором правил.

См. Полное обсуждение здесь на TryGhost GitHub: https://github.com/TryGhost/Ghost/issues/10441#issuecomment-460378033

Я не рассматривал, что потребуется для реализации этой функции, но предложение о прокси запроса может сработать.... если бы мне не нужно было работать в GKE Multi регионе (который требует использования GCE-Ingress, у которого нет поддержки перенаправления, ха!).Это было бы относительно легко решить для входа nGinx.

Надеюсь, это кому-нибудь поможет - я буду обновляться по мере прохождения процесса.На данный момент я решил эту проблему, выгрузив свою базу данных GCP CloudSQL вниз в файл базы данных SQLite во время сборки (что позволило мне сохранить мой экземпляр администратора чистым и отделенным от конечной точки API - который для меня остается тем же URL).

Answer 2

Относительно вашего вопроса, если возможно создать перенаправления 301 без добавления контейнера nginx, я могу предложить использовать istio, узнать больше информации о маршрутизации трафика здесь .