Deploying Black Duck in Azure Kubernetes Service

The recommended approach to deploying Black Duck on Azure Kubernetes Service (AKS) is to use an external database (Azure Database for PostgreSQL) and Azure File for persistent volumes within the Kubernetes cluster for the following reasons:

PostgreSQL as a container cannot run on Azure File storage because Azure File does not support symbolic links.
Azure Disk storage would allow the PostgreSQL container but is tied to the node in the AKS cluster, so if a pod moves to another node it cannot access the data volume and the database will fail. When a node is lost all data is lost.
Azure File storage (which is available to the cluster and not the node) is recommended but prevents the use of the internal PostgreSQL container database, so you must use an external database.
Synopsys recommends using an external database for production Kubernetes deployments.

The following instructions describe deploying Black Duck using native Synopsysctl commands on AKS using an external database (Azure Database for PostgreSQL).

This document assumes you have followed these steps as a prerequesite.
1. Created an Azure Resource Group for your Kuberenetes Service and Azure Database for PostgreSQL.
2. Created the Azure Kubernetes Service cluster.
3. Connected kubectl to your Azure Kubernetes Cluster ('az aks install-cli' and 'az aks get-credentials')
4. Created the Azure Database for PostgreSQL instance. Ensure it is in the same region as your Kubernetes Service and is version 11 (for Black Duck 2020.6.0 or later).
5. Configured Dynamic persistent volumes for Azure File. https://docs.microsoft.com/en-us/azure/aks/azure-files-dynamic-pv
Initialise the external database ready. To do so you will need to be able to connect to your Azure database via psql in the console. This requires you to:
- Have psql installed
- Not be on a VPN network as port 5432 is blocked.
- Have configured your IP address in Connection Security of the Azure Database for PostgreSQL.
Connect to your database via psql (in Azure console you can get the connection string under the Connection strings page under the database:
psql "host=synopsys-blackduck-db.postgres.database.azure.com port=5432 dbname=postgres user=blackduck@synopsys-blackduck-db password={your password here} sslmode=require"
4. When you connect, run the following SQL statements one at a time so that we modify template1 to change the database encoding to SQL_ASCII:
ALTER DATABASE template1 is_template false; DROP DATABASE template1; CREATE DATABASE template1 WITH template=template0 LC_COLLATE 'C' LC_CTYPE 'C' encoding 'SQL_ASCII'; ALTER DATABASE template1 is_template true;
5. Exit (\quit) out of psql.
6. Create a file called initdb.psql with the following contents and modify the XXXXX for your password choices.
Note this has an additional line to usual versions of this file 'GRANT blackduck_user to blackduck;' and also uses template1:
CREATE DATABASE bds_hub owner blackduck TEMPLATE template1 ENCODING SQL_ASCII lc_collate='C' lc_ctype='C'; CREATE DATABASE bds_hub_report owner blackduck TEMPLATE template1 ENCODING SQL_ASCII lc_collate='C' lc_ctype='C'; CREATE USER blackduck_user WITH NOCREATEDB NOSUPERUSER NOREPLICATION NOBYPASSRLS; CREATE USER blackduck_reporter; ALTER USER blackduck_user WITH password 'XXXXX'; GRANT blackduck_user to blackduck; \c bds_hub CREATE EXTENSION pgcrypto; CREATE SCHEMA st AUTHORIZATION blackduck; GRANT USAGE ON SCHEMA st TO blackduck_user; GRANT SELECT, INSERT, UPDATE, TRUNCATE, DELETE, REFERENCES ON ALL TABLES IN SCHEMA st TO blackduck_user; GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA st to blackduck_user; ALTER DEFAULT PRIVILEGES IN SCHEMA st GRANT SELECT, INSERT, UPDATE, TRUNCATE, DELETE, REFERENCES ON TABLES TO blackduck_user; ALTER DEFAULT PRIVILEGES IN SCHEMA st GRANT ALL PRIVILEGES ON SEQUENCES TO blackduck_user; ALTER DATABASE bds_hub SET standard_conforming_strings TO OFF; \c bds_hub_report GRANT SELECT ON ALL TABLES IN SCHEMA public TO blackduck_reporter; ALTER DEFAULT PRIVILEGES FOR ROLE blackduck IN SCHEMA public GRANT SELECT ON TABLES TO blackduck_reporter; GRANT SELECT, INSERT, UPDATE, TRUNCATE, DELETE, REFERENCES ON ALL TABLES IN SCHEMA public TO blackduck_user; GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public to blackduck_user; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, TRUNCATE, DELETE, REFERENCES ON TABLES TO blackduck_user; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL PRIVILEGES ON SEQUENCES TO blackduck_user; ALTER DATABASE bds_hub_report SET standard_conforming_strings TO OFF;
7. Execute the following file against the database:

8. Download and install synopsysctl (see https://synopsys.atlassian.net/wiki/spaces/BDLM/pages/173506572 .
- On Windows download the zip and extract synopsysctl.exe to a folder of choice, open a command prompt and cd to that folder.
- The folloiwing example commands install 1.1.0 on Linux:

10. Deploy Black Duck using synopsysctl:

a. Create the namespace

b. Create the deployment yaml file for Black Duck and replace:

Name and namespace with your choice.
Database Passwords (XXXXX).
Seal-key of your choice - this is a 32 character key that you should keep in a safe place.
Version of Black Duck (2020.8.0 in this example).
Size of Black Duck (small in this example).
Database host and connection user (note the connection user is defined in different ways, the environs should refer to the full Azure database user with the hostname included).
Note this uses Azure File and assumes you have configured dynamic persistent volumes for azurefile. We recommend Azure File as it is storage available to all nodes in the cluster.

c. Deploy the Black Duck yaml file

11. Notice that your persistent volumes are bound, pods all start and the external IP is provisioned:

12. Black Duck should now be available at the external IP listed in the kubectl get svc output.