🔦 Feature: support read-only and non-root docker containers about nocodb

[salim-b]

@pranavxc I've submitted #8439, please have a look.

[pranavxc]

@pranavxc Extracting on the first run is unfavorable in the case of a containerized app since the extraction is repeated on every container restart (unless /usr/src/appEntry lives on persistent storage), which delays startup. And by adding a tar archive in the container image to be extracted at run-time, you actually _in_crease the storage requirements for the app at run-time.

I'm successfully using the above approach with the official Docker image, i.e.

FROM nocodb/nocodb:latest
RUN tar -xzf /usr/src/appEntry/app.tar.gz -C /usr/src/app/ && rm -f /usr/src/appEntry/app.tar.gz
COPY --link --chown=0:0 mystartup.sh /usr/src/appEntry/start.sh

(where mystartup.sh is the customized start-litestream.sh)

so I think it should work in general.

Would you welcome a PR?

Your concerns make sense, I will have a look at the Dockerfile and get back to you. Skipping compressing will increase the overall image size slightly and other than that no issues are there but I will double-check.

[tcurdt]

Regarding the non-root part, I'm concerned about existing users who have already mounted volumes if they migrate to the version where we're utilizing a non-root user.

One way could be to just allow for easy non-root user usage. That way it's up to the user to migrate - if they want.

But I think with good upgrade instructions it would not be that bad either. In the end it's just a chown - which maybe could even be baked into the Dockerfile. And nocodb is still pre 1.0. In the long run it certainly would be better to run as non-root.

[salim-b]

TBH I am not quite sure why an un-tar would be necessary at container startup at runtime over build time.

It is not. Simply removing the untar (also from the other start scripts)

nocodb/packages/nocodb/docker/start-litestream.sh

Lines 27 to 30 in 08dfcfa

	if [ ! -f "$FILE" ]
	then
	tar -xzf /usr/src/appEntry/app.tar.gz -C /usr/src/app/
	fi

and adding the following line to the Dockerfile at this position should suffice.

RUN tar -xzf /usr/src/appEntry/app.tar.gz -C /usr/src/app/ && rm -f /usr/src/appEntry/app.tar.gz

I wonder what @pranavxc thinks.

[pranavxc]

TBH I am not quite sure why an un-tar would be necessary at container startup at runtime over build time.

It is not. Simply removing the untar (also from the other start scripts)

nocodb/packages/nocodb/docker/start-litestream.sh

Lines 27 to 30 in 08dfcfa

	if [ ! -f "$FILE" ]
	then
	tar -xzf /usr/src/appEntry/app.tar.gz -C /usr/src/app/
	fi

and adding the following line to the Dockerfile at this position should suffice.

RUN tar -xzf /usr/src/appEntry/app.tar.gz -C /usr/src/app/ && rm -f /usr/src/appEntry/app.tar.gz

I wonder what @pranavxc thinks.

We are keeping our build as a compressed tar file to reduce the overall size, on the first run we are extracting the build and then proceeding. We will check how we can make it support read-only and non-root options.

[salim-b]

@pranavxc Extracting on the first run is unfavorable in the case of a containerized app since the extraction is repeated on every container restart (unless /usr/src/appEntry lives on persistent storage), which delays startup. And by adding a tar archive in the container image to be extracted at run-time, you actually increase the storage requirements for the app at run-time.

I'm successfully using the above approach with the official Docker image, i.e.

FROM nocodb/nocodb:latest
RUN tar -xzf /usr/src/appEntry/app.tar.gz -C /usr/src/app/ && rm -f /usr/src/appEntry/app.tar.gz
COPY --link --chown=0:0 mystartup.sh /usr/src/appEntry/start.sh

(where mystartup.sh is the customized start-litestream.sh)

so I think it should work in general.

Would you welcome a PR?

[pranavxc]

@salim-b: I've reviewed it, and I suggest removing the compression part entirely from the Dockerfile and keeping the build in the extracted state. If you're interested in collaborating on this, please let me know, or I can handle this aspect. Regarding the non-root part, I'm concerned about existing users who have already mounted volumes if they migrate to the version where we're utilizing a non-root user.

[dstala]

Please reopen this thread if you need further assistance