Hi! We use the Balena CLI tool to build images on our local development machines, then deploy them directly to our Balena applications. This flow has been working great for us, and we’re happy that you all continue to support this deployment mechanism.
In order to pull from private repositories, we have to make our SSH keys available to the Docker build, and then we have to be careful about removing the keys after they’re used so that the keys are not persisted in individual layers. This has been a general Docker problem for a while, but I saw that there’s a new feature in Docker 18.09 that allows us to safely expose an SSH agent to the Docker build, which is pretty cool
Do you think this is something that could be supported by the Balena CLI in the future? I tried to deploy an image to Balena that was built using this feature, but the deployment wasn’t successful.
This is the flow I tried
docker build --ssh default .
and then
balena deploy --application <my_app> <image_id>
I’m guessing the deployment failed because I didn’t build the image using balena build
This could be a useful feature for the CLI, so I thought I would let you all know!
@nicktardif, thank you for this request / suggestion. Unless you are using specific balena build features such as replacement variables in a Dockerfile.template file, it should be OK for an image to be built on your laptop/desktop computer with docker build --ssh, then deployed to devices with balena deploy like you described. I believe the laptop and the device need to have the same architecture, like Intel x86. I have just successfully tested building an image on a MacOS laptop and then deploying it to a balena app with an Intel NUC device:
So perhaps you could share more details about what exactly went wrong in your deployment attempt? Like, the build logs and any relevant command lines in full.
As for the --ssh command-line option, we are actually currently working on a different option, the --secret option, which might also allow you to achieve what you need:
I don’t currently have an estimate of time for this work to be released to production, but it has fairly high priority.
I have created a GitHub issue in the balena-cli repo for the --ssh option, so that the request gets visibility over there as well, though it is not yet confirmed when / if / how it will be implemented:
Thanks for your quick response! I think that the secrets functionality will be a great addition, and I’m also glad to hear that running a docker build followed by a balena deploy should work for my use-case too! Thanks for adding that issue to balena-cli too!
Here’s some more details into my failure case:
First I had built a Docker image using this command
docker build --ssh default -t 1_14_test .
And the image built correctly. After that I tried to deploy it using this command
root@build-server:~/Paracosm/bootstrap/docker# balena deploy g_space_parakeet/px80capturebeta 958b0178f1b6
[Info] Creating default composition with image: 958b0178f1b6
[Info] Everything is up to date (use --build to force a rebuild)
[Warn] Target application requires legacy deploy method.
[Info] Initializing deploy...
[Info] Uploading [========================] 100% eta 0s
[Error] Deploy failed
Remote error: undefined
If you need help, don't hesitate in contacting us at:
GitHub: https://github.com/balena-io/balena-cli/issues/new
Forums: https://forums.balena.io
My guess is that there was a mis-match somehow after the image was uploaded to the Balena server, and that caused an error. I’ve never tried to build an image using the same architecture as the Intel NUC, so maybe that’s the problem. My desktop has an AMD processor, and the cloud service I’m using has Intel Xeon processors. I thought that a Docker image would be be indifferent to the host machine’s build architecture, but maybe that’s causing a problem.
Are there any logs on your side that could show us why Remote error: undefined is appearing?
Actually - I just tried to deploy an image that I built with balena build too, and I got the same deployment error as before, so there must be something wrong with my deployment command. I did just upgrade my CLI tool version, so I could be missing a flag that is required for legacy applications
Edit: I was trying out CLI version 9.12.0, upgrading from version 6.8
I’m going to try deploying using version 6.10.3 and see if that works
Edit 2: The Resin CLI version 6.10.3 allows me to deploy images to our application, so I wonder if the deploy issue is due to our application being a legacy app?
Hi @nicktradif
you are probably right that this could be connected to your application being type legacy,
Also it looks like you might have found possible faulty behaviour introduced in newer versions of the balena cli.
As to the legacy app type is it possible that you can deploy the image to a non legacy application ?
Also you could enable extra debug by calling the more recent version of the balena cli in debug mode as follows:
DEBUG=1 balena deploy … ?
I did a few tests and I think we got the expected results. I did both of these tests with Balena CLI version 9.12.0
I tried deploying an image to our legacy application with debug mode on and it failed with some additional output
user@server:~/Github# DEBUG=1 balena deploy g_space_parakeet/px80capturebeta d9541f4cab41
[Debug] Parsing input...
[Debug] Loading project...
[Info] Creating default composition with image: d9541f4cab41
[Debug] Creating project...
[Info] Everything is up to date (use --build to force a rebuild)
[Warn] Target application requires legacy deploy method.
[Info] Initializing deploy...
[Info] Uploading [========================] 100% eta 0s
[Debug] Received data: {"type":"error","message":"Unauthorized. Cannot access application"}
[Error] Deploy failed
Error: Remote error: undefined
at Request.handleMessage (/snapshot/balena-cli/build/utils/deploy-legacy.js:67:25)
at emitOne (events.js:96:13)
at Request.emit (events.js:188:7)
at IncomingMessage.<anonymous> (/snapshot/balena-cli/node_modules/request/request.js:1080:12)
at emitOne (events.js:96:13)
at IncomingMessage.emit (events.js:188:7)
at IncomingMessage.Readable.read (_stream_readable.js:381:10)
at flow (_stream_readable.js:761:34)
at resume_ (_stream_readable.js:743:3)
at _combinedTickCallback (internal/process/next_tick.js:80:11)
at process._tickDomainCallback (internal/process/next_tick.js:128:9)
If you need help, don't hesitate in contacting us at:
GitHub: https://github.com/balena-io/balena-cli/issues/new
Forums: https://forums.balena.io
And then I created a new sample application (shouldn’t be legacy because it’s new) and the deploy was successful
user@server:~/Github# DEBUG=1 balena deploy sample_new_app d9541f4cab41
[Debug] Parsing input...
[Debug] Loading project...
[Info] Creating default composition with image: d9541f4cab41
[Debug] Creating project...
[Info] Everything is up to date (use --build to force a rebuild)
[Info] Creating release...
[Debug] Tagging images...
[Debug] Authorizing push...
[Info] Pushing images to registry...
[Debug] Saving image registry2.balena-cloud.com/v2/6aa2cd67dcb8b8d7f16fa48d7a126a8e
[Debug] Untagging images...
[Info] Saving release...
[Success] Deploy succeeded!
[Success] Release: d715f674e22beafe36d83921ce21b19a
@nicktardif, a new balena CLI release, v9.14.6, should fix the unauthorized error when deploying a legacy app prefixed by a username, such as the g_space_parakeet/px80capturebeta case you have kindly reported here. This should allow you to upgrade to the latest version of the CLI and use it with the legacy app. Note there are 2 ways of upgrading the CLI: using npm or downloading the “standalone installer”, whichever is more convenient to you: https://www.balena.io/docs/reference/cli/#install-the-cli
Let us know if you still come across any issues that appear related to the legacy app. Thanks again!
