Unable to connect to SQL Server inside docker container - sql

Question

I have 2 docker containers (inside one of them I have an application, inside another SQL Server).
I tried to connect from the docker-container with application to the SQL Server database inside another container.
For this I did:
root#application:/# sqlcmd -S 172.17.0.1 -U sa -P test
After I got an issue:
Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : Login timeout expired.
Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : TCP Provider: Error code 0x2749.
Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online..
When I used this option inside docker-container with the SQL Server database without -S 172.17.0.1, it works fine.
Any ideas how to connect from container with application to the container with database via sqlcmd?
Update
I was mistaken, I used pass this command from docker-container with database.
Still have a problem with connection from app to the database

Answer 1

One way. The most "trust worthy" way IMHO.
You have to expose your sql-server as a SERVICE.
apiVersion: v1
kind: Service
metadata:
name: mssql-service-deployment
#namespace: mycustomnamespace
spec:
selector:
app: mssql
ports:
- protocol: TCP
port: 1433
targetPort: 1433
type: LoadBalancer
..
Then your connection string becomes:
jdbc:sqlserver://mssql-service-deployment.default.svc.cluster.local;DatabaseName=MyDB;"
where ".default." is the NAMESPACE of the exposed service.
Note the repeat (same string value) of "mssql-service-deployment"
This is documented here:
https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/#namespaces-and-dns
When you create a Service, it creates a corresponding DNS entry. This
entry is of the form
..svc.cluster.local, which means that if
a container just uses , it will resolve to the service
which is local to a namespace. This is useful for using the same
configuration across multiple namespaces such as Development, Staging
and Production. If you want to reach across namespaces, you need to
use the fully qualified domain name (FQDN).