Check out a free preview of the full Enterprise DevOps & Cloud Infrastructure course

The "Deploying a Service" Lesson is part of the full, Enterprise DevOps & Cloud Infrastructure course featured in this preview video. Here's what you'd learn in this lesson:

Erik walks through deploying the service repository to AWS. When code and docker images are committed in the developer repositories, a GitHub action connects to AWS and pushes the image to ECS.


Transcript from the "Deploying a Service" Lesson

>> So, when we talk really quickly about what we've done so far, we've done Terraform Cloud Automation, Dynamic Configurations, VCS Tracking, Source Control Automation, Cloud Infrastructure Automation, Service Infrastructure Automation, Service Repository Automation, and now we want to see if we can actually deploy this service really quickly and check if it's working.

So, I'm going to close a whole bunch of stuff here. Just to give myself some, some space, right? And I'm gonna go to console that and I'm going to go to my cluster right? And look at this. I have a task running but it's actually not working all right, it's a it's a failed deployment at the moment.

And the main reason for that is is because, can anyone guess? We created the service before we push the image. Right another chicken before the egg scenario. Now at hippo, we let it fail. We let it fail, and you might say, well, why do you do that? Why do you let it fail?

That seems like a bad idea. We let it fail even in prod. I may even sound like a worst idea. Why do you do that? Well, we do it because realistically, if it's not working in product, it kind of doesn't matter. [LAUGH] It's just a dead service. You know what I mean?

It's not really taking resources for us or anything crazy like that. So, realistically, it can be dead, like, it's fine but the moment somebody does what I'm doing right now, which is, all right, I'm a developer, cool, all right, let me create my pull request, right, awesome, cool, I got all my code, I know my pipeline's in here.

Cool. Again, we know that the registry name is right. We know that the repository let's check the repo cool. Let's go check that really quick. ECR. This time if I go in. Sure enough, there it is. But if I click here, no images, right? Nothing. So it's just, it's just in a failed loop essentially.

So what we do is we go back here take a look at anything else and this also needs access keys. Interesting. So not only do we need access keys for Terraform to create resources but we're also gonna need access keys on Google to then make it so am sorry on GitHub so that GitHub can then deploy your service, right?

So to do that, you're gonna go to settings, you're gonna go to secrets and variables, and then actions. This gives you the ability to add environment secrets, repository secrets, variables, all that other stuff. And this is what we wanna do. We wanna add some new repo I'm sorry, we wanna add a new repository secret.

So we're gonna click on that and then we're gonna do exactly what we did in the other place. We're gonna say AWS access key id. And again, let me do this off screen real quick. So I'm just gonna add that and hit add secret again. I know you can't see that, but now if I bring this over here.

You can see that my access key has been added, right? And do the same thing again for my repository secret for my other two. So I'm gonna hit New Repository Secret. I'm gonna do the same thing for the default region, as well as the secret access key. So AWS, I know you can't see it, but default region, US West 2, right, cuz we need to make sure that we're pointed to the same region as our other stuff.

And then new repository secret, AWS secret access key. Cool. Grab that, And close that. Cool. Go here. Add it and commit it, all right? So now I have my three environment variables that my pipeline needs. Access key ID default region and secret access key so now what I'm going to do is I'm going to merge my code so the repo is fully set up now I'm just gonna squash and merge.

Now, you'll notice that it doesn't run on this branch. That's because at the moment, this isn't meant to run on this branch. We're not worrying about that right now. If you wanna add tests to it. You've got the the template right there we're just running it on main for now but what I'm gonna do is I'm gonna go and all right let's see what's happening look at this we have two separate things happening and whoa what already finished update-ssm and build-push-docker.

So we have two separate jobs that have two separate things that they're trying to solve here, and I want to be very clear with that, right? We don't necessarily want to, but you might want to bind the config update after the push. That's up to you. If you do, you can.

But this is a good example of, like pushing to one location versus updating something in another location, and you can have multiple repositories or multiple workflows to handle that, right? Now, if you'll notice after we built, look at that, something else popped up here. So what we decided to do in this repo was to say, well SSM or the secrets, those can be updated whenever we want.

But we wanna make sure that the build and the restart doesn't happen until after, right? So this I wonder if something was missed, so this might be a bug. I'm not really super worried about it. So what I'm going to do instead is, is if this fails, which is fine cuz we pushed our image.

Let's go to ECR really quickly, or ECS, I should say. And look at that. I didn't even have to do anything. And because we pushed the image to ECR, and because ECS is trying to constantly restart it, once the image got pushed and it was able to notice that that image got pushed once it restarted it pulled in the image and it started running.

So what does that mean? Well, that means technically I should be able to try and see if I can navigate to this now. So I go to ECE to load balancers. And in here I should have a load balancer for my cluster. And I have a few of them already but I could see here this is my most latest one and if I click here I can see my DNS name at the bottom.

I'm gonna copy this DNS name and I'm gonna do a curl now you'll notice I've already put this curl in here but what I'm essentially doing is, I'm saying, hey, I wanna make a request to this load balancer, but I don't have this domain necessarily routable yet. So, let's just pretend like this is the host that we're going through, and let's make a request.

And you'll notice that says, hey, message not found. Now that's a little interesting, so let's take a look and see what's going on. So I'll go to target groups go down here targets cool my targets there all right so then let's go back to load balancers and let's go to listeners and rules.

We've got two rules I didn't name my domain right because I said service prod here but the actual is ECIE riner. So let me go like this, right, because I'm really just locating my cluster. Hey, there we go. So now what did we just do? Right? Let's talk about it one more time.

We, set up Terraform Cloud Automation, Dynamic Configurations, VCS Tracking, Source Control Automation, Cloud Infrastructure Automation, Service Infrastructure Automation, Service Repository Automation, which now enables developers to go in, push changes, immediately goes to production once it's merged, right? And it's also navigatable and routable now. So when you do this, you should be able to achieve the same thing.

Now I wanna note that the hostname and my name here is just for this course, right? Realistically, it would be like a service or something like that. But again, as I said before, we wanted to try and make sure that you all could do this as well. And so this just makes sure that the domain, if we used a real live domain, we wouldn't have conflicts, right?

So that's just one thing to note why this looks the way it does. How you set up the domains and all of that, it's in the infrastructure automation. So choose it as you as you please. Okay, cool. So if we do a git status really quickly, we are in our TerraForm TFe.

We'll say git checkout main, Paul main at this point, guys. We've basically built all of the main infrastructure deployed the service and accomplished the main goal of what we wanted, which is to create enterprise cloud infrastructure and have deployed services through it. Okay, so that's amazing. We achieved a lot and if you really think about what we've done in probably just today alone, you would imagine might take you weeks depending on it.

So this is really the power of automation.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now