Should We Template or Patch Kubernetes Manifests? ][#Helm vs #Kustomize side by side comparison]

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
and with that we'll go ahead and get started so should we template or patch kubernetes manifests uh customize and help serve the same primary function both allow us to define applications and more uh in a more flexible way than using kubernetes manifests however the way helm solves the problem is very different than customized so which one is better which one should you choose uh so victor farsig is going to show you in this hands-on comparison and with that victor take it away okay let me put my whole uh face in front for now i will do the demo soon uh for now let's uh very quickly write what we're doing basically essentially if you're using kubernetes and i hope you are because 2021 uh you need to define your applications one way or another defining application is only using kubernetes yaml and applying them only using cubecattle does not work simply because we always need something else whatever that something is there is always some change in one environment compared to another uh ingress host might be different the number of replicas might be different from one place to another and so on and so forth there is an unavoidable need to be able to have some differences between your manifests depending on environments and especially if you're using third-party software then you definitely need to customize that because almost nothing ever works out of the box without a single change somewhere um so we need we cannot use directly kubernetes manifests with cube cattle we need something else and the three main players that i know of at least to allow us the ability to modify customize adapt manifest depending on situations is helm customize and what is the third one uh jsonnet right now i will not go into json today unless you ask me uh so we're going to see how customizing helms solve specific problems and that problem is how do we define and apply kubernetes resources in kubernetes clusters now before i proceed one very important thing here is that help does many other things that customize doesn't do unless you ask me and you can and then we can go through it i will not go through additional features today i am unless you ask me focused on the ability to to manipulate our definitions our kubernetes manifests and apply them um in our clusters right and i will be by default ignoring additional features either of the tools might provide again unless you ask me so so what i will do is that i will now share my screen and uh i have here two terminals so i will be doing some hands-on parts just to show you how that works and on the left side here will be help and on the right side will be customized so you will be able to see both in parallel how they are defined how they react how they work and then we can comment about the differences and potential use cases when you might use one or over the other now before i proceed uh a short in case you're not familiar with one or both of those tools you probably know helm already but anyways the major difference between the two is that one and that is helm is a templating mechanism it allows us to create templates that are converted into kubernetes manifests before they are propagated to cube api and then kubernetes does something with them customize has a completely different approach customize uses pure kubernetes manifests without any templating option and it applies patches as a way to customize to modify the default behavior of those money pure kubernetes manifests depending on specific situations and those patches are very similar to what you would accomplish by executing cube cattle patch and then some long json except that in case of customers those patches are declarativeness and define these files in yumbles or jsons installing it and so on and so forth but essential difference is that help templating engine customize pure kubernetes manifests with additional instruction how to apply them in kubernetes so uh we are going to go through a few different scenarios first one is to begin with always we need to define our application right what our application is now here i have already uh created like in this director i can show you here here i have template this is not good minus one will work better i have a chart here on the left side it has typical chart uh templates and few different values files depending on the environment i will use and in templates uh are i didn't complicate the life of everybody this is a simple demo because i want to prove the point rather than go into something amazingly complicated it's the same definition of a simple application has a deployment an ingress service english actually and the service on the other hand i have customize that is basically if you go to this directory uh provides here the same thing deployment ign ingress i have additional namespace just in case here servicing customization customization you can think of it as equivalent of uh helm values file which i will show you later if you're not familiar so the first difference uh if you're defining a new application in helm on one hand we need to predict uh in advance not necessarily in advance but we need to at least try to predict the permutations that we might have with that application with that chart and as such for example if you look at helm template seeing this you will see that this is a typical english definition except that it has certain certain placeholders for templates so instead of hard-coded name it will be switched to the name of the release that is gotten from the helm command and more importantly here for example uh since i could not predict what will be the host in advance where this application will be deployed because it might be different hosting staging than a production i created a value here or a template snippet let's say that will allow me to specify what is my host right so this is pure templating it is using go templating for that now equivalent of that in customize would be this now you will see that there is no template here pretty simply because at the very very early stages i did not need to template anything with or i don't need the capabilities of templating with customize i can just say hey this is going to be pure uh yaml format because i know that whomever needs to modify it later can apply a patch patch and i will show you later how that patch works but for now i'm more concerned how it will look by default uh and then later on we're going to see how we can customize now i have a question oh brilliant go shoot all right so from sudesh if helm is templating and customizes manifest can we embed customized manifest as a part of helm charts to use templating features uh yes there are i i haven't used it much myself but there are ways to basically what you can do is you you can have a a helm chart that you and you can use help template command something like this help template and that would convert your this command would convert your your hemp chart into pure kubernetes and then you can use that as as customizable and do whatever additional operations you you you want to do so you can you can and and i've seen people i haven't done it myself much i haven't seen in sufficient reason to do that uh but i've seen people do it especially if they're transitioning from one to another and so you can com use chart convert it to uh kubernetes yaml and then use it to use it with customers to do additional changes whichever changes you might need thanks victor that's the only question for now but keep them coming everyone brilliant uh where was that yes english right now uh so in case of uh helm now since i already i showed you right here english i need to have additional uh values that will be converted into that this template will use to to convert it into final value so i have this here in uh helm values dot yaml and if you if you focus on sorry let me put a bit of space between if you focus only on english ignore the rest uh i can see hey english host here is defined as helm.dev2kitseries.com right and then if you want to apply bo uh i'd both of those uh on one hand i would do hem um upgrade uh install i never use helm installed directly it's a silly command toolkit helm uh and then i would specify namespace would be helm dev and create namespace right since this is the first time i install i'm installing it and i will have that template converted into yaml pass to kubernetes api and something is running in my cluster over there now with customize customize doesn't even customize is intentionally focused on one thing and one thing only that is to generate kubernetes manifest so you cannot use human customers to deploy something to uh to apply something to kubernetes it is just about creating final manifest for qb api so the command would be i'm going to create a namespace i forgot whether i defined it in customizer no so uh just to be on the safe side i will create it anyways so uh to do it with customize it would be customize oh customize build customize base this is where i have the the files that i showed you before and then since customers cannot deploy anything anywhere uh i would need to pipe it to cube cattle dodge namespace uh customize dev and apply file name dash right so customization relies on cube cutler whichever tool you might be using to communicate with kubernetes uh to do the actual work of propagating it to the api uh what did they do i'm missing e here we are area the end result after all this is the same i have my applications running uh in in my cluster we can see that cube cattle dash and uh get namespaces uh cube cattle dash and uh helm dev get all for example including ingresses and you see it's deployed and similarly i can do cube cattle dash and customize dev get all dot dash a comma ingresses and i get them right so the end result is the same how we get there is different now when we think about it if i focus now only on this only on the initial definition of what i need without ignoring what comes afterwards and we're going to talk about it customize at least in my opinion is much easier because it allows us to focus on kubernetes yaml which we need to focus no matter what we're doing and we can skip the whole templating you know putting curly braces in different places and then values and all those things it's just pure kubernetes it's so much easier on day one we're going to get to what happens later but on day one it makes it so much easier as a way to define it initially victor i have a couple questions is this a good time yes yes every time is good time you mentioned transitioning from one to another a few uh another a few minutes ago from which to which are people transitioning these days i heard from people moving uh from uh i know cases of people moving from helm to customize uh but that's personal experience i cannot say that that you should not think of that statement as being that nobody moves from customers to to helm i just my experience with people is that if anybody moves from one to another that's from home to customers but that's my personal experience i don't have data to back the top there might be the other way around as well choose which one is right for you right that's what this webinar is exactly so and rasmus asks couldn't cube cuddle dash k some files be somewhat considered deploying something directly with customize just without the advanced release management in helm yes but this is the state of cube cattle dash k is uh is a very bad one a horrible one uh so what happened and i haven't checked it last for a month so the situation might have changed but basically uh they included the the team behind customers including the customers library into cube cattle so that you can use customers directly from cube cattle and then in considering only that you are absolutely right that would be considered uh also the ability to deploy however the customer is included in cube cattle is an old one i think that the one in cube cattle is two point something and the one in customers is three point something don't call me for versions i'm not sure whether but anyways uh i'm not using it myself because it's quite a lot behind and uh as far as you know nobody's trying to fix it because there are some issues with the conflicts and what's or not and basically nobody's working that i know of on uh getting customers inside of cube cattle up to date now whether the features that are available in your one are important for you or no would lead you towards using directly cube cattle or customize i tend to use customers simply a binary simply not to think about the potential compatibility issues what i can what i cannot do and stuff like that and one more question before you move on um this is from lolita if i want to give customers a deploy tool from a dashboard in an assigned kubernetes cluster namespace which one is useful helm or customize along with get offs both are from guitar's perspective both are equally good let's say uh i prefer keeping if if when using helm uh i prefer keeping my charts in a git repository not in some chart repository you know chart museum or what's or not because that gets me closer to those manifests it's easier for me to inspect it there than in in a chat museum or whichever other registry you might be using but other than that from guitar's perspective it doesn't really matter whatever you're more comfortable with and whatever is more useful to you outside of the scope of githubs uh so i drop i wouldn't make my decision whether to use one or the other based on the relation with githubs both were worked pretty fairly well with both argo cd and um uh flux right two major players in in that area so either make a decision independently of githubs and you will see a couple of other examples that might help you soon uh make that decision sounds good that's all the questions for now thanks victor brilliant okay uh so now that was day one right and in my opinion customers is easier simply because i don't need to think much about much about templating variables whatever i just have purely now uh if you think about if if you start if you go let's say today what they do and start thinking about how will that application be deployed in different environments let's say development and production staging whichever environments you have you need to start introducing variations between the manifests you're using now in case of helm those variations are basically one example of those variations would be this right here i have a different uh ignore the commented parts they will become important later imagine that nothing that whatever is commented doesn't exist uh train your brain to ignore comments in this case so let's say that in production i want to use a different host address for my application than wherever i deployed it few minutes ago right so in case of cal i would i would create a new file with values that would overwrite the default values and i would say hey use the default value says they are but when deploying to production i want you to overwrite the default value of ingress to be host and this value of the host like here on production.okitseries.com right now the same thing in customers would be that i would before i showed you the base directory now i'm showing you a different directory directory can be anything uh there is unwritten standard that we specify additional environments in overlays and then some name so i have here a customization yaml inside of directory overlays production that contains specifics for my production environment remember in case of helm those specifics are all part of the same chart now here uh to accomplish more or less the same result what i'm telling customers hey use those jumbo definitions that i showed 15 minutes ago but add the namespaces additional thing which is production namespace and i want you to patch the ingress i want you to use this file to patch my english so english stays as is that yaml file that i showed initially it stays it is but we are going to modify it uh and we are going to modify the one that is based on networking kubernetes io ingress and the one called devops toolkit right so this is customer's way to say hey i would write like to patch that specific resource that is defined in this file um and that patch itself looks something like this so this here file that i'm using to patch is like this basically i want you to replace specifications rules the first entry and then the host and i'm intentionally showing you more complicated example than the simpler one majority of patches are potentially easier to grasp than this uh so i want you to overwrite this spot in that english definition and to put this value right and then if you want to apply those things uh i would do scam upgrade install uh devops toolkit helm is the directory and i want you to do it in a namespace uh helm production and i want you to create namespace and what else do i want you to do uh yes and i want to use this new set of values all that are going to already default ones which are in this file that i showed before right and we hit enter uh and that's it right now in case of customize it's this almost the same as before customize build what was it the directory is i sorry my bed customize build and the directory is customized overlays production and we want to pipe it to cube cattle apply that dash file name dash right and the magic happens now and this is all my personal opinion which might differ right if you're talking now about shifting left enabling developers to who might not necessarily have a lot of knowledge and understanding deep understanding about kubernetes helm approach is much easier because you can say hey you don't need to worry about the chart all you have to worry about is this file to create the file and say which values you want to overwrite and that's it now if i would if i would give the same set of instructions to to somebody who is not really proficient with kubernetes for customize explaining potentially uh how to how to create a new customization is potentially more complicated i mean not potential it is more complicated now from developer perspective manipulating values file is so much easier now from the perspective of somebody who is writing those definitions in this specific scenario i'm not sure um on one hand for chart you need to predict in advance what will be the all the permutations you need customers on the other hand allows you put to postpone those definitions and and just apply patches for specific uh situations personally to me from the perspective of this admin patching is easier because it's simply for me easier to to comprehend what is going on without too many curly braces templates and so on and support but i can understand that even from sis admin perspective or a perspective of somebody who is proficient with kubernetes hell might be equally simple or equally complicated from the definition perspective and as a user as a developer there is absolutely no doubt that yaml file uh values file changing just few values you never need to know that there are jumbo files involved it sounds much easier and more user-friendly victor i have a few questions yes please all right let's do it if a microservice is having its own db which one will be better to use does it depend on the factor of having db or persistence volume uh i'm not sure i understand the question is the question uh related which one whether customizer help to use or i think so i'm going to guess that but but let us know this was anonymous so let us know in the chat um if we understood that correctly yeah so i will assume that yeah which one refers to helmer customers uh it it really at the end result is the same i don't think it really uh the decision depends much whether it's a stateful set that will have persistent volumes or it's a deployment it's more about what makes it easier to manipulate uh uh to actually to create definitions that will ultimately allow you to generate yaml uh pure yaml one way or another so i don't think it really depends much on on whether you're using a database or not thanks victor and he did confirm that that was the question so thank you for that and the next one is um isn't it more complicated using customize as it requires a more in-depth knowledge of cute cuddle than in helm which only relies on one specific definition for the resources yes yes that's kind of the point which i was trying to make before that from a perspective of somebody who is not very experience with kubernetes helm is definitely easier because you can just go and say hey i know nothing about deployments and services and ingresses and all this stuff tell me which values i can change i'm going to change those values and off i go basically anybody can understand that there is a file with some properties values that you modify to customize uh how you work with something and so from in experience personal perspective uh let's see i'm gonna call it developer even though we are all developers we all write code today uh uh helm is easier from perspective of experienced at least in my case i feel that customize is easier so kind of like it's it's been some lose some because you cannot really have it all uh customize allows me to do things that that i believe are harder uh in helm than in helm but at the cost of making it difficult for those who are not very familiar with kubernetes all right we have a few more questions for you if you're up for them now the next one is great um how can the configurations on the cluster be rolled back to release which was um which was applied two patches ago using customize yes so uh i strongly believe that uh today we shouldn't be applying directly uh rollbacks no matter whether we are using cube cattle directly or customize or helm or json or any of those things today i believe that we should be controlling those things by uh storing some definitions no matter the format in git and if i want to roll and the head of my master branching it should always represent the desired state that i want the cluster to be in and that means that if i want to roll back i will either make a new commit that will be the same as two comments ago or i will revert the comment in git uh i'm very much focused i i'm strongly believer that nothing should be neither rolled back nor forward that we should never change state of the cluster directly like what i'm doing right now i'm doing this only for the demo in real world situations i do not execute customize this i do not execute custom hem debt i always store the manifesting git i have process that converges that stating it into into the the state of the cluster that the actual state uh this is only for the demo i hope that that answers your question just if i misunderstand the question you keep them coming and i will i will explain better and then one more question from sadesh um customize looks like a tactical fix mechanism where helm looks like a more strategic fixed mechanism where it comes to kubernetes do you agree can you share your views uh i'm not sure what tactical fix would be uh i think that they are all flowed in different ways one is less user friendly the other one one is more complicated for complicated stuff uh what one example that uh where i think that the differences between helm and customers become more apparent is when we use third-party applications right on probably everybody in this call has at least one application that is deployed with helm or customers hopefully or will soon have uh that is a third party so now what we're having if if you jump into third party applications let's say that you want to install prometheus right i'm just inventing now example you go there and say this is the helm chart of prometheus excellent you change five values in uh to make it uh work as usual as you want it to work let's say that you change one value to the to decide what will be the cost of prometheus uh ui and off you go you're done like this if you want to do it with customize you will go to either prometheus already have uh he has customized definitions i'm not sure and i would need to check or if he doesn't it's very easy to convert your you xiamel into customers that's that's two minutes work anyways but if you want to change english it will take more time but here comes the here comes the big difference let's say that uh you want to use that prometheus uses allows you to change the host value a third party up of the ingress that is based on nginx and let's say that in your cluster you're using istia just for the sake of argument and that you don't want any ingress but i mean you want english but you don't want engine extinguishers of any of those things you want is your gateway to manage the incoming traffic to your um to your prometus ui and that's third party right you cannot modify it what can you do you can fork that and uh change it uh to include this to your gateway but then you will have problem upgrading right you can create a chart that has a your own chart that has a dependency on prometheus chart but that's clunky and really ugly uh basically you don't have a good solution for that or maybe to manage that is to get with the outside of the chart of prometheus which which also complicates things a lot now if i would be using customers for that same example i would say okay i have customer accurate customers jumble it goes to istio prometheus definition uh wherever it's stored i don't even need to copy it to my repo i can reference specific tag uh in prometus repository and i'm going to apply this patch for example or no i i wouldn't need even to apply the patch i will just add uh in in that customized example uh second entry in resources and say and on top of all that i want you to uh apply this different yaml that is easter gateway so it's much easier for me to extend third party apps to exactly what i want but in cases where the existing values that are already thought through by the community in this case of remedies are not what i need now if what prometheus gives you if prometheus gives you what you need then the kelm is definitely easier because you just changed few values if it doesn't give you what you need then customize becomes easier and you probably you will not probably notice that i don't have the answer that applies to all the cases which one is better i'm just trying to give you different use cases because i myself use both and depending on situation one or the other i have several more questions victor you want to hold them for a little bit and continue or keep them rolling hey if you if i can keep them rolling as long as there are questions i like answering questions more than showing the demo that sounds good so as a cloud infrastructure engineer the product devs are the ones who are our customers and want to be able to create new microservices and update environment variables for companies using customize how have the product devs felt about it uh for uh that's the thing i i feel and again i'm talking from personal experience i don't have the industry by data devs tend to be happier with help uh but uh infrastructure engineers tend to be happier with customers and uh and then we have a problem right kind of uh do you make yourself less effective by satisfying others or do you make yourself more effective uh by not satisfying enough others that there is the balance that is very hard to um like the example with tremeters to me that's a clear winner even if devs are going to suffer a bit and you might actually devs might never need to know about prometheus and i see a lot of cases lately where people use both and depending on the use case uh for one use case choose help the other one customize but yes devs are happier with help uh tend to be happier that helm and what you call cloud infrastructure engineers happy with customers thank you and i victor i might have you look at the q a for the next question um if you could pull open just your q a button just because there's a code example um so jersey asks why not simply patch using a partial manifest instead of using targets and he's kind of shown an example here uh is that uh jurassic yes yes okay okay okay uh let me see the patch blah blah blah yes yes yes uh i i definitely want to show a bit more complicated example even though it yes this would be easier to to do actually uh yes your example is easier than mine i just wanted to show something that is a bit more kind of like freaky let's say and for that simple application couldn't find anything that really justifies it but you caught me yes that would be easier uh in the follow up later if i have time i have an example with actually here let me put on a screen so that everybody sees uh if i look at if i look at to change the deployment with customize i would have something like this this would be equivalent of the example you pasted right where i'm modifying a deployment with this name and just modifying the first the container called device toolkit to add those things that did not exist before uh in um in that in that deployment imagine that somebody forgot to put it or that was not needed for anybody but but that specific environment or something like that i think that this is very simple similar to the example you you put uh i'm butchering the names i think it was juank or something like that okay and i have another question from mehmet um how good is argo cd in terms of ci i mean to release new versions and keep different versions across multiple environments like dev product et cetera so how good is our concept in terms of cr so argo cd is not ci uh argo cd is not i think the target city has terrible name it should never have been called argo city because i i believe that's very misleading because continuous delivery is uh is about automating the whole process of from committing something to get pushing something to get repository until it is running in production uh sorry see that would be cd and ci would be part of that process anyways uh it's a bunch of steps usually defined in a pipeline uh i don't think that that's what argo cd is doing what uh argo cd is doing is that it is only only working on the deployment part right i have my definition in git i have an agent in my cluster that is monitoring that git repository and whenever i change my manifest whether it's customized helm pure kubernetes json it doesn't matter uh argo cd will fetch those changes in applying it to the cluster so that whatever is in a cluster is the same as the desired state defined in form of manifest in a git repository so argo city is doing only deployments now the fair comparison uh the the better question would be how good is argo workflows in in terms of ci or cd for that i mean in terms of automating pipelines or workflows that you have in form of automated processes and in that case the answer would be that it's absolutely awesome uh argo workflows if i would replace your question argo cd video argo workflows in that question i would say that argo workflows is one of the very few that are kubernetes native uh pipeline slash workflows type of tools um and i i it happens to be my favorite right now thank you victor a great round of questions um we have about 18 minutes left so if you want to continue with the demo and then we'll see if we have some questions at the end cool so now uh another one of the many other scenarios that you might run into is let's say that that i have something that nobody thought of uh that i need and i need it only in one environment only for me for me not for the rest of the team not for the rest of the company i need change that applies only to me now in case of helm uh if i let's say that only for me even though it's a very simple silly example i want to add resources to deployment but only for me remember that's important part of the story now uh if i would do that in helm uh first thing i would probably do is imagine this is not commenting that i'm writing it right now i would need to add a few values in the yaml file like i want to add resources and i would always always always need to set it to a nets have a value like enable false because if i'm if i want to apply changes that are only for me i need to make sure that i'm not affecting others so my major occupation in that case would be how do i introduce changes to the chart without affecting others so in this case hypothetical situation i would have enabled false remember that valuable and some data whatever that data would be empty by default and then i would need i'm going to copy the snippet from uh from this thing imagine that i'm not copying this just because i'm too lazy to write the next thing i would need to do with uh in that scenario is that i would need to go to the chart i would go to uh the deployment and i would need to add something like this to my existing deployment right uh and this this is where things over time become potentially ugly uh i would say hey first of all if the value of resources enabled if the value of the enabled variable is set to false do nothing because like my the last thing i want is to affect everybody this is only for me so do nothing and but if i in my specific case set this to true then do something and that something can be many different things in this case add this section resources and then uh convert some value to yaml and indent it by 12 or you know there may be different scenarios basically i start down the path of having potentially many effects statements and things like that uh because i cannot affect others now um and uh in case of customize that same scenario would be exactly the same as uh as the one i i had before so i would say um i would uh create uh like this deployment patch that is only for me nobody else this is the one i showed when i was answering one of the questions and say hey whenever i choose so apply this patch and this plate patch will find a container called devos toolkit and add these resources and the only really apart from writing that file that the only thing that i would need to do is go to overlay's production customization file i have it here commented but basically i would write those two lines here i would say hey i want to apply a patch the patch is defined here that's it that's what i want and this is only for my overlay for my environment for my use case nobody else i'm not touching the base um the base manifests right in the case of helm the last thing i would need to do is uh because remember the values file that i showed before where is it here this value which is default values i set data to nothing enabled false because this is not supposed to affect everybody but i cannot not have those values defined and then i would create one that is specific to my environment which would have basically these entries that would modify the resources variable to contain so enable true and um data would have the all the resources that i want to define whatever i want to inject in my deployment right and this now again can be interpreted in many different ways right uh it and it really greatly depends on the preferences uh when it's personally when things are planned in advance when we know what we want in advance i've i i tend to find helm easier but on the other hand when uh when there are things that need to apply only to me or to a limited number of people uh the ability not to touch the base manifest and customize is potentially awesome uh this might be the first webinar i did in a long long time with where i didn't give a clear use this i almost feel uncomfortable not saying customize is better or helm is better but it really depends so i was more gaming towards showing you how differences between the two so that you might be able to [Music] draw your own conclusions i can give you personal preference i i'm more and more using personally customers instead of helm but that is under no conditions recommendation that means that customers is better it really depends more questions i guess yep we have one more question and keep them rolling guys we have another 10 minutes if you have any questions for victor pop them in the q a button using your zoom toolbar so from oliver one thing that bugs me for customize is the amount of repetition of code like the first 10 lines are in deployment patch.yaml have little to do with the resources being added what do you think victor yes that's absolutely correct uh i mean i i would even go further i would say that generally kubernetes in general has a lot of repetition uh uh probably like 30 percent of manifests are bloated unnecessary things that are not really uh i mean in this case this is an example where i'm not really using a real manifest but it would have a bunch of labels that are repeated across all the resources and annotations across the all the resources stuff like that so uh i would answer that with yes to begin with kubernetes has a lot of repetition but if i focus now my attention between uh customers and um with helm you have let's say potentially unnecessary efl statements and conditional logics while in customers uh depending on the number of patches you have you have that repetition that you always need to specify the path towards something that you're changing right in this case this is basically you can con the highlighted part actually what i have highlighted right now is basically a pot towards the part of the manifest that should be changed and that's could be considered in a very repetition yes all right and another question from rasmus my main point that brought me here today is i'm trying to avoid helm for certain reasons but customize can get so wordy if you're trying to change tiny things uh like an app label name in several places or a single value like the cpu limit using both is an interesting option to use a values file for changing values but does involve helm again what are your thoughts so i personally don't use i use both helm and customers but not for the same ups let's say or same definitions i i tend to go for one or the other uh but i have friends or acquaintances let's say that they're using uh both in combination that they would it's what i said before that you they would convert helm using some template into yaml and then do some customized things uh but personally to me that that always sounded like a last resort that might not be worth the effort thank you and i have a question from joshua helmsman is a great tool to run on top of helm as it requires less in-depth knowledge of helm and cube cuddle is there an equivalent tool for customize i don't know because i haven't used helsmann myself so uh the best thing i can do is write it down in my to-do list first to go through it now now independently of what helsmann does which i which i'm not familiar with um i haven't used tools on top of customize so but that does not in under any way under any condition means that there aren't any it's just that i haven't been looking for them um so this is embarrassing i cannot answer the question sorry for that if anyone's familiar please feel free and shout out in the chat um and then he let's see why do you personally prefer customize could you elaborate a little bit more victor yes uh i somehow feel and and it's important that i'm using feel uh word feel feel more comfortable with having not having templates in my declarative definitions of something to be honest if i would be going for templating solution i would be more inclined of writing those definitions let's say go directly than in then in helm that's my personal kind of my my brain has a conflict with uh seeing templates in declarative definitions um so i prefer keeping it either very decorative or which is i think customized basically uh and avoid templates all together or when i'm using templates i personally prefer them going uh going straight into into into a language into into whichever coding language you prefer and just spitting them out from there personal and we have a couple more questions next one is from charles um on the other way around if the base deployment.gamel contains resources or environmental variables and i don't want them only for me is it easier with help wait i need to read one more time on the base deployment channel contains resources in environment and i don't want them only for me uh i'm richard understood the question but so i'm going to try to ask the same question different way just to see whether i understood it uh so uh before if the deployment already contains resources environment variables sorry the chart already contains all the things you need and those things are uh needed only not only for you but for others and if it already contains all the stuff yes helm is much easier to use if that was the question if i just do it right because if you if you have a chart that has everything you need uh and all you have to do is to change values helm is easier without a doubt thanks and i just want to highlight a comment joshua made in the chat here he said he's heard a few people asking about using helm to template customized files as an alternative to helm he's used ytt for customizing yaml files both related to kubernetes so if you want to check out that link go ahead and open up the chat and then from oliver another thing that is not possible with customize is to make it explicit how values are iterated uh for example a port might be used in several places in the ammo with helm there is an explicit uh via the value being reused in customized it is implicit do you agree yeah with with yes with customize so the way how i think about it is that uh with helm you decide in advance what is modifiable right this does not mean that that cannot change over time but basically for vast majority of users you don't go through uh hem templates values are your alpha alpha and omega right uh with customize you are forced in a way to go and say hey okay so this is the yamaha those are the finishes this is what this is what they want to change this is how i change it which is much more complicated i mean uh or easier depending on the level of understanding of those things right like uh i i really there are many cases where i just especially with third party i just use helm and i still use it even though i'm slowly switching towards customize i use helm because it's easier hey i want that prometheus i'm going to change host that's it but on the other hand i had many examples of third party charts also where i need to start going into the templates to understand what it really does and what i need and how i should so the moment i start going into templates to start checking uh understanding things because the moment values file is not enough for me i'm already starting thinking about customize as long as values is fine uh and gives me what i want or very few changes in templates uh then templates come in my personal opinion tends to be easier so it really uh at least in my head the the major question was always do i need to go to templates to understand do i need to go to templates or no if i need to go to templates that to me that starts being more complicated with templates and helm uh and as long as i can i can get away mostly with values then yes i stick to helm myself all right i'm not sure if they answered your question just if they didn't ask enough yeah answer yeah oliver just post in the chat if you'd like him to elaborate any further um while we wait for yep he said yes thank you uh so perfect thanks victor um if y'all have any more questions we have a couple more minutes but in the meantime i want to remind everyone to just follow codefresh on twitter linkedin or facebook you're going to hear about all of our upcoming events and especially talks from victor you even have a podcast coming out thursday or friday which i will post as soon as it's available so make sure and follow us so you get all of these uh great talks victor talks many different places not just here um on our webinars or suggest a webinar suggest what if you have a subject i haven't said that in previous feminists if you have a subject that you're interested in let us know let me know and we'll organize a webinar or something and talk about it just let us know what you want to know absolutely you can send that directly to victor v farsik on twitter or you can just reply to my email that i'm going to send you with the recording those are both really easy ways so whatever you prefer if you have any ideas very likely we will make that webinar happen for you so it seems like that is all the questions for today and we're just about done with time so victor thank you so much this is an awesome side-by-side literal uh comparison webinar here um so we hope everyone will join us next time uh please look out for my email with the recording and uh yeah if you have any suggestions for upcoming webinars please reply to me or reach out to victor so thank you so much everyone for joining have a great rest of your day and we'll see you next time on code fresh live cheers
Info
Channel: Codefresh
Views: 563
Rating: 5 out of 5
Keywords:
Id: Q19x62ZrR-U
Channel Id: undefined
Length: 55min 48sec (3348 seconds)
Published: Wed Feb 24 2021
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.