使いこなせ！Argo Workflows / How to use Argo Workflows

CloudNative Days Tokyo 2021 使いこなせ！Argo Workflows @makocchi

2 Makoto Hasegawa Working at // CIU, CyberAgent, Inc Currently
// Develop and maintain private OpenStack cloud. Develop and maintain Kubernetes as a Service platform. Kubernetes organization member (sig-docs-ja) CKA / CKAD / CKS Job Title // Technical Lead Infrastructure Engineer WHO am I Twitter // @makocchi Facebook // makocchi0923 Hobby // Playing bass

CloudNative Days Tokyo 2021 | @makocchi 3 💪 本日のゴール💪 Argo
Workflowsについて理解して使えるようになる！既に使っている人は知識の復習に！タコが好きになる Argo Workflows について一緒に学んでいきましょう👌

CloudNative Days Tokyo 2021 | @makocchi 4 Argo Workflowsとは？ https://github.com/argoproj/argo-workﬂows

CloudNative Days Tokyo 2021 | @makocchi 5 Argo Workflows is
an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Argo Workflows is implemented as a Kubernetes CRD (Custom Resource Definition). https://argoproj.github.io/argo-workﬂows/ Argo Workflows は Kubernetes 上で並列 Job を構成するオープンソースのコンテナネイティブなワークフローエンジンです。 Argo Workflows は Kubernetes の CRD で実装されています。つまりということ

CloudNative Days Tokyo 2021 | @makocchi 6 一つ一つの処理(Job)がパイプラインのようにつながっているもの例えばこんなもの
アプリケーションのソースを GitHub から Pull する 🔽 アプリケーションをビルドする 🔽 アプリケーションのコンテナイメージを作成する 🔽 コンテナレジストリに Push するワークフローとは？

CloudNative Days Tokyo 2021 | @makocchi 7 ワークフローをどうやって定義するの？このようなワークフローの定義を Kubernetes
の CRD を使って定義・実行することができるアプリケーションのソースを GitHub から Pull する 🔽 アプリケーションをビルドする 🔽 アプリケーションのコンテナイメージを作成する 🔽 コンテナレジストリに Push する apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: my-awesome-wf- spec: entrypoint: pull-from-github templates: - name: pull-from-github container: image: docker/my-image:1.0.0 command: [“git”, “clone”] …

CloudNative Days Tokyo 2021 | @makocchi 8 Argo Workflows では下記の
CRD が使われています Kind Shotnames Namespaced ClusterWorkflowTemplate clusterwftmpl,cwft FALSE CronWorkflow cwf,cronwf TRUE WorkflowEventBinding wfeb TRUE Workflow wf TRUE WorkflowTaskSet wfts TRUE WorkflowTemplate wftmpl TRUE ※ WorkflowTaskSet は v3.2.0 から登場参考までに CRD の情報

CloudNative Days Tokyo 2021 | @makocchi 9 Argo Workflowsをインストールしよう

CloudNative Days Tokyo 2021 | @makocchi 10 多くのケースでは下記のインストールの仕方で十分です $ kubectl
create namespace argo $ kubectl apply -n argo -f https://github.com/argoproj/argo-workflows/releases/download/vN.N.N/install.yaml 現時点での最新は v3.2.2 このケースではコントローラーには clusterrole が割当たり、クラスター全体(全ての namespace のリソース)を watch するパターンになります namespace に閉じた形でインストールしたい場合は install.yaml を namespace-install.yaml に変更してインストールして下さい Kubernetes クラスターに Argo Workflows をインストールする

CloudNative Days Tokyo 2021 | @makocchi 11 イマドキ kubectl なんかでインストールしてられっか！という人には・・
Helm Chart も用意されてます $ helm repo add argo https://argoproj.github.io/argo-helm $ helm install --create-namespace --namespace argo argo-workflows argo/argo-workflows 細かい設定の変更をしたい場合はこの方法がオススメです Chart は下記の GitHub リポジトリにあります https://github.com/argoproj/argo-helm/blob/master/charts/argo-workﬂows/ Kubernetes クラスターに Argo Workflows をインストールする

CloudNative Days Tokyo 2021 | @makocchi 12 時代はやっぱ kustomize でしょ！っていう人には・・・
もちろん kustomize でも可能です $ cat base/kustomization.yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - [email protected]:argoproj/argo-workflows.git/manifests/cluster-install?ref=vN.N.N namespace に閉じてインストールしたい場合は cluster-install の部分を namespace-install に変更してください Kubernetes クラスターに Argo Workflows をインストールする

CloudNative Days Tokyo 2021 | @makocchi 13 インストールが完了すると workflow-controller と
argo-server の 2 つのコンポーネントが稼働している(deployment)状態になっていると思います特に設定を変更しなかった場合は各 deployment は両方とも Pod が 1 つだけです場合によっては冗長化して動かしておきたい場合もあると思いますが、workflow- controller は Leader Election に対応しているので、Pod の数を増やすだけで特に何も考えずに冗長化することが可能です(v3.0.0以降) argo-server もそれ自体は状態を持たないので、特に何も考えずに Pod の数を増やすだけで冗長化することが可能です(v2.6.0以降) HA構成もオススメ Kubernetes クラスターに Argo Workflows をインストールする

CloudNative Days Tokyo 2021 | @makocchi 14 各種ワークフローの操作は argo コマンドで行います
なお、だいたいの操作は kubectl でも可能ですが、一部(ワークフローの resubmit とか)は argo コマンドじゃないと出来ない操作もありますインストールはバイナリが用意されているので配置するだけで完了します # Linux ͷ৔߹ (Mac ͷ৔߹͸ linux ͷ෦෼Λ darwin ʹมߋ͍ͯͩ͘͠͞) $ curl -sLO https://github.com/argoproj/argo-workflows/releases/download/vN.N.N/argo-linux-amd64.gz $ gunzip argo-linux-amd64.gz $ chmod +x argo-linux-amd64 $ mv ./argo-linux-amd64 /path/to/argo mac の方は brew でも可能です $ brew install argoproj/tap/argo コマンドラインツール argo をインストールする

CloudNative Days Tokyo 2021 | @makocchi 15 実は argo-server の
Pod は argocli というイメージが使われていますなので argo-server の Pod 内で argo コマンドを叩いてしまうという手もあります # ϕʔεΠϝʔδ͸ scratch ͳͷͰ͜ΕҎ֎͸΄΅Ͱ͖ͳ͍ɾɾ💦 $ kubectl exec -ti -n argo argo-server-68b9f8c695-h4nxp -- argo auth token Bearer eyJhbGciOiJSUzM... $ kubectl exec -ti -n argo argo-server-68b9f8c695-h4nxp -- argo list -n argo NAME STATUS AGE DURATION PRIORITY hello-world-b4n87 Succeeded 3m 31s 0 ※ ちなみに workflow-controller もベースイメージは scratch ちょっと触ってみるか、の場合はこれでいいかもしれませんコマンドラインツール argo をインストールする (楽ちん編)

CloudNative Days Tokyo 2021 | @makocchi 16 GUIにアクセスしてみよう

CloudNative Days Tokyo 2021 | @makocchi 17 Hello-world のワークフローを動かしたところ
Argo Workflows には素敵な UI が用意されています

CloudNative Days Tokyo 2021 | @makocchi 18 UI にアクセスするために必要なこと (expose
編) UI は argo-server の port 2746 によって提供されています。「kubectl port-forward」もしくは Service(NodePort や LoadBalancer) を作成することでアクセスが可能になります。 # port-forward ͷྫ (port 2746 -> port 2746) # ϒϥ΢βͰΞΫηε͢Δ৔߹͸ https://localhost:2746 $ kubectl port-forward -n argo svc/argo-server 2746:2746 Forwarding from 127.0.0.1:2746 -> 2746 Forwarding from [::1]:2746 -> 2746

CloudNative Days Tokyo 2021 | @makocchi 19 UI にアクセスするために必要なこと (expose
編) v3.0.0 以降、argo-server はデフォルトで HTTPS で Listen するようになりました。 port-forward する時は特に気にすることはないんですが、LoadBalancer や Ingress 配下にぶら下げたい場合に HTTP で Listen してほしいケースがあると思いますその場合は argo-server の Pod 内の args に「--secure=false」を追加、もしくは ARGO_SECURE=false の環境変数を設定してくださいしかしこれだけだと readinessProbe が「scheme: HTTPS」になっている場合にいつまで経っても READY にならないので「scheme: HTTP」に変更することも忘れずに！ちなみに Helm だと「--secure=false」がデフォルトになっているようですちなみに自己証明書の期限は 1 年(今の所ハードコード)で自動的に作成されます (Pod を再作成することで証明書も再作成されます)

CloudNative Days Tokyo 2021 | @makocchi 20 UI にアクセスするために必要なこと (Auth
mode 編) UI へアクセスすることができても、最初は何もできないと思います💦 なんらかの形で Login しないと先程のワークフロー一覧のような画面に辿り着くことができないようになっています。こんな感じで Login が必要になります

mode 編) argo-server では 3 つの認証方式をサポートしています。 server client sso v3.0.0 以前は server 方式がデフォルトで、v3.0.0 以降は client 方式がデフォルトです。認証方式の設定は argo-server の起動時に「--auth-mode=server」のように指定します。 3 つの認証方式はそれぞれ独立しているので、認証方式は複数指定することが可能です引数に渡す時に少し気をつけないといけないことがあります

