simplify the stand-up of a sandbox

[jacobweinstock]

Description

This simplifies the stand-up of a sandbox. This PR has Vagrant Virtualbox, Vagrant Libvirt, Terraform Equinix Metal, and Docker Compose setups. This refactor modularizes the Tinkerbell stack to use docker-compose as the entry point and makes the creation of infrastructure on different providers the consumers of the docker-compose. Vagrant and Terraform are now only responsible for standing up infrastructure and then running docker-compose, not for running any glue scripts. The compose calls single-shot services to do all the glue required to get a fully functional Tinkerbell stack. All the single-shot services were made to be as idempotent as possible.

This increases portability and the speed of the development iteration cycle. This also simplifies the required steps needed to get a fully functioning sandbox up and running. All of the quick start guides are about 6-7 steps each.

This refactor aims to help people looking to get started by getting them to a provisioned machine quicker and more easily.

With the recent update in Hook to publish the kernel and initrd, this PR makes Hook the default OSIE. The Original OSIE can still be used. This is accomplished by updating the deploy/compose/.env and setting OSIE_DOWNLOAD_URL to an OSIE URL and TINKERBELL_USE_HOOK to false. Currently only an x86_64 Hook is published so only x86_64 machines can be provisioned with the sandbox using Hook.

Rendered QuickStart guide: https://github.com/jacobweinstock/sandbox/blob/one-touch-sandbox/README.md

Why is this needed

The existing setup.sh and genenv.sh and other glue scripts are outside of the the docker-compose and as such depend on the environment and require understanding to run successfully. This PR makes the stand up much simpler by only requiring docker-compose up. This will help people looking to get started by getting them to a provisioned machine quicker and more easily.

Fixes: #74, #85

How Has This Been Tested?

How are existing users impacted? What migration steps/scripts do we need?

Checklist:

I have:

• updated the documentation and/or roadmap (if required)
• added unit or e2e tests
• provided instructions on how to upgrade

[djpbessems]

[...] though I didn't thoroughly test it, I opted for the dirty workaround [...]

I looked into it some more, and I have been trying to solve the wrong issue. Instead of allowing images-to-local-registry to run in an airgapped environment (after running it once before during VM-template generation), I should have looked into why registry doesn't persist its library of images...

I checked /var/lib/docker/volumes and the contents of the unnamed volumes, it does seem that all the images are actually there, yet linuxkit tells me that the manifest was not found when it tries to pull from the registry. Similarly, when I push the image again to the registry, it doesn't say it's already there.

Do you think it would help if I explicitly defined a data-volume for it (similar to certs: and auth:)?

(I'm now just doing a sed -e '/images-to-local-registry:/,/^$/d' -i docker-compose.yml during the deployment of my template, so it doesn't even try to start that part.)

[djpbessems]

Do you think it would help if I explicitly defined a data-volume for it (similar to certs: and auth:)?

I see two unnamed volumes in /var/lib/docker/volumes, both with contents that show it's from registry, so this is very likely the solution. I'm going to test and let you know!

(And sorry for all the spammy messages with my train of thoughts spelled out, even though it's mostly out of scope for your PR :P)