cloud foundry + circleci integration

[m-richo]

Shall we add a manifest.yml and circle.yml to the repo to allow automated deployments using ausDTO tooling?

[auxesis]

@m-richo what buildpack are you using to launch the app on PWS?

The simplest way to make this work is to build a binary on CircleCI, and launch it with the binary buildpack.

[m-richo]

I could build and run it locally just fine. 👍

I tried out the golang buildpack, but it struggled to find dependencies (see below). I managed to get it deployed only once i'd renamed the _vendor dir to vendor and removed the src dir layer. vendor/src/gopkg.in/alecthomas/ -> vendor/gopkg.in/alecthomas/. I don't know vendoring of golang dependencies well enough to understand how it should be done.

I think your suggestion of using the binary buildpack makes more sense. I'll wrap the nudge.json config file as a build environment variable and try that out.

Starting app nudger in org DTO / space staging as x@y.z.au...
Creating container
Successfully created container
Downloading app package...
Downloaded app package (38.1K)
Staging...
-------> Buildpack version 1.7.12
https://buildpacks.cloudfoundry.org/concourse-binaries/godep/godep-v74-linux-x64.tgz
https://buildpacks.cloudfoundry.org/concourse-binaries/glide/glide-v0.11.1-linux-x64.tgz
-----> Installing go1.6.3... done
Downloaded [https://buildpacks.cloudfoundry.org/concourse-binaries/go/go1.6.3.linux-amd64.tar.gz]
 !!    Installing package '.' (default)
nudger.go:6:2: cannot find package "gopkg.in/alecthomas/kingpin.v1" in any of:
    /tmp/app/.heroku/go/src/github.com/AusDTO/nudger/vendor/gopkg.in/alecthomas/kingpin.v1 (vendor tree)
    /tmp/cache/go1.6.3/go/src/gopkg.in/alecthomas/kingpin.v1 (from $GOROOT)
    /tmp/app/.heroku/go/src/gopkg.in/alecthomas/kingpin.v1 (from $GOPATH)
Failed to compile droplet
Exit status 223
Staging failed: Exited with status 223
Destroying container
-----> Running: go install -v -tags cloudfoundry .
Successfully destroyed container

FAILED
BuildpackCompileFailed

TIP: use 'cf logs nudger --recent' for more information

[auxesis]

OK nice, I'm just hooking up the circle.yml bits now.

[auxesis]

Per #7 we're have a circle.yml that's testing the project in a fully self contained way on Circle (no pulling of deps with go get).

Per #8, we're building and storing the artifact, for later use.

I believe the steps required now are:

• [ ] Add a cideploy.sh to deploy to PWS
• [ ] Ensure cideploy.sh is looking up PWS credentials from environment variables
• [ ] Add environment variables on Circle
• [ ] Add a manifest.yml to specify the binary buildpack should be used to run nudger
• [ ] Find a way to inject a private config during the deploy step

[auxesis]

This might be a decent way of storing the config.

[aussielunix]

I had some thoughts on this but need to understand what the solution is for handling config in a cloud native way.

If your app has no config file and expects config from environment variables then how do you manage these variables across CI, staging and production and amongst the team ?

Example manifest for deploying to cloud.gov.au. This expects you have copied the config file to bin/ alongside the binary.

---

applications:
- name: nudger
  memory: 32M
  disk_quota: 64M
  health-check-type: none
  buildpack: binary_buildpack
  path: bin/
  command: /home/vcap/app/nudger --config="/home/vcap/app/nudger.json"
  no-route: true

[auxesis]

I can think of a couple of ways to do this:

• Expose all config as environment variables. You can dump all the config into an environment variable, or use a series of environment variables. Yuck.
• Inject config as a file at runtime. This requires storing state in a file, which can cause problems because (encrypted) credentials will have to exist out in the open.
• Source config at runtime. Have Nudger source its config from a URL (provided in an environment variable at boot time), and refreshed at an interval.