Preview: Currently, the Blazor App is accessible via the internet through the public DNS. While registering through the app (which requires db access), two exceptions are thrown in the broswer:
SocketException: Name or service not known.
SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 35 – An internal exception was caught).
Goal: Connect Blazor App running in EC2 instance container to SQL Server running in the same EC2 instance/different container.
What I know:
- Both Containers are running (including EC2 agent) within instance.
- Port 1433 is accessible from any public IP:
- SQL Server container can be pinged from within SQL Server container by its IP Address, but not by its host/container name:
What I’ve tried (condensed):
- Set proper security group settings:
-
Removed "1433" from connection string for the Server property ("Server=sqlserver,1433;" -> "Server=sqlserver;")
-
Added "hostname" key in the Task Definition JSON:
{
"family": "blazor_app_task",
"containerDefinitions": [
{
"name": "blazor_app_container",
"image": "thecodeiackiller/exercise-api-blazorapp:latest",
"cpu": 205,
"memory": 307,
"memoryReservation": 205,
"portMappings": [
{
"name": "blazor_app_container-8080-tcp",
"containerPort": 8080,
"hostPort": 80,
"protocol": "tcp"
}
],
"essential": true,
"environment": [
{
"name": "ASPNETCORE_ENVIRONMENT",
"value": "Development"
},
{
"name": "DB_CONNECTION_STRING",
"value": "Server=sqlserver;Database=fitsked;User Id=sa;Password=supahstrongpassword#69;Encrypt=False;TrustServerCertificate=True;MultipleActiveResultSets=true"
},
{
"name": "AWS_EC2",
"value": "true"
}
],
"mountPoints": [],
"volumesFrom": [],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/blazor_app_task",
"mode": "non-blocking",
"awslogs-create-group": "true",
"max-buffer-size": "25m",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "ecs"
}
},
"systemControls": []
},
{
"name": "sqlserver",
"image": "mcr.microsoft.com/mssql/server:2022-latest",
"cpu": 1024,
"memory": 2048,
"memoryReservation": 1536,
"portMappings": [
{
"name": "sqlserver-1433-tcp",
"containerPort": 1433,
"hostPort": 1433,
"protocol": "tcp"
}
],
"essential": true,
"environment": [
{
"name": "MSSQL_SA_PASSWORD",
"value": "supahstrongpassword#69"
},
{
"name": "ACCEPT_EULA",
"value": "Y"
}
],
"mountPoints": [],
"volumesFrom": [],
"hostname": "sqlserver",
"systemControls": []
}
],
"taskRoleArn": "arn:aws:iam::448049819404:role/ecsTaskExecutionRole",
"executionRoleArn": "arn:aws:iam::448049819404:role/ecsTaskExecutionRole",
"networkMode": "bridge",
"volumes": [],
"placementConstraints": [],
"requiresCompatibilities": [
"EC2"
],
"cpu": "1536",
"memory": "3072",
"runtimePlatform": {
"cpuArchitecture": "X86_64",
"operatingSystemFamily": "LINUX"
}
}
2
Answers
AWS ECS, by default, uses the default bridge network when selecting "bridge" for the network settings on an ECS Task Definition. Per Docker Docs, "User-defined bridges provide automatic DNS resolution between containers. Containers on the default bridge network can only access each other by IP addresses, unless you use the --link option, which is considered legacy. On a user-defined bridge network, containers can resolve each other by name or alias."
When defining a network in a dockercompose.yml, specifying "bridge" specifies a user-defined bridge network, which is why DNS Resolution resolved between my local containers.
Unfortunately and from the information I was able to gather, AWS does not currently support for the user-defined bridge networking option. Switching to awsvpc is likely to best move at the moment.
Have you tried ip address in behalf of sqlserver and basically we use ipaddress, port and have you checked tcp pipeline enabled in configurations setting of sqlserver and sql server is installed in mix mode during installation