Build and Deploy Images to a vCenter Machine Fleet

A compact build-and-rollout pipeline for VM fleets. The flow clones application source, builds a Docker image, runs a validation step, then fans out deployment across a machine list fetched at runtime, capping parallel rollouts so you never take down more than a couple of hosts at once. The machine list, validation, and deployment steps are deliberate stubs marking exactly where your vCenter API, image scanner, and rollout mechanism plug in.

How it works

1. The getDeployMachinesListFromAPI task (io.kestra.plugin.core.output.OutputValues) provides a structured list of target machines (hostname, IP, owning service account); swap it for an io.kestra.plugin.core.http.Request against your vCenter or CMDB API.
2. The buildImages task (io.kestra.plugin.core.flow.WorkingDirectory) shares a filesystem between the clone and the build: cloneSourceCode (io.kestra.plugin.git.Clone) checks out main into src, and buildDockerImage (io.kestra.plugin.docker.Build) builds from an inline Dockerfile that copies files from the checkout, tagging my-app-image:latest and exposing imageId as an output.
3. The validateImage task (io.kestra.plugin.scripts.powershell.Commands) is the hook for image scanning or smoke tests before anything ships.
4. The deployImages task (io.kestra.plugin.core.flow.ForEach with concurrencyLimit: 2) iterates the machine list; each iteration extracts fields with jq filters (taskrun.value | jq('.hostName') | first) and hands them to the deployment stub, which you replace with a Subflow or SSH-based rollout.

What you get

• One pipeline from source checkout to fleet-wide rollout with an auditable image id.
• Bounded-concurrency deployment that acts as a built-in canary buffer.
• Runtime machine discovery instead of hardcoded inventories.
• Clear extension points for scanning, approval, and per-host deployment logic.

Who it's for

• Virtualization teams distributing containerized workloads onto vCenter-managed VMs.
• Platform engineers standardizing image build and rollout without a heavyweight CD system.
• Ops teams that need rollouts throttled and observable per machine.

Why orchestrate this with Kestra

Shell scripts that build and scp images have no concurrency control, no shared artifact metadata, and no per-host visibility. Kestra gives the rollout structure: the image id flows from the build task into every deployment iteration, ForEach with concurrencyLimit throttles blast radius, each machine's deployment is a separately retryable task run, and the whole pipeline can be triggered by a Git push, a schedule, or an upstream flow.

Prerequisites

• Docker available to the Kestra worker for docker.Build.
• A Git repository with your application source or image definitions.
• For real deployments, network access from the worker (or subflow workers) to the target machines.

Secrets

• None required for the stub version. Add Git credentials for private repositories and registry credentials when pushing images (for example DOCKERHUB_USERNAME, DOCKERHUB_PASSWORD on a push: true build).

Quick start

1. Point cloneSourceCode at your repository and adjust the Dockerfile.
2. Execute the flow: the image builds and three stub deployments log their targets, two at a time.
3. Replace the deployment stub with your rollout mechanism (Subflow, io.kestra.plugin.fs.ssh.Command, or vCenter API calls).
4. Replace the machine stub with your live inventory API.

How to extend

• Push the built image to a registry by adding push: true and credentials to docker.Build.
• Insert a io.kestra.plugin.core.flow.Pause approval between validation and rollout.
• Add Trivy or Grype scanning in validateImage and fail the flow on critical CVEs.
• Record each machine's rollout result and post a fleet summary to Slack.

Links

• Docker plugin docs: https://kestra.io/plugins/plugin-docker
• ForEach task docs: https://kestra.io/plugins/core/tasks/flow/io.kestra.plugin.core.flow.foreach
• Git plugin docs: https://kestra.io/plugins/plugin-git