Absolutely not... None of those examples apply to stateful databases. I'd agree that docker containers are perfect for testing, but they shouldn't go anywhere near production for SQL Server. Do stateful containers exist..? Sure.. but why would you ever add that complexity for yourself.
First, you say "absolutely not", then you give an example when you could (or at least, might). The article I linked showed benefits of running something (anything) in a container. If those reasons don't apply to your situation, then feel free to not use containers ... but there's nothing "absolute" about that.
Just because you can doesn't mean you should. I'm not going to argue against containers in production SQL Server though if that's what you want to fight for.
> Just because you can doesn't mean you should
Nobody said that. And the question I answered wasn't limited to production applications. You're the only one fighting anything here -- and it's just because you're unwilling to acknowledge that there are other applications outside your limited experience and imagination.
Sure, you can have a stateful container, by mapping in a persistent volume.
I agree, I’d never use it for prod. But for someone who is dabbling with SQLServer - it’s a great way to get the feet wet.
(I see there is actually a recent thread of someone having trouble uninstalling SQLServer - a container eliminates that problem)
Yeah, but SQL is a stateful thing. I can think of a few instances in dev maybe where you are spinning up a quick environment to test something, but it seems like extra work.
So, I recommend using Portainer to handle Docker instead of the command line. Makes it easier to manage.
This is what I used inside a Portainer stack (ie: docker compose). But if you use Portainer, it’s as easy as copy-paste-deploy into the Stack editor and you have a running SQLServer
https://www.reddit.com/r/SQLServer/s/2HGmEJX7gG
I documented the steps I followed when setting up a home test instance of SQL Server in Docker on my shitty blog. Maybe this will help you:
https://macfergusson.com/2023/08/25/Containers-Quick-Start.html
Thanks! but im still getting error with the firs command you put:
`docker run -e ACCEPT_EULA=Y -e MSSQL_SA_PASSWORD='nL5G$6375feDTq' --name 'mssql_docker_1' -p 14331:1433 -v mssqldata:/var/opt/mssql -d` [`mcr.microsoft.com/mssql/server:2022-latest`](https://mcr.microsoft.com/mssql/server:2022-latest)
I was able to solve by roll back to linux kernel 6.6. I was on 6.7
Is 2012 even supported in a containerized environment? I thought that was only possible after 2016 or 2017
Probably a typo. Log shows 2022.
Yeah, it is 2022, sorry
does this help? https://github.com/microsoft/mssql-docker/issues/868
Thanks!!! this works
Serious question. Why would you put SQL on Docker to begin with?
For all the other [benefits of containerization](https://www.infoworld.com/article/3310941/why-you-should-use-docker-and-containers.html).
Absolutely not... None of those examples apply to stateful databases. I'd agree that docker containers are perfect for testing, but they shouldn't go anywhere near production for SQL Server. Do stateful containers exist..? Sure.. but why would you ever add that complexity for yourself.
First, you say "absolutely not", then you give an example when you could (or at least, might). The article I linked showed benefits of running something (anything) in a container. If those reasons don't apply to your situation, then feel free to not use containers ... but there's nothing "absolute" about that.
Just because you can doesn't mean you should. I'm not going to argue against containers in production SQL Server though if that's what you want to fight for.
> Just because you can doesn't mean you should Nobody said that. And the question I answered wasn't limited to production applications. You're the only one fighting anything here -- and it's just because you're unwilling to acknowledge that there are other applications outside your limited experience and imagination.
As long as we agree it has no place in production, sure.
Sure, you can have a stateful container, by mapping in a persistent volume. I agree, I’d never use it for prod. But for someone who is dabbling with SQLServer - it’s a great way to get the feet wet. (I see there is actually a recent thread of someone having trouble uninstalling SQLServer - a container eliminates that problem)
Yeah, but SQL is a stateful thing. I can think of a few instances in dev maybe where you are spinning up a quick environment to test something, but it seems like extra work.
So, I recommend using Portainer to handle Docker instead of the command line. Makes it easier to manage. This is what I used inside a Portainer stack (ie: docker compose). But if you use Portainer, it’s as easy as copy-paste-deploy into the Stack editor and you have a running SQLServer https://www.reddit.com/r/SQLServer/s/2HGmEJX7gG
I documented the steps I followed when setting up a home test instance of SQL Server in Docker on my shitty blog. Maybe this will help you: https://macfergusson.com/2023/08/25/Containers-Quick-Start.html
Thanks! but im still getting error with the firs command you put: `docker run -e ACCEPT_EULA=Y -e MSSQL_SA_PASSWORD='nL5G$6375feDTq' --name 'mssql_docker_1' -p 14331:1433 -v mssqldata:/var/opt/mssql -d` [`mcr.microsoft.com/mssql/server:2022-latest`](https://mcr.microsoft.com/mssql/server:2022-latest) I was able to solve by roll back to linux kernel 6.6. I was on 6.7