BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News CircleCI Adds Additional Partner Integrations to Support Kubernetes Workloads

CircleCI Adds Additional Partner Integrations to Support Kubernetes Workloads

This item in japanese

CircleCI has announced new partner integrations as part of their Technology Partner program. CircleCI previously introduced a package management solution called Orbs. Orbs bundle common CI/CD tasks into reusable, shareable packages. With this announcement, CircleCI has added partner-supported orbs for AWS, Azure, VMware, Red Hat, Kublr and Helm.

Orbs are shareable components that combine commands, executors, and jobs into a single, reusable block. This allows for organizations to share their preferred CI/CD across teams and projects. It also simplifies the integration of third-party solutions into the CI/CD pipeline with a minimal amount of code.

CircleCI provides an orbs registry allowing for sharing of both official orbs, partner-provided orbs, and orbs contributed by the community. Tom Trahan, head of business development at CircleCI, indicated in a conversation with InfoQ that since the launch of Orbs back in November there are now over 700 orbs available in the registry. Within the registry orbs are marked as "Certified" if they are provided by CircleCI, or "Partner" if supplied by a partner integration.

This latest announcement sees additional orbs added from both CircleCI and partners to support and manage Kubernetes services and environments. This includes orbs for Google Kubernetes Engine, Amazon Elastic Container Service (EKS), Azure Kubernetes Service, and Red Hat OpenShift. Orbs were also added to facilitate interacting with container registry services from Amazon, Google, Docker, and Azure.

Nathan Dintenfass, product manager with CircleCI, shared that orbs are meant to solve three key problems. The first is providing better "Don't Repeat Yourself" (DRY) support within CircleCI configuration. Secondly, the team looked to allow for code reuse to be possible between projects. Finally, they looked to provide easier paths to allow for common configuration and reduce the amount of boilerplate code common in setting up CI/CD pipelines. In preparing the new package management solution, the team looked to maintain existing decisions made with how CircleCI configuration is structured: preferring the configuration to be in code, providing deterministic builds, and storing configuration as data.

As Dintenfass explains, the team made the decision that orb revisions are immutable. This ensures that no changes are shipped without first adjusting the version. For version tracking, orbs must follow a strict semantic versioning approach. To allow for development versions, orbs can be published with the version dev:foo. This allows for development orbs to be mutable by anyone on the team with the orbs expiring 90 days after the last publish date. Orbs published with a semver version are considered production orbs and are then immutable and durable.

Orb dependencies are locked at the time of publishing. For example, if Orb-A has a dependency on Orb-B, that dependency will be version-locked when Orb-A is added into the registry. If a new version of Orb-B is shipped to the registry, it will not be incorporated into Orb-A until a new version of Orb-A is published. Dintenfass indicates that this choice aligns with the decision to provide deterministic builds.

Each orb lives in a unique namespace. As Dintenfass describes, "There is no 'empty' namespace, nor are there reserved special defaults like _ for CircleCI or 'official' orbs. We decided that we didn't want orbs we author to be considered the default set or have special significance in our namespacing scheme." They have introduced a Certified Orbs program, where certified orbs are treated as part of the platform by the CircleCI team. At the time of writing only orbs in the circleci namespace are certified.

At this time, all orbs are open-source. Dintenfass indicates that: "If you can execute an orb, you can see the source of that orb. This is so you are never executing a black box inside your jobs, where your code and secrets are present." While there is no automatic static scanning of orbs at this time, Trahan has shared that this is on the roadmap for an upcoming release. He also added that all certified and partner orbs go through a review process by CircleCI to ensure they follow best-practices.

Trahan provided details that the CircleCI has themed releases planned as part of their roadmap. The team reviews common use cases from their clients and look to provide improvements to simplify those cases. According to Trahan, future themes will include security improvements (vulnerability scanning, secrets management, and policy compliance), tools to provide management of open-source projects, and automated testing solutions. In addition to future feature improvements, the team is also adding new partners on a monthly basis.

CircleCI has provided documentation on both how to use and publish orbs. The current listing of orbs can be viewed in the Orb Registry. Orbs are currently available within both the free and paid tiers of the cloud offering. While not currently available on the self-hosted version, Trahan has indicated this is on their roadmap. For more information about the new partners and orbs added to the registry, please review the official announcement on the CircleCI blog.

Rate this Article

Adoption
Style

BT