The Machine Image Build Environment
There’s not a lot of flexibility in the images available for Triton. There simply isn’t. So I’ve been doing a lot of research into how I can remedy that.
For hardware virtual machines, any disk image that has cloud-init support built in will do fine as long as the SmartOS plugin is enabled. It has to be in raw format.
However, for zones, the image building process is slightly different. With the Machine Image Build Environment (or mibe, as they call it), you can generate SmartOS images that are customized from a base image.
This functionality was originally built to enable the Machine Images that Joyent offered when JPC was active. These were images such as the apache and nginx container images that were supposed to be paired with a delegated dataset. It enabled a docker-like experience for JPC users, before they built out the docker-engine endpoint.
But mibe is still in use today. It appears that the people over at SkyLime are actually still using it to develop their core.io computing cloud. Their GitHub was instrumental in getting mibe working in the first place.
Additionally, there were a few bugs within the environment that really irked me, so I went ahead and cloned the repo just to fix the bugs. The base repo actually doesn’t work very well with modern git servers, and was ultimately designed for a private git server that joyent used, so I modified
repo_pullall (and lib/mibe.inc) to support adding usernames in front of repo names in etc/repos.list.
The next big modification was that automatic vm creation based on a specfile actually worked, unlike the README would imply, but destruction of the build vm only worked if the build succeeded, which would make build automation rather hard, so I modified lib/mibe.inc to include the already written vm cleanup function.
You can find all of these changes in the KCRL mibe repo.
After that, you need some configuration repos. You can use the mi-kcrl-base and mi-kcrl-full as an example.
The basic file structure is:
/Changelog - a basic textfile that’s a pretty self-explanatory log of changes, its unclear if this gets used in building the image in any way.
/packages - a newline separated list of package names to install, for example
/customize - a bash script thats run after the packages are installed.
/manifest - a manifest of the image metadata used to build the image.
/manifest.json - its unclear what this does, but the skylime images have it, so I included it. Its essentially a json formatted version of manifest. You can add metadata requirements in this version of the manifest.
/motd - a message of the day file. This is used to generate the login blurb for the image.
/copy/ - a directory structure that gets copied directly ontop of the zone filesystem.
Some things to look out for:
If any command in customize returns a non-zero status-code, the script will be assumed to have failed. This will abort the whole build.
If you need specific dns resolvers set during build, you’ll need to set them yourself. At KCRL we have a specific setup that ruins our ability to use the image default resolvers, so we have to set those in the customize script as well.
The etc/vm.json file has to be a json file generated by triton itself. We couldn’t get it to build correctly with a normal SmartOS vmspec. YMMV.
We haven’t yet tested this process on a base SmartOS install. YMMV.
Don’t forget to upload any images you create and find useful to datasets.at.