Private corporate batches, live online cohorts and 1-on-1 mentoring in daemonless, rootless containers and pods — user namespaces, Quadlet and the Kubernetes bridge — 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 Podman around the two decisions that make it different from Docker rather than around the commands they share: the daemonless path from podman to conmon to crun, and the user-namespace mechanics of rootless operation — subordinate UID ranges, podman unshare, keep-id mapping, unprivileged port ranges, and SELinux :z and :Z labelling. Sessions then cover pods and the podman kube generate and kube play round trip into Kubernetes, image work split across Buildah and Skopeo including signing and multi-architecture manifests, netavark and aardvark-dns networking, and Quadlet unit files that put containers under systemd supervision on hosts with no orchestrator. Everything is demonstrated live against running rootless hosts.
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 Podman that means a trainer who has run it in production — daemonless, rootless containers and pods — user namespaces, Quadlet and the Kubernetes bridge — 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 Podman batchPodman is a container engine for OCI images, containers and pods that runs without a daemon. There is no long-lived background service holding the containers: podman run forks a small supervisor called conmon, conmon starts the OCI runtime — crun or runc — and the container becomes an ordinary child process of the session that launched it. Removing the daemon removes the root-owned socket that effectively grants root to anyone who can reach it, and it removes the failure mode where restarting the engine disturbs every container on the host.
The second design decision is rootless operation. A rootless container runs inside a user namespace, where UID 0 inside the container maps to the invoking user's subordinate UID range declared in /etc/subuid and /etc/subgid. Images and layers live under the user's home directory on fuse-overlayfs or native rootless overlay, connectivity comes from pasta or slirp4netns rather than a root-owned bridge, and privileged ports and certain kernel capabilities are genuinely unavailable rather than merely discouraged. Knowing which of those limits are real and which are configuration is most of the distance between a working rootless deployment and a frustrated one.
Around that core Podman is deliberately unbundled. Buildah builds images, Skopeo copies, inspects and signs them across registries and transports, and CRI-O runs the same containers under Kubernetes. Pods are a first-class primitive rather than a metaphor: containers in a pod share a network namespace through an infra container, exactly as they do in Kubernetes, and podman kube generate and podman kube play move workloads between a laptop and cluster YAML. For long-lived services, Quadlet turns a declarative unit file into a generated systemd service, so containers are supervised by the same init system as everything else on the host.
The container engine stopped being a free choice the moment security baselines caught up with it. A root-owned daemon socket is a privilege-escalation path that appears in every serious host hardening review, and CI systems that mount that socket into build jobs hand root to whatever the build executes. Podman's daemonless, rootless model removes the finding rather than documenting an exception for it.
Distribution decisions have pushed the same way. Red Hat Enterprise Linux and Fedora ship Podman, Buildah and Skopeo as the supported container toolchain, so any estate standardised on RHEL now needs engineers fluent in Podman rather than engineers who translate Docker commands and hope. The CLI compatibility makes the first day easy and the second week hard: the commands look identical, but user namespaces, SELinux labelling, rootless networking and systemd integration behave differently enough that surface familiarity produces confident mistakes.
There is also a growing class of workload that never reaches an orchestrator — edge nodes, appliances, single-tenant servers, build hosts — where systemd plus Quadlet is the whole platform. That is the gap Podman fills, and it is a skill organisations hire for specifically.
What Podman replaces, and why the difference is architectural rather than cosmetic. The conmon supervisor, the OCI runtime beneath it, and how a container ends up as a child of your shell instead of a system service — followed by an honest comparison with the Docker client-daemon split, including what you give up.
Topics: The daemonless execution model: podman, conmon, crun and runc · OCI image and runtime specifications · Podman compared with the Docker client-daemon architecture · Why the Docker socket is a privilege-escalation path · Podman, Buildah, Skopeo and CRI-O as separate tools with separate jobs · containers/storage and containers/image as shared libraries · Reading the effective configuration with podman info
Getting a usable environment on RHEL, Fedora, Debian, macOS and Windows, then the command surface. Because the CLI is deliberately Docker-compatible, this module spends its time on where the two diverge rather than re-teaching container basics.
Topics: Installing on RHEL and Fedora, Debian and Ubuntu, macOS and Windows · podman machine and the managed Linux VM on macOS and Windows · containers.conf, storage.conf and registries.conf and their precedence · Short-name resolution and unqualified-search-registries · Container lifecycle: run, start, stop, rm, exec, logs, inspect · Where Podman diverges from Docker: restart policy, healthchecks, default networks · The Podman REST API socket and its Docker-compatible endpoint · podman-docker and aliasing docker to podman safely
The module that decides whether rootless is viable for your estate. Subordinate UID and GID ranges, what UID 0 inside the container actually is on the host, why file ownership across a bind mount looks wrong, and which capability and port restrictions the kernel genuinely enforces.
Topics: User namespaces and the /etc/subuid and /etc/subgid mapping · Rootless storage: fuse-overlayfs, native rootless overlay and the home directory layout · podman unshare for working inside the mapping · --userns=keep-id, auto and nomap and when each is correct · Privileged ports and net.ipv4.ip_unprivileged_port_start · Rootless networking with pasta and slirp4netns · Capabilities, seccomp profiles and SELinux relabelling with :z and :Z · What rootless genuinely cannot do · loginctl enable-linger and services that outlive the login session
A Podman pod is a Kubernetes pod, not an analogy for one. The infra container and the shared network namespace, port publishing at pod level rather than container level, and the round trip between running something locally and describing it as cluster YAML.
Topics: Creating and managing pods; the role of the infra container · Shared namespaces: network, IPC, UTS and optionally PID · Publishing ports at pod level and what that means for the containers inside · podman kube generate: containers and pods to Kubernetes YAML · podman kube play: running Kubernetes YAML on a single host · ConfigMaps, secrets, volumes and persistent volume claims under kube play · Where local pods stop and a real cluster begins · CRI-O as the cluster-side runtime for the same images
Podman builds images, but Buildah is where construction gets interesting — including building an image with no Containerfile at all. Then Skopeo for copying, inspecting and signing images across registries and transports without ever pulling them into local storage.
Topics: podman build, Containerfile and Dockerfile compatibility · Multi-stage builds, layer caching and build arguments · Buildah primitives: from, run, copy, config, commit · Scripted builds with Buildah and no Containerfile · Rootless and unprivileged builds inside CI containers · Skopeo copy, inspect, list-tags, sync and delete · Transports: docker://, containers-storage:, oci:, dir: and docker-archive: · Image signing with sigstore and GPG, and enforcing policy.json · Multi-architecture images with podman manifest and buildah manifest
Netavark and aardvark-dns replaced CNI as Podman's default network stack, and the rootful and rootless paths differ in ways that matter operationally. Then volumes, mounts and SELinux labelling — the origin of most bind-mount failures on Red Hat systems.
Topics: Netavark and aardvark-dns, and migrating from the CNI plugins · Bridge, macvlan, ipvlan and host network drivers · Container name resolution inside a user-defined network · Rootless networking: pasta versus slirp4netns, and their trade-offs · Port publishing and firewalld interaction · Named volumes, bind mounts and tmpfs mounts · Volume import, export and volume plugins · SELinux contexts, the :z and :Z mount options, and container_file_t · Diagnosing connectivity with podman network inspect and nsenter
The part that turns Podman into an operations tool. Quadlet unit files and the systemd services generated from them, auto-update against registry digests, healthchecks that systemd acts on, and the logging, resource-limit and upgrade story for hosts that will never have an orchestrator.
Topics: Quadlet unit types: .container, .pod, .volume, .network, .kube and .build · Generated systemd services and the deprecated podman generate systemd path · User services, linger and reliable start at boot · podman auto-update and the io.containers.autoupdate label · Healthchecks, on-failure behaviour and restart policy under systemd · Running services under a dedicated unprivileged system account · Logging to journald and choosing a log driver · cgroups v2 resource limits applied through systemd · podman system prune, df, reset and storage reclamation · Upgrading Podman and migrating storage across major versions
We rebuild the agenda around the tools you actually run.
Request a custom agendaRun a web service rootless on a privileged port, then justify every mapping, sysctl and capability decision that made it possible.
Reproduce the classic rootless ownership failure across a bind mount, then fix it correctly with podman unshare and keep-id rather than chmod 777.
Take a multi-container Compose application, run it as a Podman pod, generate Kubernetes manifests from it and replay them with kube play.
Construct the same image twice — declaratively with a Containerfile and imperatively with a Buildah script — then sign it and copy it with Skopeo.
Write Quadlet units for a container, a volume and a network, enable linger, reboot the host and prove the service came back unaided.
Deliver a hardened single host running a multi-container application rootless under systemd, with auto-update, healthchecks, journald logging and a documented rollback.
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 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.
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.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
| 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.