Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2019 (Barcelona), 22 May 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Intro to CNAB: Packaging Cloud Native Applications with Multiple Toolchains - Chris Crone, Docker

Description

Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io

Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects

Intro to CNAB: Packaging Cloud Native Applications with Multiple Toolchains - Chris Crone, Docker

When you deploy a cloud native application, you probably use a variety of tools for each part of the application. Terraform or ARM templates for the infrastructure, Helm or Compose for containers, etc. No single tool handles all your needs and each one has its own package manager! This talk will introduce the Cloud Native Application Bundle (CNAB) specification and tooling: - duffle: Reference implementation of CNAB installer - duffle-bag: GUI for installing CNABs - cnab-to-oci: Convert CNAB to an OCI index CNAB embraces the multi-tool world and allows one to package up multiple formats and their toolchains into a single artifact. Imagine a single installable application package that uses Terraform to launch an RDS instance and Helm to deploy the application that uses it. CNAB allows you to package this all together, cryptographically sign it, and share it via any container registry.

https://sched.co/MPX8

A

Oh so hi everyone, I'm Chris, Crona I work in engineering at Daka, I'm part of the application definition team we've, mostly in Europe I'm based in Paris, and we've got a couple of people in Cambridge and some more in Paris we're responsible for compose docker, app composing communities, among other things.

A

So today we're gonna, take a look at what problems scene app tries to solve the CNF specification itself, because it's pretty new and not many people, know about it. We'll take a quick look at the scene, AB ecosystem and then we'll ask you know what's next to see now, because it is quite young.

A

So to start with we'll talk about the, why of scene app. So why did we build this thing before we can do that, though? We need to. We need to talk about what an application is, because C now stands for cloud native application bundle. We need to know what what we're talking about so the Oxford English Dictionary defines an application, as so so a program or piece of software designed to fulfill a picket particular purpose. That's a pretty loose definition! If you ask me I feel like they, they didn't really didn't, really try.

A

So we can maybe do better we're a. We were a bunch of people in tech. We can maybe answer that question a bit more concretely. So is an application, a binary and a virtual machine. Is it a binary in a container? Is it multiple containers, orchestrated by cuban Eddie's? Is it a host of database in some lambdas or is it any combination of the above? So it turns out. If you ask 10 people you'll probably get 10 different answers, because applications are very specific to organizations and to people.

A

So it you write an application to solve a problem which means that it might even be something completely different so that that hasn't really got us to anywhere better. But we can ask the question: how do you deploy an application? So once again, it completely depends if it's a binary, I hope you're using some sort of package manager, so like apps, maybe you're putting up some infrastructure.

A

So you can use terraform if you're installing something to accuse cluster, you could be using help, charts and helm or if you wrote your own cubm or maybe you're just using cubic you cuddle, apply, compose, also works in Cuban AD, so you could use stack, deploy or maybe you have some specific up. Some specific infrastructure thing. That's only provided by a table. Yes, in which case you need to use their their CLI tooling. So that's how we got here. That's a good thing, not a bad thing.

A

The reason that the CNC F landscape is as big as it is is because there are lots of different problems to solve and you need lots of different tools to solve them. The problem is that each tool comes with its own version management and each tool probably comes into its own package manager. So you have this nightmarish landscape, where you can't deploy an application easily, because you need multiple tools.

A

So what is CNM well, it stands for cloud native application, bundle yep, another acronym, it's a packaging format for distributed applications and it's a specification. So the primary audience of C NAB is people making tools.

A

So what are seen apps goals? Well, it's to solve that problem. We saw its. How do you deploy a complex application easily? It aims to be cloud agnostic, so you shouldn't care where you're running it or how you're running it. It aims to be secure because we live in a world now where we can't have nice things and it aims to handle a spread of use cases.

A

So it's everything from IOT to edge air-gapped normal clusters, everything so right about now, there's probably a bunch of alarm bells going off and you know why do we need yet another standard or yet another spec? Sorry to make this happen.

A

