MS SQL Server в Docker

06.06.25

Разработка - DevOps и автоматизация разработки

Готовим контейнеризированный Microsoft SQL Server в среде Windows

Всем контейнеризированный привет!

Недавно на площадке увидел публикацию про установку SQL Server. Хммм, подумал я. И это в 2К25 году. Банально проклацать кнопку "далее" - ну это такое себе. Тем более, что только ленивый не ставил SQL Server. И тут мне пришла идея поделиться с сообществом более технической статьей, так сказать, под современные тренды в айтишке.

Здесь будет полный гайд по созданию и использованию SQL Server в Docker-контейнере.

Если кто вдруг не в курсе, что такое Docker, то расскажу вкратце. Docker - это набор специализированного системного программного обеспечения, позволяющее упаковать в отдельный контейнер вашу программу со всем её окружением и со всеми её зависимостями, и в дальнейшем изолированно запускать вашу программу в своей собственной "песочнице", ресурсы которой будут независимо использоваться от вашей основной системы и от присутствующих в ней программ. Отличие контейнеризации от виртуализации в том, что последняя тратит ресурсы на обслуживание полноценной операционной системы внутри себя. А Docker-контейнер использует ядро текущей операционной системы для управления процессами, дисковыми и сетевыми ресурсами, которые разграничены с основной хост-системой.

Родная система для Докера, это, конечно же, Linux. Но Microsoft прилагает немалые усилия по интеграции Linux в Windows. Поэтому сейчас стало возможно использовать виндовые контейнеры, почти так же, как и линуксовые.

Здесь я покажу виндовую контейнеризацию. В качестве подопытного скуля возьму SQL Server 2019, так как он пока ещё актуален и будет поддерживаться до 2030 года. А также он совместим с новыми и достаточно старыми платформами 1С. Вы же для повторения можете взять любую версию.

Не спешите сразу кидаться помидорами, мол, у нас импортозамещение. Это да. Но MS SQL стоит ещё у многих. А если кто и перевёл на Постгрес свой основной продуктив, то смежные базы, вероятно, на MS SQL.

Поплыли Поехали !

Если у вас на виндовой машине нет докера, то установим его:

Перед установкой убедитесь, что у вас включена аппаратная виртуализация (VT или AMD-V в настройках UEFI/BIOS). Переходим на страницу Install Docker Desktop on Windows и скачиваем инсталлятор "Docker Desktop Installer.exe" и запускаем его. Всё оставляем по умолчанию, проходим шаги инсталлятора, в конце инсталлятор предложит перезагрузиться. После перезагрузки запускаем Docker Desktop - это графическая оболочка над Докером.

Можно управлять докером и через консоль.

docker -v

отобразит текущую версию.

Т.к. я больше уважаю консоль, чем графическую оболочку, то мы будем вводить команды в cmd, а некоторые результаты смотреть в десктопном приложении.

Для начала нам нужно скачать стартовый образ Windows Server 2019. Делается это следующей командой:

docker pull mcr.microsoft.com/windows/servercore:ltsc2019

Я взял за основу Core редакцию Windows Server 2019, вы же можете взять и более новые (или старые).

Забегая наперед, скажу, что контейнеры построены как бы послойно. Т.е. за основу берется какой-либо готовый образ, потом на него накатывают различные обновления, ПО, команды. И получается по аналогии со слоеным пирогом. Это экономит место и время для сборки похожих и/или наследственных контейнеров.

После скачивания на вашу машину проверим существующие образы:

docker images

В ответе будет что-то подобное:

Аналогичную картину можем увидеть и через ГУЙ:

 

Отлично. У нас есть основа. От неё будем далее создавать свой образ.

Для этого создадим пустой текстовый файл и назовём его Dockerfile без расширения. (Выделите у себя на компе отдельный рабочий каталог, в котором будем сохранять всю работу). В этом Докер-файле будем описывать логику построения нашего образа.

Первой строкой пропишем, от какого образа мы будем плясать:

FROM mcr.microsoft.com/windows/servercore:ltsc2019

А пока нам надо раздобыть инсталлятор скуля. Будем брать Developer-версию для разрабов. Она для разработки и тестирования бесплатна, а по функциональности аналогична Enterprise версии.

