 Hello, my name is Cesar Savedra. I'm a Technical Marketing Manager here at GitLab. In this short presentation, I will give you an overview of the ECS task definition from local JSON capability introduced in GitLab 13.3, which was an improvement to our GitLab's ECS deployment template. This new capability introduces the ability to update the task definition of an ECS service with a JSON file defined in your local repository. But before we jump into this new capability, introducing 13.3, let's quickly revisit how you set up an ECS cluster and also how you integrate it with GitLab. So if you check out our documentation for our integration with ECS, you will notice that you actually need to define three variables in your project, ECS cluster, service and task definition. And in my case, I have this project. And here I have ECS cluster, which is called Cesar Savedra ECS cluster that I already defined and I'm sorry created. Then you have ECS service. In this demo, I'm going to be talking about the ECS service that is for Fargate. And that's the environment of this variable is going to be review wildcard environments. And then the task definition, which is called Cesar Savedra Spring Task Def-F. So those are the three variables needed. Obviously beyond that, you also need the AWS access key region and secret access key to be able to connect to AWS from the runner. One more thing you need is the AutoDevOps platform target. I have AutoDevOps enabled here because I'm using the ECS deployment template. And in this case, I've defined the value to be Fargate so I'm going to be creating a Fargate target task definition and a Fargate ECS service. I have duplicates here because they are targeted to different environments as you can see. The next question is how do you create, you know, you have to create ECS service, the cluster first service task definition. So one way to do it is, you know, following the AWS documentation. And the first thing that personally I create is the task definition. And the task definition is a description of what's going to be in a container that's going to be running as a service in ECS. So you follow the instructions. They actually have launched wizards in AWS. So you can just go through each page and define the values as, you know, per the requirements of your application. Then the next thing I did was create the cluster. And again, their instructions on how to create the cluster. And I chose EC2 Linux plus networking. And then after that, I created an application load balancer that would take in traffic from the Internet and route it to a specific ECS service. In this case, I have an ECS service per environment. So I have three load balancers. And then finally I created the ECS service. And they actually, you can follow the documentation as well as the wizards that the AWS provides. So let me show you what it looks like. That looks like once they are created. So here is this ECS cluster. This has three services. I have three environments. So my production environment is actually deploying my application to this running service. I have another branch for review, which is this one here. The review that starts with a two rollback. That environment is being deployed to this right here, to this service. And the Fargate based service is being deployed to this instance here. The first iteration of our integration to ECS was the ability to deploy from GitLab to ECS through the pipeline. And it looked kind of like this. So here, so this is a pipeline, a deployment pipeline. And it's building this application here that happens to be a Java spring sample application. And then it deploys it to Fargate to, it's basically deploying it to this service. Okay. And it's using the task definition names, CSA better spring task depth. So these are the parameters that are being defined in the environment variables of the project to the cluster, the service name and the task definition. The improvement introduced in 13.3 to this integration is the ability to actually have the content of the task definition, which is right here. Let's open the one from Fargate, for example. We can pick the last one here to have this file, this JSON file defined and actually declared within your project. So what we're going to do in this demo is we're going to be creating a file and the file content will be the task definition. And then when we do the deployment to ECS, the deployment will use that file that you created here in your project to push out the deployment to ECS. Instead of just reusing the one that was already here. Okay. And, you know, this allows you to manage your definition file, task definition file within your project. You know, you get the version and obviously you can, you can, you know, track the changes. You have stakeholders collaborating in Mars to modify and update the task definition file and also the streamlines streamlines your deployment to ECS, making you more productive as a developer. So the next thing I'm going to show you is how the pipeline looks like. So the pipeline here is super simple. It just includes a template, which is basically the GitLab's ECS deployment template. There's a bunch of variables here to disable a lot of the tests that are included in the auto DevOps pipeline. So if we look at the deploy ECS GitLab here, this contains five stages and it includes actually it is setting up the DevOps platform to ECS, which is not going to be used. I'm using, remember, I'm using Fargate in the project. So that's going to be overridden. And then it includes these two templates. And the one of interest here is this one here. And this template is actually the one doing the deployment. There are different types of deployments. It could be just a production ECS, production Fargate review Fargate review ECS. There's those four options. And what it's really doing is doing an ECS update task definition. So it's going to think of it as going to be replacing the running service by applying the new task definition file from your GitLab project. So let's start making the changes then. So in this case, let's add the task definition file to our project. So first let's create a directory. And then inside that directory list, create a new file. So how did I go about creating this task definition file? Well, one way to do it is to actually go to the AWS documentation for ECS task definition creation and copy the template and then adjust the template. According to your application needs. And then use that as the content of the file that you will be storing in your repository, which is this one here. But what I did was, which is another way, is to use the Amazon ECS task definition console. You click on create task definition, you select Fargate. And then you follow the wizard entering the name of your task definition, the requirements of your application and container. Then at the end, you can click on this button and it will give you the JSON file for all everything that you selected through the wizard. You can copy and paste that JSON onto here. Now what I did was I copy that JSON, but that JSON needs to be slightly modified. This is the original JSON that I copy and paste it. And one thing I had to do is delete every single line that had a value equal to null. So this is the before and after. So notice this file has no null values. Another thing I did was I had to delete the section that says repository credential. So I deleted this so it wouldn't get in the way of the runner correctly signing into the AWS ECS environment. And the last thing I did was I had to make sure that the AWS log groups had the location of the task definition that we were replacing. So think of this as the before and then the new we're replacing that task definition with this new one. Something to keep in mind here though is that you need to keep the log location the way it was for this to work. All right, so the next thing that we need to do here is actually define a variable. And the new environment variable needs to be CI AWS ECS task definition and then the value is going to be CI. And then the file name is TD ECS Fargate.JSON. Oh, and then we want this to be used there. TD ES Fargate.JSON. Right now I have a running service under one of my environments under this environment, which is the one I want to affect with this change is a spring is here in blue background is blue. So just make a change for the of the background. And one more thing is that if we go to the cluster right now this this is a service name that I'm trying to redeploy will be redeploying. And the task definition is C Savedra spring task def F for Fargate. So after the deployment, this task definition name will change because the new name will be will be this one right here. So the new name will be C Savedra Fargate task def dash F not spring. Notice that this is a new name. Okay. And I'm showing you this so that you can see the difference once the deployment happens. So let's make a change to the code so that we can kick off a pipeline. We need to go here. Let's just go to Web IDE. And let's make a change. We'll make this will turn this to brown. And then we also need to change it here. All right. So then we commit the changes to the same branch. And this is going to kick off a pipeline, which is going to build and it will deploy to Fargate. Now that the pipeline is done executing. Let's go into the review Fargate job and notice that it succeeded. The task definitions has been updated with the file from our project. And let's check on the Amazon ECS. And here, as you can see, the ECS service dash F here as before no longer has this C Savedra spring task definition F. Now it has the C Savedra Fargate task def dash F and version number one. Because this is the first version of this task definition that has been applied to this service. If we look at the tasks, notice that the new task is on its way up. So we need to wait until it's in a running state for us to see the newly deployed web page. Now that the Fargate service task is up and running, we can go and check the web application to ensure that the changes that we applied earlier have been deployed and are successfully up and running. And there it is. This is the updated background. So the changes have been deployed using the new task definition file. By the way, just as you, you can use and declare a file, a JSON file here. Another way to provide the JSON file for the task definition is to do it as a variable. So in that case, you would come to the variable here, variable section. And here you can actually paste the content of the JSON file here and make sure that you change this to file. And that should also work. So in conclusion, in this technical demo, we have discussed the new feature ECS task definition from local JSON. And having the task definition file on your GitLab repository allows you to maintain its versions via our version control and collaboration capabilities, have other stakeholders collaborate on the task definition configuration and development, rollback to a previous version of a task definition, and can also help you with your organizational audit and compliance of your ECS container definitions. So I hope you enjoyed this video and I'll see you next time. Thank you.