In our application we are using linux based container which access SQL server installed on VM. Everything works fine in local environment outside the container, But when I ran the app in local container we are getting the below error.
"A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 35 - An internal exception was caught"
appsetings.json
"ConnectionStrings": {
"DbConnection": "Server=tcp:vmname\\sqlservername,49763;Database=dbname;User ID=username_Users;Password=pwd;MultipleActiveResultSets=true;Integrated Security=False;"
}
Dockerfile
FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
.......
Any inputs will be appreciated
The issue was related to TLS version of the SQL server, enabling TLS 1.2 resolved the issue
Please add ;TrustServerCertificate=true to your connection string.
Related
Trying to spin up an mssql server with a docker-compose file:
version: "3.7"
services:
sqlserver:
image: mcr.microsoft.com/mssql/server:2017-latest
container_name: sqlserver
user: root
ports:
- "1433:1433"
environment:
SA_USERNAME: sa
SA_PASSWORD: Dev1234!
ACCEPT_EULA: Y
MSSQL_AGENT_ENABLED: 'true'
volumes:
- ./volumes/data2:/var/opt/mssql/data
- ./volumes/backup:/var/opt/mssql/Backup
The server is up and running successfully, But when tried to connect with powershell script code:
$connectionString = "Data Source=localhost,1433;User ID=sa;Password=Dev1234!;"
$connection = New-Object System.Data.SqlClient.SqlConnection($connectionString)
$connection.Open();
It throws error like:
"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: 0 - The
remote computer refused the network connection.)"
That is, it fails when trying to connect with 'localhost' as host, it is successfully connecting when "127.0.0.1" is specified as host.
The same happens when I tried to connect with SQL server management studio.
My docker engine is running in wsl, an ubuntu distro specifically. There is MySQL and different other servers already spun up which I can access with localhost.
Is there anything I need to specify in docker-compose to make this work? When checking documentation, there are no params aligned to it as I see.
I'm currently working on a small app that has to fetch data from a SQL Server DB and push it on the cloud. It works correctly, but I would like to dockerize it to make its deployment easier.
The database is on a private network and I have to use a VPN connection to access it for development (in red in the diagram below). In production, the app will be on a VM in the database's network.
I'm still confused with Docker networks and the --publish option.
Here is my docker-compose file for now.
version: "3.4"
services:
myapp:
build:
context: .
network: host
restart: always
ports:
- "128.1.X.Y:1433:1433"
container_name: myapp
But when I connect to the VPN from my machine (remote) and run my image with this configuration, I get this error:
driver failed programming external connectivity on endpoint myapp (bbb3cc...):
Error starting userland proxy: listen tcp4 128.1.X.Y:1433: bind: cannot assign requested address
Simply "1433:1433" does not work either. The database cannot be accessed. Not really sure about "network: host" either...
Does anyone know what I could be doing wrong?
And another thing I'm wondering is, will the Docker config be the same when I will deploy my container on the VM?
Thank you!
I'm migrating a local SQL Server development database to run in a Linux docker container (on the same dev machine). When running my integration tests in Visual Studio 2019 on Windows, I receive MSDTC errors:
Exception thrown:
'System.Transactions.TransactionManagerCommunicationException' in
System.Data.dll An exception of type
'System.Transactions.TransactionManagerCommunicationException'
occurred in System.Data.dll but was not handled in user code
Communication with the underlying transaction manager has failed.
Here's my latest iteration of SQL Server in my docker-compose:
services:
sqlserver:
image: mcr.microsoft.com/mssql/server:2019-latest
container_name: SqlServer
restart: always
environment:
- ACCEPT_EULA=Y
- SA_PASSWORD=verySecretPassword
- MSSQL_RPC_PORT=13500
- MSSQL_DTC_TCP_PORT=51000
ports:
- "1401:1433"
- "135:13500"
- "51000:51000"
volumes:
- sqldata:/var/opt/mssql
I've tried all sorts of ways to adjust the RPC port to get this working. This is the main MS article. I've tried port 135:135 but it gives the same error. The note in the article at the bottom appears to be related to my issue.
For SQL Server outside of a container or for non-root containers, a
different ephemeral port, such as 13500, must be used in the container
and traffic to port 135 must then be routed to that port. You would
also need to configure port routing rules within the container from
the container port 135 to the ephemeral port.
Also, if you decide to map the container's port 135 to a different
port on the host, such as 13500, then you have to configure port
routing on the host. This enables the docker container to participate
in distributed transactions with the host and with other external
servers.
SQL Server 2019 containers run as a non-root user. I've tried port routing using netsh in windows... and also the MS article links to how to perform port forwarding in Ubuntu... which I'm unable to do even when logged in as root in the SQL Server container... iptables is not installed, and it doesn't let me apt-get install it?? I also updated the DTC options in windows to make it as open as possible, but it had no effect. Not sure what the secret sauce is. Hoping someone else has a similar setup that works.
Thanks for the tip on msdtc config, I got mine working with this compose:
version: '3.4'
services:
sqlserver:
image: mcr.microsoft.com/mssql/server:2019-GA-ubuntu-16.04
container_name: sqlserver
user: root
environment:
- ACCEPT_EULA=Y
- SA_PASSWORD=[yourPwd]
- MSSQL_RPC_PORT=135
- MSSQL_DTC_TCP_PORT=51000
ports:
- "1433:1433"
- "135:135"
- "51000:51000"
volumes:
- D:\DockerVolumes\sqlserver:/var/opt/mssql/data
I am using Istio and Envoy as sidecar proxy. I have deployed the bookinfo sample and its working fine but when I am deploying my own application which calls SQL Server on https or other external services, it gives exception.
A connection was successfully established with the server, but then an
error occurred during the pre-login handshake. (provider: TCP
Provider, error: 35 - An internal exception was caught)
To let Istio applications communicate with external TCP services,
check this blog post https://istio.io/latest/blog/2018/egress-tcp/.
To let Istio applications communicate with external HTTP and TLS services, check https://istio.io/latest/docs/tasks/traffic-management/egress/egress-control/.
I faced same issue to connect SQL server from my application, Which i have deployed
in istio enabled namespace. I created serviceentry as shown below to create accessablity.
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: sql-replica
spec:
hosts:
- SQL-DNS-NAME or IP
addresses:
- xxx.xx.x.xxx/32
ports:
- number: 5432
name: tcp
protocol: TCP
location: MESH_EXTERNAL
Here in config file xxx.xx.x.xxx ip is that IP which we get by pinging to DNS
$ kubectl apply -f access-sql-server-from-mesh.yaml
I am trying to deploy a JEE application in Docker container. The application requires embedded apache derby on port 1527. It works fine when run in regular dev environment. However, when I run inside a Docker container, the connection on port 1527 is refused.
Things to note, I am using 'default' db connection. That means the application is trying to access the database on localhost:1527. Following is the error message:
java.net.ConnectException : Error connecting to server localhost on port 1527 with message Connection refused (Connection refused).
I am wondering what does localhost mean within a Docker container, the host server or the container?
Any suggestions to fix it?