Introduction

I conducted a PoC for Argo Workflow and Argo Event, evaluating their installation and performance.
Through this article, I aim to determine whether they encompass the necessary features for our service integration.

Install

In my previous article, I utilized yaml for installation. However, for more streamlined management, I’ve now opted for Helm Chart.
Given that the official documentation offers an exhaustive guide, I’ll provide a link in lieu of a detailed explanation.

• Argo Workflow
• Argo Event
• Github

Workflow Archive

Through the Workflow, you’ll initiate Jobs or CronJobs.
An excessive number of Workflows, Jobs, and CronJobs can potentially disrupt Kubernetes operations.
As a precaution, it’s essential to regularly remove older Workflows after they’ve been active for a set duration.

For operational considerations, it’s crucial to document when the Workflow was deployed and the parameters utilized.
To cater to this requirement, Argo Workflow offers a feature to preserve execution histories, termed as “Archive”.

Argo Workflow’s Archive functionality is compatible with both MySQL and PostgreSQL.
In this guide, I’ll delve into the MySQL implementation. However, the approach for PostgreSQL mirrors closely.
Engaging with the established MySQL Database entails two pivotal tasks.

1. Set up an account and associated permissions using Kubernetes Secret.
2. Configure Database Options.

Set up an account and associated permissions using Kubernetes Secret.

For account configuration, please refer to the example provided below.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

apiVersion: v1
kind: Secret
metadata:
  labels:
    app: mysql
  name: argo-mysql-config
  namespace: argo
stringData:
  password: ${password}
  username: ${account}
type: Opaque

Configure Database Options.

Upon attempting to integrate the established MySQL with Argo Workflow, I encountered an SSL-related connectivity error.

Fortunately, this complication has been addressed in the latest release, version v3.3.x.

While a brief search based on the error message will clarify the solution, the remedy involves simply adding an option to MySQL.
Surprisingly, this solution isn’t documented in the Argo Workflow official documentation.
Nevertheless, by exploring the Git Issue (PR)), it becomes evident that this topic has been addressed and subsequently resolved.

Moving forward, given that Argo Workflow is deployed using Helm, we need to ensure that the Helm Chart’s template accommodates this particular feature.
The connection information for the Database is structured into a ConfigMap to facilitate the Archive capability. At this juncture, it’s imperative to ascertain whether MySQL Options can be seamlessly integrated within the ConfigMap.

Thankfully, as indicated by this link, it’s evident that the inclusion of Options is feasible.

Structure

Argo Event has the capability to capture a range of events and subsequently initiate the desired Job or Object.
Argo Workflow, on the other hand, is tasked with executing Workflows as delineated within the YAML file.
Utilizing Calendar(Cron) and Webhook EventSource, events are generated. These spawned events then act as triggers for the Workflow.
The ensuing diagram encapsulates the flow derived from the aforementioned narrative.

Requirement

Beyond the intrinsic features, it was imperative for me to ascertain the ability to register vital functionalities and granular details.
The ensuing criteria were pertinent:

• Usability of Webhook and Cron
• Comprehensive History Management
  • Identification of the executor during manual operations
  • Verification of execution date when automated
  • Insight into parameters utilized during execution
• Facilitation of manual parameter adjustments within the UI interface
• Feasibility of templating; Manageable through ArgoCD (helm) (GitOps)

Given that I’ve previously evaluated resource consumption and the feasibility of Webhook and Cron, I won’t re-examine these aspects.

Managing History

For the three elements listed below, I’ve opted to use screenshots as a means of verification.
This approach allowed me to substantiate that detailed logs pertaining to the executor, execution timeframe, and selected options can be meticulously recorded.

Identification of the executor during manual operations

Verification of execution date when automated

Insight into parameters utilized during execution

Feasibility of templating

To utilize Argo Workflow, one must craft the yaml in alignment with the Workflow Spec.
Yet, it’s often a challenge for individual users to draft the yaml while adhering to the Workflow Spec guidelines.
By designing a Template via Helm Chart and accompanying it with a Guide, users can conveniently adapt their use case by merely tweaking the example values.yaml, independent of the Workflow Spec intricacies.
I’ve leaned heavily on ArgoCD’s Helm capabilities to simplify this process.

Below is a visual representation of the anticipated layout alongside its corresponding applied UI.

Projected Diagram

Argo Workflow Visualized

Workflow Variable

Even with templating in place, there can be instances within Spring Batch’s Parameter where the integration of variables becomes essential.
A typical example would be leveraging the execution date.
Anticipating such needs, Argo Workflow furnishes a functionality to enable variable implementation.
This is architected atop the Golang Template Language, a syntax that some might find novel and potentially daunting to experiment with.
For a more granular exposition, I’ll reserve a comprehensive discussion for a subsequent piece.

Conclusion

Integrating and utilizing Argo Workflow and Argo Event posed no significant challenges.
While there were several specifications to consider, Argo Workflow’s inherent capabilities met these prerequisites, affirming its seamless deployment.