Я только что создал виртуальный экземпляр с помощью Google Cloud, но у меня есть три проекта, и он назначил экземпляр не тому проекту. Это действительно похоже на ошибку, но как я могу быть уверен, что вина лежит на Google, а не на мне. Кроме того, кто-то неизбежно посоветует мне использовать облачную консоль для создания экземпляров, поэтому позвольте мне опередить этот совет. Я пытаюсь свести все свои облачные вычисления к нажатию одной кнопки. Я планирую регулярно создавать и уничтожать экземпляры, и я должен иметь возможность делать это быстро и эффективно. Следовательно, все мои облачные вычисления должны выполняться с помощью Python. В любом случае у меня есть два проекта: «move_files» и «9920» (названия я не придумал). Я использовал следующий синтаксис Python:

import subprocess
str1 = "/users/kylefoley/codes/move.json"
os.environ['GOOGLE_APPLICATION_CREDENTIALS'] = str1

def create_instance(name='', machine_type=''):
    name = 'kfoley76'
    machine_type = 'n1-standard-1'

    subprocess.run(['gcloud', 'compute', 'instances', 'create',
                    name, f'--machine-type={machine_type}',
                    '--zone=us-west2-a'])

create_instance()

Этот код привел к созданию экземпляра в «атомарном» проекте, а не в проекте «перемещение», и все же мои учетные данные приложения Google четко указывали на обратное. Единственное, о чем я могу думать, это то, что я как-то неправильно назвал файл json. Но как мне это проверить?

Кроме того, позвольте мне предоставить доказательство того, что неправильный идентификатор проекта содержит экземпляры. Думаю, я не смогу сохранить имена в секрете, но я полагаю, что их нельзя украсть, если кто-то не знает мой пароль. Атомный проект действительно называется 9920:

the move files project (no instances)

the 9920 project

0
logic1976 23 Дек 2019 в 16:36
Метод: projects.get( ) поможет вы получаете информацию о своем проекте, такую ​​как имя, родитель, projectId и projectNumber. Вы можете использовать клиентскую библиотеку Python. Затем вы можете выполнить gcloud config set project my-project, где my-project — ваш идентификатор проекта, который позволит указать идентификатор проекта Google Cloud Platform для работы по умолчанию. Позвольте мне знать, если это помогает.
 – 
sllopis
23 Дек 2019 в 17:34

1 ответ

Я рекомендую другой (лучший) подход, чем использование Python для выполнения вызовов gcloud. Хотя ваш текущий подход будет работать, он более сложен, чем необходимо, усложняет обработку ошибок и, как вы видели, может привести к неожиданному поведению. В этом случае, поскольку вы обращаетесь к gcloud, вы также наследуете его конфигурацию.

Альтернативой является использование Google Python SDK. Все сервисы Google (например, Compute Engine) доступны через предоставленные Google SDK. Существует 2 основных разновидности SDK. Более старые клиентские библиотеки API и более новые (и только для [некоторых] облачных сервисов [и, к сожалению, не для Compute Engine]) облачные клиентские библиотеки. Вот пояснение от Google.

NB gcloud сам написан на Python и использует клиентские библиотеки API.

Документация API Google превосходна. Каждый сервис (не только Cloud) и каждый метод полностью (и правильно|автоматически) документирован. Вот метод вставки экземпляра Compute Engine: https://cloud.google.com/compute/docs/ ссылка/остальные/v1/экземпляры/вставка

Примечание На странице также представлен обозреватель API Google, который позволяет напрямую выполнять вызов API для наблюдения за поведением.

Если вы прокрутите эту страницу вниз, вы найдете примеры для каждого из языков, поддерживаемых Google: https://cloud.google.com/compute/ docs/reference/rest/v1/instances/insert#examples

См. также эту страницу для примера: https://cloud.google.com/compute/docs/tutorials/python- руководство

NB Когда вы используете (любой из) API напрямую, вы должны явно указать, какой проект использовать. Это связано с тем, что gcloud допускает значения по умолчанию, например. gcloud config set project, но сами API не имеют состояния и не имеют.

Примечание Я лично рекомендую никогда не использовать gcloud config set ..., так как это может привести к подобным проблемам. Я думаю, что лучше всегда явно ссылаться, например. проект с помощью команд gcloud, например. gcloud ... --project=${PROJECT} ...

1
DazWilkin 25 Дек 2019 в 03:53
«Документация API Google превосходна». -- Точно нет. Но опять же, то же самое относится и к 90% всей документации, которую я когда-либо читал, так что API Google является средним в том, что касается документации, но это все равно, что сказать, что эта свалка мусора является средней в отношении дампов мусора.
 – 
logic1976
28 Дек 2019 в 17:38
Позвольте мне привести вам пример того, насколько плоха документация. Предположим, я хочу переписать код `subprocess.run(['ssh-keygen', '-t', 'rsa', '-f', '/users/kylefoley/.ssh/ssh_key','-C', 'kylefoley76'])` с помощью Google API. Ввожу ssh в окно поиска и нам даже ничего не приходит.
 – 
logic1976
31 Дек 2019 в 19:37
subprocess – это модуль Python (а не API Google). Когда вы используете subprocess, ваше программирование на Python порождает программу gcloud как отдельный процесс. Я рекомендую вам не использовать subprocess для запуска команд gcloud (для последующего вызова Google API), а использовать Google Cloud API для Compute Engine непосредственно в вашей программе Python.
 – 
DazWilkin
31 Дек 2019 в 22:23