From b3e8720f2ad7b8f36d27062ab10a3a78996cec1b Mon Sep 17 00:00:00 2001 From: Deon George Date: Wed, 8 May 2019 22:39:55 +1000 Subject: [PATCH] Minor updates --- source/index.md | 28 ++++++++++++++++++++-------- source/server/index.md | 10 +++++----- 2 files changed, 25 insertions(+), 13 deletions(-) diff --git a/source/index.md b/source/index.md index 8fb7166..af1728e 100644 --- a/source/index.md +++ b/source/index.md @@ -4,34 +4,38 @@ date: 2018-03-07 09:50:12 description: Docker and Spectrum Protect --- # 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. - 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. -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: 1. Stop application 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. 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. 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). + 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: 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.) + 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. @@ -41,9 +45,17 @@ 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, 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. + + 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). + 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). diff --git a/source/server/index.md b/source/server/index.md index cb5621b..f44ae30 100644 --- a/source/server/index.md +++ b/source/server/index.md @@ -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. 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. - 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) > * 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). @@ -57,12 +57,12 @@ COPY install.xml install-fp.xml /tmp/ > **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. -> * The `install.xml` file performs an installation of the server, with the license libraries/files. -> * 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. -> * 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! +> * 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 the install of fixpacks. +> * 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! -Next, is performing a silent installation of SP. ** TO UPDATE ** +Next, is performing a silent installation of SP. ```Dockerfile RUN SOURCE_URL=http://YOUR_SITE_URL_HERE && \