3d387cd26e
Signed-off-by: Michael Richard <michael.richard.ing@gmail.com> ## Description This configures NGINX to listen on port 8080 and lets go the need to configure a second IP address on the host dedicated to NGINX. ## Why is this needed Setting up a second IP address to host NGINX on the same host is not always easy, especially when running tinkerbell on network devices like switches. The second IP address adds a useless level of complexity. In the future, all the code required to identify the host operating system and configure the IP address could even be removed and left as a prerequisite, since the host is likely to have an IP address already configured. ## How Has This Been Tested? The untouched vagrant_test.go test ran sucessfully. ## How are existing users impacted? What migration steps/scripts do we need? Simply re-applying the docker-compose.yml should be sufficient (untested). Additional firewall rules to allow traffic on port 8080 could be required depending on user's network configuration. ## Checklist: I have: - [ ] updated the documentation and/or roadmap (if required) - [ ] added unit or e2e tests - [ ] provided instructions on how to upgrade |
||
|---|---|---|
| .github/workflows | ||
| cmd/getbinariesfromquay | ||
| deploy | ||
| script | ||
| test/_vagrant | ||
| .envrc | ||
| .gitattributes | ||
| .gitignore | ||
| .mergify.yml | ||
| CODEOWNERS | ||
| current_versions.sh | ||
| generate-envrc.sh | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| README.md | ||
| setup.sh | ||
| shell.nix | ||
This repository is a quick way to get the Tinkerbell stack up and running.
Currently it supports:
- Vagrant with libvirt and VirtualBox
- Terraform on Packet
Tinkerbell is made of different components: osie, boots, tink-server, tink-worker and so on. Currently they are under heavy development and we are working around the release process for all the components.
We need a way to serve a version of Tinkerbell that you can use and we know what is running the hood. Sandbox runs a pinned version for all the components via commit sha. In this way as a user you won't be effected (ideally) from new code that will may change a bit how Tinkerbell works.
We are keeping the number of breaking changes as low as possible but in the current state they are expected.
Binary release
As part of a new release for sandbox we want to push binaries to GitHub Release in this way the community will be able to use them if needed.
We build Docker images across many architectures, each of them in its own repository: boots, hegel, tink and so on.
Sandbox is just a collection of those services and we follow the same pattern for getting binaries as well.
There is a go program available in ./cmd/getbinariesfromquay/main.go. You can
run it with go run or build it with go build:
$ go run cmd/getbinariesfromquay/main.go -h
-binary-to-copy string
The location of the binary you want to copy from inside the image. (default "/usr/bin/hegel")
-image string
The image you want to download binaries from. It has to be a multi stage image. (default "docker://quay.io/tinkerbell/hegel")
-out string
The directory that will be used to store the release binaries (default "./out")
-program string
The name of the program you are extracing binaries for. (eg tink-worker, hegel, tink-server, tink, boots) (default "hegel")
By default it uses the image running on Quay for Hegel and it gets the binary
/usr/bin/hegel from there. The directory ./out is used to store images and
binaries inside ./out/releases.
To get the binaries for example for boots you can run:
$ go run cmd/getbinariesfromquay/main.go \
-binary-to-copy /usr/bin/boots \
-image docker://quay.io/tinkerbell/boots:sha-9625559b \
-program boots
You will find them in ./out/release