Creating volumes and folders for deployment on Kubernetes
The content services component containers require some persistent volumes, persistent volume claims, and folders to be created before you can deploy. The deployment process uses these volumes and folders during the deployment.
About this task
New in 20.0.2 You can choose to have the operator dynamically provision storage for you at deployment time. In that case, you do not need to create volumes and folders manually for your container environment. You can leave all storage values for your FileNet® Content Manager components with the default value in the custom resource YAML.
- If the claim does not exist, dynamic provisioning is used. The persistent volume claim names provided in the custom resource YAML are used when the claim is created.
- If the claim does exist, that claim is used when deploying.
- If static provisioning is used, the persistent volumes and persistent volume claims must be pre-created and the persistent volume claim name provided in the CR.
If you are deploying For 20.0.1 or earlier, or you want to use manual configuration for your storage, use the steps in this topic.
Although the following information describes the volumes that are generally required, you can decide to designate more or fewer persistent volumes and volume claims.
You can use a YAML file to capture details like the name and the specifications of the persistent volume that you want to create, and use the Kubectl command line tool with the file to create the persistent volume object. You use a similar approach to create the persistent volume claims. See the following example for more details: Configure a persistent volume for storage.
Directory permissions and ownership
- The NFS export root_squash option is strongly recommended for security. If you use the root_squash option, then the file directories to be used for the PVs group ownership must be set to the one specified by the anongid option given in the NFS export definition. The default anongid value is 65534.
- If the no_root_squash option is used, the PV group ownership must be set to the root group 0.
- Assign read, write, execute permissions to both the user and group owners, for example, chmod 770
- The rw,sync,no_wdelay settings are required.
- The no_subtree_check setting is recommended for performance.
<NFS Server>
in the
samples, you might need to provide the private IP of the server, depending on your
environment.accessModes: - ReadWriteMany
persistentVolumeReclaimPolicy: Retain
chmod -R g+rw
The persistent volume and persistent volume claim names that are provided in the following tables are examples.