Roberto Freato: K8s Automation with Azure DevOps: A GitOps Approach w/o Tools

In this talk, Rob discusses a personal approach to enhancing DevOps practices for development teams, drawing on his background in software development and data engineering. He emphasizes the importance of transitioning to Kubernetes for better infrastructure governance and connecting development with operations. The speaker introduces the concept of GitOps, highlighting the process of managing application configurations with Git repositories to maintain the desired state of Kubernetes clusters. He outlines a simplified pipeline that automates code building, Docker image creation, and deployment, making it accessible for developers unfamiliar with Docker and Kubernetes. Rob also suggests a framework for generalizing pipelines to streamline the deployment of multiple applications, allowing teams to gradually develop their DevOps skills while keeping initial implementations simple.

[Music] hello uh thanks to be here I'm Rob and today I'm going to show you uh a personal approach okay that I really support uh for teams uh that want to be in the devop stage okay I am a former developer I usually develop few things still but now I'm still of a company and I'm trying to to guide the Strategic guidelines of all the technical teams

that are inside this company so I'm trying to make to connect the dots and uh my background is from development to data part so big data thata engineering and of course devops so what I'm going to show you today uh let's start with this uh few assumptions okay uh I think that Kate is uh really crucial for model application so uh beginning with like three years ago

something like that we decided to move some workloads on cabetes because it was easier for us to um make all the things together and govern all our infrastructure so it's really important that uh many uh developer teams that are now not using cabetes they should move or um just evaluate it in production okay uh theop said something that probably was born like 10 years ago as a

movement but I really trust I really uh believe that this is the a crucial point to connect the development team with the operation teams in terms of skills okay what I want to um uh to to share with you is that in my personal opinion a devops guy the perfect devops guy is someone that is like a former developer that has gained much experience experience in the

development ecosystem and services and then also connected us with the production okay so uh unfortunately some teams are not really aware with the devops ecosystem which is quite huge in terms of tools in term of processes in terms of uh many things in terms of skills okay so this uh approach that I want to share with you is to reduce the curve the learning curve that you

should have with the devops word ecosystem uh why because there are many tools that uh divides you as a developer uh and the um the the production and the cabern side okay so this approach as the myone that um this common um principle that uh stands for many uh modern it um areas that is start symol okay so uh the desired process in a uh giops approach

is like this one okay this is maybe it's a simplified version okay in this slide you can see uh the get comit on of your code okay that probably will trigger a build okay an automated build in case of failure okay developers are notified but in case of success probably this uh build art fact is like um left in an artifact repository okay may have could be

like a an mpm a nougat package or also like an artifact store that is internal to your devops too okay after that probably uh another bot is building the docker image itself and publishes to the image registry okay and this is the starting part of the giops uh the giops area okay when a new image is available uh you should probably update the Manifest of youro uh

to be ped into cabetes and after that something may CH may may happen like uh PR on the giops repository uh or the giops tool can detect the change and try to push to push into Cabernet is the new uh manifest the new yaml to sync the cluster State uh here in this in the slide we have two uh main uh important aspects okay one is the

the coupling between the code and the giops so the code is like uh finishing here okay and the g the gitops part starts here okay and the second part is the concept itself of giops okay uh one of the main concept is to have like a repo like a place with all your manifest of your all your application manifest that is continuously sinking with the Cabernet States

so think about the main pillar of gith hubs is to have the state of your cluster outside Cabernet so in like a repository and something okay like tool that sync that state with with the desired state so uh let's say that what is in the git repo of the Manifest should be also in the cabetes cluster okay starting from this uh assumption uh you may have so

let's step back okay and you may have a team that uh is uh not so aware of the docker ecosystem okay so in that case you can probably commit your code into your git repository and the build engine will build your code after that okay something is started to build the docker image to be pushed into the cabetes ecosystem this is the scenario that I want you

to uh show as the common scenario when where developers are not so aware about all the stuff that needs to be known to go to cabetes uh in that case of course you will um sorry I Chang the slide uh this is the scenario where you're are not so aware so you are committing your code you are building uh and testing your code outside Docker and then

