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'
Related
Currently I'm trying to breakdown my serverless service into multiple services to get over the cloudFormation resource limit.
My current project structure is as follows:
aws-backend
functions
workers
serverless.yml // workers service
.env.local
.env.dev
serverless.yml // Rest of the functions in here
In my workers service, I'm trying to reference the .env.* files in the root folder using variables.
My issue is when i use the following syntax
${env:SLS_AWS_REGION}
I get a
Error:Cannot resolve serverless.yml: Variables resolution errored with:
- Cannot resolve variable at "provider.region": Value not found at "env" source
but when I use the following syntax:
${../../env:SLS_AWS_REGION}
It works but I get a warning:
Warning: Invalid configuration encountered
at 'package.individually': must be boolean
at 'provider.region': must be equal to one of the allowed values [use-east-1, etc...]
How can I get rid of this error? Am I even using the correct syntax?
Thanks
as for this error
Error:Cannot resolve serverless.yml: Variables resolution errored with:
- Cannot resolve variable at "provider.region": Value not found at "env" source
You get this error because the Framework cannot find SLS_AWS_REGION environment variable. The env variable source doesn't read from .env files, but from environment variables from the process.
As for this syntax:
${../../env:SLS_AWS_REGION}
This does not work because env is a correct variable source, not ../../env.
You have two options here:
Ensure that content of the .env file(s) is exported so the variables defined in these files are actually exported as environment variables before running serverless commands.
Set useDotenv: true in your serverless.yml file so the .env files will be loaded automatically with dotenv. Please see the docs for reference on how it works: https://www.serverless.com/framework/docs/environment-variables
According to the plugin documentation, you should run sls deploy with --stage or --env (deprecated in Serverless >=3.0.0) or NODE_ENV corresponding to the .env file name. If you run it without any of those flags, it will default to development, and the plugin will look for the plugin will look for files named .env, .env.development, .env.development.local
Note that Serverless Framework .env files resolution works differently to the plugin.
The framework looks for .env and .env.{stage} files in service directory and then tries to load them using dotenv. If .env.{stage} is found, .env will not be loaded. If stage is not explicitly defined, it defaults to dev.
I believe the plugin takes precedence here.
I'm trying to set environment variables from inside a Lambda wrapper script contained in a Lambda layer (I can do this more directly elsewhere, but I'm trying to set them from a wrapper script for specific scenarios).
Here's the important parts of the wrapper script:
set -euo pipefail
OWN_FILENAME="$(basename $0)"
tempFile=$(mktemp /tmp/${OWN_FILENAME}.XXXXXXXX)
echo "export ONE=\"two\"" >> ${tempFile}
. ${tempFile}
Here, I'm creating a temporary file which contains an environment variable exported to the environment. Then I source the file.
I would expect this to create a variable called ONE on process.env, which is set to "two".
If I were to run this script and then run a Node script that contains:
console.log(process.env.ONE);
It would print "two".
However, this appears to not work with a NodeJS Lambda. I can see that, if I add logs to the wrapper script, the logs will print prior to the Lambda handler running, so it appears the wrapper script is definitely executing prior to the handler.
AWS has a blog post here that shows the above process for setting environment variables. See the section "Conversion to environmental variables".
Is there something I'm not doing to make this work for a Lambda handler?
I have created a .env file in my local system while developing a project. If I upload my project along with .env file, will it work fine or do i have to assign env variables separately?
According to the documentation it won't work like that.
You can set them in Console or provide with --set-env-vars flags during deployment from command line or set id Dockerfile with ENV parameter.
All I've done is initialize a template Azure Functions project in VS and when I try to set run configuration environment variables via launch.json, VS directly warns me that it's not "allowed".
Furthermore, even when I try to run my .ps1 with env anyway, it doesn't work because I have something like
$variable = $env:AWS_REGION
Write-Host $variable
and the terminal output is blank, so clearly it's not working.
It's not possible directly atm see Issue 1472
I can however see that you are trying to start local version of azure functions, so you could declare your environment variables in local.settings.json or in profile.ps1
Edit: This just means its avalible while running the local instance of az functions, and not avalible in the integrated powershell console. the local.settings.json is also the local version of app configuration in azure and you should makre sure to include this file in your gitignore, if you are using git.
Under Ubuntu environment, NodeJS Google Vision complains:
Error: Unable to detect a Project Id in the current environment.
Even though I already put json credential through
$ export GOOGLE_APPLICATION_CREDENTIALS=/var/credential_google.json"
Please help.
As a quick hack you can try this :
$ GOOGLE_APPLICATION_CREDENTIALS="/var/credential_google.json" node app.js
It's not recommended to use a .json config file locally. I've seen these leak on production servers causing whole platforms to be deleted + the introduce environmental switching and security issues.
Setup Google Cloud CLI.
Now the server will 'look' at the local environment and use that.
If you get the error "Unable to detect a Project Id in the current environment.", it means the auth library cannot find the project default id.
You need to have a base project in Google Cloud set, regardless of environmental variables and project you're running.
Run
gcloud config set project [some-project-id]
Now if you run (node example)
"dev": "NODE_ENV=dev GCP_PROJECT=some-project-id nodemon index.ts",
It will load the project environment. This also allows you to deploy easier with:
"deploy:dev": "y | gcloud app deploy --project some-dev-project app.yaml",
"deploy:prod": "y | gcloud app deploy --project some-prod-project app.yaml"
App engine has security setup automatically with standard environments. With flex you can use one of the manage images Google Provides.
If you are usually a windows user and trying out Ubuntu (like me), the problem is likely with the assumptions that the export command exports variable to all terminal sessions and that you need to open a new terminal to get it to use (as expected in a windows terminal for an environment variable).
The export command doesn't export the variable to another terminal session. So if you export it in a terminal, you use it on the same terminal.
If you would like to export it permanently, then you can try the solution listed here
You can put the path to the JSON credentials directly when instantiating the client, by passing it as an argument.
For example:
const client = new speech.SpeechClient( {keyFilename: "credential_google.json"});
Also, for me setting it in the terminal didn't work.