[Question]: SQLExpress firewall help?
toranb opened this issue · comments
Thank you for such a great starter repository! I was able to stand up a host machine/ build the SQLExpress image (with your fine work here) but one issue I've been plagued with is not showing port 1433 as "listening" in WinServer2016TP5 and I'm curious if you have any resources related to this that are current/work.
I've tried a handful of the usual firewall rule hacking but it appears that I may have a handful of other issues that I'm less aware how to diagnose
- MS SQL Server Browser Service may not be running. How could I find out/ start this ?
- TCP/IP channel is disabled under SQL Server. How could I find out/ enable it?
- any other networking issue?
Any guidance/ resources would be greatly appreciated :)
You'll have to expose the correct port when running the container, eg.: docker run -p 1436:1433 -d sqlexpress
I find it to work - if in doubt you can always telnet <host> 1433 to make sure SQL Server is listening.
I don't think the browser service will be running - what do you need it for?
You can connect with SQL Server Management Studio with , 1433:
This is the Dockerfile that I use: https://github.com/Microsoft/Virtualization-Documentation/tree/master/windows-container-samples/windowsservercore/sqlserver-express/2014sp1
Ah, so you are using port 1436:1433 ? I assumed 1433:1433 (just wanted to confirm that wasn't a typo)
Oh, sorry - that was because I was testing running a bunch of them and exposing them on different ports on the host - you can run with 1433:1433
If I get a console on the container itself using powershell, how can I confirm the SQLExpress instance works at all using sqlcmd ? I've tried with something like this
Invoke-Sqlcmd -Query "SELECT @@VERSION"
@toranb the port may not be available from inside the container (but not 100% sure) - you should be able to connect from whatever host you're on with SQL Server Management Studio.
When I get an interactive prompt on the SQLExpress container and I run Get-Service I can see that MSSQL is stopped (not running).
Have you seen this running WinServer2016 TP5 ?
Doing a little more looking - who actually registers this service during the install? I don't see a specific register-service in the dockerfile/or start files
here is a screenshot showing what services are running in the container by default
Here is the error I get trying to start that service myself
I, like friism, have found it to work under TP5, tested using the Azure "Windows Server 2016 Technical Preview 5" VM image
An alternative to telnet (which is not installed by default) within the running container is: "netstat -a"
In both the brogersyh and friism Dockerfiles: The SQL Express installer registers the windows-service; TCP/IP listener is configured.
In the brogersyh Dockerfile, start.ps1 copies the .mdf files to where they need to be (volume mount or non volume mount scenario) then starts service, using the default CMD
in the friism Dockerfile, the service is left in a running state during build - it comes up running regardless of what the startup CMD is
The only other networking-related issues I've seen are the Windows Firewall setting for whatever port you configure (1433 or otherwise) and for Azure, additionally, a firewall rule in the Network Security Group. An example of configuring both of these may be found at: Dockerfiles-for-windows-README: Azure Resource Manager Template
@brogersyh what does your netstat -an show? also, if you attach to your session and do Get-Service do you see the same "name" for SQL Server I show above (with the $ in it) ?
also, what did you use to "build" the container w/ docker run? did you pass in a special command to be run on boot the first time or ?
@brogersyh @friism just a quick update :) I was able to get SQLServer running today by coming in w/ docker run (using powershell) and doing start (the script) directly. yay :)
Next question - how "should" I do this w/ docker run because when I tried the following I got an error (so I had to powershell in instead)
docker run -it -p 1433:1433 sqlexpress "powershell ./start"
(this worked but the above did not)
docker run -it -p 1433:1433 sqlexpress powershell
edit
last question - when I come back to this after a host reboot and use docker start what should this full command look like to correctly "start" the SQLExpress server??
another quick question (non windows user so please forgive me)
if I'm at the powershell prompt in the container with SQL Server running what command can I use to connect and verify it's up? So far this won't work
sqlcmd -U sa -P thepassword2# -S localhost\SQLEXPRESS,1433
w00t! finally got connected :)
for anyone following along w/ me so far - here is the full command you need to run once you are on the box (using the SA password from this very repository)
sqlcmd -SLOCALHOST\SQL -Usa -Pthepassword2#
@brogersyh @friism thank you both for helping push me across the finish line :) just about gave up on this last night
another question for @brogersyh @friism
inside the SQL container itself netstat -an shows 1433 as expected - but in the host VM (winserver 2016 TP5) a netstat -an does not show the 1433 (yet docker ps does show the mapping is bound)
What does your host VM netstat show? do you see 1433 as I did in the SQL container itself?
I'm hitting this same issue. netstat -a shows the container is listening on 1433, but the host VM (winserver 2016 TP5) netstat -a does not show listening on 1433. docker ps shows the port is mapped.
@toranb Did you find a resolution?
@Frannsoft so I had 2 choices ...
- Connect w/ sqlcmd from host => to docker SQLExpress machine
- Verify the connection does work but w/ a simple utility
I spent a few min looking at what it would take to get sqlcmd installed on the host and decided to use option 2 instead so ... try this command to see if you get an error or not
(new-object Net.Sockets.TcpClient).Connect("THEIPADDR", 1433) //THEIPADDR here is the actual ip of the docker container using `netstat -a` I believe`
I noticed when the docker container didn't have SQLExpress running I would get a diff result so I think this actually worked but would love another set of eyes to confirm that assumption. Can you give that a try and report back?
This came back as connected (.Connected == true), which I did not expect. After some further investigation I tried connecting to the sql server instance using the container's internal IP address and specifying the port as well "[ipaddress],port"[instancename] and was able to connect!
Thanks for the kick in the right direction.