Doubt related to the integration of Docker registry?

I have a doubt suppose I am using BalenaCloud or OpenBalena then, in that case for the fleet deployment, I was referring this document =>

Here it is mentioned for Balena push that =>

If you need to pull in proprietary code or use a private base image during your builds you can do so using the build time secrets or private base images feature of balena push .

I am using the Base image provided by the Balena But I have a proprietary code that I want to deploy on the End Device using Balena Push or Balena Deploy. Do I need to have a Private repository on Docker Hub?

Hi,

The private repository on Docker Hub is needed in case you have a private self-built Docker image that you want to pull when building the application, If it’s a proprietary code then you should use the build time only secret file here (https://www.balena.io/docs/learn/deploy/deployment/#build-time-only-secret-file).

Thanks for the Response I read the https://www.balena.io/docs/learn/deploy/deployment/#build-time-only-secret-file Link you sent here.

I have a doubt So I need to create a subdirectory .balena in the root of the Repository.
Inside that directory, I need to make another directory named secrets and a file named balena.yml

And In that secrets directory Do I need to add my proprietary code?

Yes, we have a file called super-secret-recipe in the docs and it will be mounted as /run/secrets/my-recipe file in the container, you should do the same for your code.

Also please notice that subdirectories are supported in both the source (.balena/secrets) and the destination (/run/secrets)

Okay, I got that but I have a doubt.

Suppose I have these 5 directories with the proprietary code =>

super-secret-recipe, super-secret-recipe-1, super-secret-recipe-2, super-secret-recipe-3, super-secret-recipe-4

Now I’ll all these directories inside secrets directory.

And in the .balena/balena.yml I’ll add

build-secrets:
    services:
        service1:
            - source: super-secret-recipe ( Same way for Other Services )
               dest: my-recipe2

Please correct me if I am wrong.

Now In that documentation that you shared, I found these lines

This will mount the super-secret-recipe file into /run/secrets/my-recipe file in every build container. Note that the /run/secrets folder is only available during the image build, and not present in the image that is deployed to the devices.

According to my understanding, these line stat that /run/secrets folder is only available during the image build and not in the Image deployed to the device.

So will it make my code available on the end device at the location I specify in docker-compose.yml? Do I need to have a docker-compose.yml or balena.yml will replace the docker-compose.yml? I am confused How I should I build the structure of My Repository that I am pushing?

Can you please share a sample example here?

Hi,

yes you are correct, the secrets mount will only be available during the build. You can then add a line like COPY /run/secrets/my-recipe /bin/my-recipe for example.

Does that help?

Hi
Sorry But I think I have got all confused here.
I referred the document I need to make sure If I understood the process of fleet deployment in the right way

For instance, here I am using an OpenBalena Stack and Now I have the code ready on the local machine in which I have signed in using OpenBalena and created a device and application. Assigned the device to an application in this instance consider MyApp.

I am using the Base Image provided by the Balena for my container and Have added the dependencies in my Dockerfile. I have my application which has a completely proprietary code.

Now suppose I pushed the code using balena push MyApp ( Note: Suppose I haven’t added .balena/balena.yml nor the secrets directory here )

Then in that instance, it will go to my OpenBalena Stack where Builder will build the image and it will upload these image to the OpenBalena registry and create a release entry in the balena API ( I suppose Builder, OpenBalena and balena API components are on the Server on which OpenBalena is configured. )

Now the confusion starts here if the code is uploaded on OpenBalena / Balena Cloud registry then why on the diagram from that documentation has Docker registry?

I don’t have much of idea about docker But When I referred the Docker documentation I found this line

The Registry is a stateless, highly scalable server-side application that stores and lets you distribute Docker image

Which one is used OpenBalena / BalenaCloud registry or Docker Registry? If Docker registry then can you please explain How secrets can help me in deploying the proprietary application.

Also, I am confused about this line

If you need to pull in proprietary code or use a private base image during your builds you can do so using the build time secrets or private base images

Pull the proprietary code from Docker Hub?

And How can I deploy my application which is proprietary?

Hello can anyone please help me here with the above stated problem?

Hello, the docker registry you are referring to in the diagram would be the open-balena-registry. Remember that the builder is not included in open-balena, which means that balena push ... will not work. What you want instead is to balena deploy which will build your containers locally. If you need to pull-in a private base image for your build, you can do so via the --registry-secrets option. Have a look at https://www.balena.io/docs/reference/cli/#deploy-appname-image which has examples on how the registry-secrets file should be formatted.

Okay Except the Build Operation balena deploy will deploy the code on OpenBalena Registry after that a release will be created in OpenBalena API and will be stored in OpenBalena API database.

So I just wanted to confirm while deploying the proprietary application from my local machine I only need to use `balena deploy ’ No need to used build time secrets Right?

That is correct. Secrets are primarily meant to be used to pass things like API keys to the build process, without exposing them in the resulting container. If I understand correctly your use case, registry-secrets should be what you are looking for. This allows you to use your private base images (thus keeping the proprietary code hidden) in your build process, so that you can then deploy those to your devices without ever making them publicly available.

Actually, I am not using the private base image. I am using the Base Image provided by the Balena. Only thing I don’t want to be exposed in this process is my proprietary code.

As I understand all the Operations happen on OpenBalena Stack so none of my proprietary code will be exposed. Please correct me if I am wrong.

So I am confused Why would I require private base images?

Can anyone please help here regarding to this Question?

Hello @Sharvin26, my colleagues have been advising on this thread on the assumption that you’re going to be using balenaCloud. The definition of “private image” is obviously not the same between balenaCloud and openBalena.

From the cloud perspective, a private image means private to you or your team. That is, apart from other users (obviously), not even balena staff have access to the image. To enforce this sort of privacy to your images, you can use the tools already suggested in this thread.

From an openBalena perspective, images are inherently private from the world. Noone has access to the images apart from the owner of the openBalena installation.

I hope this clears things up. If you have further questions specific to openBalena, it’s best if you could post into the dedicated category :slight_smile:

Actually I had doubt related to both in this scenario. But your answered the problem here.
I got confused due to the image in that documentation ( Which I have added above ) that shows docker registry.

The Docker registry on that illustration refers to the registry component of balenaCloud which is a deployment of a vanilla docker-distribution service on balenaCloud servers. openBalena bundles the same exact component as well. I see how that picture may be confusing in that it may suggest images go to Docker Hub, which is an external registry owned by Docker. I’ll see how we can improve on this.

Yes that’s what exactly happened with me here. Thanks for the clarification.