Today I was looking into a .net core app we run on Windows, and wanted to see if I could create some disposable test / review app environments using Docker. In short, it didn’t work great because the .net core app uses Sentry/Raven for c#, and that library is not yet compatible with .net core – so we still have a 4.6 dependency that I had forgotten about. Bummer.
However, I got pretty close to standing it up, and I wanted to drop a few notes here for future me.
C:\Users\Tim λ git clone project λ cd project # I'm using Docker for Windows, so excuse the funny looking $PWD ahead # %CD% in Windows will replace with current directory λ docker run -it --rm -v %CD%:/app microsoft/dotnet bash # Now in a linux bash shell with dotnet available $ cd /app $ dotnet restore # Woah it works! # But then later when I tried building this specific example # failed because of the 4.6 dep. But it doesn't have to!
C:\Users\Tim λ docker run -e ACCEPT_EULA=Y -e SA_PASSWORD=GreatPassword! -p 1600:1433 -v "D:\\SQL DB\\BACKUP\\":/var/opt/mssql/data/bak --rm microsoft/mssql-server-linux
- I opted to mount my current local directory I use for db backups to see if I could restore a database I had previously backed up on my Windows based SQL Server 2008 and 2012. It worked way better than I expected!!! If you are using Windows, make sure you escape your backslashes (maybe you can get away with forward slashes too?)
A gotcha or two:
- Make sure if you are using Windows or OSX that Docker is able to access > 3.5 GB of ram. On Docker for Windows in Windows 10, right click the Docker Icon > Settings > Advanced.
SA_PASSWORD is interesting. It’s a disposable container, so I tried setting the password to something dumb like ‘password’. During setup, password policy was upset and complained that I needed to specify a stronger password, which made the container explode. Interesting that the system is telling me, root, what to do!!! sudo make me a sandwich!
You’ll notice I forwarded the ports funny. This is because I have normal SQL Server running on my dev machine. I had to change the port it was listening on since it was in use on my host. Which brings me to the most obnoxious part of getting this working…
Apparently, unlike the rest of the networking universe, if you want to connect with SSMS on a specific port, the connection is
HOSTNAME:PORT. If you use a colon like a normal person, you will never connect to your db. It feels more like a timeout/networking issue than a syntax error, so it was easy to assume something was actually wrong. It’s a comma folks, not a colon.
This worked much better than the last time I tried Dockering around MS technology. Get that .NET 4.6 dependency resolved and toss this stuff in a docker-compose file, and booyah. I love the future.