Add example for Cloud Native Buildpacks

.gitignore

@@ -1,4 +1,8 @@
 */mta_archives/*.mtar
+*/*.mtar
+*/.*_mta_build_tmp/
+*/Makefile_*.mta
+*/mta-op-*/
 .DS_Store
 */target/*
 *.code-workspace

README.adoc

@@ -26,6 +26,7 @@ Clone the repository, following the link:https://help.github.com/en/github/creat
 * link:/cf-app[Simple CF app example, managing app attributes & deploy parameters]
 * link:/cf-app-features[Managing CF app features with app-features parameter]
 * link:/cf-app-docker[Docker images as cf apps]
+* link:/cf-app-cnb[Cloud Native Buildpacks as cf app staging lifecycle]
 * link:/app-routes[Managing cf app routes]
 * link:/sharing-values-between-apps[Sharing configuration values between apps]
 * link:/skip-app-deploy[Skip app deployment using `skip-deploy` parameter]

cf-app-cnb/.cfignore

@@ -0,0 +1,7 @@
+node_modules/
+.gitignore
+.cfignore
+*.mtar
+mta-op-*/
+.cf-app-cnb_mta_build_tmp/
+Makefile_*.mta

cf-app-cnb/.gitignore

@@ -0,0 +1 @@
+node_modules/

cf-app-cnb/README.md

@@ -0,0 +1,52 @@
+# Staging a CF app with the Cloud Native Buildpacks lifecycle
+This example shows how to model a Cloud Foundry application whose source code is staged on the platform with the [Cloud Native Buildpacks (CNB) lifecycle][cf-cnb-lifecycle], rather than the classic "buildpack v2" lifecycle. The CNB lifecycle lets you reference any [CNB-compliant builder image][buildpacks-io] (typically from [Paketo Buildpacks][paketo-io] or your own registry) and have the platform run it during staging. CNBs are considered to be the future for Cloud Foundry and already bring in [new capabilities](<https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0017-add-cnbs.md>), including SBOMs, different compilation-options for traditionally supported languages, such as native-builds for Java and support for languages that have been uncovered so far (e.g. Rust, Elixir, Haskell).
+
+The bundled application is a verbatim copy of the [`nodejs/npm` sample][upstream-sample] from the upstream `paketo-buildpacks/samples` repository: a small Express HTTP server. Only [`mta.yaml`](<mta.yaml>), [`mtad.yaml`](<mtad.yaml>) and a [`.cfignore`](<.cfignore>) are added on top to wrap the sample as an MTA module.
+
+[cf-cnb-lifecycle]: <https://v3-apidocs.cloudfoundry.org/#the-cnb-lifecycle>
+[buildpacks-io]: <https://buildpacks.io>
+[paketo-io]: <https://paketo.io>
+[upstream-sample]: <https://github.com/paketo-buildpacks/samples/tree/main/nodejs/npm>
+
+## Try it out
+The example demonstrates 2 different approaches that lead to the same result.
+
+### Deploy directly from directory
+This approach uses deployment descriptor [`mtad.yaml`](<mtad.yaml>). The `.cfignore` file makes sure that no local development artefacts (e.g. `node_modules/` produced by a local `npm install`) are uploaded:
+```shell
+$ cf deploy ./ -f
+```
+
+### Build an MTA archive and deploy it
+This approach uses development descriptor [`mta.yaml`](<mta.yaml>) to package the sources into an MTAR archive:
+```shell
+$ mbt build --platform=cf --target=.
+$ cf deploy a.cnb.cf.app_0.0.0.mtar -f
+```
+
+The Paketo Node.js buildpack then runs `npm install` during staging on the platform and registers `node server.js` (taken from the `start` script in `package.json`) as the `web` process type, so no explicit `command:` parameter is required in the descriptors.
+
+## Examine the result
+```shell
+$ cf mta a.cnb.cf.app
+Showing health and status for multi-target app a.cnb.cf.app...
+OK
+Version: 0.0.0
+
+Apps:
+name                  requested state   instances   memory   disk   urls
+my-cnb-managed-app    started           1/1         256M     512M   <host>.<domain>
+
+$ cf app my-cnb-managed-app
+...
+buildpacks:
+        - docker://docker.io/paketobuildpacks/nodejs
+
+$ curl https://<host>.<domain>/actuator/health
+{"status":"UP"}
+```
+
+## Clean up resources
+```shell
+$ cf undeploy a.cnb.cf.app -f
+```

cf-app-cnb/mta.yaml

@@ -0,0 +1,38 @@
+_schema-version: "3.3.0"
+ID: a.cnb.cf.app
+version: 0.0.0
+
+modules:
+  # A CF app whose source is staged on the platform via the Cloud Native
+  # Buildpacks (CNB) lifecycle.  The Paketo Node.js buildpack runs `npm
+  # install` during staging and registers `node server.js` (taken from the
+  # `start` script in package.json) as the `web` process type, so no explicit
+  # `command:` is required here.
+  - name: my-cnb-managed-app
+    type: application
+    path: .
+    build-parameters:
+      # Files to exclude from the MTA archive.  `node_modules/` would otherwise
+      # be uploaded if the user ran `npm install` locally; the buildpack
+      # produces it on the platform during staging.  The other entries are
+      # build artefacts of `mbt` itself, plus the previous run's MTAR.
+      ignore:
+        - node_modules/
+        - .gitignore
+        - .cf-app-cnb_mta_build_tmp/
+        - Makefile_*.mta
+        - "*.mtar"
+    parameters:
+      # Switch this app from the default "buildpack v2" lifecycle to "buildpack
+      # v3" (Cloud Native Buildpacks).  See the Cloud Foundry documentation:
+      # https://v3-apidocs.cloudfoundry.org/#the-cnb-lifecycle
+      lifecycle: cnb
+      # CNB buildpack image, given as a fully qualified Docker URL.  The Paketo
+      # Node.js image is pulled by the platform during staging.
+      buildpacks:
+        - docker://docker.io/paketobuildpacks/nodejs
+      memory: 256M
+      disk-quota: 512M
+      instances: 1
+      routes:
+        - route: ${default-host}.${default-domain}

cf-app-cnb/mtad.yaml

@@ -0,0 +1,19 @@
+_schema-version: "3.3.0"
+ID: a.cnb.cf.app
+version: 0.0.0
+
+modules:
+  # A CF app whose source is staged on the platform via the Cloud Native
+  # Buildpacks (CNB) lifecycle.
+  - name: my-cnb-managed-app
+    type: application
+    path: .
+    parameters:
+      lifecycle: cnb
+      buildpacks:
+        - docker://docker.io/paketobuildpacks/nodejs
+      memory: 256M
+      disk-quota: 512M
+      instances: 1
+      routes:
+        - route: ${default-host}.${default-domain}