Note: Development and Testing purposes only. Not supported in production environments.
Link to other containerization articles
In this blog post, we will be exploring how to overcome the limitations that were previously mentioned in the blog post Spin up PI Data Archive container. Container technology can contribute to the manageability of a PI System (installations/migrations/maintenance/troubleshooting that used to take weeks can potentially be reduced to minutes) so I would like to try and overcome as many limitations as I can so that they will become production ready. Let us have a look at the limitations that were previously mentioned.
1. This example does not persist data or configuration between runs of the container image.
2. This example relies on PI Data Archive trusts and local accounts for authentication.
3. This example doesn't support VSS backups.
Let us go through them one at a time.
Data and Configuration Persistence
This limitation can be solved by separating the data from the application container. In Docker, we can make use of something called Volumes which are completely managed by Docker. When we persist data in volumes, the data will exist beyond the life cycle of the container. Therefore, even if we destroy the container, the data will still remain. We create external data volumes by including the VOLUME directive in the Dockerfile like such
VOLUME ["C:/Program Files/PI/arc","C:/Program Files/PI/dat","C:/Program Files/PI/log"]
When we instantiate the container, Docker will now know that it has to create the external data volumes to store the data and configuration that exists in the PI Data Archive arc, dat and log directories.
This issue can be addressed with the use of GMSA and a little voodoo magic. This enables the container host to obtain the TGT for the container so that the container is able to perform Kerberos authentication and it will be connected to the domain. The container host will need to be domain joined for this to happen.
When data is persisted externally, we can leverage on the VSS provider in the container host to perform the VSS snapshot for us so that we do not have to stop the container while performing the backup. This way, the container will be able to run 24/7 without any downtime (as required by production environments). The PI Data Archive has mechanisms to put the archive in a consistent state and freeze it to prepare for snapshot.
1. Grab the files in the 2017R2 folder from my Github repo and place them into a folder. elee3/PI-Data-Archive-container-build
2. Get PI Data Archive 2017 R2A Install Kit and extract it into the folder as well. Download from techsupport website
3. Procure a PI License that doesn't require a MSF such as the demo license on the techsupport website and place it in the Enterprise_X64 folder.
4. Your folder structure should look similar to this now.
5. Execute buildx.bat. This will build the image.
6. Once the build is complete, you can navigate to the Kerberos folder and run the powershell script (check 3 Aug 2018 updates) to create a Kerberos enabled container
.\New-KerberosPIDA.ps1 -AccountName <GMSA name> -ContainerName <container name>
You can request for a GMSA from your IT department and get it installed on your container host with the Install-ADServiceAccount cmdlet.
If you think it will be difficult for you to get a GMSA from your IT department, then you can use the following command as well to create a non Kerberos enabled container
docker run -id -h <DNS hostname> --name <container name> pidax:17R2
7. Go to the pantry to make some tea or coffee. After about 1.5 minutes, your container will be ready.
Demo of container abilities
This section only applies if you created a Kerberos enabled container. After creating a mapping for my domain account using PI System Management Tools (SMT) (the container automatically creates an initial trust for the container host so that you can create the mapping), let me now try to connect to the PI Data Archive container using PI System Explorer (PSE). After successful connection, let me go view the message logs of the PI Data Archive container.
We can see that we have Kerberos authentication from AFExplorer.exe a.k.a PSE.
2. Persist Data and Configuration
When I kill off the container, I noticed that I am still able to see the configuration and data volumes persisted on my container host so I don't have to worry that my data and configuration is lost.
3. VSS Backups
Finally, what if I do not want to stop my container but I want to take a back up of my config and data? For that, we can make use of the VSS provider on the container host. Obtain the 3 files here. elee3/PI-Data-Archive-container-build
Place them anywhere on your container host. Execute
.\backup.ps1 -ContainerName <container name>
The output of the command will look like this.
Your backup will be found in the pibackup folder that is automatically created and will look like this. pi17 is the name of my container.
Your container is still running all the time.
4. Restore a backup to a container
Now that we have a backup, let me show you how to restore it to a new container. It is a very simple 3 step process.
- docker stop the new container
- Copy the backup files into the persisted volume. (You can find the volumes at C:\ProgramData\docker\volumes)
- docker start the container
As you can see, it can't get any simpler . When I go to browse my new container, I can see the values that I entered in my old container which had its backup taken.
In this blog post, we addressed the limitations of the original PI Data Archive container to make it more production ready. Do we still have any need of the original PI Data Archive container then? My answer is yes. If you do not need the capabilities offered by this enhanced container, then you can use the original one. Why? Simply because the original one starts up in 15 seconds while this one starts up in 1.5 minutes! The 1.5 minutes is due to limitations in Windows Containers. So if you need to spin up PI Data Archive containers quickly without having to worry about these limitations (e.g. in unit testing), then the original container is for you.
New updates (3 Aug 2018)
Script updated to allow GMSA to work in both child and parent domains. For example, mycompany.com and test.mycompany.com.
Refer to Upgrade to PI Data Archive 2018 container with Data Persistence to build the pidax:18 image needed for use with the script.