По ссылке SQL 2019 DEV качаем онлайн инсталлятор. Запускаем его. Выбираем 3-й пункт "Download Media":

 

Далее переставляем переключатель на "CAB", ниже выбираем нашу рабочую папку и нажимаем кнопку "Download".

 

Через *цать секунд у нас в нашем рабочем каталоге появятся 2 файла: "SQLServer2019-DEV-x64-ENU.exe" и "SQLServer2019-DEV-x64-ENU.box". Это инсталлятор и дата-файл для стокового SQL Server 2019 Developer Edition.

Ещё один служебный файл надо скачать с официального репозитория Microsoft. Он нужен для присвоения пароля и присоединения существующих баз данных. Положите его тоже в нашу рабочую папку.

Т.к. скуль-сервер стоковый, надо еще скачать последнее кумулятивное обновление. Переходите на страницу и скачивайте самый свежий на данный момент KBxxxxxxx. Переименуем этот новый скачанный файл из "SQLServer2019-KBххххххх-x64.exe" в "SQLServer2019-CU-x64.exe" для дальнейшего удобства.

 

У нас всё готово для создания образа скуля. Вернёмся к нашему Dockerfile. Далее в нём прописываем переменные окружения:

ENV sa_password="_" \
    attach_dbs="[]" \
    ACCEPT_EULA="_" \
    sa_password_path="C:\ProgramData\Docker\secrets\sa-password"

Пропишем поведение скрипта при различных обстоятельствах:

SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]

Затем копируем в образ в корень файловой системы необходимые файлы:

COPY start.ps1 /
COPY SQLServer2019-DEV-x64-ENU.exe /
COPY SQLServer2019-DEV-x64-ENU.box /
COPY SQLServer2019-CU-x64.exe /

Задаем текущую рабочую директорию для контейнера:

WORKDIR /

Запускаем процесс установки SQL-сервера:

RUN Start-Process -Wait -FilePath .\SQLServer2019-DEV-x64-ENU.exe -ArgumentList /qs, /x:setup ; \
        .\setup\setup.exe /q /ACTION=Install /INSTANCENAME=MSSQLSERVER /FEATURES=SQLEngine /UPDATEENABLED=0 /SQLSVCACCOUNT='NT AUTHORITY\NETWORK SERVICE' /SQLSYSADMINACCOUNTS='BUILTIN\ADMINISTRATORS' /TCPENABLED=1 /NPENABLED=0 /IACCEPTSQLSERVERLICENSETERMS ; \
        Remove-Item -Recurse -Force SQLServer2019-DEV-x64-ENU.exe, SQLServer2019-DEV-x64-ENU.box, setup

Далее останавливаем службу SQL-сервера и меняем некоторые настройки:

RUN stop-service MSSQLSERVER ; \
        set-itemproperty -path 'HKLM:\software\microsoft\microsoft sql server\mssql15.MSSQLSERVER\mssqlserver\supersocketnetlib\tcp\ipall' -name tcpdynamicports -value '' ; \
        set-itemproperty -path 'HKLM:\software\microsoft\microsoft sql server\mssql15.MSSQLSERVER\mssqlserver\supersocketnetlib\tcp\ipall' -name tcpport -value 1433 ; \
        set-itemproperty -path 'HKLM:\software\microsoft\microsoft sql server\mssql15.MSSQLSERVER\mssqlserver\' -name LoginMode -value 2 ;

Накатываем поверх кумулятивное обновление:

RUN Start-Process -Wait -FilePath .\SQLServer2019-CU-x64.exe -ArgumentList '/Action=Patch /InstanceName=MSSQLSERVER /quiet /IAcceptSQLServerLicenseTerms' ; \
        Remove-Item -Recurse -Force SQLServer2019-CU-x64.exe

Проверяем, работает ли сервак, выполнит ли он SQL-запрос?:

HEALTHCHECK CMD [ "sqlcmd", "-Q", "select 1" ]

Стартуем сервер с нашими входными параметрами, которые будем задавать при старте контейнера:

