 Okay, morning My name is Miguel soon again. I'm gonna go over and talk about the this talk is gonna be how we're basically gonna Use the opens that components as microservices Inside of containers. I'm gonna try to go a little bit slow. It's too early and probably everybody's kind of like hangover or something This is the agenda that I'm gonna go through it First of all, we're gonna just pray of definition microservices. Why open stack? How we're basically move opens that into microservice itself and we're just gonna see the standard architecture of open stack after that We're gonna go through why it's better to go over and do this on microservices instead of using dev stack for development You'll see in a minute after that. I'm gonna go and show you how pretty much you build your code Using the latest container. I mean build your containers using the latest code So you can actually test from pretty much source and master or any release that you want Then I'll show you a real quick into how docker file is written What kind of a templates do we use because we're basically using OpenShift and Kubernetes underneath? And then I'm gonna just give a really quick Display on how pretty much keystone shows up later After that, we're just gonna go through some basic stuff recommendations of how to run the open stack controllers And how do you pretty much? Roll updates and at the end just have a general picture on how this stuff works So let's start With the beginning after that we're gonna have Q&A if you guys want in there So first of all, what is the microservices? This is pretty much from Wikipedia and you can and you've been hearing this a lot and pretty much the only thing That is saying is that I'm you architect your application in a way that you go over and decouple it and Every single piece or every single group becomes a service group that they talked with each other within it So you can have your application if it is a billing or whatever Type of application you can have like your billing system becomes one microservice Then your account management becomes another microservices. Then you pretty much just split it apart You grab those pieces that are really tight-coupled and those becomes just like a unit So this time you are not looking into going over and figuring out like where is X, Y or C piecing to the code or if you have a monolithic application You usually start spreading apart not as saying, okay, I have my application server and my web server pretty much just from function so the whole idea of microservices is Design the software in a way that will basically Imitate or pretty much try to look how your business work the same way that you when your business is you have Different departments doing different things. That's the whole idea of kind like a microservice So after that and they are hold the other point of doing the microservices that I'm they're pretty much Independent of each other and they talk through APIs They don't have to go and say you know what I need to do something with this other piece of code That is sitting on some other place because you can just request it So if the whole other piece of the code changes as long as you have the API you can still go over and use it That's the whole point of using the microservices So now why are we doing it with OpenStack? Well, first of all OpenStack is a huge ecosystem multiple components, right? You have base core and then you have a lot of different other components Then the second one everyone and every every of these components. It's already called service So it's just like okay. I mean you have your compute service You have your storage service you have keystone you have horizon each of them is actually doing a specific function And they already talk each other using the APIs. It's not like you're gonna go over and Use some crazy RPC call in the back even though some part of OpenStack They actually rely on RPC calls, but it's not as in you're having keystone answering RPC calls from NOVA Usually it's just RPC calls within the same service itself and And last and for all it's pretty much the components are independent from each other except for the keystone dependency that you basically use for authentication Every other component doesn't matter if you have it or not. So that's the reason why we picked it up in OpenStack now how you put it in Why move it as microservices first of all like I said Each component requires its own database. So it's not sharing anything You can have your own separated database for each of the components that basically allows it I mean it might indicate that you have to manage multiple databases instead of having just one huge server But it also allows you to just a couple everything from okay Now this is the section for open for NOVA itself So you can go around deploy your own database inside of the NOVA microservice without having to affect anybody else Like I mentioned before they interact with APIs So it doesn't matter what exactly happens in the OpenStack code in the back as long as you're using the API It will basically go over and still work That's one of the reasons why OpenStack pretty much allows some type of upgrades without much of a problem Usually when you try to upgrade OpenStack Aside of going over and saying I need to modify the schema in the database every other things pretty much straightforward Second one is pretty much to the architecture of share nothing Like it's pretty much completely independent And it's not going to be going over and relying on something that you have to be seen by multiple servers at the same time Then it's the sign from scratch since day one Even when it was some what I said cactus They already start looking to microservices themselves. So it's already built in and the last for it Is if once you create your microservice inside of your container You can easily go over and deploy it right away and give the developers the ability to deploy. Yes, you say it's just like one click deployments so Moving forward here. This is the standard architecture of OpenStack That's how pretty much everybody sees it and that's from like open stock Docs of opensack.org, but as you can see it's already telling you right there It's pretty much different services connecting through the API So our so the whole reason was I mean if it is already sitting in that point Why not use something that is already built for microservices? That's the reason we decided to go and start Doing Kubernetes an open shift Kubernetes pretty much designed for doing microservices gives you everything that you require like a load balancer replication Scalability at the microservice level now I'm not saying about the Kubernetes cluster or anything like that pretty much is at the microservice so when you go over and have your Pretty much deployment Inside of Kubernetes you pretty much you can go around define services each service becomes like the network service or the compute service or The image service within those image services. They are running your containers of those open stock components only So you can pretty much decouple everything now having containers is really easy to go over and say, okay We need to start testing something else or you need to go over and give it a new Environment to somebody so he can actually test something So it's really way much simpler than going over and doing a whole open stack deployment Into okay with this our dev environment then this our test environment and this our production environment So moving forward that's the reason why we started with Dev stack and moving this stuff into it Problem with one of the problems with Dev stack that everybody knows and everybody goes over and code It's that it's a mess. I mean, it's really a mess you go over You just run some script that basically does everything in the back for you and you have no idea what's going on So a lot of a lot of the problems when you are coding Pretty much it goes into. Okay. What exactly is doing here? If you're coding some specific section, just like a Python module or something like that That's fine, but if you're actually trying to go something a little bit bigger It's a it's way much more than difficult to go in there I have no idea how like developers actually deal with it right now because you go and try to figure it out that I'm gonna I don't know put a Nova a Nova API version 3 and how do you test against everything else? It's like you have to know like what exactly Keystone is doing what exactly Nova is doing In novice if Nova is gonna talk to Neutron So the problem with Dev stack from from the point of view is that you don't see the actual thing Running you just see a bunch of things that are happening and you have no idea what it is However, once once we decided to go and start moving to microservices That thing changes because now you have every single of those components even calling it from master Which basically is what Dev stack does starts downloading everything from master and then set it up for you But this time you're pretty much separating in small docker containers And you can actually see the whole system working without any without having to go and do some craziness into it or or nothing like that It's just like really straightforward You create the docker container build it and then you go and deploy it in pretty much just pushing the Jason template tool Open she fought to or to Kubernetes pretty much the same thing And now when you are actually coding you can see the difference because you can go and see okay I have the rabbit MQ service here I have the database service here, and I have the other microservices sitting around You can actually see what is going to be the relationship between each other and we'll give you a better idea on what exactly you need to go And figure it out when you're trying to develop something so Once we have it once we actually move through this Is how you build open stack containers using the latest code well Pretty much that's one of the benefits of docker And that's the reason why we decided to containerize this stuff because you can go over and you don't have to be running any specific RPM distribution you can go over and install the RPM distribution if you want But you can also go over and just create grab a docker container Log in there and pull down the source code and do just the pip install Requirements and then pip set up build and that's pretty much it will go over and deploy everything for you Now how you go over and pass over The like parameters and all that kind of stuff. I'll go through it in a minute but in doing this stuff in in microservices is way easier because You will be able to put it on the CI pipeline straightforward. So every single time somebody makes a new commit they rebuild Right now. That's pretty much what they are doing in semantic the on the open stack team basically pushes something in there and some of the actual Scribes on the CI pipeline will build the docker container or will build RPMs Depending on what we're basically want to want to go and put in there Then it's easy to deploy through the CD pipeline The thing with Kubernetes is that once you create your template for Kubernetes for each of these open stack components It's just a matter of handing over that template to another developer and that's it He doesn't have to write it again. He doesn't have to modify it. It's straightforward. Just pass it over He'll initiate at the the the pretty much OpenShift Kubernetes deployment and Probably in a few seconds you'll have his own version or his own environment for the open stack components Second one is the pretty much you can use the same container over and over and over once you jump into container side Some people will go over and say well, it's pretty much the same way as doing packages Kinda The only thing is that it's way easier than doing over a devian file or doing over an RPM file Here is just like the same instructions that you have in open stack on how to download and contribute Just go into the container build it up and there you go after you build a container You just pretty much tag it into which environment do you want so you can tag it as development you can Tag it as my version one my testing version two or whatever it is Once you test it over you just pretty much change the tag or tag the container again Or actually the image of the container and we'll go over and say okay. It's now. It's ready for production at that point Kubernetes can and OpenShift can go over and say okay. I have a new tag that is ready for production I'm gonna start rolling it out So it pretty much moves the same way and you can actually align it to the releases for open stack and last for all Once you have it inside or you only see I pipeline pretty much is really straightforward to build a container So I'm gonna give some examples here Okay, so have time some examples of what is it that is happening here. So to build the Docker files There's something that you have to go through here sometimes you go and say okay I'm just gonna go into Docker hub download what is what is up there the fact that is in Docker hub And it is actually a container doesn't mean that will run on Kubernetes That's one of my problems that we went through because Kubernetes has a different way of using Docker Which is pretty much the it's similar But realizing some smaller components like using environmental variables to pass something into a container So if you go over and just pull down whatever you have from like open stacking Docker hub might run on your VM But that doesn't mean that will be able to go in putting there Same reason why we tried to go over and build it ourselves that way we build the containers ourselves We basically move it over to fit to fit the actual Kubernetes cluster And we can go ahead and move forward with it the other section The other thing is that um now that you're basically inside of the inside of this stuff Docker allows you to pass over multiple environmental variables multiple scripts and everything But how it is an easy way to go and set it up is that you create three scripts The installation script Then the configuration script and then the startup script pretty much are only wrappers around the act the the actual instructions So on the configuration script you just put it on that okay I'm gonna download git clone from OpenStack everything is in there once you have all your dependencies You call the order the installation script do Python set up that pie there you go And on the run script which is the actual script that runs Docker is where you start the actual service for OpenStack Passing all the environmental variables. So with that in mind, this is a small example. Can you guys see it? Increase it or not, let me just put it here Okay, there we go there we go So this is just one of the examples Like you see we're basically going over and saying from sent us we're using sent oh seven as the base container Then we just put the maintainer and then we started finding the environmental variables that we're gonna pass over to the configuration script Why we do this is because when you drop this stuff into Kubernetes The only way of setting it up your container or actually telling it you have to do this stuff is either you can grab Something from outside let's say to the tell the container download first the configuration file from somewhere or pretty much here All the environmental variables that I'm passing you configure your configuration file automatically before it actually runs So that's the reason why we have so many environmental variables But like I said, there's multiple ways of doing this then we pretty much just grab the installation the installation script for horizon that's the one that actually contains all the git clone and Pretty much pulling every single thing from from our git repository Then we have the configuration script and the startup script So as you can see When we build the image itself the one that we're running and the this section that is going down here That says running the install horizon all that kind of stuff That's what it gets executed when you're building the image and when you're doing the Docker build So by the end of that one you already have a container image with horizon install when we actually pass over the startup that is H is really more into okay Just call this stuff is going to start a patchy for us passing all the environmental variables at that point So these are really some of the just one of the examples, but all of the others is pretty much straightforward You just define all the environmental variables that you're having there You can put up your installation script your configuration script and then the one that actually calls this service I'm gonna go over through the next one Which is let me just put it up here Oh Here it is So okay before we move into that one Another of the things here is that I'm another the benefits is that for instance How do you do with services that pretty much are running multiple things like Nova? You have Nova proxy you have Nova API you have Nova conductor and you have the Scater and pretty much the scheduler what we did in that case is that we basically install Nova and on the startup script We just pass over the environmental variable of the service itself So the star script reads for instance when we do a docker run manually We do docker run Open stack Nova and then we pass over API and then all the other environmental variables that pretty much allows you to have Only one image that can spin up all the services from Nova itself Depending on which environmental variable you pass over you can actually go over and start this time I'm gonna put out Nova proxy or this time I'm gonna start up conductor or this time I'm gonna just put up Nova itself a Nova API So that's one of the other benefits that you can have everything in there And you don't have to rework your stuff in order to be able to spin up multiple services within the same within The docker in the container ecosystem. So once we have our containers itself We're gonna go and I'm gonna show you a little bit of a File there we go. So this is the actual OpenShift Kubernetes This is the actual Kubernetes OpenShift template that we use for Keystone So you can see here we have the deployment configuration which basically goes over and tells okay you know what we're gonna have a trigger every single time an image change and We basically just pass the URL of the image in there So our automatically gets in there we specify the number of replicas of Keystone that we're gonna be running So since it's inside of the Kubernetes world Each container becomes pot itself So you can go around have your container actually a pot that is sitting with the MySQL database and a separate pot That is going over and sitting with the actual Keystone service the thing that allows you this stuff this time is that The MySQL might not be able to scale because you have to do some magic tricks in there, right? But the in Keystone API you can pretty much just go around tell it instead of one replica here and 130 and Kubernetes automatically goes over and scales Keystone on the fly Since it's already a microservice itself, and it's only running as a Docker container it's pretty much just going over and grabbing the Docker containers and there you go Started so here is pretty much where we go and tell it We're basically running one keystone the keystone container itself We're putting the product and the ports that we're basically using for the admin and the standard port Well, not standard port But anyway, and then we pass over all these environmental variables that I was mentioned at the beginning that at the moment that the Keystone container starts and Kubernetes passes over these environmental variables. It will go over and automatically configure the Keystone.com and let it actually run with whatever settings that you want. So the developers can actually go and Change the stuff on the fly without having to like where is running or in which server I have to jump into it They basically just go into the actual Kubernetes cluster itself and just redeploy really straightforward with whatever they want to go and put So this is just one another example The file is kind of long because we pass a lot of the things in there But we're passing every single piece that requires in order to authenticate I mean in order to start the thing then after that we go over and tell it okay, let's we're gonna create the routes Pretty much a route allows the external services that are not within the the Kubernetes OpenShift cluster to access it So for instance if you have Client if you want to try it out with the Keystone client you create the route Automatically Kubernetes goes over and says okay this route that is gonna hit this a specific service they have here We'll go over and tell it send it over directly to the container. They don't have to worry about anything else It's just like going through the actual load balancer Hitting the actual system they have in the back then we have another separated There's a second route because since we have two ports. We're basically load balancing the We're load balancing the traffic between the each of the like replicas for those specific boards And it's pretty much the same way. It's just like we're gonna create another external access To go over and hit this service once you define that one you pretty much define here exactly what it's gonna be the service itself So you just go over and call it Keystone a or Keystone b or Keystone whatever Specify which is gonna be the port that you're gonna be going over and using at that point And then you can tell it over with the selector to which actual container are gonna be running. So Moving forward Here's the other example of the second Keystone stuff and then we have the parameter sections where we basically is just input field that Openshift creates where the developers go over and just like start typing down the parameters that you want and everything that you Have here will basically be passed over to the actual container when it starts So like I said, it's a little bit bigger long because it has a lot of different things that were basically passing over but The whole point of this that I wanted to show is that once you have it this one You just pass over the file and that's it or you just pretty much enable Openshift to go over and say I'm gonna share this template with somebody else And you just share the template across all your or all your users or to a specific user They don't have to go and do the rework or anything else So anybody that wants to go and deploy Keystone, it's just either UI One click and go over and put it or just grab this file and upload it to your to his own account in Kubernetes And that's pretty much straightforward So that being said We just go back to the presentation here real quick. This is how pretty much looks once we deploy it so as you can see there's Already in there. That's one of the services that we're basically specifying in there The other one is the second service each of them are basically going over and have their specific ports and The coolest thing here is that within the Kubernetes cluster itself if you want to go over and hit Keystone from another container Let's say that no is going to hit Keystone You don't have to learn the actual URL that you're using you just pretty much tell it the name of the service that you specify So if I'm inside of another container and I want to hit the Keystone API I just have to go over and like ping open stack Keystone dash a and that basically Kubernetes results automatically to the node that you're actually running that that specific container and passes over all the traffic into it So you don't have to worry about like oh, what's the URL now? What's the IP now? It doesn't matter at all doesn't matter if you just pretty much scale it down to zero and bring it back Pretty much the whole deal is that Kubernetes knows where it's like every single or microservice So he's able to route everything through it, which allows us to pretty much do like really quick deployments so And this is just like I said, this is pretty much just the kind of like the UI part of that we have in there Once if the like another another the developers wants to go and add for instance Nova Or he wants to go and do something with no or test something with Nova She has a matter of clicking on the other project They select the Nova template and pretty much goes over and gets deployed So now that we have that one in there, how I mean, I'm gonna go through really quick into how we basically got there So we created like I said one image per service We have one image for keystone one Docker image for keystone one for Nova one for glance one for horizon and one for cinder Then we push the images into our registry that we have internally We basically create the template only once and Once we have the template we can basically start sharing it up Then Kubernetes takes the template and starts deploying the microservices Anywhere where you want doesn't matter if like if you want to go and have your own Dev test and prop the user just gets in there Creates a dev project deploys the things into it gets again gets a creates another project in Kubernetes And goes over and deploy the things again And then creates another project and deploy the things again, but it's pretty much its own environment So you don't have to be fighting around resources or like who brought and who broke something or something like that You know it's pretty much really straightforward Then after that we have test test test and try to test and then you just promote it to the next environment how the promotion gets done Like I said with Docker tags We can go over and say I'll show you pretty much the pipeline how it runs in a minute Or actually the diagram at the end, but you'll be able to see That it's pretty much up to whether you want to use the releases of open stack and every single time you commit Something gets a new image built or you pretty much go over and run every single time you run a Jenkins job For instance, or every single time you create a new Docker image straightforward pretty much open shift and Kubernetes there They can go and execute the redeployment on any of those three or six scenarios So now that we have everything they're up and running Okay, so have time Now that we have everything up and running Allows us to pretty much simplify not only that section, but also part of the operations Because deploying an application within Kubernetes like I mentioned before it's just matter of creating a new image Kubernetes has multiple ways of deploying you can go over and recreate everything or you can do rolling updates where basically it's gonna go over and start replacing each of the Containers that he has so each of the pods until he gets to the actual version that you require on that a specific Docker image So moving forward on the rolling updates Like I said the way that pretty much set up said a new image gets created You deploy on the test project you tested it out Then you tag it as production or any other flag that you want to put it in place And then pretty much automatically Kubernetes gets redeployed There's a little bit of sometimes there's a little bit of a downtime But it really depends on like how fast Kubernetes actually spinning up the container which to be honest is really fast because usually Kubernetes goes over and tries to Prefetch the image and then it'll go over and actually start the container itself before killing the previous one So one of the thing is that I'm the two nodes that I put in there The upgrades means that you're actually upgrading the application SQL schema and that's something that we pretty much at cement that we went through it when we were moving from what was it Ice house to kilo. I think it was from ice ice ice house to kilo We had to pretty much go over and build a separate open stack Control pane to be able to move all the beams first through the load balancer and pretty much Built a separate control pane because we were basically moving forward from ice house to kilo, right? So we upgraded everything and On a new pretty much control plane and then the previous one We just moved all the eyepiece or all the pretty much all the beeps to point to that one And then we destroy the second one, but doing the actual schema upgrade. That's a whole different story So this is pretty much allows you to move forward And really fast but as long as like I said, you don't have to do much of a database schema You can still go over and tell it You know what coordinates when you're actually going to go over and deploy something execute a job Kubernetes also trying to hit me and hit the same way that um, it's kind of pretty much It's kind of like trying to hit the job scheduler part Messages really good at this stuff, but we're in it's just started to add those specific sections So for those only instances where you have to upgrade a schema or pretty much fail over something or all that Kind of stuff that is only once you can define a specific update job where you actually pass over the command that you're going to be executing I guess some some of the containers or a specific part and I will basically get in there Executed I mean using Docker exec and everything it will execute it itself and then we'll tell you okay I'm done then you can actually move forward with the actual deployment and the other thing is that I'm Depending on how you have it set it up Like I mentioned it you can go over and out of deploy or you can pretty much wait until okay I'm gonna sit down here and Go over and click the bottom myself. So it's pretty much depending on how you set up the deployment configuration It's you will basically go and do one or the other So at the end this is pretty much the open star architecture that we have The pretty much developer goes over and starts coding something That one pretty much we have three options. We basically set up the git hot in the Git repo webhook that basically every single time and you commit this in there. It's actually merge It will go until openshift Kubernetes. There's a new version of the code Openshift has Thing called source to image that pretty much takes care of grabbing the code directly from it Building the image for you and then having it stored locally in there So you can actually go over and redeploy it So if you really want something that is completely automated you put out the git rip on the git webhook As soon as the they literally as soon as they put merge works like a github webhook webhook pretty much the same deal git tells Openshift new commit is in there in place and openshift basically pulls down the latest code Actually pulls down that specific commit up to the up to that commit and starts building the image for you And then it will allow you to say, okay I'm gonna deploy it or not you already deploy it depending on how you have the configuration triggers in your application The second one is that we can go over and deploy things using the CI pipeline The same way that you'd have on the git webhook works There's a JSON webhook that you can pass over to anything as long as you just do a curl to hit the specific application that Kubernetes is giving you it will basically go over and do the same thing. I'm pulling down the new image I'm pulling down the new source build the image itself and there we go Or you can pretty much move it over until you your docker image after the CI pipeline is done You can build the image itself there and you can go over and push it over into your jet on registry at that moment same way OpenShift Kubernetes is basically querying your registry for all the images that you're using inside of the Kubernetes cluster So pretty much it will go and say, okay I have a new tag on this specific image that I just came out and I don't have that and that Mdi5 hash, so I'm just gonna pull it over into the actual into my Internal registry and then I'm gonna go ahead and deploy it automatically Like I said the triggers depends on when you're building and where you're gonna go over and deploy If you go around tell it as soon as a new image is seen there go over and deploy it New image gets in place and hit it seen there and then after that you will see that this is pretty much a small diagram of The architecture that is how it's pretty much running The service that we have here is like I mentioned at the piece of the load balancer that takes care of it that is managed by Kubernetes and then you have the pod which is the actual database inside of that database is a small container for the specific It's a small container having the The mySQL instance where pretty much keystone and all the other components drop their pieces in there So for if for some reason keystone goes down it takes its own database and it's not gonna affect anybody else It's not something that you have to worry about okay I mean you still have to worry like if you want to put a Galera cluster in the back or something in there But it's not something that will basically impact everything and that's one of the key What that's one of the purpose of microservices if you lose that specific microservice You won't impact the others because it's pretty much not you are not sharing any of the components And the whole piece in the middle is pretty much just the Kubernetes Network that they basically go out and allow the other components to just go and say I need to talk to Nova I'm just gonna go over and use the name of the service of Nova to talk to it directly I don't have to worry about IPS or anything else and Pretty much that's the whole reason why we decided to go over and start testing this out moving forward into it and Right now like I mentioned and we already have the pieces for Nova Keystone horizon Celerometer glance Congress and I don't remember which one is working right now Which are on their building but anyway, but pretty much they allow them to go over and say right And they're doing right now on the testing of what is better using keystone with Apache or a keystone with event lit So in order to test it out simple just go and deploy the actual Jason template from keystone Apache The other one of Jason of event lit and just pretty much benchmark it straightforward You don't have to go over and tell okay I'm gonna reconfure everything in there or put up an RBM or something like that because it doesn't even matter for from the infrastructure point anymore and with that said I'm not even sure if I'm still half less five minutes. Okay. I'm gonna leave pieces to Questions and answers any questions No, there are questions Since you put Open shift along with communities do we need both or No, I'm open shapes basically Coverned is with an extra extension that red hat bill for it, which provides like user management Security context the deployment section, but pretty much as Kubernetes So to start using this you need first open shift to be installed right before we can do anything. Yeah, based on what you have given Yeah, so the thing is that I'm Pretty much. This is almost like this is pretty much running an open stack on top of Kubernetes or on top of open Whichever way you want to call it, but and that's the and that's the whole thing a lot of the times here You go over and say, okay I'm gonna deploy my control plane and I have to go over and build BMS and I have to go and provision the BMS and just like a View or everything and replication and the load balancer and all that kind of stuff We're pretty much letting Kubernetes take care of that for us Since when you create the Kubernetes cluster, you pretty much allocate nodes at the beginning and just install Kubernetes Doesn't matter what you're actually deploying inside of it It will basically just load balance across all the all those nodes move them around and pretty much take care of All the other like infrastructure pieces for you Thank you Any of our questions? No, awesome. Well, thank you very much. I really appreciate your time and getting up early