Closed sophokles73 closed 1 year ago
Yes, you can configure the Eclipse Kanto Container Manager with credentials for container registries. Refer to the Kanto Reference for details.
In Leda (starting 0.0.6), there is a convenient utility to modify the Kanto configuration:
sdv-kanto-ctl add-registry -h ghcr.io -u my_username -p my_password
It will automatically restart the container-management service so that the changes take effect. You may need to remove / recreate the container
That's good to know. It is, however, unclear to me under which circumstances I need to remove/recreate a container manually. I am currently using the init-dir approach to specify a manifest file for my container. When I make a change to that file, when will the change be picked up?
I think that would be a question to the Kanto project.
But due to this code, the init_dir approach will only run once on "first start of Kanto", but never again e.g. reboots or restarts of the container-management service will not trigger any kind of redeployments by Kanto itself.
So, to answer your question:
init_dir
: You need to remove the container and recreate your container manually. Alternatively, stop Kanto, delete all its internal files and restart the service.As the init_dir
approach is not as "convenient" as we had wished for, we decided to go for the kanto-auto-deployer approach in Leda for now. Starting with 0.0.6, the kanto-auto-deployer service will also watch for file change events in the manifests folder, so when you change a .json file in there, kanto-auto-deployer will pick it up and tries to redeploy the changed container.
Btw, we've added the "private container registry" documentation: https://eclipse-leda.github.io/leda/docs/device-provisioning/container-management/container-registries/
Now I am even more confused :-)
I was trying to follow the approach described in the Leda documentation.
My understanding is that the init_dir is the /data/var/containers/manifests
folder, right?
The last paragraph states
Important: The manifests in the kanto-cm init-dir are checked only ONCE - on service start-up. If you add/change a manifest you would need to restart the whole “container-management” service for your changes to take effect.
Now you are saying that a change will not be picked up unless the corresponding container gets removed (manually using kanto-cm remove -n container-id
?). If so, why would I need to recreate the container manually? Isn't that what should be done automatically based on the manifest file(s)?
When you use kanto-auto-deployer: Modifying the container json manifest (or even touching it) and saving it is enough for kanto-auto-deployer.service to pick up the change automatically, remove the existing container and recreate a new container.
The Leda documentation seems to suggest that I would use the auto-deployer simply be means of putting (auto-deployer specific) template files to folder /data/var/containers/manifests_dev
. However, that folder does not seem to exist in Leda 0.0.6 images.
Starting with 0.0.6, the kanto-auto-deployer service will also watch for file change events in the manifests folder, so when you change a .json file in there, kanto-auto-deployer will pick it up and tries to redeploy the changed container.
Does this mean that I do not need to use the auto-deployer specific template file format? Given that the init_dir approach also seems to expect manifest files to reside in that folder, which mechanism for deploying containers is now in effect, init_dir, auto-deployer, both?
Indeed the Leda documentation requires update, as the kanto-auto-deployer has been updated recently:
I think the sentence about "the containers are only deployed once - on service start" is not quite correct.
It's true for first boot, but not true for subsequent reboots. I think this has never been tested thorougly and we made the assumption it would be doing it on service (re)start.
The current mechanism is kanto-auto-deployer.
It takes the same manifests than kanto, but kanto init_dir is disabled in the container-management config.
We will keep using kanto-auto-deployer for the Leda quickstart images, as for development reasons, it's more convenient to have automatic redeployments as soon as the container manifest files change on disk.
And btw, kanto has an open pull request to also support updating containers after the "initial deployment", so the implementation there is ongoing...
ok, got it, thanks for explaining and IMHO you should really adapt the docs accordingly ;-)
I am using the version 0.0.6 leda x86_64 QEMU image, trying to start an additional container from a private container registry. I have created a
/data/var/containers/manifests/my-container.json
file:However, the repository on GitHub is private so, not unexpectedly, starting the container fails with an error being logge to
/var/log/container-management/container-management.log
:Is there any way to configure leda to use certain credentials for authenticating to a container registry?