The alarm bells are good, but I'd like to reassure you that we're not creating C AB alone, so we're doing this with a bunch of other folks who are actually in the room with here today as well from Microsoft, pivotal bitNami hashey code fresh, we're doing this in the open, so we have week by weekly meetings and the idea of doing this. This way is that we want to get a bunch of different use cases and test them as we're building the spec.

A

So we build something that actually resembles the real world and obviously we you know in order for it to be cloud agnostic, we need a bunch of different people working on it. So how do you go about putting together as vacation that tackles something that's complicated?

A

Well, you need to start by finding what's common between applications, so every application has a definition. This could be your home chart. It could be a compose file, it could be QP amel, it's the description of what will be inside the application. You need then, need tooling to deploy and manage your applications. So in the helm case you need the helm CLI and to the what until v3 comes out, you need darkus, tak, deploy or dakka dakka CLI to deploy compose files. You may need coop couple to manage QV, amal and so on.

A

And finally, you have these parameters and credentials. These are things that you want to set when you deploy the application parameters. Are things like ports, so an operator will say: I want this to expose something on this port and credentials will be things that you used to call API is to deploy your application, so it could be a cube, config certificates or something else.

A

The other thing that we thought about when we started putting the spec together is what do we have already, and what can we reuse we're not the first people to work in the space we should. We should try to reuse what we have so I talked about having a definition, there's a notion of an artifact where we could build this into an immutable thing that we can then hopefully share. So we have.

A

We have something for this in the container world, so in in the container world we have a docker file or something else to define the what the container image will look like. We have an OC eye image that you build, that into which is an immutable artifact that can be signed so that you can secure it, and we have OC I registries, which are which you can use to share these OCI images so for applications. Maybe we can do the same thing.

A

The definition part is going to be difficult because, as I showed you before, each of those different tools will have its own method of defining a definition. So maybe that part's- not not that easy, but maybe we can package these as OCI images, and maybe we can store them in OCI registries so that we can share them and not have to rebuild the infrastructure from scratch.

A

So, let's, let's take a quick look at the CNF specification itself: it's broken up into a bunch of pieces and we're working on different pieces in parallel because, as you saw before, there's a bunch of us working on this, the first three, so the bundle definition invocation, image and runtime are part of the core specification and these are nearly stable. We were hoping to stabilize them pretty soon. There's then the claim store, signing and distribution portions which are works in progress, so we'll start with the bundle definition.

A

This includes the common parts of the application that we saw before. So we have the metadata so things like named version description. We have a reference to the invocation image which I'll get to just now, but that's essentially the Installer. We have a list of parameters, a list of credentials and a list of executable images, so on disk, it's Jason and so you'll see on the first line at the top there we have the metadata. This is things like a name version description. We then have a list of the images.

A

These are invocation images, so these are the install images you can use docker images or something else. We come from a container background. So that's what we was reviews. We then have the credentials so you'll see here. We have something named cube, config, which will be mounted to a path that you can specify and we have parameters which is strongly typed, so you can validate them, which is great, so you can, for example, for reports.

A

You can set an integer, you can set a default value, you can set a minimum maximum and so on for Strings you can use red X and whatnot. It's really cool and there's some other things that you can store inside the bundle by Jason.

A

The next thing we have is the invocation image. So the invocation image as I said before, is the application installer, it's generally a container image, but it doesn't have to be. It contains the application definition. So let's say your cube: Y ml and the deployment ceiling, which would be your cube couple. For example, it has a specific filesystem layouts and a well defined entry point with required actions, so we'll dive into that.

A

Don't worry so just taking a look at what the the file hierarchy looks like you have something like this, where you have some definition, which is highlighted here so in this case, I've got a database which we could deploy with terraform, because it's a host a database and then some QB I mul that will just cube cuddle apply. Do you then have this run executable, which is what you need to make?

A

The entry points of the installer image, which can either have the tooling built inside or could just be a shell script that does something else. Okay, so now we have these two parts already. We have the bundle, a dot jason of the bundle definition and the invocation image. We then get to the run time, which ties all these things together, so the scene at runtime reads the bundle that jason or the bundle definition.