mode 編) 複数の認証方式を設定する時は・・・「--auth-mode=client --auth-mode=server --auth-mode=sso」のように「--auth- mode」を複数回指定しなければなりません「--auth-mode=client,server,sso」のようにすることは出来ません・・！理由としては内部で cobra の StringArrayVarP で処理されているからで、これが StringSliceVarP だったらカンマ区切りでいけるのにな・・・ちなみにドキュメントには特に書かれていないんですが、hybrid というモードも指定することができます (「--auth-mode=hybrid」にすると server と client が有効になる) ソース見て初めて知った hybrid

mode 編) それぞれの認証方式はどのようなものなのでしょうか？ 1つずつ見ていきましょう！

CloudNative Days Tokyo 2021 | @makocchi 24 認証方式 server について

server による認証方式は UI の操作を argo-server 自体の権限で行う方式になりますおそらくみなさんの argo-server は「serviceAccount: argo-server」で動いていると思います。そして clusterrole として「argo-server-cluster-role」が割当たっているんじゃないでしょうか。(cluster install の場合) 「argo-server-cluster-role」は結構強い権限で、UI からワークフローを作成したり削除したりすることができます v3.0.0 より前はこれがデフォルトの認証方式でした

ちょっとログインが分かりにくいんですが、真ん中の token を使ってログインする場所で token を入れずに「LOGIN」をクリックすれば OK です。

CloudNative Days Tokyo 2021 | @makocchi 27 認証方式 client について

client による認証方式は UI の操作を特定のサービスアカウントの権限で行う方式ですサービスアカウントの token を入力してログインします「argo auth token」というコマンドを叩くと、自身の kubeconfig 内の token を抜き出して表示してくれますただし token 方式で認証していない kubeconfig を指定していると、「could not find a token」って怒られます・・・ v3.0.0 以降はこちらの方式がデフォルト

client による認証方式は UI の操作を特定のサービスアカウントの権限で行う方式ですサービスアカウントの token を入力してログインします「argo auth token」というコマンドを叩くと、自身の kubeconfig 内の token を抜き出して表示してくれますただし token 方式で認証していない kubeconfig を指定していると、「could not find a token」って怒られます・・・ v3.0.0 以降はこちらの方式がデフォルト # ͍͍ͪͪ token औಘ͢ΔͷΊΜͲ͍͘͞ͳ͊ɾɾͱ͍͏ਓ͸͜ΕͰ😝 $ kubectl exec -ti -n argo argo-server-68b9f8c695-h4nxp -- argo auth token Bearer eyJhbGciOiJSUzM...

ログインする場合は token の入力欄に「Bearer 」+「<token>」を入力してログインしますこの「Bearer 」(スペース有り)が無いとうまく認証できませんので注意！「argo auth token」で表示した場合は Bearer が付与されて表示されます「Bearer 」忘れずに

CloudNative Days Tokyo 2021 | @makocchi 31 認証方式 sso について

sso による認証方式は外部に認証を任せる方式です例えば Google 認証と連携させたりすることが可能ですログイン後にルールに従って RBAC を適用(サービスアカウント権限を割り当てる)することが可能です ⏩ の例は [email protected] でログインしたら「argo-read-only」のサービスアカウントの権限を与えるという例ですこの RBAC 連携は v2.12.0 以降で実装されています設定で RBAC 連携させるかさせないか選択が可能です

sso + RBAC の設定はサービスアカウントに対して「workflows.argoproj.io/rbac- rule」の Annotation を付けることで制御します # ྫ͑͹ @makocchi.com ͰϩάΠϯͨ͠Β argo-read-only ͷݖݶΛ౉࣌͢ apiVersion: v1 kind: ServiceAccount metadata: name: argo-read-only annotations: workflows.argoproj.io/rbac-rule: "email endsWith ‘@makocchi.com'" workflows.argoproj.io/rbac-rule-precedence: "10" 内部のルールの書き方はこちらの記述方式で行います https://github.com/antonmedv/expr/blob/master/docs/Language-Deﬁnition.md

「workflows.argoproj.io/rbac-rule-precedence」の Annotation は適用順序を制御する時に使います省略した場合は 0 で扱われるので、何かしら数を割り当てておいたほうがよいデフォルトのルールを 0 で定義しておくと良い # rbac-rule ͸ true ʹ͓ͯ͘͠ apiVersion: v1 kind: ServiceAccount metadata: name: default-ui-account annotations: workflows.argoproj.io/rbac-rule: "true" workflows.argoproj.io/rbac-rule-precedence: "0"

「--auth-mode=sso」の場合、別途設定が必要になります workflow-controller が参照する configMap で設定しますまた client-id や client-secret-key は別途 secret に登録する必要があります RBAC 連携をしない (sso.rbac.enabled=false)の場合、UI は argo-server のサービスアカウントの権限が割当たります # configMap Ͱ͍Ζ͍Ζઃఆ͕ඞཁ kind: ConfigMap metadata: name: workflow-controller-configmap data: config: | sso: issuer: https://accounts.google.com clientId: name: client-id-secret key: client-id-key clientSecret: name: client-secret-secret key: client-secret-key redirectUrl: https://your-server/oauth2/callback scopes: - openid - email - profile rbac: enabled: true sessionExpiry: 10h

いろいろ設定がめんどくさい部分がありますが、設定してしまえばかなり柔軟にアクセス制御できるようになるので是非 sso + RBAC をオススメします Argo CD の Dex との連携もできるよ！

CloudNative Days Tokyo 2021 | @makocchi 37 ここまでのまとめ

CloudNative Days Tokyo 2021 | @makocchi 38 Argo Workflows とは、ワークフローの処理をカスタムリソース
で管理することができるオープンソースのソフトウェア Kubernetes に対して様々なインストール方式に対応している kubectl apply / Helm / Kustomize HA 構成も手軽に組むことができる UI が用意されており、ワークフローの把握がしやすい UI は様々な認証方式に対応している server 方式 / client 方式 / sso 方式ここまでのまとめ

CloudNative Days Tokyo 2021 | @makocchi 39 ワークフローを書いてみよう

CloudNative Days Tokyo 2021 | @makocchi 40 用語の説明 UI の見た目と操作
シンプルな例 Dag の紹介パラメーターの渡し方 withItems を使った loop ワークフローの自動削除簡単なスクリプトの実行ワークフローから Kubernetes のリソースを作成するリトライ処理の仕方 Kind: Workflow の書き方 - 目次 - 失敗しても無視して進む方法条件によって処理を分岐させる Exit-handler の使い方ワークフローの途中で承認をしないと進まないようにしたい外部にあるリソースを簡単に取ってくるバックグラウンドでずっと起動させる Pod を作成する volumeClameTemplate を使ったファイルのやりとり artifacts を使ったファイルのやりとりワークフロー全体で使える変数を定義するワークフローの同時実行数の制御組み込み関数、sprig を使ったパラメーターの操作

CloudNative Days Tokyo 2021 | @makocchi 41 Kind: Workflow の書き方
# ͘͢͝γϯϓϧͳྫ apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: Name: hello-world spec: entrypoint: main templates: - name: main steps: - - name: step1 template: whalesay - name: whalesay container: image: docker/whalesay:latest command: [cowsay] args: [“step1”] とりあえずシンプルな例だとこちらです

Argo Workflows では一つ一つの処理を「template」という概念で管理します spec.entrypoint は必須になっていて、これはワークフローがどの処理(template)から開始するかを指定するものですワークフローの流れは steps として記述します(dag でも記述することが可能です) 実際の処理の詳細は「name: whalesay」に記述します(今回は steps の内部から参照する方式で記述しています) # ͘͢͝γϯϓϧͳྫ apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: Name: hello-world spec: entrypoint: main templates: - name: main steps: - - name: step1 template: whalesay - name: whalesay container: image: docker/whalesay:latest command: [cowsay] args: [“step1”]

先程のサンプルを UI で見るとこんな感じになります

こんな感じで Pod のログも見ることができます

steps の中身は基本的には上から書いた順に実行されていきます先程のシンプルな例に単純に step2 を追加するとこうなります # ͘͢͝γϯϓϧͳྫ2 ... spec: entrypoint: main templates: - name: main steps: - - name: step1 template: whalesay - - name: step2 template: whalesay - name: whalesay container: image: docker/whalesay:latest command: [cowsay] args: [“step1”]

# ͘͢͝γϯϓϧͳྫ2 ... spec: entrypoint: main templates: - name: main steps: - - name: step1 template: whalesay - - name: step2 template: whalesay - name: whalesay container: image: docker/whalesay:latest command: [cowsay] args: [“step1”] steps の中身は基本的には上から書いた順に実行されていきます先程のシンプルな例に単純に step2 を追加するとこうなります UI 的にはこんな感じになります

CloudNative Days Tokyo 2021 | @makocchi 47 ちなみに UI もいろいろオプションがあるよ
デフォルトだと上から下に流れるように表示されますが、左から右に流れるように表示することも可能ですここで切り替えられるよ！

CloudNative Days Tokyo 2021 | @makocchi 48 ちなみに UI もいろいろオプションがあるよ
その2 大きさも変えられますよ！ここで拡大縮小できる

CloudNative Days Tokyo 2021 | @makocchi 49 さらに言うと・・・実はボタンを増やすことができます外部にログ基盤とかあるのであれば Pod
の Status(startedAt とか)を url に埋め込めるので、リンクさせておくとか便利かもしれません

