This article discusses how to perform subdomain based routing to containerized applications using application load balancer rules and elastic container service.
Requirements:
- AWS account
- Domain name registration
- Dockerized applications
The Architecture from a High Level View:
Imagine you have two separate applications that you want to live under the same domain name and you would like appA to be accessed by the domain appA.example.com and you also have appB to be accessed by the domain appB.example.com.
The overall solution would be to set up an Application Load Balancer, point your domain to said load balancer, have a listener with an HTTPS certificate that receives those initial communications, have a two separate target groups (one for appA and one for appB), and have your given applications in their respective backends.
There are a few considerations to think about when setting up this architecture and I’m hoping to cover these issues you may run into when deploying an architecture like this.
1. SSL Certificate Considerations
If your domain is hosted in AWS using route53, your certificate should issue automatically. But if your domain isn’t hosted in AWS you’ll need to set up the certificate yourself. I recommend setting up what is called a wildcard certificate (for example “*.example.com”), this allows you to add additional routes to your load balancer without compromising your HTTPS setup. To do this, when you’re requesting the certificate using AWS Certificate Manager, use a “*” for the subdomain value.
2. HTTP to HTTPS
You might run into an issue where your load balancer doesn’t respond to your domain when you access your site using HTTP (http://example.com). This is due to the fact that you may not have set up an HTTP listener on your load balancer. Simply Add the HTTP (port 80) listener and create a rule that redirects your traffic to HTTPS (port 443) with a response code of 301 (permanently moved). This will force all connections to your applications to use HTTPS.
3. Subdomain Routing (appA.example.com, appB.example.com)
This can be acquired using a rule type that is offered by your application load balancer HTTPS listener. Simply set the rule condition to “Host Header” and specify the full domain name of the intended domain (ex. appA.example.com) and specify the target group to point to the respective group. Then add an additional rule and perform the same actions but for appB.
4. Port Configurations
This can get a little tricky since you want to have HTTPS set up. Generally, you want to have an HTTPS connection between the end user and the load balancer listener. This will usually be the only time you are using HTTPS, your load balancer can connect to your target group using port 80 or the port your container is configured to listen on. If you are having connectivity issues it could be due to your target group using port 443 to connect to your container and you don’t have an additional SSL certificate configured.
Remember, the connection on the browser’s end is between the end user and the application load balancer listener, all other connections within AWS don’t have anything to do with the HTTPS status for the user.
5. Application Not Connecting When Accessed via Domain Name
If you are trying to access your application but it isn’t loading, you may have an issue with your container configuration. This can occur due to unhandled bugs in the container itself. Check the target group your container is associated with and check the health status. If it is showing unhealthy be sure the protocol you are accessing the container on is correct. Generally you want to use port 80 for your backend containers. Also, be sure that your container is configured to open the port your are attempting to access it on. Check your container configuration in the task definition you created to deploy the service.
Want to do more with Docker? Check out this guide on how to Dockerize a PHP application!
