At the moment, the balena builders expect that any referenced image is a pre-built image that already exist on Dockerhub. In the case of the
controller service, although it builds the source and then tags it locally, it doesn’t check locally to see if that image exists, instead attempting to fetch it from Dockerhub (which is why we see the
[Error] Error: pull access denied for controller, repository does not exist or may require 'docker login' error.
My hope was that you could use the build context to do this instead, ensuring that a single image is produced for both services, eg:
However, after carrying out a quick test, this also doesn’t work, instead producing two images (although the layers are shared, so the device essentially downloads what comprises the single image, with slightly different metadata). Obviously this isn’t the same as what happens under a Linux/Window/macOS native install, where the service images use the same image ID.
I’ve raised an internal ticket here, as I believe what should happen is that the builder parses the docker-compose manifest to see if the build context matches that for other services, or an image is referenced along with a build context for use in other services. We’ll then discuss this in a product meeting and determine future steps.
Unfortunately, the best I can recommend at the moment is the use of the same build context (as I’ve shared above). Although it will still produce separate images, the actual downloaded layers will be (apart from a small amount of metadata) the same (and therefore not take up extra space).