Build and test containers and VMs using plain shell script

79bbea0 Inhibit cleanup by unregistering traps

~dxld pushed to ~dxld/oida git

4 days ago

79bbea0 Inhibit cleanup by unregistering traps

~dxld pushed to ~dxld/oida git

4 days ago

#oida -- Shell DSL for OS image build automation

Let's face it, Dockerfiles suck. Not only is the syntax a complete mess, they also only work for building containers but not full blown disk images.

I present to you, dear reader, a more powerful and yet more convenient alternative:

The humble shell script.

The fact of the matter is that scripting OS builds without a framework like Docker can be a bit of a PITA because of all the filesystem mounting, chrooting and generally running dangerous commands that could eat your development workstation if you forget you're not in the proper chroot.

This is where oida comes in. It's essentially a well written shell library plus a couple of custom shell builtins that together expose the full power of Linux namespaces (Docker's magic sauce) to Bash scripts in a safe manner.

Your script accidentally ran rm -rf /* because some variable expanded to nothing? No problem. Before running the build script oida protects the system mount points by making them locally read-only for the shell process running the build script. So you won't accidentally kill your development system.

#Getting Started

Before you can start using oida you have to compile the bash builtins, to do that we need the headers from the bash-builtins package. On Debian(esque) distros we can install that with

$ apt-get install bash-builtins

and then compile them

$ make builtins

If you want to be more comprehensive and check everything works as intended you can also just run make, which will run unit tests and lint the code with the shellcheck static analyzer.

Some tests need root and the makefile will run those only if it's running as uid=0.


We very much welcome patches and other contributions. Please send patches to the oida mailing list. See https://git-send-email.io if you're not familliar with the email based git workflow.