3
votes

Google App Engine: modifier l'environnement Cloud Run

J'essaye de déployer une application Next.js qui utilise un serveur Node.js personnalisé.

Je souhaite injecter des variables de construction personnalisées dans l'application:

next.config.js

env_variables:
  DOGE_ENV: production

Le fichier ci-dessus est exécuté au moment de la construction ( construction du fil ).

Le problème est que Google App Engine utilise Cloud Build en arrière-plan. Là, le NODE_ENV est toujours défini sur development . Comment puis-je remplacer le NODE_ENV ici; c'est-à-dire comment puis-je personnaliser le Cloud Build utilisé pour le gcloud app deploy de Google App Engine?

Je ne peux pas simplement utiliser Docker à cause de ce problème .

package.json

runtime: nodejs10

app.yaml

{
  "name": "blah",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "dev": "NODE_ENV=staging node server.js",
    "build": "rm -rf node_modules/ && yarn && rm -rf .next/ && next build",
    "start": "node server.js",
    "lint": "eslint . --ext .js",
    "gcp-build": "yarn build"
  },
  "dependencies": {
    "body-parser": "^1.18.3",
    "dotenv": "^7.0.0",
    "dotenv-webpack": "^1.7.0",
    "express": "^4.16.4",
    "express-session": "^1.16.1",
    "firebase": "^5.10.0",
    "firebase-admin": "^7.3.0",
    "isomorphic-unfetch": "^3.0.0",
    "lodash": "^4.17.11",
    "next": "^8.1.0",
    "now": "^15.0.6",
    "react": "^16.8.6",
    "react-dom": "^16.8.6",
    "session-file-store": "^1.2.0",
    "styled-components": "^4.2.0",
    "yenv": "^2.1.0"
  },
  "devDependencies": {
    "babel-eslint": "^10.0.1",
    "eslint": "^5.16.0",
    "eslint-config-airbnb": "^17.1.0",
    "eslint-plugin-import": "^2.17.2",
    "eslint-plugin-jsx-a11y": "^6.2.1",
    "eslint-plugin-react": "^7.12.4"
  },
  "engines": {
    "node": "10.x.x"
  }
}

image

Vous trouverez ci-dessous la sortie de la transmission d'une variable DOGE_ENV depuis app.yaml . Comme vous pouvez le voir, il est indéfini . Cependant, NODE_ENV est un développement .

Autrement dit, l'ajout de ce qui suit à app.yaml ne fonctionne pas.

const NODE_ENV = process.env.NODE_ENV;
const envType = NODE_ENV === `production` ? `production` : `staging`;

const envPath = `./config/${envType}`;
const { env } = require(envPath);

module.exports = {
  env: { ...env },
};

 entrez la description de l'image ici


2 commentaires

Utilisez-vous Google Cloud Build pour compiler vos ressources de fil avant que votre application ne s'exécute dans Cloud Run / AppEngine? Ou s'agit-il d'un processus en cours d'exécution qui est généré dans l'instance Cloud Run / AppEngine en cours d'exécution?


Cloud build exécute yarn build qui construit l'application qui est servie par node server.js . Je n'utilise pas directement Cloud Build, mais tous les gcloud app deploy sont associés à un Cloud Build utilisant le runtime déclaré dans app.yaml (dans ce cas, runtime: nodejs10 ).


3 Réponses :


0
votes

N'utilisez pas NODE_ENV, créez votre propre variable d'environnement et utilisez-la:

App.yaml

const environment = process.env.ST_ENV;
const envType = environment === `production` ? `production` : `staging`;

const envPath = `./config/${envType}`;
const { env } = require(envPath);

module.exports = {
  env: { ...env },
};

suivant .config.js

env_variables:
  ST_ENV: Production


2 commentaires

Merci pour la réponse, mais cela ne fonctionne pas, car l'environnement Cloud Build est l'environnement de compilation et les env_variables spécifiées dans app.yaml sont des variables d'exécution. Ainsi, process.env.ST_ENV sera indéfini lorsque next.config.js s'exécutera réellement.


J'ai ajouté une image de la sortie Cloud Build qui illustre ce problème.



0
votes

J'ai eu le même problème, à la fin j'ai résolu le paramètre NODE_ENV = production dans le script package.json, donc dans votre cas, utilisez simplement:

{
  "gcp-build": "NODE_ENV=production yarn build"
}

sinon vous pouvez créer un fichier de configuration Cloud Build, vérifiez le docs , il prend en charge une section env dans laquelle vous pouvez définir des variables d'environnement


0 commentaires

0
votes

J'ai eu le même problème et j'ai fini par utiliser une approche similaire à la réponse de Luca , mais avec un mécanisme pour remplacer le corriger la variable dans package.json avant le déploiement (à l'aide de microsoft / variable-substitution action GitHub dans mon cas).


0 commentaires