The Problem
I'm dipping my toes into AWS by deploying a simple API built with NestJS. This will be the first app I've deployed to a cloud service. I've already cloned my repository on an AWS Lightsail Linux instance with Node.js and installed all of my dependencies. However, I'm confused on how best to provide environment variables to my app.
Obviously, I has a local .env file that I used during development with credentials for my database, port info, etc. Do I just create a new .env file on the machine running my instance through the command line? I've read that for other AWS services you can provide env variables through that service's UI, but I can't find the same thing for Lightsail.
I would greatly appreciate it if someone could give me an explanation of env variables, and how we should generally provide them to cloud services.
Thank you!
There could be a better method. But, you could add a file locally on the LightSail server itself. If you don't know how to do so through console, I'll explain below.
Create the file: touch .env
Open up the file in console: vim .env.
Now you will see the file opened up in console, with weird UI if you haven't seen it before.
Prepare to write to file: press i.
Now you should see a the ~Insert~ mode appear at the bottom.
Add the variables: copy and paste your .env from your local laptop to your lightsail console.
close out: press esc, then type in :wq, and click on enter
This should work as normal with any .env file. I'm unsure if there are security issues with this, but I don't believe so.
Related
As usual many things to do and no time to do it, so I need some suggestions.
This the scenario. AWS Lambda development based on SAM cli (aws cli/sam cli/docker/IntelliJ with AWS plugin) on Ubuntu 18.04
Developing a lambda function on node.js 12 - Javascript.
Everything is almost working perfectly. I edit the function, run from IntelliJ, docker is executed with the lambda function, logs are happily popping up.
I say almost because I have a problem.
I create a text file in the function and is saved on /tmp/myTextFile.txt
I would like to be able to see the content of this file.
So I was wondering if exists a way to do it accessing the docker image.
I did try to "debug" the function rather than just execute it, putting a breakpoint after generating and saving the file.
I verified that the docker image remains open when the breakpoint is hit.
Then I did try to attach a terminal to the open docker image, no errors but also nothiing happens.
On a terminal I did open a terminal and :
docker container ls
I did see the docker image opened from the the local SAM development
Then :
docker container attach "ID of the opened image"
and .. nothing.
There is a way to login and execute commands like "ls" or "cat" ?
In this way I could see if the file was generated and if is correct.
Thanks for any suggestion !
Steve
We have a Vue app hosted as an Azure App Service. Under Settings\Configuration in Azure Portal We have added application settings like VUE_APP_API_ENDPOINT_URL. These become environment variables like the documentation explains, and can be verified by opening a console from the portal and type 'env'.
I Had hoped that These env variables would now be accessible inside Vue by use of
process.env.VUE_APP_API_ENDPOINT_URL
My guess is that its only becomes available in VUE when aplication is build with WebPack or similar.
At least it doesn't work.
Are there any nice way to read those env variables created from Azure App Settings into the vue app?
Some people mentions dotenv npm package, but we need to read the env variables not add them from a config file.
You would be correct that the Environment Variables only become available when you build the application. And to elaborate on that, only the Environment Variables that you specify/supply at build time are the ones that become available in the application from the build process as per the documentation here:
https://cli.vuejs.org/guide/mode-and-env.html#environment-variables
Specifically look at this:
Note that only NODE_ENV, BASE_URL, and variables that start with VUE_APP_ will be statically embedded into the client bundle with webpack.DefinePlugin. It is to avoid accidentally exposing a private key on the machine that could have the same name.
I was struggling to accomplish essentially the same thing that you're trying to accomplish. I was trying to get a value from Azure's Application Settings so that I could setup multiple environments for my application and not have to constantly change values depending on the environment I published the app to.
After realizing that you might be onto something and reading the confirmation of such in the documentation, I decided to try putting the Environment Variable that I was trying to get from Azure's Application Settings in a .env file with a default so that it would be specified at build time. I then published my app to Azure and tested it and it worked!
Try creating a .env file with all of the Azure Application Settings that you're trying to set with default values or something, like:
VUE_APP_API_ENDPOINT_URL=default_value
And then set those same variables into your Azure Application Settings with the proper values and it should work.
Zoull's comment, while somewhat factual, is not possible. His comment implies that setting VUE_APP_API_ENDPOINT in Azure's Static App Settings blade will seamlessly include that var, and perhaps other VUE_APP_* vars into the vue app.
This is wrong.
Webpack is responsible for inclusion of VUE_APP_* vars into the build, and this is only possible at build-time.
This can be verified by following his logic, and then dumping to console "env" at runtime. Values will be set to, permanently, whatever they were at build-time.
tl;dr: Vue will never read, post-build, vars from Application Settings.
I use Github actions to build and deploy. By adding an env: setting after the with: stanza, and including VUE_APP_* vars there, I can do what OP is trying to do.
I believe I can also set some github "secrets" in githubs settings for my repo, and also include them dynamically in the YAML.
Ex. If I have a github secret key/val of: "VUE_APP_FOO: true", in my github action yml, I can do:
env:
VUE_APP_FOO: ${{secrets.VUE_APP_FOO}}
Then, in my final vue build, I should have a value of "true" when I read the process.env.VUE_APP_FOO var.
Savvy?
I have a node.js application I have adopted from a more senior developer. I want to deploy it, and I know it will work because he already deployed it several times. I am reading these instructions:
https://galaxy-guide.meteor.com/deploy-quickstart.html
I use windows, as did he.
How does deployment work?
Take these instructions:
Windows If you are using Windows, the commands to deploy are slightly
different. You need to set the environment variable first, then run
the deployment command second (the syntax is the same as everything
you’d put for meteor deploy).
In the case of US East, the commands would be:
$ SET DEPLOY_HOSTNAME=galaxy.meteor.com
$ meteor deploy [hostname]
--settings path-to-settings.json
Am I just supposed to go to the source directory on my laptop and run these commands? What then happens? Is the source uploaded to their server from my laptop and then their magic takes care of the rest?
What about when I want to make a change to the code? Do I just do the same thing, poiting to an existing container and, again, they do the magic?
Am I just supposed to go to the source directory on my laptop and run these commands? What then happens? Is the source uploaded to their server from my laptop and then their magic takes care of the rest?
It is not magic. You basically go to your dev root and enter these commands. Under the hood it builds your app for production (including minification and prod flags for optimization) and once complete opens a connection to the aws infrastructure and pushes the build bundle.
See: https://github.com/meteor/meteor/blob/devel/tools/meteor-services/deploy.js
On the server there will be some install and post install scripts that set up all the environment for you and, if there are no errrors in the process, start your app.
These scripts have if course some automation, depending on your account settings and the commands you have entered.
What about when I want to make a change to the code? Do I just do the same thing, poiting to an existing container and, again, they do the magic?
You will have to rebuild (using the given deploy command) again but Galaxy will take care of the rest.
I'm working with node-red, on boilerplate IBM cloud. I know that there is a way, changing the value of enviroments variables(NODE_RED_USERNAME and NODE_RED_PASSWORD), to change username and password of the editor flow. But, what about UI dashboard? I mean using dashboard nodes. Forbid access to
https://noderedservicename.mybluemix.net/ui/
I know that on the code, changing the variable httpNodeAuth on the file settings.js I can do what I want. What is the way for doing that on IBM Cloud?
Thank you in advance!
You need to add the httpNodeAuth (not the httpAdminAuth as this is for controlling access to the Node-RED editor and can done with the environment variables discussed in the other answer.) to the app/bluemix-settings.js file.
Something like this:
...
httpStatic: path.join(__dirname,"public"),
httpNodeAuth: {user:"user",pass:"$2a$08$zZWtXTja0fB1pzD4sHCMyOCMYz2Z6dNbM6tl8sJogENOMcxWV9DN."},
functionGlobalContext: { },
...
Details of how to generate the pass can be found here
There are a number of ways you can edit the file, some of which include linking the Node-RED deployment to a git repository or downloading the whole app, editing the file and pushing it back to Bluemix (when you first deploy Node-RED from the starter pack it gives you instructions on how to download the source to make changes and then push them back. You can get to these instructions by clicking on the "Getting started" link in your Node-RED Bluemix console page).
But the quickest/simplest/dirtiest way is probably to just SSH into the instance and change the file with something like vi. Details on how to ssh to an app instance can be found here. But the following should work:
cf ssh [app name]
Once you have edited the file you will need to tell bluemix to restart the app. You can do this from the web console or with the cf command line tool.
(The changes made by this method will not survive if the app is restaged, or bluemix decides to move your instance to another machine internally because it will rebuild the app from the pushed sources. The permanent solution is to download the source, edit and push back)
This link will help you but it's written in Japanese.
http://dotnsf.blog.jp/archives/1030376575.html
Summary
You can define the "user-defined" environment variables through the IBM Cloud dashboard.
It contains the variables to protect Node-RED GUI.
You have to be set as follows
NODE_RED_USERNAME : username
NODE_RED_PASSWORD : password
I have a Node.js app that I wrote and successfully deployed to a Heroku app via Bash. From my computer running Ubuntu at home it runs fine locally too.
However, I have just cloned the repository to a Windows machine and while I've successfully managed to push updates to the Heroku remote, which work, whenever I run heroku local from Windows and try to access the local version (localhost:5000), that page serves an error and my command line returns TypeError: Request path contains unescaped characters and layer.js:95.5.
The app uses https.get and this seems to be the problem line, locally.
I'm reluctant to try adapting my code since it works fine on Heroku itself and works fine on my Ubuntu machine -- so can only assume that something needs configuring on my Windows machine.
Any idea what the problem might be?
tl;dr
Be careful which variable keys you choose for config/.env in Heroku. Windows has some reserved keys (like user and path) which will mean trying to set your own values against these keys will not work.
The detail
It turns out the issue is with my choice of variable names as used in my .env file.
When you have data that you don't want to commit to a repository (in my case, an authentication key and details for my account) you can add them to Heroku as "config vars" -- key=value pairs which Heroku keeps separate to your code so you can version and share your repository as needed and others can add their own details.
When running Heroku locally however using the heroku local command from the toolbelt, these variables need to come from somewhere else. Heroku's help recommends setting them up as key=value pairs in a file called .env (which you can then add to .gitignore to prevent accidental committing.
Unfortunately, in my case it was my choice of variable keys in .env that caused the problem. I had created dependencies on variables called user and path but these seem to be reserved on Windows and have a special purpose and therefore could not be overwritten by what was in my .env file. This is why what worked for me on my Ubuntu machine would not work directly on Windows.
You can see this in action by calling console.log(process.env.user, process.env.path) from Node on a Windows machine.
Now that I have changed the variable names to something non-reserved heroku local works fine. Calling the programme via node command will still not work as it is not set up to pick up the variables from .env as Heroku.
Hope this helps someone else.