CMD .\start -sa_password $env:sa_password -ACCEPT_EULA $env:ACCEPT_EULA -attach_dbs \"$env:attach_dbs\" -Verbose

 

Кажется сложно, но нет. Выше мы описали примитивные действия. Далее будет самое интересное.

Проводя аналогии, можно сказать следующее: если представить образ (image) в качестве слоёного пирога, то Dockerfile является рецептом этого пирога; если образ - это инсталлятор для программы, то контейнер - это уже запущенная программа.

 

На данном шаге у нас всё готово для сборки нашего образа! Запускаем билд:

docker build --memory 4g --tag=microsoft/mssql-server-windows-developer-2019:latest .

Вместо четвёрки в 4g вы можете выделить любой размер оперативки, который вам не жалко для сборки, но и этого объема хватает. Ключ tag задаёт имя образа; по данному имени в дальнейшем будем запускать контейнеры.

Ждем *цать секунд, пока образ соберется. Имя у него будет "microsoft/mssql-server-windows-developer-2019", как мы задали в команде.

Теперь мы можем запустить контейнер из нашего образа! Прелесть Докера в том, что из одного образа мы можем запустить множество контейнеров, в каждом из которых будет "крутиться" свежий SQL Server 2019 Developer Edition, независимый от серверов в других контейнерах.

Запустим:

docker run --name sql2019dev -d -p 1444:1433 -e sa_password=Aa123456! -e ACCEPT_EULA=Y microsoft/mssql-server-windows-developer-2019

Обратите внимание, что в данной команде мы мапим (делаем соответствие) наш порт на компе 1444 на порт sql-сервера в контейнере 1433. (по дефолту у ms sql server порт 1433, но у меня он занят основным скулём, вы же можете назначить любой доступный порт, даже 1433, если он у вас не занят). Пароль ставьте свой, этот приведён для примера.

Смотрим в Docker Desktop:

 

или в консоли:

docker ps

 

У нас запущен полноценный SQL Server в контейнере! Подключимся к нему через SSMS:

Обратите внимание: порт указывается через "," (через ЗАПЯТУЮ, Карл!), а не как мы все привыкли - через ":" .

Полноценный (* почти) сервер для разработки и тестирования в строю!

 

Мы можем интерактивно зайти в контейнер и посмотреть, что там и как происходит:

 

или то же самое консолью:

docker exec -it XXXXXXXX cmd

где вместо XXXXXXXX надо указать ID контейнера

 

Зачем я всё это читаю? А где же тут 1С ? А вот она. Ради этого всё и затевалось )

Создадим серверную базу данных 1С (не забываем про порт через запятую):

И оно работает! В контейнере! Невероятно, но факт!

 

Для чего это всё надо, можете спросить вы?

Во первых, вы НЕ захламляете и НЕ утяжеляете свой ПэКа. Достаточно 1 раз запустить сборку образа, а потом из этого образа запускать серваки для своих целей. Вы можете передать Dockerfile другу, который по аналогии соберет у себя образ и будет запускать скуль для работы/учёбы/развлечений/прочее. Во вторых, можете у себя поднять SQL-кластер из нескольких серверов. И всё это на одной машине. С минимальным потреблением ресурсов (образ занимает всего около 10 Гиг дискового пространства). С большим удобством/скоростью запуска/остановки сервера.


Представьте ситуацию: нам передали файлы базы данных sql-сервера. (мы же все знаем, что это *.mdf и *.ldf файлы). Нет ничего проще, чем пробросить их в наш контейнер и далее работать с предоставленной базой:

docker run --name sql2019devDB -d -p 1455:1433 -v D:/PROJECT/Docker/win_sql/FileStorage1C:C:/temp/ -e sa_password=Aa123456! -e ACCEPT_EULA=Y -e attach_dbs="[{'dbName':'FileStorage1C','dbFiles':['C:\\temp\\FileStorage1C.mdf','C:\\temp\\FileStorage1C_log.ldf']}]" microsoft/mssql-server-windows-developer-2019

Здесь мы мапим нашу папку с файлами базы данных на папку внутри сервера, а скрипт для старта приаттачит файлы базы к запускаемому серверу:

Удобно? Очень удобно!

 

