Presenters

Source

Level Up Your Deployments: Unlocking Advanced Canary Strategies with Argo Rollouts Step Plugins 🚀

Ever felt like your canary deployments could be smarter? Like they needed a bit more… oomph to handle complex scenarios? Well, buckle up, fellow tech enthusiasts, because Intuit, the financial powerhouse behind QuickBooks and Mailchimp, has just dropped a game-changer in the cloud-native world: Canary Step Plugins for Argo Rollouts! 🤯

Intuit, a true champion of open-source contributions to the cloud-native ecosystem (they’re the brilliant minds who originated Argo CD, after all!), unveiled this pivotal enhancement at Argo Con. Their staff software engineers and Argo maintainers, Alexandre Gaudreault and Zach Aller, shared how this feature, introduced in Argo Rollouts version 1.8, is poised to supercharge your canary deployment strategies by allowing you to inject custom logic directly into the rollout process.

Intuit’s Argo Rollouts Powerhouse 💪

Before we dive deep, let’s talk scale. Intuit doesn’t just use Argo Rollouts; they live it. They’re managing a staggering 24,000 rollout resources, with a combined 85,000 steps, executing an impressive 116,000 deployments every single month! And the best part? Argo Rollouts has been a superhero in incident prevention, aborting problematic changes over 100 times monthly. That’s a testament to the power of intelligent, automated deployments.

The Evolution of Argo Rollouts: Beyond Traffic and Metrics 🌐

Historically, Argo Rollouts has been fantastic at handling traffic routing (think Istio, App Mesh) and integrating with metric providers to act as the “source of truth” for aborting deployments based on performance dips. But what if your setup is a little… unique? What if you’re using a traffic router that Argo doesn’t natively support, or you need to perform specific pre-deployment checks before any traffic even starts shifting?

This is where the new step plugins come in, marking a massive leap forward. They allow you to weave custom actions directly into the fabric of your rollout workflow, addressing those limitations and opening up a universe of possibilities.

Why Step Plugins Are a Big Deal ✨

The benefits of this new feature are pretty compelling:

• Extended Integration: Say goodbye to being locked into supported traffic routers! Step plugins empower you to integrate Argo Rollouts even with unsupported systems by developing your own custom plugins.
• Reduced Open-Source Burden: Intuit is smart. By distributing the complex task of maintaining plugins for various traffic routers across the vibrant Argo community, they’re fostering innovation and reducing the maintenance load on any single entity.
• Enhanced Workflow Customization: Move beyond simple traffic shifting. Step plugins enable you to craft intricate deployment scenarios that perfectly match your unique operational needs.

Under the Hood: Plugin Architecture and Configuration 🛠️

So, how does this magic happen? Argo Rollouts defines a plugin as a standalone Go process that runs a gRPC server. They’ve opted for HashiCorp’s Go plugin library, choosing the straightforward net/rpc over the more complex gRPC proto file and code generation. While this means plugins are written in Go, it significantly streamlines the developer experience.

Configuring these plugins involves two key stages:

1. Argo Rollouts ConfigMap (Global Magic) 🪄: This is where you define your plugin globally. You’ll specify:
   • The plugin’s name.
   • Its binary location.
   • Any arguments needed for execution.
   • A super useful new feature: the disable flag. This allows operators to gracefully skip a plugin if its endpoint is temporarily unavailable, preventing deployments from getting stuck! 🚫
2. Rollout Objects (Step-by-Step Control) 🚶‍♂️: Within the Canary steps of your rollout definition, you’ll introduce a plugin step. This is where you link to your configured plugin:
   • Specify the name to match the ConfigMap entry.
   • Provide a flexible config object. This can be any arbitrary data structure, allowing you to pass rich, detailed parameters to your plugin.

Building Your Own: Plugin Implementation Essentials 👨‍💻

Developing a step plugin involves implementing three core methods, each designed to give you granular control over the rollout process:

• run Method (The Workhorse) 💪: This is where your custom logic lives. It can be synchronous or asynchronous. For long-running operations, returning the Running phase and a backoff duration is crucial for keeping the rollout controller informed. If your operation is asynchronous, don’t forget to save essential state (like job IDs) within the rollout’s status. This ensures continuity if the controller restarts. A Failed status will trigger an abort and rollback, while an Error prompts retries by the controller.
• abort Method (The Cleanup Crew) 🧹: This method is invoked when a rollout is aborted – whether manually, due to a deadline, or a plugin failure. It’s called in the reverse order of plugin execution, giving you a critical window to clean up any ongoing operations (think canceling a triggered Jenkins job).
• terminate Method (The Fast Pass) 💨: This is called when a rollout is fully promoted, and you want to skip any remaining steps. It also provides an opportunity to cancel any in-progress plugin operations.

Unleash the Power: Real-World Use Cases 💡

The flexibility of step plugins unlocks a treasure trove of advanced deployment patterns:

• Custom Traffic Routing Logic: Need to route traffic to a secondary region for updates before shifting it back? Step plugins can handle that complexity.
• External System Integration: Trigger and monitor jobs in external systems like Jenkins, using their results to dictate rollout progression.
• Pre-Rollout Validation: Execute custom validation checks or tasks before any traffic is shifted, ensuring a smooth ride.
• Conditional Deployments: Dynamically alter your rollout path based on external conditions, making your deployments truly intelligent.

Live Demo Insights & Best Practices 🌟

The live demo at Argo Con was a fantastic showcase, illustrating a rollout that shifted traffic to a secondary region for primary region updates, then gradually shifted it back. It powerfully demonstrated:

• How plugin state is persisted in the rollout status, ensuring resilience.
• The absolute necessity of idempotency for the run method.
• The reverse execution order of abort calls, crucial for graceful cleanup.

For those looking to build their own step plugins, Intuit shared some invaluable best practices:

• Asynchronous Execution is Key: Always prefer asynchronous operations for long-running tasks to avoid blocking rollout reconciliations.
• State Persistence is Non-Negotiable: Save critical state in the rollout’s status object, not in memory, for true resilience against restarts.
• Mind Your State Size: Be aware of Kubernetes object size limits when storing state in the rollout CR.
• Thoughtful Config Design: The plugin configuration object is a user-facing API. Design it with care!

Security and Secrets: Keeping it Safe 🔐

Worried about security? Plugins running within the rollout controller inherit its permissions and have access to the same Kubernetes resources. Secrets can be securely provided to plugins by referencing Kubernetes secrets within the controller’s namespace, either directly or via references passed in the plugin’s configuration.

The Future is Extensible 🤖

The introduction of Canary Step Plugins transforms Argo Rollouts from a sophisticated deployment tool into a highly extensible platform. It empowers organizations to move beyond basic canary strategies and build tailored, robust, and incredibly intelligent deployment workflows. This is a significant step forward for anyone serious about reliable and advanced software delivery.

What complex deployment scenarios are you going to tackle with step plugins? The possibilities are truly exciting! ✨

Appendix