В предыдущих двух статьях этой серии мы обсудили важность сохранения данных в контейнерах и где эти данные хранятся на наших системах. Теперь давайте рассмотрим, как мы можем указать местоположение данных на основной файловой системе.
Представьте, что мы хотим предоставить доступ к каталогу нашей базовой операционной системы macOS непосредственно в контейнере, не помещая наши данные в виртуальную машину Docker Linux. Давайте попробуем и посмотрим, что произойдет.
Мы можем запустить контейнер с Docker Volume, сопоставляющим каталог “/Users/demo/demos/data” на базовой ОС с контейнером по пути “/var/opt/mssql”. Вот команда:
docker run
--name 'sql19dv'
-e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD='$PASSWORD
-p 1433:1433
-v /Users/demo/demos/data:/var/opt/mssql
-d mcr.microsoft.com/mssql/server:2019-latest
Однако, когда мы проверяем статус контейнера с помощью “docker ps -a”, мы обнаруживаем, что контейнер завершился с ненулевым кодом выхода. Это нехорошо.
Первое, что мы должны сделать в таких случаях, – это изучить журналы контейнера. Мы можем сделать это с помощью команды “docker logs sql19dv” (где “sql19dv” – это имя контейнера). Журналы предоставят нам диагностическую информацию об ошибке.
В данном случае сообщение об ошибке указывает на то, что программа столкнулась с фатальной ошибкой из-за ошибки ядра. Проблема возникает потому, что macOS не поддерживает режим файла, называемый O_DIRECT, который используется системами, управляющими собственным кэшированием файлов, такими как системы управления реляционными базами данных (RDBMS). В результате файлы данных SQL Server не могут быть открыты в этом режиме, что приводит к сбою контейнера.
К счастью, мы все равно можем использовать Docker Volumes для других частей контейнера. Например, мы можем создать контейнер с использованием двух Docker Volumes. Один том, “sqldata1”, может использоваться для каталога данных внутри Docker VM, в то время как второй том может использоваться для чтения и записи другой информации, такой как резервные копии.
Вот команда для создания такого контейнера:
docker run
--name 'sql19dv1'
-e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD='$PASSWORD
-p 1433:1433
-v sqldata1:/var/opt/mssql
-v /Users/demo/demos/backup:/backup
-d mcr.microsoft.com/mssql/server:2019-latest
В этой конфигурации наш экземпляр SQL будет использовать “sqldata1”, сопоставленный с “/var/opt/mssql”, в качестве каталога данных, позволяя SQL Server открывать файлы с соответствующими режимами файла. Однако мы все равно можем читать и записывать информацию напрямую в нашу базовую ОС в каталоге “/Users/demo/demos/backup”, который сопоставлен с контейнером по пути “/backup”. Файлы резервных копий не требуют флага O_DIRECT.
Например, мы можем выполнить резервное копирование нашей базы данных в этом месте с помощью следующей команды:
sqlcmd -S localhost,1433 -U sa -Q "BACKUP DATABASE [TestDB1] TO DISK = '/backup/TestDB1.bak'" -P $PASSWORD -W
Если мы проверим каталог “/Users/demo/demos/backup” на базовой операционной системе, мы увидим файл резервной копии базы данных вне контейнера. Это позволяет нам легко создавать резервные копии файла в облаке с помощью автоматических процессов резервного копирования.
Мы даже можем совместно использовать том “/backup” с другими контейнерами на нашей системе. Запустив другой контейнер, “sql19dv2”, и убедившись, что у него есть уникальное имя, порт и том для его файлов, мы можем выполнить оператор RESTORE на резервные копии, которые находятся на базовой ОС и сопоставлены с контейнером по пути “/backup”. Эта техника может быть полезной для работы с большими наборами данных, так как она позволяет избежать необходимости копировать резервную копию в контейнер с помощью “docker cp”.
Вот команда для запуска второго контейнера:
docker run
--name 'sql19dv2'
-e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD='$PASSWORD
-p 1432:1433
-v sqldata2:/var/opt/mssql
-v /Users/demo/demos/backup:/backup
-d mcr.microsoft.com/mssql/server:2019-latest
С такой настройкой мы можем выполнить оператор RESTORE на резервные копии, находящиеся на базовой ОС по пути “/Users/demo/demos/backup” и сопоставленные с контейнером по пути “/backup”. Эта техника может использоваться в операционных системах Windows, Linux и macOS.
В заключение, мы узнали, как сопоставить местоположение файла из базовой ОС в контейнере и использовать его для чтения и записи данных, таких как файлы резервных копий. Однако для файлов данных SQL Server нам все равно нужно использовать Docker Volume, обслуживаемый контейнером Linux. Мы также узнали, как совместно использовать Docker Volume между контейнерами, обеспечивая быстрый способ перемещения резервных копий и других данных между контейнерами без использования “docker cp”. Эти техники не являются специфичными для macOS и могут быть применены в системах Windows и Linux.
Следите за новыми статьями о SQL Server и контейнерах Docker!
Читайте оригинальную статью на Centino Systems Blog.