Building our new Synopsys Operator took some effort, but the results are impressive! Read our tips for creating your own Operator for Red Hat OpenShift.
Synopsys and Red Hat have produced a smooth Operator that I think would even impress Sade herself! Synopsys is introducing a new version of our Synopsys Operator, version 2019.4.0, which helps our customers easily deploy our application security testing tools in container orchestration environments. We also just completed Red Hat certification for this version of the Synopsys Operator, and we’re tremendously impressed by how it’s rendered and integrated into OpenShift 4.
In this blog post, I’ll share some resources and lessons we learned through the process of producing what you see in the following screenshot. Even though it’s not the smooth operator Sade was singing about, it’s pretty darn sexy!
Synopsys Operator is a cloud-native administration utility for Synopsys software. Synopsys Operator assists in the deployment and management of Synopsys software like Black Duck, OpsSight Connector, and Black Duck Alert in a Kubernetes and Red Hat OpenShift environment.
In addition to the OperatorHub, the Synopsys Operator deployment can be managed by a utility called synopsysctl. The synopsysctl utility makes it easy to deploy Synopsys Operator, and it eliminates the need to edit YML/JSON configuration files when deploying and managing software with Synopsys Operator. Synopsysctl provides a rich set of command-line parameters to allow for fast, highly configurable deployments of Black Duck, OpsSight Connector, and Black Duck Alert. Synopsysctl’s interface mimics that of kubectl and oc, making it immediately familiar to anyone with Kubernetes or Red Hat OpenShift experience.
You definitely need a rock star engineering team, like we have at Synopsys, to develop a smooth Operator. Stating the obvious here. But then, as you begin the Operator publishing process, here are some key resources to keep in mind:
As a result of all my mishaps, I’ve got some tips to help you while you publish your Operator. You’ll notice a common theme in all these points: If I had just RTFM!
verifytwice, the second time with the
./openshift-install create cluster.
apiVersion: operators.coreos.com/v1 kind: OperatorSource metadata: name: synopsys-certified namespace: openshift-marketplace spec: type: appregistry endpoint: https://quay.io/cnr registryNamespace: davemeurer displayName: "Synopsys Operators" publisher: "Synopsys"
Well, I hope this blog is somewhat helpful as you contribute your Operators to Kubernetes and OpenShift. At the very least, the best advice I can give you as you’re working on the required metadata files is to throw on some early ’80s music in hopes that you’re building a smooth Operator. Feel free to ping me if you have any questions, or stop by our booths at Red Hat Summit and KubeCon this year!
Dave Meurer currently serves as the senior technical alliances manager on the Synopsys Software Integrity Group’s Business Development team, where he leads technical planning, solution development, enablement, and evangelism with existing and potential strategic alliances and partners of Synopsys. Dave joined Synopsys through the acquisition of Black Duck, where he served in a similar role as the director of sales engineering for North America. Before coming to Black Duck Software, Dave worked for Skyway Software, HSN.com, and Accenture in various management and development roles. When he’s not thinking about joint partner solutions, he plays Uber driver for his five kids’ sports activities. Follow him on Twitter at @davemeurer. He mostly just posts pictures of homemade pizza.