DEV Community: Collins Adom Baffour

Running a Container Without Docker (Bootstrapping with the Filesystem and a Bundle)

Collins Adom Baffour — Thu, 27 Aug 2026 08:13:25 +0000

Docker is convenient, but it's also a thick layer of abstraction sitting on top of a handful of Linux kernel primitives. If you strip away the daemon, the CLI, and the image registry, a "container" is really just:

a process with restricted namespaces (its own view of PIDs, mounts, network, hostname, etc.)
a root filesystem it's been chroot/pivot_root'd into
optionally, cgroups limiting what it can consume

In this post we'll build a minimal container runtime by hand — no dockerd, no containerd, just unshare, chroot, and a plain directory tree we'll call a bundle. This is roughly what runc does under the hood when Docker "runs" a container.

Why bother?

It demystifies what Docker is actually doing.
It's useful when you're stuck on a machine with no Docker installed (e.g. a locked-down CI runner) but you have root and a kernel with namespace support.
It's the mental model you need if you ever touch the OCI runtime spec, runc, crun, or write your own sandboxing tool.

The ingredients

You need:

A Linux kernel with namespace support (basically any modern distro).
unshare and chroot (from util-linux / coreutils — almost always already installed).
A root filesystem for the container — a directory containing /bin, /lib, /etc, etc. This is our "bundle."

Step 1: Build the bundle (rootfs)

The simplest way to get a working rootfs without pulling a Docker image is to export one from an existing image with skopeo/umoci, or — even simpler — just untar a minimal distro's rootfs tarball. Alpine publishes exactly this:

mkdir -p ~/mybundle/rootfs
cd ~/mybundle
curl -LO https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/x86_64/alpine-minirootfs-3.20.3-x86_64.tar.gz
tar -xzf alpine-minirootfs-3.20.3-x86_64.tar.gz -C rootfs

You now have a directory that is a Linux filesystem: rootfs/bin, rootfs/etc, rootfs/lib, and so on. This directory is your bundle — the same idea as the rootfs/ + config.json layout the OCI runtime spec formalizes.

Step 2: Isolate it with namespaces

unshare lets you spin up a process in new namespaces without any daemon involved:

sudo unshare \
  --mount --uts --ipc --net --pid --fork \
  --mount-proc \
  chroot ~/mybundle/rootfs /bin/sh

Breaking that down:

--mount — the container gets its own mount table; mounting/unmounting inside it won't affect the host.
--uts — its own hostname/domainname.
--ipc — isolated System V IPC and POSIX message queues.
--pid --fork — a new PID namespace; the shell becomes PID 1 inside the container.
--net — its own network stack (no interfaces except lo by default — more on this below).
--mount-proc — remounts /proc inside the new mount namespace so ps reports container-local PIDs instead of the host's.
chroot ~/mybundle/rootfs /bin/sh — pivots the process's filesystem root and execs a shell.

Run that, and ps aux inside the shell will show basically nothing but your own shell as PID 1. hostname somename will only affect this namespace. You are, for most practical purposes, "in a container."

Step 3: Give it a real root (pivot_root instead of chroot)

chroot alone is famously escapable and doesn't fully detach the process from the host's mount tree. The more correct approach — what runc actually does — is pivot_root, which swaps the entire root mount rather than just relabeling a path.

This replaces Step 2's chroot, it doesn't chain after it. If you chroot into the rootfs first and then try to run the commands below, they'll fail: once you've chroot'd, the path ~/mybundle/rootfs no longer exists from your process's point of view (its root is now /), so mount --bind ~/mybundle/rootfs ~/mybundle/rootfs errors with "No such file or directory," and pivot_root errors with "Resource busy" because the target isn't a proper mount point. Pick one entry method — chroot (Step 2) or pivot_root (this step) — not both.

Here's the full sequence run correctly, from the host, in one unshare invocation:

# run as root on the HOST — do not chroot first
mkdir -p ~/mybundle/rootfs/oldroot

unshare --mount --uts --ipc --net --pid --fork --mount-proc -- \
  /bin/sh -c '
    set -e
    ROOTFS=~/mybundle/rootfs
    mount --bind "$ROOTFS" "$ROOTFS"   # rootfs must be a mount point for pivot_root
    cd "$ROOTFS"
    pivot_root . oldroot
    mount -t proc proc /proc
    umount -l /oldroot
    rmdir /oldroot
    exec /bin/sh
  '

Note the mount --bind happens on the host's original mount namespace before anything is switched — that's what makes $ROOTFS a valid mount point in the first place. pivot_root . oldroot (called with relative paths, after cding into the rootfs) is the actual root swap; there's no separate chroot call needed afterward, since the process's root is already the new filesystem.

Now the process genuinely cannot see the host filesystem at all — there's no /oldroot path left to walk back through, unlike a plain chroot where a determined process can sometimes break out.