Также с помощью виртуальных томов (volumes) мы можем прописать при запуске контейнера пути, чтобы файлы создаваемых баз данных записывались в нашу файловую систему, чтобы при повторном старте контейнера продолжить работать с существующими данными. Можно создавать виртуальные сети и объединять контейнеры в независимые локальные сети, где внутри подобной сети контейнеры будут "видеть" друг друга. А ещё существуют специализированные ПО для оркестрации контейнеров, где оркестратор "рулит" контейнерами, например, может перезапускать упавшие контейнеры, может масштабировать нагрузку, поднимая или прибивая контейнеры и много чего другого, выходящего за рамки данной статьи.

И много много всего интересного можно делать с контейнеризацией. Это современный тренд, и используется он в современной разработке и ДевОпсе повсеместно.

 

* Microsoft не рекомендует использовать SQL Server в контейнере на продуктиве, т. к. перезагрузка контейнера Windows приводит к изменению ключа машины, и, следовательно, если у вас настроено какое -либо шифрование, перезагрузка SQL в контейнерах Windows порвёт цепочку ключей шифрования в SQL Server. Поэтому не существует официальных Docker-образов для скуля. Но в целях разработки вполне подходит собранный нами контейнер.

 

Надеюсь, что статья кому-то будет полезной и кто-то может подчерпнёт для себя что-то новое.

А если вам зашёл контент, то ставьте лайки плюсы. Наберётся много, напишу ещё что-нить про докер, например, 1С в докере (Win / Lin) или Постгрес в докере (на Линуксе).

Также не забывайте заходить на мой гитхаб. Выложу материалы по статье туда.

 

Всем творческих успехов и до скорого!

 

SQL server Docker DevOps сервер разработка pipeline

См. также

Тестирование QA DevOps и автоматизация разработки Программист Пользователь Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.173.37.

2160 руб.

20.01.2022    9209    36    0    

17

DevOps и автоматизация разработки Программист Платформа 1С v8.3 Россия Абонемент ($m)

Устали от ручной поддержки версий обработок, отчетов и печатных форм в 1С в разных базах, ошибок и перезаписи важных изменений разными программистами? Автоматизируйте процессы с CI/CD и Jenkins. Читайте статью, скачивайте готовые скрипты и настройки, ставьте плюс и делитесь с коллегами!

2 стартмани

09.06.2025    4268    da_1c    12    

3

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) EDT Программист Платформа 1С v8.3 Бесплатно (free)

В процессе использования 1С:EDT и репозитория Git для обновлений релизов доработанных конфигураций появилась необходимость в регулярной загрузке конфигураций от вендора 1С в Git-репозиторий. Описанное в статье решение позволяет автоматизировать эту операцию и может быть полезным специалистам, занимающимися обновлениями с использованием 1C:EDT+Git

21.05.2025    1906    ICL-Soft    3    

17

DevOps и автоматизация разработки Программист Платформа 1С v8.3 Бесплатно (free)

В проектной разработке часто возникают проблемы с однообразностью ландшафта, производительностью и быстрой разверткой инфраструктуры. Об одном из способов избежать или изолировать данные проблемы с помощью контейнеризации расскажем в статье.

18.09.2024    6449    antonov_av    6    

16

DevOps и автоматизация разработки Бесплатно (free)

Когда информационная база «весит» несколько десятков/сотен гигабайт, для разработки и тестирования обычно используют полную копию рабочей базы. Но если информационная база превышает несколько терабайт, такой подход сталкивается с нехваткой места на диске, долгой реструктуризацией, замедленной скоростью работы и другими проблемами, связанными с размером базы. В статье расскажем, как правильно готовить копии больших баз для разработки и тестирования.

28.08.2024    12163    yuraid    32    

61

DevOps и автоматизация разработки Программист Бизнес-аналитик Руководитель проекта Платформа 1С v8.3 1С:Документооборот Россия Бесплатно (free)

В данной инструкции рассмотрим процесс развертывания приложения на Python с использованием фреймворка Flask и Tesseract OCR в контейнере Docker. Узнаем, как использовать Tesseract в связке с Flask и осуществлять обращения к Tesseract для обработки изображений. Рассмотрим пример обращения к приложению Docker из 1С, в том числе для замещения CuneiForm в старых конфигурациях 1С:Документооборот версии 1.4 и ниже.

