CNAB: Packagaging for Applications with Multiple Toolchains

CNAB: Packagaging for Applications with Multiple Toolchains

Talk from Skills Matter in London introducing CNAB, the Cloud Native Application Bundles specification, and associated tooling.

98234c645fe8c935edc0fec0186d28b8?s=128

Gareth Rushgrove

January 23, 2019
Tweet

Transcript

  1. CNAB: Packaging for Distributed Applications with Multiple Toolchains January 2019

    Gareth Rushgrove
  2. @garethr Docker

  3. This talk - A little background What is the user

    need behind CNAB? - Diving into the CNAB specification Core concepts and state of play - Emerging CNAB tools What tools have been built so far? An introduction to Cloud Native Application Bundles
  4. None
  5. A bit of background

  6. How many tools do you use? In particular when describing/deploying

    your apps
  7. Helm, Kustomize, Docker, Compose, Kubernetes configs, Puppet, Chef, Salt, Ansible,

    Ksonnet, Pulumi, Pallet, Kops, Terraform, Kubespray, AWS CDK, Cloudformation, Serverless Framework, Azure Resource Manager, ...
  8. Helm, Kustomize, Docker, Compose, Kubernetes configs, Puppet, Chef, Salt, Ansible,

    Ksonnet, Pulumi, Pallet, Kops, Terraform, Kubespray, AWS CDK, Cloudformation, Serverless Framework, Azure Resource Manager, ...
  9. Helm, Kustomize, Docker, Compose, Kubernetes configs, Puppet, Chef, Salt, Ansible,

    Ksonnet, Pulumi, Pallet, Kops, Terraform, Kubespray, AWS CDK, Cloudformation, Serverless Framework, Azure Resource Manager, ...
  10. Multi-service apps often use multiple toolchains Which means distributing lots

    of versions of lots of tools, often separately from the application
  11. Large organisations often have a diversity of toolchains Which means

    distributing lots more versions of lots more tools
  12. CNAB allows for packaging the tools along with the app

    they manage Just install
  13. AWS RDS and Helm example

  14. But how many times have we re-invented package formats? Hint,

    it’s more than once
  15. With reference to XKCD 927

  16. CNAB isn’t trying to solve the whole problem Just the

    bits we can build agreement around
  17. Metadata Fundamental parts What do we mean when we say

    package On-disk representation Execution Distribution
  18. Terraform Cloud Formation Azure Resource Manager Compose Helm Pulumi etc.

    Terraform Module None None None Helm Chart None etc. Terraform Module Registry None None None Helm Chart Repository None etc.
  19. Terraform Cloud Formation Azure Resource Manager Compose Helm Pulumi etc.

    Terraform Module None None None Helm Chart None etc. CNAB compatible registries Compatibility between repositories/registries should reduce the upfront cost for adopting new technologies that utilise CNAB. You’ll already have a compatible package registry in place.
  20. Terraform Cloud Formation Azure Resource Manager Compose Helm Pulumi etc.

    Standard tools for creating packages for different toolchains Today not all tools have a package concept, CNAB makes that easier to implement in a standard way, either in technology-specific tooling (better UX) or generic tooling (no need to wait for integration) CNAB compatible registry
  21. CNAB is more like MSI than Helm Charts or Terraform

    Modules It’s not tool specific, it’s about compatibility between tools
  22. Demo

  23. Diving into the spec

  24. deislabs/cnab-spec

  25. Metadata CNAB parts What do we mean when we say

    package On-disk representation Execution bundle.json Specified file system layout OCI runtime with specified entry point and arguments Distribution OCI image and distribution specifications
  26. Table of contents

  27. bundle.json A schema for package metadata

  28. None
  29. Basic metadata like name, version, description, etc.

  30. Credentials required by the tools to talk to relevant APIs

    (eg. KubeConfig.)
  31. The actions which the bundle responds to. Must include install,

    uninstall and upgrade.
  32. The user interface exposed to those installing the package. These

    are provided at runtime.
  33. Extend the metadata with format specific information.

  34. Invocation Image - A file system hierarchy following a defined

    pattern - A executable entry point responsible for translating action requests (install, upgrade,...) to a sequence of tasks - Runtime metadata - The material necessary for reproducing the invocation image Referenced in the bundle.json
  35. Claims A record of a CNAB action

  36. Signing, Attesting, Verifying and Validating Ensure package was vetted by

    a trusted entity and has not been altered
  37. Emerging CNAB tools

  38. Duffle: Go reference implementation

  39. Building a CNAB with duffle $ duffle build ./examples/helloworld/ Step

    1/5 : FROM alpine:latest ---> 196d12cf6ab1 Step 2/5 : RUN apk add -u bash ---> Using cache ---> 54b3a85c5c2e Step 3/5 : COPY Dockerfile /cnab/Dockerfile ---> Using cache ---> cd6f4ff8d83d Step 4/5 : COPY app /cnab/app ---> 38a482447ffd Step 5/5 : CMD ["/cnab/app/run"] ---> Running in 8b22055f0a37 ---> e5c795c2a1f4 Successfully built e5c795c2a1f4 Successfully tagged deislabs/helloworld-cnab:64dfc7c4d825fe87506dbaba6ab038eafe2a486d ==> Successfully built bundle helloworld:0.1.0
  40. Installing a CNAB with duffle $ duffle install helloworld-demo -c

    helloworld-creds helloworld:0.1.0 Executing install action... hello world Install action Action install complete for helloworld-demo
  41. Docker App: Package Compose apps

  42. Start with a Compose file $ cat docker-compose.yml version: '3.6'

    services: hello: image: hashicorp/http-echo:${version} command: ["-text", "${text}"] ports: - ${port}:5678
  43. Provide metadata and parameters $ cat metadata.yml version: 0.1.0 name:

    hello description: sample app for DockerCon maintainers: - name: garethr email: garethr@docker.com $ cat parameters.yml port: 8765 text: hello DockerCon version: latest
  44. Demo

  45. Install and upgrade your application $ docker-app install Waiting for

    the stack to be stable and running... hello: Ready Stack hello is stable and running $ docker-app status ID NAME MODE REPLICAS IMAGE PORTS 38e1cec8-f88 hello_hello replicated 0/0 hashicorp/http-echo:latest *:8765->5678/tcp $ docker-app upgrade hello --set port=9876 --set text="hello again" Waiting for the stack to be stable and running... hello: Ready Stack hello is stable and running
  46. Get information about your bundle $ docker-app inspect hello 0.1.0

    Maintained by: garethr <garethr@docker.com> sample app for DockerCon Service (1) Replicas Ports Image ----------- -------- ----- ----- hello 1 8765 hashicorp/http-echo:latest Parameters (3) Value -------------- ----- port 8765 text hello DockerCon version latest
  47. Push bundles to Docker Hub $ docker-app push --namespace garethr

    The push refers to repository [docker.io/garethr/hello] b86b3b8bd0d3: Pushed 6b91c6b22046: Mounted from garethr/myapp ead7fcac6d91: Mounted from garethr/myapp df64d3292fd6: Mounted from garethr/myapp 0.1.0-invoc: digest: sha256:9f5fa85893cc87024a74b2261d19a309e5de55dff5e43d19fcf1d2f2657dbe2a size: 1157 Successfully pushed garethr/hello:0.1.0@sha256:1f7f2ac9ce061f7727addce5843d65fb052382f4e5f92dd38dd519b5e9b1e60a $ docker-app install garethr/hello:0.1.0 Waiting for the stack to be stable and running... hello: Ready Stack hello is stable and running
  48. CNAB is an implementation detail, unless you want to drop

    down a level
  49. bundle.json and Invocation Image $ docker-app bundle Invocation image "hello:0.1.0-invoc"

    successfully built $ docker image ls hello REPOSITORY TAG IMAGE ID CREATED SIZE hello 0.1.0-invoc cfd34904554c 6 days ago 40.1MB $ cat bundle.json { "name": "hello", "version": "0.1.0", "description": "sample app for DockerCon", "maintainers": [ { "name": "garethr", "email": "garethr@docker.com", "url": "" }
  50. By creating CNAB bundles we get a GUI installer for

    free, in the form of duffle-bag Why we adopted CNAB?
  51. We can also more easily add support for different toolchains,

    all in the same signed package Why we adopted CNAB?
  52. Some examples to get you started garethr/docker-app-cnab-examples

  53. Duffle Bag: GUI installers for CNAB

  54. Porter: Declarative bundle builder

  55. Describe actions using mixins $ cat porter.yaml mixins: - exec

    name: hello version: 0.1.0 invocationImage: porter-hello:latest install: - description: "Say Hello" exec: command: bash arguments: - -c - echo Hello World uninstall: - description: "Say Goodbye"
  56. garethr/pycnab: Python client

  57. Write Bundle configuration in Python import json from cnab import

    Bundle, InvocationImage bundle = Bundle( name="hello", version="0.1.0", invocation_images=[ InvocationImage( image_type="docker", image="technosophos/helloworld:0.1.0", digest="sha256:aaaaaaa...", ) ], ) print(json.dumps(bundle.to_dict(), indent=4))
  58. Running a CNAB from Python from cnab import CNAB app

    = CNAB("fixtures/hellohelm/bundle.json") # list available actions print(app.actions) # list available parameters print(app.parameter) # list required credentials print(app.credentials) # Here we pass the value for the required credential # in this case by reading the existing configuration from disk with open("/home/garethr/.kube/config") as f: print(app.run("status", credentials={"kubeconfig": f.read()}))
  59. Conclusions

  60. Conclusions - CNAB is a specification first Think MSI or

    OSI rather than Helm Charts - Early days, but lots of hacking potential Client libraries, contribute to existing tools, integrate your own software - Get involved #cnab on CNCF Slack, or open issues on the GitHub repository If all you remember is...
  61. Thanks and any questions?