A

It then executes the image with the scene, ab action, injecting the parameters waits for the invocation container to complete and then stores the result as what we call a claim. So that gets us to the claim store. This keeps track of installations so that you can, you basically have a store of what's been installed and each installation has a unique name so that you can record the actions on each installation. So you could say what the last action was, what the status was, which bundle was used and which parameters were set.

A

This is primarily to make subsequent actions easier because it means you don't need to recess if I, which bundle you used, which parameters they were and so on, and so I think that's about high time for a demo in this first demo, I'm going to be showing you how to write a scene app from scratch. Just to show you how easy this is write. All of the demos are on github, so you can check them out later.

A

If you'd like I, don't guarantee they'll work on your machine, so it fits so here we have my demo directory I've got a make file just to make things easier for me. Oh you can't see sorry which screen do I need to put that on.

A

Let's eat that no right right, I'm, probably gonna, actually mirror. My displayer also won't be able to see anything.

B

A

There we go is that big enough for the people at the back good right, I hate demos when you can't read what's being said, I'll make it bigger anyway, all right, so here's what I have inside my directory I have make file, which just makes my life easier, so don't watch the commands. I have bundled up. Jason I have a tool named duffle and I have an invocation image folder. So, let's start with the bundle up Jason.

A

So this is pretty much the simplest scene. Ab you can write. You'll see that the schema version is the working draft of v1 I've named my application bundle. It has a description. So that's you know somebody finds it they can. They can do something with it. I have a version. I then have a list of invocation images which I'll show you how I built just now and I can add, maintain as and other metadata as well.

A

So if we look inside the invocation image directory, we'll see that I have a docker file and then I have a run tool with a main go. So that's all implication image. What I'm going to show you first is the docker file, so this will show you how the invocation image is built so I'm using a multi-stage, build it's very simple.

A

It's the first step builds a go program which is my main go and the second step just copies the results of that and sets the entry points to /c nav, slash, app, slash run, which is the standard scene, app entry point and I'll show you now the the go, the go program so in the first block of Const I have the keys for the environment variables.

A

So, as I said, the run time tool injects the action, the installation or the bundle name and the installation name as environment variables, along with some other things, so I've got constants just to keep track of that. I then have the three required actions which were install upgrade uninstall that for any application it Maps pretty well and then I just have some simple error.

A

Checking before I have this switch over here, which switches on the action, and so what it's going to do is when I install it's gonna, say hello, and when I uninstall, it's going to say goodbye, that's it so what I can do now is I can make my invocation image, which will just copy my commands. So I'll show you. This is just a simple like a build I'm tagging it for to push it to a repo that I have.

A

As I said. It's I've already prepared this demo to make sure it will work without the network so that that's not a very interesting part, then to install it. What I will do is I will get the install command so I'm using duffel here duffel is the reference implementation for scene AB. It's something! We've been developing along with respect to exercise the spec, in this case I'm selling duffel to install I'm, giving it a name for my application.

A

So the claim that we'll store it as I'm passing it the bundled up Jason, because it's going to read that so you find out which invocation image to use and I'm telling it that the bundle that Jason is a file and that it's insecure because it's not signed, otherwise it will it'll air out. So we'll see now it's executing the install action and we see hello coupon because it's gone through that it's run the image and gone through that go program in the same way.

A

If I wanted to uninstall now, instead of having to Reis Pesa fie, the bundle I can just uninstall it by name so there you go and that'll say goodbye, cube Khan. So that's that's! A the simplest possible hello world example of of C nap.

C

A

So, let's take a look at the hello at the ecosystem, because I talked a little bit about duffel, so the first tool is is duffel, which is hosted on the dais labs, github repo, it's the reference implementation and it's a CLI tool. So we use this primarily to exercise the specification and it's vended and a bunch of the other, the tools that use the CNF spec. We then have a duffel bag, which is a GUI tool for manipulating for manipulating C abs. We have Porter, which is an opinionated scene, app tool.

