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

Minor updates

Browse Source
This commit is contained in:
Deon George 2019-05-08 22:39:55 +10:00
parent 74f83c14ce
commit b3e8720f2a
No known key found for this signature in database
GPG Key ID: 7670E8DC27415254
2 changed files with 25 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
source/index.md
View File

@ -4,34 +4,38 @@ date: 2018-03-07 09:50:12
description: Docker and Spectrum Protect description: Docker and Spectrum Protect
--- ---
# General thoughts on Docker # General thoughts on Docker
Docker is tool that will make the lives of system admins easier. It really helps application and data management in three specific ways: Docker is tool that will make the lives of system admins easier (IMHO). It really helps application and data management in three specific ways:
1. Applications only get installed "once", but can be deployed many times. 1. Applications only get installed "once", but can be deployed many times.
You can think of a Dockerised application, as an application that has been installed and ready to run for the "first time". After the installation has completed, the install point is "frozen" to that point in time, so that when you "unfreeze" it, you continue on from where you left off. 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.
So each deployment of a Dockerised application is ready to go, as if you have just completed the installation. So each deployment of a Dockerised application is ready to go, as if you have just completed the installation.
2. It optimises the upgrade and back-out paths, and provides a quick recovery capability for any failed deployments. 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.) 2. It optimises the upgrade and back-out paths, and provides a quick recovery capability for any failed deployments.
So upgrades are really easy - you can consider an upgrade as: So upgrades are really easy - you can consider an upgrade as:
1. Stop application 1. Stop application
1. Backup the application data (and a super quick way to do that is a file system or disk snapshot) 1. Backup the application data (and a super quick way to do that is a file system or disk snapshot)
1. Deploy new version of application 1. Deploy new version of application
1. New version of application should read data, and if appropriately "update it" to enable it to work with that new version 1. The new version of application should read data, and if appropriately "update it" to enable it to work with that new version of the application
Then if the upgrade completes normally, you can remove 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. 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).
If something does go pear shaped and fails, your back-out plan is: If something does go pear shaped during an upgrade, and fails, your back-out plan is:
1. Stop new version of application 1. Stop new version of application
1. Recover the application data from the latest recovery point (or revert the snapshot) 1. Recover the application data from that recovery point (or revert the snapshot)
1. Deploy the original version of the application - it should continue on as if nothing happened (other than it being shutdown and restarted). 1. Deploy the original version of the application - it should continue on as if nothing happened (other than it being shutdown and restarted).
You should be able to do an upgrade (and backout if necessariy) in minutes.
3. It separates files relating to any application into 3 specific categories: 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. 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 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. 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.)
So, for any application, you just need to keep the Application related files (1) and the Application data files (2). So, for any application, you just need to keep the Application related files (1) and the Application data files (2).
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. 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.
@ -41,9 +45,17 @@ In Docker, your Application related files are in a Docker Image, your Applicatio
# Docker and Spectrum Protect # Docker and Spectrum Protect
## Spectrum Protect Server ## Spectrum Protect Server
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: 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.
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. 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.
I've upgraded SP servers in minutes (admittedly they are not very big servers).
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). 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". 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). If you are interested in Dockerising Spectrum Protect, this might help you get [started](server).

10
source/server/index.md
View File

@ -19,7 +19,7 @@ related:
> * Depending how your storage volumes are provisioned to running containers, you may need to increase the "default size" of a provisioned volume. > * Depending how your storage volumes are provisioned to running containers, you may need to increase the "default size" of a provisioned volume.
For example if your storage driver is `devicemapper` then the default volume size `Base Device Size` may be 10GB, which wont be enough for a SP installation. You will need to increase it to at least 15GB - details on how to do that are outside of the scope of this document. For example if your storage driver is `devicemapper` then the default volume size `Base Device Size` may be 10GB, which wont be enough for a SP installation. You will need to increase it to at least 15GB - details on how to do that are outside of the scope of this document.
> * Also make sure your host has sufficient memory to perform the build - SP requires at least 12GB of RAM to pass the installation logic. > * Also make sure your host has sufficient memory to perform the build - SP requires at least 12GB of RAM to pass the installation logic.
I actually perform the build on an iMac with 16GB of memory allocated to Docker. It is also using the `overlay` storage driver, which means the size of the volume the build container gets is the available free capacity of my /Users mount point. I actually perform the build on an iMac with 16GB of memory allocated to Docker. It is also using the `overlay` storage driver, which means the size of the volume the build container gets is the available free capacity of my `/Users` mount point.
> * The accompanying files for this build are available in my [gitlab](http://dev.leenooks.net/deon/spdocker/tree/master) > * The accompanying files for this build are available in my [gitlab](http://dev.leenooks.net/deon/spdocker/tree/master)
> * And lastly, most importantly, running SP in a container is **not officially supported by IBM** - so you cannot make a help-desk call about having problems. > * And lastly, most importantly, running SP in a container is **not officially supported by IBM** - so you cannot make a help-desk call about having problems.
Technically it should work without problems, but if you are experiencing a problem, be prepared to recreate your environment on a physical host and validate that your problem still exists (and thus not a result of Docker or the implementation on Docker). Technically it should work without problems, but if you are experiencing a problem, be prepared to recreate your environment on a physical host and validate that your problem still exists (and thus not a result of Docker or the implementation on Docker).
@ -57,12 +57,12 @@ COPY install.xml install-fp.xml /tmp/
<small> <small>
> **NOTES** > **NOTES**
> * We only include the silent install configuration files here - not the installation media, otherwise the size of the resulting Docker image is too big. Current versions of `docker build` do provide the ability to "flatten" the resulting container, but those instructions are outside the scope of this tutorial. > * We only include the silent install configuration files here - not the installation media, otherwise the size of the resulting Docker image is too big. Current versions of `docker build` do provide the ability to "flatten" the resulting container, but those instructions are outside the scope of this tutorial.
> * The `install.xml` file performs an installation of the server, with the license libraries/files. > * The `install.xml` file performs an installation of the server, with the license libraries/files. You need this when you install a licensed version of Spectrum Protect.
> * The `install-fp.xml` file performs an installation of the server WITHOUT the license libraries/files. Since fixpacks (from fixpack central) dont includes the license files, we need to use this file during install of fixpacks. > * The `install-fp.xml` file performs an installation of the server WITHOUT the license libraries/files. Since fixpacks (from fixpack central) dont includes the license files, we need to use this file during the install of fixpacks.
> * TIP: If you download the server package from the http site (which doesnt include the license libraries/files, you can use this `install-fp.xml` file during the install to create a 90 day trial! > * TIP: If you download the server package from the IBM http site (which doesnt include the license libraries/files), you can use this `install-fp.xml` file during the install to create a 90 day trial!
</small> </small>
Next, is performing a silent installation of SP. ** TO UPDATE ** Next, is performing a silent installation of SP.
```Dockerfile ```Dockerfile
RUN SOURCE_URL=http://YOUR_SITE_URL_HERE && \ RUN SOURCE_URL=http://YOUR_SITE_URL_HERE && \