I have an asp.net core that connects to a SQL Server. When I run it in docker on my local computer everything works as expected, but when run the docker image on a linux server (centos 8) i get a network error when trying to connect to the database. I don't know what to do, since I used the actual server's ip in the connection string and it still does not work.
Thank you a lot
You should configure the firewall correct and watch if SELinux is blocking you in some way.
Just to speed up your testing, try after these commands:
sudo su -
systemctl disable firewalld
setenforce 0
Related
I had setup a WSL2 Ubuntu. Now I am running a local SQL Server instance on the 1401 port using Docker.
Container port:
0.0.0.0:1401->1433/tcp
I would like to connect this instance from SSMS but I am getting following error:
Server name: localhost, 1401
Error:
Cannot connect to localhost,1401.
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 wait operation timed out.)
(Microsoft SQL Server, Error: 258)
[Solution]
I am able to connect it via the WSL2 IP. I run "hostname -I" command in WSL2 and use the same IP in SSMS. And, I am able to make a connection
First question -- Is there a VPN running/connected in Windows? If so, ignore the rest of this and suspect that first. Make sure the VPN is not running, stop Docker, issue a wsl --shutdown, restart and try again.
Assuming that's not the problem ...
Normally, WSL2 provides a feature known as "localhost forwarding" which allows services/apps on Windows to communicate with the virtualized WSL2 IP using localhost. It essentially takes any localhost traffic that isn't directed to a port bound under Windows and forwards it to the Hyper-V virtual network for WSL2.
All WSL2 instances (including the Docker instance) share the same WSL2 network interface as they are all running in the same virtual machine/kernel.
So you seem to be doing the right thing in attempting to connect to localhost from SSMS.
But ... sometimes that localhost forwarding breaks. There are two common (related) scenarios that can cause this (and perhaps others):
Hibernation of the Windows host
Having Windows Fast Startup enabled in Power Manager
First check to make sure you can access 1401 from within WSL2:
nc -zv localhost 1401
^^^ assumes netcat is installed, which it is by default in the WSL2 Ubuntu distribution. For other distributions, install it or check connectivity via other methods.
If that doesn't succeed, then I'd suspect some configuration issue in SQL Server.
If that does succeed, then run the same test from the Windows host in PowerShell:
Test-NetConnection -ComputerName "localhost" -Port 1401
If that doesn't succeed, then I'd suspect a localhost forwarding issue.
Side note: I'm assuming you are running Docker Desktop, but if you are just running Docker Engine in a WSL2 instance, that's no problem. Just ignore the Docker Desktop instructions below.
First, check if you have a /etc/wsl.conf in any of your running WSL2 instances that mention disabling localhostForwarding. I'm assuming no, since that is not the default. However, if you happen to, make sure you set these to true.
Stop all WSL2 services, instances, shells, apps, etc. (including Docker Desktop)
From PowerShell:
wsl --shutdown
Then restart Docker Desktop and/or your container and try again
If localhost doesn’t work, try use [::1] in the server name. In WSL2, port 1433 is using IP/TCPv6, SSMS some times is not able to resolve localhost to loopback IP [::1].
Source: https://jayfuconsulting.wordpress.com/2020/11/14/sql-server-2019-docker-wsl-2/
One last thing which you could try is to modify the windows host file. I almost tried all the steps mentioned over different link, but all goes in vain. Then I opened the host file which could be accessed using
C:\Windows\System32\Drivers\Etc
Open the host file and uncomment(remove # sign) from the localhost name resolution section
I am pretty new to postgreSQL. I am running version 9.5 of it on my main machine. I am trying to establish a telnet connection from my virtual machine. Before doing that I have configured the postgresql.conf and pg_hba.conf files to accept connection from remote machine in the same network.
However when I start the postgresql service using:
service postgresql start
The process show the status:
active(exited)
and the telnet connection is also refused(when i run telnet x.x.x.x 5432). Also when i start the postgresql service using
systemctl start postgresql#9.5-main
the status is active(running) but the telnet connection is still refused. Can anyone tell me how to establish the telnet connection? I dont really know whats going on and I am new here so please dont mind if its a noob question
I have faced with very strange issue.
Host OS is Windows 10 Pro, installed Docker for Windows.
When I run microsoft/mssql-server-windows-developer container using simple command
docker run -d -p 1433:1433 -e sa_password=<SA_PASSWORD> -e ACCEPT_EULA=Y microsoft/mssql-server-windows-developer
I can connect to SQL Server via MS SQL Management Studio using server name=localhost. But I can't open Server Properties or open "Attach DB" wizard. There is the same error all the time "The semaphore timeout period has expired".
I can run container with attached DBs and I can execute sql inside MS SQL Management Studio. But when I run my Web Application - I get the same error "The semaphore timeout period has expired" on connect to DB.
Then I tried to connect to SQL Server using IP address which I get via docker container inspect - in my case it was 172.28.93.83. And everything worked as it should - I can manage with SQL Server, my Web Application connects to the DB, etc.
So, what is the issue there? I still want to use localhost to connect to server to have unified connection string in all developers environments.
When I tried to run Linux container - everything worked fine using localhost to connect to server.
I could be important - before I decided to use docker to work with MS SQL Server I had MS SQL Server installed and then uninstalled it. Maybe it made some changes in a routing or network which I have to remove...
I would appreciate any help
Try with increase timeout seconds in connection string.
I solved a similar incident changing the metric to the card generated by Docker.
I put 5000.
Luck.
So I know there are a load of questions on SO related to this already, but I think at this point I've read them all, tried all the suggestions, and still haven't found a resolution.
I've got a simple .Net core MVC app with a connection to a local MSSQL database. I have been unable to get it to connect to SQL when running it in a container... I just get an error that a connection couldn't be established. When run in IIS Express it connects fine.
My connection string is:
Data Source=10.11.56.36,1433;Initial Catalog=TestDB;Integrated Security=false;User id=testdb;Password=######;MultipleActiveResultSets=True
My container is launched via:
docker run -it -p 8080:80 testing
Here are the things I've attempted so far:
Ensured the SQL server is configured to accept remote connections
Used "host.docker.internal" for server name
Ping'd the SQL server IP to ensure it's accessible to the container
Verified port 1433 is allowed through the firewall
Tried a different port and configured SQL server to listen on that
Tried without the port in the connection string
There were a host of other things I've tried as well in the last few hours of beating my head on this, but I've made no progress at all. What am I missing?
Any help would be greatly appreciated.
Please check if this bug is the reason for your error, if you are running a Linux Container:
https://github.com/dotnet/corefx/issues/29147
If so, the fix is to add the following to the runtime image in dockerfile
RUN apk add --no-cache icu-libs
ENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false
I just had this issue. I spent 3 days and the fix for me was to use a fully qualified domain name.
MyServerName.MyDomain.com
Part of my job involves data collection to help size workloads that could be transferred to the cloud. An element of this is being able to enumerate SQL instances within a client's environment for insights such as "hey you have some out of support legacy SQL here that was supposed to be decommed years ago, what's the deal."
With the release of SQL Server 2017, I've just now created an instance of the SQL Server Enterprise 2017 on Linux container (using this image) that I'm running locally on Windows 10. I can connect to the instance via SSMS and SELECT ##VERSION to confirm it's legit, but my question is if it is possible to inventory the device and find the SQL instance without knowing that connection string.
Things I've tried:
-Running on Windows 10 so I believe this is supported via Hyper-V, when I try to go through the Hyper-V manager to connect to the VM Docker spun up, can't get any interface there (which I figured, since Docker emulates apps rather than full VMs)
-Tried to do a sqlcmd -L from the Win10 host device and don't see the instance (Don't have SQL installed on the Windows 10 device I'm running this from)
-I can find the docker image via a docker ps, then exec -it to bash, and use sqlcmd from there, but the sqlcmd -L isn't listed as an option within Linux.
-ipconfig from the host device shows the Docker IP address, but it wouldn't give me the port information so I would have to scan through all the ports which feels dirty.
I'm kind of at a loss at this point. If I didn't explicitly know a Docker container was running MSSQL-Linux, is there any way I could identify that from inventorying the host device? (sorry for the long post)
After banging my head on it for a bit I've found a painful workaround of:
connect to the container's bash using: docker exec -it <container_name> "bash"
then using ps aux | grep sql to list all of the sql processes. The MS image shows up as /opt/mssql/bin/sqlservr from local testing. Once SQL has been identified you can attempt to connect to it using the Docker ip from ipconfig and the port from docker ps
It's not elegant, but it should be possible to automate those steps for use across a set of unknown devices.
Leaving this open for a bit for any better alternatives.