20.08.2024    5125    romanichenko    2    

9

DevOps и автоматизация разработки Тестирование QA Программист Пользователь Платформа 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Зарплата и Управление Персоналом 3 и версии КОРП: 3.1.30.178.

3240 руб.

05.08.2024    2578    17    1    

11

DevOps и автоматизация разработки OneScript Системный администратор Программист Стажер Бесплатно (free)

Рассмотрим создание самоформирующейся документации через комментарии и соглашения: как это сделать и зачем, с описанием полного цикла от исходников конфигурации до странички в интернете

17.06.2024    9969    bayselonarrend    5    

63
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. akR00b 25 23.05.25 09:30 Сейчас в теме
Супер статья, спасибО! Постгрес в докере (на Линуксе) и на Вин было бы еще интереснее)) ждем!
slavik27; SerVer1C; +2 Ответить
14. Segate 270 25.05.25 21:39 Сейчас в теме
(1) https://hub.docker.com/r/segateekb/pg_pro
Docker pull, docker run
Есть все версии с 12 до 15 или до 16... Надо будет проверить
2. akR00b 25 23.05.25 09:31 Сейчас в теме
единственный вопрос, при перезапуске контейнера или системы в целом (данные внутри контейнера сохраняются?)
3. SerVer1C 921 23.05.25 09:50 Сейчас в теме
(2) Проверил. Да, базы внутри контейнера сохраняются.
15. Segate 270 25.05.25 21:41 Сейчас в теме
(3) сохраняются, если вы вольюм прокинули...
Если вольюма нет, то при пересоздания контейнера- все пропадет.(При пересоздания, а не при перезапуске)£
4. akR00b 25 23.05.25 13:15 Сейчас в теме
5. slavik27 105 23.05.25 14:49 Сейчас в теме
спасибо, классная статья инструкция, будем пробовать
SerVer1C; +1 Ответить
7. SerVer1C 921 24.05.25 10:50 Сейчас в теме
(6) Почитайте внимательно статью
8. TMV 9 24.05.25 12:20 Сейчас в теме
(7) Зачем? Как установить Docker Desktop и так понятно.
10. SerVer1C 921 24.05.25 12:57 Сейчас в теме
(8) для невнимательных: контейнер работает на win server
20. TMV 9 26.05.25 13:15 Сейчас в теме
(10) А зачем win в контейнере? В чем плюсы?
21. SerVer1C 921 26.05.25 13:43 Сейчас в теме
(20)
А зачем win в контейнере?
Затем же, для чего и win на сервере используют.
В чем плюсы?
В данном случае это родная среда для MS SQL Server.
9. aximo 2350 24.05.25 12:53 Сейчас в теме
Есть статистика от том как это все стабильно работает???
11. SerVer1C 921 24.05.25 13:03 Сейчас в теме
(9) У меня статистики нет, но в инетах должна быть. Думаю, что стабильность должна быть такая же, как и у нативных сервисов/процессов.
12. comol 5252 25.05.25 01:50 Сейчас в теме
Хотел уже написать "НЕ НАДО ПИХАТЬ СУБД В DOCKER!"
но нашел оговорку в тексте статьи от автора :))))
Только для разработки, коллеги, только для разработки...
13. SerVer1C 921 25.05.25 08:10 Сейчас в теме
(12) Дайте развернутый ответ, почему, по вашему, не надо СУБД в докер
16. Segate 270 25.05.25 22:00 Сейчас в теме
(13) ну... Все зависит от архитектуры.

Если мы говорим про докер-десктоп(на Винде или, прости Господи, на маке) то тут все понятно.
Связка виртуализации(wsl)+ контейнеризации даёт нехилый такой оверхед, без основных плюшек.
Если мы говорим про Линукс, и, скажем, кубернетес, то мы должны подразумевать, что приложение к нас может мигрировать между нодами, и нужно обеспечить его доступность, а значит бд, должна болтаться где- то или на нас, или на каком- нибудь cephfs для получения распределенного хранилища, что опять-же бьёт по производительности и увеличивает требования к сети.

