 So your favorite stallion again. Good morning We are going to have a special Presentation today. It's more of a boxing match between reddit and suzer than Than a presentation. Well, I'm very I'm very happy to have Herman and and Roberto here with us. It's a it's a beautiful Example of community work reddit and suzer are competitors They work they go on same clients and same behind same technologies and all these things But still they are working together to improve our open source community and that's extremely and If that's not an example of community work, I don't know what it is So please give it up for Herman and Roberto. Thank you hello everyone and Welcome to another get obsession in the Cuban artist community days. I'm still in 2023 I'm Roberto Caradela and in me a cloud services black vaults working for reddit And this is her my mental awareness. I'm a technical marketing manager at suzer So today we will explain the different patterns for the different ketops deployments and To manage cloud native applications so imagine that you are working in a platform engineer or a DevOps team that needs to manage hundreds of different microservices and you recently adopt the different ketops methodology But you wanted to know also how to implement these different patterns that you have so we will Describe the different patterns that you can use daily basis as well And we can introduce the different ketops tools and projects to managing the different environments and also to managing the ketops Deployments and applications. So let's start with the ketops tools and projects so in terms of the tools and projects we're going to review first some of the Some of the project that we're going to see Can you go please Okay, so the first thing so we are not going to invest so much time in this because We are assuming that we are all familiar with the get ups With a get ups But I'm so some of the principles the system is described declaratively it's It's a new good paradigm that we are going to see for deploying the applications as even deploying or changing the infrastructure The decided the state is version around get the different states The current states is what we get from the clusters and the decided state is what we want to get All the appropriate changes can be applied automatically. There's two models to major models There are pull and push models and both of them will be applied directly as long as we have the changes in in the In the git repository and also a controller exists in case of any drift is detected between the Decorate and the state under the side of the state what is declared into the repository and what is the what is reported from the cluster itself So the one of the major tools that we are going to use is the Argo CD We are all familiar with Argo CD. I hope so. It is a cluster an application configuration version it in Git it automatically syncs configuration from git to the clusters in case of any drift detections You can visualize and correcting depending off how you configure that It provides granular control over sync order for complex URLs It can roll back and roll forward for to any git coming. So so the git will be Will be a milestone a point on time about what our infrastructure what's at certain point of time and The manifest template in support, which is going to be the major point of this talk This is going to be a lot talking about the template in so This is focused on the custom eyes, but will be covering also helm It can also provide some visual insights About the situation we have into the infrastructure So one of the when it comes to manage a large number of Devices of infrastructure or one of the major tools that it's really useful It's fleet fleet is an open source to get a solution designed it specifically to manage Large number of devices or infrastructure. This is really good because in terms of the edge architecture for example where infrastructure need to be Increase it or or adding or removing with the flexibility in terms of Having a manufacturer or whatever it is really good because of fleet can group in different different devices and the configurations can be leveraged just applying a certain numbers or foreign specific environments or devices so Let's start with the Some fun with it of patents with our city You have also this qr and also this url and if you just scan it You can go to one open source repo and you can reproduce every single demo that you have in here So we like risks and for that reason we are doing live demos with a hotspot. So, yeah, it will be fun and we have also our Argos to the Instance in here and In this Different qr we have different demos so we can start defining the different demos that we have The first demo that we want and the first part and it's that the August the application's projects and the different settings can be Defined yes with an as another cuban and this object So you have here an August the application that it's just another cuban at the manifest and you can apply this application defining the different source and you can define the different repositories paths or also environments and The destination that could be the exact same cluster or could be other remotes that we will see in another pattern as well and The most important part is the same policy that defines for example when Argos city takes the drips between the desired state of the manifest and also the life state of the cluster Will define if there is sinking manually or automatically giving the distributes So the pattern zero is yet another cuban at this objects and you can define the August the applications So let's jump into the first pattern customize to the rescue Customize traverse a cuban as manifest adding or changing the configuration as needed This is going to be the core of the course as long with the Argos cd Some of the principles we have for with the customize and customize is consistent in a base file some of the base files with the customization dot the ammo file itself Which is the cladding what what is going to be the files that will be changed here or some of the some of the specifications that we're going to add Depending of which environments we want to create based based on the base Where we will be able to create some overlays in this case for this example We have to the development one and the production one each of them has different CPU counts replica counts and Other customization that we want to add the major point of that It's we don't want to duplicate the files depending off the environments because this is okay for one application Let's try to imagine this with thousand thousand application. It's almost impossible so This is a really good for templating things because if you are Templating with customize you don't need you remove that need of duplicating things. So let's jump to see that into the demo So we go to the repository the first one the first patterned and just Copy and paste the files that we have prepared for you If we go to the dashboard we'll be able to see the application is It's deployed and we can see the different objects available if you go to the details You can see the repo URL. So it's pointing to the give repository where you have all the The customization files and within a specific path if you go there You will be able to see the customization file itself, which is pointing if you go into the customization Thank you buddy It's now targeting using some of their resources available and the patch strategy that we want to change in this case For example, we want to target in this specific deployment this deployment We have here with the name of the bgdk will be Changing these values here. So we want to change the first item into the first array and we want to change that value to yellow Customize will read that and will apply the changes to the application deployed in in Argo CD So if you go back here and see the applications details Go down into the manifest. I hope that everyone can see that you see the first item in the value It's the name of color. Thank you and the value of yellow So in this way, you can change that so imagine this as development environment You can push that to production and you can change that to the desired value that you want to All right then first Demo life So what if you wanted to control? The ordering of the different github's because github's it's thinking every single Kubernetes manifest But what if you need to first deploy your database? Insert some data into the database and therefore deploy your front end How you can control the order within the github's deployment? Introducing sing waves and hooks a single if it's a way to order How it actually applies to the different manifest storing it and all of the manifest All of the Kubernetes manifest have Dsenotation with this sing wave and also one number that defines the grouping of the different applications So you can group and you can define first is the database and then you can apply Different things like the front end implying also and defining all the things and are very handy also To its hooks that could be and can run before during and after a sync operation So in this specific demo, we will insert some information Usually in the API when everything is ready, but you can send messages in slack send If everything for example works well, you can send one slack message if everything was wrong You can send a page a duty for example. You can control the different stages or not So in this demo, we will control the order and we will first deploy the database We insert data we will deploy the front end and we'll make an STD because just with a single You see there hopefully Let's see So if we go to the second pattern in this second pattern, we have DTG application we copy paste that we go to the pattern to the pattern to and we deploy it just Go to these show it because it's pretty quickly and as you can see This is not a big bang. It's having order. It's first deploying the application of the post rest and applying also different things like The front end as well and it's doing everything with the different order So it's not applying every single object that the text it's maintaining the proper order defining for example This how you can control it remember that we apply Seam waves and we have a single wave with zero that it's applying the first Time and afterwards when it's ready when it's deployed and sing the properly We have also the same way to defining different things that we can control and controlling the order within the different GitOps deployments so you can have the power of controlling and orchestrating your different Kubernetes manifests So what a good way to orchestrate things, right? So let's go to see the third pattern here the GitOps orders awaken We already see what happened when we have to define a single application We cause we go to the arg of CD we define what we want to the git repository But what happened when we need to scale that this up to thousand different related applications We cannot have a single definition for each of them because managing that or sending that to the operations teams will Make them mad. It's possible It's going to reduce or increase retention policy of the employees So the question act here actually rise. What about deploying multiple related applications at once? so We don't want to end the day at like this guy. We just handle in the different files or just trying to Okay, where where I would put the configuration for that Argo CD file This is intended for an specific cluster. It is for another one. This is almost impossible No one wants to deal to deal with that if you are being in the industry for more time You will probably know how that feels So The then the Argo CD app of apps pattern is going to rise to be the solution here It allows us to define a root Argo CD application that will itself define others Argo CD application belonging to the same one The root apps the Argo CD route application points to a folder in git it where you have other files where you have other files where you are defining the Argo CD plans or The components that belongs to each application that doesn't mean you don't need to define the rest of the application But Argo CD when it comes to deploy you deploy the root application and it will be orchestrating the rest of the components So we're going to see that into a demo again So if we go to the repository going pointing to the demo pattern 3 just as before we applying the The deploying to the Argo CD There we are Pattern 3 and we just applying what we get from the repository We go back to the dashboard and we filter in with just to remove the rest of the application that does not belong to this app So as you can see here We have a bunch of different Argo CD application But we just default we just deployed the root Argo CD application is the one that you see into the top left corner So if we go to the root application We can see that is the root application the root Argo CD application and the application you see on the right The Argo CD application you see on the right belongs to the same root one So if you see on the details, so you can see the path and the path it's pointing to the different components if you go there It is pointing to the repository where you can see the rest of the definitions the yaml definition of the rest of the Application belonging to the same one, but you don't deploy these apps you deploy the root Argo CD applications So you back there and you see some of the details that you can see on the application Let's trust on the Wi-Fi Thanks, God So you can see here the Argo the Argo CD application This is one of the child application belonging to the same the same root or pattern application as you can see It's an application as always Where you can see some of the river URL, so you can see the details and everything is working as Specter, but you just deployed the root the Argo CD application. That is the app of apps All right, then so I have a question. Do I need to define each Argo CD application in this pattern? Is there any way better to manage our application at scale because we saw just a bunch of application But what if you need to manage? hundreds of different microservices and You need to deploy it and you need to also orchestrate for example development staging or production applications So we introduce Argo CD application sets with these application sets that isn't specific for Argo CD You can target multiple Kubernetes clusters and also you can with a single manifest Cubinets manifest that we saw you can deploy multiple applications from one to multiple kids The purpose race improving this support of the mono repo so we can have just one repo One git repo and within you can define for example one folder structuring your different development staging and production Objects and Kubernetes manifest as well and within this multi-tenant clustering you can improve the ability of Individual cluster tenants to deploy different applications controlling your different environments that you wanted to target as well Using that we are using the generators So we have four type of generators and we will focus in this demo in two that is the key generator that will point to one specific Git repository with this folder and also you can use all the generators in this demo So we will demonstrate managing this kid of application that scale. We prepared the fourth demo and so far so good Trust in the hotspot and living in the edge And we will deploy Def staging and production environments with a single our goes to the application set So if we go again to the applications with remove the filter We saw a lot of different things and we just go To the pattern for in this pattern for we will apply These are to see the application sets and with this Application set we see that if we filter with different projects that we have We have the different staging Projects so these staging projects are the different are to see the application sets that we define it These application sets are pointing out to one specific generator and we use sticky generator So you can define the different directories and you can put whatever you want inside that will recognize Automatically defining inside of this if you put for example more applications will pop up here and will appear Without the need of defining every single object every single Kubernetes manifest just popping up Right now and if we add for example another folder will sync and we'll have so we are structuring We are defining everything that is here So we have these also for Pratt and everything. It's right So so far so good and we have another type of generation We focus just in one cluster, but what if you want to deploy it in multiple cluster? Agassi they can also define with using the cluster generator that Automatically generates this cluster parameters if you have to your credentials You can target with one single Agassi the instance Multiple different Kubernetes cluster and you can have for example inside of your Agassi the different Kubernetes clusters manage that could be within or Distributed across different environments and therefore you can have also this Generator with these clusters and you can use this in order to deploy your different environments your different development Environments staging that are you Defining in one single repo and using these generators pointing and deploying with one click your entire Infrastructure your entire environment across all of these Kubernetes clusters so you have a lot of far for using that generator as well and the last button We're going to cover today not to Mess up with the time. It's the promotion between the get-ups environment So this is what we want to get we want to have the source code We want to build into the QA then promote between different environments. So How do we use that so far We have different branches different branches pointing to different environments the production environment staging and the QA and when we want to move some changes we just Promoting the changes just Merging one branch to another or using any get a strategy base This is not what we want to do during this these demos So we need to move out because it will require to have multiple branches multiple files and it's going to be Complex to handle when it comes to edge architectures so if you see at the at the Files hierarchy we have the potencies We have a bunch of different base files and then we have the ends and the variants and we have some Specific extra settings that we are adding for each of the environments if we go to the custom eyes We are going to see the base files some of the resource are only pointing to the base files with the different components, which is longer to the variants in this case for the Europe and The batch is the strategic merchants We are going to use for both file deployments and the version because these two are relevant to promoting the content from one to another so please Thank you Then we have these different steps This is a very Graphical visual way to to visualize what what happened when we try to move that from one some into the first step We have the variant. This is the one way that we want to move between the different environments and we are applying We are applying the different the different extra settings that way we are going to add independent of the of the stage We have so two different scenarios How are we going to promote application version from death to a staging environment in the US? So we are not going to move that From the variants just copying the files into the repository We are copying the files the files version dot yaml from the dev GPU into the style in US In the second scenario, we're going to do the same but from the stage to their production. So we are going to Move out and if we see the deep GPU version on the On the dev side, we are going to that we are using or we are testing the tag image 2.0 Once we have copied that we have see we can see the Version on the production is still the one because the changes that we are validated into the previous environment We'll be pushed into the next one into the next environment to the it will be promoted into the into the other environment So everything that is validated in the previous environment will be pushed it to the production or to other environments So you don't lose the control even if you are If you are using this scenario So time for the Q&A so far so good Any questions of our Yeah Up to staging and then to production for example, this is a way to go Yeah, you have also the rollback so you can roll back to end specific commit because within Every single args to the application you have also the history and rollback and it's defined in git That's the proper way to go and if you are messing up with different branches for that reason We want to avoid it because we suffered That in the past and for that specifically we wanted to just Going with a better way in order to just copy one single file pointing out and you can just go and roll back Going to one specific commit avoiding pain More in production and this calls into a m in the morning. So a series Yes I How do you manage the controls so around deploying to production? So it's obviously a code review. Okay. How do you how do you do that? How do you make sure that nothing gets deployed that should not be that's a very interesting question because you need to for example Define the promotions and you can also use these p requests in order to at least pull requests So we did just copy in it But you can also Demonstrate it and you can put pull request and several reviewers in order to not mess up with different things So is it just a team or don't do it in production? Just put a pull request some reviewers some linting and you go to all and you have also the rollback So you can always roll back to one specific version that you know that controls and you know that works Just remember that rolling back. It's also a feature available in Argo CD So if you want to roll back a commit is just a point on time for my application So if you want to roll back, you can always go back on the commit on the GIT or you can use it or fixing something into the Argo CD just to make sure that you have the right of the right version of the application running into the previous stage Hi The pattern three explained about the apps of apps Okay, so let's say that you roll out a new version of your app And you have tested that in QA environment and that it works But for some reason when you shift to production you have a bug So it's a way that I can detect that before going to product and not doing rollback But just testing it before just switching the traffic or just yeah, there is a bunch of Different products that you can implement as well And you can use for example August the image updates in order to link everything Prepare deployed in one scenario and you can use also application sets This is the next generation of apps and you can define for example first the development and staging targeting for one specific area in scenario and therefore you can Then then you can be and have these insurance Promoted to a github using pull request or whatever that you are implementing So it's focusing first in these scenarios and developments and in staging in one cluster for example And then applying these in production that you know and you have the insurance that works my pleasure Hi, I'm here question hello So usually in an environment we try to create artifacts through pipelines. Okay, the artifacts are usually stored in a repulse story So I'm curious. How do you make the connection between a new artifact and your automated deployment? So if you have version one and you create a new artifact version two Okay, how do you want this process to be automated all the way into your github's repository without automating? The auto commit. Yeah, it's who controls the automation. Isn't it? Yeah, it's a chicken and egg So it's not easy. We try to simplify that and we try to do it at least not doing the big bang So if you see here and it's messing with me the Wi-Fi, okay The different different environments you can define as well the different directors that you can But you can narrow as well. You can deploy just Single specific application and test it and therefore you can increase these automations. It's not that big bang It's just trying to make the things that works first Keep it simple first and then you can Automate a little bit more. It is like Part of that we saw we suffered So if we are starting these applications that can save you a lot of time, but you need to take care with the automating All right, then this one because we don't want to eat We are in time. We're from Spain There's all five so far. Let's see. I'm in a question. I have a question about the same application set This one is top down the top down repository And the describes what children you have can you also have it in a decoupled way that a child says I want to belong to this parent in the other way round Yeah, and that's exactly that you can do with these matters generators You have different generators that you can deploy So you have least generators that you can apply that specific pattern and you can define this specific Application that you want instead of doing this big bang narrowing and doing that That's the best thing around generators that you have this flexibility in order to scale And you have for example this cluster generator and you can apply both So you have these mix and match using the matters generator that combines the different generator So you can target for example development in the staging for one specific Cluster and use also these key generator in order to the plan just single up or a multiple apps The generators will actually allows most of the definitions to be Flexible because independent of how you want to deploy your application or what is the strategy that you want to apply to the environment You will be able to see how many generators that you need to use Maybe you have just a single repository Maybe you have more than one cluster that you want to add and maybe that's not applicable for for most of the clusters So you can add that that kind of flexibility is specifically for edge all right then One more yeah, how do you handle secrets because there are Problems around secrets storing in the gtops worlda and there are ways you encrypt and decrypt Secrets with still secret. How do you handle in production? with carefully Carefully, I mean Yeah, carefully I suffered usually usually you seen that there is some vault solution That is intended specifically to use that for example the seal secrets or You can use the secrets and you can define it also inside with Lua and Try to sync because this is like changing and you need to be And tell Argos city that you are using these secrets that you can define in Lua as well So there are some bunch of different strategies, but this could be like another talk and Could be fun. So So far so good. Thanks for listening and Yeah, live demos. So we are living in the edge. Thanks for attending. Thank you so much Thank you very much guys beautifully a beautiful presentation an example of collaboration. I loved it. Thank you Thank you very much People yes, please go on and have a stretch we are going to restart at 1145 sharp With service mesh and Raymond from Cillium