WorkingDirectory icon
Clone icon
Commands icon
Docker icon
If icon
Log icon
Webhook icon

GitOps CI/CD to AWS EKS with Kaniko, ECR and Discord Alerts

Automate GitOps deployments to AWS EKS. Clone a repo, build with Kaniko, push to ECR, verify the rollout with kubectl and report the result to Discord.

Categories
CloudInfrastructure

Turn a Git push into a verified AWS EKS deployment without a CI server or a privileged Docker daemon. The flow builds the image with Kaniko in userspace, pushes it to Amazon ECR with an immutable per-execution tag, applies your manifests, waits for the rolling update and reports the outcome to Discord.

How it works

  1. The github_webhook trigger starts the flow on every push, and concurrency with QUEUE runs rapid pushes one at a time.
  2. clone_repository checks out git_repo at git_branch inside a WorkingDirectory.
  3. build_and_push_image runs the Kaniko executor and pushes <ecr_registry>/eks-gitops-deploy:<execution.id> to ECR.
  4. deploy_and_verify_rollout connects to EKS, injects the image tag and namespace into k8s/, applies the manifests and blocks on kubectl rollout status.
  5. check_discord_enabled (If) posts the success embed when the notify_discord input is true, otherwise it logs that it was skipped.
  6. If any task fails, the errors handler sends pod status, logs and cluster events to Discord.

What you get

  • Daemonless, unprivileged image builds.
  • One immutable image tag per execution, so each deployment maps to one Kestra run.
  • Discord alerts with the LoadBalancer URL on success and pod logs and events on failure.

Who it's for

  • Platform and DevOps engineers who want GitOps-style deploys on AWS EKS without a separate CI server.

Why orchestrate this with Kestra

A shell script can run the same commands, but it cannot queue overlapping pushes, keep a per-run history or route failures to a dedicated handler.

Prerequisites

  • An EKS cluster, an ECR repository named eks-gitops-deploy, and a Git repository with a Dockerfile and k8s/ manifests whose Deployment image is IMAGE_PLACEHOLDER.
  • A Kestra instance where the Docker task runner can run containers.

Secrets

Each can be a Kestra Secret or a KV pair.

  • AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY: credentials with ECR push and EKS access.
  • DEPLOY_WEBHOOK_KEY: any random string used as the last segment of the webhook URL.
  • DISCORD_WEBHOOK_URL: needed only when notify_discord is true.

Quick start

  1. Add the secrets above.
  2. Execute the flow with your git_repo, ecr_registry (host only), eks_cluster_name and aws_region.
  3. Optionally point a GitHub push webhook at the flow's webhook URL.

How to extend

  • Add a Parallel task to smoke-test the new LoadBalancer URL, or swap Discord for Slack with the matching plugin.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.