- \n
- ASP.NET Core with GitOps: Dockerizing an API on AWS EC2<\/a><\/li>\n
- ASP.NET Core with GitOps: Deploying Infrastructure as Code<\/a><\/li>\n
- ASP.NET Core with GitOps: Orchestrating Your Containers with Kubernetes<\/a><\/li>\n<\/ul>\n\n\n\n\n
The first article of the series explained how to create a Docker image of your ASP.NET Core WebApi and deploy it to an existing server. This ensures that you can deploy your application to any server, without having to worry about the software that is installed on it; but you still had to create the server, configure it to accept traffic from port 80, connect to it through SSH and run the Docker image. To follow along with this article, make sure that you have created the Docker image and pushed it to Docker Hub.<\/p>\n\n\n\n
By the end of this second article, you will learn how to create your EC2 instance through code, with all the necessary configuration, and deploy the API as part of the process. As explained in the first part of the series, this reduces the risk of your application working in one environment, but failing in another, since you ensure that you always have the same configuration in all environments.<\/p>\n\n\n\n
Understanding Infrastructure as Code and CloudFormation<\/h2>\n\n\n\n
Infrastructure as Code (or IaC) is a way to manage your servers, networks, and other elements of your cloud infrastructure, by writing code instead of manually configuring them.<\/p>\n\n\n\n
Most IaC tools offer a way to define your infrastructure by writing in a language like JSON or YAML, in which you can create reusable templates that you can deploy in the cloud. There are many IaC providers out there \u2013 Ansible, Azure Automation, Google Cloud Deployment Manager, AWS CloudFormation, etc. Since this series follows all the concepts using AWS, the IaC deployment process will be performed using CloudFormation. However, even on AWS, you can choose other providers, such as Ansible or Chef.<\/p>\n\n\n\n
As you will see in this tutorial, CloudFormation<\/a> works with something called stacks \u2013 simply put, collections of resources that you can manage as a single unit (you can read more about it here<\/a>). CloudFormation currently supports two file types of configuration files: JSON and YAML. The documentation always shows examples in both languages, but the rest of this series will use YAML, as it contains less noise than JSON, making it easier to read and understand.<\/p>\n\n\n\n
Each resource has a name, a type, and a list of properties \u2013 you can configure resources the same way you would do from the AWS Console. After creating a stack, managing the resources inside it is as simple as updating the file that defines your infrastructure and then performing an update<\/em> command \u2013 this will create any resources that you added in the meantime, update the existing one if necessary, or delete those resources that you eliminated from your code.<\/p>\n\n\n\n
Cleaning up is also easy, as deleting the stack will remove all the resources that were part of it, making sure you are not susceptible to any additional costs by forgetting to delete a resource.<\/p>\n\n\n\n
What about Elastic Beanstalk?<\/h2>\n\n\n\n
If you are familiar with AWS, you might have heard about Elastic Beanstalk (EB). If not, you can find an introduction to it here<\/a>. If you compare its features with what you will learn in this tutorial, it might seem that writing Infrastructure as Code is redundant, since there is a service to do it for you out of the box.<\/p>\n\n\n\n
Depending on your purposes, EB might be the way to go for you \u2013 it is easier to setup, it offers the scaling capabilities that are going to be touched in this series, and it doesn\u2019t require low-level management of resources.<\/p>\n\n\n\n
The reason to use CloudFormation instead of Elastic Beanstalk is being able to have your infrastructure in one place, as a single source of truth, and having the possibility of deploying that anywhere, while also being sure that it will have the intended result.<\/p>\n\n\n\n
Prerequisites<\/h2>\n\n\n\n
Before moving on with CloudFormation, you will need to install the AWS CLI<\/em> on your machine. This will give you access to working with your resources from the terminal, instead of needing to use the AWS Console in the browser. You can find installation instructions for your OS here<\/a>. Note that if you install AWS CLI version 2, you will need to change all the commands in the article from aws to aws2.<\/p>\n\n\n\n
After successfully installing the CLI, you need to set up an IAM user that will be used to work with your resources.<\/p>\n\n\n\n
First of all, open the AWS Console<\/em> and search for IAM<\/em> in the Find services<\/em> box.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2019\/12\/word-image.png\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
Then, select Users<\/em> from the left menu and click the Add user<\/em> button.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2019\/12\/word-image-1.png\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
Pick a name, like console-user<\/em>, for the new user, and check the Programmatic access<\/em> box. This allows the user to perform actions through the AWS CLI, among other tools from AWS, but it cannot be used to login to the Console. Then, click the Next: Permissions<\/em> button.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2019\/12\/word-image-2.png\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
This page allows you to select which actions the user will be able to perform and what resources it can access; it is a good security measure in case someone gains access to your user. Select the Attach existing policies directly<\/em> and select the AdministratorAccess<\/em> policy; keep in mind that you should not be doing this in a production scenario, but AWS policies can be tough to work with, so this works for testing purposes. Click the Next<\/em> buttons and then Create user<\/em>.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2019\/12\/word-image-3.png\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
You should now see your newly created user, an access key ID, and a secret access key. In your terminal, run the
aws configure<\/code> command, then paste the required values. For the region, you can use the one that is closest to you from this list<\/a>, such as eu-central-1<\/em>.<\/p>\n\n\n\nMake sure that you have also pushed a Docker image to Docker Hub following the instructions in the first article<\/a>.<\/p>\n\n\n\n
Deploying a Single Instance<\/h2>\n\n\n\n
The first step of deploying your Infrastructure as Code is to find out which resources you need to accomplish your goal. The goal, in this case, is to create an EC2 instance and deploy the previously created Docker image on it.<\/p>\n\n\n\n
Once you are aware of what you want to create, the easiest way to gather information is to check the CloudFormation documentation<\/a> for that resource. Going through the list of properties for the EC2 instance, you can see that none of them is required.<\/p>\n\n\n\n
To create the same instance from the previous tutorial, you only need to provide the instance\u2019s image ID. To find the current image ID, go to the EC2 Dashboard and click Launch Instance. Scroll down the list of images until you see the free Ubuntu server. Copy the image ID and save it because you will need to supply it in several scripts.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2019\/12\/word-image-4.png\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
Click Select to see the sizes. In this case, note t2.micro,<\/em> which is the free tier. You will be creating your new instance from code, so you can cancel out of the steps after collecting this information.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2019\/12\/word-image-5.png\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
To write the code to deploy this instance, create a new file called infrastructure.yaml<\/em>. This is all the code you need, considering you want to deploy an EC2 instance similar to the one from the previous tutorial. Be sure to replace the
ImageID<\/code> property with the image ID you found on the site. Note that you will need to do this each time you copy in a new version of the MainInstance section.<\/p>\n\n\n\nDescription: Creating an EC2 instance.\nResources:\n MainInstance:\n Type: AWS::EC2::Instance\n Properties:\n ImageId: ami-0ac05733838eabc06\n InstanceType: t2.micro<\/pre>\n\n\n\n
After saving the file and modifying the file path if necessary, you can run the following command to deploy your instance to the cloud:<\/p>\n\n\n\n
aws cloudformation create-stack --stack-name dotnet-docker --template-body file:\/\/infrastructure\/infrastructure.yaml<\/pre>\n\n\n\n
This will return a
StackId<\/code>, so you know the operation has started \u2013 it does not mean it was successful, though. The output will look similar to this:<\/p>\n\n\n\n![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2019\/12\/word-image-6.png\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
To check on your deployment status, go to the AWS Console and search for CloudFormation<\/em> in the Find services<\/em> box.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2019\/12\/word-image-7.png\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
As the stack only contains an EC2 instance, the deployment will complete quite quickly, so you should already see the CREATE_COMPLETE<\/em> status for your stack.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2019\/12\/word-image-8.png\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
You can click on the stack name and choose the Resources<\/em> tab to view all the resources inside the stack.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2019\/12\/word-image-9.png\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
Before pulling and running the Docker image, there is one more thing that needs to be taken care of: allowing the instance to receive (only) HTTP traffic, but to send any type of request. Since you did not provide any security group for the instance, the default one is used \u2013 any traffic, to and from any port is allowed; however, this does not provide the level of security and control that you might want for your application.<\/p>\n\n\n\n
In the same infrastructure.yaml <\/em>file, you can define a new resource, SecurityGroup<\/em>, and then reference it to the instance. However, that is not the only resource that needs to be created, and this is one of the situations where trial and error will lead you to the result. To set the inbound\/outbound traffic rules, you need a security group.<\/p>\n\n\n\n
MainSecurityGroup:\n Type: AWS::EC2::SecurityGroup\n Properties:\n GroupDescription: Security group for the API instances.\n VpcId: !Ref VPC\n SecurityGroupIngress:\n - IpProtocol: tcp\n FromPort: 80\n ToPort: 80\n CidrIp: 0.0.0.0\/0\n SecurityGroupEgress:\n - IpProtocol: tcp\n FromPort: 0\n ToPort: 65535\n CidrIp: 0.0.0.0\/0<\/pre>\n\n\n\n
The security group must link to a VPC<\/a> to define outbound rules.<\/p>\n\n\n\n
VPC:\n Type: AWS::EC2::VPC\n Properties:\n CidrBlock: 192.168.0.0\/16\n EnableDnsSupport: true\n EnableDnsHostnames: true<\/pre>\n\n\n\n
To have your components accessible from the internet, you need an Internet Gateway<\/a> attached to your VPC.<\/p>\n\n\n\n
InternetGateway:\n Type: AWS::EC2::InternetGateway\n InternetGatewayAttachment:\n Type: AWS::EC2::VPCGatewayAttachment\n Properties:\n InternetGatewayId: !Ref InternetGateway\n VpcId: !Ref VPC<\/pre>\n\n\n\n
Furthermore, you need a way to specify that all the traffic should go to the Internet Gateway you created; for this, you need to create a route table<\/a> and a route.<\/p>\n\n\n\n
RouteTable:\n Type: AWS::EC2::RouteTable\n Properties:\n VpcId: !Ref VPC\n DefaultRoute:\n Type: AWS::EC2::Route\n DependsOn: InternetGatewayAttachment\n Properties:\n RouteTableId: !Ref RouteTable\n DestinationCidrBlock: 0.0.0.0\/0\n GatewayId: !Ref InternetGateway<\/pre>\n\n\n\n
The EC2 is part of the default VPC if not otherwise specified, so the instance and the security group will be part of different VPCs, which means you will not be able to link them; to solve this, you need to create a subnet as part of the new VPC and place the EC2 instance inside that.<\/p>\n\n\n\n
Subnet:\n Type: AWS::EC2::Subnet\n Properties:\n VpcId: !Ref VPC\n AvailabilityZone: !Select [ 0, !GetAZs '' ]\n CidrBlock: 192.168.0.0\/16\n MapPublicIpOnLaunch: true<\/pre>\n\n\n\n
Finally, the subnet should be associated with the route table created earlier.<\/p>\n\n\n\n
SubnetRouteTableAssociation:\n Type: AWS::EC2::SubnetRouteTableAssociation\n Properties:\n SubnetId: !Ref Subnet\n RouteTableId: !Ref RouteTable<\/pre>\n\n\n\n
Once everything is added to the file, you can perform an update-stack <\/em>command to deploy the newly created resources.<\/p>\n\n\n\n
aws cloudformation update-stack --stack-name dotnet-docker --template-body file:\/\/infrastructure.yaml<\/pre>\n\n\n\n
Finally, with the infrastructure ready, you can add the commands to install Docker on the machine, login to Docker Hub, pull the image and run it. You do this by adding a property of the EC2 instance, called
UserData<\/code>.<\/em><\/p>\n\n\n\nSince these commands contain your password for Docker Hub, which you would not want to be committed to a Git repository, you can use parameters and specify them when creating or updating the stack. This is what the instance code looks like after adding the commands (be sure to replace your image ID).<\/p>\n\n\n\n
MainInstance:\n Type: AWS::EC2::Instance\n Properties:\n ImageId: ami-0ac05733838eabc06\n InstanceType: t2.micro\n SecurityGroupIds: \n - !GetAtt \"MainSecurityGroup.GroupId\"\n SubnetId: !Ref Subnet\n UserData:\n Fn::Base64:\n !Sub |\n #!\/bin\/bash\n apt-get update -y\n apt-get install docker.io -y\n docker login -username ${DockerUsername} -password ${DockerPassword}\n docker pull docker.io\/${DockerUsername}\/dotnet-api\n docker run -d -p 80:80 ${DockerUsername}\/dotnet-api<\/pre>\n\n\n\nAdd the parameters to a special section between Description<\/em> and Resources<\/em>.<\/p>\n\n\n\n
Parameters:\n DockerUsername:\n Description: The Docker Hub username.\n Type: String\n DockerPassword:\n Description: The Docker Hub password.\n Type: String<\/pre>\n\n\n\n
If you would like to view the whole file, you can do so here<\/a>.<\/p>\n\n\n\n
To update the stack, you can run the
update-stack<\/code> command with the parameters <\/em>tag; if you deleted the stack, you can run thecreate-stack<\/code> command instead:<\/p>\n\n\n\naws cloudformation update-stack --stack-name dotnet-docker --template-body file:\/\/infrastructure.yaml<\/a> --parameters ParameterKey=DockerUsername,ParameterValue=yourusername ParameterKey=DockerPassword,ParameterValue=yourpassword<\/pre>\n\n\n\n
If you go to the EC2 dashboard on the AWS console, you should see a new instance being created. Copy the public DNS and append
\/api\/test<\/code> to it. You should see the same JSON as in the previous tutorial. Note that if you have problems with the test, see the \u201cDebugging your instances\u201d section later in the article.<\/p>\n\n\n\n![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2019\/12\/word-image-10.png\")
<\/figure>\n\n\n\nRead also:<\/strong> Deploy Docker apps to Kubernetes using Jenkins<\/a><\/p>\n\n\n\n
Debugging Your Instance<\/h2>\n\n\n\n
What happens after you deploy your instances, and something does not work as intended \u2013 such as the test endpoint not returning anything? The easiest way to figure out what went wrong is to connect to the instance via SSH.<\/p>\n\n\n\n
First of all, allow connections to your instances via port 22, by adding another ingress rule to the security group.<\/p>\n\n\n\n
MainSecurityGroup:\n Type: AWS::EC2::SecurityGroup\n Properties:\n GroupDescription: Security group for the API instances.\n VpcId: !Ref VPC\n SecurityGroupIngress:\n - IpProtocol: tcp\n FromPort: 80\n ToPort: 80\n CidrIp: 0.0.0.0\/0\n - IpProtocol: tcp\n FromPort: 22\n ToPort: 22\n CidrIp: 0.0.0.0\/0\n SecurityGroupEgress:\n - IpProtocol: tcp\n FromPort: 0\n ToPort: 65535\n CidrIp: 0.0.0.0\/0<\/pre>\n\n\n\n
Next, in the Instance properties, you have to specify a key-pair name. You can use the one you created during the previous tutorial which you can see by scrolling down to the Network & Security section of the ECW menu.<\/p>\n\n\n\n
MainInstance:\n Type: AWS::EC2::Instance\n Properties:\n KeyName: dotnet-docker-keypair\n ImageId: ami-0ac05733838eabc06\n InstanceType: t2.micro\n SecurityGroupIds: \n - !GetAtt \"MainSecurityGroup.GroupId\"\n SubnetId: !Ref Subnet\n UserData:\n Fn::Base64:\n !Sub |\n #!\/bin\/bash\n apt-get update -y\n apt-get install docker.io -y\n docker login -username ${DockerUsername} -password ${DockerPassword}\n docker pull docker.io\/${DockerUsername}\/dotnet-api\n docker run -d -p 80:80 ${DockerUsername}\/dotnet-api<\/pre>\n\n\n\nThe update-stack<\/em> command will not achieve the intended result here, as the instance is already running. Instead, delete your stack first, by running this code.<\/p>\n\n\n\n
aws cloudformation delete-stack --stack-name dotnet-docker<\/pre>\n\n\n\n
Then create it again with the new configuration.<\/p>\n\n\n\n
Afterwards, you can follow the connection technique that you used for the instance created manually in the first article, by the SSH command. Make sure that the pem file is in a secured location.<\/p>\n\n\n\n
ssh -i \"dotnet-docker-keypair.pem\" ubuntu@{public-dns}<\/pre>\n\n\n\nOnce you are connected, you can check the logs for any issues that might have appeared while launching the instance, by running the following command.<\/p>\n\n\n\n
cat \/var\/log\/cloud-init-output.log<\/pre>\n\n\n\n
Don\u2019t forget that this method is something to be used for testing and debugging purposes only \u2013 remove such configurations when deploying production environments.<\/p>\n\n\n\n
Deploying Multiple Instances<\/h2>\n\n\n\n
If you remember the series introduction, one of the essential aspects was being able to deploy multiple, identical servers that run the same API. This way, if one of them fails, or if there is an update for the API, the customers are still able to use the service by being redirected to the working instances.<\/p>\n\n\n\n
The goal of working with multiple instances is to make it seem like the users are only interacting with one server. For this purpose, a load balancer will be placed in front of the instances \u2013 this will receive the traffic and decide where to send it, ensuring a lower response time for the clients.<\/p>\n\n\n\n
To achieve the deployment of multiple instances, there are some new resources that need to be added to the infrastructure:<\/p>\n\n\n\n
Additional subnets for different availability zones in your region; this ensures that if one availability zone fails, your API is still up and running; the
Subnet<\/code> and theSubnetRouteTableAssociation<\/code> sections created previously should be deleted.<\/p>\n\n\n\nSubnet1:\n Type: AWS::EC2::Subnet\n Properties:\n VpcId: !Ref VPC\n AvailabilityZone: !Select [ 0, !GetAZs '' ]\n CidrBlock: 192.168.0.0\/24\n MapPublicIpOnLaunch: true\n Subnet2:\n Type: AWS::EC2::Subnet\n Properties:\n VpcId: !Ref VPC\n AvailabilityZone: !Select [ 1, !GetAZs '' ]\n CidrBlock: 192.168.1.0\/24\n MapPublicIpOnLaunch: true\n Subnet1RouteTableAssociation:\n Type: AWS::EC2::SubnetRouteTableAssociation\n Properties:\n SubnetId: !Ref Subnet1\n RouteTableId: !Ref RouteTable\n Subnet2RouteTableAssociation:\n Type: AWS::EC2::SubnetRouteTableAssociation\n Properties:\n SubnetId: !Ref Subnet2\n RouteTableId: !Ref RouteTable<\/pre>\n\n\n\n
A Launch Configuration<\/a>, that represents the template for any instance that is going to be created; since you are not creating the instances manually anymore, this will specify the image id, the size and the user data for your servers; as part of this step, you must also delete the EC2 instance code (
MainInstance<\/code> section). This section contains the Image ID, so be sure to replace it.<\/p>\n\n\n\nLaunchConfiguration:\n Type: AWS::AutoScaling::LaunchConfiguration\n Properties:\n UserData:\n Fn::Base64: !Sub |\n #!\/bin\/bash\n apt-get update -y\n apt-get install docker.io -y\n docker login -u ${DockerUsername} -p ${DockerPassword}\n docker pull docker.io\/${DockerUsername}\/dotnet-api\n docker run -d -p 80:80 ${DockerUsername}\/dotnet-api\n ImageId: ami-0ac05733838eabc06\n SecurityGroups:\n - Ref: MainSecurityGroup\n InstanceType: t2.micro<\/pre>\n\n\n\nAn Auto Scaling Group<\/a> to control how many instances are created, when to create them and when to stop them.<\/p>\n\n\n\n
AutoScalingGroup:\n Type: AWS::AutoScaling::AutoScalingGroup\n Properties:\n VPCZoneIdentifier:\n - !Ref Subnet1\n - !Ref Subnet2\n LaunchConfigurationName:\n Ref: LaunchConfiguration\n DesiredCapacity: 3\n MinSize: 2\n MaxSize: 4\n TargetGroupARNs:\n - Ref: TargetGroup<\/pre>\n\n\n\n
A Load Balancer<\/a> that will control the traffic for the instances inside the Auto Scaling Group.<\/p>\n\n\n\n
LoadBalancer:\n Type: AWS::ElasticLoadBalancingV2::LoadBalancer\n Properties:\n Subnets:\n - !Ref Subnet1\n - !Ref Subnet2\n SecurityGroups:\n - Ref: MainSecurityGroup<\/pre>\n\n\n\n
A Load Balancer Listener<\/a> and a rule for it, as well as a Target Group<\/a>, to specify how to check the health of each instance and make sure they are still running. Here is the Listener Rule section:<\/p>\n\n\n\n
ListenerRule:\n Type: AWS::ElasticLoadBalancingV2::ListenerRule\n Properties:\n Actions:\n - Type: forward\n TargetGroupArn: !Ref TargetGroup\n Conditions:\n - Field: path-pattern\n Values: [\/]\n ListenerArn: !Ref Listener\n Priority: 1<\/pre>\n\n\n\n
Add the Listener.<\/p>\n\n\n\n
Listener:\n Type: AWS::ElasticLoadBalancingV2::Listener\n Properties:\n DefaultActions:\n - Type: forward\n TargetGroupArn:\n Ref: TargetGroup\n LoadBalancerArn:\n Ref: LoadBalancer\n Port: '80'\n Protocol: HTTP<\/pre>\n\n\n\n
Also add the TargetGroup section.<\/p>\n\n\n\n
TargetGroup:\n Type: AWS::ElasticLoadBalancingV2::TargetGroup\n Properties:\n HealthCheckIntervalSeconds: 10\n HealthCheckPath: \/\n HealthCheckProtocol: HTTP\n HealthCheckTimeoutSeconds: 8\n HealthyThresholdCount: 2\n Port: 80\n Protocol: HTTP\n UnhealthyThresholdCount: 5\n VpcId: !Ref VPC<\/pre>\n\n\n\n
You can view the file containing all the resources here<\/a>.<\/p>\n\n\n\n
From the CloudFormation Stacks list, delete the original stack. You should now run the same command from earlier with
create-stack<\/code> and the username and password parameters. Once it finishes (and it might take longer than the previous versions, since there are many new resources added), go to the EC2 dashboard on AWS Console to inspect the resources. You should see three instances.<\/p>\n\n\n\n![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2019\/12\/word-image-11.png\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
You can go to any of them, copy the public DNS and append
\/api\/test<\/code> to it, and receive the expected JSON message from earlier. This ensures that all the instances work as expected.<\/p>\n\n\n\nWhile on the instances page, if you scroll down in the left menu and select Load Balancers<\/em>, you should see one resource.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2019\/12\/word-image-12.png\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
Below, you should see a property called DNS Name<\/em>, which is the URI for your load balancer. You can copy it, append
\/api\/test<\/code> and receive the same JSON message as from the instances. You are done!<\/p>\n\n\n\nDebugging Your Instances<\/h2>\n\n\n\n
Enabling SSH connections to your instances is essentially the same process as the one described earlier, for the single instance \u2013 however, the key-pair will be added to the launch configuration and propagated to all the EC2 instances.<\/p>\n\n\n\n
The first step is adding port 22 as an ingress rule for the security group.<\/p>\n\n\n\n
MainSecurityGroup:\n Type: AWS::EC2::SecurityGroup\n Properties:\n GroupDescription: Security group for the API instances.\n VpcId: !Ref VPC\n SecurityGroupIngress:\n - IpProtocol: tcp\n FromPort: 80\n ToPort: 80\n CidrIp: 0.0.0.0\/0\n - IpProtocol: tcp\n FromPort: 22\n ToPort: 22\n CidrIp: 0.0.0.0\/0\n SecurityGroupEgress:\n - IpProtocol: tcp\n FromPort: 0\n ToPort: 65535\n CidrIp: 0.0.0.0\/0<\/pre>\n\n\n\n
Next, in the Launch Configuration properties, specify the key-pair name.<\/p>\n\n\n\n
LaunchConfiguration:\n Type: AWS::AutoScaling::LaunchConfiguration\n Properties:\n KeyName: dotnet-docker-keypair\n UserData:\n Fn::Base64: !Sub |\n #!\/bin\/bash\n apt-get update -y\n apt-get install docker.io -y\n docker login -u ${DockerUsername} -p ${DockerPassword}\n docker pull docker.io\/${DockerUsername}\/dotnet-api\n docker run -d -p 80:80 ${DockerUsername}\/dotnet-api\n ImageId: ami-0ac05733838eabc06\n SecurityGroups:\n - Ref: MainSecurityGroup\n InstanceType: t2.micro<\/pre>\n\n\n\nAgain, don\u2019t forget to remove these settings before deploying your instances to production!<\/p>\n\n\n\n
Cleaning Up<\/h2>\n\n\n\n
If you are following this just for testing or learning purposes, you should avoid keeping the resources alive for too long, as it can create additional costs or reach the free tier limits; since all the resources are part of a stack, deleting them is as simple as deleting the stack. You can do it from the console, by running.<\/p>\n\n\n\n
aws cloudformation delete-stack --stack-name dotnet-docker<\/pre>\n\n\n\n
You can also remove the stack from the CloudFormation dashboard in the AWS Console, by selecting the stack and clicking the Delete<\/em> button.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2019\/12\/word-image-13.png\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
What is Next?<\/h2>\n\n\n\n
It might seem that the goal of the tutorials is more or less achieved: you can pack the code from your Git repository in a Docker image and deploy it to multiple instances, ensuring the high availability of your application. But you are still handling most of this process manually.<\/p>\n\n\n\n
Going forward, you will learn how to use Kubernetes to orchestrate your Docker containers, and how to automate the deployment process.<\/p>\n\n\n\n
Read also:
<\/strong>Part 1: Dockerizing an API on AWS EC2<\/a>
Part 3: Orchestrating Containers with Kubernetes<\/a>
Securing your DevOps pipeline and cloud infrastructure<\/a><\/p>\n\n\n\n\n - ASP.NET Core with GitOps: Deploying Infrastructure as Code<\/a><\/li>\n