 Welcome everyone to config s code by Nilesh Mewada. We are glad he could join us today. Without further delay, over to you Nilesh. Thanks Bridgen, thanks a lot. Welcome folks, welcome to the session on code configs code, the worry free config deployments. In this session, I'll be talking about problems with configs text. And then I'll be talking about the solution using dial, which is configs code tool. And in the end, if time permits, I'll basically try and address the question and answer session questions and try to address those as well. So before we start, let me talk about the typical code and config combinations that we see into most of the projects. So essentially, you know, I'll be, I'll be using PHP and engine x configurations that as one combination during my presentation for Java and spring. We would have, so if Java and spring is the backend system, then we will have application properties and the Kubernetes configuration that can go along with that code. So just to give a quick understanding on the configurations, this is how the engine x configuration looks like. So it is essentially a simple text file with a nested and hierarchical structure being it. So it being a reverse proxy, it can handle, you know, things like, you know, HTTP request handling configs, it will have log formats, it will have, you know, load balancing configuration, performance configuration, etc. Moving on the Java config that I talked about. I think most of us already know, it's a simple, you know, list of key value pairs and it can, you know, contain pretty much what the Java app would require to run it. Right. The Kubernetes configuration also probably most of us are already aware. It is a YAML file. So that itself means that it's a nested structure. It will have, you know, configurations such as, you know, where are my continuing ages, the repository locations, the old hardware configurations, health probes like, you know, start-up drop, readiness drop, linus drop, etc. So we have looked at the different config files. Let me also talk about the environment workflow that I'm going to discuss during this presentation, throughout this presentation. So, you know, it's a very simple setup that I've, you know, considered. It's like a local environment wherein, you know, developers basically create, you know, code and the configurations. And if you want to deploy those code and conflicts, basically, they have to run, you know, what you see on the right-hand side, the three environments. It is like the integration environment, which is system integration test environment wherein we, you know, combine different components and see whether the wiring is, you know, correct or not and we test that and then we move ahead to the pre-prod environment where again, we do, you know, some sort of a sanity test, etc. You know, PT, etc. And then if everything goes good, we basically go to the production environment, right? So if I have to, you know, give the holistic perspective in terms of the typical CI CD flow, in terms of the environment workflow that I just, you know, talked about, here is how it looks like. So we have the local environment. As I said, you know, the code and conflicts are basically, you know, checked in the grid or any VCS for that matter, which essentially, you know, triggers a particular built pipeline. So we are talking the CI CD pipeline. So CI flow will basically trigger on a commit, which essentially, you know, creates a code and a config artifact for us, right? In general cases, the config artifact is basically part of the code artifact only, but just for the simplicity and to explain things better throughout this presentation, I have kept them as a separate entities over here. So let's assume that we have a two code artifact and the config artifact separately created by a built pipeline. And if you want to deploy that in the environment workflow that I just talked about in the earlier slide, we basically, you know, add this combination into an environment first. We test it. If it looks fine, then we, you know, introduce the same combination into the next environment and so on. And that is how we ultimately reach to the prod environment. It is basically that we test this config and code together into a particular environment, right? So that is the main point out there. So having talked about, you know, different engine X, so different configuration files, you know, a typical CI CD flow and the work environment flow. Now let's, you know, start looking at the configs text, right? And how it basically influences our typical setup that we just talked about, right? So why it is a configs text? First of all, let's clarify that. It is configs text because all the configurations that I just talked about, right earlier, those are basically text files as simple as that. And we basically, humans are basically managing those text files. And in configs text, since we have, so for each environment, we will be having a separate copy, right? So for example, local will have its own copy of the country. And so is the case with the site pre product. So just to give the clarity, if we are talking about PHP engine X combination projects, we will have PHP code plus we'll have four, you know, copies of the engine X configurations, one for each environment. And similarly for the Java, for the Java projects, we'll have Java code plus four application properties, one for each environment. And KDIS configuration for each, for KDIS configuration for each of those environments, right? So now having this particular setup for managing configuration, what are the problems you see that might happen if you can add it to a chat box? Copy paste errors, yes. Correct. So yeah, most of you are right. I mean, all of you are right in fact. So let me run through those problems once again. So as everybody has mentioned, you know, duplication is one of the prime problems. It's like, as you can see on the screen on the left-hand side of that, you see a broad config, broad engine X config on the right-hand side, you see, you know, pre-prod. And as you can see, there is like nearly, you know, 93% duplication in this. And so is the case with, you know, the Java application properties that we see. And so is the case with the Kubernetes configuration as well. By the nature of how we manage this config as text configs, right? We generally, so we have such huge files to manage, right? So generally, as humans, we basically, you know, try to copy paste to manage all these different versions of files, right? So it naturally falls into, you know, having some sort of a copy paste errors. So something like, you know, pasting, pasting at the wrong place. So as we see in this example, we have pasted something before this operator rather than after it. Similarly, we might have a problem of, you know, pasting it multiple times. Like in this example, we have by mistake pasted it couple of times instead of just once. Similarly, we might, you know, might be facing a problem like, you know, forgetting to, you know, press control key while pasting. So how we do a typical copy paste is control C, control V. But just in case while doing control V, if you forget to press control, we might see, you know, problems like, you know, having this letter V, you know, spread it into our config files randomly. It is quite hard to spot over here, but then yeah, this is also one of the problem. On the similar lines, again, if we, the cycle is like control C, control V and control S. So after we paste, we basically save it. And again, in that case, if we, you know, forget to press control key, then we will have this letter S also, you know, appearing into a configuration file, which is also might create a problem, right? Another one is like, you know, having a wrong values. Like in this case, instead of rolling update with double L, we have a rolling update with a single L, which is a, which are like the misspelled values. Another, you know, common problem is like, we forget to add update or remove a particular piece of config into other environment config files. Like for example, in this, on the left hand side, we see that there is one block that was supposed to be part of a pre-prod configuration. But then in production configuration file, we basically, you know, forgot to paste it, right? Just to summarize, we talked about duplication problems. We talked about typical copy paste errors like pasting at a wrong place, pasting with multiple times, missing to press, you know, control key while pasting or saving, you know, misspelling values and forgetting to add or update, remove a particular entry in the config file. So having talked about this, right? Do you think, so these are the problems, right? But do you think we have any more problems to deal with when we are using CAT? Just think about it. I'll take a quick pause. The answer is yes. We have more problems to deal with. Actually, all the problems, you know, all those misconfigurations that I just talked about, that basically, you know, ends up creating a havoc when we basically hit this particular step into CI CD pipeline. So it is like a release pipeline. When we hit release pipeline, you know, we are dealing with, you know, a code and a config, a misconfigured config. And we will only come to know about this misconfigured config at the time when we deploy our code, right? So, for example, let's say that when we deployed code and config into SIT system integration environment and we tested and everything worked fine. This combination basically worked fine into this environment, right, for the test that we run over here. Now, when we reach, when we promote the artifacts to pre-prod environment, the same code artifact with the pre-prod configuration, it did not work well. It gave a surprise and it, I mean, because it was misconfigured by mistake, you know, it is basically failing. So we can get all those surprises. So let me talk about all those problems now. So, yes, as I just mentioned, we might get, you know, unpleasant surprises while doing this deployment. So even though we see green, you know, all the test go green into lower environments, we might find problems into higher environments. That essentially means that we have to resolve those issues, right, the deployment issues. And that might, you know, result into extended downtime window, getting the approvals, et cetera, which is the case in majority of the organizations and it is not a pleasant experience in my opinion. Again, if this deployment, basically if we cross the threshold time to deploy or resolve the issues while we get during deployment, the next step is basically to roll back by deployment, which is also not a pleasant experience because we'll have to go through this entire process of, you know, deploying this code in config once again, all over again, right. The worst of the lot is basically the last problem that you can see is basically we were successful in deploying to a production environment, but with the wrong config values and we never caught those particular error, right. That is the worst of the lot because that basically means that we might, you know, get into a situation with some random errors coming at some point in time in the future, which we are never aware of, like something like, you know, random crashes because probably we missed, you know, correctly configuring the thread counts, et cetera, or we might, you know, experience into, you know, user basically not experiencing the way, I mean, the behavior that was expected, right. So all those, you know, random issues might drop in, which we call it as a production once, right. So these are the typical problems with the config as text. So what do you think is the root cause of the problem if we try to minus config as C-A-T way. Again, I'll take a quick pause if you just, you know, try to reflect on that, right. So let me run through it. The main problem over here, as I just mentioned earlier as well, once is that we have a different copy of this configuration files for each of these environments. So when we basically run through this particular environment workflow, right, the idea is we test this code and config into a site in one of the environment, lower environment. But as we reach the next environment, we get the different copy of the config, which is never tested before into all the earlier lower environments, right. And same is the case with the prod environment as well. Once we reach over here, if this is misconfigured, we have never tested that particular piece ever before. And that is what the problem is, right. That is the root cause of the problem. So how do we solve that problem, right. The idea is essentially, we should have a single source of tools for all this configuration files. What I mean by that is we should have a single source from where we can create all this configuration files for all the environments rather than managing a different copies of those, right. For that, essentially we use config as code as a tool. And what we do into that is essentially as we write code like Java code or PHP code to create your business functionality, right. Essentially we write a code using the CAC tool to generate this configuration file. So it is basically a code that we managed rather than the raw configuration files that we managed. So let me show you how do we do it. Let me show a demo, quick demo of that. So here what we see is we have this production. So I'm going to show this Nginx configuration. I'm going to create this configuration, Nginx configuration files for two environments. One is the production. The other one is the pre-plot environment, right. Now, let me actually go through a bit of Dal details. We may not be able to basically cover in the interest of time, but then let me just go through it. So in Dal, basically we have this small, small functions that we write to create a particular. So this particular function is basically responsible for creating a small snippet into this particular configuration file. So similarly, we have this set of files, all these files, which will ultimately together will create the final file for us. Each one of them will create a separate snippet. And ultimately we will have the final configuration file. So let me run it for you. So let's say, you know, we created for a production environment. Okay, first of all, let me basically get rid of this existing conflict, right. So let's get rid of this existing conflict now for the pre-plot as well. I'm deleting those. Now let me create this. So as we can see, this is the Dal command to create this text configuration. And we are creating it for the prod environment. And we are directing that output to the prod-enginex file. Let me hit the enter. And yes, we have found that, as we can see, we have actually generated the enginex config for prod environment. Similarly, we would be, you know, doing same for the pre-plot environment as well. So as you can see, I'm using the same command, Dal command to create a text configuration. But this time I'm using a pre-plot environment to create it. And I'm just, you know, directing that output to pre-plot-enginex config, right. And again, as we see, the pre-plot-enginex config has also been populated, right. So this is how we basically, you know, generate the configuration. So just to, you know, recap on that. We, so we use Dal. We use those Dal commands in the build pipeline to create this code and the config artifact. So instead of managing it manually, this is basically a CSE tool, which basically creates all these configurations for us. And how we are addressing the problems of cat is like this. So duplication is gone because we are basically using the code. So as we manage the backend code, we manage this using the simple functions and structures and that promotes visibility. So there is duplication is gone. Again, copy paste errors and, you know, other errors are basically gone. It's gone out of the picture because it is the same code that is going to create a config for us for each of the environment. So if it is creating the right file for one environment, it will create for the right file for the other environments as well. Typing errors might happen, but the idea is that we would be able to cache those errors earlier in the environment. So basically, instead of the late feedback, we will get a earlier feedback. And yes, Dal basically provides more benefits. So there are a lot of benefits as, you know, listed over here. You can basically get more, much more information on this particular site. So basically go to dallang.org and you'll find more information about it. So that's it from me. I hope that you enjoyed this particular short session on this. Thank you, Nilesh, for sharing your experience with us today.