I can't go into details unfortunately, but I'll try to be as thorough as possible. My company is using AWS Beanstalk to deploy one of our node services. We have an environment property through the AWS configuration dashborad, the key ENV_NAME pointing to the value in this case one of our domains.
According to the documentation, and another resource I found once you plug your variables in you should be able to access it through process.env.ENV_NAME. However, nothing is coming out. The names are correct, and even process.env is logging out an empty Object.
The documentation seems straight forward enough, and the other guide as well. Is anyone aware of any extra steps between setting the key value pair in the dashboard, and console logging out the value once the application is running in the browser?
Turns out I'm an idiot. We were referencing the environment variable in the JavaScript that was being sent to the client. So, we were never looking for the env variable until after it was off the server. We've added a new route to fetch this in response.
Related
So I'm using cPanel with Setup Node.js App plugin for an node/express app. (don't asky why cPanel)
Everything is working as expected in development, except for environment variables in production, I set up them manually from the cPanel interface, I restarted/stopped the app, logging the process.env on the server and I don't see the env variables there (not to say when trying to call them they are undefined).
When doing res.json(JSON.stringify(process.env)); i get a bunch of variables except for the one I manually wrote in cPanel variables interface.
It is important for me to store these variables as a secret key because they are API credentials.
Does anyone know what I might have misconfigured or had this problem?
Is there a way with the AWS CLI to tell that you are running your lambda locally programmatically? I'm trying to avoid adding extra data in the request.
I have some functionality that I don't want kicked off when I'm running locally, but I do once its up in the AWS cloud.
Thanks
A first option is to use one of the environment variables that are available when a Lambda function is executed. The AWS_EXECUTION_ENV - like you stated in your comment - can be a good pick for this.
A second option is using the context object which is passed in as a second parameter to your handler function. This contains very specific information about the request, such as the awsRequestId which could also help you in determining whether or not your code is running on the cloud or locally.
Im asking this question because I spent a long time trawling google trying to find an answer to it and finally stumbled upon a single line in an AWS doc that pointed me to the correct answer, but it is not obvious, so hope this helps someone save some time.
Problem:
I am trying to call AWS services via the AWS SDK in my NodeJS Express app, but the SDK is not loading the profile and key details I have in my ~/.aws/credentials and ~/.aws/config files. When I try and log the credentials object it is empty. I am trying to use a profile which I have set using the AWS_PROFILE environment variable, set in a .env file. Looking at the AWS docs the SDK should look in these files under ~/.aws, but it doesnt seem to be doing this.
So the answer lies in a single line in one of the AWS docs: http://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/getting-started-nodejs.html
Similarly, if you have set your region correctly in your config file, you can display that value by setting the AWS_SDK_LOAD_CONFIG environment variable to a truthy value
Adding AWS_SDK_LOAD_CONFIG=true to my .env file caused the SDK to start using the credentials stored in the ~/.aws/config and ~/.aws/credentials files.
I dont know why the docs dont make it more explicit that you need to do this (that page suggests you only need to set this to get the region to pass), everything I read suggested that these files would be checked by the SDK regardless.
Hopefully this helps save someone else a lot of frustration and Googling!
I configured a stack for a NodeJS application server using Amazon OpsWorks.
I need to access some environment variables which define Google API credentials. How can I achieve this ? I already spent more two days on this.
I ended up by the following chef recipe :
magic_shell_environment "GOOGLE_CLIENT_ID" do
owner 'root'
group 'root'
value "********"
mode '0600'
end
I use the root account because it seems the NodeJS is run under that account. If I remove the owner and group attributes, I can read those environment variables fine (as the default ubuntu user). However, when I ssh to my instance and type echo $GOOGLE_CLIENT_ID as root, I get an empty string.
Also, where is logged the output of console.xxxx(...) ?
OpsWorks now lets you specify up to 20 custom environment variables in the app settings page. In the case of a node.js app these will be available in the process.env object.
This should be fairly easy to do. Just add the following line to the top of your recipe.
ENV['GOOGLE_CLIENT_ID']="YOUR_CLIENT_ID"
Use the OpsWorksEnvy cookbook. It hooks nicely into the default nodejs cookbooks and lets you set the environment variables in your stack attributes.
I have to configure one of the module in my application and give it a specific URL, based on the hostname. Something like http://localhost locally and http://myapp.herokuapp.com. I know I can just hardcode the value depending on NODE_ENV, or even store it as an environment value and use process.env.CUSTOMVAR_HOSTNAME. But somehow it feels wrong, since myapp is already configured in the Heroku admin panel. And I can't use request.headers.host since the module configuration happens at the start of the application, before any request can be handled.
Is there a way to retrieve the Heroku application name from the code ? Or from an environment variable ? I want my code to stay the same whether I'm executing code locally or on Heroku (or any other place actually).
I didn't find any way, so I created a local variable hostname based on NODE_ENV (development or production) with the proper hostname value.