Layering Server Profiles
|
The With few exceptions, many |
One of the benefits of our Docker images is the ability to layer product configuration. By using small, discrete portions of your configuration, you can build and assemble a server profile based on multiple installations of a product.
A typical organization can have multiple installations of our products, each using different configurations. By layering the server profiles, you can reuse the configurations that are common across environments, leading to fewer configurations to manage.
You can have as many layers as needed. Each layer of the configuration is copied on top of the container’s filesystem (not merged).
|
The profile layers are applied starting at the top layer and ending at the base layer. This ordering might not be apparent at first. |
Before you begin
You must:
-
Complete Get Started to set up your DevOps environment and run a test deployment of the products.
About this task
You will:
-
Create a layered server profile.
-
Assign the environment variables for the deployment.
-
Deploy the layered server profile.
Creating a layered server profile
For this guide, PingFederate is used along with the server profile located in the pingidentity-server-profiles repository. You should fork this repository to your Github repository, then pull your Github repository to a local directory. After you have finished creating the layered profile, you can push your updates to your Github repository and reference it as an environment variable to run the deployment.
You will create separate layers for:
-
Product license
-
Extensions (such as, Integration Kits and Connectors)
For this example, these layers will be applied on top of the PingFederate server profile. However, you can span configurations across multiple repositories if you want.
You can find the complete working, layered server profile of the PingFederate example from this guide in the pingidentity-server-profiles/layered-profiles directory.
Because PingFederate’s configuration is file-based, the layering works by copying configurations on top of the PingFederate container’s file system.
|
Files are copied, not merged. It’s best practice to only layer items that won’t be impacted by other configuration files. |
Creating the base directories
Create a working directory named layered_profiles and within that directory create license and extensions directories. When completed, your directory structure should be:
└── layered_profiles
├── extensions
└── license
Constructing the license layer
-
Go to the
licensedirectory and create apingfederatesubdirectory. -
Create the PingFederate license file directory path under the
pingfederatedirectory.The PingFederate license file resides in the
/instance/server/default/conf/path.mkdir -p instance/server/default/conf/Your license profile path should look like this:
└── license └── pingfederate └── instance └── server └── default └── conf └── pingfederate.lic -
Copy your
pingfederate.licfile tolicense/pingfederate/instance/server/default/conf.Using the DevOps evaluation license, when the PingFederate container is running, you can find the license in the container file system
/opt/out/instance/server/default/confdirectory.You can copy the
pingfederate.licfile from the Docker file system using the syntax:docker cp <container> <source-location> <target-location>For example:
docker cp \ pingfederate \ /opt/in/instance/server/default/conf/pingfederate.lic \ ${HOME}/projects/devops/layered_profiles/license/pingfederate/instance/server/default/confUsing the
pingctltool (update product and version accordingly):sh pingctl license pingfederate 11.1 > \ ${HOME}/projects/devops/layered_profiles/license/pingfederate/instance/server/default/conf
Building the extensions layer
-
Go to the
layered-profiles/extensionsdirectory and create apingfederatesubdirectory. -
Create the PingFederate extensions directory path under the
pingfederatedirectory.The PingFederate extensions reside in the
/instance/server/default/deploydirectory path.mkdir -p instance/server/default/deploy -
Copy the extensions you want to be available to PingFederate to the
layered-profiles/extensions/pingfederate/instance/server/default/deploydirectory .The extensions profile path should look similar to the following (extensions will vary based on your requirements):
└── extensions └── pingfederate └── instance └── server └── default └── deploy ├── pf-aws-quickconnection-2.0.jar ├── pf-azure-ad-pcv-1.2.jar └── pf-slack-quickconnection-3.0.jar
Assigning environment variables
Although this deployment assigns the environment variables for use in a Docker Compose YAML file, you can use the following technique with any Docker or Kubernetes deployment.
If you want to use your own Github repository for the deployment in the following examples, replace:
SERVER_PROFILE_URL=https://github.com/pingidentity/pingidentity-server-profiles.git
with:
SERVER_PROFILE_URL=https://github.com/<your-username>/pingidentity-server-profiles.git
!!! note "Private Github Repo" If your GitHub server-profile repo is private, use the username:token format so the container can access the repository.
For example, https://github.com/<your_username>:<your_access_token>/pingidentity-server-profiles.git. For more information, see Using Private Github Repositories.
-
Create a new
docker-compose.yamlfile. -
Add your license profile to the YAML file.
For example:
- SERVER_PROFILE_URL=https://github.com/pingidentity/pingidentity-server-profiles.git - SERVER_PROFILE_PATH=layered-profiles/license/pingfederateSERVER_PROFILEsupportsURL,PATH,BRANCHandPARENTvariables. -
Using
SERVER_PROFILE_PARENT, instruct the container to retrieve its parent configuration by specifying theextensionsprofile as the parent:- SERVER_PROFILE_PARENT=EXTENSIONSSERVER_PROFILEcan be extended to reference additional profiles. Because we specified the license profile’s parent asEXTENSIONS, we can extendSERVER_PROFILEby referencing theEXTENSIONSprofile (prior to theURLandPATHvariables):- SERVER_PROFILE_EXTENSIONS_URL=https://github.com/pingidentity/pingidentity-server-profiles.git - SERVER_PROFILE_EXTENSIONS_PATH=layered-profiles/extensions/pingfederate -
Set
GETTING_STARTEDas theEXTENSIONSparent and declare theURLandPATH:- SERVER_PROFILE_EXTENSIONS_PARENT=GETTING_STARTED - SERVER_PROFILE_GETTING_STARTED_URL=https://github.com/pingidentity/pingidentity-server-profiles.git - SERVER_PROFILE_GETTING_STARTED_PATH=getting-started/pingfederateBecause the
GETTING_STARTEDprofile is the last profile to add, it will not have a parent.Your
environmentsection of thedocker-compose.yamlfile should look similar to this:environment:# **** SERVER PROFILES BEGIN **** # Server Profile - Product License - SERVER_PROFILE_URL=https://github.com/pingidentity/pingidentity-server-profiles.git - SERVER_PROFILE_PATH=layered-profiles/license/pingfederate - SERVER_PROFILE_PARENT=EXTENSIONS # Server Profile - Extensions - SERVER_PROFILE_EXTENSIONS_URL=https://github.com/pingidentity/pingidentity-server-profiles.git - SERVER_PROFILE_EXTENSIONS_PATH=layered-profiles/extensions/pingfederate - SERVER_PROFILE_EXTENSIONS_PARENT=GETTING_STARTED # Base Server Profile - SERVER_PROFILE_GETTING_STARTED_URL=https://github.com/pingidentity/pingidentity-server-profiles.git - SERVER_PROFILE_GETTING_STARTED_PATH=getting-started/pingfederate # **** SERVER PROFILE END ****
Deploying the layered profile
-
Push your profiles and updated
docker-compose.yamlfile to your GitHub repository. -
Deploy the stack with the layered profiles.
To view this example in its entirety, including the profile layers and docker-compose.yaml file, see the pingidentity-server-profiles/layered-profiles directory.