Hi @ycy88 – You’d be able to automate that using the resin cli.
https://docs.resin.io/reference/cli/#os-download-type- would enable you to download the image for the device type – Note: If you make a local copy of the file to do the rest of the modifications on, you wouldn’t have to re-download this every time
To further elaborate, we wanted to do it as a backend service, so that our non-technical folk can configure devices without installing the CLI, would there be a direct API that we can use?
Also, we are trying to run the operation as a NodeJS microservice on AWS Lambda, and it’s not quite feasible to invoke the CLI from there.
Have tried looking resin-device-init package (https://github.com/resin-io-modules/resin-device-init) which seems to allow us to do this. However, it runs post install scripts using Python to further configure, which will be tricky to run from a NodeJS microservice as well.
Would you have further suggestions on how we might do this?
@ycy88 We don’t currently have an API for pre-configuring images and make them available for download on our end. Also while using resin-device-init is certainly possible, we don’t really maintain that to be used as a public library, so there might be breaking changes somewhere along the line, making the CLI a far more dependable choice.
The good news is that Lambda does actually allow you to do, well, almost anything – It just doesn’t make it as visible for ease of use – however in the end it’s just a linux docker container that you can do anything with, as long as you keep in mind they’ll be spun up and destroyed as demand requires, so you can’t store state on them.
The way you’d go about implementing something like this would be to install the resin-sdk and all it’s dependencies in your project directory, and include them in the zip file you upload to Lambda – because all the dependencies are already there, you can just execute the CLI from NodeJS as a child process (https://nodejs.org/api/child_process.html#child_process_child_process).
You could either include the image you want to configure in the zip file you upload to Lambda, or store it in AWS S3 and download it from there every time the configuration micro service is called.
For some inspiration on how to build custom Lambda hacks, you could look at:
Thanks again @chrischabot - super detailed and helpful explanation.
One more point to clarify, for image builds with a fairly large size, such as the RaspberryPi3 which stands about 1.8GB - the total size of the raw image file would exceed what Lambda can hold.
Could we otherwise implement the config CLI command on a zipped version of the file? Does not seem to be supported at the moment.
@ycy88 ah right you are – Unfortunately the CLI wouldn’t be able to work on a zipped image (not without decompressing it anyways, which would cause the same issue)
Otherwise having a small dedicated EC2 instance or Amazon Elastic Container Service instance to generate the image file and call that from the lambda function