Server Profile Structures
Each of the Docker images use a server profile structure that is specific to each product. The structure (directory paths and data) of the server profile differs between products. Depending on how you Deploy Your Server Profile, it will be pulled or mounted into /opt/in
on the container and used to stage your deployment.
The following locations are the server profile structures for each of our products with example usage. For help with an example of the basics, see the pingidentity-server-profiles/getting-started examples.
In the getting-started profile examples, you should not use the
|
PingFederate
See the example at getting-started/pingfederate.
Path | Location description |
---|---|
instance |
Directories and files that you want to be used at product runtime, in accordance with the directory layout of the product. |
instance/server/default/data |
An extracted configuration archive exported from PingFederate. |
instance/bulk-config/data.json |
A JSON export from the PingFed admin API |
instance/server/default/deploy/OAuthPlayground.war |
Automatically deploy the OAuthPlayground web application. |
instance/server/default/conf/META-INF/hivemodule.xml |
Apply a Hive module config to the container. Used for persisting OAuth clients, grants, and sessions to an external DB. |
By default, PingFederate is shipped with a handful of integration kits and adapters. If you need other integration kits or adapters in the deployment, manually download them and place them inside server/default/deploy of the server profile. You can find these resources in the product download page here.
|
PingAccess
Example at getting-started/pingaccess.
Path | Location description |
---|---|
instance |
Directories and files that you want to be used at product runtime, in accordance with the directory layout of the product. |
instance/conf/pa.jwk |
Used to decrypt a |
instance/data/data.json |
PA 6.1+ A config file that, if found by the container, is uploaded into the container. |
instance/data/PingAccess.mv.db |
Database binary that would be ingested at container startup if found. |
PingAccess profiles are typically minimalist because the majority of PingAccess configurations can be found within a PingAccess 6.1.x+ supports using only |
PingAccess 6.1.0+ now supports native
A |
For PingAccess 6.0.x and earlier, the JSON configuration file for must be named data.json and located in the instance/data directory.
|
For all PingAccess versions, a corresponding file named For example, if PingAccess is running in a local Docker container you can use these commands to export the curl -k -u "Administrator:${ADMIN_PASSWORD}" -H "X-Xsrf-Header: PingAccess" https://localhost:9000/pa-admin-api/v3/config/export -o ~/Downloads/data.json docker cp <container_name>:/opt/out/instance/conf/pa.jwk ~/Downloads/pa.jwk |
You can find the PingAccess administrator password in
|
Ping Data Products
The Ping Data Products (PingDirectory, PingDataSync, PingAuthorize, PingDirectoryProxy) follow the same structure for server-profiles.
Example at getting-started/pingdirectory.
Path | Location description |
---|---|
pd.profile |
Server profile matching the structure as defined by PingDirectory Server Profiles |
instance |
Directories and files that you want to be used at product runtime, in accordance with the layout of the product. In general, this should be non existing or empty. |
env-vars |
You can set environment variables used during deployment. See Variables and Scope for more info. In general, this should be non existing or empty. |
extensions |
You can provide URLs to download Server SDK extensions in a remote.list file. See Including Extensions in PingData Server Profiles for more info. |
|
Use the manage-profile generate-profile --profileRoot /tmp/pd.profile rm /tmp/pd.profile/setup-arguments.txt |
Follow the instructions provided when you run the generate-profile
to ensure that you include any additional components, such as encryption-settings
.