you build your IM image otherwise if you are aware you will probably build a code and tested inside Docker so inside Docker image you can perform all the building part and all the testing part but to do this you should be aware of docker and you as developer you should prepare the docker file with all the uh desired steps to um build a code and uh to

script it okay to run inside the docker engine uh after that we can go to the cabetes part okay when the docker image is on the registry you can update your manifest uh to and you can optional you can perform some modification some adjustment in terms of new features for instance if you want to promote your application to a web application or map a custom domain for

instance uh you should all you should probably uh put your ends inside the yaml that defines the Ingress part the ports part the domain mapping part so this is here after that you can probably create a pull request on another git store that is the gft store where the Manifest exists okay and with the optional pipeline of review and merge you can then go to the production

part uh all this stuff can be done with Git with GitHub of course with many git tools with some other uh tools that are like Argo CD influx um not influx sorry git flux okay so uh that's why I think that it's not so easy for newcomers to uh understand the big picture and go going straight to the production line so my uh proposed approach is to

start simple so uh this is like a monolith okay in if we think about microservices okay microservice are often compared to the monolith the software the monolith software architecture okay uh in that case I will perform the same comparison okay if you uh want the desired ution probably is more like the microservices part so every service that perform their specific tasks to going in production but if

we think about a monolyth I will show you a single task that performs all the steps okay to run your code into cabetes okay in this case we have the code pushed uh um a task that builds the code that generates the docker file so it's important that we are generating doer file so the developer doesn't know anything about Docker and the pipeline is generating Docker file

for him or for her okay after that we can build Docker image the generation of the case yaml itself so even the yaml can be generated at run time to then be customized and pushed into cabetes the last step is to save the um result the yamama result to git in order to have that kind of State in git which can be synced after that to cabetes

okay so let's uh see how to realize this monolith with AER okay we can create a new pipeline so just few assumption we have this code okay this is like console application okay let's start it hello word okay every second so very simple doet application with a well through okay and we would like to push it in production to this cabes cluster okay oh sorry this was

my experiment a few hours ago okay so we can use the classic Editor to have like a graphical user interface to start S simple but after that we will move to yaml so first step is to bind to uh get uh uh repository we can call it yes demos C is not a problem the agent will run on Linux and we can create the first part that

is the building of the code so we can directly publishing so publish is like restore build and publish okay and here we can like say Okay publish they hello continously project uh we may have some arguments like how to put like uh release uh configuration release I I don't remember uh In My Memory okay but okay some arguments uh this is the step build the code build

the code after that we can generate a Docker file with some scripting okay so here we can touch Docker file and then we can add some few lines like uh from uh image Etc with scripting so like with cat pip planning I I don't remember B scripting I usually use chat GPT to to have this kind of commands because I'm not so expert about this but this

can be the step of generate doc file after that we can build a Docker image so there's a task to do this okay and let's just build Docker image uh to push it in the container register that I previously configured inside the project settings so in this area or the of the vops I configured some Services connection the AKs for demonstration and the keks is like the

U Cabernet services so the connection to the the CL cluster and the connection to the uh image registry so uh the container repository can be the name of the the application I can specify the docker file that is created in the previous step and some few other uh things and parameters and after that I can generate the um yaml okay so I will use the common line

again to uh take um a um generic like a yaml for this kind of application that I have here in my repo so this one that is generalized just by this build number okay so what I want to say is take this yaml so with a step that can be like CP is/ say Y and then some said uh minus I uh like locally slash deploy Amo

something like that so I'm copying it locally and then I'm replacing I don't remember of course the syntax the build number with the build number that I have inside the context so something like okay and this can be the step generate generate cases yo after that I have the publishing part so there's a specific uh C okay CTL action to do this so this is the publish

into katees part the connection can be the demos AKs the Nam space can be apps because it's one of the namespace that they previously Crea in the Cates environment and after that finally I can save my generated yaml my custom yaml inside the git so something like G add the name of the well dot get comit and get push okay this is conceptually okay the pipeline that

