SQL Server w kontenerze pozwala szybko wdrażać i replikować środowiska testowe dzięki obrazom Docker.
Jak działa SQL Server uruchomiony w kontenerze
SQL Server w kontenerze jest instancją Microsoft SQL Server działającą wewnątrz odizolowanego procesu uruchomionego przez silnik kontenerowy, najczęściej Docker Engine. Microsoft publikuje obrazy dla systemu Linux w rejestrze Microsoft Container Registry. Przykładowy obraz można pobrać z adresu mcr.microsoft.com/mssql/server, a konkretny tag obrazu określa używaną wersję oraz wariant SQL Server. Kontener nie jest osobnym silnikiem bazy danych, lecz sposobem dostarczenia i uruchomienia instancji SQL Server wraz z wymaganym środowiskiem systemowym.
Przy pierwszym uruchomieniu obraz wymaga zaakceptowania umowy licencyjnej przez zmienną środowiskową ACCEPT_EULA=Y. Hasło konta sa przekazuje się przez MSSQL_SA_PASSWORD; musi ono spełniać zasady złożoności wymagane przez SQL Server. Port TCP używany przez silnik to standardowo 1433, ale port kontenera można opublikować pod innym numerem na hoście. Przykładowe uruchomienie wykorzystuje parametry -p 1433:1433, -e ACCEPT_EULA=Y oraz -e MSSQL_SA_PASSWORD=....
Obraz, kontener i trwałość danych
Obraz zawiera pliki potrzebne do uruchomienia SQL Server, natomiast kontener jest konkretną instancją uruchomioną na podstawie tego obrazu. Usunięcie kontenera nie powinno oznaczać usunięcia baz danych. Pliki danych, logów transakcyjnych i innych elementów instancji należy przechowywać w wolumenie zamontowanym w ścieżce /var/opt/mssql. Przykładowy wolumen Docker można przypisać parametrem -v sqlserver-data:/var/opt/mssql. Bez takiego trwałego magazynu odtworzenie kontenera może pozostawić środowisko bez wcześniej zapisanych baz.
Powtarzalność wdrożenia wynika z jawnego wskazania obrazu, zmiennych środowiskowych, mapowania portów, wolumenów i sieci. Do testów można użyć edycji Developer, ustawiając MSSQL_PID=Developer, o ile warunki licencyjne tego zastosowania są spełnione. W środowisku odtwarzanym przez zespół warto używać ustalonego tagu obrazu zamiast nieokreślonego tagu aktualizowanego automatycznie. Aktualizacja obrazu nie powinna być utożsamiana z aktualizacją danych: obraz można wymienić, a wolumen z bazą zachować i ponownie podłączyć do nowego kontenera.
Połączenia, konfiguracja i kontrola uruchomienia
Aplikacja znajdująca się w innym kontenerze powinna łączyć się z SQL Server przez nazwę usługi lub nazwę kontenera w tej samej sieci Docker, a nie przez localhost. Wewnątrz kontenera aplikacji adres localhost wskazuje bowiem na samą aplikację. Klient działający na hoście może korzystać z adresu hosta i opublikowanego portu, na przykład localhost,1433. Jeżeli port hosta został zmieniony, klient musi użyć numeru przypisanego po lewej stronie mapowania, przykładowo -p 11433:1433 oznacza połączenie z hosta przez port 11433.
Stan uruchomienia można sprawdzić poleceniami Docker, takimi jak docker ps i docker logs nazwa_kontenera. Sam fakt, że proces kontenera działa, nie potwierdza jeszcze gotowości SQL Server do przyjmowania połączeń. Po starcie silnik może potrzebować czasu na inicjalizację systemowych baz i odczyt istniejących plików z wolumenu. Test powinien obejmować rzeczywiste połączenie klienta oraz wykonanie prostego zapytania, na przykład SELECT @@VERSION;. Warto również zweryfikować, czy używany klient obsługuje szyfrowanie i ustawienia certyfikatu wymagane przez konkretną wersję SQL Server.
Diagnostyka problemów z instancją w kontenerze
Najczęstsze problemy wynikają z błędnej wartości MSSQL_SA_PASSWORD, braku akceptacji licencji, zajętego portu hosta, nieprawidłowego montowania wolumenu albo niewystarczających zasobów systemowych. Log kontenera może wskazać, że SQL Server zakończył pracę podczas inicjalizacji, nie może zapisać plików w /var/opt/mssql albo nie odnalazł oczekiwanych plików bazy. Przy analizie należy rozdzielić błąd silnika SQL Server od błędu narzędzia Docker, sieci lub systemu plików. Restart kontenera nie naprawia uszkodzonych plików danych ani nie zmienia niepoprawnej konfiguracji.
Diagnostyka powinna obejmować identyfikację dokładnego tagu obrazu, sprawdzenie parametrów uruchomienia, dostępności opublikowanego portu, stanu wolumenu oraz wyników połączenia z użyciem właściwego loginu. Jeżeli baza ma być odtwarzana w innym środowisku, bezpieczną metodą jest użycie zweryfikowanej kopii zapasowej lub kontrolowane podłączenie plików, a następnie sprawdzenie integralności i logów SQL Server. W przypadku problemów ze sprzętem lub hostem analizuje się także obciążenie procesora, pamięci masowej i dostępnej przestrzeni dyskowej, ponieważ kontener nie usuwa zależności SQL Server od zasobów systemu, na którym działa.
