Private corporate batches delivered onsite across Pune, or live online in IST (UTC+5:30) — taught by a practitioner who runs Docker 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 Docker as an image supply chain. Namespaces, cgroups and capabilities come first so isolation is understood rather than assumed, then image anatomy and what actually invalidates a layer, multi-stage builds over large vendor toolchains, and the mount and network work that lets a container reach a licence server or a device on the site network. The registry material is built for governed estates — rebasing onto an approved parent, promotion by digest, and moving an image set to a disconnected host with save and load — and the runtime comparison across dockerd, containerd and runc is taught because it is what turns a stuck container into a diagnosable one. Every concept is demonstrated live against running daemons rather than described on a slide.
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 Docker that means a trainer who has run it in production — containers and image supply chain for Pune's build farms, captives and plant-side services — 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.
Onsite delivery covers Hinjewadi, Talawade, Kharadi, Magarpatta, Baner and Viman Nagar, and we travel to Pimpri-Chinchwad and Chakan for plant-side teams; you provide the room, a screen and network, we bring trainer, agenda, lab repositories, assessments and certificates. Hours are 09:30 to 17:30 IST with the 08:00 to 13:00 IST half-day split available for teams that owe an evening handover. The one thing to check before a Pune Docker batch is laptop policy — attendees need either local virtualisation enabled or a Linux VM each, and where corporate images block that we run the labs on free-tier cloud instances the attendees provision themselves. If your estate proxies or blocks a public registry, tell us at the discovery call and we mirror the lab images into your internal registry beforehand so no exercise depends on an outbound pull. Invoicing is in INR with GST against your purchase order from the Indian entity.
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 Docker batchDocker is a way to turn an entire software environment — not only an application — into a versioned artefact. Underneath, a container is an ordinary process that the kernel keeps inside its own namespaces, with cgroups capping what it may consume and capabilities trimming what it may ask the kernel to do; there is no guest operating system and no hypervisor in the picture. What makes that useful on a build farm is the image: an ordered stack of content-addressed layers plus a small configuration blob naming the entrypoint, user, environment and working directory. Everything the work needs, down to the shared libraries and the compiler patch level, travels inside it.
That property is why one pooled agent can serve three customer programmes pinned to three incompatible toolchain versions. Each programme gets an image referenced by digest, and the agent stops being a negotiation about what may be installed on the host. The parts of Docker that then matter are the ones a short tutorial never reaches: multi-stage builds so a multi-gigabyte vendor software development kit stays in the build stage and never ships, instruction ordering so a source change does not reinstall the compiler, bind mounts that expose attached hardware or a licence dongle, and a network path that lets a container reach a floating licence server.
Distribution is the third piece and the one policy constrains hardest. Registries — an internal Artifactory or Nexus, Harbor, ECR, ACR — move images between build and runtime, and where nothing may be fetched from the public internet the working skill is rebasing an application image onto an approved parent rather than picking a base from a public catalogue. Where there is no route at all, save and load carry an image set to a disconnected site as a tarball. Below the daemon sit containerd and runc, and knowing where one ends and the next begins is what makes a stuck container diagnosable.
Container demand in Pune is shaped by who is doing the containerising. Along the Hinjewadi and Talawade corridor the people booking this training own a build farm rather than a web application, and their constraint is that a pooled agent cannot hold every customer's toolchain simultaneously. Containers become a scheduling and cost answer rather than a modernisation slogan: fewer agents, less contention between programmes, and a build that behaves the same in week one and week ninety of a contract.
The regulated captives around Kharadi, Yerwada and Magarpatta reached the same skill from the opposite direction. Once base images are governed centrally, every application team has to rebase, rebuild and account for what is inside an image without reaching the public internet, and a vulnerability in an approved parent turns into coordinated rebuild work across dozens of services. That is standing engineering work, not a one-off migration project.
The third pull comes from the manufacturing belt around Pimpri-Chinchwad and Chakan, where a container is how a plant-adjacent service reaches a host on an unreliable link with no appetite for a remote package install. Image size, offline transfer, restart policy and log rotation are the questions asked there, and none of them are answered by an orchestration syllabus. Across all three, what gets tested in an interview is image supply chain rather than cluster theory.
Isolation before tooling. Namespaces, cgroups and capabilities demonstrated directly on a host, then the layered filesystem an image is assembled from. The point is that later, when a build container cannot see a device or a process refuses to die, the responsible layer is obvious rather than mysterious.
Topics: What a running software environment is actually made of · Namespaces: PID, mount, network, UTS, IPC and user · cgroups and limits the kernel enforces whether the process agrees or not · Capabilities, and what root inside a container really means · Boot, root, user and application filesystems · Containers against virtual machines, stated honestly · Where the container runtime interface sits
The platform and the path a command travels through it: client, daemon, containerd and runc, plus images, containers and registries as objects. Installation on Linux and Windows Server, then daemon configuration — the storage driver, data-root, log driver and proxy settings that decide whether the first build of the day works on a controlled network.
Topics: Docker Engine and the client-daemon split · Images, containers, volumes and registries as objects · Installing on CentOS, Ubuntu and Windows Server · daemon.json: storage driver, data-root, log driver, registry mirrors · Proxy and certificate configuration where egress is inspected · Docker Desktop against Docker Engine, including the licensing question · Alternatives: Podman, containerd, and where each is the better answer
The commands real work depends on, and the PID 1 problem that explains a surprising share of container bugs. Every lifecycle transition and the signal it sends, then working inside a running container without destroying the evidence you need.
Topics: docker run in depth, and the flags that matter on a shared agent · create, start, stop, restart, pause, unpause, kill and rm · docker stop against docker kill, and which signal arrives when · Why PID 1 matters and what an init process fixes · exec, attach, and detaching without killing the process · cp, diff, rename and inspect for investigation · update and wait in scripted workflows
Seeing what containers and the daemon are doing, with particular attention to hosts that nobody visits. Logging drivers and rotation matter more on a plant-side machine with a small disk than on a laptop, and disk exhaustion from unpruned images is the most common way a build agent dies quietly.
Topics: Container logs and choosing a logging driver deliberately · Log rotation and size caps on hosts with limited disk · Live resource statistics and per-container process lists · Real-time daemon events as an audit trail · dockerd troubleshooting and reading the daemon log · Disk usage, prune strategy and reclaiming space safely on an agent · A repeatable method: logs, inspect, exec, events, stats
The artefact everything else revolves around. Image anatomy and digests, what invalidates a layer and what does not, building from a running container against building from a Dockerfile, and each instruction's effect on the resulting graph — including the ones that quietly bake a secret into a published layer.
Topics: Image anatomy: layers, digests and the configuration blob · What invalidates a layer, and what only appears to · Building from a running container against building from a Dockerfile · Every Dockerfile instruction and its effect on the layer graph · ARG against ENV, and secrets that must never reach a layer · .dockerignore and the cost of a large build context · docker history, and finding the layer responsible for half the size
The module engineering teams book this course for. Separating a multi-gigabyte vendor software development kit from the runtime it produces, pinning a toolchain version per programme, and making layer caching genuinely reduce wall-clock time on a pooled agent rather than only on a warm developer laptop.
Topics: Multi-stage builds and copying only the artefacts forward · Keeping a licensed compiler or code generator in a build stage · Pinning a toolchain version per programme by digest · Instruction ordering for dependency install against source copy · Cache behaviour across a shared agent pool, and cache warming · Base image choice: full, slim and minimal, with the trade-offs stated · Running as a non-root user, and repairing what that breaks
What survives a container and what does not. The three mount types with the reasoning for each, then the awkward cases that dominate real work: a device or dongle passed into a container, a host user whose numeric identity does not match the container user, and a mount that silently hides a populated directory.
Topics: The writable layer and its copy-on-write cost · Named volumes, bind mounts and tmpfs compared · Passing a device or licence dongle into a container · UID and GID mismatch and the permission failures that follow · Mounting over a populated directory, and what disappears · Volume drivers and storage held off the host · Backup, restore and migration for containers holding state
How a container is reached and what it can reach. Each driver with the case it exists for, the NAT path behind published ports, and embedded DNS — then the constraint that dominates licensed toolchains: a container that must appear on the site network or hold a stable address for a floating licence server to hand out a seat.
Topics: Bridge, host, none, overlay, macvlan and IPvlan, and when each is right · Port publishing and the NAT path a packet takes · Embedded DNS and name resolution between containers · Reaching a floating licence server from inside a container · macvlan where a container must appear directly on the site network · User-defined networks and isolation between stacks on one host · Diagnosing connectivity with exec, nsenter and packet capture
Images as controlled artefacts rather than downloads. Tagging discipline and digests, internal registries as the only permitted source, rebasing an application onto an approved parent when that parent is patched, and the transfer mechanics for a site that cannot pull anything at all.
Topics: Tagging strategy, digests and immutability · Artifactory, Nexus, Harbor, AWS ECR and Azure Container Registry · Pull-through mirrors, and a registry as the single permitted source · Rebasing an application image onto an approved parent without breaking it · Promotion by digest between environments, with no rebuild · save and load against export and import, and why the difference matters · Carrying an image set to a disconnected site and verifying it on arrival
What is inside the image and who says so. Scanning and the triage that follows, rebuild cadence when a governed parent changes, least-privilege runtime settings, and the evidence an internal review will ask for before an image is allowed near production.
Topics: Vulnerability scanning, and triaging the findings that actually matter · Rebuild cadence when an approved parent is patched · Dropping capabilities, read-only root filesystem and no-new-privileges · Why the Docker socket is a privilege boundary, not a convenience · Secrets at build and run time, and what leaks into a layer · Signing, attestation and a software bill of materials · Evidencing image contents for an internal review
Beyond one container. Compose for a multi-service definition with dependencies and per-environment overrides, restart policy for hosts nobody logs into, then the runtime beneath Docker — containerd, CRI-O and runc — and an honest account of which Docker habits stop working under Kubernetes.
Topics: Compose files, service dependencies and healthcheck conditions · Profiles and per-environment overrides · Restart policies for unattended and intermittently connected hosts · Running the same workload directly on containerd · dockerd, containerd, CRI-O and runc compared · Docker Swarm and the narrow case where it still fits · What changes under Kubernetes, and which habits do not survive
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild an isolated process from namespaces, a cgroup and a root filesystem by hand, then start the same workload under Docker and account for every difference.
Containerise a large licensed build toolchain three times at three pinned versions, run all three on one host, and prove each build resolves the compiler it expects.
Pass attached hardware into a container, hit the numeric user mismatch that follows, and fix it twice — once by changing the image and once by changing the run.
Take a container that cannot check out a seat from a floating licence server, work through resolution, routing and driver choice, and get the checkout to succeed.
Rebase an application image onto a patched internal base image with no public pull available, then promote the resulting digest through three registries unchanged.
Assemble a multi-service stack, transfer it as an image archive to a host with no route to any registry, start it, verify it, and document the upgrade path for the next release.
The most common Docker problem in Pune is not containerising a web application — it is containerising a toolchain. Engineering-services and ER&D teams in Hinjewadi, Talawade and Hadapsar build with vendor compilers, code generators and simulation tools that are licence-locked and pinned to a specific version per customer programme, and the only workable way to run three programmes on three toolchain versions across one shared build farm is an image per programme. That drags in the parts of Docker most courses skip: multi-stage builds over multi-gigabyte SDKs, licence-server reachability from inside a container, bind mounts to attached hardware, image provenance, and layer caching that genuinely saves time on a pooled agent.
The regulated captives around Kharadi, Yerwada and Magarpatta bring the opposite constraint — nothing is pulled from a public registry at all. Base images are golden, scanned and approved, everything arrives through an internal registry, and the valuable skill is rebasing an application image onto an approved parent without breaking it. Out along the Pimpri-Chinchwad and Chakan manufacturing belt, containers are increasingly how plant-adjacent services reach sites with intermittent connectivity, which makes image size, offline load and save, restart policy and log rotation the questions people actually ask rather than orchestration theory. Pune job listings pair Docker with an automation server and an artifact repository far more often than with a service mesh, which tells you where the local skill gap really sits.
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
Helped to understand more on overall DevOps concepts.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
| 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.