deon/spdocker
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fixed typo

Browse Source
This commit is contained in:
Deon George 2018-03-08 10:49:30 +11:00
parent 5b5090d154
commit 5343c1abca
No known key found for this signature in database
GPG Key ID: 7670E8DC27415254
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
source/index.md
View File

@ -41,7 +41,7 @@ In Docker, your Application related files are in a Docker Image, your Applicatio
# Docker and Spectrum Protect
## Spectrum Protect Server
So from a Spectrum Protect point of view, if we are to run a Spectrum Protect server, containerizing it enables you to leverage points all three points above:
1. Regardless of whether you'll have 1 SP server or 100, you deploy it "once" and store it in your Docker Image library (aka a Docker Registry) and you can deploy it many times almost instantly.
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.
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".