A

What Porter allows you to do is build applications that require multiple tool chains using mix-ins. So, for example, you could create something that uses in Azure database, but it's deploys a compose file somewhere as well, so that exists that uses that database and finally, there's what my team is working on, which is docker app and that's specifically, a packaging system for compose based applications, they're also a bunch of libraries that have come up.

A

So we have the go library which we all use, there's also a rust library, because that's that's vegetable, gareth rush grove, one of my colleague. What about old colleagues has ripped the Python library and our team bolts seen have two OCI which I'll discuss just now, which is basically a tool to push scene abs to OCI registries. I I met somebody at a talk on actually who works, Intel, who also wrote one with four node Jas, so I know there's even more than this that exists already.

A

So when we were developing a scene, apps I, we asked what can what infrastructure can we reuse and primarily because we're lazy? We just don't want to build things from scratch.

A

We also noticed that the OCI index is designed to handle a list of OCR artifacts, and we- and we thought about this a bit and we said well see Knapp, has this invocation image and a list of images. So this feels like a good match.

A

The problem with the OCI next is that it does not have a top-level type, so we need to duck type this to make it work, but the the overriding design idea behind scene out OCI has been, let's reuse, existing OCI registries and not require modifications, because it's it's just too difficult.

A

So this is a bit of registry 101, but basically how it works is that on the on the right hand, side we have our blobs. These are just binary bits of data that are pushed up that you push up to the registry. Everything inside the registry is content addressed, which means that when you store it, the registry sends you back and address. You can then combine those blobs up into things and reference them using what are called manifests.

A

So, for example, for layers you could just have about a list of layers which is a list of addresses and you store those manifests again as a blob which you can reference from the next item. So it's kind of like this chaining process. So this is what we basically did for 4c NAB's. Is we restore the the bundle definition as a blob? We then store the invocation image and then be 1/2 or 0 to n images that are required by the application.

A

That's all then stored inside, what's called an OCR index, which is basically just a list of manifests. I left out one step we actually support multi arch, which means that you can have the OCI index the route 1 is referencing lists of indexes themselves because original the OCI index was developed for multi arch. So the idea of you can have a Python image that works on Windows, Linux arm, AMD, etc.

A

So, once again, why we did this because it works with the existing container registries. This is a good thing. All the images are stored in the same repository, which means that it's drastically simplifies the security in our back, because, if everything's in the same place you guaranteed to get everything that you that you need for the application back, you also. We also have that because the digests are fixed, it's reproducible, so it's it's more secure.

A

So with that I think it's time to show you the real power of C naba, so we're going to deploy a more complicated application, which is something you would normally require multiple tools to do so, in this case, I'm going to be deploying open fast on my machine and installing a lambda in one step.

A

So this one I also wrote by hand, so this just gives you an idea that this is actually not that hard to do. Although people will be building tooling to make it easier. So here's my here's, my directory for this one once again, I have my make file to cheat for the commands. I have a bundle of Jason I have two tools: I have docker up and steam out, so you see I I have my invocation image folder and a pulled Oh Jason we all get to just now.

A

So let's start with the bundled up Jason. So once again, we've got the same schema version and the top parts are the same. The invocation image is different because we need a different image to install this application. It's a different application. I then have an image map, and this lists all the images that are required for my application. So I have open fast images and things that open fast needs.

A

I then, have this Python 3 Alpine image, which is used for my lambda I, then have credentials so I have a username and a password which will be mounted into my invocation container at runtime. I have two parameters: I have something to set the open, fast gateway that I use inside my other script and I have an image map, which is just a variable that I'm using to display the image map to show you how that works.

A

Alright, so once again, I've got a similar structure for my invocation image. I have a docker file. I have a functions folder, which contains my my Python lambda I'll show you that quickly and a run-run shell script, because that was the quickest way of making this work, and so I'll start with my docker file, this one's a bit more complicated. So it's once again a multi-stage docker file. If you don't use multistage, you should it's great, the first step downloads, all the bits I need for open fasts.

