Breaking Tradition: The future of package management with Kubernetes

thank you everyone for joining us welcome to today's cncf live webinar breaking tradition the future of package management with kubernetes i'm libby schultz and i'll be moderating today's webinar i'm going to read our code of conduct and then hand things over to dmitry kalanin engineer at vmware a few housekeeping items before we get started during the webinar you are not able to speak as an attendee there's a q a box on in the chat uh on the right hand side of the screen so just drop any of your questions in the chat and we'll get to as many as we can this is an official webinar of the cncf and as such is subject to the cncf code of conduct please do not add anything to the chat or questions that would be in violation of that code of conduct and please be respectful of all your fellow participants and presenters please also note that the recording and slides will be posted later today to the cncf online programs page at community.cncf.io under online programs they are also available via your registration link you use to sign in and the recording will be on our online programs youtube playlist as well with that i will hand things over to dimitri so take it away hey folks um feels a little weird without all the little zoom boxes of seeing everyone else um but uh that's uh that i guess we'll do for now um well thank you uh or maybe later viewing this this talk i'm dmitry i work at vmware in the map bu unit mostly working on kubernetes but i i do have uh quite a interesting background you know coming from cloud foundry uh and you know before that working on various uh consulting projects with pivotal so today we really want to talk about kubernetes package management with carvel and specifically one of the carvel's project called cap controller carvel is an oss project sponsored by vmware um it was born uh probably around two years ago maybe um it's actually a toolkit um of various kubernetes related tools now some of those tools are generic they're not necessarily specifically written for kubernetes but they work well with kubernetes and some of those tools are obviously very much kubernetes specific so we have a little uh site there carvel.dev that actually lists out all of the tools and we are also talking about revamping that stuff to make it a little bit more um new user friendly so tell us what you think when you visit the website here's a slack pound caravel on the kubernetes slack instance we're very active there actually recently reached a thousand uh really excited for me seeing kind of a community grow over time um and uh you know we welcome anybody to drop in uh chat with us on carvel related questions or maybe even just how you use kubernetes we're always eager to learn you know what you all are doing um so one thing that you might have seen from recent kubecon uh is a talk uh by one of my colleagues chaterupa uh there was a keynote called breaking traditional the future of package management with kubernetes there's going to be a link that you can click in the slides and i'm sure you can find it on youtube uh the talk kind of talked about um what we have been up to within carvel community uh and you know what are some of our you know desires and visions for package management um so it actually serves like a good background maybe for this talk now this talk uh is maybe more of a continuation uh to kind of dive in a little bit deeper into the details uh and i actually love doing a lot of demos so i will be doing a lot of live demos hopefully things go go well but if they go wrong that's actually more fun than usual all right so one of the slides from that talk was this uh this specific slide um it was calling out declarative kubernetes apis immutable bundles uh distributor of oci registries and really picking the right tool for the job right and when i say the right tool for the job what i mean is being at the abstraction level that your problem uh deserves right so most users right don't necessarily have the same exact problem it's similar problems or or it's really kind of stacked up in different ways and so uh at least from my experience i think it's important to find the tool that actually solves your problem and doesn't actually do too much extra because if it does do too much extra then you know you're dealing with all the extra complexity or maybe vice versa right you found a tool that does bare minimum but it's not quite enough for your uh for your problem one of the actually other things that we'll we'll touch on is is is using oci registry as a storage system uh now obviously we all use ocr registry for container images but as you probably have noticed the industry have turned uh into using registries for variety of other artifacts and uh we also caught up on that trend i would say quite a bit early and are very uh excited in how we use the registries and how we deliver some of the software so let's um jump in into this last bullet point layered approach so carvel as i mentioned before uh is a toolkit right there's various tools and these tools try to follow unix philosophy what i mean by that is we want to have small sharp tools that know how to help you solve a particular problem and not do anything beyond that right and we have a collection of tools that help you with a configuration building for example the kubernetes configuration building we have a tool for example that allows you to manage kubernetes resources in bulk as kind of seen as an application uh you know we have tool that allows you to interact with registries and you know do interesting things with with the assets stored in the registries and there's a few other tools one of the tools um specifically we'll start with um is is cap cli cap cli is that tool that allows you to manage multiple resources in bulk right you can think of it as cube ctl on steroids uh we'll actually one of the first demos is to actually look at that tool and and you know deploy something with it um since i've said you know different problems should probably be solved at different levels of abstraction so capsule is really a cli that you get to use maybe yourself or maybe in your ci system but we also thought well uh there's definitely cases where it's much more useful to have an abstraction within kubernetes that represents the deployment of some configuration to your cluster right and that's what app cr is all about it's really meant to describe how do you fetch configure and deploy your application to the cluster um the next oops oh no oh pressing the wrong button all right the next layer that we'll actually talk about uh is uh two other crs package install cr and a package right so this is where we get a little bit into maybe more traditional um thinking around package management right so a package cr represents a piece of software at a particular version that you know that is this concrete thing and the packaging style is actually an intent to install that piece of software now as you can see over here we have a package installed arrow pointing to the app cr and that's intentional because we want to reuse the lower level abstractions in our higher levels right so we're not throwing away all the useful work that we've done we're building on top of it and you as a user can decide which layer you really want to be at and oh my god keep on pressing the upper arrow so all right the next final uh top level at least in our current stack uh is package repository and a package repository is all about delivering a set of package crs to the cluster right so similar to a linux distribution right a repository contains a collection of packages in our case a package repository contains a collection of package crs that could ultimately be installed so we'll take a look at this entire stack as we go along and see what happens let's dig in live alrighty so i'll um i'll jump over to my terminal here and i do have a cluster over here that's authenticated uh and i'm using cap cli to interact with this cluster right now right so what i'm saying is let's list all of the applications that we have installed to the system now we haven't currently installed anything so the list is empty and so if we go ahead and i've prepared a few handy commands to run for ourselves to kind of explore some of the stuff if we actually go ahead and deploy the sample yaml from um from github we'll see that cap is going to tell us what things we will install with this yaml right so the yaml is actually from one of our uh carvel uh simple apps running on kubernetes it's a little go app uh but in our case over here as you can see uh we have a service a kubernetes service that's being added and we also have a deployment uh that's being added and the deployment is pointing to some image that's been built somewhere and similar to tools like terraform maybe cloud formation you get this little nice diff right that tells you what are the exact operations that will take now one of the benefits of using cap is that these are the only operations that will be taken right so you know exactly what would happen to your cluster this gets a little bit interesting uh of course once you actually start changing the objects not just creating them and deleting them right so let's go ahead and actually press um confirm and uh we'll have our app being deployed here and it succeeded pretty quick and we can actually inspect what kind of resources got created so here i've used a simple app as the name so we'll say simple app and we will see that uh simple app now is composed of two uh six resources right deployment and service that's the stuff that we have put in and then the kubernetes cluster also added in the endpoints for the service and then you know of course the deployment got broken down into the replica set and the pod uh and etc so that that's the that's the basic of cap right uh you're able to for example go ahead and say okay i i no longer want this app on my cluster and you're able to delete it um and you know it will find all of these resources and get rid of them one of the you know maybe basics around cap operation is that we're not trying to do anything um outside of just the basic kubernetes feature set right we're not trying to hide the apis or anything like that uh for example the way that cap knows which resources are associated with this app is really a true label so all it's doing is it's generating a unique label and getting that deployed all right so cap cli you know could be used in your ci environments for example if if you're really pushing out the content to your uh to your cluster or maybe you are um i don't know maybe you're for whatever reason playing locally yourself right and gives you ability to converge this set of resources in you know in some kind of a um deterministic manner right rather than trying to hunt down which resources were in a previous version of the thing that you were deploying and removing it and whatnot so with cap of course you know so that was a simple little example right and you know we can of course cap is used in production environments to deploy more uh you know serious software and so for example here's an example of uh here's an example of cert manager uh from uh 161 release from github i will install that real quick as well uh just to showcase that you know it's it's it's happily deploying things uh it does show you a little progress log telling you what's going on what kind of research is getting implied you know some resources are getting applied in parallel so i'm not we're waiting for some pods to start up and whatnot but all in all all it's trying to do is just deploy converge um make sure that the resources are in a particular state and we'll go ahead and also delete the same thing so cap delete dash acm go ahead and say yes all right so that was a lowest abstraction level that we typically start with right uh very simple um now in our next example over here uh we're actually throwing in a little bit of a configuration um uh challenge right so uh let's take a look at this config right so this is the config that we deployed from the github uh and it had a service it had a deployment and it had something you know environment configuration going on there uh and a particular url now we also have a tool within um carvel called ytt ytt is all about um changing your data structures that are represented within yaml right via various approaches right some approaches uh that are allowed is templating for example another approach that's very common is overlaying and some folks for example mix them because sometimes the overlaying is much more useful for uh after uh the maybe environment specific configuration uh versus maybe templating is useful when you're uh still kind of uh reconfiguring your uh configuration in the first place right so uh we allow both of the approaches to be you know either solely used or mixed together found it very powerful uh when dealing with especially large amounts of configuration so let's grab that and uh do a little deploy over here so we'll have well actually let's see so we'll do a deploy over here and in our case since we're just updating the simple app that we previously installed um it's actually telling us that we're only going to change replicas to to be set to three and this is based on that overlay right that's saying hey we will set replicas on the deployment uh within you know the configurable that it found right so it matched this particular object all right so let's go ahead and say yes and i think to nobody's surprise you know if we go ahead and say okay get pod right we'll see that there's three pods now running versus what it was is one foot running before right uh nothing too complicated right so just scoping the discussion for a second to this two tools cap and ytt right you get a variety of possible usages right you could be doing all kinds of things with for example using other tools to generate the yaml but then doing a cap deploy or maybe you're actually uh maybe you actually gen using ytt to generate or modify let's say upstream configuration right if i wanted to tweak something insert manager yama that's been published with ytt and then maybe send that to cube ctl or some other tool for example uh mixing and matching is what kind of a brings the power to some of those tools right we're not trying to uh tell you what is the what is the entire uh tool stack that you should be using right we're really trying to say okay you have a problem on your hands we have this particular tool that solves this particular problem okay so easy so far all right let's get a little bit more uh interesting with um with maybe a non-cli option right so cap deploy is great you might be doing it yourself or maybe you're doing it in the ci that's all cool um some of our users uh do appreciate uh a github's first approach right and so for that we actually have a project called cap controller cap controller actually brings several tools together in a fairly opinionated way and that's what actually provides that stacking of the app cr to the package install to the package into the package repository so let's actually go ahead and install cap controller with cap deploy onto the cluster and i think we're installing the latest version of cap controller here from github i'll just go ahead and say yes you know of course you could be using cube ctl to do this but i'm just using cap deploy here and what we'll do is actually check out what is it uh doing uh inside this uh number three directory so what does app cr look like so actually that's not a directory that i wanted to take a look at which oh yeah maybe apps you are config map oh yeah that is the directory so um app cr is really composed of three pieces fetch template and deploy we felt like this is the right amount of balance that allows you to mix and match certain things right for example you might be fetching things from a config map in this case right so we have a config map that actually contains a bunch of yaml and overlay and you're able to combine it in particular ways so in this particular case you can combine it with ytt and finally as a last step you're doing a cap deploy right and so what this app cr is meant to describe is your way of deploying this application you can imagine right if you have a hundred apps it's very beneficial to have that consistency across all of them right they always get deployed let's say by app cr driven through git for example uh now node we also have a service account over here because appcr doesn't give you any kind of privileges you do have to bring your own service account so that the fcr will use it and actually deploy it so in our case over here we have a config yaml that we want to deploy so let's go ahead and do that the cap so we have a cap control already installed on the cluster we will actually go ahead and do a delete of simple app because that's where we're going to be installing through app cr so that hopefully gets rid of pods real quick here goes all right so we only have cap controller now uh and we will go ahead and apply the um we'll create a service account here so i'll actually copy this out over here we'll create a service account so that our app cr can deploy things and we're using in this example of course default namespace but you know this is not really namespace specific and so we'll go ahead and actually deploy our appcr right and a config map to our cluster here goes so cap is actually smart enough to wait for app cr to reconcile and you can actually see that that app cr reconciled pretty quick and there is some nice some nice status information that's available to you uh we have you know our spec of how we told uh appcr to do things but we also have the status getting that hey the deploy have succeeded and note over here the deploy that that output may look very familiar and the reason why it may look very familiar is because app cr actually internally uses cap deploy to deploy the application right so we're building on top of that lower primitive within this higher level now you also notice that uh the fetch step succeeded over here it it fetched some stuff from a config map nothing too exciting right and finally you know the templating steps succeeded over here and we do have this nice little handy inspect output indicating what's been what's been created so now after that appcr has succeeded you actually get to see via cap that simple app exists here deployed three pods over here happily running right um and uh you know we can go ahead and for example change something inside this config map let's say we want to scale it down to four and we'll go ahead and apply the same uh we'll even make it a little fancy here and show you that that's what we're changing here we're changing the replicas for yes and then the app cr should pick up it might have already picked up so okay get pod now there's four pods running right uh all right so that's the app cr level layer that we've been talking about and let me flip back to the slide real quick so we've covered the cap cli uh and then we're also covering right now the app cr um now let's take a look at the app cr that's a little bit more complicated than what we have right so what we had was just hey read some stuff read some content from a config map but that might be useful for maybe a local tweaking local development maybe even you can imagine building little clies that that that allow you to fill in the config map from your local resources more on that later maybe beyond the talk come talk to us about your use cases in the slack channel here's on the other hand a more complicated app cr uh that actually quite uh powerfully captures what most people want right so they have a maybe a git repository somewhere uh that contains some configuration and they want to be able to munch this configuration a little bit and then finally they want to deploy it right so same exact steps in this case though we're only fetching from git we're doing a little bit of ytt massaging for uh for that configuration we're deploying this right so let's go ahead and again we'll do cap delete actually let's do a just copy paste this we'll just do this here oh actually this is uh uh oh yeah that's true okay so you can actually see that it's changing from inline to get it's changing ytt from doing nothing to for example including a particular set of directories within what it fetched uh and then it's actually getting rid of this config map because there's no need for it and so that happened awfully fast but here it is reconciled we can actually take a look at this um and as you can actually see because we're fetching from git this time there is actually a little bit of handy information that's being included over here we're actually showing what is the uh what is the commit that it fetched uh and uh you know here you can actually see that it converged based on the changes right so previously this our config map was containing uh i guess a deployment in the service and after it's been fetching this stuff from the actual git repository there's been a little bit of changes and you can actually configure appcr to show you the exact difference similar how we're doing locally but at least in this case it's it's not it's not configured to do it and then we also have the little inspect over here so back to capital s here you can see we're back to uh back to app ctrl being now managed by the by the git source okay so that's a git repo with some yaml and uh you know nothing nothing too exciting uh because app cr is really somewhat agnostic right to the content that it's fetching right um and the split between fetching templating and deploying is really this powerful uh way of thinking about stuff right we can do all kinds of other things that you know a lot of the common use cases call for right so here we're fetching from a bitnami chart git repository at a particular reference we're actually saying let's uh let's do a little bit of helm templating this particular nginx values and this chart i guess uh supports the configuration of nginx server and then we're also on top of that so not just we did the helm template but on top of that we're also doing ytt overlay that allows us to change something that is not configurable in that chart so we are removing external traffic policy in this case and actually setting the type cluster ip on this particular service right and so this is a little nginx app cr and let's actually go ahead and grab that and deploy that all right so uh we'll go ahead and say so we are creating the nginx app cr we are deleting our simple app because i guess we don't need it anymore in this config and we're also applying the nginx values so let's go ahead and say yes to that so that may take a little bit since it's going to you know deploy the resources to the cluster fetch the images etc you can actually see well not quick enough i guess you can actually see uh incremental output uh as things progress right so uh we don't just update the status at the end we actually update the status as as the app cr reconciliation progresses uh and as you can see over here uh the nginx helm chart here was uh it had the deployment and the service and and the config map i guess nginx server server block uh and ultimately deployed that and supposedly there is some nginx running here yep there's engine export running inside the default namespace where i'm installing it so that's that kind of showcases right the power that you can really you know we could actually be uh within app cr you know there's like different uh ways of fetch things and so you could be using a helm chart uh directly to fetch it from the helm repository or it could be using git or you can actually be doing uh something that we've been doing at vmware more recently is also putting in configuration into the oci registry and actually fetching the configuration uh from what we call bundles from the ocr registry but the greater point here is that we're able to mix and match those things within app cr and that gives tremendous flexibility actually one thing um that recently somebody was uh was really appreciative of is the feature of being able to uh decrypt a certain configuration via sops uh as part of the templating section so we do have uh we do have a sops configuration that you can provide over here uh to for example use the age backend uh to decrypt some of the configuration that might be encrypted in your git repository and in theory uh you know if you haven't noticed here fetch is an array so you could actually be fetching multiple things so one of those things could for example be your encrypted uh you know credentials maybe right if that's how you manage your credentials in the production right so a lot of the flexibility here because a lot of people have different choices made for their production environments for their dev environments et cetera all right so let's keep on going here so the next example that we've got going on uh is an app cr that actually uses this concept of an image package bundle and so what exactly are these image package bundles well to break that down a little bit more maybe in a more visual way uh let's actually look at this slide over here i'm not going to press the present mode because it's a little bit uh don't see my screen so it's uh it's a little bit terrifying uh so we'll um we'll break this concept of a bundle into a few things right so to deploy something to kubernetes you need some configuration right now that configuration may come in different types of formats for example it might be a configuration that's a plain yaml manifest right it might be you know helm template it might be a ytt template maybe it's some new templating mechanisms that you know have recently been invented right now previously i've mentioned that similar to the rest of the industry there's a recent trend that uh let's use registry because it's such a common api now that's available everywhere let's use the registry to actually store content that's not directly container images so we've we've started doing that quite a bit ago with this tool called image package and one of the things that we've kind of organically grew is in image package is this concept of a bundle we want to be able uh to not not just to store the configuration of something but we also want to be able to reference other oci artifacts uh so that we can build up a graph of the software and so this image kind of tries to showcase that right so you may have some let's say yaml configuration file 2 yaml file 3 yaml but we also have this dot image package images ymo that references this other images that are being let's say referenced by this file 2nd file 3 ammos right now we do have another tool that actually easily is able to evaluate like hear the x number of images that you've been using and then actually create the images yaml for you but the general concept of being able to build up this graph is quite powerful what's even more powerful about this is that when we do this reference to another image it could in here be another bundle right so you can kind of see how we're building up this graph and image package itself doesn't actually have an opinion what's inside those images it doesn't even know right it just knows how to deal with oci registry references now these oci register references don't even have to be in the same registry right you know if you've seen for example uh you know you may want to push your configuration up into your registry but that configuration is actually pointing to the other registries uh maybe something to you know in gcr or docker hub et cetera et cetera because i don't know depend depending on your level of uh confidence with some of the external assets right you may be just consuming the external assets directly versus like trying to rebuild them yourself directly right so how does this actually look like when somebody is building image package bundles right well it actually looks very close to what you typically do with with docker commands right so you have this image package push that takes a reference and you also get to specify uh the content of the bundle right and so inside this my bundle directory you typically would have that image package bundle subdirectory that contains a little bit of metadata and the content that you want to put in there now one of the things that you could be doing now now that you have this graph of the software is you can actually take that graph of software and move that over to a different registry as for example a lot of users who really appreciate these features are the users who want to have an air gap environment right so they're able to say image package copy this bundle to a tarball and so that recursively grabs everything that you ever need and then brings that over to the other registry of your choice wherever you import your tarball that contains let's say 100 images and then you're able to plug that back in into let's say cap controller or i mean orienteer you may have entirely different set of tooling that you know that that you're using for deployment or something like that right um so that's that's that that's where it gets interesting right once you have this graph you can do cool things around it now more recently we actually added a functionality to also grab the cosine signatures um we you know we know the entire graph and so that means that we can actually check if for each one of the nodes in the graph is there an associated signature or multiple signatures right we can also start bringing in things like as bombs and um you know at the stations right uh it's really you know once you have the graph you can do all kinds of additional things that you know production system for example may want to take advantage of um and finally you know once you've carried that over maybe to your own registry or maybe you've you know kept the bundle in the original location you know you can always pull it unpack it into a directory this just unpacks the contents of the bundle directly like doesn't actually bring over all the referenced images or anything like that but it does give you a list of referenced images that you can take advantage of and you know put it in into you know consume it via you know some other system and actually use those references right now because we are requiring everything to be digest based uh digest referenced right we have that guarantee that your bundle digest represents the entire graph that it captured right so again you can you can for example cosine the bundle itself right and then uh that that effectively translates into the confidence that you're bringing over the entire thing uh and it's all exactly the same digest so that's a little bit of image package and so where does that leave us right so in our example over here we're actually using image package bundle i think this is one of the images that we use in uh in our end-to-end uh test suite for cap controller uh but you're able to download this bundle uh and then you know run some configuration munching on it uh cable is the little tool that actually inserts the new updated references and then finally uh you do the deploy here right and so if we want to actually apply that so we'll uh actually again i'll copy i'll copy this over here and so as you can see over here where we're adding our app cr that uh that uses the image package bundle we're actually deleting in this case the engine x related bits because i guess this example no longer needs it um and so uh first step right fetching we will take advantage of image package pool grab the bundle and deploy it and you can actually see it here again nothing too exciting again we're back to uh we're back to our deployed applications pretty quickly um so that's how you would use a bundle now what's interesting about oci registry is they do give you this you know location where you can find various things right and so once you get to that you can get a little bit fancy with for example your tags right so here we're saying use the particular tag right now but also for example if you if you really wanted to do this for a production would probably do something like you know k build through it and actually grab uh and have your yaml have the digest right to to be referenced to that exact image however in this example we're saying you know what we don't want to know which tag is going to get picked which image is going to get picked uh it will happen automatically based on this tag selection uh policy right so in in here we have semver as the way to decide what to fetch and so within this uh oci registry repository there's a few tags uh i think this one was using v1 this one will most likely pick v2 because i think that's what it is and so let's go ahead and actually apply that as well so we'll say i think it's that and so here we're changing to the tag selection we're also throwing in some ytt stuff not that it's really necessary but um so here it goes it goes in and image package will talk to the registry will figure out uh what's going on which which is the tag you want and so if we look at that app status we will actually see what happened here so you can actually see that it pick tag vo now by default actually we don't uh pick pre-release versions right because pre-releases are not necessarily maybe production man however you could uh you could add a little bit more uh configuration over here that for example says include the prereleases uh or maybe even even one of my favorite features maybe include certain pre-releases that have let's say rc in them right and so that kind of acts as a way for you to filter out like what what do you actually want your environment to be consuming right and in different types of environments you might be consuming slightly different artifacts right all right so that was an example of how we use uh more flexible fetching right to determine what you actually want to install right so so far we've gone through the examples of cap cli doing the deploy directly you are responsible for running the cap deploy right wherever you are right uh we looked at app cr that allows you to explicitly say concretely how to deploy how to fetch template and deploy your application right and cap controller will facilitate that continuously um by the way maybe i haven't made that clear sorry this is this is something that's been uh that's maybe been not talked about is that the app cr deployment process happens continuously actually for app crs the default is fairly short it's it's i think it's about 30 seconds or something like that right so this this loop if actually is happening all the time now there's definitely a few optimizations to react to the system in various ways more uh quickly but at the least right there is that reconciliation period happening uh and so if your artifact is changing right like you might be pointing to an origin develop here right and origin develop keeps on changing cap control will pick up those changes and redeploy them right at that you know at that time all right so app cr you get to specify concretely how to deploy something now in a higher level block right if we go back to our uh to our slides over here the next layer of uh this notion of a packaging style impact cr well sometimes right times users don't want to actually decide how to deploy something right they don't know maybe some other team is responsible for determining that maybe somehow they receive that piece of software so they want to not worry about it right and so that's exactly what package tr is about let me just kind of uh focus on uh this particular cr so we have kind package cr right it has a name ref name here and it has a version right so this is what's um you can think of it similar to how crgs have a fully qualified name right we expect each package to also have a fully qualified name right so that there is no funky maybe aliasing conflicts going on and whatnot and we also want uh a version to be provided right now this two pieces of information is is actually this this section and this section is what's required in package cr everything else is optional obviously it's good to provide all kinds of useful metadata to whoever is consuming this package crs but for our example here really the focus is the ref name the version and the template section now the template section is actually app cr type embedded in right so this is a similar pattern how the deployment in kubernetes embeds for example a pods pack right so this is exactly the same thing and this is ultimately how this uh how it gets translated is that package install that operates on the package cr that reads it in right through a reference it will create that app cr based on this template right so all of the functionality that you might have been using directly with app cr right could be interior used here right now for our own usage we have mostly stuck with image package bundles because they provide you that nice guarantee of immutability especially when pointed through digest right but you may for whatever reason want to hide uh what a piece of software how the piece of software is actually being installed and maybe that software is being installed from a git repository at a particular git show or something like that right or maybe just continuously changing right um so that's the package cr right and once it gets loaded into the system right you can now use package install to install it based on a ref name based on a particular version selection now no the version selection kind of sounds like that tag selection that i've previously mentioned in the app cr well it's actually backed by the same little struct and what that allows you to do ultimately is allows you to specify the policy of which version do you want to select right and so because the package crs are actually uh require you to have versions to december format you get to potentially put in some interesting constraints here that have your system automatically evaluate and kind of maybe keep things updated continuously right so let's actually go ahead and install this package cr to our cluster over here so we'll grab that and uh we'll do oops unauthorized well that's unfortunate i think my session expired for the cluster let me stop sharing for a second let me real quickly reload my token here apologies for the little pause maybe a coffee break for anybody watching and let me grab the appropriate configuration here [Music] uh it's going to be one second just keeping it real with the live live demos that's right i was kind of you know i i did the refresh my tokens and whatnot uh right before but i wasn't actually sure how long and when they expire so there was a calculated bet that hopefully maybe they last an hour but i guess they last a little less alright so looks like looks like i'm back so let me screen share again all right hopefully we're back so as i was saying we're going to run the cab deploy and here it goes again all right so here what we're doing is we're adding a package cr to the cluster we have an app over here and we have a package installed and in fact what's actually going to get a little funky here is that both packaging style and app they're called simple app here and so let's go ahead and actually still go for it but because package install installs the app it might get a little uh confused if you will so let's uh let's see what's going on over here so oops um so so we have i i guess it's finished all right and so uh still was pretty quick we have the app uh that simple app and we also now have a package installed oops is it not package install like that i actually don't recall what it's supposed to oh it must be package install yeah uh the shortcut is uh the the short name is packager and i've been using it for for long enough to remember the la to forget the long name all right so we have a version two that's been installed and we have the app that ultimately the package install created as a result of this package cr now we also have package uh record here right that's the thing that we imported version two uh here is it in its yaml shape and form and it actually tells you uh all the information that we saw in the yaml actually one thing i forgot to mention was uh the little section over here in the package yaml that i hidden away is the little values schema so you can actually know what potentially your package is exposing as configuration we'll get to that i think in a moment so uh package install successfully installed version two sounds great nothing fancy again let's move on maybe to the next example then so in the next example what we have here is the following so the package install can be configured with certain values and unfortunately i think this this example doesn't actually showcase the values that it's uh how it's configuring let's say maybe this one yeah so here's an example of for example um packaging style allows you to specify certain values and this values are referenced through a secret and inside the secret right you could be dropping in you know that configuration so this is very you know exactly the same actually as the app cr in fact the secret reference will make it down into the app cr that gets created now on top of that some things are not configurable true values right like well somebody authored some software and they just don't have uh they just don't have a certain configuration up that you really need in your environment right uh that's ultimately how we actually you know why ytt for example includes templating and overlaying because we do see that 80 20 match between 80 of templating let's say and 20 of overlaying right especially in production environments where with different kind of ways of configuring things so in this example we're saying package install please use uh this secret as an additional overlay on top of this package so that by the time gets installed things get modified a little bit so um in this case we're actually say setting replica 5 in our overlay and right now there's only three pods so if we go ahead and think again i have real handy copy paste so i'm cheating a little bit over here i'm using this dash p um dash p flag and what that means is actually don't try to delete anything only do the create or update actions which is handy if you're just kind of iterating on stuff and maybe you don't want to provide the entirety of the config every single time and so as you can see over here the diff is add the little overlay um on the package install and we actually have well our secret is hidden away from us because who knows maybe it's sensitive information uh but the overlay yaml uh includes uh you know setting two five replicas and so if we go ahead and uh cap deploy this uh hopefully a few seconds later we can see that now there is five parts instead of three parts right so our overlay is actually modifying our overlays modifying the underlying package in a particular way right so this is a really great way to adopt something from let's say upstream right but you don't necessarily have um you know ability to modify it and you don't want to fork it you don't want to you know do something special just for yourself right so you get to use the overlay to override uh and add in your opinions all right so uh here's another example package install of nginx um it's not that exciting i would say since we've already seen app cr taking advantage of that nginx so if you actually look at the package yaml you can actually see that this is a straight copy of that app cr put it in here wrapped in a package cr we give it a name nginx testcarvel.dev version one right and in package install you're saying i'd like to install version one of nginx test carveldev right and you're providing those values so given the time where i think running a little low here i'm just going to skip over this example and maybe jump uh straight through this example of package repository our highest layer so in our picture over here our highest layer was package repository and maybe you can't really argue that it's a layer on top it's more of a wrapper since a lot of let's say users might be consuming a lot of versions of the software right how do you distribute your package crs right well you could definitely throw it in into let's say an image package bundle or a git repository and have another app cr that keeps on updating your cluster totally uh valid way of using it but we figured let's actually add a higher level concept package repository that allows us to specify where is this repository uh located through you know the fetch section right and ultimately being able to install things from that package repository right so an example of this would be so let's go ahead and delete our app over here so this is deleting the package installed the package the overlay so we'll just go to kind of a clean nice uh world here so your ghost finished so if we go ahead and say capital s nothing here right we only have cap controller installed and so we'll go ahead and apply the step nine over here step nine here it goes actually that's a step eight get step nine so we have a package repository and a package install let me go ahead and say yes right and what would happen oops what will happen is that if we look inside our cluster the package repository brought to this three package crs of different versions right and our packaging style actually decided okay i'd like to actually install version one now there's actually a few variations i put in here for just the sake of uh entertainment here so this is how you specify an explicit version but you may actually specify just give me the latest thing right we're not specifying any constraints right so in this case the latest thing would have been 200 right versus 1 0 that i explicitly selected and remember i said that we don't actually do rc uh or we don't do pre-release builds right and so minus rc is the pre-release build so you could actually enable it and say okay well actually get me the latest uh any build uh or see you or not right so that's that uh one thing maybe worth mentioning real quick um really running out of time is okay well package repositories right who's creating this package repositories well recently um one of the teams was in vmware tanza actually uh made a uh opened up an open source project called tanzu community edition right and so an example of a a real package repository uh comes from uh folks uh uh from from those folks over there a really great job at uh um at uh making that all happen so if we go ahead and say uh cc f and i think it's 9.1 tce tc yaml i'll just go ahead and add this repository here real quick so we'll go ahead and say yes and give it a few seconds here and so previously we only had this set of packages right now if we go ahead and say show me the packages inside this namespace we got lots of different packages right now as you can see here uh we actually have multiple versions of cert manager that the tc community has uh uh included in uh and you can actually see package metadata which is kind of a more combined view it doesn't have any versions or anything just the package names and so you can see we have search manager contour etc etc right but this is just an example right and in addition to our other repo that brings in some other packages you know from from our earlier examples um i'm now going to go and uh do maybe an install of cert manager i think you all got the point already that it just all it is is a standard now api was in kubernetes package installed something right and it's done so we'll uh we'll maybe get back to the window over here so the last slide i had was you know please join us in the carvel slack we love the discussions we want to hear your feedback when you hear your ideas carvel dev is a also a good starting point to find out more about all these carvel tools uh and do do tell us the suggestions of how we can improve any of this stuff what are your use cases and how we can be helping you potentially solve those use cases uh and i'm going to uh i guess uh flip over to the to the chat over here and see any questions here that might be worth calling out and by the way if anybody wants to discuss their questions further uh jump in uh jump into the carvel slack we can we can discuss there too uh so what do we have here so hello from slovakia hello from brazil hello all hey hey all to you too um hello from prim is it prem or or is it perm from france uh just to level set package management with skates that will be discussed here is fully upstream compatible not being very timezo specific yes absolutely it's all oss uh it just happens to live within a vmware tanzu uh github organization but it is a just like all the other projects contour you know valero they're all open source uh anything you can uh you can take to uh to use yourself um and that's been already replied any insight on difference between argo cd and cap well cap cli is a cli right that allows you to do that deployment so it's a little different in the sense that argo cd is a system to to it's a higher level system right so arguably one would want to compare argo cd and cap controller uh that goes a little bit into we feel like uh the feature set that we have uh and the way that the apis are designed is more kubernetes centric rather than argo cd and we also like the laying that we've got going on uh on top of the cap cli the app crs the packages etc so that's that's our take on it um and uh and possibly this helm and customize huge topic uh we do have some notes in uh in the ytt documentation how we feel like ytt is comparing to some of them uh are these atomic operations can we add custom template engines tools uh so some folks try to extend a little bit we do want to work on out of the box extensibility a little bit more but we haven't had a chance to actually collect more feedback from a community do come over and uh uh tell us uh from uh uh tell us in the slack channel uh you know what kind of what kind of tools you would wanna extend what kind of what kind of integrations would you look forward to or maybe how would you want to extend those things and by the way i think i realized your name was uh prem now that wasn't the location so hello um all right uh we had a need for oops uh something uh uh hey squat package is amazing thank you thank you for that um vmware tca supports cargo pack i have no idea about vmware tca but uh i'm sure we can find out that answer for you um we have a need for the combination of customizing solves great to see you're considering it yes i think you know so we got the integration for already customized we don't have it yet but we definitely like to hear the feedback of how you all you know would like to use it what kind of features customize hat does have a lot of features and there's definitely some considerations in how it's best to expose those features but otherwise we're open to ideas all right so i'll leave it i'll leave it at that uh come by to carvel channel uh glad you all could make it and uh thank you for for joining thank you so much dimitri and thank you everyone for joining with a great turnout today everything will be online shortly as well as the slide deck and catch us again next week for another round of live webinars and live streams and thanks again thank you

Channel: CNCF [Cloud Native Computing Foundation]

Views: 1,773

Keywords: kubernetes, carvel, vmware, cncf, cloud native

Id: us3NhfUfIFk

Length: 60min 43sec (3643 seconds)

Published: Tue Nov 09 2021