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?
Related
We have set up Application Insights for our Dev & Prod environments, not with the SDK but through the Portal. We're now in the process of installing the SDK so we can have more control over customizing logging, what to measure in performance, etc.
I have found how to separate the environments in code (separate Instrumentation Key in different config files etc), but I have found nothing when it comes to my local environment. Which instrumentation key should I use there, the dev one? Wouldn't then this skew our dev metrics everytime one of the developers runs the app locally?
And also, doesn't it make sense to have a separate App Service slot just for the local environment, so I can test everything and see the logs I'm trying out locally, and not have to deploy to dev everytime I want to see what I'm doing?
I've tried creating a separate slot for local, but it generates a weird url based on the name I give, which I can't change later.
I've googled for a couple of days already and couldn't find any (or very little) helpful advice when it comes to this.
I realise there is a "Just add the SDK to try local only mode" option in Visual Studio, but then I would have to use it exclusively locally. What I want is to use all three - my local, dev & prod.
We're using .net core 2.2 for our backend and Angular 7 for front end.
I'm an idiot.
The url set up automatically basically means nothing. I solved the problem by just adding another App Service slot (created from our App Service production one, just like dev), and added this key to the local settings in our project.
Now we can use this key to get real time results as we debug, and use the other two for dev & production.
I am having a slight (though, not impacting functionality) issue with Azure App Service and the ASPNETCORE_ENVIRONMENT. On my local development environment I used the command setx ASPNETCORE_ENVIRONMENT "Development" to set my local to Development. When I output the value of Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") in my local it correctly returns "Development" and correctly selects the proper Development appSettings JSON file. So far so good.
Here is where things get weird (or maybe it's correct?). In Azure App Service I set the ASPNETCORE_ENVIRONMENT value within the Application Settings portion to "Production". When I output this value in the application it says "Production;Development". I was expecting "Production". The application is correctly pulling the production appSetting values, but why am I seeing both values? I was able to adapt my code to check if the value .Contains("Production") for production specific functionality, but I cannot figure out why both values are present. I have researched thoroughly and cannot find a reason. My solution and project files have no variables set. My Azure Build/Pipline has no variables set for this.
Any thoughts?
This ended up being caused by a process adding a "Web.config" file and pre-populating it with ASPNETCORE_ENVIRONMENT. Removing the value from the Web.config worked. I have since then been only setting environment values on the machines/systems/cloud apps.
I need to expose few simple configuration options for my website, that should be easy to change, without requiring recompilation or restarting the app. I'd also like the options to be cached in the app, but they should refresh when the config is changed (or at least every few minutes). My website is an ASP.NET Core MVC app, which runs on Azure App Service and is deployed by pushing to a git repository and then rebuilt using Kudu.
I was thinking about using Configuration with an EF provider, but it requires quite a bit of work to support reloading of the config when the data is changed.
I noticed that JSON config provider has "reloadOnChange" option, so this seems like a good candidate. However, I'm not sure where I should put the JSON file on the Azure App Service environment so it's easily readable by the app, shared across all instances and persistent between deploys. I know that the "d:\home" folder is shared and persistent. The wwwroot is inside of it, but I'm afraid that the file might get deleted at some point when the app is redeployed. So I'd like to put it in one of the parent folders, but how do I access the home folder from the C# code? I'm assuming I shouldn't just hardcode the "d:\home" path.
I'm also very keen to hear about any alternative ways to achieve the goal.
Actually, you do not need to worry that it will delete appsetting.json file when you redeployed. If you change your configurations, it will override the json file.
var configuration = new ConfigurationBuilder()
.SetBasePath(System.IO.Directory.GetCurrentDirectory())
.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
.AddEnvironmentVariables()
.Build();
Note: When you publish the app, remember do not click "Remove additional files at destination".
Also, if you want to set the appsetting.json in home folder, you could use Environment.GetEnvironmentVariable("Home"); which is equal to "D:\home".
And if you set like this, you need to set ASPNETCORE_ENVIRONMENT to distinguish your environment is azure or local.
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
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.