You can think of a Dockerised application, as an application that has just been installed and is ready to run for the "first time". After the installation has completed, the install point is "frozen" to that point in time, so that each time you use it, you continue on from where you left off.
Then if the upgrade completes normally, you can remove the snapshot (or archive it). And if you archive it along with the container image that was being used, you have a recoverable application as at the point in time the snapshot was created (which you can later reuse if you need to).
3. It separates files relating to any application into 3 specific categories:
1. Application related files - in Docker, they are the put inside the Docker image, when the image is built.
2. Application data files - this is the data that personalises the application, and often is linked to the specific application version that created the data. In general terms, this has business value, it could be your Email database data, your RDBMS database data, etc
3. Temporary data files - these are the files that your application may create as a result of running, (EG: temp files, etc) - they have no value, but are needed by the application to run. If they are lost, there is no concern.
It also enables you to move applications to different hosts and/or different paths. (In fact applications moving between hosts in a Docker cluster is very normal.)
By design containers should be considered ephemeral, IE: they can be destroyed and created many times. As long as the Application data files are connected to the same version of an Application related files when a Container is started, the application will live on until it is retired.
In Docker, your Application related files are in a Docker Image, your Application data files are on "Persistent Storage" and the Temporary data files are often created inside the container, and discarded when the container is destroyed.
So from a Spectrum Protect point of view, if we are to run a Spectrum Protect server, containerising it enables you to leverage points all three points above:
1. Regardless of whether you'll have 1 SP server or 100, you install it "once" and store it in your Docker Image library (aka a Docker Registry) and you can deploy it many times, almost instantly.
Want to spin up another Spectrum Protect server, just `docker run ...`
2. When you upgrade your Spectrum Protect server, you have easy upgrade and back-out plan, and in fact you can even "test" the upgrade before you do it live.
3. When you deploy it, your "Application data files" will be your Spectrum Protect configuration (IE: the database), and the Spectrum Protect configuration data (IE: your disk storage pools).
You can place those anywhere you like following your organisations data deployment policies, but when referenced inside the container, they are always referenced at the same point that SP has been prepared for when you have "installed it".
If you are interested in Dockerising Spectrum Protect, this might help you get [started](server).
From a client point of view, IE: protecting your business application and enabling you to recover it, by Dockerising your application, you have many your Spectrum Protect management even easier. IE: From the same three points above:
1. Application related files - IE: these are Docker Images and don't really need to be protected (daily at least). You'll have a copy of your Docker Image on your host(s) where your application is deployed and a copy in your Docker registry.
If your host ever dies, you'll setup a new host, ```docker pull``` the application, recover your data and start your application. (If anything, you could protect your "built" application by protecting the Docker Registry that it is stored in.)
2. Application data files, which represent your applications configuration and data, you do want to protect this, and in many cases you can protect this from "outside" the container.
There is no silver bullet on how to protect this data, so it will depend on the application and whether it provides an API or a "dump" capability on your approach to protecting it. In very, very simple terms, you could "pause" a Docker container, snapshot the devices (disk or file system) where the persistent storage is held and you have the equivalent of a hardware based snapshot backup.
3. Temporary data files - this can be ignored. Generally this data is "inside" the container and discarded if the container is ever "destroyed and recreated".
If you are interested in Dockerising Spectrum Protect Clients, this might help you get [started](client).
