Build a search-engine and swap it on the appliance

The script is ~/code/scripts/build_and_deploy_search_engine.sh on the Mac (a personal script, not part of either application repository). Usage: build_and_deploy_search_engine.sh sn7d-jetnpd x86_64. It was used for debug builds in September (a 1 September binary sits in the build directory) and was changed on 6 October to build a release binary with the product’s compiler and to copy the binary over the LAN. The release form had not run when this page was written, so this page describes the script, not a verified operation.

Why a binary and not an image

The product builds an image with docker buildx bake; that Dockerfile cross-compiles on the host’s own platform and installs only the aarch64 cross toolchain, so an arm64 Mac cannot build the amd64 image, and the build server lacks the buildx plugin. The shipped binary needs only glibc 2.35, which both the build server and the container have, so a host-built binary runs unchanged inside the 10.0.0 container. The cost: the container’s image tag no longer says what runs, so the script prints the sha256 of the old and new binaries.

What the script does

1. On the build server: first-time setup of build tools and rustup, then rustup toolchain install 1.89.0 (the version the product Dockerfile pins).
2. rsync of app/svc/search-engine and app/shared/shared-rs from the Mac checkout to /home/pi/appliance-build, excluding target/.
3. cargo +1.89.0 build --release --locked with the build directory /home/pi/search-engine-target. Expect 20 to 40 minutes the first time on this box; later builds are incremental.
4. file and sha256sum of the binary on the build server, then scp from the build server to the appliance’s LAN address (the Mac’s agent forwarded with ssh -A).
5. On the appliance: the container’s current binary is kept once as /home/pi/search-engine.before; both hashes printed; docker stop, docker cp into /usr/local/bin/search-engine, docker start; the hash inside the container printed.

Prerequisites: the Mac’s agent holds the key and a fresh Vault-signed certificate (the library copy used the same forwarding); the build server can reach 192.168.1.15; no measurement run in progress, since the build loads the simulator host and the swap restarts the service.

Way back

Copy /home/pi/search-engine.before into the container the same way and restart it, or recreate the container from its image with the compose project. Neither has been exercised yet. A reboot does not revert the swap, because nothing re-runs compose at boot; a firmware update from the product does.