Private registry AWS ECR - Torizon OTA Problem

I need to pull images from AWS ECR registry with OTA. I’m using this instrucion: Using private registries with torizon ota except i’m generating token on other machine becouse on torizon there is no aws-cli support. The problem is, this token expires after 12 hours so it is useless on production. I was able to create public image that can generate token from passed environment variables and save config.json to binded directory. Is there any posibility to run this image before pulling next one in the docker compose file?
Mayby there is some other posibilty to pull images from private ECR registry?

Greetings @Maciej.Gornicz,

Let me see if I understand your situation here.

  • You have container images stored on some private registry
  • You can create tokens to access this private registry, but they only last 12hours.
  • Now you need to figure out a way to update the device such that it has new tokens to access the registry before it actually tries to update and pull the container images.

Is that more or less correct?

Off the top of my head one way that should work right now, is doing the following:

  • Create a new OS update package with the new tokens. Push the OS update to the device first, so that it has the new tokens in config.json.
  • Once the OS update is successful, push the new container/docker-compose update.
  • If done before the tokens expire then the device should be able to access the registry.

Of course this method is a bit more cumbersome since now for every docker-compose update you need to push an OS update first for the tokens. But it should work currently, assuming I understood your use-case correctly.

Would this work for you? Or are there other factors?

Best Regards,
Jeremias

1 Like

You understand my problem perfectly :slight_smile:
I’ve just managed to do it like this:

  • I uploaded docker compose file with “login” image with passed variables of AWS Credentials
  • This image saved config.json with new token to the system by binded directories.
  • Then I uploaded actual docker compose file with production image which works.

The problem is, this is not secure. If something goes wrong with actual update. Then system will not go back to the previous state.

So this is more workaround than actualy solution i think.

Best Regards
Maciej Górnicz

What about the method I described? Doing an OS update first to put the token/credentials on the system, then performing a docker-compose update.

This way if something goes wring with the docker-compose update it should rollback to the previous state. Since we used the OS update to put the credentials on the system rather than a docker-compose update.