A

The second step is from docker: that's just referencing the docker image and then what I do for the run step is I just copy in the things that I need. So the great thing about multi-stage builds is you can build everything in one image and have all your bull chained inside that, but then leave it behind by creating a new stage and just having what you need for the runtime.

A

So here I copy the open, fast source, because I'm going to be I need that for what I'm doing I copied the fast CLI I copied docker it's the daka CLI tool, I copy my functions. Folder and finally, I copy my run dot sh script. To be the the run script that's used inside the C app, so I told you I'd, show you the lambda quickly, it's the world's simplest land.

A

It's simply an app and echo that will whatever you send it. It sends back. The more interesting thing is my run in shell scripts. So this is more complicated. This is actually gonna, be the thing that runs the install so you'll see at the top here. I get the scene, app action and installation name. You can ignore the image map part for now.

A

I'll come back to that I, create secrets, so I don't want to just store my username and password as as things inside the image I want to use darker secrets, so they've securely stored, I then install open fast over there. They open at the install open, fast step so I go into the correct repo I.

A

Do a darker stock, deploy with the name I then build my open fast function with the fast CLI I then deploy it well I sleep a little bit to make sure it's stable, then I log in deploy it and I write an installation done. The uninstall step is just removing all the pieces there. All right so once again, I can make the invocation image and it's the same as what the last command was.

A

It's just building that invocation image I've done it before, so it should be relatively quick there we go except what I'm going to do when I install this time is I'm going to use docker app as I told you. This is a specification and you don't have to use any one tool to exercise it so doctor app is the scene out compliant find the client, which means that we can install a generic scene ABS with docker app, even ones that weren't generated by it.

A

So in this case, I'm gonna, say doc: correct, install I'm gonna pass my two credentials. There don't steal my my password and I've, given it a name fast and I'm, telling it to use the bundle but Jason which I showed you earlier. So this is doing the same thing that duffel did before it reads. The bundled up Jason runs the invocation image and injects everything inside that's needed. You see it's a really creative, the secrets. It's now in story installing open fasts.

A

This takes a moment, there's a bunch of services to spin up after this, it builds the the lambda function, which is quick because it's just a docker build with the source code that I gave it on the Python 3 Alpine image it logs in to open fast and deploys the function. That's great, so it says it's done. Let's, let's check, if that's true, so if I got a localhost 8080, which is the the place that this is installed, you'll see that I have open fast installed and even better than that.

A

I already have the echo function installed. So if I had multiple things set up already, I could install all the functions at the same time and just have this atomic moving of the whole application in one go. I can test it from here.

A

By clicking the invoke button and that works, and obviously if I want to test it from the from the CLI I can do that too so I can just do a curl and that works. So that's that's all working.

A

I'm gonna uninstall it just using docker app again because the credentials are not stored in the in the claim, store, I need to repass the credentials each time. I do an operation, and this is just gonna run that in an install script that I had inside my run, dot SH but inside the invitation image. So you go. That's not installed so now that I've made this super useful application, which is just an echo function. I want to probably share it with other people, and so how would I do that?

A

Well, that's why we built scene app to a CI, so what you can do is you can push the scene app to a registry and what that does. Is it pushes not only the the information you have inside the bundle or JSON, but all the images as well into the same repo, and the reason that's interesting is, as I said before, it's reproducible. You now have everything in one place. It then returns a digest that I can share with other people. So so, if I want to print out what this looks like now,.

A

May have changed the digest. It did.

A

I'm going to download what the what the bundle of Jason now looks like from the information that we have inside the registry. So if we look inside this pooled blood, Jason you'll see that this is where the image map comes into play. So here we have this map, identification, image or sorry. The map of images over here, which has the key, which is the original name, and then we have the new image sha, so it's referenced by char, instead of just by name for the for the for each of the images.

A

