There are a handful of steps to the AWS Fargate deployments that require the setup of networking etc. for each container. We need to create Security Groups in steps with specific ports and then reference these later on, which can lead to confusion and errors in the deployment.
It is important to note that in the ideal architecture configuration HTTPS traffic will come into the AWS Elastic Load Balancer (ELB) and then with the necessary Security Group configured to allow traffic over port 3000 from the ELB to the container that is running the Tines Application. If this is not configured properly you will not be able to access Tines Application UI. The AWS ELB is expected to act as a forwarder of traffic and without the correct port openings, Tines will be unable to do so.
If you try to access the URL and receive error messages such as HTTP 503 or HTTP 504 error code, it is typically a generic error being served up from the ELB itself indicating it is having an issue reaching the destination with the HTTPS request, in this case, the Tines Application server. If an actual HTTP error occurred with the Tines Application server itself, indicating traffic was reaching the App, this error would be generated by Tines and written to CloudWatch.
Verify the following:
The ELB is allowing HTTPS traffic from the internet
The ELB has the appropriate SG (Security Group) configured to allow traffic over port 3000 to the Tines App
The same SG allowing traffic in over port 3000 is allowing all traffic out (noted as: 0.0.0.0/0)
To confirm which SG is associated with the container, have the user navigate to ECS > Clusters > The Tines Cluster Name They Created > Service: The Tines Service
With the Tines deployment in Fargate, the Security Group is attached directly to the service.
If you check the CloudWatch logs for the Tines-Application container and see similar log lines below, this indicates that the Tines App is functioning correctly. We would recommend reviewing the hosting network for any possible issues.