Step 4: Limit resources with cgroups

Namespaces isolate view, cgroups limit consumption. These commands are run on the host, as root — not inside the chroot/pivoted rootfs (Alpine's minirootfs doesn't even ship sudo, so running them post-pivot will just fail with "sudo: not found"). If you're already root (e.g. via sudo su), drop sudo entirely:

mkdir /sys/fs/cgroup/mybundle
echo "+cpu +memory +pids" > /sys/fs/cgroup/cgroup.subtree_control
echo "50M" > /sys/fs/cgroup/mybundle/memory.max
echo "20"  > /sys/fs/cgroup/mybundle/pids.max
echo $$    > /sys/fs/cgroup/mybundle/cgroup.procs

Do this before the unshare call that launches your namespaced shell, capturing the PID via echo $$ right before you invoke it (or write the container's PID into cgroup.procs right after unshare --fork returns it). Then the shell — and everything it spawns — is capped at 50 MB of memory and 20 processes, exactly like a docker run --memory=50m --pids-limit=20 would enforce.

Step 5: Networking (optional, and the fiddly part)

By default the --net namespace only has loopback. To give the container real connectivity you create a veth pair, put one end inside the namespace, and NAT it — this is precisely what Docker's docker0 bridge and iptables rules automate for you:

sudo ip link add veth-host type veth peer name veth-ctr
sudo ip link set veth-ctr netns <container-pid>
sudo ip addr add 10.200.1.1/24 dev veth-host
sudo ip link set veth-host up
# inside the namespace:
ip addr add 10.200.1.2/24 dev veth-ctr
ip link set veth-ctr up
ip link set lo up
ip route add default via 10.200.1.1

Add a NAT rule on the host (iptables -t nat -A POSTROUTING -s 10.200.1.0/24 -j MASQUERADE) and the container can reach the outside world. This is the one piece where "just do it by hand" starts to feel like reimplementing Docker's networking stack — which, in a sense, you are.

Putting it together: a tiny launcher script

#!/bin/sh
# run-container.sh <bundle-dir> -- <command>
# run as root on the host (e.g. sudo ./run-container.sh ...)
BUNDLE="$1"; shift; shift  # drop the "--"
ROOTFS="$BUNDLE/rootfs"

mkdir -p "$ROOTFS/oldroot"
exec unshare --mount --uts --ipc --pid --fork --mount-proc -- \
  /bin/sh -c "
    set -e
    mount --bind '$ROOTFS' '$ROOTFS'
    cd '$ROOTFS'
    pivot_root . oldroot
    mount -t proc proc /proc
    umount -l /oldroot
    rmdir /oldroot
    exec $*
  "

sudo ./run-container.sh ~/mybundle -- /bin/sh

That's a real, working container in about ten lines of shell. It's missing image layering, a registry client, seccomp profiles, and a dozen other things runc/containerd/Docker handle for you — but the isolation primitives are the same ones Docker uses.

What this maps to in OCI terms

If you've seen runc spec generate a config.json, that file is just a declarative description of exactly the steps above: which namespaces to unshare, what the rootfs path is, what cgroup limits to apply, what mounts to bind in. A "bundle" in the OCI sense is literally:

mybundle/
├── config.json     # namespaces, cgroup limits, mounts, entrypoint
└── rootfs/          # the filesystem tree, e.g. our Alpine extract

runc run mycontainer just reads that config.json and does the unshare/pivot_root/cgroup dance for you, with a lot more edge-case handling (capabilities, seccomp, user namespaces, /dev setup, hooks). Understanding it manually first makes reading runc's source — or debugging a weird container issue — a lot less intimidating.

Caveats

This needs root (or user namespaces configured for rootless operation — a whole extra topic).
Skipping seccomp/capabilities means this is not a security boundary equivalent to a real container runtime. Don't run untrusted code in it.
Cgroup v1 vs v2 paths differ; check mount | grep cgroup to see which your system uses.

If you want to go further, the natural next step is reading runc's libcontainer source or the OCI runtime-spec repo — everything above is the tip of what it formalizes.

Amazon Simple Storage Service (S3)

Collins Adom Baffour — Wed, 13 Nov 2024 18:14:37 +0000

Introduction

Amazon S3 is an incredibly scalable, durable, and secure object service solution used by businesses worldwide to store and retrieve data. Whether you’re handling backups, websites, or big data, S3's flexibility makes it an ideal choice. Amazon S3 stores data as objects within buckets. Object is a file and any metadata that describes the file. Bucket is a container for objects. To store your data in Amazon S3, create a bucket and specify a bucket name and AWS Region. Then, you upload your data to that bucket as objects in Amazon S3. Each object has a key (or key name), the unique identifier for the object within the bucket.

Buckets vs Objects

Storage Classes

Amazon S3 offers a range of storage classes designed for different use cases. These classes are purpose-built to provide the lowest cost storage for different access patterns. These classes are ideal for virtually any use case, including those with demanding performance needs, data lakes, residency requirements, unknown or changing access patterns, or archival storage. The table below shows the various storage classes and their use cases.

Access Control

Amazon S3 is secure, and private by default, with extensive auditing capabilities to monitor access requests to resources. Access to S3 resources must be explicitly granted to an identity to ensure security.
This access can be granted by the below Access Management tools

Bucket Policy: JSON-based policies attached to buckets to specify access permissions, enabling fine-grained control over who can access specific resources.
Identity-Based Policy: Policies attached to AWS IAM identities (users, groups, roles) that define permissions to access S3 resources across the AWS account.
S3 Access Grants: An access control tool that simplifies granting cross-account access to specific objects or buckets using access permissions.
Access Points: Customized access control points with unique policies to simplify access for large data sets, especially in shared environments or multi-tenant architectures.
Access Control List (ACL): Legacy method for managing access to buckets and objects by defining read and write permissions for users and groups.
Object Ownership: A setting that controls ownership of objects uploaded to a bucket, often used to ensure the bucket owner automatically owns all objects, simplifying permissions management.

Data Protection

Versioning: Versioning in Amazon S3 is a means of keeping multiple variants of an object in the same bucket. You can use the S3 Versioning feature to preserve, retrieve, and restore every version of every object stored in your buckets.
Buckets can be in one of three states:
- Unversioned (the default)
- Versioning-enabled
- Versioning-suspended
Replication: You can use replication to enable automatic, asynchronous copying of objects across Amazon S3 buckets. Buckets that are configured for object replication can be owned by the same AWS account or by different accounts.

Security and Encryption

Encryption Options: All Amazon S3 buckets have encryption configured by default, and all new objects that are uploaded to an S3 bucket are automatically encrypted at rest.

Server-side encryption - Amazon S3 managed keys (SSE-S3) is the default encryption configuration for every bucket in Amazon S3. To use a different type of encryption, you can either specify the type of server-side encryption to use in your S3 PUT requests, or you can set the default encryption configuration in the destination bucket. Other server-side encryption includes Server-Side Encryption with AWS Key Management Service and Server-Side Encryption with Customer-Provided Keys
Client-side encryption – You encrypt your data client-side and upload the encrypted data to Amazon S3. In this case, you manage the encryption process, encryption keys, and related tools.

Conclusion

In summary, Amazon S3 provides a scalable, secure, and versatile storage solution for a range of needs. With robust access controls, encryption options, and seamless AWS integration, S3 empowers businesses to efficiently manage and protect their data, supporting innovation and growth in the cloud.

If you enjoyed this article, please let me know in the comment section or send me a DM. I'm always happy to chat! ✌️

Thank you so much for reading! 🙏 Keep an eye out for more AWS-related posts, and feel free to connect with me on LinkedIn 👉
https://www.linkedin.com/in/collins-adom-baffour/.

References

Security in Amazon Virtual Private Cloud

Collins Adom Baffour — Sun, 12 May 2024 21:19:19 +0000

Introduction

When it comes to securing resources within an AWS Virtual Private Cloud (VPC), both Security Groups and Network Access Control Lists (NACLs) play vital roles. However, they operate at different layers of the network stack and serve distinct purposes. Let's explore the differences between Security Groups and NACLs:

Security Groups

Operational Layer

Operates at the Instance Level: Security Groups are stateful firewalls that operate at the instance level. They control inbound and outbound traffic for individual EC2 instances, RDS instances, and other resources within the same VPC.

Rule Configuration

Allow Rules Only: Security Groups consist of rules that allow traffic based on specified criteria (e.g., IP addresses, protocols, ports). By default, all traffic is denied unless explicitly allowed by a rule.

Filtering

Stateful: Security Groups are stateful, meaning they automatically allow return traffic for permitted inbound connections. For example, if an inbound rule allows traffic on port 80, the corresponding outbound traffic is allowed without requiring an explicit rule.

Dynamic Updates

Dynamic: Changes to Security Group rules take effect immediately. This flexibility allows for quick adjustments to network access based on evolving requirements.

Application

Instance-level Security: Security Groups are ideal for enforcing security policies specific to individual instances or resource groups. They provide granular control over network traffic and are well-suited for application-level security.

Network Access Control Lists (NACLs)

Operational Layer

Operates at the Subnet Level: NACLs are stateless firewalls that operate at the subnet level. They control traffic entering and exiting subnets within the VPC.

Rule Configuration

Allow and Deny Rules: NACLs consist of numbered rules that allow or deny traffic based on source and destination IP addresses, protocols, and ports. Unlike Security Groups, NACLs support both allow and deny rules.

Filtering

Stateless: NACLs are stateless, meaning they do not automatically allow return traffic. For each packet, both inbound and outbound rules are evaluated independently.

Priority Order

Evaluated in Order: NACL rules are evaluated in ascending order based on their rule numbers. If a packet matches a rule, the action (allow or deny) specified by that rule is applied, and subsequent rules are not evaluated.

Application

Subnet-level Security: NACLs provide an additional layer of security by controlling traffic flow at the subnet boundary. They are useful for implementing broad network security policies across multiple instances or services within a subnet.

Conclusion

Both Security Groups and NACLs are essential components of network security in AWS, and they are often used together to create multi-layered defense strategies for protecting resources within a VPC.

Amazon MSK (Managed) vs Apache Kafka (Self -Managed)

Collins Adom Baffour — Sat, 11 May 2024 16:42:39 +0000

Introduction

In the world of real-time data processing, Apache Kafka has long reigned as the go-to solution for building robust and scalable streaming platforms. However, with the rise of managed services like Amazon Managed Streaming for Apache Kafka (Amazon MSK), businesses face a choice: stick with the tried and true self-managed Kafka or embrace the convenience of a managed service. In this blog, we'll delve into the key differences, pros, and cons of Amazon MSK versus Kafka, helping you make an informed decision for your streaming needs.

Understanding the Basics

Apache Kafka:

Apache Kafka, developed by LinkedIn, is an open-source distributed event streaming platform used for building real-time data pipelines and streaming applications. It is designed for high throughput, fault tolerance, and horizontal scalability. Kafka operates on a distributed architecture consisting of brokers, topics, producers, and consumers. While powerful, Kafka requires manual provisioning, configuration, and maintenance, which can be complex and resource-intensive.

Amazon MSK:

Amazon Managed Streaming for Apache Kafka (Amazon MSK) is a fully managed service that simplifies the deployment, management, and scaling of Apache Kafka clusters on AWS. With Amazon MSK, AWS handles infrastructure provisioning, software installation, maintenance, and monitoring, allowing users to focus on building applications rather than managing infrastructure.

Key Differences:

Managed vs. Self-Managed: The most apparent difference between Amazon MSK and Kafka is the management approach. With Kafka, users are responsible for setting up and managing the infrastructure, including provisioning servers, configuring brokers, and ensuring high availability. In contrast, Amazon MSK abstracts away much of this complexity, providing a fully managed service where AWS handles cluster management, updates, and monitoring.
Integration with AWS Ecosystem: Amazon MSK seamlessly integrates with other AWS services, such as Amazon CloudWatch, AWS CloudFormation, AWS Identity and Access Management (IAM), and Amazon VPC, enabling users to leverage existing AWS tools and services for monitoring, security, and networking. While Kafka can also be deployed on AWS, integrating it with AWS services requires additional setup and configuration.
Scalability and Elasticity: Both Amazon MSK and Kafka offer scalability and elasticity, allowing clusters to scale horizontally by adding or removing nodes to accommodate changes in workload. However, Amazon MSK simplifies the scaling process by automatically handling cluster resizing and rebalancing, whereas with Kafka, users must manually adjust cluster configuration and rebalance partitions.
Cost Structure: The cost structure differs between Amazon MSK and self-managed Kafka. With Kafka, users pay for infrastructure resources (e.g., EC2 instances, storage, networking) based on usage and configuration. In contrast, Amazon MSK follows a pay-as-you-go pricing model, where users pay for the managed service based on cluster usage (e.g., broker-hours, storage, data transfer).

Pros and Cons:

Kafka:

Pros:

Full control over infrastructure and configuration.
Flexibility to customize and optimize cluster performance.
No vendor lock-in, as Kafka is open-source and can be deployed on any infrastructure.

Cons:

Requires expertise in deployment, configuration, and maintenance.
Time-consuming and resource-intensive management tasks.
Limited integration with AWS services out-of-the-box.

Amazon MSK:

Pros:

Fully managed service reduces operational overhead and complexity.
Seamless integration with AWS ecosystem for monitoring, security, and networking.
Automated provisioning, scaling, and maintenance tasks.

Cons:

Vendor lock-in to AWS ecosystem.
Limited flexibility for customizing cluster configuration and performance optimizations.
Potentially higher costs compared to self-managed Kafka, depending on usage patterns.

Conclusion:

Choosing between Amazon MSK and Kafka depends on your organization's specific requirements, expertise, and preferences. While Kafka offers greater control and flexibility, it requires significant investment in management and maintenance. On the other hand, Amazon MSK provides convenience and simplicity, allowing users to focus on application development rather than infrastructure management. Ultimately, the decision boils down to striking the right balance between control, convenience, and cost-effectiveness for your streaming platform.

Further Reading