WRC-CFS Deployment on WRCP
Introduction
CFS (Conductor File Service) provides file access and retrieval, as well as WRCP ISO customization services for WRC workflows.
This page explains how to deploy CFS within WRCP. CFS utilizes Ceph for persistent storage, and administrators can configure multiple replicas (more than one) across worker nodes to ensure high availability.
Installation Procedure
Create an override-values.yaml file as shown in the following example:
# Default values for cfs services.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
replicaCount: 1
nameOverride: "cfsapp"
fullnameOverride: "cfsapp"
global:
namespace: cfs
cfsapp:
image:
repository: xx.xx.xx.xx/conductor/conductor-file-service
tag: WRC_latest-250102_1651Z
logginglevel: "DEBUG"
FILE_SERVER_URLROOT: "http://xx.xx.xx.xx:30220"
FILE_SERVER_PATHROOT: "/cfs-data"
cfsfileserver:
image:
repository: xx.xx.xx.xx/conductor/nginxinc/nginx-unprivileged
tag: 1.25.4
volume:
accessModes: ReadWriteOnce
persistentVolume:
size: 20Gi
storageClass: cephfs
certificates:
enabled: false
Installation Command:
You have the following installation options:
If you choose to not to configure certificates, run following:
helm install -n cfs cfsapp -f cfs-override-values.yaml <cfs-charts.tgz>
If choose to configure certificates, extract the helm chart, create certificates directory under resources, follow Certifications configuration instructions, and then run following:
helm install -n cfs cfsapp . -f cfs-override-values.yaml
Uninstall Command:
To uninstall, enter:
helm uninstall cfsapp -n cfs
Upload a file:
Login to the WRCP cluster that hosts cfs and run the following commands:
kubectl exec -it <cfsapp pod> /bin/bash -n cfs -c cfsfileserver
Copy file to cfsfileserver:
kubectl cp test.yaml <cfsapp pod>:/cfs-data -n cfs -c cfsfileserver
File Access:
http://xx.xx.xx.xx:30220/
ISO customization Access:
http://xx.xx.xx.xx:30215/
Example:
Certificate Configuration (Optional)
Create a directory to hold the CFS certificates on the WRCP host that will host CFS.
- After extracting the helm chart, create the certificates directory under resources:
mkdir -p resources/certificates
Generate Certificates (if using selfSigned certs)
- Generate Certificates on CFS WRCP host:
openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt -subj "/CN=SelfSignedRootCA"
- Generate the server side of certificates. On the CFS WRCP host, enter:
openssl genrsa -out server.key 2048
openssl req -newkey rsa:2048 -nodes \
-subj "/CN=<ip address: xx.xx.xx.xx>" \
-addext "subjectAltName=IP:<ip address: xx.xx.xx.xx>" \
-keyout server.key \
-out server.csr
openssl x509 -req \
-in server.csr \
-CA ca.crt \
-CAkey ca.key \
-CAcreateserial \
-days 3650 \
-sha256 \
-out server.crt \
-extfile <(echo "subjectAltName=IP:<ip address: xx.xx.xx.xx>")
- ca.crt is used by WRC workflow
- server.key and server.crt are used by CFS
- Move the certificates to the
resources/certificates/
directory for CFS to use.
On CFS host, enter:
cp /tmp/server.crt resources/certificates/
cp /tmp/server.key resources/certificates/
- Setup the override.yaml by modifying the file_server_root to https:
FILE_SERVER_URLROOT: "https://xx.xx.xx.xx:30220"
Enable certificate in the cfs-override-values.yaml
certificates:
enabled: true
serverCert: "resources/certificates/server.crt"
serverKey: "resources/certificates/server.key"
-
On the WRC side of the configuration, enable the use of certificates for WRC related workflows:
- The input needs to specify:
cfs_use_custom_ssl_ca_bundle: true
file_server_use_custom_ssl_ca_bundle: true
- ca.crt contents needs to be copied to secret: cfs_ssl_ca_chain
- The input needs to specify:
-
Verify the certificates are working with curl command:
curl https://xx.xx.xx.xx:30220 -v --cacert ca.crt
* Trying xx.xx.xx.xx:30220...
* Connected to xx.xx.xx.xx (xx.xx.xx.xx) port 30220 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: server.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* start date: Jan 2 01:29:50 2025 GMT
* expire date: Dec 31 01:29:50 2034 GMT
* subjectAltName: host "2620:10a:a001:aa0c::70" matched cert's IP address!
* issuer: CN=2620:10a:a001:aa0c::70
* SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.74.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Mark bundle as not supporting multiuse
< HTTP OK
Server: nginx
Date: Thu Jan :42:06 GMT
Content-Type: texthtml
Transfer-Encoding: chunked
Connection: keep-alive
html>
<head><title>Index of /</title></head>
<body>
<h1>Index of /</h1><hr><pre><a href="../">../</a>
</pre><hr></body>
</html>