А вот если мы используем нативный докер, без прослоек, просто для изоляции и ограничения ресурсов- то тогда, с одной стороны, будет минимальный оверхед, а с другой- минимальный Профит от использования. Проще уж просто напрямую выделить неймспейс, а ресурсы ограничить через cgroup.

По итогу: если знать что делать, если у тебя идеальные условия и ты умеешь готовить, то контейнер для субд- ничем не плох. Но и ничем особо не хорош
Dach; starik-2005; +2 Ответить
17. comol 5252 26.05.25 01:47 Сейчас в теме
(16) Не в оверхеде одном счастье. Глубже
18. comol 5252 26.05.25 01:57 Сейчас в теме
(13) Всё что далее напишу строго про "продакшн". К докеру для разработки никак не относится, для разработки - более чем норм.

В продакшене же СУБД в докер = расстрел вот почему:

1) C - Consistency. Для Presistence надо подключить volume. Который очевидно может храниться где угодно и как угодно. В случае с докером - это не будет Local volume - соответственно будет что то в сети. Которое может падать бай дизайн, ответив при этом "да, данные записаны на диск" (помним же у постгри есть даже fsync - не доверяй никому, даже локальному кэшу). С учетом того что для контейнера НОРМАЛЬНО когда он падает и поднимается, перемонтирует ФС, особенно в кубере согласованность данных очевидно нарушается рано или поздно, оттуда нарушается ACID и вообще теряют смысл транзакционные СУБД

2) В продакшене же у вас не будет докера, а будет докер в кубере... а там не всё так просто, вообще контейнеры должны иметь возможность падать и подниматься, для СУБД это почти непреемлимо. Я не эксперт по куберу, поэтому сошлюсь на флант https://highload.ru/moscow/2018/abstracts/4266

3) Для OLTP систем ключевой параметр Latency i\o подсистемы. Оверхед небольшой, но сетевой диск для OLTP неприемлим - задержки конские.

4) Для продакшена добавляем репликацию и fail over уровня СУБД что очевидно и вот тут появялются очередные проблемы с отключаемым докером, идентификацией узлов и т.п.


Всё вышескзанное конечно справедливо и имеет значение ТОЛЬКО для продакшн сред, ТОЛЬКО для OLTP систем и только для Транзакционных СУБД. Всё остальное в докер пихать нужно, правильно, удобно
SirAlex; Dach; kauksi; starik-2005; +4 Ответить
19. starik-2005 3179 26.05.25 10:40 Сейчас в теме
(18)
в докер пихать
В свое время докер вылупился из необходимости поддерживать идентичное окружение в деве, проде, тесте, где-то еще у удаленщика-непойминачем или еще там кого. Потом из этого ленивыми людьми было взято все, чтобы уменьшить себе телодвижений, а произвидительность была выше, чем на виртуалках, поэтому ленивые медленно выгреблись с виртуалок, т.к. нужна скорость. Ну и экспириенс, полученный при разворачивании контейнеров условной одной кнопкой понравилась, после чего народ, как малое дите, стал тянуть это в ротпрод. С другой стороны, компы работают быстрее и быстрее, так почему бы и нет? Ну не всем же надо 1к записей в секунду мутить в предельных пределах. А то скайп у прибалтов еще когда была, то на постгресе без всех этих докеров достигала 20к в сек, но это было давно и неправда. Кстати, а где она ща? Неужели загнулась?
SirAlex; comol; +2 Ответить
22. aleksxx 70 27.05.25 01:13 Сейчас в теме
23. fuser 3 27.05.25 11:49 Сейчас в теме
Прикольно конечно. Но докер был придуман для сохранения/восстановления окружения. А окружение - это разные приложения, библиотеки и их настройки. Хранить там стандартный MS SQL смысла не вижу.
С помощью MS SQL Setup создал установочный ini файл и можешь в пакетном режиме устанавливать MS SQL. Файл настроек занимает пару Кб. Зачем несколько ГБ файлов данных тянуть в контейнер?
Можно несколько экземпляров MS SQL установить на одну ОС на разных портах с разными настройками и запускать их одновременно или по очереди.
26. SerVer1C 921 27.05.25 13:16 Сейчас в теме
(23) Вы сами себе противоречите. На докер-хабе существуют различные образы контейнеров с СУБД внутри.
34. fuser 3 28.05.25 11:54 Сейчас в теме
(26) на докер-хабе много чего существует. Какое это имеет отношение к нам?
35. SerVer1C 921 28.05.25 11:57 Сейчас в теме
(34) Есть официальный образ sql server на линуксе от майкрософта. Они что, дураки, по вашему, что предоставляют СУБД в контейнере? Если вы не видите смысла, это не означает, что его нет.
24. Dach 388 27.05.25 12:33 Сейчас в теме
(0) зачем все это, если достаточно поставить расширение portainer (уже давно есть в составе самого докер-десктоп), а в нем есть готовый шаблон для скачивания и поднятия контейнера MS SQL Server Dev edition ? Выполняется в 3 клика мышкой

