Our app has some configuration that requires a list.
Is there any prior art for containing lists in the heroku config / exporting arrays through environment variables?
Related
For each space within an org using Pivotal Cloud Foundry (PCF) is there a way to set SPRING_PROFILES_ACTIVE for each space?
space1: SPRING_PROFILES_ACTIVE: development
space2: SPRING_PROFILES_ACTIVE: performance
space3: SPRING_PROFILES_ACTIVE: production
etc...
Thanks,
Brian
The primary way that you would set Spring profiles on Cloud Foundry is via environment variables.
Cloud Foundry does not provide a way to set environment variable groups per org or space. You can only set a staging and a running environment variable group which applies to all staging or all running apps. That's in addition to the standard facilities for setting environment variables on an application.
I think you might be able to get this to work, but it'll take a little effort. Here's the idea.
Create a custom buildpack (don't panic, this isn't that difficult). The buildpack's only responsibility would be to create a .profile.d/ script (just a regular Bash script) that contains export SPRING_PROFILES_ACTIVE=<some-profile>.
Any buildpack can create .profile.d/ scripts which are primarily used to configure environment variables. These scripts are automatically sourced by the environment before any application starts. Thus if the buildpack sets SPRING_PROFILES_ACTIVE here, it would be available to your app and take effect.
https://docs.cloudfoundry.org/buildpacks/custom.html#contract
You would just need to create the bin/supply and bin/detect scripts as defined at the link below. The bin/supply is where you'd put your logic to create the .profile.d/ script and bin/detect could be as simple as exit 0 which would just tell it to run always.
https://docs.cloudfoundry.org/buildpacks/understand-buildpacks.html#buildpack-scripts
Your custom buildpack could be as simple as hard coding profiles to use or it could be fancy and look at the VCAP_APPLICATION environment which contains the space name.
Ex: echo $VCAP_APPLICATION | jq .space_name.
The buildpack could then apply logic to set the correct profile given the space name. I don't think the org name is available to the app at staging/runtime, at least not through environment variables, so it would be harder to apply logic based on that.
The last step is using CF's multi-buildpack support. Your custom buildpack would be a supply buildpack so it would be first, then you'd list the actual buildpack to use second as you push your application.
Ex: cf push -b https://github.com/your-profile/your-custom-buildpack -b java_buildpack your-cool-app.
https://docs.cloudfoundry.org/buildpacks/use-multiple-buildpacks.html
Hope that helps!
I was just checking on how pipelines work in Heroku. I want the staging and production apps to be the same except that they should access different API endpoints.
How could I achieve that?
Heroku encourages getting configuration from the environment:
A single app always runs in multiple environments, including at least on your development machine and in production on Heroku. An open-source app might be deployed to hundreds of different environments.
Although these environments might all run the same code, they usually have environment-specific configurations. For example, an app’s staging and production environments might use different Amazon S3 buckets, meaning they also need different credentials for those buckets.
An app’s environment-specific configuration should be stored in environment variables (not in the app’s source code). This lets you modify each environment’s configuration in isolation, and prevents secure credentials from being stored in version control. Learn more about storing config in the environment.
On a traditional host or when working locally, you often set environment variables in your .bashrc file. On Heroku, you use config vars.
In this instance you might use an environment variable called API_BASE that gets set to the base URL of your staging API on your staging instance and to the base URL of your production API in production.
Exactly how you read those values depends on the technology you're using, but if you look for "environment variables" in your language's documentation you should be able to get started.
I am working on a laravel project which is hosted on AMAZON AWS. We are also using AWS AutoScaling service, since new instances can be added/removed on the fly, I am also using AWS CodeDeploy so whenever a new instance will be created it will pull the code from github as we do not include environment variable file on git so new instance will not have the environment variable file so the application will not be able to run. I also do not want to include the environment variable file on git as it is not recommended to include that file on git. If I ignore the best practices here and add the env file on git then still there is a problem as I have different branches with different env files so when I merge the code it will replace the env file as well. So what are the best practices or solutions for this case ?
FYI: we are not using ElasticBeanstalk as I am familiar that on elastic beanstalk there is an option on EB dashboard to add environment variables and the path where env file will create upon new instance creation but we are not using ElasticBeanstalk, we are using AutoScaling service and according to my findings AWS do not provide such functionality for AutoScaling service.
There are several options to configure the env vars for an application.
Place the env files on S3 and on boot in the user data/launch config for that environments auto scaling pull down the config file for that env. Also to lock it down in the role for an environment only allow access to that bucket.
Store the env vars in Dynamodb for the env, and on boot look those up in user data and set at env vars. (unless the contain secrets/connection strings, et al., no way to store encrypted secrets in DDB. )
Use Consul https://www.consul.io/
KV Store: Applications can make use of Consul's hierarchical key/value store for any number of purposes, including dynamic configuration, feature flagging, coordination, leader election, and more. The simple HTTP API makes it easy to use.
I'm not really sure where to start with this. I'm making a Ruby project that interfaces with a dictionary API, and uses an API key. I don't want anybody and his uncle to be able to see this key, but the project will have to be hosted on GitHub. How can I go about doing this, and accessing the key from the Ruby program?
Clarification: this is for a class, and we have to use GitHub
Normally, you'd put such things in a file like this:
DICTIONARY_API=key_goes_here
and check in a version of the file (named .example or .sample or something) which just contains blanks:
DICTIONARY_API=
Or you could read the key from the environment, using ENV. If you host on Heroku, this is recommended. See also the Dotenv gem and the ENVied gem.
I've seen both methods combined (especially when using Dotenv) by making a .env file for local/non-heroku usage, and using Heroku's config settings on Heroku.
Use the Figaro gem. Documentation
Basically you will use a file called application.yml and store environmental variables. Double check that application.yml is listed in your .gitignore file so nobody can view it on github.
You could set:
# application.yml
API_KEY: my_api_key_here
And then you could set it to another variable in your app with:
# anywhere in your app
api_key = ENV['API_KEY']
For production, you can use Figaro's commands to sync your env variables with Heroku.
I made a Sinatra app, that will be hosted on Heroku, and the source will be up on GitHub. The problem is that i have a file with API keys, that is currently in .gitignore. Is there a way, that I can push my repo to heroku with the key file and exclude the file when pushing to GitHub?
Thanks in advance!
It is possible to maintain a separate branch just for deployment, but it takes much discipline to maintain it properly:
Add a commit to a production branch that adds the config file (git add -f to bybass your excludes).
To update your production branch, merge other branches (e.g. master) into it.
However, you must then never merge your production branch into anything else, or start branches based on any “production commit” (one whose ancestry includes your “add the keys” commit).
An easier path is to adopt Heroku’s custom of using environment variables to communicate your secret values to your instances. See the docs on Configuration and Config Vars:
heroku config:add KEY1=foobar KEY2=frobozz
Then access the values via ENV['KEY1'] and ENV['KEY2'] in your initialization code or wherever you need them. To support your non-Heroku deployments, you could either define the same environment variables or fall back to reading your existing config files if the environment variables do not exist.
The Figaro gem provides a good way to manage this issue. It basically simulates Heroku's environment variable approach locally, and makes it easy to keep your keys in sync between your development environment and Heroku.