In my last blog post I wrote about how to use a Tomcat container and war files for mid-tier testing. In this one I'd like to show you how the combination of a database container and the Remedy silent install process can be used to speed up test server deployment. Other advantages of this approach include
- being able to consistently reproduce a system in the same state.
- less concern about disposing of a system after testing as it is easily recreated.
- use of database backups provides options for quickly restoring test systems to known good states.
The option to run Remedy with a flat file database went away many moons ago (bonus points if you can name the last version to offer this) and the current versions require either MS-SQL or Oracle, both of which are large and complex pieces of software. The effort required to download, install, and configure these databases can add significantly to the time taken to create a test environment. Wouldn't it be nice to be able to run a few commands and have a new database instance up and running, ready for use? Containers to the rescue!
Both MS-SQL and Oracle are available as containers which means that a lot of the work needed to get them set up has already been done. The Oracle container is more complex to manage, as well as being larger, so this article will focus on using MS-SQL.
If you've read any of my previous articles you won't be surprised to find that we're going to be using a Linux system for our tests, specifically a CentOS 7 virtual machine. At this point those of you that are familiar with the Remedy compatibility documents may be wondering about the combination of MS SQL and Linux. There are two things to consider, firstly the use of Linux for the database platform and, secondly, whether a Linux based AR Server can talk to an MS SQL database.
Remedy has always been very platform agnostic with regards to the OS used to host the database. If it looks like an MS SQL server, runs like an MS SQL server and squeaks like an MS SQL server, there's a very good chance that Remedy will run just fine. On the second point, one of the consequences of the move to Java for the AR platform in version 9.0, was that the AR Server started using JDBC in place of the native database drivers of earlier releases. This means that it is possible BUT NOT SUPPORTED for an AR Server running on Linux to use an MS SQL database. Please note the highlighted comments in the previous sentence! Yes, a Linux AR Server will work with MS SQL, but this should only be used for test systems as, at the time of writing, BMC DO NOT support this combination and you use it at your own risk.
OS Update and Docker Install
Start by making sure that the operating system is up-to-date, rebooting if many packages or the kernel are refreshed.
# yum update
Create working directories to store our files. If you don't use /docker you will need to substitute your choice in some of the later commands.
# mkdir -p /docker/mssql
# cd /docker
If you haven't already installed Docker use these steps to add the software repository, install, and start the Docker engine.
# yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
# yum -y install docker-ce docker-ce-cli containerd.io
# systemctl start docker
Confirm that Docker is running with:
# docker version
API version: 1.37
Go version: go1.9.5
Git commit: 9ee9f40
Built: Thu Apr 26 07:20:16 2018
We're also going to use a tool called docker-compose to help manage the database container configuration. Note the version used in the command below may not be the latest, check the documentation if you want the most recent.
# curl -L https://github.com/docker/compose/releases/download/1.20.1/docker-compose-$(uname -s)-$(uname -m) -o /bin/docker-compose
# chmod a+x /bin/docker-compose
# docker-compose -version
docker-compose version 1.20.1, build 5d8c71b
# curl https://packages.microsoft.com/config/rhel/7/prod.repo > /etc/yum.repos.d/msprod.repo
# ACCEPT_EULA=Y yum -y -q install mssql-tools unixODBC-devel
To help make the management of the container a little easier we're going to use docker-compose. This allows us to put all of the configuration options in a file rather than having to remember them each time we want to run a container. Here's an example, copy and save this as a file called mssql2017.yml in the /docker directory:
The various options we've used are:
|image: mcr.microsoft.com/mssql/server:2017-latest||The image used to create the container.|
|container_name: mssql2017||A friendly name for the container.|
|hostname: mssql2017||Sets the hostname rather than using one that is automatically generated. This will help us when we come to install AR as this is also used to name the database.|
|Maps container ports to the outside world.|
|Creates a shared volume to allow the database files to be stored on the docker host file system rather than inside the container.|
Pass environment variables used to set up the database. Please note these requirements for the password from the Microsoft documentation :
The password should follow the SQL Server default password policy, otherwise the container can not setup SQL server and will stop working. By default, the password must be at least 8 characters long and contain characters from three of the following four sets: Uppercase letters, Lowercase letters, Base 10 digits, and Symbols.
All that is now required to start a database container is a single command:
# docker-compose -f mssql2017.yml up -d
Creating mssql2017 ... done
We can check that the container is running using the docker ps command and then query the database using the sqlcmd tool we installed earlier:
# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0ed2f8602ce9 mcr.microsoft.com/mssql/server:2017-latest "/opt/mssql/bin/sqlserver" 1 hours ago Up 8 seconds 0.0.0.0:1433->1433/tcp mssql2017
# /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P P@ssw0rd -Q "select getdate()"
(1 rows affected)
We can also see that the container has created the default database files under the /docker/mssql directory:
# tree /docker/mssql/
│ ├── master.mdf
│ ├── mastlog.ldf
│ ├── modellog.ldf
│ ├── model.mdf
│ ├── msdbdata.mdf
│ ├── msdblog.ldf
│ ├── tempdb.mdf
│ └── templog.ldf
│ ├── errorlog
│ ├── errorlog.1
│ ├── HkEngineEventFile_0_131963630182660000.xel
│ ├── log.trc
│ ├── sqlagentstartup.log
│ └── system_health_0_131963630191840000.xel
Believe it or not, that's all it takes to get a running MS-SQL Server instance on Linux!
The database container can be stopped with:
# docker-compose -f mssql2017.yml stop
Stopping mssql2017 ... done
Installing Remedy (quietly...)
One of the challenges of setting up a Remedy test system is the time taken to run all of the installers, particularly if you're also installing the ITSM Suite. There's an added complication if you're using a headless Linux server in that using the installer GUI requires a suitable X-Windows server running on a PC to display the interface. One of the under-used (I think) Remedy features is the ability for the installers to run in a silent mode, using a configuration file to provide all of the inputs that you usually type in using the GUI interface. Using this option has a number of benefits:
- no need for a GUI environment on Linux.
- can be scripted so installations may be run remotely/unattended.
- consistent and repeatable which makes it easier to recreate environments for testing.
All of the Remedy components can be installed using this silent mode and the process is covered in the relevant pages on the BMC docs website:
So how does it work? When you unpack the installer you will find an example options file, usually in a directory called utility. This is a text file template that provides details of how to run the installer in silent mode and lists all of the options, and values where appropriate, that you need to provide. The exact contents will vary depending on the product but the minimum required set of options may be a lot less than you expect.
Let's see what we would need to have in the silent options file to install an AR Server on the Linux system where we're running our MS-SQL container.
# cat silent_ar.txt
You can see we're providing the Java path, product options such as language choice and sample data, database and Demo user credentials - everything that you would usually enter via the GUI. A similar file could be used for an Oracle database but there would be some different options, which are explained in the sample file, that would need to be used. Once this file has been created we just have to include it on the command line when running the installer:
# ./setup.bin -i silent -DOPTIONS_FILE=/path/to/silent_ar.txt
The installer will run, displaying some output on the screen and creating the usual log files, and setup the server. Note that the file above does not include the mid-tier so you'll either have to add the options to install this or use a container based one created using the earlier blog post.
Once your server is up and running you can use the same process to install CMDB, AI, ITSM, SLM, SRM and so on... With a bit of practice you could set up a script to create a full ITSM system from scratch with a single command. Set it running as you leave for the the day and have it ready in the morning, perfect for testing.
There are other ways to use the MS-SQL container without installing Remedy from scratch, the next section looks at backing up and restoring the database from an existing AR Server which can then be configured to use the container based database.
Restore an Existing Remedy Database
If you don't want to wait for the silent install steps, and happen to have an existing Remedy system using MS-SQL, you could take a database backup and restore it into the container. Transfer the .Bak file from the original system and copy it to the /docker/mssql/data directory - let's assume it is called ARSystem.Bak. The sqlcmd utility is then used to perform the restore:
# /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P P@ssw0rd -Q "restore database ARSystem from disk='ARSystem.Bak' with replace, move 'ARSystem_data' to '/var/opt/mssql/data/arsys.mdf', move 'ARSystem_log' to '/var/opt/mssql/data/arsyslog.ldf'"
You may need to change the highlighted values depending on what your current system uses. Progress will be shown as the restore takes place:
Processed 189816 pages for database 'ARSystem', file 'ARSystem_data' on file 1.
Processed 184 pages for database 'ARSystem', file 'ARSystem_log' on file 1.
Converting database 'ARSystem' from version 706 to the current version 869.
Database 'ARSystem' running the upgrade step from version 706 to version 770.
Database 'ARSystem' running the upgrade step from version 867 to version 868.
Database 'ARSystem' running the upgrade step from version 868 to version 869.
RESTORE DATABASE successfully processed 190000 pages in 3.662 seconds (405.344 MB/sec).
Then we need to create an ARAdmin account and make it the owner of the newly restored database, again some changes may be necessary to reflect your local names:
# /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P P@ssw0rd -Q "create login ARAdmin with password='arsystem', default_database=ARSystem, check_policy=off"
# /opt/mssql-tools/bin/sqlcmd -S localhost -d ARSystem -U sa -P P@ssw0rd -Q "exec sp_changedbowner ARAdmin, true"
Query the database as the ARAdmin user to confirm it has been restored as expected:
# /opt/mssql-tools/bin/sqlcmd -S localhost -U ARAdmin -P arsystem -Q "select schemaid, serverid, currdbversion from control"
schemaid serverid currdbversion
----------- ----------- -------------
4088 2 58
(1 rows affected)
That's it, we've created a new MS-SQL instance in a container and restored a Remedy database that's ready to use. If you change the Db-Host-Name (and Db-user/Db-password if required) in the ar.cfg of the AR Server that was using the original database system, setting it to the name of your docker host machine, it should be able to run using the restored copy.
I've started using this type of set up for most of my test environments and find it very flexible. The ease and speed of creating a new database, along with the ability to install various combinations of Remedy products with minimal interaction, means that I no longer find it necessary to keep many different VMs lying around just in case I need a particular version. Of course there are cases where this approach is not suitable, longer term test and development systems for example, but I'd encourage you to give it a go next time you need a system for a quick test or have a new version you want to evaluate.
Questions, comments & feedback are welcome.