Is there a way to start an MSSQL server in Docker with an initially created database? I like to avoid to mount entrypoint scripts.
For instance, in PostgresSQL, one simply can start the server with environmental variable POSTGRES_DB=mydb in order to have database named mydb automatically created. I am looking for an equivalent option for MSSQL.
Related
I am having a VERY difficult time publishing a pre-existing SQL Server project to a Docker hosted instance of SQL Server.
What I am attempting to do is make a clean pipeline for a Docker hosted instance to use in testing a SQL Server project, which of course starts with doing it first by hand to understand all the steps involved. The SQL Server project itself has been around for many years, and has no problems deploying to SQL Server instances hosted on Windows boxes.
As near as I can tell, the issue comes while SSDT is generating the SQL Server deployment script itself. In a normal deployment to a Windows hosted SQL Server, the generated script starts out with some :setvar commands, including:
:setvar DefaultDataPath "C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\"
:setvar DefaultLogPath "C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\"
However, when publishing to a Docker hosted instance of SQL Server, and the same deployment process, the SQL script has:
:setvar DefaultDataPath ""
:setvar DefaultLogPath ""
The 1st thing this deployment does is to alter the database by adding in an additional data file, e.g.:
ALTER DATABASE [$(DatabaseName)]
ADD FILE (NAME = [ARCHIVE_274A259D], FILENAME = N'$(DefaultDataPath)$(DefaultFilePrefix)_ARCHIVE_274A259D.mdf') TO FILEGROUP [ARCHIVE];
The Docker based deployment then craps itself because the file path is (obviously) invalid.
In researching this problem, I've seen MANY solutions which hand-edit the generated deployment SQL script, and manually set the "proper" values for DefaultDataPath and DefaultLogPath ... and even one solution that ran the generated Sql through some sort of post-processor to make that same edit in a programmatic way with string replacement. This does work, but is less than optimal (especially in an automated build/test/deploy pipeline).
I've checked in the Docker instance itself, and its mssql.conf file does have defaults defined:
$ cat /var/opt/mssql/mssql.conf
[sqlagent]
enabled = false
[filelocation]
defaultdatadir = /var/opt/mssql/data/
defaultlogdir = /var/opt/mssql/log/
Can anybody shed light on why these are not being picked up by the SSDT process of generating the deploy script?
I spent a few days trying various workarounds to the problem ...
Defined the DATA and LOG directories in the Docker "run" command, but this had no effect on the gnerated Sql deploy script, e.g.: -e 'MSSQL_DATA_DIR=/var/opt/mssql/data/' -e 'MSSQL_LOG_DIR=/var/opt/mssql/log/'
Configure the Sql Project with SQLCMD Variables. This method could not override the DefaultDataPath or DefaultLogPath. I could add new Variables, but those would not affect the file path of the ALTER DATABASE command above.
Tried a Pre-Deployment script specifically tailored to override the values of DefaultDataPath and DefaultLogPath. While this technically CAN override the default values, the Pre-Deployment script is included in the generated Sql deployment script after the ALTER DATABASE commands to add data files. It would effectively work for the rest of the script, just not the specific portion that was throwing the error on initial deployment of the database.
At this point I feel there is either a Sql Server configuration option that I am simply unaware of, or possibly a flaw in SSDT which is preventing it from gathering the Default Path values from the Docker Sql Server instsance. Any ideas?
I'm using a postgresql (9.6) database in my project which is currently in development stage.
For production I want to use an exact copy/mirror of the database-cluster with a slightly different name.
I am aware of the fact that I can make a backup and restore it under a different cluster-name, but is there something like a mirror function via the psql client or pgAdmin (v.4) that mirrors all my schemas and tables and puts it in a new clustername?
In PostgreSQL you can use any existing database (which needs to be idle in order for this to work) on the server as a template when you want to create a new database with that content. You can use the following SQL statement:
CREATE DATABASE newdb WITH TEMPLATE someDbName OWNER dbuser;
But you need to make sure no user is currently connected or using that database - otherwise you will get following error.
ERROR: source database "someDbName" is being accessed by other users
Hope that helped ;)
I'm onboarding in a company that handles bootstrapping the database using a small SQL Server backup file. I prefer to avoid having to pollute my main Windows installation with various middleware, so I'd like to dockerize as much of this as possible.
That said, I'm not very familiar with SQL Server administration, so I'm somewhat at a loss as to how to accomplish the details, and if my thinking on this is at all correct.
I'm considering two basic approaches to this:
Make initializing the database (i.e. restoring the backup) part of the build for the database image. That is, I'd add a Dockerfile with FROM microsoft/mssql-server-windows-express to the project, restore the backup file, end up with a container image with the database ready as the end result.
The upside here is that it kind of makes sense for this to be part of the image build - if the initial backup file is updated, I only need to use docker-compose up --build to get a correct state.
The drawback is the data files should probably be in a Docker volume, and those don't really exist at container build-time. Having to remember to clear the volume before image rebuild to actually recreate a schema seems like it would kind of obviate the desired advantage.
Make a one-off tool to restore the database into a MDF+LDF stored in a Docker volume, then detach them from the server. Then use the attach_dbs environment variable to attach them in the SQL Server service that'll be running long-term.
This approach makes it obvious that the lifetime of the database files is independent from the lifetime of any given SQL Server instance.
My questions then are:
Which of those approaches is a better idea, if they're even both at all workable?
Is there a better approach to accomplish going from .bak -> working database in container?
How do I restore, using the command-line, a SQL Server database backup to a specific path - i.e. "C:\Data" within the container. (That will be mapped to a host directory using a volume.)
Its not clear exactly when you need the state of the container database to be reset, both your options sound like they'd work.
In the event that changes to the backup require the database to be rebuilt, this can be done quite efficiently in a two stage windows container:
from microsoft/mssql-server-windows-developer as db_restore
copy db.bak \.
run Invoke-Sqlcmd -Query \"restore database [temp] from disk = 'c:\\db.bak' \
with move 'Db_Data' to 'c:\\db.mdf', \
move 'Db_Log' to 'c:\\db.ldf'\"
run Invoke-Sqlcmd -Query \"shutdown with nowait\"
from microsoft/mssql-server-windows-developer
workdir \data
copy --from=db_restore \db.mdf .
copy --from=db_restore \db.ldf .
run Invoke-Sqlcmd -Query \"create database [Db] \
on primary ( name = N'Db_Data', filename = N'c:\\data\\db.mdf') \
log on (name = N'Db_Log', filename = N'c:\\data\\db.ldf') for attach\"
I have installed PostgreSQL 9.4.6 in docker image with docker version 1.10.1. According to this official image:
https://github.com/docker-library/postgres/blob/443c7947d548b1c607e06f7a75ca475de7ff3284/9.4/Dockerfile
As it is said here , that to create initial databases I add my sql script in "/docker-entrypoint-initdb.d" .
https://hub.docker.com/_/postgres/
Now after having some trouble I found that when I add query to create a database in sql script where database name has '-' ,they just cause the container to crash(i.e. the containers exits just after starting).
But query with having no '-' in database name works fine and container also doesn't crash and i can access those database.
For example, This query runs fine.
create database 1stName_2ndName with owner vagrant;
But I tried both of this queries individually and it fails for both cases
create database '1stName-2ndName' with owner vagrant;
or
create database 1stName-2ndName with owner vagrant;
Note: consider queries without double-quotation. vagrant user is already created and works fine.
I have a database which name is 1stName-2ndName. Can anybody help me to figure out the issue?
At my local Postgres installation, the following query works without a problem:
create database "1stName-2ndName" with owner vagrant;
How do I create a database generator to allows a user to create his own table in the database without access to PHPMyAdmin and without any emphasized text knowlege about PHP or MySQL?
You at-least need the sql file to run so that the database can be created....
create the sql file (the whole backup of the database along with subroutines)
just load the database via this command
mysql -u'root' -p'password' databaseName < /path/to/file.sql
In order to run mysql, it should be in your environment variable..