# inline ΋Մೳ apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: Name: hello-world-inline spec: entrypoint: main templates: - name: main steps: - - name: step1 inline: container: image: docker/whalesay:latest command: [cowsay] args: ["inline"] step 内の処理を template 内に別途書くのはちょっと違和感があるなぁという方は、inline でワークフローを書くこともできます少し直感的になるかもしれませんが、step が多いような場合に可読性が下がるかもしれません

ハマりがちポイント steps を記述する際に気をつけるポイントとして、「- -」という風に配列をネストさせる必要があります！「Failed to parse workflow: json: cannot unmarshal object into Go struct field Template.spec.templates.steps of type []map[string]interface {}」が出たら要確認！ # ΄Μͱؒҧ͑΍͍͢ apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: Name: hello-world spec: entrypoint: main templates: - name: main steps: - - name: step1 template: whalesay - name: whalesay container: image: docker/whalesay:latest command: [cowsay] args: [“step1”] - が 2 個必要！

なぜ map の配列が必要なのかというと、step で並列で動かしたい処理があった場合に対応するためです例えばこのように記述すると 2-1 と 2-2 は並列で動きます # ฒྻॲཧΛهड़͢Δ͜ͱ΋Մೳ ... - name: main steps: - - name: step1 template: argosay - - name: step2-1 template: argosay - name: step2-2 template: argosay - - name: step3 template: argosay - name: argosay container: image: argoproj/argosay:v2

なぜ map の配列が必要なのかというと、step で並列で動かしたい処理があった場合に対応するためです例えばこのように記述すると 2-1 と 2-2 は並列で動きます UI で見るとこのようになります # ฒྻॲཧΛهड़͢Δ͜ͱ΋Մೳ ... - name: main steps: - - name: step1 template: argosay - - name: step2-1 template: argosay - name: step2-2 template: argosay - - name: step3 template: argosay - name: argosay container: image: argoproj/argosay:v2

「- -」のせいで steps 書くの嫌いになった人がいるとかいないとか・・・そんな人には steps の代わりに dag を使うこともできます # ฒྻॲཧΛهड़͢Δ͜ͱ΋Մೳ ... - name: main dag: tasks: - name: step1 template: argosay - name: step2-1 depends: "step1" template: argosay - name: step2-2 depends: "step1" template: argosay - name: step3 depends: "step2-1 && step2-2" template: argosay steps の代わりに dag を記述する

「- -」のせいで steps 書くの嫌いになった人がいるとかいないとか・・・そんな人には steps の代わりに dag を使うこともできます dag を使う場合は depends を使って順番を制御してあげる必要があります # ฒྻॲཧΛهड़͢Δ͜ͱ΋Մೳ ... - name: main dag: tasks: - name: step1 template: argosay - name: step2-1 depends: "step1" template: argosay - name: step2-2 depends: "step1" template: argosay - name: step3 depends: "step2-1 && step2-2" template: argosay depends を書こう

「- -」のせいで steps 書くの嫌いになった人がいるとかいないとか・・・そんな人には steps の代わりに dag を使うこともできます dag を使う場合は depends を使って順番を制御してあげる必要があります「いっけーなーい。dag なのに depends 書き忘れちゃった😝てへっ」になるとこうなります # ฒྻॲཧΛهड़͢Δ͜ͱ΋Մೳ ... - name: main dag: tasks: - name: step1 template: argosay - name: step2-1 depends: "step1" template: argosay - name: step2-2 depends: "step1" template: argosay - name: step3 depends: "step2-1 && step2-2" template: argosay depends を書こう

同じような処理を parameter を変えて処理させたいと言ったケースが多いと思いますその場合は各処理は parameter を受け取ることができるので、それを使います inline で記載していると parameter の恩恵は受けにくいと思いますので、inline じゃない書き方に慣れておくほうがいいかなと思います # parameter Ͱॊೈʹॲཧͤ͞Δ ... - name: main steps: - - name: step1 template: whalesay arguments: parameters: - name: message value: hoge - name: whalesay inputs: parameters: - name: message container: image: docker/whalesay:latest command: [cowsay] args: ["{{inputs.parameters.message"]

parameters の定義は step 内で template を呼び出す時に定義するのと、呼び出される template 側の両方で定義してあげる必要があります呼び出す側は「arguments」として定義し、呼び出される側は「inputs」で定義します # parameter Ͱॊೈʹॲཧͤ͞Δ ... - name: main steps: - - name: step1 template: whalesay arguments: parameters: - name: message value: hoge - name: whalesay inputs: parameters: - name: message container: image: docker/whalesay:latest command: [cowsay] args: ["{{inputs.parameters.message"]

Inputs.parameters の定義はデフォルトの値を設定することが可能ですその場合は steps の arguments は省略することができます ⏩ の例の場合は cndt2021 が args として展開されます # parameter Ͱॊೈʹॲཧͤ͞Δ ... - name: main steps: - - name: step1 template: whalesay - name: whalesay inputs: parameters: - name: message value: cndt2021 container: image: docker/whalesay:latest command: [cowsay] args: ["{{inputs.parameters.message}}"] Value を設定するとデフォルト値になる

当然ですが、呼び出す時に arguments で定義すればデフォルト値は上書きされて渡されますちなみにデフォルト値が設定されていない場合に arguments でパラメーターを渡さなかった場合は「inputs.parameters.xxxx was not supplied」という形でワークフロー登録時にエラーになります # parameter Ͱॊೈʹॲཧͤ͞Δ ... - name: main steps: - - name: step1 template: whalesay arguments: parameters: - name: message value: hoge - name: whalesay inputs: parameters: - name: message value: cndt2021 container: image: docker/whalesay:latest command: [cowsay] args: ["{{inputs.parameters.message}}"] hoge で上書きされる

同じような処理を arguments だけ変えて繰り返し実行したい！というケースもあると思います例えば ⏩ のように処理したいケースです # parameter Ͱॊೈʹॲཧͤ͞Δ ... - name: main steps: - - name: step1 template: whalesay arguments: parameters: - name: message value: "1111" - name: step2 template: whalesay arguments: parameters: - name: message value: "2222" - name: step3 template: whalesay arguments: parameters: - name: message value: "3333"

同じような処理を arguments だけ変えて繰り返し実行したい！というケースもあると思います例えば ⏩ のように処理したいケースですそのような場合は withItems でまとめることができます注意点としてはあくまで同じ階層で複数回実行されるので、並列で処理されることになります # parameter Ͱॊೈʹॲཧͤ͞Δ ... - name: main steps: - - name: step1 template: whalesay arguments: parameters: - name: message value: "1111" - name: step2 template: whalesay arguments: parameters: - name: message value: "2222" - name: step3 template: whalesay arguments: parameters: - name: message value: "3333" # withItems Ͱϧʔϓͤ͞Δ ... - name: main steps: - - name: step1 template: whalesay arguments: parameters: - name: message value: "{{item}}" withItems: - "1111" - "2222" - "3333"

処理が成功した(もしくは失敗した)ワークフローは自動で削除したいケースがあると思いますその場合は ttlStrategy を使います ttlStrategy が無いと Completed な Pod で溢れることになりますので、設定しておくことをオススメしますいちいち Workflow に書くの面倒くさいよねっていう場合はコントローラーで TTL のデフォルト値を設定しておくことも可能です # ttlStrategy ͸ઃఆ͓ͯ͜͠͏ apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: hello-world-til spec: ttlStrategy: secondsAfterCompletion: 10 secondsAfterSuccess: 5 secondsAfterFailure: 5 entrypoint: main ... workflow-controller が参照する ConfigMap で設定しておく

ttlStrategy の設定項目の説明ワークフローは内部的にステータスとして Phase という状態を持っていますその Phase によってそれぞれ TTL を設定できます secondsAfterSuccess : Phase が Succeeded secondsAfterFailure : Phase が Failed secondsAfterCompletion : これがちょっと特殊で、ワークフローの Phase に関係なく各処理の状態が Running じゃないもの # ttlStrategy ͸ઃఆ͓ͯ͜͠͏ apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: hello-world-til spec: ttlStrategy: secondsAfterCompletion: 10 secondsAfterSuccess: 5 secondsAfterFailure: 5 entrypoint: main ... 自分もちょっと自身が無いんですがワークフローは Phase として Succeeded と Failed 以外に Error もあるので Succeeded と Failed 以外の状態のものと考えていいかもしれません

ちょっとしたスクリプトを実行したい場合もあると思いますその場合は script を使うことができます sh だけじゃなくて python とかでも OK # script Ͱ sh Λ࣮ߦ͢Δ apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: sh-script spec: entrypoint: main templates: - name: main steps: - - name: sh template: sh-script - name: sh-script script: image: alpine:latest command: [sh] source: | apk -q update && apk -q upgrade apk -q add figlet echo cndt2021 | figlet conatiner の代わり

ワークフローの処理中に Kubernetes のリソースを作成したい！そんな場合も resource を使って定義することが可能です serviceAccountName が無い場合は namespace 内の default の権限で実行されることになるので、大抵の場合は失敗することになります serviceAccountName は適切に設定することをオススメします # ࣌ʹ͸௚઀ૢ࡞΋ඞཁʹͳΔ͔΋ʁ ... - name: main steps: - - name: k8s-create-cm template: k8s-create-cm - - name: k8s-get-cm template: k8s-get-cm - name: k8s-create-cm serviceAccountName: workflow-sa resource: action: create manifest: | apiVersion: v1 kind: ConfigMap metadata: name: test-cm data: key: value - name: k8s-get-cm serviceAccountName: workflow-sa container: image: argoproj/argoexec:latest command: [sh, -c] args: ["kubectl get cm test-cm"]

