Using the Serverless framework, I want to be able to change the AWS region from an envrionment variable.
provider:
name: aws
region: ${env:AWS_REGION}
Then, AWS_REGION can be set to eu-west-2.
However, I want to have that set in a .env file:
AWS_REGION=eu-west-2
And then have that .env read by Serverless.
There are many topics about setting variables in the serverless.yml file, and exporting them from that file, but I want to put them into the file.
Out of the box serverless doesn't parse .env, that part belongs to you.
I see three options for you:
Use the serverless-dotenv-plugin.
Write a script that exports .env vars to your local environment before you run serverless.
Run serverless in docker-compose which is .env aware -- I use this in combination with Makefile, even in a CI/CD context.
Serverless now supports .env files without the need for a plugin
Add useDotenv: true to your serverless.yml file. The variable should be at the root level, same as service: ...
Add a .env file at the root of your project and serverless will load the variables.
Example:
// .env
MY_TABLE=A_TABLE_NAME
use this plugin to write .env with serverless.yaml serverless-export-env. so you just need to overwrite your region inside serverless yaml, and your env will be generated based on whay you've written in serverless.yaml.
Related
I'm wondering how can I set up the MS AppCenter to use the specific .env file, let' say the .env.staging for example:
and the CI/CD of the AppCenter will do the build for me with that .env file
If you have separate branches for staging, release etc. this can be made to work.
For each of the branches have a common environment variable to identify the specific release. Ex: TARGET = staging
(Or you can even use Appcente's pre-defined variable APPCENTER_BRANCH to grab the branch name. Depends on the strategy you follow.)
Next create a either a appcenter-pre-build.sh or appcenter-post-build.sh and update it as follows. This will create a copy of your TARGET env file as .env
#!/usr/bin/env bash
# Appcenter pre-build hook to setup amplify.
set -e
IFS='|'
echo "Making a copy of .env file"
cp .env.${TARGET} .env
I'm building an app using Vue CLI 3.
I've included .env in my project and everything works fine.
But when i'm building the app for production via npm run build there is no .env file in my dist folder, so i can't change my environmental variables in production server.
Any solution or it's just fine?
This is supposed to happen. The env variables are embedded in your build.
You can make seperate .env files for production. These variables will be used during the production build.
Create a new .env file named: .env.production
Source: https://cli.vuejs.org/guide/mode-and-env.html#modes
It is normal because application needed to be recompiled when .env file changed.
For convenience you can use .env.prod or .env.dev for your CI/CD pipeline.
I have config server which is a containerized. now my task to create a API in express. the problem i am facing is how to read the common properties defined in the config server in my express api.
Create a .env File to store your environment variables. Example: .env.development or .env.test or .env.production files that you can put into a config folder.
Download the node module "node-foreman" https://github.com/strongloop/node-foreman
Now run your web server using foreman and specify which environment you want with the following command line command.
./node_modules/foreman/nf.js --env ./config/.env.development start web=1
That will load the correct environment that you want.
Then to access your environment variables in the actual code, you use "process.env".
For example if you have a key-value pair in your .env file like version=5.5 then to access it in the code you do process.env.version.
I know I can write it to the mounted host file system which will be shared amongst the multiple build containers. But how can I make use of that file in a drone plugin container like docker-plugin?
Or, is there any other way to pass arbitrary data between build steps? Maybe through environment variables?
This is drone 0.5
It is only possible to share information between build steps via the filesystem. Environment variable are not an option because there is no clean way to share environment variables between sibling unix processes.
It is the responsibility of the plugin to decide how it wants to accept configuration parameters. Usually parameters are passed to the plugin as environment variables, defined in the yaml configuration file. Some plugins, notably the docker plugin [1], have the ability to read parameters from file. For example, the docker plugin will read docker tags from a .tags file in the root of your repository, which can be generated on the fly.
pipeline:
build:
image: golang
commands:
- go build
- echo ${DRONE_COMMIT:0:8} > .tags
publish:
image: plugins/docker
repo: octocat/hello-world
Not all plugins provide the option to read parameters from file. It is up to the plugin author to include this capability. If the plugin does not have this capability, or it is not something the plugin author is planning to implement, you can always fork and adjust the plugin to meet your exact needs.
[1] https://github.com/drone-plugins/drone-docker
I'd like my API's base URL to change from dev to prod. In Angular I user to use a config.json file which was later injected into the app using grunt-env
If you use the Aurelia CLI, it will generate an environments directory inside of your aurelia_project.
Within this directory you can setup environmental configs that will be copied into environment.js in your src directory based the --env [dev/stage/prod] flag that you pass into your au build/run commands.
Then you can use import environment from './environment' to access your environment specific configuration values.
Another option that you can look into is the Aurelia Configuration Plugin, which also has dynamic environmental configs.
If you want to 'inject' it only once then what is stopping you from using a simple ES6 module ? It should be loaded only once from the server.
For instance you could something like that in a config.js file : (warning ! I didn't try to run it)
export var Config = {
path : 'path to find'
};
you can then use your module anywhere you need it :
import {Config} from 'config';
I have successfully used the Aurelia-Configuration plugin to dynamically switch environments based on the domain that hosts the app
More info https://github.com/Vheissu/Aurelia-Configuration/blob/master/README.md#get-started to do this