I have a background service of of runtime: node and would like to install the AWS CLI, so I can periodically trigger shell commands that run it.
Can I do this without resorting to a custom Docker container image?
It’s not available as an npm package anymore, although I can install it via pip (python -m pip install awscli).
I need to run this command (and echo 'export PATH=$PATH:/opt/render/.local/bin/' >> ~/.bashrc) at some point when the background service is set up, but I’m not sure where in my render.yaml. If I add it to my buildCommand or preDeployCommand the files it creates don’t make it over to the file system of the background service instance (I assume that is limited to ~/project/).
If I add this to startCommand, this gets run every time the service is restarted, which is not ideal.
This seems to leave two options: Go the whole route of creating a custom Docker image after all, or manually putting it on a persistent disk (which I already have for other reasons anyway).
It would be great if disks were mounted and available in the build container, alas no.
Recreating everything in the default node runtime in a new Docker container is a little daunting for me. It would be great if Render published what is essentially a copy of the node runtime as a Docker image that I could customise (nothing like that in the examples).
Using a human-interactive CLI inside an otherwise automated service is fairly antithetical, and Render images generally don’t contain a lot of things to support human-interactive components, two reasons why this task is as hard as it is. You should probably set the AWS CLI up on a system of your own ownership.
If you want to be able to trigger a call to AWS and have the application process it as an on-going task, use AWS’ API and configure the application to process it as needed.
The AWS CLI is triggered to mimic part of a build/deploy process that is usually done by hand. The background service along with a headless CMS are meant to abstract away exactly how this process works and provide flexibility to change the implementation details (in an access controlled way).
I agree that implementing an S3 deploy via the AWS API would be better and trivial, but in the short term, I don’t yet know what deploy means or destinations we might use in the next six months, so I wanted to make as little changes as possible.
Manually installing it on a persistent disk worked in the short term. I’ve made a note to remove an explicit AWS CLI dependency when it makes sense (although the background process still triggers a build and runs other shell commands).
For the benefit of other Render customers though, it would help to have some more explicit documentation for people who want to customise the standard runtime. The docs mention Docker, but a template repo that replicates the node runtime as close as possible where one could just add a few packages of their own would be useful.
Or better yet, a render.yaml blueprint option to install an additional package.
Does it need to be inlined into the Web Service? A Private Service could be set up and since it’s separate it could then be a Docker image that would greatly simplify adding the AWS CLI. A small web or other listener on a specified port makes this pretty trivial. It could even be done with a Background Worker if the task can be invoked as a background job.
I don’t know what else you have in your stack, or if it’s strictly required to be in the Web Service, but those are some alternative possibilities to fulfill a separate service to setup as Docker.