 Hello everyone, we're happy to be here and to discuss with you about multi-cloud Kubernetes. One github slope to move them all on this specific period and we could say a little weird period because we wear a mask. I'm going to start the presentation and just remove my mask first. I think it's going to be easier to earn here and now. First I would like to introduce us quickly. I am working with Johan Zagray, cloud DevOps engineer and tech leader on DevOps side and myself Jonathan Ranger of the South. I'm a field CTO for Kajiminai, based in France, Toulouse and we're really happy today to sharing with you some thoughts and some things we've done with client around github and Kubernetes. First of all I would like to, it's important to introduce the github's definition we could say or some element about github's. First we could find on some work previously, github's for, could say first time introduce with cloud native infrastructure but for most of you and I think and for myself I've been in open source for 15 years now, github's it's like the basic of the infrastructure for open source people and people working on Linux for years. It's mostly how we're using the best practice of developing and the same tooling of the developers to run our infrastructure and this is for me really a way just to converge between developer and ops on the same way, on the same way of working and the same tooling and that's why for me, even if I really like the github definition of the github's we're taking the best practice and we're trying to work together and that's exactly what we're going to show you right now with a different project and we have a demo at the end of the presentation, he's going to make my U1. First just to continue on the basics about DevOps, github's I could say the idea is to have one pipeline and on this pipeline you're going to have, I don't like the term one pipeline, you're going to have multiple pipelines and each pipeline is going to be dedicated on different components of your infrastructure and of your code. It's really important, you're going to share some tooling like github, github for example or the registry between the dev side and the gith side but technically you have to differentiate and you're going to differentiate what is the github's pipeline, your pipeline to deploy operation and to deploy the infrastructure and your pipeline to develop for developers. First why you're going to separate both, it's really about segregation of rights, securitization of duty and to be sure you're going to securize well your pipeline but globally you could say we're going to use the same tooling, same pipeline to do two different things, set up environment and deploying software and that's the mindset of github's just to give you, we're going to go through directly some example right now on Kubernetes for sure. We could say a lot of people like to talk about infrastructure as code or honestly I'm not a big fan of this word. I really prefer github's but I get what people try to do with infrastructure as code. As code is meaning you're going to use the same way of working your infrastructure on deploying your infrastructure and you're going to integrate it in your development code or your application code. You're going to see an example because I think Kubernetes is a great example for that but it's a point of view because Kubernetes we could say it's a platform itself and you have the infrastructure and you have the application and sometimes even if the mindset is to say okay infrastructure as code we're going to put infrastructure component in your code you have some time to separate the different workloads and to have a clear roadmap and a clear way to segregate your environment and to apply security rules and and and all the elements on your infrastructure. It's not a mess you know it's something you have to organize. You could say globally what we're looking at what we really like today github's approach it's a jail. I put this it's really small you know because infrastructure being a jail is not always easy. It's open source as I mentioned I've been in open source for years and we've been doing that for years also it's really linked with open source. It's a decentralization decentralization way of working we're going to talk about that later because it's an important point and what you're going to look at particularly it's a hand-to-hand workload DevOps pipeline CICD and also adoption. It's really important when you would like to move to DevOps if you're sure you people and you ops people you see something they're going to use the same tooling than the developer the same process the same way of working is going to be easier to work together it's going to be easier to understand each other and it's really difficult to stay and to work on two different with two different tooling and approaches when you're talking about DevOps that's why you could say you have continuous integration which is really dedicated to I'm not going to talk about github I think you all were aware about continuous integration but about your code and what you are going to talk Kubernetes github mostly how you're going to set up your Kubernetes update your Kubernetes components and all the services you're going to put on it and this is particularly how you could make the difference between github just to give you some example I think this is is not obvious maybe the next one because I would like to show you more of the conceptual approach first you're going to have on the left your main components it could be your master you could say and after you're going to develop a way to deploy a Kubernetes cluster with all the tooling in it and everything automated and I'm going to show maybe the next slide's going to be easier to understand just give you the example and we're going to have you and he's going to give us a demo about that just after that look at this part on the left side you have all the DevOps tooling you're going to use and you're going to deploy for the different cluster you're going to you're going to have for example you have an open chief cluster and a Kubernetes cluster on the right and you could say okay my mission is to deploy a Kubernetes on open an open chief Kubernetes and vanilla Kubernetes on two different places but with a same set of tooling on this approach of github and forge as a service you could say okay we on this side using and leveraging this tooling to deploy and maintain and upgrade and release all deployments tool set meaning or Kubernetes deployment and also the tooling inside and it's it's interesting because you could see it's a really a loop it's really a worth working because in to you you're using the DevOps tools to develop and maintain your environment and in the same time you deploy this same this same technologies into your different cluster with this you manage your different cluster and all the components that you upgrade with and in here is where you're developing your platform you develop you release your different setup you release the way of working you know it's what we could name centralized way of working and decentralized way of deploying i'm pretty sure it's not totally clear for you right now but we're gonna show in the demo but in that scenario and maybe what could be confusing is because you also using Kubernetes to deploy but it's a real loop because today you say okay i would like to guarantee and to ensure i'm going to have the same level of quality and quality and sell the same level of deployment on each project and i have multiple project of Kubernetes and and i have to give for all this project a set of DevOps tooling and that's the way you're going to do and you're going to monitor your different component with a git lab a registry somewhere where you're going to update the kubernetes cluster but also a way in internally you're going to manage the the lifecycle of all your components in your different cluster it's it's an interesting way we're going to go through that also later just right now and after the demo what's going to happen also when you're talking about multi-cloud kubernetes if we continue this way and today on the market you you do have a bunch of solutions all are pretty i could say young it's not solution really broad really used today but when you would like to to work on multi-cloud kubernetes solution what you would like to do first is to centralize a way to manage your cluster to apply the same rules on every cluster manage your user your airbag your namespace and every component you're going to use and the networking what networking port also and you will like to centralize everything but in the overhand you have to decentralize the way of consuming the platform for the developer and today we could say you have different solutions like tanzu as your orc launcher reddit advanced cluster management for kubernetes on thus and and the one we're going to show you this is really a pure github's approach what's the difference between github's and not github's you could say most of the solution previously you have a user interface you have a way of working or where you're going to just use your interface and you're going to click click click click and save and and i could say it's really an end user point of view of how you're managing your infrastructure and your component where in the github side we're going to really look okay we're going to work with github or githlab and we're going to really create repository a forking repository create branches where we're going to upgrade and update the platform and the different component every in in the same way you you developing software it's really interesting in some in some because you could really release seeing what you're doing and giving back and sharing the same tooling and giving back to the project all the the element they needed to to do their job and for these studies we we did it for clients and you could say at this time the idea is to have a multicloud kubernetes meaning for each entities of the organization they need a new cluster setup but they would like to manage and to centralize the setup of the cluster with a central team and it's an interesting and i really encourage you to look at this different solution as you know i'm as an open source people guy i could say today you have only a launcher and the new red art components not yet available open source but ready there are really open source and on our side we just release and reuse open source tooling we show you as we use the term of AnsibleTower you will see because it's a commercial version but you could also use AWS but i think because the the work of the editor is really important we have also to promote the the enterprise edition to to go on this side and on this complex discussion i would like to to go on the what we named centralize and decentralize the idea behind the github's approach for multicloud kubernetes you have to centralize the deployment as a configuration of all the clusters across region and you have to be sure if there is consistency on the configuration on the security restriction of the airbag role on everything you're going to say it's the basic security component of the kubernetes the decentralization is giving on each team local team could be a nub steam for example international company we have for example the open shift team in france may be maintaining the platform engineering and maintaining the platform and you have a team in japan okay when what you would like to be sure when you deploy an open shift in japan you would like to be sure they're going to have the best best of breed open shift implementation or kubernetes implementation with the security layers and so on but on the other hand you don't you don't want to manage this open shift instead of them you know if this is on their job they rely on their project they depend on their constraint locally and that's what we named decentralization decentralization needs to say to give back enough capabilities and power on the platform to the local team to be allowed to extend the cluster be able to create namespace be able to to give some capabilities and on the application owner and so on and so on leveraging service mesh and so on and it's it's really interesting and it's really i see more and more client and more more user seeing this way of light and this way of double approach an example of this we could say we could say i'm going to move my video here sorry because there is some animation yeah it's an example you know you see we have a git repository you could see different tooling we put there this is an open stack infrastructure but you will see after that we could have a public cloud a private cloud any infrastructure you have a vania kubernetes but it could be also an open shift a launcher or another kubernetes distribution and you're going to have some tooling you're not going to see first in your DevOps approach you're going to have deploying and managing and updating cluster you're going to use on this we're going to see in the demo but in the way we are implementing them you're going to use ansible terraform and vault and git for example to deploy and concretely when you would like to create a cluster you you already have configured a way of deploying the cluster and infrastructure the way of integrating and installing first installing the infrastructure layer after installing kubernetes third applying apply all the rules you would like to apply on the clusters meaning airbag rules security rules policy rules and so on after that you're going to have the monitoring alerting we're going to centralize the monitoring alerting with prometheus alert manager and this one it's tannos i don't know if you know the tannos project from the clownative computing foundation it's really interesting and the idea it's to even if you deploy 50 different platform you're going to really give it and converge on the monitoring in the same interface let's allow you just to you just imagine you create your new cluster you see it's a cluster japan one japan two japan four and at the end of the day you're going to have all the information about the monitoring on the same place and on your same monitoring interface and particularly on old tooling they're going to alert you about what happened because it's alerting the most important but also you're going to share locally with local team they're going to have their own prometheus on alert manager and on our side you could also see the same thing at the higher level of the organization it's really interesting to see that this mystic cluster you're going to see we put on the monitoring side you have to centralize the information but also give back to the local teams the capabilities to to monitor and to maintain their platform on their on their side also this is deploying updating namespace security and apps hybridization is really interesting on this scenario because putting service mesh as a networking layer as your main networking components that allow you particularly to deploy apps in the different cluster with a possibility to create communication communicate between two clusters expand myself if you put for example service mesh and it's issue here if you put as as a central services among different clusters you could say okay my component my namespace my pod could communicate with this cluster in this region through my service mesh features and is is how you're going to complexify you have private and public cloud approach is really to say okay service national now is not only a feature it's not only dedicated to developers it's really a way well you're going to organize and strategically organize your network dependency and your communication amongst your different cluster and different region it's it's really interesting also here you have a vault you you have some components you you build the consistency leveraging Elm for example just to be sure you're going to deploy the same thing the cluster on the same way on each different platform that's really important in this detail architecture we're talking about the ops point of view from the centralized team this is the point of view of the centralized team just to let you know if you go on these details first you create you it's a the Jolik we're working you create your environments with unsabled tower terraform you have your different repo you create your repo varies or not a depot already existing do you have specific content locally i have to integrate and to update and so on and after when you finish to create your environment you have to create the depot of your environment to be sure you're going to upgrade it you know and link and connect with for example service now or all the external components second you have create the cluster itself you have your environment it's vms it's s it's bomb et al after you create your environment your cluster you going to deploy Kubernetes apply all the airbag rules namespace security policy and so on and also you're going to create automate of the connection of your cluster with the different tooling you have to be sure various consistency of a connection and this is the second part you know and same thing you're going to see on the git lab repo or git repo where is your cluster images where is a different component where are your repo where is your registry and so on and and third it's configuration inside the cluster as i mentioned after you finish to deploy your cluster you're going to apply different rules on configuration you're going to for example create user airbag namespace role and maybe also creates the the gate to connecting or ipi to discuss with ad for example if you have an ad or held up component is where you go you see you follow three different layers and you're going to follow rules and a logical approach with all git lab web there on git repo on way of creation on way on building consistency across your different deployments on the other side we could say on this side if you look at this infrastructure on two different point of view on the left side you have the point of view of the application owner is he could do we in this is he could be it's a different layer of what we saw because we use console on this project ansible tower and open shift mostly but with different components as you say as you could see but the idea is you're going to have access to the same git lab you're going to git repo you're going to deploy and connect your infrastructure but you the limitation will is going to be on the way of you can't manage directly infrastructure you can change infrastructure organization and you can't access or all the admin rules or admin user access to your infrastructure but you're going to do some creating a namespace set of rules everything you think as an organization you have to decentralize because it's going to be easier to be deployed by the local team it's really depend on how far you would like to go on the on the on the on the dependent i'm not dependent i could see on the autonomies how far you would like your team is going to work without any external help and be by on their own on the right side it's the dev user side where you're going to see they're going to use ansible tower on some way to deploy mshort for example or really for example have access to the project or ansible is going to is going to create the project or the local project and after you could say you have the traditional loop of implementing your codes into the platform and it's interesting you could see on the different side different steps we could say you we all using the same tooling we all working on with the same approach and we all sharing the same practice so everything else it's a wealth working it's a wealth thinking it's a set of rules a set of an approach about security user management militant approach but is what will you looking today on the DevOps github side the next slide i'm going to is going to be we're going to move to uh to yarn and yarn is going to is going to give you give you a show you a demo about this implementation so for this demonstration we have already created a small infrastructure inside uh aws if we have to represent what have been created actually it should be the core services that Jonathan explained just before so actually i am able to to show you how we have structured the github to allow us to allow us to separate all the different elements that should be deployed so for example for the platform we have actually uh create some aks environment open shift kubvania and eks inside we will be able to found the terraform code that have been created so for the infrastructure we have created a jump server to secureize the connection to the different cluster as we don't want that the cluster should be able to connect directly to internet and to be accessible directly to internet for security reason evidently and uh just before you have all the different elements the different software element that will be deployed so inside each one you will be able to find the m chart that should be uh packaged and uploaded inside the harbour registry that will be later used by ansible and elm to deploy the different elements and configure them depending of the need of the client team so if i go inside ansible tower we are able to find all the different models that have been already created so we have the deployment of the platform itself as a workflow so we will be able to found inside the workflow the three different steps that janetan presented just before as for example the terraform deployment for the infrastructure and later we will be able to found the different step of configuration like the secureization of the jump server the creation of the admin account for the team that should be responsible of the infrastructure the installation of the different dependency like elm awvs client if the target infrastructure is uh based on awvs the creation of the kubernetes cluster itself and later we will be able to find the creation of the user inside the cluster and finally we will be able to find some the most important part in this logic it's all the different playbook that permit to deploy the software inside the cluster so if i take for example the this one that permit to deploy a matter most services uh we'll be able to found that uh we have set some standard configuration for matter most uh and that will permit us to know on each server where uh oh if i can say more exactly in a which namespace uh the software will be deployed so that permit us to keep a logical structure between all the different cluster but we'll be still be able to have some custom configuration at launch because we will be asked by a survey to specify some element like the size of the pv that will be used and also which name should be used for the ingress and element like that that will equally permit us to specify the which version of the elm package that we have generated before should be used for an initial installation and also for updating the software so that permit us to with only one playbook to have a full lifecycle of of and support the software so for example if we go to a full demonstration uh with matter most to to do a for a first deployment and uh an update i will take this one so we will be asking on which cluster we want if i save and don't launch that will not work so well so uh i will be asking first in which cluster i want to deploy my my software so for this case i will take the cluster created for the demo i will have been asking all the different elements that should be specified for the deployment a lot of elements are automatically set and is standard but we will be permit to change for example i don't want to have matter most as the name of the this service inside the url that will be used i want for example to have the ingress only chat so okay i launch it and if i jump back in my terminal i will connect directly the jump server that will be able us to to see what we have so okay so air will be able to find the the matter most that i just deployed it's the version that we have uh just specified before and i will be able to check again if the the ingress have been correctly set by uh by awx because awx will generate uh with the different values that we have set it will generate the n values that should be used during the deployment so uh get ingress so yes i can find my matter most services and the ingress that has been specified it's the co-rest one so it's chat as i well as i have said and after it's something that have been specified directly during the teraform deployment we have set which base name should be used for all kind of ingress so inside the n i just specified the name the specific name of the service and not all the url it's that permits the dev to just focus on the software that that that they are currently developing and not all the ops on your ops stuff so yes actually i have deployed my service i have the 0.1.0 version but if i create a new version so uh actually we will change just change the the number of version i will not change anything inside as uh we are a little short on on time so now that i have pushed the new version my pipeline should have been triggered we just have to wait that if he finished to build the m package and to push it inside arbor okay the version 0.2.0 is not available so if i'm going and go back in directly in uh awx i will be able to launch my uh my deployment playbook again but this time i will specify with uh no i will be able to specify the version uh the new version so the demo cluster and i want to have the new version of it i will uh equally change the ingress name i will uh this time keep the correct one so it will change uh again the ingress i want to this time i will stay on uh on the action realized by awx just to to permit you to to see how it was done so we create a temporary directory inside jump server where we will be able to found uh the um m values that have been used and now it's okay it's deployed okay so if i check again we now have the the matermost with the version 0.2.0 that have been deployed and the ingress should should have changed to to yes this time it's correctly set to matermost.apps so as you have been able to see uh we are totally able to create uh services deploy them and update them quite easily i just have to uh to push my code inside gitlab and to launch it directly with a survey inside awx i don't have to know all the m command work and elements like that as uh for now i just show you the command because it was for the demo and we want to test it but uh final user should not have to use it so he is now able to directly connect to his matermost services i just change the url to match what we have set matermost it's going to be better and i did at this part too without s okay and my service is open already so i just give back the end to janathan and we could say even uh to yes together maybe we're gonna you're gonna switch on the on the presentation just to to finish and to conclude and uh we're gonna happy to to have some question about uh from you first uh we're gonna say a big thanks we are both open source guy and we we if we hear and if we work like this today is because of the huge work from the community i say the new linux community don't forget free software also and linux this is the basics of course the cloud native computing foundation and all the good guys we're contributing uh today and first uh again thanks you to open source summit and the work of linux foundation and because if all your good guys doing your job we could doing uh and i think it's important to to give back and now we we're okay to we have team 10 minute question answer session and we're gonna be happy to to answer your question into the chat and thank you very much to listen to us and see you next event maybe physically this time bye