処理が失敗した時に自動でリトライしたい！そんな場合は retryStrategy を設定しますリトライ回数は limit で指定しますあくまでリトライの回数なので、⏩ の例だと本実行とリトライの合計で 6 回まで処理が実行される可能性があります(最初の実行は 0 番目のリトライとして表示されるみたいです) # ϦτϥΠॲཧͰສ͕Ұͷ࣌΋҆৺ ... - name: main steps: - - name: fail-with-retry template: fail-with-retry - - name: step-after-success template: whalesay arguments: parameters: - name: message value: "Success!" - name: fail-with-retry retryStrategy: limit: "5" script: image: python:alpine3.6 command: ["python"] source: | import random; import sys; exit_code = random.choice([0, 1, 1]); sys.exit(exit_code) ...

処理が失敗した時に自動でリトライしたい！そんな場合は retryStrategy を設定しますリトライ回数は limit で指定しますあくまでリトライの回数なので、⏩ の例だと本実行とリトライの合計で 6 回まで処理が実行される可能性があります # ϦτϥΠॲཧͰສ͕Ұͷ࣌΋҆৺ ... - name: main steps: - - name: fail-with-retry template: fail-with-retry - - name: step-after-success template: whalesay arguments: parameters: - name: message value: "Success!" - name: fail-with-retry retryStrategy: limit: "5" script: image: python:alpine3.6 command: ["python"] source: | import random; import sys; exit_code = random.choice([0, 1, 1]); sys.exit(exit_code) ...

少し高度な retryStrategy リトライの間隔や時間の設定を backoff を使って細かく設定することが可能ですいわゆる exponential backoff を実現することが可能です ⏩ の例だとリトライは 10秒待つ⇒20秒待つ ⇒40秒待つ・・となります(factor は何倍するか) maxDuration が 1m(60秒) なので、リトライとしては 2 回で終わることになります # ϦτϥΠॲཧΛ΍͘͢͞͠Δ ... - name: main steps: - - name: fail-with-retry template: fail-with-retry - - name: step-after-success template: whalesay arguments: parameters: - name: message value: "Success!" - name: fail-with-retry retryStrategy: limit: “5" backoff: duration: "10s" factor: "2" maxDuration: "1m" script: image: python:alpine3.6 command: ["python"] ...

いやいや処理が失敗したらリトライしないでフローを進めてほしいそんな場合は失敗を無視したい step に対して continueOn を設定します失敗したフローがあったとしてもワークフロー全体としては成功扱いになります # ΤϥʔΛແࢹ͢Δஉؾ step ͸ͪ͜ΒͰ͢ ... - name: main steps: - - name: continue-on-fail template: always-fail continueOn: failed: true - - name: step-after-fail template: whalesay arguments: parameters: - name: message value: "I'm fine!" - name: always-fail script: image: python:alpine3.6 command: ["python"] source: | import sys; sys.exit(1) ...

直前の処理の結果によって処理を分岐させたい条件付き実行は when を使うことで実現できます特定の処理のステータスは steps.<step名 >.status で取ることができます # ෳࡶͳॲཧΛ͢Δʹ͸ when ͸͔ܽͤͳ͍ ... - name: main steps: - - name: random-fail template: random-fail continueOn: failed: true - - name: after-succeeded-step when: "{{steps.random-fail.status}} == Succeeded" template: whalesay arguments: parameters: - name: message value: "Success!" - name: after-failed-step when: "{{steps.random-fail.status}} == Failed" template: whalesay arguments: parameters: - name: message value: "Fail!" ...

処理の結果(ステータス)だけではなくて、出力結果による分岐も同じような記述で可能です出力結果は steps.<step名 >.outputs.result で取得できます result を取得する場合は RBAC 的に pods/log が必要になりますその為 serviceAccountName を設定しないとエラーになることがありますので注意して下さい # ෳࡶͳॲཧΛ͢Δʹ͸ when ͸͔ܽͤͳ͍ ... serviceAccountName: workflow-sa templates: - name: main steps: - - name: random-output template: random-output - - name: zero-step when: "{{steps.random-output.outputs.result}} == zero" template: whalesay arguments: parameters: - name: message value: "zero" - name: one-step when: "{{steps.random-output.outputs.result}} == one" template: whalesay arguments: parameters: - name: message value: "one" - name: random-output script: image: python:alpine3.6 command: ["python"] source: | import random; result = "zero" if random.randint(0,1) == 0 else "zero" print(result) ...

各処理ではなくて、ワークフロー全体として成功したか失敗したかをハンドリングして特定の処理をさせたいワークフローには onExit を設定することでワークフローが終了した時の処理を定義することが可能です(exit-handler) この機能を使えば、例えばワークフローが失敗した場合に Slack に通知する、なんてことも可能です本格的に運用する場合は必ず設定しておくといいでしょう # େࣄͳϫʔΫϑϩʔʹ͸ඞͣ exit-handler Λઃఆ͠·͠ΐ͏ ... spec: entrypoint: main onExit: slack-post templates: - name: main steps: - - name: hello template: hello - name: hello container: image: alpine:latest command: [sh, -c] args: ["echo hello"] - name: slack-post container: image: curlimages/curl command: [sh, -c] args: ["curl -XPOST -d ‘payload={....}'"] ... ワークフローが終わった時に呼ばれる

ワークフローが失敗した時だけ onExit で処理させたい onExit の処理を記述する時に steps と when を使うことで実現できます残念ながら steps の内部じゃないと when は使えないのでこんな書き方になりますもちろん onExit の処理の中でワークフローが成功した時と失敗した時で処理を分岐させることも可能です # େࣄͳϫʔΫϑϩʔʹ͸ඞͣ exit-handler Λઃఆ͠·͠ΐ͏ ... spec: entrypoint: main onExit: exit-handler templates: - name: main steps: - - name: hello template: hello - name: hello container: image: alpine:latest command: [sh, -c] args: ["echo hello"] - name: exit-handler steps: - - name: webhook when: "{{workflow.status}} != Succeeded" template: slack-post - name: slack-post container: image: curlimages/curl command: [sh, -c] args: ["curl -XPOST -d 'payload={....}'"]

処理の途中で一旦止めて、確認が済んだら続きを開始したい steps の中に suspend を入れることで実現できます「Suspend: {}」とすることで無限 sleep 状態処理を再開させるには UI では RESUME をクリックしますコマンドラインで再開させるには「argo resume <ワークフロー名>」を実行します # approve ॲཧΛೖΕΔ ... - name: main steps: - - name: hello template: whalesay - - name: need-approve template: need-approve - - name: after-approve template: whalesay - name: need-approve suspend: {} - name: whalesay container: image: docker/whalesay command: [cowsay] args: ["hello world”] ...