I can prepare uh with this graphical interface uh to do all the steps that we saw in the slide okay this approach is the developer friendly because uh uh main devops tools are based on yaml directly but yaml is still another um convention to learn another uh not the convention itself so yam is just a text file okay but what will you write inside the yaml this

text has names and parameters so it's not so easy to um start from scratch with this of course there chat GPT that can help you you okay but if you have this kind of mind map which are the actions after that you can export uh the steps in the desired yaml that you can reuse in your yaml pipeline okay good of course I do not have so

much time in the session to configure all the details so arguments EXC of the specific steps I have it but just it's just a copy paste approach that I don't want really to share with you so I have a pipeline ready that is this one that is the same exact uh collection of steps that I just created a few seconds ago in this case we can see

okay the project Source the arguments the uh script to generate the docker file which in this case is specific to net 8 and the entry point is specific to the dll that we just built in the previous step okay and I also specify the working directory because uh this script will create a Docker file inside this folder that is specific to Ed devops it's just just like

a context okay just the local folder where the code is built okay uh after that I will build the image based on this Docker file and I will push it to with this name to The Container Repository uh the script to generate the yaml is quite easy so I copied the uh base yaml with the specific definition of this application to a uh generic so to a

local copy and then I will change this build number uh this approach has the limit that uh the operator so the devops operator should prepare this yl that is this one okay uh every time okay ER someone deploys a new application so this is specific to this application okay of course the bill number may change and we use said in Linux to replace the build number with

the actual build number of the pipeline but it's specific so uh the developer would push the code and someone else or the developer itself okay if it has he or she has the skills the appropriate skills uh May write this yamama after that with this um straightforward con configuration we will deploy the yaml inside the cluster and then with this few lines of code we'll push the

uh where is it okay we push the new um generated yaml generated manifest to the repo we are doing everything inside of the same git repo because of this demonstration because uh we need to make it simple but uh um just to give you an advice look forward uh uh what we did in the last few years is to decouple also the repository where the code is

and repository where this kind of infrastructure is okay to be of course more decoupled also to decouple the skills of the developers to the ones of the devops okay let's run this Pipeline and what we want to see is just the the steps in in action and what we expect is to have the application deployed here not only the application deployed here but also a new version

of the man of of the Manifest pushed into the git repo so uh the G repo is this one this is the state folder when I decided to push the the result the outcomes okay so the the the final manifest so at this stage there's the uh for build number but after the uh pipeline that builds the code builds the nothing to show well generates the docker

file build the docker image generate the yaml publish into cabetes so cabetes probably there's something new 20 seconds so it's new and it's logging hello word okay after that we have the git ad so I'm expecting if pulling to have yeah the 65 version inside my git so this is like a monolith okay of a pipel that does all this all the things okay from building the

code and optionally testing it of course generating docket file that doesn't exist in the git rep okay uh generating a custom yaml based on a specific yaml that should exist okay in this case to have the result in the git itself so if we have um like a production ready scenario you can have a git repo just for definition of yaml manifest that can be synced with

a cabetes um cluster good so now let's introduce just a small um generalization okay in this process so my actual suggestion is that the next step uh could be to um the couple um more uh the not really the couple but to recycle okay uh the common code of uh cabetes um to reuse it and to reduce the the um the effort that you can made to

create this pipeline okay uh in the previous example you should create a pipeline visually but optionally you can also go there in the pipeline and you can export the yaml okay and this yaml has this okay this uh aspect okay and you can publish directly this uh yaml instead of the graphical user interface but still with this approach if you have multiple microservices multiple console application or

other kind of application you should have one file one pipeline file for each uh application that you want to deploy so what I want to suggest right now is to introduce some generalization step so the Cod the code is pushed of course uh the only thing we should write as developer is just a small the smallest build definition we can have inheriting like a base pipeline that

is defining all the generic steps that we developed before so what we want to do is generalize this part how to do this well we can work on this yaml and say that something like that can be parameters parameters I don't remember exactly the syntax okay but this can be the up name okay these parameters can be defined on top of the yo okay like parameters and

