Google App Engine, 2 службы, dispatch.yaml: похоже, nginx-app.conf больше не учитывается

Я пытаюсь переместить существующее приложение на GoogleAppEngine PHP/Flex в GoogleAppEngine PHP/Standard, чтобы воспользоваться функциями стандартного движка.

Мой проект настроен следующим образом:

  • server/public_html/rest/index.php: Slim Framework, front_controller_file
  • server/src : код приложения php
  • server/public_html/index.html : приложение angularjs (+другие файлы в этом каталоге.

В GAE PHP Flex мой файл app.yaml выглядел следующим образом:

api_version: 1

runtime: php
env: flex

skip_files:
        - ^db$
        - ^vendor$
        - ^Spotfire$
        - ^complete-sync\.sh$
        - ^phinx\.yml$
        - ^phinx-template\.yml$
        - ^selective-sync\.sh$

runtime_config:
  document_root: /app/public_html
  front_controller_file: /app/public_html/rest/index.php
  enable_stackdriver_integration: true
...

И чтобы Slim Framework работал

nginx-app.conf находился в /server/nginx-app.yaml

location / {
  # try to serve file directly, fallback to front controller
  try_files $uri /index.html$is_args$args;
}
location /rest {
  # try to serve file directly, fallback to front controller
  try_files $uri /rest/index.php$is_args$args;
}

location ~ \.php {
    try_files $uri =404;
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param SCRIPT_NAME $fastcgi_script_name;
    fastcgi_index index.php;
    fastcgi_pass 127.0.0.1:9000;
}

Теперь, в стандарте GAE PHP, мой app.yaml выглядит следующим образом:

runtime: php72
entrypoint: serve public_html/rest/index.php

runtime_config:
        document_root: public_html
        enable_stackdriver_integration: true

и мой dispatch.yaml выглядит следующим образом:


dispatch:
  # Send all rest traffic to the backend
  - url: "*/rest/*"
    service: default

  # Send the rest to the front (angularjs)
  - url: "*/*"
    service: front

и nginx-app.conf все тот же.

Когда я достигаю URL-адреса (example.com) приложения, приложение angularjs загружается правильно, я вижу экран входа в систему.

если я перейду на example.com/rest/index.php

Я получаю ошибку аутентификации, что является ожидаемым поведением.

Однако, если я пойду в

example.com/rest/authenticate

Я получаю 404, и я все еще должен получить ошибку приложения вместо 404. С правилом перезаписи nginx он должен преобразовать URL-адрес в это:

example.com/rest/index.php?аутентифицировать

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

Когда я нажал кнопку входа в систему, в моем гибком развертывании путь $ был «аутентифицирован», а здесь «/rest/authenticate».

$path   = $request->getUri()->getPath   ();

Любая идея о том, как отладить это?

Я чувствую, что мог бы использовать только одну службу (по умолчанию), но example.com/ указывает на public_html/rest/index.php, что мне не подходит, так как я хочу/быть приложением angularjs и частью REST с отдыхом/ в пути.


person Thomas    schedule 04.04.2019    source источник
comment
Чувак, я думаю, ты должен переписать свой вопрос и попытаться сделать его короче.   -  person IsraGab    schedule 04.04.2019
comment
Я переписал вопрос теперь, когда я знаю, что стандарт GAE не предоставляет никаких средств для перезаписи URL: stackoverflow.com/questions/55540008/   -  person Thomas    schedule 05.04.2019
comment
Не должно быть необходимости трогать файл dispatch.yaml, который работает выше уровня службы и определяет по имени, к какой службе должен быть направлен конкретный запрос. Язык программирования/среда служб не имеют значения в этом решении о маршрутизации.   -  person Dan Cornilescu    schedule 06.04.2019
comment
У меня есть две службы: передняя (для приложения angularjs) и по умолчанию для остальных API. Я не уверен, что мне нужно развертывать angularjs в другом сервисе... все еще изучаю.   -  person Thomas    schedule 06.04.2019


Ответы (1)


Возможно, в вашем файле index.php есть неправильное направление. Взгляните на ваши разные случаи и на какой файл .php ссылается страница аутентификации, чтобы убедиться, что он такой же для аутентификации, как и на других страницах. Поскольку dispatch.yaml имеет приоритет над всеми другими методами маршрутизации, у вас может возникнуть конфликт между index.php и dispatch.yaml. Вы можете провести некоторое тестирование обработки своих сервисов непосредственно из index.php, если у вас возникли трудности с устранением неполадок. У вас также может быть файл authentication.php в другой подпапке.

Если вы получаете 200 при прямом доступе к example.com/rest/authenticate.php, то виноват может быть index.php. Поскольку стандартная среда для App Engine отличается от среды Flex, вот некоторые документы, относящиеся к вашей ситуации:

Передние контроллеры: https://cloud.google.com/appengine/docs/standard/php7/building-app/#initializing Dispatch.yaml: https://cloud.google.com/appengine/docs/standard/php7/reference/dispatch-yaml Точка входа: https://cloud.google.com/appengine/docs/standard/php7/runtime#application_startup

Кроме того, более внимательное изучение трассировки, ведущей к ошибке 404, может дать вам некоторые подсказки.

Вот несколько общих советов по переходу с одной среды на другую (обратные, но все же полезные): https://cloud.google.com/appengine/docs/flexible/php/migrating

Ваше здоровье

person PYB    schedule 05.04.2019
comment
Спасибо за ответ. Я не понимаю, почему может возникнуть конфликт между index.php и dispatch.yaml. Я бы сказал, что это между nginx-app.conf и dispatch.yaml. Также в документации Slim говорится, что для этого требуется перезапись URL-адреса, а стандарт GAE не предоставляет этого. Поэтому я чувствую, что здесь не хватает части, чтобы SlimFramework работал правильно. Я использую тонкий только для вызова отдыха, поэтому, возможно, я делаю дополнительное использование, и тонкий может работать в другом сценарии. Я пытаюсь реализовать это решение: cloud.google.com/appengine /docs/standard/php/config/mod_rewrite Я чувствую, что не за горами, чтобы заставить его работать - person Thomas; 06.04.2019
comment
Что возвращается при непосредственном переходе по этим URL-адресам (вывод ОТРЕДАКТИРОВАНО)?: - example.com/rest/authenticate.php - example.com/rest/index.php?authenticate - person PYB; 11.04.2019