The question has come up as to which Debian version is closest to balenaOS? Because colleague doesn’t yet believe that local development model of balena is “close enough” to native console and keyboard. Shaking my head but asking the question. It does make sense if you want to load the executable in the debugger…
Which version of Debian should we install on an Intel NUC to be as close as possible to balenaOS?
Hi @jason10, I guess that depends on what development setup that your colleague is trying to achieve.
There’s no Debian version that’ll be close to balenaOS because balenaOS isn’t based on Debian, but instead built with Yocto. But if your colleague wants a dev experience where they write code on a console, then manually start a program, they can do a few things:
a) Run a Debian that’s close to whatever base image you use for your containers. So, say your Dockerfile uses FROM balenalib/intel-nuc-debian:stretch or something like that, then you can just install Debian Stretch on the NUC and the environment will be close to the one that your app will run on. Though it might make sense to install a kernel that matches the one used by balenaOS (which you can check with uname -a).
b) Run a development balenaOS image, and instead of using local mode, push a “development environment” container with your code’s git repo, which runs systemd or a dummy script to keep the container running. That way you can use ssh to run a console into this development environment, in which you can run the program to test, and commit/push changes when you want to persist them. You can also move the git repo and any other relevant state to a volume to make it persistent if the container is restarted. And you can make this development container close to the actual production image you’ll use except for the dummy start script and having the git repo instead of just the built code or binaries. You can even start an X server in the container and use the NUC as a full GUI environment.
That being said, has your colleague tried the beta “livepush” functionality of local mode? https://www.balena.io/docs/reference/cli/#--live--l It’s a new feature that does some smart things to keep a local folder synchronized with what’s running in the container. If this still doesn’t work for them, we’d love to hear the feedback from your colleague on the kind of development environment they’d like to have.
Thanks, as you clarified, it’s the base image of the container that really matters. Often we can’t / aren’t on the same network as our devices (startup lifestyle) so local push isn’t an option.
One of the techniques I have been using for dockerfile.template development is to git push a starting dockerfile template, maybe even with “sleep infinity” as the command, and then use the dashboard template to try to find the sequence of apt-get, pip3 installs, etc that move me forward. Jetson TX2 is a challenge compared to the Intel NUC!
Hey Jason,
For development purposed it might make sense to have one of the devices you have in production next to you so you can quickly iterate on it using live push, while deploying to the remote ones using a full balena push. Would that make sense for you?
LOL, yes that would made sense. However it’s more to carry around, including any networking gear. A VPN to the office / lab might work too.