Aug 15, 2019 by Cameron Motevasselani
Software is written with a particular purpose in mind, e.g., text editing, payment processing, chatting, etc. Despite having automation via software, historically we have still had to manually integrate disparate components. For example, when a build is ready, it is a manual process to install it to a server. Over the past decade, there has been a growing trend towards integrating your software with other systems.
While it may seem commonplace these days, that green “build passing” sign in your favorite project’s repo is one of those integrations that saves us countless hours of time:
Automation via system integration is more important than ever, as seen by these projects:
In the context of Spinnaker, integrating with other systems is challenging. Traditionally, integration required either:
In order to make extending Spinnaker functionality easier to do, we’re working on the ability to create and use plugins for the Spinnaker ecosystem.
Everyone who runs Spinnaker has slightly different needs, and that is one of the great things about Spinnaker — it will meet you where you are. One great example of this is the built-in ability to use many different cloud providers. Currently, Spinnaker packages up the functionality to interact with every supported cloud provider, whether users use them or not.
This unused functionality leads to bloated binaries and a larger threat surface. Ideally, you’d be able to customize your Spinnaker installation to include only what you need. In the case of Spinnaker’s Clouddriver microservice, it would be great to configure and include functionality only for the clouds you interact with. Playing this idea forward, you might even want to split up each Clouddriver microservice to interact with one cloud provider at a time, so you can scale Clouddriver instances independently for each cloud.
Stripping out unnecessary and unused pieces of code turns Spinnaker into a project with a lean core. With the addition of Plugins, we provide the basis for an expansive ecosystem. By moving Spinnaker towards being a project with a lean core and expansive ecosystem, users will be able to customize their own Spinnaker faster and have a lower barrier to entry for contributing to the Spinnaker ecosystem. Plugins also help deliver new features to Spinnaker users without requiring a version update. After talking with numerous customers about this feature, we heard about the following use cases:
Do you have any use cases you’d like to share? Reach out to us at [email protected]!
All that sounds great, but how do we get there? Version 1.16 of Spinnaker includes the ability to add custom stages via plugins, as seen in this demo video.
Adding a new stage is as simple as creating a package that implements an interface in Java and configuring your Spinnaker installation to use your new plugin! This significantly lowers the barrier to entry to customizing Spinnaker to integrate with custom environments.
Once you’ve packaged up your plugin (or use an off-the-shelf plugin), then you can use Halyard to update the Spinnaker configs and re-deploy the necessary Spinnaker services with the configured plugin(s). In the case of custom stages, the services that are re-deployed are Orca and Deck.
This is just the start of the plugin ecosystem for Spinnaker. Future plans include a registry, since a plugin ecosystem isn’t complete without a way to discover and download your favorite plugins. We’d love to see both OSS and Enterprise members contribute to the plugin ecosystem and we plan to help facilitate that.
If you have any questions or use cases, please don’t hesitate to contact us at [email protected]!
Introducing Quick Spin One of the most common challenges that organizations face when implementing a continuous deployment strategy is the time and focus that it takes to set up the tools and processes. But a secure, flexible, resilient and scalable solution is available right now. Want to see if it’s the right tool for your […]
Read more →
Spinnaker is the most powerful continuous delivery tool on the market. DevOps engineers and developers recognize this power and are looking to use Spinnaker as a foundational tool in their Continuous Integration and Continuous Delivery (CI/CD) process for hybrid and multi-cloud deployments. Such a powerful, expansive open source tool needs expertise within your organization to […]
Read more →
Today, Armory is excited to announce the availability of the GitHub Action for Armory Continuous Deployment-as-a-Service. GitHub is where developers shape the future of software. After a developer writes and tests their code in GitHub, it must be deployed. Armory’s GitHub Action for Continuous Deployment-as-a-Service extends the best-in-class deployment capabilities to Kubernetes. CD-as-a-Service enables declarative […]
Read more →