0

Recently I was deployed a EKS cluster and connect it with our Gitlab.com group, I already deployed some examples and templates from Gitlab and all works fine.

Now I’ll want to deploy my Node.js based app. I set STAGING_ENABLED because I’m interest on have a pod for staging and another for production. I’m using dotenv to set some environment variables with some secrets and hosts for some services that my app is using.

My question is: I have two dotenv files one for staging and another for production. Which is the better way to pass/copy this files into my build/deployment process?

My .gitlab-ci.yml is so simple like this:

variables:
  PRODUCTION_REPLICAS: 2
  STAGING_ENABLED: 1

include:
  - template: Auto-DevOps.gitlab-ci.yml
Rodrigo Moreno
  • 243
  • 1
  • 2
  • 11

1 Answers1

0

There are multiply ways to do this. If your're not using Gitlab Auto Devops you could use kubectl or helm to use the variables. I would recommend you to use Helm because it has a lot of features that can benefit your situation.

You could create a Gitlab CI variable with the type File (https://docs.gitlab.com/ee/ci/variables/#custom-environment-variables-of-type-file) which saves the dotenv files for staging and production.

With the use of a Helm chart you could save all the dotenv values in a values.yaml format (https://helm.sh/docs/chart_template_guide/values_files/). This file can have all kind of settings like replica's etc.

Then in your Gitlab-CI you can do helm upgrade <name> <chart> -f $staging.yaml for staging and helm upgrade <name> <chart> -f production.yaml for production. The *.yaml files are then just saved in the Gitlab CI variables with the type files so that you can edit the files and do upgrades.

Zawadi
  • 11
  • 2