then we can say up name uh type string and something else I have the prepare I have prepared this base pipeline so this is what uh um we need to generalize it so this pip planine base has three parameters the application name the CPU and memory uh the desired CPU and memory but of course we can have many more parameters to customize our build definition and I

replaced the fixed part of the pipeline with this uh generic um placeholder which take uh parameters from the context okay here here here in the docker file here in the container registry here in the um the customization of the yaml I created a new deployment template that deploys an application to cabetes that is not so specific anymore to the um the previous U console application but is

generic okay and using the said so just Linux scripting okay I'm replacing all the key the the tokens with the actual parameters so this is the step when I take the the template copy it locally replacing all the um all the placeholders to produce and show in the console uh they customize yaml to perform the job after that it's quite the same so even the the git

part of course is generalized here and uh we can use this pipeline based with very few lines of code so the new um pipeline for the Sayo continuously project that before was specific may change to this so this is really tiny okay a tiny file that anyone can write even the developer that doesn't know anything about devops can write something like init from this Pipeline and uh

you just need to to know that you should place a few parameters the up name the CPU and the memory desired uh I um connect this pipeline in the vops by doing this so in pipeline you can say new pipeline starting from yaml uh and you can select an existing yaml file inside the git so this one the composite one and when you run it I have

another one that is here that is ready okay when it you are actually invoking the base pipeline that we built before so with this approach you are performing the same exact job of before but uh um in a generic level okay so which are the main um advantages of this approach that if you have a bunch of microservices and you need to deploy them um everyone with

the same approach you can just focus to the base pipeline to introduce uh features to introduce even new version so like to to to give you an example we migrated uh one year go every year actually the net version to the new one so what we just needed to do was to just change the base Pipeline with the new version number and then we redeploy all the

stuff with just few clicks and we also have the script for this okay so the same exact process but actually uh the code that you need to write to do this is just uh this okay so Fel lines code good so uh to make the example stronger we can also create a new let's pull it we create can create a new console application okay on the fly

to demonstrate that it's quite easier conso up one can be okay and then we can have a loop again okay like while true conso right line hello the Ops and let's sleep for a second for a second okay so let's test okay I think it's quite simple but a test is not hey build it please okay good it's working I'm also adding to the same repo a

new pipeline okay new file that can be one. this uh schema okay the app name should be console app one CPN memory it's okay let's give 0.2 and 0.2 of memory just because it's different okay let's get the change so feed new micro service with small devops config okay let's sync it and now we are pushing the code and the small configuration what is um left to

do uh we just need to to create a new pipeline as I showed a few minutes ago starting from an existing yaml file that is the consolle up one we can even customize it here but it's not really needed I save it and I rename it to console up one just because of clarity because the default name is the repository and after that I run my pipeline

so I'm expecting the same exact steps so um and I'm expecting of course in few seconds because the build is really simple to have a new deployment here that is called console one uh console app one Etc and the new pod running let's see the result because it's it's quite slow it's quite fast so I hope in few seconds we have the result the meantime I will

check if there are some questions okay I check the various chat that I open in my monitors no no question the time being okay it's quite slower I'm expecting like three five seconds for each step but that's just wait okay this is the generated yl nothing to show again okay so the generated yl is customized by this application of course didn't work okay oh because it's not

lower case okay sorry my fault okay uh so sorry about that I have another one in case that is this hello doc um dry run that is another uh console another um simple Pipeline and we can run this one why I'm running this one to show you that the more uh Pipeline and microservices are built with this approach the more yl manifest uh will be here in

the state folder so this G Bops approach will populate your state folder or your dedicated repo for this uh with all the Manifest of your cluster what it means it means that after that you can control of the deployments of your cabetes from there or you can even put a tool inside between your git and the cabetes to sync the state so this can be the starting

point to introduce something like Ergo CD or or flux Etc so let's come back to the build perfect so here we have another service and the good thing is that we can let's Sy again this state we can uh Delete all this stuff like this or or apply all this stuff like this okay so of course you should avoid in production to use QB directly but it's

