1. Home
  2. Training Library
  3. DevOps
  4. Courses
  5. Developing Cloud Native Applications with Microservices Architectures

Blue/Green Deployment

Developed with
Red Hat
play-arrow
Start course
Overview
DifficultyBeginner
Duration2h 24m
Students405
Ratings
3.5/5
starstarstarstar-halfstar-border

Description

Do you have a requirement to identify the right frameworks and tools to build your own Microservices Architecture? If so this course is for you!

In this course we'll teach you how to combine different frameworks and tools into a microservices architecture that fits your organizational needs.

You’ve no doubt heard about the microservices architecture, but understanding and executing it can be a bit of a challenge. Through a series of videos, this course will introduce microservices, review multiple microservices frameworks and runtimes, and show you techniques to deploy them through a hassle-free DevOps pipeline. We’ll discuss containers, Docker, Spring Boot, NodeJS, .NET, OpenShift, Jenkins, Vert.x, Kubernetes, and much more.

Transcript

If you remember earlier in our conversation, we talked about the fact that there is a whole lot of steps in your journey to microservices. We kind of quickly ran through DevOps, and things like elastic infrastructure. We did spend a fair bit of time with things like Kubernetes and CI CD, as a good example, deploying pipelines. 

But now we really want to drill down on this concept of advanced deployment techniques, because there are somethings which you can try right here on your laptop, taking advantage of the technology we provided. that really kind of, really help you understand how certain things can happen at a production environment. So, think about going super-fast to production, what does that mean? 

And what happens if you break things in production, and can you roll them back easily? And the idea of the Blue/Green deployment is exactly that. The idea being that if something happens at the SCM level, right. So, I do a git push I do a git commit, git push I do my SVN check-in, whatever you have done, you have updated the source code. And in theory you have an automated deployment pipeline, as you saw earlier, that will grab that component, grab that change to your source code, actually do build of it, maven build, and of course a Docker package, if you go around it. and move it from Development to QA to Staging to Production. 

The difference here is, in Production we have two production environments, we actually have a Blue and a Green, and right now you can see that the Blue is the active one. In other words, the router, the load balancer, is focussed on Blue, and all our user traffic is focussed on Blue, and the last build that comes in lands on Green. And when it is on Green and happy on Green, we just switch the router. It is real simple, right? We switch the router and if Green for some reason is bad, we, the users are complaining, the Twitterverse is blowing up, people are complaining about our service, I can switch right back to Blue. So, the concept of the Blue/Green gives you a lot more, a lot more assurance, if you will that when you do make your super-fast, you know, we are deploying ten times a day, or 200 times a day, that you are not breaking things. 

And if you do break things, you can easily roll back, that is the concept of Blue/Green deployment. We have a demo of this, and I want to show it to you because it is all part, again, of that presentation, that set of instructions here. So, let’s go Blue/Green, okay. We define how do Blue/Green set up on OpenShift specifically that uses routes or services. 

So, we are going to mess with the route option. Route sits on top of services, and you can also do the service option, they kind of work about the same way. Again the configuration is all defined here. Let’s kind of go look at our environment. Let’s go see, all right. We have our, okay. All right. So, we are going to focus on the API Gateway here, and let me bring this guy up, and bring this guy up, ./poll_api-gateway.sh, alright. 

So, there it is, and nicely we have Aloha corrected now, in use. So, there is our, that is the system that we had running, right? And again they kind of runs there for us. Let’s go look at our code based for this. Let’s see if we can actually find it. We don’t, we need to find it. All right. So, Aloha, we want api_gateway, here we go. CamelRestEndpoint and, oh, it is over here. All right? See here where it says New? We are not going to call it New, let’s just simply call this Blue. Okay? 

We will call it Blue, and so we have updated the code, we are not going to the whole pipeline in this case, we are just going to do, we are going to make a manual overwrite super quickly. So, I am going to go over here to my code base. And so I am in the right directory, here it is. Standard maven directory, so mvn clean compile package. So, we are doing our compilation of that. That produces that fat JAR, as before. And much like you saw earlier, you could do the docker build and all that sort of thing. In this case we are going to use the oc start-build and I think I have run it before. So, there you go, oc start-build and we are updating the Blue, remember we have both Blue and Green already provisioned. So, we are up, so, Green is the one in this live right now. 

That is the one that is reporting back over here, so there we go. It is working away. And we are doing our Blue build right now, so there it is doing a Blue build, let's look at our OpenShift Console, let’s find our Blue up here. There it is, you see that build is occurring, right? Now it is doing a rolling update of Blue out to production right now. But if we look back over here, and here, nothing is happening. Okay? 

From a user’s standpoint, it still sees the old code, right? It does not see the fact that Blue is actually being updated because it is technically still on Green, right? That is the whole magic of this idea. You can actually get up there and fix Blue, in this case, to make it exactly you want it. Test it, have employees hit it, if that is what you want, and then, when we think it is all good, flip it so that the users see it. 

So, let’s go and do that. And again, this is all documented in that document we mentioned earlier. But I think I have the route patch here, let’s see, there it is. And let’s make it Blue. Okay. And flip over here, and now we are Blue. So, the user is seeing Blue because that is what we did. We made that code change. Let me go look at my user interface, go over here, all right. 

We are Blue and then, all of the sudden Marketing comes screaming in: Oh. My God, someone updated this software we don’t want it to be Blue. You can say: Oh, no problem. I know your requirements said otherwise, but we will fix it for you right now. And then you are back to the Green environment. So, that is the beauty of the Blue/Green deployment architecture and of course it is super easy to set up. 

All the instructions are listed right here in our documentation. You can see it is pretty straight forward. We just set up a separate Blue deployment configuration, and then all we do is flip the route back and forth between the two. 

So, that is Blue/Green, but we have yet more to show you. Stick with us. 

About the Author

Students27597
Labs32
Courses93
Learning paths22

Jeremy is the DevOps Content Lead at Cloud Academy where he specializes in developing technical training documentation for DevOps.

He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 20+ years. In recent times, Jeremy has been focused on DevOps, Cloud, Security, and Machine Learning.

Jeremy holds professional certifications for both the AWS and GCP cloud platforms.