I've created a Node v12 (5.2.2 platform) elastic beanstalk app, and set the env vars in the EB console.
Locally, I use dotenv to load envs, but EB does it their own way. The env variables are recognized when I view the elastic beanstalk server logs, but when I ssh into the EC2 instance, and console.log(process.env), or echo $MY_ENV_VAR, none of the values are set.
So, I source'd the env vars at /opt/elasticbeanstalk/deployment/env and can now echo them, but running migrations shows that the env vars are still unset, and console.log(process.env) shows none of them are set.
Why is this? How do I ensure they're set so I can run migrations and other commands that require envs?
/root/.ebextensions/environmentvar.config:
option_settings:
aws:elasticbeanstalk:application:environment:
TEST_VAR: helloworld
Related
I have two different projects checked in Gitlab, frontend and backend.
For both the projects i have a Dockerfile each.
I have set the env variables in gitlab ci/cd .
I am running docker container in kubernetes,
but i am not able to access the gitlab env variables either in my react or node.js (express) application.
I was thinking that those env variable would be available to me when i do process.env.variable_name, but i am not able to access them.
What’s the best way to access Gitlab env variables in kubernetes (deployment.yaml) env variables ?
UPDATE
I have found that we can specify env variables in kubernetes, deployment.yaml file (under env section). How can i pass gitlab env variables to deployment.yaml?
Docker containers require that you set environment variables when you run them:
https://docs.docker.com/engine/reference/commandline/run/#set-environment-variables--e---env---env-file
--env , -e Set environment variables
I was able to access environment variable in Node js application using Gitlab K8S_SECRET_ variable naming convention.
For example define a variable like K8S_SECRET_MY_TEST_API in gitlab.
In Node js, you can access this variable using process.env.MY_TEST_API.
Only issue I am facing is that those variables are not available in React app. Still trying to figure that out. I will update here once I resolve that issue.
To inject environment variables to a react app created with create-react-app you should add the prefix REACT_APP_ to every env var.
During the build, webpack will pick all the environment variables with that prefix and will add them to environment.
I'm trying to run some commands on my NodeJS app that need to be run via SSH (Sequelize seeding for instance), however when I do so, I noticed that the expected env vars were missing.
If I run eb printenv on my local machine I see the expected environment variables that were set in my EB Dashboard
If I SSH in, and run printenv, all of those variables I expect are missing.
So what happens, is when I run my seeds, I get an error:
node_modules/.bin/sequelize db:seed:all
ERROR: connect ECONNREFUSED 127.0.0.1:3306
I noticed that the port was wrong, it should be 5432. I checked to see if my environment variables were set with printenv and they are not there. This leads me to suspect that the proper env variables are not loaded in my ssh session, and NodeJS is falling back to the default values I provided in my config.
I found some solutions online, like running the following to load the env variables:
/opt/python/current/env
But the python directory doesn't exist. All that's inside /opt/ is elasticbeanstalk and aws directories.
I had some success so I could at least see that the env variables exist somewhere on the server by running the following:
sudo /opt/elasticbeanstalk/bin/get-config environment --output YAML
But simply running this command does not fix the problem. All it does is output the expected env variables to the screen. That's something! At least I know they are definitely there! But the env variables are still not there when I run printenv
So how do I fix this problem? Sequelize and NodeJS are clearly not seeing the env variables either, and it's trying to use the fallback default values that are set in my config file.
I know my answer is late, but I had the same problem and after some attempts with bash script I found a way to store it in your env vars.
you can simply run the following command:
export env=`/opt/elasticbeanstalk/bin/get-config environment -k <your-variable-name>`
now you will be able to easily access this variable:
echo $your-variable-name
afterward, you can utilize the env var to do what ever you like. in my case, I use it to decide which version of my code to build in a file called build-script.sh and its content is as follows:
# get env variable to know in which environment this code is running in
export env=`/opt/elasticbeanstalk/bin/get-config environment -k environment`
# building the code based on the current environment
if [ $env = "production" ]
then
echo "building for production"
npm --prefix /var/app/current run build-prod
else
echo "building for non production"
npm --prefix /var/app/current run build-prod
fi
hope this helps anyone facing the same issue 🤟🏻
mine is a react app (not build from creat react app) we use env file for different environments variables(use Dotenv web pack ) from npm . We are deploying this app to docker container in kubernetes. Looking for a way that env vars can be managed from kubernetes side than from .env file . While running In localhost (not in docker ) it should work also when deploying should take from kubernetes.any suggestion
You can use configmap and secrets in kubernetes to manage the environment variables. while both are default in kubernetes so no need of extra installation.
there are many other option you can also use the hashicorp vault for more secure varible store.
If environment variables will used inside kubernetes you can use configmap & secrets
If you want to transfer variable outside kubernetes better setup vault for more security purpose.
if you want to set the environment variables in docker file include you can do it like
...
RUN npm run build
ENV File_location=/app/.env
ENV DB_PORT=9090
WORKDIR /
RUN npm install express
...
This environment variable you can use and import to code.
I have a Cloud9 environment spun up and have modified my ~/.bash_profile to export a value at the end of the file.
export foo="hello world"
I run . ~/.bash_profile and then echo $foo and I see hello world output in the terminal.
I then created a NodeJS Lambda with API Gateway. I run the API Gateway locally in Cloud 9 and attempt to read the environment variables
console.log(process.env)
I see a list of variables available to me that AWS has defined. My export is not listed there however. Since I will be using environment variables when my Lambda is deployed, I want to test it with environment variables defined in the Cloud9 environment.
Is there something specific I have to do in order to get the Lambda to read my .bash_profile exports?
AWS Cloud9's Lambda plugin is backed by SAM Local, which uses Docker: https://github.com/awslabs/aws-sam-cli . By default, this means that the ~/.bash_profile file is not used by Lambda; you'll want to load this in manually.
Please see Using the AWS Serverless Application Model (AWS SAM) article that describes how to work with environment variables in SAM (so also in cloud9).
In summary - put environment variables into the template.yaml file (present in the root folder of your app) like below:
Properties:
.... # tons of other properties here, add yours at the end
Environment:
Variables:
MY_ENV_VARIABLE: 'This is my awesome env variable value'
setting environmental variables for a Hubot is pretty easy on the production server. However when I want to test the bot locally, I need the env vars inside a file. I already have the file .env for env vars that heroku is using for running locally.
But I can't seem to find a way to load env vars inside the Hubot scripts from a file.
Merry Christmas :-)
okay it's possible with hubot-env.
https://www.npmjs.com/package/hubot-env
The following command will load the file from a relative path:
hubot env load --filename=[filename].
It previously didn't work for me because I had HUBOT_ENV_BASE_PATH set on my mac so the command searched in the wrong folder for the file.