IBM Technology Zone (TZ) has built a deployment automation system that allows IBMers, Red Hat® and Partner seller (sellers) teams to select from a wide range of IBM® products and enables them to build unique, customized solutions. These solutions can be deployed into reserved TechZone OpenShift Clusters, or into an OpenShift cluster that was previously built including clusters built by TechZone OCP Installer. This system enables sellers to quickly build and share customized environments throughout the entire lifecycle of a sale including deployment in the customer’s cloud environment.
TZ Deployer is composed of a set of deployment automation scripts, a software catalog, and provisioning tools that leverage the catalog to deploy the scripts onto provisioned OpenShift® Clusters.
TechZone deployment components should be built to be portable. IBM sellers use TechZone to demo software and deploy solutions. When transitioning to customer environments the same deployment automation should be available to accelerate the transition.
Users should be able to globally search all solutions aided by filtering mechanisms on product areas, platforms and quality standards.
Both users and contributors should be able to see and note defined relationships between assets, products, version and owners.
Contributors and developers should have a great experience building and testing their code making it easy to develop new automation components. Contributors should find it easy to generate a product, see other well-constructed examples, and then build and test their contributions. Tested contributions should automatically be available for users.
Component and requirement
Reason for choice
Alternative choice
Automation engine
A way is needed to programmatically define the steps to deploy a piece of software into a Kubernetes openshift cluster. Most IBM product documentation is complex and requires a large number of prerequisites, requiring a high skill level to achieve.
Tekton is a cloud-native solution for building CI/CD pipelines. It consists of Tekton Pipelines, which provides the building blocks, and of supporting components, such as Tekton CLI and Tekton Catalog, that make Tekton a complete ecosystem. Tekton is part of the CD Foundation, a Linux® Foundation project.
Tekton installs and runs as an extension on a Kubernetes cluster and comprises a set of Kubernetes Custom Resources that define the building blocks you can create and reuse for your pipelines. Once installed, Tekton Pipelines becomes available via the Kubernetes CLI (kubectl) and via API calls, just like pods and other resources.
Jenkins, Travis
Software catalog
A way is needed to help both contributors and users register and search for automation components. For users they need to quickly be able to see a list of components, and choose the most suitable.
The Backstage Software Catalog is a centralized system that keeps track of ownership and metadata for all the software in your ecosystem (services, websites, libraries, data pipelines, etc). The catalog is built around the concept of metadata YAML files stored together with the code, which are then harvested and visualized in Backstage.
There are other commercial offerings for developer portals and software catalogs such as configur8. Most large enterprises have multiple custom built portals built on a range of software such as mediawiki, wordpress or confluence.
Developer tools
Tektons adaptation to deploy IBM products has produced a wide variety of ways of building pipelines. To increase adoption and accelerate new pipelines and updates, developers should have access to project generation and code tools that help build Tekton pipelines in a standard way.
Cdk8s is a new library built on previously established work for AWS in CDK and Terraform with CDKtf. CDK8s allows developers to treat yaml generation as a standard development operation including unit tests, classes, imports and reuse.
The default approach would be to create some standard yaml templates and copy these across. Other approaches would include packaging the automation as helm charts.
Provisioning tool
A user should be able to quickly and easily apply a pipeline to a specific cluster and initiate that pipeline to deploy the target software. The provisioning tool should validate and collect any user parameters needed, validate the cluster is ready, install pipelines on the cluster and check status.
We built a custom cli to anticipate and interface with user commands on a command line to install and manage the pipelines and automation components.
oc cli, kubectl, or helm
Telemetry and Monitoring
User and contributor activities should be logged with key metrics being baselined. Incident response should be enabled.
Several alternatives being researched.
Instana, Grafana, OpenTelemetry, Eventstreams
Key decisions for implemention
Storage, catalog and provisioning should be able to scale to the amount of developers and users deploying at any one time. IBM TechZone has focused on provisioning systems with a microservice architecture that allows up to 30,000 provisioning activities a month.
SSO and RBAC
Both the catalog and provisioning systems interface with an IBM hosted SSO and RBAC system to identify users and assign roles.
Secrets management
Automation components and clusters can interface with secrets management so that Users have access to only the secrets they need to deploy the keys. Secrets can be stored in Kubernetes secrets, IBM Cloud® Secrets Manager or third party products such as vault. Secrets are brokered by an External Secrets Operator to be available in cluster namespaces.
Teams and organization
For scale and separation of concerns we recommend scaling a set of teams as adoption grows:
Testing and validation
All automation components should be continuously tested on a regular schedule. Any solutions that fail testing should be removed from availability and refer back to original authors for maintenance. Refer to the IBM Well-Architected framework for comprehensive testing scenarios.
Telemetry and monitoring
The system should collect telemetry and logs from the testing framework, the software catalog and deployment attempts. Baselines should be established and any out of baseline incidents. These systems trigger alerts when SLIs deviate from acceptable ranges, allowing engineers or automated processes to respond quickly to address indicative signals.