README
¶
tang-operator
Contents
Introduction
This operator is a Proof of Concept of a tang operator, and how it is deployed in top of OpenShift.
Up to date, it can be deployed as a CRD, containing its proper configuration values to perform appropriate tang server operations.
An introductory video can be seen in next link:
NBDE in Openshift: tang-operator basics
Versions
Versions released up to date of the tang operator and the tang operator-bundle are:
- v0.0.1: Hello world version.
- v0.0.2: Basic version with no fields still updated.
- v0.0.3: First release correct version.
- v0.0.4: Version that fixes issues with deployments/pods/services permissions.
- v0.0.5: Version that publishes the service and exposes it on configurable port.
- v0.0.6: Types refactoring. Initial ginkgo based test.
- v0.0.7: Include finalizers to make deletion quicker.
- v0.0.8: Tang operator metadata homogeneization.
- v0.0.9: Tang operator shared storage.
- v0.0.10: Code Refactoring I.
- v0.0.11: Extend tests.
- v0.0.12: Fix default keypath.
- v0.0.13: Add type for Persistent Volume Claim attach.
- v0.0.14: Fix issue on non 8080 service port deployment.
- v0.0.15: Add resource request/limits.
- v0.0.16: Fix scale up issues.
- v0.0.17: Key rotation/deletion management via spec file.
- v0.0.18: Advertise only signing keys.
- v0.0.19: Add Events writing with important information.
- v0.0.20: Use tangd-healthcheck only for liveness.
- v0.0.21: Use tangd-healthcheck for liveness and readiness, separating intervals.
- v0.0.22: Remove personal accounts and use organization ones.
- v0.0.23: Selective hidden keys deletion.
- v0.0.24: Execute tang container pod as non root user.
- v0.0.25: Allow key handling without cluster role configuration.
Installation
In order to install tang operator, you must have previously installed an Open Shift cluster. For small computers, CRC (Code Ready Containers) project is recommended. In case normal OpenShift cluster is used, tang operator installation should not differ from the CRC one.
Instructions for CRC installation can be observed in the Links section. Apart from cluster, the corresponding client is required to check the status of the different Pods, Deployments and Services. Required OpenShift client to install is oc, whose installation can be checked in the Links section.
Once K8S/Openshift cluster is installed, tang operator can be installed with operator-sdk. operator-sdk installation is described in the Links section.
In order to deploy the latest version of the tang operator, check latest released version in the Versions section, and install the appropriate version bundle. For example, in case latest version is 0.0.25, the command to execute will be:
$ operator-sdk run bundle quay.io/sec-eng-special/tang-operator-bundle:v0.0.25
INFO[0008] Successfully created registry pod: quay-io-sec-eng-special-tang-operator-bundle-v0-0-25
INFO[0009] Created CatalogSource: tang-operator-catalog
INFO[0009] OperatorGroup "operator-sdk-og" created
INFO[0009] Created Subscription: tang-operator-v0-0-25-sub
INFO[0011] Approved InstallPlan install-lqf9f for the Subscription: tang-operator-v0-0-25-sub
INFO[0011] Waiting for ClusterServiceVersion to reach 'Succeeded' phase
INFO[0012] Waiting for ClusterServiceVersion "default/tang-operator.v0.0.25"
INFO[0018] Found ClusterServiceVersion "default/tang-operator.v0.0.25" phase: Pending
INFO[0020] Found ClusterServiceVersion "default/tang-operator.v0.0.25" phase: InstallReady
INFO[0021] Found ClusterServiceVersion "default/tang-operator.v0.0.25" phase: Installing
INFO[0031] Found ClusterServiceVersion "default/tang-operator.v0.0.25" phase: Succeeded
INFO[0031] OLM has successfully installed "tang-operator.v0.0.25"
If the message OLM has successfully installed is displayed, it is normally a sign of a proper installation of the tang operator.
If a message similar to "failed open: failed to do request: context deadline exceeded", it is possible that a timeout is taking place. Try to increase the timeout in case your cluster takes long time to deploy. To do so, the option --timeout can be used (if not used, default time is 2m, which stands for two minutes):
$ operator-sdk run bundle --timeout 3m quay.io/sec-eng-special/tang-operator-bundle:v0.0.25
INFO[0008] Successfully created registry pod: quay-io-sec-eng-special-tang-operator-bundle-v0.0.25
...
INFO[0031] OLM has successfully installed "tang-operator.v0.0.25"
Additionally, correct tang operator installation can be observed if an output like the following is observed when prompting for installed pods:
$ oc get pods
NAME READY STATUS RESTARTS AGE
dbbd1837106ec169542546e7ad251b95d27c3542eb0409c1e 0/1 Completed 0 82s
quay-io-tang-operator-bundle-v0.0.25 1/1 Running 0 90s
tang-operator-controller-manager-5c9488d8dd-mgmsf 2/2 Running 0 52s
Note the Completed and Running state for the different tang operator pods.
Once operator is correctly installed, appropriate configuration can be applied from config directory. Minimal installation, that just provides the number of replicas (1) to use, is the recommended tang operator configuration to apply:
$ oc apply -f config/minimal
namespace/nbde created
tangserver.daemons.redhat.com/tangserver created
In case tang operator is appropriately executed, ndbe namespace should contain the service, deployment and pod associated to the tang operator:
$ oc -n nbde get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service-tangserver LoadBalancer 172.30.167.129 34.133.181.172 8080:30831/TCP 58s
$ oc -n nbde get deployments
NAME READY UP-TO-DATE AVAILABLE AGE
tsdp-tangserver 1/1 1 1 63s
$ oc -n nbde get pods
NAME READY STATUS RESTARTS AGE
tsdp-tangserver-55f747757c-599j5 1/1 Running 0 40s
Note the Running state for the tangserver pods.
Compilation
Compilation of tang operator can be released in top directory, by executing make docker-build. The name of the image must be provided. In case there is no requirement to update the version, same version compared to the last version can be used. Otherwise, if new version of the tang operator is going to be released, it is recommended to increase version appropriately.
In this case, same version is used. Last released version can be observed in Versions section.
To summarize, taking into account that the last released version is v0.0.25 compilation can be done with next command:
$ make docker-build docker-push IMG="quay.io/sec-eng-special/tang-operator:v0.0.25"
...
Successfully built 4a88ba8e6426
Successfully tagged sec-eng-special/tang-operator:v0.0.25
docker push sec-eng-special/tang-operator:v0.0.25
The push refers to repository [quay.io/sec-eng-special/tang-operator]
79109912085a: Pushed
417cb9b79ade: Layer already exists
v0.0.25: digest: sha256:c97bed08ab71556542602b008888bdf23ce4afd86228a07 size: 739
In case a new release is planned to be done, the steps to follow will be:
- Modify Makefile so that it contains the new version:
$ git diff Makefile
diff --git a/Makefile b/Makefile
index 9a41c6a..db12a82 100644
--- a/Makefile
+++ b/Makefile
@@ -3,7 +3,7 @@
# To re-generate a bundle for another specific version without changing the
# standard setup, you can:
# - use the VERSION as arg of the bundle target (e.g make bundle VERSION=0.0.25)
# - use environment variables to overwrite this value (e.g export VERSION=0.0.25)
-VERSION ?= 0.0.24
+VERSION ?= 0.0.25
Apart from previous changes, it is recommended to generate a "latest" tag for tang-operator bundle:
$ docker tag quay.io/sec-eng-special/tang-operator-bundle:v0.0.25 quay.io/sec-eng-special/tang-operator-bundle:latest
$ docker push quay.io/sec-eng-special/tang-operator-bundle:latest
- Compile operator:
Compile tang operator code, specifying new version, by using make docker-build command:
$ make docker-build docker-push IMG="quay.io/sec-eng-special/tang-operator:v0.0.25"
...
Successfully tagged sec-eng-special/tang-operator:v0.0.25
docker push sec-eng-special/tang-operator:v0.0.25
The push refers to repository [quay.io/sec-eng-special/tang-operator]
9ff8a4099c67: Pushed
417cb9b79ade: Layer already exists
v0.0.25: digest: sha256:01620ab19faae54fb382a2ff285f589cf0bde6e168f14f07 size: 739
- Bundle push:
In case the operator bundle is required to be pushed, generate the bundle with make bundle, specifying appropriate image, and push it with make bundle-build bundle-push:
$ make bundle IMG="quay.io/sec-eng-special/tang-operator:v0.0.25"
$ make bundle-build bundle-push BUNDLE_IMG="quay.io/sec-eng-special/tang-operator-bundle:v0.0.25"
...
docker push sec-eng-special/tang-operator-bundle:v0.0.25
The push refers to repository [quay.io/sec-eng-special/tang-operator-bundle]
02e3768cfc56: Pushed
df0c8060d328: Pushed
84774958bcf4: Pushed
v0.0.25: digest: sha256:925c2f844f941db2b53ce45cba9db7ee0be613321da8f0f05d size: 939
make[1]: Leaving directory '/home/user/RedHat/TASKS/TANG_OPERATOR/tang-operator'
IMPORTANT NOTE: After bundle generation, next change will appear on the bundle directory:
--- a/bundle/manifests/tang-operator.clusterserviceversion.yaml
+++ b/bundle/manifests/tang-operator.clusterserviceversion.yaml
@@ -36,17 +36,6 @@ spec:
displayName: Tang Server
kind: TangServer
name: tangservers.daemons.redhat.com
- resources:
- - kind: Deployment
- version: v1
- - kind: ReplicaSet
- version: v1
- - kind: Pod
- version: v1
- - kind: Secret
- version: v1
- - kind: Service
- version: v1
DO NOT COMMIT PREVIOUS CHANGE, as this metadata information is required by scorecard tests to pass successfully
- Commit changes:
Remember to modify README.md to include the new release version, and commit changes performed in the operator, together with README.md and Makefile changes
Cleanup
For operator removal, execution of option cleanup from sdk-operator is the recommended way:
$ operator-sdk cleanup tang-operator
INFO[0001] subscription "tang-operator-v0.0.25-sub" deleted
INFO[0001] customresourcedefinition "tangservers.daemons.redhat.com" deleted
INFO[0002] clusterserviceversion "tang-operator.v0.0.25" deleted
INFO[0002] catalogsource "tang-operator-catalog" deleted
INFO[0002] operatorgroup "operator-sdk-og" deleted
INFO[0002] Operator "tang-operator" uninstalled
Tests
Execution of operator tests is pretty simple. A k8s infrastructure (minikube/minishift) must be running to execute tang operator tests based on reconciliation. Execute make test from top directory and available tests will be executed:
$ make test
...
go fmt ./...
go vet ./...
...
setting up env vars
? github.com/latchset/tang-operator [no test files]
? github.com/latchset/tang-operator/api/v1alpha1 [no test files]
ok github.com/latchset/tang-operator/controllers 6.541s coverage: 24.8% of statements
In order to execute tests that require having a cluster up and running, CLUSTER_TANG_OPERATOR_TEST environment variable must be set:
$ CLUSTER_TANG_OPERATOR_TEST=1 make test
...
go fmt ./...
go vet ./...
...
setting up env vars
? github.com/latchset/tang-operator [no test files]
? github.com/latchset/tang-operator/api/v1alpha1 [no test files]
ok github.com/latchset/tang-operator/controllers 9.303s coverage: 36.5% of statements
As shown previously, coverage is calculated after test execution. Coverage data is dumped to file coverage.out. To inspect coverage graphically, it can be observed by executing next command:
$ go tool cover -html=cover.out
Previous command will open a web browser with the different coverage reports of the different files that are part of the controller.
CI/CD
tang-operator uses Github Actions to perform CI/CD task. A verification job will run for each commit to main or PR. The verify job perform following steps:
- Set up Go
- Minikube Installation
- Check Minikube Status
- Build
- Test
- Cluster Test
- Deployment
- Scorecard test execution
NOTE: CI/CD is in a "work in progress" state
scorecard
Execution of operator-sdk scorecard tests are passing completely in version v0.0.25. In order to execute these tests, run next command:
$ operator-sdk scorecard -w 60s quay.io/sec-eng-special/tang-operator-bundle:v0.0.25
...
Results:
Name: olm-status-descriptors
State: pass
...
Results:
Name: olm-spec-descriptors
State: pass
...
Results:
Name: olm-crds-have-resources
State: pass
...
Results:
Name: basic-check-spec
State: pass
...
Results:
Name: olm-crds-have-validation
State: pass
...
Results:
Name: olm-bundle-validation
State: pass
Links
CodeReady Containers Installation
operator-sdk Installation
OpenShift CLI Installation
Validating Operators using the scorecard tool
Documentation
¶
There is no documentation for this package.
Source Files
Directories
¶
| Path | Synopsis |
|---|---|
|
api
|
|
|
v1alpha1
Package v1alpha1 contains API Schema definitions for the daemons v1alpha1 API group +kubebuilder:object:generate=true +groupName=daemons.redhat.com
|
Package v1alpha1 contains API Schema definitions for the daemons v1alpha1 API group +kubebuilder:object:generate=true +groupName=daemons.redhat.com |