I wanted my own custom image in our internal Redgate Clone cluster, so I decided to make one. This is an overview of how this works.
This is a series of posts on Redgate Clone, which is a way of quickly and easily creating ephemeral developer images of databases.
Overview
Usually a custom image comes from production, which is masked and subsetted, then available for devs. However, if you are working in greenfield development or want to experiment, you want to start somewhere. I decided to start with an empty instance and customize it.
The process I followed is this:
- create a blank container (create)
- make changes to the container
- save the changes (save)
- create an image from the container (graduate)
I’ve added the RGClone commands in parenthesis after each of these steps.
Creating a New Container
We have an internal Redgate Clone cluster that many of our developers and teams use for spinning up database environments. I connected to this and created a data container using this command.
rgclone create data-container –image empty-sql-current
This is a blank image we have that contains SQL Server 2019 on it (current was a poor choice for naming) and no databases installed. As you can see below, this created the container and then returned the endpoint in a connection string, including credentials.
When I then listed out the containers running, I could see mine below. It’s the last one, where the container name is the image with a random set of characters appended.
Once this was done, I decided to connect to this instance and then customize things. This container is just a plain SQL Server instance, and appears like that on the network, so I connected to it in SSMS.
Customizing things
Once I connected, I could see this was a standard SQL Server instance, just as if I’d installed SQL Server on a VM.
I had a script to create a database, so I ran that and created a new database and added some data. When I was satisfied with my changes, I decided to save this as a new image.
Graduating the Image
I don’t know why graduate was chosen as the verb, but it was. This means we’ll take an existing container and use it as the source for a brand new image. To do this, we follow a two step process: we save the container state and then create a new image.
The first step is saving, and we use the save verb with the container who’s state we are saving. This creates a revision of this particular moment in time of what the container looks like. I didn’t include a version, since I was learning. The default is rev.x, where x is the next numeric version.
Here’s the command and output.
rgclone save data-container empty-sql-current-wyzpthav
Now that I have a saved state, let’s use that to create a new image. I used the graduate verb here, but this didn’t work. There is an error that ran off to the side, which noted there was no revision number 1. That’s because the docs didn’t quite explain this, and I wasn’t sure.
The better command is:
rgclone graduate data-container empty-sql-curent-wyzpthav –revision rev.1 –name sql-2019-cu22-Northwind
where we give the contained and the actual revision used (or returned from the save command. In this case, rev.1 is the revision. I also gave this a better name, which reflects the actual version of SQL Server.
Once this was done, I could see my sql-2019-cu22-Northwind image in the list of data images. I could easily create a new container instance from this, which would be my starting point for more development work.
Summary
This is a basic look at how to use Redgate Clone to create custom images based on your work. Ideally, a bunch of this work would be automated, so we could get updated images of the current state of our development systems as we evolve and change our schema and data.
There are ways to automate things, often starting with a backup, but if you have developers that might want or need to customize a container and want to deploy that to others, this is a way to do that.
Redgate Clone is a part of our Test Data Manager solution, which includes the ability to also mask and subset your data.