-
Notifications
You must be signed in to change notification settings - Fork 93
_Persistent Volume Considerations
This page has been deprecated. Please see the official Kubernetes Black Duck Installation Guide here.
Synopsys Operator can create persistent volume claims that ensure that Black Duck data persists even if Black Duck's containers are stopped and restarted.
Note: If persistent storage is not used, then Black Duck will use "emptyDir" for storage. emptyDir is not guaranteed to persist across container restarts. As such, emptyDir is fine for demonstrations, evaluations, proof-of-concepts, and ephemeral Black Duck deployments, but is not suitable for production Black Duck usage.
In order to deploy Black Duck that uses persistent volume claims, you must first allocate the underlying persistent volumes. How to provision persistent volumes is beyond the scope of this document, but a good place to start is the Kubernetes Persistent Volume documentation.
See the sections below for information about sizing and characteristics of your persistent volumes.
Generally, a Black Duck deployment will require 200 GB of persistent-space, at minimum. Substantially more could be required for larger Black Duck deployments. There are three components of Black Duck that consume persistent storage:
Each is described, below.
The vast majority of disk space is consumed by the Back Duck Postgres database container. At minimum, your database will require 150 GB of space, but for large-scale deployments (many scans per day with scans stored for long periods of time) 1000 GB or more could be required. Work with Black Duck support to determine what size is right for your deployment. See also the Database Considerations page.
Black Duck Binary Analysys (BDBA) is an optional component that allows for uploading and scanning of endpoint binaries. If you enable this optional feature, then your Black Duck deployment will need at least an additional 100 GB of space (to be clear, this is in addition to what is needed for Postgres).
Black Duck will make an additional 8-10 persistent volumes claims totaling roughly 50 GB for various storage tasks, including logging, configuration data, licensing info, authentication, and miscellaneous caching.
Once you know how much space to allocate in your persistent volumes, you have a few more decisions to make.
You can either provision a number of static persistent volumes, or, you can use a dynamic provisioner linked to a particular storage class. This storage class, once defined, will be displayed in the Synopsys Operator console UI and will be selectable when you enable Persistent Volumes.
Regardless of whether you choose static or dynamic volumes, please note that the Black Duck deployment will claim around a dozen persistent volumes for the systems listed in the previous section.
Also note that persistent volumes must be defined as "ReadWriteOnce". This ensures that data cannot be shared across pods.