I'm building a web app with Yesod and am currently passing in secrets such as API keys via environment variables (as per The Twelve-Factor App) to avoid storing these values in version-controlled configuration files. For example, I run my app in dev mode as follows:
SOME_API_KEY=value yesod devel
I have a value in my config/settings.yml file that is defined in terms of this environment variable with an empty value as follows:
meetup-api-key: "_env:SOME_API_KEY:"
To deploy using Keter, I'm building the Keter package using the yesod keter command and dropping the resulting file into Keter 'sincoming directory. Since I'm using environment variable configuration, my app's .keter file does not contain the SOME_API_KEY value (which is intentional).
How should I pass SOME_API_KEY into the instance of my app running inside Keter?
I would like to avoid baking the value into my keter-config.yaml for at least the following three reasons:
It is less secure than the environment variable approach.
Being embedded directly into the configuration file for Keter itself, as opposed to the configuration to the app, the secret cannot be changed without stopping and restarting the entire Keter process.
The environment variables are passed into every app being managed by Keter.
I am hoping that there are some "best practices" out there for this scenario.
Set your secrets as environment variables on your server and ‘forward’ them to your app using forward-env in config/keter.yml as seen in the following patch: https://github.com/snoyberg/keter/commit/9e9fca314fb78860fb5c9b08cad212d92b0b20d4
Related
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 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.
How to control which _settings.py or config/.py is loaded when starting py.test? I have some defaults set in init.py and some values in development.py. I have tried to load test values from conftest.py but conftest gets executed after the other 2 are loaded. I am specifically looking to change the db being used in development, test and production modes. How to achieve this?
What you are looking for is configuration management in flask. Take a look at this document: flask config management
This SO question could help you too: enter link description here
Basically, depending on your environment (devel / production / test) you change parameter specifying with which settings your app should start. Using system environment variables is one of the option.
app = Flask(__name__)
app.config.from_envvar('YOURAPPLICATION_SETTINGS')
Then, on your devel machine, just set env variable
export YOURAPPLICATION_SETTINGS="/path/to/settings.conf"
and run the application.
On production environment, do the same thing, just change value to /path/to/production/settings.conf
Keter has been awesome so far. For my little toy project, I used to create the keter bundle on the production server and push it keter's incoming directory and everything worked fine.
Now I wanted to learn how to setup a staging environment and so I tried compiling my bundle on staging server (it is an image copy of the production server). When I push this bundle to my production server (via scp), it logs out signed-in users. The app itself is fine after logging back in.
What has changed:
Some templating code has changed but nothing drastic and such changes were fine when compiled on the production server before
Yesod's settings.yml changed to use the staging server's IP address for development testing
Keter.yaml was not modified.
What am I doing wrong? Why does Keter care where my .keter bundle was created? Is there a way to create these bundles without disrupting signed-in users?
Thanks!
Most likely, the issue is that a new client_session_key file is being created each time your app is being deployed. Instead, you need to generate a key file once and reuse it. This is generally handled correctly by the Yesod scaffolded site, but providing an implementation of makeSessionBackend that stores the key file in config.
What is your current implementation of makeSessionBackend? And do your keter bundles include a file config/client_session_key.aes?
I'm coming to the beta deployment phase of building a Node.js application running through iisnode on Windows Azure. Having set up multiple instances, as well as production/staging separation, my research has led me to the following conclusion:
If I want to change configuration settings on the fly without redeploying code, I need to use Service Configuration .cscfg files.
My problem is that I've stored various configuration settings in the <appSettings> and <iisnode> elements of web.config that I might want to change, which are currently exposed in my Node application via the process global object.
I've looked around MSDN, Node documentation and SO (the usual), and can't find if Node does or can expose Service Configuration settings in the same way. If not, is there a way I can expose them to my application?
Edit: To be more specific, I'm really only looking to move the node_env setting from web.config to Service Configuration, since I'd like to be able to switch from staging to production setup with just a config change. The reason - we're using IP switching to swap between staging and prod, and there are some very minor differences between the two (the URL of the RESTful web service it consumes, for example).
I also know I can configure node_env in an iisnode.yaml file read by iisnode, but that will still recycle the application, and I don't want to modify x yaml files and redeploy, where x is the number of instances of the production/staging application.
You can access the configuration settings via the Azure SDK for Node.js.
To install:
npm install azure
To get the configuration settings:
var azure = require('azure');
azure.RoleEnvironment.getConfigurationSettings(function(error, settings) {
if (!error) {
// You can get the value of setting "setting1" via settings['setting1']
}
});
These settings seem to be held in an XML file located in c:\Config\ folder of the Azure machine.
I'm certain that you're not supposed to access these directly, but you could easily parse this XML and read the settings when node starts.