I'm using the Golang google-cloud-sdk to get informations on resources (specifically here compute instances, but it doesn't really matter).
The gcloud cli allows to do something like this:
gcloud config set compute/zone ZONE
Which under the hood will write in ~/.config/gcloud/configurations/config_default those value as something that looks like an ini file.
Can the (go) sdk read config those config file ?
The cli also read the environment variable CLOUDSDK_COMPUTE_ZONE if not defined in the config file.
Can the sdk also read this variables ?
To sum up the question , how can I use the same config mechanism the gcloud cli uses with the Go sdk ?
To sum up the question , how can I use the same config mechanism the gcloud cli uses with the Go sdk ?
As far as I know, you can't. You need to specify the zone to all your operations.
Long time ago, someone asked about CLOUDSDK_CONFIG and the last response is cristal clear:
Resolved: we decided not to honor CLOUDSDK_CONFIG, in the interest of maintaining simplicity for the ADC spec.
https://github.com/googleapis/google-cloud-go/issues/288
And I think it's true for all the CLOUDSDK_* env.
Related
Here is the link 12 factor
I am confused weather if I should store values inside my app.properties file vs environment variable.
App.properties
Memory_Folder_Test = Test
Memory_Folder_Prod = Production
Memory_Folder_Dev = Development
Strong_threshold = 10
Low_Threshold = 2
Username = FirstUser
Password = PasswordSecret
So theoretically where should I put these values in? application.properties or as environment variables? If I did not read wrong the purpose of 12 factor is to remove putting values in properties file and externalize it.
You can store the values in application.properties file, however, spring allows you to override those values using environment variables. Hence, it is a 12 factor compliant.
You store the properties externally using something like spring cloud config. You then use the environment properties to define the configurations (like the url) needed to access cloud config from your applications
I prefer to store environment variables in files, encrypt the files and check the encrypted files into git, via blackbox: https://github.com/StackExchange/blackbox
Blackbox will handle encryption/decryption so that it makes it rather difficult to check the unencrypted creds into your repo. Also, the way openpgp works, you can enable teams of devs to encrypt/decrypt the files.
That project is maintained by StackExchange (aka the guys who run this site). It takes some time figuring out openpgp/gpg (which blackbox depends on), but it has been well worth it for me. I've been using in linux and also in windows (via the windows linux subsystem).
I need to display all existing environment variables for snapshots installed on BPM. Is there a way I can do this using the wsadmin command ?
I don't think we have a wsadmin command to display all existing variables for a snapshot. If this is something that would be useful, I would suggest opening a Request for Enhancement(RFE) with BPM development for their consideration. Here is a link on how to do this:
https://developer.ibm.com/answers/questions/175980/how-do-i-submit-an-enhancement-request-or-rfe-for.html
Thanks!
I agree with Paula, there is no wsadmin cmd to display env variables.
However, you can check out:
BPMSetEnvironmentVariable:
https://www.ibm.com/support/knowledgecenter/SSFPJS_8.5.6/com.ibm.wbpm.ref.doc/topics/rref_bpmsetenvironmentvariable.html
And REST call to get env variable:
https://www.ibm.com/support/knowledgecenter/SSV2LR/com.ibm.wbpm.ref.doc/rest/bpmrest/rest_bpm_wle_v1_system_env_variable_get.htm
This can be achieved by the BPM REST Interface APIs.
Use this API to retrieve the list of process applications, in which you can find the ID of the snapshot you are interested in.
https://<bpm_host_or_ip>:9443/rest/bpm/wle/v1/processApps
Use this API to retrieve the envrionment variables and their default values.
https://<bpm_host_or_ip>:9443/rest/bpm/wle/v1/processAppSettings?snapshotId=2064.11a398d0-c6b8-41e4-b8eb-daaef864be14"
You can easily use jq in a Linux environment to parse out the information you are interested in.
Finally use this API to retrieve the current value of a given environment variable.
https://<bpm_host_or_ip>:9443/rest/bpm/wle/v1/system/env/variable?processAppAcronym=<APP_ACRONYM>&name=<ENV_VAR_NAME>
So I have been running concourse pipelines using a separate yaml file to hold my variables, similar to this example in the documentation. However I would like to set my variables within my main pipeline.yml file to avoid using the cli option --load-vars-from some_other_file.yml. How could I do this?
Note: I might be looking for something that uses params:, but I want the params I set to be global for everything in my pipeline.yml file, so that everything can use the variables I set in it.
I don't believe that what you want to do is possible, in the way that you suggest.
I think you have two options:
Put your YAML file in an S3 bucket, and have the pipeline watch the S3 bucket as a resource, and call set-pipeline on itself whenever that bucket changes, using the YAML file in the bucket to populate variables.
Put your YAML file in an S3 bucket, and use it as an input to whatever job needs those variables. You can then use a tool like yml2env to make the contents of that YAML file available to your scripts as environment variables.
As of concourse v3.3.0, you can setup Credential Management in order to use variables from the Vault (this is the only supported credential manager by concourse right now). This way you won't have to keep any variable in a separate file and Vault will keep them secure as well.
Using the Credential Manager you can parameterize:
source under resources in a pipeline
source under resource_types in a pipeline
source under image_resource in a task config
params in a pipeline
params in a task config
For setting up vault with concourse you can refer to:
https://concourse-ci.org/creds.html
I've set a few custom config variables. I can see them in my application's settings->config variables. I can also see the values with the heroku config command. But when I start my application the environment variables are not there. I use (System/getenv "MY_VARIABLE_NAME") in Clojure to fetch them.
Is it because I try to retrieve them at boot time? Are they only available later? Or is there some twitch which I can get rid of by doing some trick? I've used config variables in Heroku before and they've worked, I don't know what's the problem here...
I was trying to retrieve client ID and secret for oauth authentication with Google from a config variable with System/getenv. I use a library called Friend to do this. Problem is, the set up for oauth parameters in that library is done via macros. And macro expansion happens compile-time. Heroku config variables are not available as environment variables during compilation (for good reasons). They are, however available via filesystem which was my solution to the problem. So instead of:
(System/getenv "MY_APP_GOOGLE_CLIENT_ID")
I'm using this:
(slurp (str (System/getenv "ENV_DIR") "/" "MY_APP_GOOGLE_CLIENT_ID"))
And it works!
I'm currently writing a tutorial on setting up Wordpress on Heroku. Right now I'm using the ClearDB add-on which sets a CLEARDB_DATABASE_URL ENV variable automatically. Is it possible to alias the ENV variable through Heroku as DATABASE_URL?
It's not possible to alias an config var or refer to one from another. I asked a similar question and this is what they said:
I'm afraid that Config Variables can't refer to each other in this
way, as they are simple a collection of Names and Values, with no
interpolation or calculation available to the values.
You might like try a
profile
file...
I've had a similar issue - where I'm trying to use an app in a pipeline connected to 2 different heroku DB's - in order to keep all he environments consistent in code, I did the following:
Heroku Configs:
DATABASE_URL=XXXXXXXX - this was the first DB that heroku attached
HEROKU_POSTGRESQL_JADE_URL=XXXX - this was the second DB that heroku attached (the key name changes in each environment)
SECOND_DB_KEY_NAME=HEROKU_POSTGRESQL_JADE_URL
(ie. after each environment was set up - I added a reference to the new key)
This second DB key name, does not change if the DB credentials refresh.
In code, I then did the following at start up:
const databaseUrlKey = process.env.SECOND_DB_KEY_NAME
process.env['SECOND_DATABASE_URL'] = process.env[databaseUrlKey]
Maybe I'll just say something stupid, but why not just do this:
heroku config:set DATABASE_URL=CLEARDB_DATABASE_URL
In code:
ENV[ENV['DATABASE_URL']]
I'm not sure this information will be helpful for anyone but just in case:
This question involves an eroneous assertion. The ClearDB add-on does not set a CLEARDB_DATABASE_URL ENV variable. The ClearDB add-on creates a CLEARDB_DATABASE_URL config var. When the app is started an ENV variable is created from the config var. These two variables are different and could even have different values if you changed the ENV variable in your code base.
Of course, within your code base, you can do whatever you want with the ENV variables.
As to whether config vars can reference other config vars, or other ENV variables, or vica versa - I don't know. But surely this would be something pretty hacky, and contrary to intended use, and proper coding practice, and socially responsible behavior.