Skip to content

cloud.gov

Jump to bottom
Aaron D Borden edited this page Feb 22, 2021 · 12 revisions

Cloud.gov Cheat Sheet

Helpful resources:

Setup

To login to cloud.gov, enter cf login -a api.fr.cloud.gov --sso

To set the organization and space to development, use cf target -o gsa-datagov -s development

Many commands in this document are specific to an application. If you run app_name=<your-app-name>, such as app_name=inventory (should be in either the manifest.yml file or vars.yml file), then you can run the commands as-is without replacing the ${app_name}

Test environment VCAP_SERVICES

To test jq queries against a json services variable, you can get the json list of services by running cf env ${app_name}. Then, copy the relevant JSON and use this thread to paste the command into your local command line variable:

read -r -d '' VCAP_SERVICES << EOM
[[copy-pasted from previous command]]
EOM

Now, you can run test jq queries against a VCAP_SERVICES variable as the buildpack should have.

Attaching to your app via ssh

You can read more details in the cloud.gov docs.

  • First make sure that you're able to ssh via cf ssh-enabled ${app_name}
  • If it's enabled then run cf ssh ${app_name}
  • Activate your application's environment by running /tmp/lifecycle/shell

You're ready to go!

Deployment

cf CLI v7 includes the push --strategy rolling for rolling deployment. This performs a zero-downtime deployment for you following blue-green deployment.

Occasionally, the new version is unhealthy. While the old healthy application will continue to serve traffic you must manually rollback by cancelling the deployment.

$ cf cancel-deployment ${app_name}

Deployment via GitHub Actions

The easiest way to deploy, and to validate your PR will deploy as expected, is to comment out the if statement in the .github/workflows/commit.yml that looks like if: github.ref == 'refs/heads/develop'. This will then deploy your changes on any commit to that branch. You can then watch the deployment run via the github actions logs, or through your own command line via cf logs ${app_name}. If you need to rapidly iterate and need to skip tests for some reason, you can comment that out too. Make sure all PR's are checked for this change, and do not merge if this change is in place!

Space organization

We have four spaces:

  • management
  • development
  • staging
  • prod

Each space should have a ci-deployer service.

$ cf create-service cloud-gov-service-account space-deployer ci-deployer

Each repository should create their own deployer key.

$ cf create-service-key ci-deployer inventory-deployer

View the username and password to add as a CI secret for deploying.

$ cf service-key ci-deployer inventory-deployer

Secrets Management

We typically store secrets necessary for an application in a User Provided Service. If necessary, they will typically be named ${app_name}-secrets, with a different user-provided-service for each application and each environment.

If you are creating a user-provided-service for the first time, follow the documentation to either provide a JSON file or simply provide the keys and input values via the command prompt. You'll need to bind the secrets to the service across each space; the simplest way is usually to add it to the services list in the manifest file (but can be done manually)

If you are updating a user-provided-service, we need to get the current configuration and change only the parts that we want/need. To find what the current user-provided-service looks like, run cf env ${app_name}. It should appear in the VCAP_SERVICES JSON object, something like ${app_name}-secrets. Copy the credentials JSON object part, and place it in a temporary local file (usually secrets.json is git ignored). Edit this file (add, update, remove, etc) until the object is correct. Then, use cf uups ${app_name} -p /path/to/file to update the configuration. Remember this will need to be done for each application and space separately (use cf target -s <development, staging, prod> to change space), and the temporary JSON file should be removed once the updates are done and confirmed.

Because secrets are provided to the application as environment variables, there is effectively a 4096 byte limit to secrets. In some cases, it might help to gzip and base64 encode your secret.

Clone this wiki locally