com.google.api.config.ServiceConfigSupplier - не удалось получить версию конфигурации по умолчанию для службы (только на локальном хосте)
Я использую Cloud Endpoints Frameworks (2.0.1) для Java как часть моего проекта за последний год и до сих пор был относительно успешным с ним. У меня нет проблем при развертывании на моем домене appspot.com, однако при локальном развертывании у меня возникают некоторые проблемы.
(Любые ссылки на my-project-id в следующих блоках кода являются псевдонимами для моего фактического идентификатора проекта в облачном Google)
У меня есть действительный дескриптор openapi (openapi.json) аннотированного класса @API, который я развертываю на конечных точках облака, используя "gcloud service-management deploy openapi.json". Команда успешно возвращается:
Service Configuration [2017-02-23r0] uploaded for service [api.endpoints.<my-project-id>.cloud.goog]
Затем я сопоставляю возвращенный config_id с правильным endpoints_api_service в моем app.yaml
endpoints_api_service:
name: api.endpoints.<my-project-id>.cloud.goog
config_id: 2017-02-23r0
Эта служба указана в gcloud cli с помощью "списка управления службами gcloud".
NAME TITLE
storage-component.googleapis.com Google Cloud Storage
api.endpoints.<my-project-id>.cloud.goog api.endpoints.<my-project-id>.cloud.goog
etc...
и "список конфигураций управления службами gcloud --service api.endpoints.my-project-id.cloud.goog"
CONFIG_ID SERVICE_NAME
2017-02-23r0 api.endpoints.<my-project-id>.cloud.goog
... other version configs
и доступен в моем домене appspot.com (я могу позвонить на конечную точку и получить правильный ответ)
Я пытаюсь развернуть свой проект на локальном хосте, используя плагин maven appengine для java (mvn appengine:devserver), но после запуска я получаю следующее исключение:
WARNING: Failed startup of context com.google.appengine.tools.development.DevAppEngineWebAppContext...
com.google.api.config.ServiceConfigException: Failed to fetch default config version for service 'api.endpoints.<my-project-id>.cloud.goog'. No versions exist!
at com.google.api.config.ServiceConfigSupplier.fetchLatestServiceVersion(ServiceConfigSupplier.java:155)
....
Затем развертывание застревает в бесконечном цикле попыток запустить причал и получить сообщение об ошибке, перезапуск и т. Д. Любые попытки доступа к localhost:8080 приводят к ошибке "503: служба не найдена"
Я предполагал, что локальное развертывание моего приложения сможет получить доступ к конфигурации службы, которая была развернута с помощью "развертывания gcloud service-management", так же, как и развертывание appspot.com, но разве это не так? Глядя на источник для ServiceConfigSupplier.getchLatestServiceVersion(), я понимаю, что serviceManagement.services(). Configs(). List(my-service-name).execute(). GetServiceConfigs() возвращает пустой список, но почему это только происходит локально?
Дополнительная информация
моя переменная окружения ENDPOINTS_SERVICE_NAME совпадает с 'api.endpoints.my-project-id.cloud.goog'
Я заметил, что несколько дней назад было обновление (1.0.2) для com.google.api.config, и оно зависит от более старой версии com.google.api.services.servicemanagement (зависит от v1-rev14). -1.22.0 с последней версией v1-rev340-1.22.0) Я сомневаюсь, что это проблема, но я подумал, что упомяну об этом, поскольку он содержит классы, относящиеся к исключению (ServiceManagement используется ServiceConfigSupplier, который выбрасывает исключение). Возможно, есть несогласованность в том, где они ищут сервисные конфиги?
Я довольно озадачен, это немного над моей головой. Мне не хотелось бы удалять конечные точки, как мне это начинает нравиться, но мы также не можем потерять использование нашего devserver. Я надеюсь, что кто-то может пролить немного света на эту проблему.
7 ответов
Это не исправление, но я смог обойти проблему, воспользовавшись советом в /questions/11287199/ispolzovanie-oblachnyih-konechnyih-tochek-google-v-appengine/11287207#11287207.
А именно, комментируя ServiceManagementConfigFilter:
б) закомментируйте ServiceManagementConfigFilter из web.xml, т.е.
<!-- <filter> <filter-name>endpoints-api-configuration</filter-name> <filter-class>com.google.api.control.ServiceManagementConfigFilter</filter-class> </filter> --> <!-- <filter-mapping> <filter-name>endpoints-api-configuration</filter-name> <servlet-name>EndpointsServlet</servlet-name> </filter-mapping> -->
Обратите внимание, что вы должны закомментировать filter и filter-mapping и они не рядом друг с другом в файле.
Я обнаружил, что мне не нужно удалять блок масштабирования, как указано в пункте "а" в связанном ответе.
Это может быть связано с проблемой разрешения, если вы извлекли все последние обновления. git pull Также убедитесь, что ваш Cloud SDK обновлен, используя: gcloud components update,
Предполагая, что вы следовали инструкциям, перечисленным на https://cloud.google.com/endpoints/docs/frameworks/java/quickstart-frameworks-java. Чтобы обойти эту проблему, вы можете создать учетную запись службы с необходимыми разрешениями или использовать команду gcloud auth application-default login,
Вы можете настроить служебную учетную запись с помощью Cloud SDK gcloud по адресу https://cloud.google.com/sdk/docs/authorizing
Пожалуйста, дайте мне знать, если у вас есть еще вопросы.
Что касается команды gcloud auth application-default login, Согласно описанию справки:
Получает учетные данные для доступа пользователей через веб-поток и помещает их в известное место для учетных данных приложения по умолчанию, чтобы использовать их в качестве прокси для учетной записи службы.
Когда вы используете эту команду, она получает учетные данные для gcloud вашей учетной записи Gmail. что-то@gmail.com, а затем сохраняет учетные данные в месте, которое, как известно, содержит учетные данные приложения.
Это может произойти, если вы изменили проект Google Cloud, в котором вы пытаетесь пройти аутентификацию (если кто-то изменил проект, это может произойти, когда вы извлекаете изменения из системы контроля версий). В этом случае учетные данные учетной записи службы, которые вы использовали для старого проекта, больше не будут действительными, и вы можете пройти аутентификацию в новом проекте, выполнив:
gcloud auth application-default login
Он работал с "gradle appengineRun", но в проекте IntelliJ Idea мне пришлось заменить все ${endpoints.project.id} в web.xml и appengine-web.xml, чтобы запустить / отладить localhost из IntelliJ (импортированный из исходников gradle, установленный Плагин Google Cloud Tools и настройте конфигурацию запуска / отладки из Tools/GoogleCloudTools/ Запуск на локальном сервере App Engine Standard dev).
Моя ошибка: не удалось получить версию конфигурации по умолчанию для службы 'echo-api.endpoints.${Endpoints.project.id}.cloud.goog'. Никаких версий не существует!
cloud.google.com в документах есть только пример сборки Maven Сборка Gradle находится на github.com
Для меня проблема заключалась в том, что я не развернул открытый API. Таким образом, выполнив приведенное ниже, проблема была устранена:
gcloud endpoints services deploy openapi.json
У меня была довольно похожая ошибка,
endpoints.repackaged.com.google.api.config.ServiceConfigException: не удалось получить конфигурацию службы (код состояния 404): не удалось найти имя конфигурации службы и идентификатор конфигурации. Дважды проверьте правильность установки параметров инициализации фильтра endpoints.projectId и endpoints.serviceName.
и проблема для меня заключалась в том, что переменная среды ENDPOINTS_SERVICE_VERSION была указана в моем appengine-web.xml. Таким образом, в принципе, удаления этих строк было достаточно в моем случае (поскольку конечные точки используют самый последний ENDPOINTS_SERVICE_VERSION, если он не предоставлен).
<env-var name="ENDPOINTS_SERVICE_VERSION" value="1" />
Еще одна вещь, которую стоит иметь в виду, это то, что ваша учетная запись службы имеет необходимые разрешения, ваша учетная запись службы выглядит следующим образом
[project ID]@appspot.gserviceaccount.com.
По умолчанию это Project(редактор), по крайней мере, вам нужно предоставить его в качестве роли Service Controller.
Если это не так, вы можете следовать этим инструкциям, чтобы добавить обратно.