При необходимости шаблон можно чутка поправить и прокинуть волумы туда, куда нужно
25. SerVer1C 921 27.05.25 13:13 Сейчас в теме
(24)
есть готовый шаблон для скачивания и поднятия контейнера MS SQL Server Dev edition
К сожалению, с windows контейнером таких НЕ существует в природе.
27. Dach 388 27.05.25 13:58 Сейчас в теме
(25) тут выше уже писали, что запихивать СУБД в контейнер приемлемо только для dev-контура или максимум для контура тестирования. А если так, то не все ли равно, какая там ОС под капотом? И для целей разработки MS SQL на lin-контейнере вполне нормально работает. А если контейнер на win, то зачем все эти танцы с бубном то? В чем проблема на родную хостовую win-систему просто поставить его как службу и все? Где профит?
28. SerVer1C 921 27.05.25 14:05 Сейчас в теме
(27) Можно нативно и на win и на lin поставить. Причем, как сказали выше, даже несколько инстансов. Можно вообще ничего не ставить. Можно и на рабочий сервак установить. Вариантов множество. Тут каждый ищет профит для себя.
29. Dach 388 27.05.25 14:14 Сейчас в теме
(28) все смешалось в доме Облонских - кони, люди...
Вы зачем-то взяли и запихнули в win-контейнер нативное win-приложение.
Которое отлично ставится и на хостовую систему.

При этом выгода контейнера только в том, что не засоряются системные файлы и настройки хостовой системы и на этом все.

Ах да, почему-то в статье не упомянуто о том, что еще при такой установке мы внутри контейнера теряем возможность запускать службу sql-агента и таким образом нам недоступен запуск заданий по расписанию.

Короче, публикация из серии "не было печали - купила баба порося"
31. SerVer1C 921 27.05.25 14:17 Сейчас в теме
(29)
Вы зачем-то взяли и запихнули в win-контейнер нативное win-приложение.
Которое отлично ставится и на хостовую систему.
Вообще-то всё можно установить на хостовую систему. К чему тогда придумали докер??
32. Dach 388 27.05.25 14:24 Сейчас в теме
(31) для запуска в изолированной среде (чтобы исключить влияние окружения) приложений - раз; для запуска на win контейнеров lin - два (конкретно докер-десктоп и wsl создавались именно для этого); для организации удобного, мигрируемого и легко оркестрируемого рабочего места разработчика - три; возможность автоматизировано запускать и останавливать контейнеры - четыре. Это как минимум

Ваша установка не одному из этих преимуществ не соответствует. Не, ну ок, потренировались образы заворачивать в контейнеры - тоже хорошо, конечно
33. SerVer1C 921 27.05.25 14:31 Сейчас в теме
(32)
Ваша установка не одному из этих преимуществ не соответствует.
Перечитайте ещё раз статью.
Не, ну ок, потренировались образы заворачивать в контейнеры - тоже хорошо, конечно
В RU сегменте инета вроде бы нет инфы, как завернуть мс скуль в виндовый контейнер. Тренировки - наше всё.
30. Dach 388 27.05.25 14:16 Сейчас в теме
Оставьте свое сообщение