Simple one line Dockerfile: FROM baserow/baserow:1.10.1
Disk created at /baserow/data/
Error:
Jun 28 02:14:28 PM 2022-06-28 18:14:28,985 CRIT unknown problem killing baserow-watcher (203):Traceback (most recent call last):
Jun 28 02:14:28 PM File "/usr/lib/python2.7/dist-packages/supervisor/process.py", line 432, in kill
Jun 28 02:14:28 PM options.kill(pid, sig)
Jun 28 02:14:28 PM File "/usr/lib/python2.7/dist-packages/supervisor/options.py", line 1251, in kill
Jun 28 02:14:28 PM os.kill(pid, signal)
Jun 28 02:14:28 PM OSError: [Errno 1] Operation not permitted
This error doesn’t happen using Docker Desktop, so wondering if it’s something with the disk mounts on Render.
I think this is going to be more involved than a simple dockerfile to run this on us that ended up in quite a deep rabbit hole.
But…
I forked the repo at https://github.com/johnbeynonorg/baserow - that you can also fork, and then use New > Blueprint Instance and select your fork and then the renderize branch. This spins up a Render managed Postgres ($7 per month) and Redis (free) instance but also uses our Starter Plus plan for the webservice at $15 per month as it seems to be fairly resource hungry even with using Postgres and Redis from outside the container and ran out of memory on our lower plans.
Once booted you should visit the shell tab of the service and execute:
./baserow.sh backend-cmd manage migrate
Note, this is provided ‘as-is’, I/we don’t use this at all ourselves but should help you get on your way. It does not use any disk for permanent storage as the advice is to use S3 for persistence. Similar to the heroku deploy there is an env file located at deploy/render/render_env.sh that is copied into the container at build time which sets a bunch of vars that you might need to update as a result.
I am the dev responsible for the docker setup at Baserow. Thanks for taking the time to figure out how to get Baserow running on Render. I briefly had a go a while back doing the same but also ran into problems with Baserow being too resource hungry for the free plan.
Would you mind if I cherrypicked/modified your fork from Github to release an official Baserow image for render? We would also add an installation guide specifically for running Baserow on render. Alternatively if you were able to raise an MR yourself on our gitlab repo at Merge requests · Bram Wiepjes / baserow · GitLab I’m also very happy to review and merge that way.
One question I did have was why you needed to split out the migrate command to be run manually after the deploy? Is the automatic migration that normally occurs on startup not possible for some reason with render?
With regards to setting other environment variables like the ones to configure S3, you should be able to just set those in your render yaml file’s envVar section. The deploy/xyz/xyz_env.sh files setup sensible defaults for a particular deployment platform but Baserow’s docker scripts will also just pass through supported env vars at container startup.
Finally I was wondering if there was a process or a way we could help to get a Baserow page added in your Docker quickstarts section? Perhaps first we would need to get it’s resource usage down so it runs acceptably on a free plan?
Absolutely! Please help yourself to anything, it would be great to have a Render option in the official repo.
On Render we don’t have a post deploy ability to run migrations just yet, so I opted for the manual option - unless of course I missed something that does the migration on startup as you’re possibly suggesting occurs.
For the s3 vars, they certainly could be in render.yaml as placeholders with sync:false which would present the UI to enter values as they’re deploying it.
Jun 28 02:14:28 PM 2022-06-28 18:14:28,985 CRIT unknown problem killing baserow-watcher (203):Traceback (most recent call last):
Jun 28 02:14:28 PM File "/usr/lib/python2.7/dist-packages/supervisor/process.py", line 432, in kill
Jun 28 02:14:28 PM options.kill(pid, sig)
Jun 28 02:14:28 PM File "/usr/lib/python2.7/dist-packages/supervisor/options.py", line 1251, in kill
Jun 28 02:14:28 PM os.kill(pid, signal)
Jun 28 02:14:28 PM OSError: [Errno 1] Operation not permitted
I also got this error when using render with Baserow.
Baserow’s all-in-one image internally uses supervisord to manage it’s various internal services. This supervisor process sometimes tries to SIGKILL these internal services (usually when something goes wrong). This error suggests to me that render is running containers without some relevant capability allowing kill signals to be sent. I’ll experiment further trying to work around this. I think the main goal here is ensuring the internal Baserow services shut down cleanly when the container shuts down.
An alternative solution I was thinking of is to provide a render.yaml which runs each of Baserow’s services as a separate service in render. We have a django backend service, a nuxt SSR web-frontend service, a celery worker and a cron worker atm. This will avoid this issue as our single service images are simpler and don’t use supervisord etc.
Glad to hear, i’ll post again with a link to our docs etc when ready.
And yup by default when our backend service starts up it applies migrations. Your render_env.sh has disabled this, but i’ll test out enabling it and doing it automatically
The deploy to render button doesn’t seem to work? It looks valid to me, I get a Missing Blueprint repository URL error when clicking it:
[](https://render.com/deploy?repo=https://gitlab.com/bramw/baserow/tree/master)
When entering the repo/branch manually with Render, I can’t select our master branch in the dropdown?
You’re not doing anything wrong here - looks like we have an issue with our Deploy to Render button and Gitlab. I’ve raised an issue internally to get it looked into.
