Назад | Перейти на главную страницу

Я неправильно выполняю развертывание Google Cloud?

Раньше я использовал Heroku и AWS, а теперь настраиваю сервис на платформе Google Cloud, используя App Engine и Cloud SQL (Postgres).

Мы попытались создать приложение, используя 12-факторные принципы.

Настройка оказалась настолько утомительной, что я начинаю сомневаться, не упустил ли я что-то принципиально.

Вот что меня смутило:

Поощряется к написать пароли в файл, который попадает в систему управления версиями (app.yaml).
Требуется взломать обходной путь для загрузки переменных среды (если я не хочу, чтобы они передавались в систему контроля версий).
Обнаружив, что для подключения к экземпляру облачного sql мне нужна строка, относящаяся к конкретному экземпляру в app.yaml - так теперь мне нужны app.staging.yaml и app.production.yaml?
Обнаружение этой строки, похоже, поддерживает только 1 экземпляр БД и неясно, есть ли поддержка, если мы хотим, чтобы приложение подключалось к 2 БД.

Пропустил ли я некоторые важные изменения в администрировании серверов, где они стали лучшими практиками? Только что обнаружив №3 и №4, я действительно начинаю думать, что, должно быть, сделал что-то в корне неправильное в своей настройке. Есть я?

Я специально не пытался настроить приложение так, как вы описываете, но я знаю, что это не то, что намеревается сделать Google. Чтобы уточнить некоторые особенности:

Подключение к Cloud SQL В частности, говорится, что следующее, что хранение паролей не является тем, что они предназначены, и предоставляет отдельное решение для секретов.
```
# Remember - storing secrets in plaintext is potentially unsafe. Consider using
# something like https://cloud.google.com/secret-manager/docs/overview to help keep
# secrets secret.
```

Основываясь на этой статье, движок приложений Google не поддерживает переменные среды в app.yaml (Комментарии к аналогичным проблемам с Google App Engine). Мое решение аналогичной проблемы заключалось в следующем коде:

#!/bin/bash
# deploy-helper.sh

prepare_yaml() {
    [ -z "$1" ] && echo "ERROR: template.yaml filename must be provided." && exit 1

    template="${1}"         # ARG #1 : filename of template yaml
    finalYAML=$(mktemp)     # make temporary file

    generated_stdin_cmds="$(echo "cat <<EOF >\"$finalYAML\""; cat $template; echo EOF;)"
    source /dev/stdin <<< "$generated_stdin_cmds"
    echo "$finalYAML";      # return filepath of filled-in file
    return 0
}

# Set environment variables 
TYPE="prod"                     # in script file
source env/production.vars      # read them in from a file

DEPLOYMENT_FILE="app.flexible.yaml"
tmpfile="$(prepare_yaml "app.tpl.yaml")"
if [ $? -eq 0 ]; then
    mv "$tmpfile" "$PWD/$DEPLOYMENT_FILE"   # gcloud wants specific filename
    gcloud app deploy "$DEPLOYMENT_FILE"
    rm "$DEPLOYMENT_FILE"                   # Cleanup temporary file
fi

ПРИМЕЧАНИЕ. Этот сценарий также можно написать на python с помощью библиотеки подпроцесса. Вот как я автоматизировал сборку своего проекта GKE.

Затем возьмите файл приложения app.yaml и добавьте замену строки переменной bash, как в этом примере app-tpl.f flexible.yaml:

# example app-tpl.flexible.yaml
---
runtime: custom
env: flex
env_variables:
  MYSQL_SOCK: "/cloudsql/${project}:${region}:${instance}"
  MYSQL_DB: "${db_name}"
  MYSQL_USER: "${db_user}"
  MYSQL_PASSWORD: "${db_pw}"

Сделать файл, содержащий необходимые переменные (игнорируются в системе управления версиями)

#!/bin/bash
# FILE: env/production.vars

project="project-name"
region="europe-west1"
instance="prod001"
db_name="db001"
db_user="root"
db_pw="qwerty"

Это должно быть решено ответом №2. Добавьте в скрипт флаг / параметр для выполнения для замены экземпляра SQL или измените имя переменной среды.
Похоже, вам нужно будет настроить два экземпляра подключения CloudSQL, и тогда автоматический прокси CloudSQL сможет подключиться к 2 базам данных. Видеть cloud.google.com/sql/docs/mysql/connect-app-engine-f flexible и это ответ так как они заставили его работать с разными номерами портов.

Удачи!