just to demonstrate to you that if you have all the state of your cabinetes cluster with a specific configuration inside a git repo or something you should create a tool or use an existing tool to sync that state from one to another good so let's come back here we generalized the part and what's next in this approach uh parameters so in uh production we have this kind

of approach for part okay so we have few parts in the organization and a part that we call Dat data platform we have this approach and another one we use GitHub for instance okay so it's not something that you should adopt for your the entire organization okay you should also you you can use this for a bunch of project and microservices and another approach for another part

what I mean I mean that um the more your team is going to be skilled on this topics the more is autonomous to build their own pipelines and their own action in yaml with flux with many tools you can complicate the stuff as much as you can okay but uh in with this approach we introduce many parameters so CPU request replicas autoscaling rules uh topics and CES

to monitor to uh to trigger the autoscale the specific version of net I mentioned that we perform um an update but actually if we want to run something that is net 6 we can with a parameter okay we have a few types of application and every type of application at as a specific template yaml uh to start from okay to be customized uh and also we can

support the GitHub devops many repos so you can take the code from a repo a library for for another from another repo and the git itself so the configuration the gitops repository in another repo again so this is what can be next with this proposed approach also you may have yamal addition so uh since we are we have deployed like a simple deployment so like a microser

that continuously run is not a complete comprehensive solution you may have a web uh application that can may need an Ingress okay so you can compose in this pipeline also parts of yaml in based on the workload that you are going to deploying of course it's a scripting work okay you can be you can find help with GPT of course but it's something that you can centralize

in your in a that is aware of this of the steps uh until your team is ready to take part of this governance by themselves okay another addition is the SC the the kapart so the outo scaler of cernes or the specific deployment that you should put for Crown jobs that in this case also have like an affinity part that is uh fixed but you can of

course transform it to be uh generalized okay so uh this was the approach this was the session and the takeaways is that uh if you want to build your devops team your devops skill start simple okay with an approach that can be this one or another one but with like a monolith okay I would suggest the same approach exactly for software development okay if you need to

write something from scratch do not engineer it with many microservices at the start but try to start simple with just like a good proof of concept which can be a monolith okay and after that complicate things to be more um flexible to um give the right responsibility to every person and every team but please start simple uh why because uh to complicate things you are always on

time and you can do this to scale of course eventually uh in terms of at the end sometimes at the end you can of course introduce tools and we have those tools when the process is mature okay so but to really understand those tools and the complete um pipeline the complete uh um process that I show you at the beginning of this session it takes time okay

so that's why I would like to uh propose this approach so uh we finished I have uh few minutes five no seven minutes for question if any uh otherwise I really thank you for uh attending the session I'm uh you can find me on Google if you want to connect and if you want to ask something and all the materials that I showed you are will be

available in my GitHub uh events 2024 in in the afternoon thank you than you so much okay question from the audience how you manage deployments to separate environments it's a good question uh one of the parameters I was really fast but parameters not say it's not in this uh screenshot but one of the parameters uh was about the deployment uh environment so we have um a parameter

that chooses the right cluster or the right name and you can even create your own small sub process to say that um everything that go uh that goes automatically can go with like a prefix to have like staged deployments for instance you can say in the base pipeline that everything that goes automatically on in production is not really in production but it's like a u environment okay

and after that you can make a uh few lines more of code to promote it to production for instance but you can perform almost any uh scenario that I saw in last few years with good parameters of course our base pip planine is huge and many developers told me yeah it's mess I cannot really maintain this good so if you want to maintain this if you have

that skills so Fork it or even use your own stack and go go with your way that is okay so this approach will it complicates uh the this base PIP plan that can be like a framework okay but if you reach a level of uh that that is too complex for you of course you can scale out and try another path but to reply shortly to the

question you can do this with few parameters and VI script lines okay if you if you have any other okay I see in the private chat no more question so thank you very much for attending session and as I said I'm available if you want to get in touch and discuss later this uh of this approach and any other stuff thank you