SpringDoc OpenAPI 3.0 Swagger UI for Kubernetes | Centralized Swagger UI for all microservices

hi everyone in this video i'm going to show you how to create a common swagger ui using spring dock api which is based on open api 3 specifications as you see on the right hand side we have multiple micro services running now each one of these micro services need not carry the baggage of ui to only to expose the swagger ui right instead we can have a centralized ui which can expose the swagger ui by aggregating all the api definitions of each of these micro services now if there's a way if we can expose slash v3 api docs on each of the microservices which the centralized ui can leverage and aggregate all of them and show it at one common place the way it will look like is this on the local host basically this is the centralized url for the ui and this is the page which will be shown as you see in the drop down each of the micro services will appear as an entry in the drop down and you can switch back and forth between different micro services so whichever micro service is selected the corresponding api definitions would be shown on the screen now in this demo we are going to run everything on a kubernetes environment but you can if you want tweak the code little bit to make it work on any environment let's dig into the code so this is the source code for microservice1 as you can see it has a rest controller and api exposed it's a simple api which returns a friendly text back if we see the form for this uh it has the main dependencies the spring dock open api web mvc core what this dependency does is it exposes all the api definitions on a url by default which is slash v3 slash api docs which we just saw in the few moments back in the video now let's uh create a docker image of this uh application so what we are going to do is we would run spring boot build image so it will create the docker image for this application it's going to take some time till it builds everything so i'll pause the video here okay uh we're back see the docker image has been created for this uh let's go and check it out in the kubernetes so this is the docker desktop which i have it on my local so if i do docker images so there you go we have a docker image for the micro service one application now let's see another micro service which we have microservice2 the structure is pretty similar we have one rest controller which has a hello2 url exposed it's pretty similar to the microservice one it's just to give you a gist of you know how the apis can be uh it's a simple api but you can have as as complex as apis that you have in your application the palm is uh similar to what we saw for micro service one uh the important dependency here is the spring dock open api web mvc core so let's go ahead and build a docker image for this as well so again i'm going to run mvn spring boot build image for this this is also going to take some time so i'll pause the video here okay seems like the docker image has been created uh again let's go and check this time it's microservice 2 and we have an image for that so we have both our micro services set up let's take a look at the common ui application so i have this project called open api common ui let's take a look at the palm for this so it's basically uh it has a dependency on spring cloud starter gateway we'll have a spring cloud gateway uh we also have spring dock open api webflux ui which will serve the swagger ui for us uh since the application is running on kubernetes uh we have dependency of spring cloud starter kubernetes fabricate and fabricate config what this is used for is basically the service discovery on application startup it will uh discover all the services that are deployed on the cluster it will basically show all of them aggregate all the api definitions for them and show it on the ui now if we go into the source code it has a controller called swagger controller which is a rest controller the important uh api which is exposed is this now this this endpoint is really important this is the default endpoint which the swagger would start serving on when when you launch the application right if you see uh the method uh basically it uses the discovery client which is nothing but this uh discovery client object it discovers all the kubernetes services which are deployed now essentially what it's doing is it basically gets all the services and filters out the cube cube related uh services right so there are kubernetes native services which are running such as kubernetes cube dns and stuff we don't want uh to expose all that using the swagger api so what i'm doing here is filtering all those out and for each of the rest of the services what i'm doing here is uh creating an api uh basically a url with the endpoint b3 slash api docs which the microservices are exposing which can return the api definitions so the central ui would have all the micro services urls configured at the central place and we'll see how it serves up on the ui let's go ahead and build a docker image for this as well so i'm running mvn spring boot build image again this is going to take some time so i'll pause the video here okay seems like the docker image has been created for this let's go ahead and verify that okay now we have docker images for all of them two of our micro services as well as the common ui uh let's go ahead and deploy this so if i have to see what what applications are deployed already i'll run the cube ctl get po as you see there's nothing deployed as of now uh so let's go ahead and one by one deploy our market micro services so first i'm going to run a command cube ctl create deploy micro service 1 using the image that we just created so i'm doing everything from the command line but if you wish you can create a deployment and a service cml file and do a cube ctl apply on that but for this demo i'm going to stick to this command line so it says app created so we see the pods here so let's see the logs for this so as you see the application has come up cleanly there's no errors that you see on the console now let's go ahead and deploy the microservice to application for this i am going to run the cube sql create deploy command again for the microservice 2. it says the app has been created let's take a look at the logs as you see the app has come up cleanly in this case as well so both our micro services are deployed now what we'll do is create a kubernetes service for each of these right so now what i'm going to do is run a command called cubectl expose deploy microservice1 with the name of microservice1 what this will do is create a cube kubernetes service which serves the microservice1 application okay it's created now i'm going to run the same for micro service 2 application which will create the service for micro service 2. okay both services are created if i do cube ctl get svc i see the micro service one and micro service to service now both the micro services are deployed let's go ahead and deploy the common ui i'm going to run a command the create deploy command again but this time for the common ui and the image that was generated when we built using springboard build image okay this has created the deployment let's go ahead and see the logs for it as you see the application is starting up and it says started the application seems to have started now okay so both the micro services are deployed and the common ui is also deployed now let's take a look from the browser how it looks but before that uh let's do a port forward so that we can check it out from the local host so what i'll do is cube ctl port forward deploy common ui port 8080 so what this means is uh on localhost 8080 the request will be served on the common ui deployment which is running inside the kubernetes okay so now when i launch the browser and say localhost 8080 you see this swagger api came up and in the drop down here i see two micro services so by default the micro service one is selected now if you see here the generated url and it shows the api here which is the api slash hello one if i want i can go ahead and try this out if i say try out and say execute it says hello world from one if i want to pass an id let's say test and then execute it says hello test from one so so the api is kind of working now i can switch the to the other micro service which is micro service 2 so it brought the details of the micro service 2 and you see here the api changed to hello too again i can go ahead and try this out i can say hello and it will work as it is so you see the power of this central ui right it aggregates all the micro services in one place that kind of keeps the micro services lightweight and all the ui heavy lifting is done here important thing is each micro service has to expose the api which was which we exposed at slash v3 api docs which you saw in the code moments back right now one important thing which i would like to point here is uh if we are using some kind of reverse proxy or an api gateway which we are doing in this case right now uh the important thing to show you is this piece in the bootstrap yaml the server dot forward header strategy has to be set to framework otherwise uh this thing uh the servers url would not have this uh the reverse proxy the context path basically it will not show that and the api even though it will be listed here it won't work if you try it out and see if it executes fine that server dot forward header strategy has to be set in the ui as well as each of the micro services so if you go ahead and see the micro service resource application properties uh the server forward had a strategy set to framework here as well uh other than that this is the ui uh if you see here cloud kubernetes discovery has been enabled and all name space was set to true this is important if you have micro services deployed in different name spaces within the kubernetes cluster so having all name space as true enables it to discover the services irrespective of which name space it's deployed to uh this is the standard gateway routes that are mapped so if you see micro service one is mapped so the context part micro service one if the request comes there it will redirect uh the request to http micro service one colon 8080 now this http colon micro service one is the service kubernetes service uh this is how you basically do the dns uh for the services running on kubernetes so if you would have uh deployed this on a namespace other than the default you would have to mention some other namespace whichever namespace you had deployed that over here but since we had the default name space we don't have to specify them okay that's all i had for the demo uh hope you enjoyed the video we saw how each microservice exposed the api slash v3 api docs and the central swagger ui aggregated all the api definitions to show the on the browser the page like this right where each micro services are listed on the drop down so thanks for watching the video uh do subscribe to my channel if you liked it and uh like the video if you enjoyed it thank you have a good day bye

Channel: Visa2Learn

Views: 5,346

Keywords:

Id: dhzPado-P0c

Length: 16min 50sec (1010 seconds)

Published: Sat Nov 06 2021