CloudNative Days Tokyo 2021 | @makocchi # approve ॲཧΛೖΕΔ ...
- name: main steps: - - name: hello template: whalesay - - name: need-approve template: need-approve - - name: after-approve template: whalesay - name: need-approve suspend: {} - name: whalesay container: image: docker/whalesay command: [cowsay] args: ["hello world”] ... 79 Kind: Workflow の書き方処理の途中で一旦止めて、確認が済んだら続きを開始したい steps の中に suspend を入れることで実現できます処理を再開させるには UI では RESUME をクリックしますコマンドラインで再開させるには「argo resume <ワークフロー名>」を実行します RESUME

処理の途中で一旦止めるんだけど一定時間経ったら自動で進めたい、もしくは明示的に間隔を空けたい場合は suspend で duration を設定しますもちろん duration の時間が過ぎる前に RESUME で進めることも可能です # Ұఆ࣌ؒܦͬͨΒࣗಈͰ approve ͯ͠ਐΉ ... - name: main steps: - - name: hello template: whalesay - - name: 1min-sleep template: 1min-sleep - - name: after-approve template: whalesay - name: 1min-sleep suspend: duration: 1m - name: whalesay container: image: docker/whalesay command: [cowsay] args: ["hello world”] ...

GitHub や S3 からアプリケーションのソースを入手して処理させたい inputs.artifacts を使うことで簡単にコンテナ内部にソースを持ってくることができます「git」の他に「s3」や「http」があります http は例えば GitHub のリリースからバイナリを落としてきて配置する、みたいな時に便利です # git ͔Β clone ͢Δͷ΋ָͪΜ ... - name: main steps: - - name: git-clone template: git-clone - name: git-clone inputs: artifacts: - name: argo-source path: /src git: repo: https://github.com/argoproj/argo-workflows.git revision: "master" container: image: alpine:latest command: [sh, -c] args: ["ls -l /src”] ...

ちなみに http を使った例はこんな感じになります # ϦϞʔτʹ͋ΔόΠφϦΛ഑ஔ͢Δͷ΋ָͪΜ ... - name: main steps: - - name: place-kubectl template: place-kubectl - name: place-kubectl inputs: artifacts: - name: kubectl path: /usr/local/bin/kubectl mode: 0755 http: url: https://storage.googleapis.com/kubernetes-release/release/v1.22.2/bin/linux/amd64/kubectl container: image: alpine:latest command: [sh, -c] args: ["/usr/local/bin/kubectl version --client”] ...

バックグラウンドでずっとアプリケーションを起動させておいて、各処理からアクセスさせたいそんな時は daemon を true にすることでワークフローが処理されている間ずっと動かし続けることができます ⏩ の例は Nginx ですが、データベースを起動させておいて各種テストを走らせる、とかの用途にも適していると思います # daemon Ͱىಈͬ͠ͺͳ͠Λ࣮ݱ ... - name: main steps: - - name: nginx-server template: nginx-server - - name: nginx-client template: nginx-client arguments: parameters: - name: server-ip value: "{{steps.nginx-server.ip}}" - name: nginx-server daemon: true container: image: nginx:1.21 readinessProbe: httpGet: path: / port: 80 initialDelaySeconds: 2 timeoutSeconds: 1 ...

生成したファイルを次の処理に渡したい処理間でファイルのやりとりをする方法はいくつか考えられます result で渡していく (ただしバイナリの時に使うことができない) ボリュームを作成して各処理で mount して使い回す artifact を使う

生成したファイルを次の処理に渡したい処理間でファイルのやりとりをする方法はいくつか考えられます result で渡していく (ただしバイナリの時に使うことができない) ボリュームを作成して各処理で mount して使い回す artifact を使う # volumeClaimTemplates Ͱ volume Λ࡞Δ ... spec: entrypoint: main volumeClaimTemplates: - metadata: name: workdir spec: accessModes: ["ReadWriteOnce"] resources: requests: storage: 1Gi templates: - name: main steps: ... volume を定義する

生成したファイルを次の処理に渡したい処理間でファイルのやりとりをする方法はいくつか考えられます result で渡していく (ただしバイナリの時に使うことができない) ボリュームを作成して各処理で mount して使い回す artifact を使う # volumeClaimTemplates Ͱ volume Λ࡞Δ ... spec: entrypoint: main volumeClaimTemplates: - metadata: name: workdir spec: accessModes: ["ReadWriteOnce"] resources: requests: storage: 1Gi templates: - name: main steps: ... # ͋ͱ͸࡞ΒΕͨ volume Λ mount ͯ͠࢖͏͚ͩʂ ... - name: main steps: - - name: generate template: whalesay - - name: print template: print-message - name: whalesay container: image: docker/whalesay:latest command: [sh, -c] args: ["cowsay hello | tee /mnt/vol/hello_world.txt"] volumeMounts: - name: workdir mountPath: /mnt/vol - name: print-message container: image: alpine:latest command: [sh, -c] args: ["cat /mnt/vol/hello_world.txt"] volumeMounts: - name: workdir mountPath: /mnt/vol ... 各処理で mount Claim された volume はワークフローを消すと消える

生成したファイルを次の処理に渡したい処理間でファイルのやりとりをする方法はいくつか考えられます result で渡していく (ただしバイナリの時に使うことができない) ボリュームを作成して各処理で mount して使い回す artifact を使う s3 互換のオブジェクトストレージを使うことができます # artifact Λ configMap Ͱઃఆ͢Δ apiVersion: v1 kind: ConfigMap metadata: name: artifact-repositories data: minio-artifact: | s3: bucket: my-bucket endpoint: argo-artifacts:9000 insecure: true accessKeySecret: name: argo-artifacts key: accesskey secretKeySecret: name: argo-artifacts key: secretkey 例としてクラスター内の minio を使ってみます

生成したファイルを次の処理に渡したい処理間でファイルのやりとりをする方法はいくつか考えられます result で渡していく (ただしバイナリの時に使うことができない) ボリュームを作成して各処理で mount して使い回す artifact を使う s3 互換のオブジェクトストレージを使うことができます # artifact Λઃఆ͢Δ apiVersion: v1 kind: ConfigMap metadata: name: artifact-repositories data: default-v1: | s3: bucket: my-bucket endpoint: argo-artifacts:9000 insecure: true accessKeySecret: name: argo-artifacts key: accesskey secretKeySecret: name: argo-artifacts key: secretkey # ઌఔઃఆͨ͠ configMap Λࢀরͤ͞Δ ... spec: artifactRepositoryRef: configMap: artifact-repositories key: minio-artifact entrypoint: main templates: - name: main ...

生成したファイルを次の処理に渡したい処理間でファイルのやりとりをする方法はいくつか考えられます result で渡していく (ただしバイナリの時に使うことができない) ボリュームを作成して各処理で mount して使い回す artifact を使う s3 互換のオブジェクトストレージを使うことができます # artifact Λઃఆ͢Δ apiVersion: v1 kind: ConfigMap metadata: name: artifact-repositories data: default-v1: | s3: bucket: my-bucket endpoint: argo-artifacts:9000 insecure: true accessKeySecret: name: argo-artifacts key: accesskey secretKeySecret: name: argo-artifacts key: secretkey # ͋ͱ͸ step ͷॲཧʹ artifacts Λઃఆ͢Δ͜ͱͰ࢖͏͜ͱ͕Ͱ͖Δ ... - name: main steps: - - name: generate-artifact template: whalesay - - name: consume-artifact template: print-message arguments: artifacts: - name: message from: “{{steps.generate-artifact.outputs.artifacts.hello-art}}" - name: whalesay serviceAccountName: workflow-sa container: image: docker/whalesay command: [sh, -c] args: ["sleep 1; cowsay hello world | tee /tmp/hello_world.txt"] outputs: artifacts: - name: hello-art path: /tmp/hello_world.txt - name: print-message serviceAccountName: workflow-sa container: image: alpine:latest command: [sh, -c] args: ["cat /tmp/message"] inputs: artifacts: - name: message path: /tmp/message ...

CloudNative Days Tokyo 2021 | @makocchi # ͋ͱ͸ step ͷॲཧʹ
artifacts Λઃఆ͢Δ͜ͱͰ࢖͏͜ͱ͕Ͱ͖Δ ... - name: main steps: - - name: generate-artifact template: whalesay - - name: consume-artifact template: print-message arguments: artifacts: - name: message from: “{{steps.generate-artifact.outputs.artifacts.hello-art}}" - name: whalesay serviceAccountName: workflow-sa container: image: docker/whalesay command: [sh, -c] args: ["sleep 1; cowsay hello world | tee /tmp/hello_world.txt"] outputs: artifacts: - name: hello-art path: /tmp/hello_world.txt - name: print-message serviceAccountName: workflow-sa container: image: alpine:latest command: [sh, -c] args: ["cat /tmp/message"] inputs: artifacts: - name: message path: /tmp/message ... 92 Kind: Workflow の書き方生成したファイルを次の処理に渡したい処理間でファイルのやりとりをする方法はいくつか考えられます result で渡していく (ただしバイナリの時に使うことができない) ボリュームを作成して各処理で mount して使い回す artifact を使う s3 互換のオブジェクトストレージを使うことができます minio の中に格納されてる

ワークフロー全体で使える変数を定義したいワークフローのパラメーターを使うことで実現することができますパラメーターの設定の仕方はいくつかありますベタ書きで定義する(オーバーライド可) configMap から参照して定義するワークフローのラベルから定義する

ワークフロー全体で使える変数を定義したいワークフローのパラメーターを使うことで実現することができますパラメーターの設定の仕方はいくつかありますベタ書きで定義する(オーバーライド可) configMap から参照して定義するワークフローのラベルから定義する # άϩʔόϧม਺ͷఆٛͷ࢓ํ ... spec: entrypoint: main arguments: parameters: - name: message value: “hello world” templates: - name: main steps: - - name: whalesay template: whalesay - name: whalesay container: image: docker/whalesay command: [cowsay] args: ["{{workflow.parameters.message}}"] argo submit する時に「--parameter message=hoge」とすることで上書き可能

ワークフロー全体で使える変数を定義したいワークフローのパラメーターを使うことで実現することができますパラメーターの設定の仕方はいくつかありますベタ書きで定義する(オーバーライド可) configMap から参照して定義するワークフローのラベルから定義する # άϩʔόϧม਺ͷఆٛͷ࢓ํ ... spec: entrypoint: main arguments: parameters: - name: message valueFrom: configMapKeyRef: name: simple-parameters key: msg templates: - name: main steps: - - name: whalesay template: whalesay - name: whalesay container: image: docker/whalesay command: [cowsay] args: ["{{workflow.parameters.message}}"]

CloudNative Days Tokyo 2021 | @makocchi # άϩʔόϧม਺ͷఆٛͷ࢓ํ ... spec:
entrypoint: main arguments: parameters: - name: message valueFrom: configMapKeyRef: name: simple-parameters key: msg templates: - name: main steps: - - name: whalesay template: whalesay - name: whalesay container: image: docker/whalesay command: [cowsay] args: ["{{workflow.parameters.message}}"] 96 Kind: Workflow の書き方ワークフロー全体で使える変数を定義したいワークフローのパラメーターを使うことで実現することができますパラメーターの設定の仕方はいくつかありますベタ書きで定義する(オーバーライド可) configMap から参照して定義するワークフローのラベルから定義する # configMap ଆͷઃఆ apiVersion: v1 kind: ConfigMap metadata: labels: workflows.argoproj.io/configmap-type: Parameter data: msg: from-configmap この configmap-type のラベルが無いとコントローラーが認識してくれない必須

ワークフロー全体で使える変数を定義したいワークフローのパラメーターを使うことで実現することができますパラメーターの設定の仕方はいくつかありますベタ書きで定義する(オーバーライド可) configMap から参照して定義するワークフローのラベルから定義する # labels Λ௚઀ࢀর͢Δύλʔϯ apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: global-parameters3 labels: message-from-labels: hoge spec: entrypoint: main templates: - name: main steps: - - name: whalesay template: whalesay - name: whalesay container: image: docker/whalesay command: [cowsay] args: ["{{workflow.labels.message-from-labels}}"] argo submit する時に「--labels message-from-labels=foo」とすることで上書き可能

ワークフローの同時実行数を制御して同時に動かないようにしたいワークフローが同時に実行されてしまうと不都合な場合ってありますよねその場合には同時実行数を制御しておくとより安全に運用できます制御するには synchronization を使い、方式は 2 つあります semaphore による制御 mutex による制御

ワークフローの同時実行数を制御して同時に動かないようにしたいワークフローが同時に実行されてしまうと不都合な場合ってありますよねその場合には同時実行数を制御しておくとより安全に運用できます制御するには synchronization を使い、方式は 2 つあります semaphore による制御 mutex による制御 # ಉ࣮࣌ߦ੍ޚ apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: synchronization-wf-level spec: entrypoint: main synchronization: semaphore: configMapKeyRef: name: my-semaphore key: workflow templates: - name: main steps: - - name: whalesay template: whalesay - name: whalesay container: image: docker/whalesay command: [cowsay] args: ["hello world”] semaphore の場合は configMap を指定する

ワークフローの同時実行数を制御して同時に動かないようにしたいワークフローが同時に実行されてしまうと不都合な場合ってありますよねその場合には同時実行数を制御しておくとより安全に運用できます制御するには synchronization を使い、方式は 2 つあります semaphore による制御 mutex による制御 # ಉ࣮࣌ߦ੍ޚ apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: synchronization-wf-level spec: entrypoint: main synchronization: semaphore: configMapKeyRef: name: my-semaphore key: workflow templates: - name: main steps: - - name: whalesay template: whalesay - name: whalesay container: image: docker/whalesay command: [cowsay] args: ["hello world”] # semaphore ༻ͷ configMap apiVersion: v1 kind: ConfigMap metadata: name: my-semaphore data: workflow: "1" この場合は同時 1 まで

ワークフローの同時実行数を制御して同時に動かないようにしたいワークフローが同時に実行されてしまうと不都合な場合ってありますよねその場合には同時実行数を制御しておくとより安全に運用できます制御するには synchronization を使い、方式は 2 つあります semaphore による制御 mutex による制御 # ಉ࣮࣌ߦ੍ޚ apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: synchronization-wf-level spec: entrypoint: main synchronization: semaphore: configMapKeyRef: name: my-semaphore key: workflow templates: - name: main steps: - - name: whalesay template: whalesay - name: whalesay container: image: docker/whalesay command: [cowsay] args: ["hello world”] # semaphore ༻ͷ configMap apiVersion: v1 kind: ConfigMap metadata: name: my-semaphore data: workflow: "1" 1 つ実行中なので Waiting になってる

ワークフローの同時実行数を制御して同時に動かないようにしたいワークフローが同時に実行されてしまうと不都合な場合ってありますよねその場合には同時実行数を制御しておくとより安全に運用できます制御するには synchronization を使い、方式は 2 つあります semaphore による制御 mutex による制御 # ಉ࣮࣌ߦ੍ޚ apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: synchronization-wf-level spec: entrypoint: main synchronization: mutex: name: my-mutex templates: - name: main steps: - - name: whalesay template: whalesay - name: whalesay container: image: docker/whalesay command: [cowsay] args: ["hello world”]

semaphore と mutex どっちがいいのか semaphore の場合は configMap で柔軟に同時実行数を設定可能 mutex の場合は同時に 1 しか制御できない mutex は workflow-controller のメモリ上で管理されているので、1 つのワークフローが実行中に workflow-controller が再起動した場合は pending になっているワークフローが同時に実行されてしまうリスクがあります # Ͳ͕͍͍ͬͪͷ͔ʁ ... synchronization: mutex: name: my-mutex ... synchronization: semaphore: configMapKeyRef: name: my-semaphore key: workflow ... 個人的には・・ semaphore かなぁ

渡されたパラメーターを加工したい、json から特定の key の value を取り出したい等あると思いますその時は組み込みの関数や sprig を使って加工・抽出が可能です組み込みの関数を使う場合は {{ の部分を {{= にする必要があります全ての箇所で対応しているわけではないので注意が必要 ؔ਺ આ໌ asInt จࣈྻΛ Int ʹม׵͢Δ asFloat จࣈྻΛ Float ʹม׵͢Δ string Int/Float Λจࣈྻʹม׵͢Δ jsonpath Json ͔ΒΤϨϝϯτΛநग़͢Δ sprig Λ࢖ͬͨهड़ http://masterminds.github.io/sprig/

例えば asInt を使うとこんな感じに書くことができます parameter で渡されるのは全て文字列扱いになるので、int に変換しないと計算できません # ྫ(asInt) # parameter Λ 10 ഒͯ͠౉͢ ... templates: - name: main steps: - - name: multiple template: whalesay arguments: parameters: - name: foo value: "1" - name: whalesay inputs: parameters: - name: foo container: image: docker/whalesay:latest command: [cowsay] args: ["{{=asInt(inputs.parameters.foo) * 10}}"

jsonpath を使うと json の扱いが楽になります # ྫ(jsonpath) ... spec: entrypoint: main arguments: parameters: - name: config value: '{"key": “abcdef"}' templates: - name: main steps: - - name: jsonpath template: whalesay arguments: parameters: - name: foo value: "{{=jsonpath(workflow.parameters.config, '$.key')}}" ... パラメーターとして抽出された abcdef が渡される

sprig は更にいろいろ柔軟に加工できます # ྫ(sprig) ... spec: entrypoint: main arguments: parameters: - name: config value: '{"key": “dmFsdWU="}' templates: - name: main steps: - - name: jsonpath template: whalesay arguments: parameters: - name: foo value: "{{=sprig.upper(sprig.b64dec(jsonpath(workflow.parameters.config, ‘$.key')))}}" ... Base64 でデコードしてさらに大文字にしちゃう例

sprig は記述が長くなりがちなのでこんな感じで書いても大丈夫です # ྫ(sprig) ... - name: main steps: - - name: jsonpath template: whalesay arguments: parameters: - name: foo value: >- {{= sprig.upper( sprig.b64dec( jsonpath(workflow.parameters.config, '$.key') ) ) }} ... 縦に長くなっちゃいますが分かりやすいかもですね

他にも色々できますちなみに sprig の記述をミスると value にはそのままの文字列({{=...}})が渡ってしまいますので気を付けて下さい(特にエラーになるわけではない) # ྫ(sprig) # ϥϯμϜͳจࣈྻɾ਺ࣈΛੜ੒͢Δ (Ҿ਺͸จࣈ਺) value: “{{=sprig.randAscii(10)}}" # => @‘yCH_Lbs value: “{{=sprig.randAlpha(10)}}" # => XnNXvYqZea value: “{{=sprig.randNumeric(10)}}" # => 6909735364 value: “{{=sprig.randAlphaNum(10)}}" # => tCZDhEXb1c # ࣌ࠁͷૢ࡞ value: "{{=sprig.dateModify('-3h', sprig.now())}}” # => 3 ࣌ؒલ # Trim value: "{{=sprig.trim(' hoge ‘)}}" # => ‘hoge’ value: "{{=sprig.trimSuffix('.txt', ‘hoge.txt')}}" # => ‘hoge’ value: “{{=sprig.trimPrefix('my-', ‘my-hoge.txt’)}}” # => ‘hoge.txt’

CloudNative Days Tokyo 2021 | @makocchi 110 ワークフローのテンプレートを使って効率よく管理しよう

CloudNative Days Tokyo 2021 | @makocchi 111 ワークフローのテンプレートを使おうワークフローテンプレートを定義することで、定義を再利用して使うことが可能です (Steps
内で使う template の定義ではなくて、ワークフロー自体をテンプレート化する) カスタムリソースとして「kind: WorkflowTemplate」を使って定義します spec の内容は「kind: Workflow」と同じなので kind をリネームするだけでテンプレート化が完了しますワークフロー側からテンプレートを呼び出す時には templateRef でテンプレートを指定しますちなみに WorkflowTemplate は argo submit できない(無視される)・・・ので kubectl で作る必要があります

CloudNative Days Tokyo 2021 | @makocchi 112 こんなワークフローの場合 # ΋ͱͷఆٛ
apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: whalesay-original spec: entrypoint: main templates: - name: main steps: - - name: whalesay template: whalesay arguments: parameters: - name: message value: hoge - name: whalesay inputs: parameters: - name: message container: image: docker/whalesay command: [cowsay] args: ["{{inputs.parameters.message}}"] ワークフローのテンプレートを使おう

CloudNative Days Tokyo 2021 | @makocchi 113 こんなワークフローの場合こうなる # ΋ͱͷఆٛ
apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: whalesay-original spec: entrypoint: main templates: - name: main steps: - - name: whalesay template: whalesay arguments: parameters: - name: message value: hoge - name: whalesay inputs: parameters: - name: message container: image: docker/whalesay command: [cowsay] args: ["{{inputs.parameters.message}}"] # ςϯϓϨʔτݺͼग़͠ apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: hello-world-from-template spec: workflowTemplateRef: name: whalesay-template # ςϯϓϨʔτԽ apiVersion: argoproj.io/v1alpha1 kind: WorkflowTemplate metadata: name: whalesay-template spec: entrypoint: main templates: - name: main steps: - - name: whalesay template: whalesay arguments: parameters: - name: message value: hoge - name: whalesay inputs: parameters: - name: message container: image: docker/whalesay command: [cowsay] args: ["{{inputs.parameters.message}}"] ワークフローの定義はシンプルになるワークフローのテンプレートを使おう

CloudNative Days Tokyo 2021 | @makocchi 114 いったいテンプレート化に旨味はあるのでしょうか？同じような処理をパラメーターだけ変えて処理させたい場合にはとても有効ですまたテンプレートは
CronWorkflow からも参照することができます CronWorkflow を手動でも実行できるように Workflow としても定義しておきたい、なんて場合には同じテンプレートを参照するだけなので楽に実現できる WorkflowTemplate は namespaced なリソースですが、WorkflowTemplate と同じものとして ClusterWorkflowTemplate も同じ使い方で使うことができます workflowTemplateRef をする時に「clusterScope: true」を設定するだけで使えます ClusterWorkflowTemplate を定義することで、namespace をまたいでテンプレートを使い回すことが可能になりますワークフローのテンプレートを使おう

CloudNative Days Tokyo 2021 | @makocchi 115 こんなイメージ WorkflowTemplate A
Workflow A namespace foo Parameter: A Workflow A’ Workflow A’’ Parameter: B Parameter: C CronWorkflow A Parameter: A ワークフローのテンプレートを使おう

CloudNative Days Tokyo 2021 | @makocchi 116 こんなイメージ ClusterWorkflowTemplate A
Workflow A namespace foo Parameter: A Workflow A’ namespace bar Parameter: B Workflow A’’ namespace buz Param eter: C namespace をまたいで使うことが可能ワークフローのテンプレートを使おう

CloudNative Days Tokyo 2021 | @makocchi 117 いやいやいや　この部分だけテンプレート化したいよそしたらワークフローでは処理の依存関係
を、テンプレートでは処理内容という風に分離して管理できるでしょ？ # ॲཧ಺༰͚ͩςϯϓϨʔτԽ͍ͤͨ͞ apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: whalesay-original spec: entrypoint: main templates: - name: main steps: - - name: whalesay template: whalesay arguments: parameters: - name: message value: hoge - name: whalesay inputs: parameters: - name: message container: image: docker/whalesay command: [cowsay] args: ["{{inputs.parameters.message}}"] ここだけ抜き出したい！ワークフローのテンプレートを使おう

CloudNative Days Tokyo 2021 | @makocchi 118 もちろんできます！ steps 内からも
templateRef で指定可能です呼び出すテンプレートは name で指定します name で指定したテンプレート内のどの template を使うのかを template で指定しますもちろん「clusterScope: true」も設定可能 # ॲཧ಺༰͚ͩςϯϓϨʔτԽ͍ͤͨ͞ apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: whalesay-original spec: entrypoint: main templates: - name: main steps: - - name: whalesay templateRef: name: whalesay-step-template template: whalesay arguments: parameters: - name: message value: hoge ワークフローのテンプレートを使おう実際のテンプレート名はどっちに書いたら良いんだ問題ちょっと分かりにくい

CloudNative Days Tokyo 2021 | @makocchi 119 もちろんできます！ steps 内からも
templateRef で指定可能です呼び出すテンプレートは name で指定します name で指定したテンプレート内のどの template を使うのかを template で指定しますもちろん「clusterScope: true」も設定可能 # ॲཧ಺༰͚ͩςϯϓϨʔτԽ͍ͤͨ͞ apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: whalesay-original spec: entrypoint: main templates: - name: main steps: - - name: whalesay templateRef: name: whalesay-step-template template: whalesay arguments: parameters: - name: message value: hoge ワークフローのテンプレートを使おう実際のテンプレート名はどっちに書いたら良いんだ問題ちょっと分かりにくい # ͜͏͍͏͜ͱ apiVersion: argoproj.io/v1alpha1 kind: WorkflowTemplate metadata: name: whalesay-step-template spec: templates: - name: whalesay inputs: parameters: - name: message value: hogehoge container: image: docker/whalesay command: [cowsay] args: ["{{inputs.parameters.message}}"]

CloudNative Days Tokyo 2021 | @makocchi 120 より柔軟に管理できるようになりますね！ WorkflowTemplate A
Workflow A namespace foo Parameter: A ワークフローのテンプレートを使おう ClusterWorkflowTemplate A ClusterWorkflowTemplate B よく使うような処理、例えば onExit で使う「ワークフローの結果を slack に通知する」を ClusterWorkflowTemplate にしておけばいろいろなワークフローに仕込むのが簡単になります

CloudNative Days Tokyo 2021 | @makocchi 121 ワークフローを定期実行したい

CloudNative Days Tokyo 2021 | @makocchi 122 定期的に実行させたい(Cron)場合は CronWorkflowTemplate で定義すること
ができます workflowSpec に処理内容を書きます Kubernetes の batch/v1 Cronjob の定義でできるような項目(concurrentPolicy や startingDeadlineSeconds など)は同じように設定可能 # Cronͷఆٛ apiVersion: argoproj.io/v1alpha1 kind: CronWorkflow metadata: name: hello-world spec: schedule: "* * * * *" timezone: "Asia/Tokyo" startingDeadlineSeconds: 0 concurrencyPolicy: “Forbid" successfulJobsHistoryLimit: 4 failedJobsHistoryLimit: 4 suspend: false workflowSpec: entrypoint: whalesay templates: - name: whalesay container: image: docker/whalesay:latest command: [cowsay] args: ["Scheduled on: {{workflow.scheduledTime}}"] ワークフローの定期実行

CloudNative Days Tokyo 2021 | @makocchi 123 Cron の手動実行は「argo submit
--from cronwf/<cronwf の名前>」可能です debug 処理を仕込んでおいて、「argo submit --from cronwf/mycron -- parameter debug=true」みたいにするといいかもしれませんもちろん workflowSpec ではテンプレートを呼び出すこともできます既存の cronjob を移行してみてはいかがでしょうか # Cronͷఆٛ apiVersion: argoproj.io/v1alpha1 kind: CronWorkflow metadata: name: hello-world spec: schedule: "* * * * *" timezone: "Asia/Tokyo" startingDeadlineSeconds: 0 concurrencyPolicy: “Forbid" successfulJobsHistoryLimit: 4 failedJobsHistoryLimit: 4 suspend: false workflowSpec: entrypoint: whalesay workflowTemplateRef: name: whalesay-template arguments: parameters: - name: message value: hogehoge ワークフローの定期実行

CloudNative Days Tokyo 2021 | @makocchi 124 イベントを検知してワークフローを実行させたい

CloudNative Days Tokyo 2021 | @makocchi 125 イベントをきっかけにワークフローを実行させることができれば、いろいろなシステムとの連携が用意になりますワークフローからワークフローへ連携させるようなことも可能になります
やりかたはいろいろあると思いますが、ここでは下記の 2 つの方法を紹介しますイベントを検知してワークフローを実行させたい Argo Events WorkflowEventBinding

CloudNative Days Tokyo 2021 | @makocchi 126 WorkflowEventBinding は Argo
Workflows の中に組み込まれている Webhook の仕組みです API のエンドポイントに対し、「argo auth token」の token (もしくはサービスアカウントの token）を使って POST することで特定のテンプレートを実行させることが可能になりますちなみに WorkflowEventBinding は定義すると UI からも確認できますイベントを検知してワークフローを実行させたい (WorkflowEventBinding)

CloudNative Days Tokyo 2021 | @makocchi 127 定義はこんな感じです discriminator はエンドポイント
の識別子に使いますどうやら workflow-controller と同じ namespace に定義しないと動かないぽいですなので発火させるテンプレートは同じ namespace 内か、 ClusterWorkflowTemplate にしないとダメそうです # WorkflowEventBinding ͷఆٛ apiVersion: argoproj.io/v1alpha1 kind: WorkflowEventBinding metadata: name: event-consumer namespace: argo spec: event: selector: payload.message != "" && discriminator == "whalesay-hook" submit: workflowTemplateRef: name: whalesay-param-template arguments: parameters: - name: message valueFrom: event: payload.message イベントを検知してワークフローを実行させたい (WorkflowEventBinding) workflow-controller と同じ namespace にする

CloudNative Days Tokyo 2021 | @makocchi 128 定義はこんな感じです discriminator はエンドポイント
の識別子に使いますどうやら workflow-controller と同じ namespace に定義しないと動かないぽいですなので発火させるテンプレートは同じ namespace 内か、 ClusterWorkflowTemplate にしないとダメそうです # WorkflowEventBinding ͷఆٛ apiVersion: argoproj.io/v1alpha1 kind: WorkflowEventBinding metadata: name: event-consumer namespace: argo spec: event: selector: payload.message != "" && discriminator == "whalesay-hook" submit: workflowTemplateRef: name: whalesay-param-template arguments: parameters: - name: message valueFrom: event: payload.message イベントを検知してワークフローを実行させたい (WorkflowEventBinding) # event Λ hook ͢Δͱ࣮ߦ͞ΕΔ͸ͣ # (argo-server ʹରͯ͠ port-forward ͍ͯ͠Δ৔߹͸ localhost:2746 ʹͳΓ·͢) $ curl -sk https://localhost:2746/api/v1/events/argo/whalesay-hook -H "Authorization: $TOKEN" -d '{"message": "hello events”}’ # discliminator Λ࢖༻͠ͳ͍৔߹ $ curl -sk https://localhost:2746/api/v1/events/argo -H "Authorization: $TOKEN" -d '{"message": "hello events”}’

CloudNative Days Tokyo 2021 | @makocchi 129 Argo Events は
Argo ファミリーの1つで、様々なイベントを検知してアクションを実行させることができるソフトウェアになります Webhook はもちろん、例えば Pub/Sub や SNS を subscribe してイベント発火させることができます同じ Argo ファミリーということもあって、連携はしやすい作りになっていると思いますイベントを検知してワークフローを実行させたい (Argo Events) https://argoproj.github.io/argo-events/sensors/triggers/argo-workﬂow/

CloudNative Days Tokyo 2021 | @makocchi 130 Argo Events では「EventSource」でウォッチする
イベント(Pub/Sub や SNS や Lambda 等)を定義します「EventSource」で検知したものは「Sensor」でトリガーされます「EventSource」と「Sensor」のやりとりには「EventBus」が使われます(NATS streaming) イベントを検知してワークフローを実行させたい (Argo Events) https://argoproj.github.io/argo-events/sensors/triggers/argo-workﬂow/

CloudNative Days Tokyo 2021 | @makocchi 131 例えば Pub/Sub を
EventSource にする場合はこんな感じで定義しておきます GCP の project や subscribe する topic を指定します Workload Identity を使わない場合は credentialSecret のフィールドが必要になりますイベントを検知してワークフローを実行させたい (Argo Events) # EventSource ͷఆٛ (Pub/Sub) apiVersion: argoproj.io/v1alpha1 kind: EventSource metadata: name: pubsub-event-source spec: pubSub: my-pubsub: jsonBody: true projectID: my-gcp-project topic: my-pubusub-topic subscriptionID: my-pubsub-subscription

CloudNative Days Tokyo 2021 | @makocchi 132 一方で Sensor からワークフローを実行させる定義
はこんな感じで定義します dependencies に先程定義した EventSource の情報を指定しますなお filter を使って細かい条件の判定や複数の EventSource を使う等可能です実際のワークフローの定義は triggers 内で行いますここでの定義をスッキリさせるために、テンプレート化しておいて workflowTemplateRef で参照させるのがいいと思いますイベントを検知してワークフローを実行させたい (Argo Events) # Sensor ͷఆٛ apiVersion: argoproj.io/v1alpha1 kind: Sensor metadata: name: my-sensor spec: dependencies: - name: my-dep eventSourceName: pubsub-event-source eventName: my-pubsub triggers: - template: name: workflow-from-pubsub argoWorkflow: operation: submit source: resource: apiVersion: argoproj.io/v1alpha1 kind: Workflow ... 先程の EventSource 情報ワークフローの実体

CloudNative Days Tokyo 2021 | @makocchi 133 その他の(役に立つかもしれない) Tips

CloudNative Days Tokyo 2021 | @makocchi 134 その他の(役に立つかもしれない)Tips 内部で使われる containerRuntimeExecutor
について Argo Workflows では Pod の処理や log の取得等の内部的な処理を containerRuntimeExecutor という概念で実装していますこの containerRuntimeExecutor には種類があり、デフォルトでは「docker executor」が設定されていますどの containerRuntimeExecutor が実行されているかは、起動された Pod 内の wait というコンテナのログを見ることで確認できます最近 Kubernetes では Dockerd ではなく、containerd を kubelet のランタイムとして設定してあるケースも増えてきていると思います containerd が使用されている場合、このデフォルトの「docker executor」ではうまくワークフローは動いてくれません

について containerRuntimeExecutor にはいくつか種類があり、workflow-controller の設定で変更が可能です containerRuntimeExecutor 特徴 docker deprecated / 3.2 までのデフォルト k8sapi いくつかの機能制限あり / 大規模環境に適さない kubelet いくつかの機能制限あり / 大規模環境に適さない pns Windows 環境で動かない emissary 出てきて間もないが大規模環境にも対応できる / 3.3 からデフォルト

について結局どれつかえばいいの？ Argo Workflows のバージョンが新しい(v3.1.0 以降)であれば emissary でいいと思いますもし古いバージョンを使っているのなら新しくしたほうが良いでしょうなんかワークフローが上手く動かない(いつまで経っても Pod が正常に終わらない、とか)場合は executor を変えることで解決する場合があります

についてわかったわかったではどうやって設定するの？ Argo Workflows が参照する configMap で設定します例えば「containerRuntimeExecutor: emissary」もし記述されていない場合はデフォルトの executor になっています(docker) # ࠓͷઃఆΛ֬ೝ͢Δ # ΋͠Կ΋ग़ͯ͜ͳ͚Ε͹σϑΥϧτ͕࢖ΘΕ͍ͯΔ $ kubectl get configmap -n argo workflow-controller-configmap -o yaml | grep containerRuntimeExecutor containerRuntimeExecutor: emissary

についてワークフロー毎に containerRuntimeExecutor を選択できるようにしたい場合はラベルによって切り替えるようにすることも可能です # workflow-controller ͕ࢀর͍ͯ͠Δ configMap Ͱͷઃఆ߲໨ # containerRuntimeExecutor ͱ containerRuntimeExecutors Ͱҧ͏ͷͰ஫ҙ containerRuntimeExecutors: | - name: emissary selector: matchLabels: workflows.argoproj.io/container-runtime-executor: emissary - name: docker selector: matchLabels: workflows.argoproj.io/container-runtime-executor: docker

についてワークフロー毎に containerRuntimeExecutor を選択できるようにしたい場合はラベルによって切り替えるようにすることも可能です # workflow-controller ͕ࢀর͍ͯ͠Δ configMap Ͱͷઃఆ߲໨ # containerRuntimeExecutor ͱ containerRuntimeExecutors Ͱҧ͏ͷͰ஫ҙ containerRuntimeExecutors: | - name: emissary selector: matchLabels: workflows.argoproj.io/container-runtime-executor: emissary - name: docker selector: matchLabels: workflows.argoproj.io/container-runtime-executor: docker # ͜ΕͰ੾Γସ͑์୊ʹͳΓ·͢ # ྫ͑͹ submit ͢Δ࣌ʹ͸ --labels Ͱࢦఆ͠·͢ $ argo submit hello-world.yaml --labels workflows.argoproj.io/container-runtime-executor=docker # Workflow ͷఆٛʹ label Λ෇༩͓ͯ͘͠Ͱ΋͍͍Ͱ͠ΐ͏ apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: labels: workflows.argoproj.io/container-runtime-executor: docker ...

CloudNative Days Tokyo 2021 | @makocchi 140 その他の(役に立つかもしれない)Tips ワークフロー全体で実行数を制限しておくなにかの拍子でワークフローが大量に🔥爆誕🔥してしまってリソースが食いつぶされた・・なん
てことの無いようにしておくといいかもしれません workflow-controller の下記の設定を調整しておくといいでしょうしきい値を超えたワークフローは Pending になります ઃఆ߲໨ 特徴 parallelism workflow-controller が実行できるワークフローの同時実行数 namespaceParallelism namespace のワークフローの同時実行数 resourceRateLimit limit と burst の値があり Pod の数を制御する

CloudNative Days Tokyo 2021 | @makocchi 141 その他の(役に立つかもしれない)Tips ワークフローのメトリクスを取得するメトリクスは
workflow-controller の port 9090 で取得可能です (Prometheus 形式) grafana のダッシュボードも用意されています https://github.com/argoproj/argo-workﬂows/blob/master/examples/grafana-dashboard.json

CloudNative Days Tokyo 2021 | @makocchi 142 その他の(役に立つかもしれない)Tips ワークフローのテンプレートレベルのメトリクスを取得する Workflow
の spec でメトリクスの設定が可能です # ಠࣗͷϝτϦΫεͷઃఆ ... spec: metrics: prometheus: - name: exec_duration_gauge_hello_world labels: - key: name value: hello_world help: "hello_world duration gauge" gauge: value: "{{workflow.duration}}" entrypoint: main templates: - name: main steps: - - name: step1 template: whalesay ... # ಠࣗͷϝτϦΫεͱͯ͠ग़ͯ͘Δ ... # HELP argo_workflows_exec_duration_gauge_hello_world hello_world duration gauge # TYPE argo_workflows_exec_duration_gauge_hello_world gauge argo_workflows_exec_duration_gauge_hello_world{name="hello_world"} 10.548116 ...

CloudNative Days Tokyo 2021 | @makocchi 143 Argo Workflows とは、ワークフローの処理をカスタムリソース
で管理することができるオープンソースのソフトウェア(再掲) テンプレートの概念を上手く使うことで効率よく管理できる本格的に運用する時は workflow-controller 側の設定項目をちゃんと把握しておくこと特に kubelet のランタイムが docker ではない人は containerRuntimeExecutor を変更することを忘れずに！君も今日から Argo Workflows 使いだ！本日のまとめ

CloudNative Days Tokyo 2021 使いこなせ！Argo Workflows @makocchi ご清聴ありがとうございました！

使いこなせ！Argo Workflows / How to use Argo Workflows

使いこなせ！Argo Workflows / How to use Argo Workflows

More Decks by makocchi

Other Decks in Technology

Featured

Transcript