Как хранить данные в GCS при доступе к ней из GAE и GCE локально

Существует проект GAE с использованием GCS для хранения/получения файлов. Эти файлы также должны быть прочитаны кодом, который будет запущен на GCE (для этого нужны библиотеки С++, поэтому не работает в GAE).

В производстве, развернутом на фактическом GAE > GCS < GCE, эта настройка работает нормально. Тем не менее, тестирование и разработка локально - это другая история, которую я пытаюсь выяснить.

Как и было рекомендовано, я запускаю GAE dev_appserver с GoogleAppEngineCloudStorageClient для доступа к (имитируемому) GCS. Файлы помещаются в локальный blobstore. Отлично подходит для тестирования GAE.

Поскольку это не GCE SDK для запуска виртуальной машины локально, всякий раз, когда я ссылаюсь на локальный "GCE", это просто моя локальная машина разработки, работающая под Linux. На локальной стороне GCE я просто использую библиотеку boto по умолчанию (https://developers.google.com/storage/docs/gspythonlibrary) с помощью среды выполнения python 2.x для взаимодействия с кодом С++ и получения файлов из GCS. Однако в процессе разработки эти файлы недоступны из boto, поскольку они хранятся в блочном блоке dev_appserver.

Есть ли способ правильно подключить локальные GAE и GCE к локальному GCS?

В настоящее время я отказался от местной части GCS и попытался использовать реальный GCS. Часть GCE с boto проста. Часть GCS также может использовать реальный GCS, используя access_token, поэтому вместо локального blobstore использует реальный GCS:

cloudstorage.common.set_access_token(access_token)

Согласно документам:

access_token: you can get one by run 'gsutil -d ls' and copy the
  str after 'Bearer'.

Этот токен работает в течение ограниченного промежутка времени, так что он не идеален. Есть ли способ установить более постоянный access_token?

Ответ 1

Похоже, appengine-gcs-clien t для Python теперь полезен только для создания App Engine и внутри dev_appserver.py, а локальные примеры для он был удален из документов разработчика в пользу Boto:( Если вы решите не использовать локальную эмуляцию GCS, лучше всего использовать Boto для локального тестирования и GCE.

Если вы все еще хотите использовать "google.appengine.ext.cloudstorage", хотя токены доступа всегда заканчиваются, поэтому вам нужно вручную обновить его. Учитывая вашу настройку, проще всего просто вызвать "gsutil -d ls" из Python и проанализировать вывод, чтобы получить новый токен из ваших локальных учетных данных. Вы можете использовать клиентскую библиотеку API-интерфейсов, чтобы получить токен более "правильным" способом, но в этот момент все будет так круто, что вы можете а также просто использовать Boto.

Ответ 2

Существует удобная опция для доступа к облачному хранилищу Google из среды разработки. Вы должны использовать клиентскую библиотеку, предоставляемую с помощью Google Cloud SDK. После выполнения gcloud init локально вы получаете доступ к своим ресурсам.

Как показано в примерах Проверка клиентской библиотеки:

# Get the application default credentials. When running locally, these are
# available after running `gcloud init`. When running on compute
# engine, these are available from the environment.
credentials = GoogleCredentials.get_application_default()

# Construct the service object for interacting with the Cloud Storage API -
# the 'storage' service, at version 'v1'.
# You can browse other available api services and versions here:
#     https://developers.google.com/api-client-library/python/apis/
service = discovery.build('storage', 'v1', credentials=credentials)

Ответ 3

Поскольку вы используете Boto в "GCE", я бы поискал еще один автономный сервер, поддерживающий s3 и запускающий его в другой VM/container/etc. В "GCE".

Ответ 4

Если вы всегда используете "реальный" удаленный GCS, новый gcloud, вероятно, является лучшей библиотекой: http://googlecloudplatform.github.io/gcloud-python/

Это действительно запутывает, сколько библиотек клиентских хранилищ существует для Python. Некоторые из них предназначены только для AE, но они часто вынуждают (или, по крайней мере, по умолчанию) использовать локальный макет Blobstore при работе с dev_appserver.py.

Кажется, что gcloud всегда использует реальный GCS, чего я хочу. Он также "волшебным образом" исправляет аутентификацию при локальном запуске.

Ответ 5

Для этой цели существует локальный сервер/сервер разработки Cloud Cloud: https://developers.google.com/datastore/docs/tools/devserver

После того, как вы настроили его, создайте набор данных и запустите сервер разработки GCS

gcd.sh create [options] <dataset-directory>
gcd.sh start [options] <dataset-directory>

Экспортировать переменные среды

export DATASTORE_HOST=http://yourmachine:8080
export DATASTORE_DATASET=<dataset_id>

Затем вы можете использовать локальное соединение datastore в своем коде.