Skip to content

Latest commit

 

History

History
82 lines (64 loc) · 3.46 KB

README.adoc

File metadata and controls

82 lines (64 loc) · 3.46 KB
Raw

Buildpacks

Goal

In this section, students will deploy their application with a modified buildpack.

Check for the modified buildpack

  • Your administrator has installed an alternate java buildpack.

    1. This buildpack has an added framework component that will set a Java system property containing a timestamp that indicates when the application was staged.

    2. The buildpack was installed (by an admin) with the command cf create-buildpack java-staging-timestamp ./java-buildpack-staging-timestamp.zip 8 --enable

    3. Students should now run cf buildpacks to see that this buildpack is installed!

Verifying your changes

  1. Now it’s time to test our changes. The cities-service contains a very basic REST controller that returns the staging timestamp in response to a GET request.

  2. Access the /staging endpoint. You should see a null timestamp as you aren’t yet using your new build pack:

    $ curl -i http://<cities-service>/staging
HTTP/1.1 200 OK
Content-Length: 52
Content-Type: text/plain;charset=ISO-8859-1
Date: Tue, 27 May 2014 17:23:57 GMT
Server: Apache-Coyote/1.1
X-Application-Context: cities:cloud:0

Application was staged at: null

  3. Now, re-push your app and use the -b flag to use your modified build pack.

  4. Note you should see an indication that you’re not using the standard buildpack anymore!

    Starting app cities-service in org jdk / space development as admin...
-----> Downloaded app package (24M)
-----> Downloaded app buildpack cache (44M)
-----> Java Buildpack Version: e89e546 | https://github.com/krujos/java-buildpack#e89e546

  5. Check the staging info provided by the Java build pack to see that our change was effective:

    $ cf files <cities-service> staging_info.yml

---
buildpack_path: /var/vcap/data/dea_next/admin_buildpacks/16b81d79-2a6a-426a-8cff-6daf779eadad_93ad9995be0bd22935c4590c6986061bbb0e9c0d
detected_buildpack: java-buildpack=158e5a6-https://github.com/cloudfoundry/java-buildpack.git#158e5a6
  java-main open-jdk-jre=1.7.0_55 spring-auto-reconfiguration=1.2.0_RELEASE staging-timestamp
start_command: SERVER_PORT=$PORT $PWD/.java-buildpack/open_jdk_jre/bin/java -cp $PWD/.:$PWD/.java-buildpack/spring_auto_reconfiguration/spring_auto_reconfiguration-1.2.0_RELEASE.jar
  -Djava.io.tmpdir=$TMPDIR -XX:OnOutOfMemoryError=$PWD/.java-buildpack/open_jdk_jre/bin/killjava.sh
  -Xmx382293K -Xms382293K -XX:MaxPermSize=64M -XX:PermSize=64M -Xss995K -Dstaging.timestamp='2014-05-27
  15:52:41 +0000' org.springframework.boot.loader.JarLauncher

    As you can see from the output, our timestamp was added as the final -D argument in the start_command.

  6. Access your application again from your browser and access the /staging endpoint. You should now see a message that contains the timestamp:

    $ curl -i http://<cities-service>/staging
HTTP/1.1 200 OK
Content-Length: 52
Content-Type: text/plain;charset=ISO-8859-1
Date: Tue, 27 May 2014 17:23:57 GMT
Server: Apache-Coyote/1.1
X-Application-Context: cities:cloud:0

Application was staged at: 2014-05-27 15:52:41 +0000

  7. Edit your manifest to ensure future pushes leverage your build pack.

What about testing buildpack changes, or one offs?

Cloud Foundry can accept a git URL as the argument to -b. If you’re iterating on a buildpack change, experimenting or do not desire to make the buildpack available to everyone this is a much easier way to consume a custom buildpack!

See the output of cf push --help for more information.