Private corporate batches, live online cohorts and 1-on-1 mentoring in identical machine images built once from a single template and shipped to every platform — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Packer as the build stage of an immutable pipeline rather than as a CLI — HCL2 source and build blocks, plugin pinning with packer init, variables and locals, and parallel builds that emit an AMI, an Azure image and a Vagrant box from one set of provisioning steps. Sessions cover what makes an image pipeline trustworthy: provisioner choice between shell and a configuration management tool, hardening a base image and proving it with automated checks, manifest post-processors that hand the image ID to Terraform, and the debug and breakpoint workflow for a build that fails on a machine that no longer exists.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Packer that means a trainer who has run it in production — identical machine images built once from a single template and shipped to every platform — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Packer batchPacker is a tool for building machine images from a single source template. You declare a source — an AWS AMI, an Azure managed image, a VMware or VirtualBox virtual machine, a Docker image, a GCP image — and a set of provisioning steps, and Packer starts a temporary instance, runs the provisioners against it, captures the result as an image and destroys the instance. The output is an artefact you can boot repeatedly and identically, which is the foundation of immutable infrastructure: servers stop being configured in place and start being replaced.
Modern Packer templates are written in HCL2. A `source` block describes where the image comes from and what it is built on; one or more `build` blocks attach provisioners to sources; variables, locals and `packer init` with `required_plugins` give the template the same parameterisation and dependency pinning Terraform users already recognise. Because build blocks can reference several sources at once, one template can produce an AMI, an Azure image and a Vagrant box from the same provisioning steps in parallel — which is what makes multi-cloud parity achievable rather than aspirational.
Packer deliberately does not do configuration management. It delegates: shell and PowerShell provisioners for straightforward steps, and Ansible, Chef, Puppet or Salt when the image should be built by the same code that manages running fleets. Post-processors handle what happens after the image exists — writing a manifest, tagging, converting formats, uploading to a registry. That division of labour, plus `packer fmt`, `validate` and `inspect`, is what lets an image build sit safely inside a CI pipeline.
The bake-versus-configure argument has largely settled. Autoscaling groups, spot instances and Kubernetes nodes all need machines that come up ready in seconds, and a node that must run a fifteen-minute configuration pass before it can serve traffic is not a node you can scale on. Pre-baked images move that work to build time, where it can fail safely and be tested, rather than to boot time, where it fails under load.
Security and compliance push the same direction. A golden image built from a hardened base, scanned once and promoted through environments is a far easier control to evidence than an estate of long-lived servers patched in place. When a CVE lands, replacing images and rolling instances is a bounded, repeatable operation; patching a thousand running hosts is not. Organisations with a real audit obligation increasingly require that images come from a pipeline, not from a person.
The practical driver is Terraform. Terraform provisions from an image ID, and the quality of that image determines how much the Terraform code has to compensate for. Teams that adopt Terraform without an image pipeline end up doing configuration management inside user-data scripts, which is the worst of both worlds. Packer is the piece that makes the immutable story complete, which is why the two skills are usually hired together.
Why baking images beats configuring at boot, and where that argument breaks down. The Packer execution model — temporary instance, provision, snapshot, destroy — and the component vocabulary: sources, builders, provisioners, post-processors and plugins. Installation and the CLI surface, including the commands that matter before build: init, fmt, validate and inspect.
Topics: Bake versus configure at boot, and the honest trade-offs · What Packer is and what it deliberately does not do · Installing Packer and managing versions · The Packer workflow: temporary instance to artefact · Components: sources, builders, provisioners, post-processors · The Packer CLI: init, fmt, validate, inspect, build · Plugins and the plugin ecosystem · Where Packer sits relative to Terraform and configuration management
The template language in full. The packer block with required_plugins and version constraints; source blocks and their builder-specific arguments; build blocks that attach provisioners to one or more sources; input variables, defaults, validation and variable files; locals for computed values; and the functions and expressions HCL2 provides.
Topics: The packer block, required_plugins and version pinning · source blocks and builder configuration · build blocks and the sources argument · Input variables, types, defaults and validation · Variable files, environment variables and CLI overrides · Sensitive variables and keeping secrets out of logs · locals and computed values · HCL2 functions, expressions and templating · Migrating legacy JSON templates to HCL2
An end-to-end AMI build on AWS, done properly. Selecting a base AMI with a source_ami_filter rather than a pinned ID that goes stale, IAM permissions and credentials for the build, VPC, subnet and security group configuration, SSH communicator settings, AMI naming with a version and timestamp, tagging, and sharing or encrypting the resulting image.
Topics: Selecting a base image with source_ami_filter · IAM permissions required for a Packer build · Credentials handling and instance profiles · VPC, subnet, security group and temporary key configuration · Communicator configuration: SSH and WinRM · AMI naming, versioning and tagging · Region copying, sharing and encryption · Build variables and the timestamp pattern · Cleaning up when a build fails midway
Getting software onto the image. Shell and shell-local provisioners, the file provisioner and upload semantics, PowerShell for Windows images, then the configuration management provisioners — Ansible, Ansible Local, Chef, Puppet and Salt — with the judgement call this module exists for: when a shell script is genuinely sufficient, and when reusing production configuration code is worth the complexity.
Topics: Shell and shell-local provisioners · Inline scripts, script files and script ordering · The file provisioner and upload directories · PowerShell and windows-restart provisioners · The Ansible and Ansible Local provisioners · Chef, Puppet and Salt provisioners · Provisioner ordering, only and except targeting · pause_before, timeouts and reboot handling · Choosing between shell and configuration management, honestly
One template, many outputs. Attaching several sources to a single build block so AWS, Azure, VMware and Vagrant artefacts are produced in parallel from identical provisioning; source-specific overrides where platforms genuinely differ; then post-processors — manifest, compress, checksum, vagrant, docker-tag and docker-push — and how the manifest becomes the handoff to Terraform.
Topics: Attaching multiple sources to one build block · Parallel builds and build isolation · Source-specific overrides with the override block · Azure, GCP, VMware, VirtualBox and Docker builders · The manifest post-processor and machine-readable output · compress, checksum and format-conversion post-processors · The vagrant post-processor and box output · docker-tag and docker-push post-processors · Handing an image ID to Terraform
An image nobody has verified is a liability. Building from a hardened base, applying a benchmark with configuration management modules, and proving the result with automated checks — InSpec, Goss or a serverspec suite — run inside the build so a non-compliant image never becomes an artefact. Then the debugging workflow for builds that fail on a machine that no longer exists.
Topics: Starting from a hardened or minimal base image · Applying a benchmark with Ansible or Chef modules · Verifying an image with InSpec, Goss or serverspec · Failing the build on a failed control · Vulnerability scanning an image before promotion · packer build -debug and step-through builds · Breakpoint provisioners · on-error=ask and keeping the instance alive to inspect it · PACKER_LOG and reading build logs · Secrets hygiene: keeping credentials out of the image and the log
Making image builds a system rather than a laptop task. A pipeline that formats, validates and lints on every commit, builds on merge, tests the artefact, records the manifest, and promotes through environments — with versioning, image metadata, deprecation and cleanup, plus HCP Packer for registry-based tracking of which image is current where.
Topics: Validating and linting templates as a fast pipeline gate · Building images from CI and handling long-running jobs · Credential management for automated builds · Testing the artefact after the build · Recording and publishing the manifest · Image versioning and naming conventions · Promotion across dev, staging and production · Image deprecation, cleanup and cost control · HCP Packer registry, channels and image tracking · Triggering downstream Terraform runs from a new image
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a brittle template with a pinned base image ID and hard-coded region, and rebuild it in HCL2 with validated variables, locals and pinned plugin versions.
Build a tagged, versioned AMI from a filtered base image, boot it, confirm it serves traffic with no post-boot configuration, then prove a failed build leaves nothing behind.
Build the same image twice — once with shell scripts, once with Ansible — measure build time and maintainability, and defend which one you would ship.
Produce an AMI, an Azure image and a Vagrant box in parallel from a single build block, with source-specific overrides only where the platforms genuinely differ.
Harden a base image against a real benchmark, verify it with InSpec or Goss inside the build, then break one control and confirm no artefact is produced.
Wire a pipeline that validates on commit, builds on merge, tests the artefact, publishes a manifest, promotes across environments and triggers a Terraform deployment from the new image ID.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.