We can then use this when we do the install, because when we install from the registry, so in this case, what I'm going to do is I'm going to be installing this application directly from the registry, so I'm not using the bundle of Jason now I'm, just using a registry reference, you can see. I've also set the image map to true. So this time it's going to print out the image map that I've set- and here you see I'm using the the reference that I had from before.

A

Although I think that, let's see if this one works anyway, so what this does in the background, is it downloads, the the manifest from from the registry I've included that variable which printed out my image map? So here you can see I have everything I need to replace all the instances where I referenced this image with this one, which is the one that's I've, pushed to my own repo?

A

It's exactly the same image what's changed here is that it's not fetching it from the the open fast, for example repo, but from from mine, because, like I, don't control the open, fast repos, and maybe that image gets pulled. All that tag gets changed. I want to have the same thing, and if we run through the steps, it's just done the same thing again and if we want to test it, we can just.

A

We can just run our our co-commander game. So that's working as expected.

A

Ok, so what we've done here is we have not only installed an application. That's much more complex than you'd normally expect we we installed open fasts on dr endpoints. We then built a function and installed it on that on that open, fast server in one step, we also managed to share this to somebody else using a registry that it already exists. I didn't have to write anything else and I think that's a really powerful thing.

A

All right so now that you've seen a little bit of how how C NAB works and what what power there is behind that. What's what's to come. Well, it's still very much a work in progress. We were still iterating on the specification to make sure that handles every use case. We specifically work to be done on the claim, store things like how do you handle distributed, claim stores? How do you share these applications? Management's of these applications there's a security aspect.

A

So how do we sign these applications in a way that makes sense in multiple environments, because it's not that easy for registries we have an answer is: is it the same for air-gapped environments or for IOT? And finally, the distribution part? What I showed you was synapse, ROC I, it's one approach to how we could share these these things by registries. We're also, obviously hoping that more people will be writing tools to exercise the C nap spec.

A

We want as many people as possible to use this, because we really want to be able to share these things and leverage other what other people have built. This ties into some conversations, conversations that are ongoing about outputs. So what we want to be able to do is understand what a scene ab has done, or so it can communicate to another step so that we can have dependencies. So if we have dependencies, you could do things like install a database and then have another scene AB that deploys an application that depends on that yeah.

A

So what do we need from you? Well, we need you to get involved. We have, as I said, we have open meetings every second Wednesday from at 9:00 a.m. u.s. Pacific time we have the spec up on github at this Labs CF spec. We have Twitter accounts and this website a scene app dot IO.

A

That has everything you need to know about scene app if you'd like to find out more right and all the demos, as I said in my presentation, or up and gets up if you'd like to grab them and and play with me yourselves. Ok, right thanks a run yeah.

D

D

E

Develops company so I have a question: can I use, yellow files.

A

Yes, you can so the application definition escena is wait. What do you mean? Yellow files for the bundle of Jason or for.

E

A

For the for the application- yes, you can so the the invocation image will contain. You can have llamo files. In fact, the one that I showed now does actually have a yellow file, because the open fast, like the deployment thing for the daca stack deploy, is a composer mol file. So it doesn't matter what you use to find your application. It'll work, no.

E

I mean definition instead of ji-sun. Oh, you.

A

Mean for the bundle definition you know, I, think red who has strong opinions about this is sitting over there I think it I think it used to be trouble at some stage and then it moved to Jason.

C

E

Second, question is: how can I keep my secrets in a secure manner, so.

A

Seen app doesn't handle that problem in this case, I use docker secret and you could easily use cuban eddie secrets or whatever else you are using. It completely depends on your application right, because, if you're deploying to cuban eddies, you could use communities secrets, but if you're, for example, deploying on iot, where you don't have an Orchestrator you'll, probably want to use something different. So it's it's kind of a lower level problem for us. We don't have a meta solution for that problem.

A

E

I can use secrets in decent definition, yeah.

A

So they it it'll, be down to the invocation image as into exactly how it does that. But yes, when it inside the bundle definition, you define what is sensitive and what is not. And then it's up to your installer to decide how to handle that secret information. Yes,.

