Was looking at the docs to set up a few apps deployed to strong-pm but ran into a cart-before-the-horse type issue:
It's not possible to set environment variables using slc ctl env-set <service> FOO=bar... before an app is deployed and given a service name.
This means that you are forced to run your app initially in a failure state upon first deploy, which is inconvenient and probably not a huge deal, but was curious if this is known.
Would be awesome if the slc ctl env-set command could set up a service name just like slc deploy does, but without the deploy itself.
As an aside, was curious if slc pm-install/sl-pm-install -e "FOO=bar" actually works to set common/shared/global env vars, but I couldn't find where these vars were set when the command was run.
When you deploy an app for the first time it auto-creates a service if one doesn't exist as part of the process. This can also be done manually with slc ctl create default. If you do that manually, you can modify the environment with slc ctl env-set default FOO=bar BAR=foo before running slc deploy.
Note that default is just a name, and if you want to use a name other then default you will have to specify it when you deploy with slc deploy -s customName since default is the default name.
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 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.
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 identifying my openshift nodejs app environment through system environment variables Ex: 'staging', 'production'. My custom environment variable name is OPENSHIFT_APP_ENV. I have set this in .bash_profile and ran source .bash_profile.
When I did printenv or echo $OPENSHIFT_APP_ENV in command line in my openshift app, I can see the values set properly.
But these variables are not read/set in my nodejs app. I am simply trying to read it as global.ENV = process.env.OPENSHIFT_APP_ENV || "development";
I feel that it should be simple setting issue, but could not get this working somehow. Any help will be appreciated.
You should use the rhc env set command as explained in this section (https://developers.openshift.com/en/managing-environment-variables.html#custom-variables) of the Developer Center to set your environment variables. Especially if you are using a scaled application, that makes sure that your custom environment variables are created on all gears.
It is also standard practice (i believe) to use the NODE_ENV environment variable to determine what environment you are operating in.
You should also make sure to stop & start (not restart) your application after you create environment variables to make sure that your process picks them up correctly (may solve your issue of your application not seeing the ones from your .bash_profile, but i would still recommend using the rhc env set command instead)
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