6

Каков наилучший способ развертывания учетных данных учетной записи службы Google в специально созданном контейнере CentOS Docker для работы в Google Container Engine или их контейнере-vm? Это происходит автоматически в контейнере google/cloud-sdk, который запускает debian и включает в себя то, что я не использую, например app-eng/java/php. В идеале я пытаюсь получить доступ к непубличным ресурсам внутри моего проекта, например, к облачным хранилищам Google Cloud Storage, без регистрации и авторизации каждый раз, когда запускается большое количество этих контейнеров.Рекомендуемая аутентификация учетной записи службы GCE внутри контейнера Docker?

Например, базовый Centos контейнер работает на GCE с пользовательским кодом и gcloud/GSUtil установлен, при запуске:

docker run --rm -ti custom-container gsutil ls 

Вам будет предложено запустить «GSUtil конфигурации», чтобы получить разрешение, которое я ожидать.

Однако, вытаскивая контейнер google/cloud-sdk в тот же GCE и выполняя ту же команду, он, похоже, умело настроил наследование учетных данных (возможно, из учетных данных host-vm?). Кажется, что он обошел запуск «gsutil config» при запуске контейнера в GCE для доступа к частным ресурсам.

Я ищу, чтобы воспроизвести это поведение в минимальном контейнере Centos для массового развертывания.

+0

Есть ли у вас вопрос о том, как легко пройти аутентификацию от GCE до GCS или о том, как иметь минимальный контейнер SDK gcloud или что-то еще? Почему вы считаете, что это хорошо для развития, но не для производства? Какие проблемы вы испытываете, когда у вас много таких контейнеров? Кроме того, рассмотрите разделение второй части сообщения на отдельный вопрос. –

+0

Отредактировано для попытки уточнения. – GNN

ответ

2

Последующие меры.

Я закончил использовать каталоги /.config & /.gce и очень минимальный набор компонентов GCE SDK (без JDK/PHP/etc). Самый лучший пример, который я смог найти, оказался wheezy-cloudtools Dockerfile.

4

Обновление: от 15 декабря 2016 года, возможность обновления областей существующей виртуальной машины теперь находится в стадии бета-тестирования; см. this SO answer для более подробной информации.


Старый ответ: Один подход заключается в создании виртуальной машины с appropriate scopes (например, Google Cloud Storage только для чтения или для чтения и записи), а затем все процессы на виртуальной машине, в том числе контейнеров, будут иметь доступ к учетные данные, которые они могут использовать через OAuth 2.0; см. документы для Google Cloud Storage и Google Compute Engine.

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

+0

Спасибо. Это на самом деле то, что я сделал, однако он не работал должным образом из разрешений внутри проекта. Я буду использовать хранилище GS в качестве примера с момента его создания. Контейнерный движок был создан с помощью -scopes https://www.googleapis.com/auth/devstorage.read_write. Затем я развертываю базовый контейнер ubuntu и контейнер google/cloud-sdk. Только контейнер google/cloud-sdk может выполнять «gsutil ls». В контейнере ubuntu вы видите «Вы пытаетесь выполнить операцию, для которой требуется идентификатор проекта, без каких-либо настроек» – GNN

+0

Вы использовали «gcloud config set project PROJECT' для установки проекта по умолчанию или явно задали проект через' gsutil ls - p ПРОЕКТ gs: // bucket'? –

Смежные вопросы