Я хотел бы иметь возможность доступа к данным на листе Google при запуске кода Python через облачный композитор;Это то, что я знаю, как делать несколькими способами при локальном запуске кода, но переход в облако оказывается сложной задачей.В частности, я хочу аутентифицироваться как учетная запись службы композитора, а не хранить где-нибудь содержимое файла client_secret.json (будь то исходный код или какое-то облачное хранилище).
По сути тот же вопрос, но вместо доступа к сервисам облачной платформы Google, это было относительно легко (даже при работе через composer) благодаря библиотекам google-cloud_ * .Например, я подтвердил, что могу отправлять данные в bigquery:
from google.cloud import bigquery
client = bigquery.Client()
client.project='test project'
dataset_id = 'test dataset'
table_id = 'test table'
dataset_ref = client.dataset(dataset_id)
table_ref = dataset_ref.table(table_id)
table = client.get_table(table_ref)
rows_to_insert = [{'some_column':'test string'}]
errors = client.insert_rows(table,rows_to_insert)
, и успехом или неудачей этого можно управлять с помощью совместного использования (или нет) набора тестовых данных с учетной записью службы композитора.
Аналогично, получение данных из хранилища облачных хранилищ работает нормально:
from google.cloud import storage
client = storage.Client()
bucket = client.get_bucket('test bucket')
name = 'test.txt'
data_blob = bucket.get_blob(name)
data_pre = data_blob.download_as_string()
и еще раз у меня есть возможность контролировать доступ через IAM.
Однако для работы с листами Google мне кажется, что я должен прибегнуть к Python-клиенту API Google, и здесь я сталкиваюсь с трудностями.Большая часть документации по этому (которая кажется движущейся целью!) Предполагает локальное выполнение кода, начиная с создания и хранения файла client_secret.json пример 1 , пример 2 , которыйЯ понимаю локально, но не имеет смысла для общей облачной среды с контролем исходного кода.Итак, вместо этого я попробовал пару подходов:
Попытка создания учетных данных с использованием discovery и oauth2
from googleapiclient.discovery import build
from httplib2 import Http
from oauth2client.contrib import gce
SAMPLE_SPREADSHEET_ID = 'key for test sheet'
SAMPLE_RANGE_NAME = 'test range'
creds = gce.AppAssertionCredentials(scope='https://www.googleapis.com/auth/spreadsheets')
service = build('sheets', 'v4', http = creds.authorize(Http()))
sheet = service.spreadsheets()
result = sheet.values().get(spreadsheetId=SAMPLE_SPREADSHEET_ID,
range=SAMPLE_RANGE_NAME).execute()
values = result.get('values', [])
Предупреждение: я ничего не знаю о работе с областями действиясоздавать учетные объекты через Http.Но, похоже, это ближе всего к работе: я получаю ошибку HTTP403
'Запрос имеет недостаточные области проверки подлинности.'
Однако я не знаю, означает ли это, что яуспешно представил себя как служебную учетную запись, которая тогда была признана непригодной для доступа (поэтому мне нужно еще немного возиться с разрешениями);или на самом деле не зашли слишком далеко (и нужно исправить этот процесс создания учетных данных).
Получение объекта учетных данных с помощью google.auth и передача gspread
My(ограниченное) понимание состоит в том, что oauth2client устарел , и теперь google.auth - это путь.Это дает объекты учетных данных таким же простым способом, что и мои успешные примеры, приведенные выше для сервисов облачной платформы, и я надеялся, что смогу просто перейти к gspread:
import gspread
from google.auth import compute_engine
credentials = compute_engine.Credentials()
client = gspread.authorize(credentials)
К сожалению, gmental не работает с этими объектами, потому чтоу них нет ожидаемых атрибутов:
AttributeError: у объекта 'Credentials' нет атрибута 'access_token'
Это, вероятно, потому что gspread ожидает учетные данные oauth2 и тевычеркнутые google.auth недостаточно совместимы. gspread docs также опускаются до уровня "просто получить файл client_secret" ... но, вероятно, если я смогу использовать предыдущий (основанный на oauth / http) подход, я мог бы затем использовать gspread для извлечения данных,На данный момент, однако, гибрид этих двух подходов спотыкается одинаково: отказано в разрешении на ответ из-за недостаточных областей аутентификации.
Итак, будь то использование google.auth, oauth2 (при условии, что длякакое-то время) или какой-либо другой облачный подход (т. е. не основанный на хранении секретного ключа), как я могу получить подходящие учетные данные в среде облачного композитора для выполнения вызовов API листов Google ?Бонусные оценки за способ, который совместим с gspread (и, следовательно, gspread_dataframe), но это не обязательно.Также рад слышать, что это ошибка PEBCAK, и мне просто нужно настроить разрешения IAM по-другому для моего текущего подхода к работе.