Google Cloud Run и JSON в переменных ENV - PullRequest
Новая
       64

Google Cloud Run и JSON в переменных ENV

0 голосов
/ 19 января 2020

Я развернул небольшое приложение Node.js, которое использует config. NODE_CONFIG читается и используется для замены любой локальной конфигурации. Это удобно при развертывании службы с секретами, поскольку конфигурация может быть введена извне.

При попытке достичь этого с помощью Google Cloud Run и CLI, я получаю ошибку escape. Очевидно, CLI поддерживает только словари.

Есть ли лучший способ передать JSON содержимое через переменные env? 

gcloud run deploy pr-$PULL_REQUEST \
  --platform=managed \
  --revision-suffix=$revision \
  --region us-central1 \
  --set-env-vars="NODE_ENV=development,NODE_CONFIG='$json'" \
  --allow-unauthenticated \
  --image gcr.io/...

Ответы [ 2 ]

2 голосов
/ 21 января 2020

Если у вас несколько переменных среды и вы настаиваете на перечислении переменных среды в CLI gcloud (вместо записи объекта Service в YAML + с использованием gcloud alpha run services replace), вы можете просто повторить --set-env-vars: 

gcloud run deploy \
  --set-env-vars="A=B" \
  --set-env-vars="C=D" \
  --image=gcr.io/cloudrun/hello

Здесь вы можете просто сделать "KEY=$value" с включенными в него кавычками.

Цитирование значения 1) предотвращает разбиение аргумента в случае, если $value содержит пробелы, и 2) экранирует кавычки внутри $value, что у вас будет, потому что у вас есть значение json.

Пример 

json='{"hello":"world"}'

gcloud run deploy foo \
  --set-env-vars="A=$json" \
  --set-env-vars="C=D" \
  --image=gcr.io/cloudrun/hello

gcloud run services describe [...] вывод: 

  Env vars:
    A                {"hello":"world"}
    C                D
0 голосов
/ 19 января 2020

Действительно, это не работает с CLI. Когда вы устанавливаете запятую между 2 значениями, она не работает.

Вы можете использовать решение @Kolban, где вы создаете файл в GCS и можете ссылаться только на этот файл в EnvVar. Но это решение подразумевает обновление вашего кода для получения и чтения файла из облачного хранилища (больше роли, больше развертывания для выполнения). Но он работает, я использую этот режим для передачи SQL запросов в мои сервисы Cloud Run, до сих пор это было единственное решение!

Однако есть новое бета-решение, доступное через 2 недели: вы можно использовать функцию services replace . Эта функция позволяет вам предоставить только файл yaml для описания вашего сервиса. Конечно, этот YAML совместим с родственным API, и, следовательно, стандарт.

Я тестировал с JSON, и он работает, но это подразумевает некоторые изменения в процессе развертывания (создайте файл YAML с изображением и env vars). Сначала создайте минимальный файл YAML (с именем, например: jsonenv.yaml) 

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  #Name of the service
  name: jsonenv
spec:
  template:
    spec:
      containers:
      - env:
        - name: NODE_CONFIG
          value: '{"1":"2","3":"4"}'
        image: gcr.io/PROJECT_ID/CONTAINER_NAME

Затем используйте эту команду 

gcloud beta run services replace jsonenv.yaml --platform managed --region WHERE_YOU_WANT

Это работает. Надеюсь, что это решит вашу проблему.

РЕДАКТИРОВАТЬ

Для наименования вашей ревизии, вы можете добавить metadata.name в template следующим образом: 

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  #Name of the service
  name: jsonenv 
spec:
  template:
    metadata:
      #Name of the revision
      name: my-revision-name
    spec:
      containers:

однако, вы не можете управлять ролью IAM с помощью этой команды. Таким образом, --allow-unauthenticated нельзя использовать с заменой. Вы должны установить эту авторизацию вручную 

gcloud run services add-iam-policy-binding jsonenv \
    --member="allUsers" \
    --role="roles/run.invoker"

Примечание : это необходимо сделать только один раз при первом развертывании службы, а не при каждом развертывании ревизии

...