I was reading through the Decouple Python library, but I don't understand what the following code does-
IP_NETWORK = config("IP_NETWORK")
IP_DEVICE = config("IP_DEVICE")
I know that, there has to be a .env file setup, where the IP_NETWORK and IP_DEVICE have to be declared. But I'm not sure how this module works.
Also, how do I find the IP_NETWORK and the IP_DEVICE ?
I'm not too sure what I'm talking about and may not make sense, but any explanation is appreciated!
Python Decouple library: Strict separation of settings from code
Install:
pip install python-decouple
This library comes handy in separating your settings parameters from your source code. it’s always a good idea to keep your secret key, database url, password etc... in a separate place (environment file - .ini/.env file) and not in your source code git repository for security reasons.
It also comes handy if you want to have different project settings on different environment (e.g - You might want debug mode on for your development environment but not on production.)
How do we decide whether parameter should go inside your source code git repository or environment file ?
It's simple trick - Parameters related to project settings goes straight to the source code and parameters related to instance settings goes to an environment file.
Below first 2 are project settings the last 3 are instance settings.
Locale and i18n;
Middlewares and Installed Apps;
Resource handles to the database, Memcached, and other backing services;
Credentials to external services such as Amazon S3 or Twitter;
Per-deploy values such as the canonical hostname for the instance.
Let's understand how to use it with Django(python framework).
First create a file named .env or .ini in the root of your project and say below is the content of that file.
DEBUG=True
SECRET_KEY=ARANDOMSECRETKEY
DB_NAME=Test
DB_USER=Test
DB_PASSWORD=some_strong_password
Now let's see how we can use it with Django. Sample snippet of settings.py
# other import statement..
from decouple import config
SECRET_KEY = config('SECRET_KEY')
DEBUG = config('DEBUG', cast=bool)
DATABASES = {
'default': {
'NAME': config('DB_NAME'),
'USER': config('DB_USER'),
'PASSWORD': config('DB_PASSWORD'),
# other parameters
}
}
# remaining code.
Hope this answer your question.
Related
# Using a single workspace:
terraform {
backend "remote" {
hostname = "app.terraform.io"
organization = "company"
workspaces {
name = "my-app-prod"
}
}
}
For Terraform remote backend, would there be a way to use variable to specify the organization / workspace name instead of the hardcoded values there?
The Terraform documentation
didn't seem to mention anything related either.
The backend configuration documentation goes into this in some detail. The main point to note is this:
Only one backend may be specified and the configuration may not contain interpolations. Terraform will validate this.
If you want to make this easily configurable then you can use partial configuration for the static parts (eg the type of backend such as S3) and then provide config at run time interactively, via environment variables or via command line flags.
I personally wrap Terraform actions in a small shell script that runs terraform init with command line flags that uses an appropriate S3 bucket (eg a different one for each project and AWS account) and makes sure the state file location matches the path to the directory I am working on.
I had the same problems and was very disappointed with the need of additional init/wrapper scripts. Some time ago I started to use Terragrunt.
It's worth taking a look at Terragrunt because it closes the gap between Terraform and the lack of using variables at some points, e.g. for the remote backend configuration:
https://terragrunt.gruntwork.io/docs/getting-started/quick-start/#keep-your-backend-configuration-dry
I have to update and optimize an nodejs Project for some new use cases. For this, i have to easily change the paths for different host systems. Till now they were hardcoded.
First i used global variables, just to get the system running. But globals are not a very clever idea. Now i created a config.js file which includes the paths and in any nodejs file i linked to them with request("config.js").
nodejs
`global.OEM_datapath = __dirname + '/public/data.csv';
now:
config.js
var PATHs = {
'OEM_datapath': __dirname + '/public/data/data.csv'
}
module.exports = PATHs;
other nodejs files:
var globals = require('./config');
console.log("path:" + globals.OEM_datapath);
'''
Is there a better way to use configuration settings? I considered to use process.env?
Node.js is an environment that helps you create server-side applications using JavaScript. One of the common Node.js elements that developers like and use are .env files. These files let you easily save and load environment variables. Developers often use them to store confidential information. However, sometimes they forget to disable access to these files from the outside, which can lead to major security problems. You can create a sperate env file and maintain the dynamic values.
I considered to use process.env
That is the standard way, in fact if you are working with containers, such as Docker this will also be the case. My suggestion would be to use YAML as the config language and derive config from that, again a Docker 'standard'.
# Using a single workspace:
terraform {
backend "remote" {
hostname = "app.terraform.io"
organization = "company"
workspaces {
name = "my-app-prod"
}
}
}
For Terraform remote backend, would there be a way to use variable to specify the organization / workspace name instead of the hardcoded values there?
The Terraform documentation
didn't seem to mention anything related either.
The backend configuration documentation goes into this in some detail. The main point to note is this:
Only one backend may be specified and the configuration may not contain interpolations. Terraform will validate this.
If you want to make this easily configurable then you can use partial configuration for the static parts (eg the type of backend such as S3) and then provide config at run time interactively, via environment variables or via command line flags.
I personally wrap Terraform actions in a small shell script that runs terraform init with command line flags that uses an appropriate S3 bucket (eg a different one for each project and AWS account) and makes sure the state file location matches the path to the directory I am working on.
I had the same problems and was very disappointed with the need of additional init/wrapper scripts. Some time ago I started to use Terragrunt.
It's worth taking a look at Terragrunt because it closes the gap between Terraform and the lack of using variables at some points, e.g. for the remote backend configuration:
https://terragrunt.gruntwork.io/docs/getting-started/quick-start/#keep-your-backend-configuration-dry
I'm new to the Node.JS. I found few articles says we can use .env file to setup the process.env variable, e.g.,
PORT = 8081
but when I run the program in my node, it is still 8080 PORT (by default). The question is how can I setup the env variable in Node without any other 3rd party module's help? (I found there are few 3rd party package to management the env config, but... it is kind confused, different package might have different rule and more complex use cases; I want to start from clear way to study purely nodejs)
Update
I have read Node Environment Setting post on StackOverFlow, but they are refer using 3rd party package, none of them tells the detail steps. (Either windows system environment, or Linux environment variables... but how can I place the setting into my project folder?!)
Dotenv file have become the most popular mode to separate configuratione from app, using system environment variables (see 12factor config).
On node there exists a lot of libraries for loading config from .env file. The most popular is motdotla/dotenv.
You can read a lot of examples on readme file about the usage of this library
Make a config.js file with the following content:
module.exports = {
bar: 'someValue',
foo: 'otherValue'
...
}
Then you can do this in some file:
const config = require('./config');
let foo = config.foo;
I'm trying to run a number of api calls using dredd and api blueprint to test a site. I would like to run the tests on circleCI, as there are Selenium tests running in the same place. Each transaction needs to be accompanied by two tokens, which are set as cookies in the headers. Ideally, these would be set in the dredd.yml file. When running on a local machine, if I replace ACCESS_TOKEN and REFRESH_TOKEN with the actual values, the test runs as expected.
circle.yml:
test:
override:
- dredd
dredd.yml headers
header: ['Cookie: access_token=ACCESS_TOKEN; refresh_token=REFRESH_TOKEN']
Where ACCESS_TOKEN and REFRESH_TOKEN get replaced by the actual values set in circleCI's environment variables. I have also tried:access_token=$[ACCESS_TOKEN], access_token=$["ACCESS_TOKEN"] and access_token=$ACCESS_TOKEN. None of these are being replaced in the headers for the first api call.
The header looks like: {"Content-Type":"application/json; charset=utf-8","User-Agent":"Dredd/1.4.0 (Darwin 14.5.0; x64)","Cookie":" access_token=$ACCESS_TOKEN; refresh_token=$REFRESH_TOKEN"}
I am new to yaml files, so I'm probably missing something basic, but I did search around for a while. The hooks file is written with node.js, so I don't think the ruby/rails help will be useful here. If I am missing anything in the question don't hesitate to let me know.
YAML is a data representation language, not a template language (or template processor, for that matter). While an individual program might support loading environment variables or additional parameters named in the configuration, the YAML parser (probably, unless it's a custom module) isn't what's injecting them. While skimming the dredd docs I don't see any references to environment variables or parameters, it may be worth creating an issue on the project and starting a discussion with the developers to see if this is supported.
I can think of a number of ways to solve your specific problem, but they all involve additional tools to render the YAML with your variables injected. Perhaps the easiest solution for your case is to set environment variables in the CircleCI web configuration (NOT version-controled circle.yml). Then, set up a pre-build step, where the YAML configuration is generated. To do this, wrap the YAML in a BASH script, with the YAML document contained inside of it as a here-doc.
#!/bin/bash
# ACCESS_TOKEN and REFRESH_TOKEN are injected by CircleCI
cat <<EOF > config.yml
---
header: ['Cookie: access_token=${ACCESS_TOKEN}; refresh_token=${REFRESH_TOKEN}']
EOF
Then run the rest of your job normally, perhaps deleting the configuration file or restoring it from version control before any artifacts are created to avoid the leakage of your credentials.
The better way to work with headers is by Hook files setting headers before each request. As you are using Node.js, try set Node environment variables:
var hooks = require('hooks');
hooks.beforeEach(function(transaction) {
transaction.request.headers.Cookie =
'access_token=' + ACCESS_TOKEN +
'; refresh_token=' + REFRESH_TOKEN;
}