E

So how can is URI.

A

We don't we don't solve the problem in our level, we're we're a packaging format. So it's up to the underlying runtime to handle the securing the secrets. Ok,.

E

F

Yeah sorry I'm a sucker, a walk in our esteem and actually years away. We pass parent rose to the invocation image. I I, don't know if it's already yet or it's still in progress. But what we do is we use a similar fashion as our cubelet inject service credentials.

F

That's it that's using a Tempe fess and a temporary file system in memory in the invocation image container, and we we just put that I in there. So it's not persisted on the on disk, just something valid ID and we also don't pass this button in the claim store for obvious obvious security reason. Yes,.

A

We do the best we can, but it's not. We don't manage the life of the secret. Afterwards. Sorry, maybe I misunderstood the question yep. We.

G

Saw the store and only stole functionality, do you have something like upgrade like helm? Do.

A

We have something like like.

G

Upgrade make sure you like.

A

G

Do you have something installed and now you want to put the new version there? Yes,.

A

So we have the three required commands, which I didn't show all of them: I ensured install uninstall, but the third one is upgrade, which is essentially the ability to to upgrade the application that could be changing parameters or credentials or it could be changing the bundle reference itself. So those are the three required ones. You can also add custom actions, so in docker app we have a bunch of custom actions like inspect and render, and some other things that are specific to our tool.

A

So that remember this is a specification, so it just aims to facilitate people building tools. It's not it doesn't do the actual tool. Building.

B

H

B

Want to know what happened with those application that needs an external resources to be there presently could be an s3 bucket or, and RDS database he's done away to deploy that interested to work with the application. Yes,.

A

So that's the point of seen as such. Is that it lets you do that it doesn't do it for you, but it lets people who are building tools so Jeremy who's sitting. Just next to you, it's actually solved that problem in Porter, but so basically what it lets you do. For example, as you saw in my my example, I installed open, fast and then I installed a function on top. In the same way, you could deploy a cuban eddie's cluster, deploy an RDS database and then install the helm charts in one step.

A

So it's designed to solve exactly that problem at the spec level. Once again, so the spec itself doesn't do it. I.

A

Didn't show the RDS database example because I don't trust the Wi-Fi.

D

Hello I see is that you used services. What can we use? Cubert entities, deployment or ports.

A

So this was just my example, because I did a darker stock deploy on swarm. You could do a darker stock deploy on Cuban Eddie's. You could do a cube. Cuddle apply with your own thing, I. It can be anything there's. No, it's not constrained at all. So at that it's you must think of Sina. This kind of like the msi of the cloud or RPM, where it's just a packaging format. It doesn't care what you do underneath. Ok,.

H

For sharing you say that there is a registry involved. What about if I want to don't want to use the registry, and and this can be used for the air-gapped environment? Well, I. Don't have a registry I have a scene that bundle, but I don't want to share with so.

A

That's still work-in-progress, it will probably depend on exactly how we store these in registries to some extent either we will have a well-defined tar format or we will use the OCI layout image layout because for container images we have the same problem, and so, if we use container privet set primitives inside registries to store these, we can just leverage the same solution for that. So it's still a work in progress, but we will have a solution for that. I.

C

Think how you define dependencies between services so in the database example I need the database running first and then I want to deploy something that relies on that database afterwards. Is that how you were talking about using multiple bundles or is it? Can you do that within one bundle as well? So.

A

There's there's both streams as such inside the bundle inside the invocation images itself. It's up to you to manage your own dependencies, so in this case I needed to get my docker CLI my fast CLI and everything else. There is work being done, particularly by the people working on Porter, who are more interested in. How do we link scene apps together? So you know what is this: what is the output of this one and what can be then consumed by another scene app, so this one provides a RDS database.

A

This one deploys a home chart and we can link those two together yeah. So it's two levels: yeah, that's it right! Thank you. Everyone for coming to my talk, I hope you enjoy this.