Add information about DENO_DIR about deno_docker

[hayd]

It can be overwritten by the user.

[hayd]

@bartlomieju what do you think about this: https://github.com/hayd/deno_docker/blob/master/example/Dockerfile

Do you think that DENO_DIR should be set in the parent(s)?

I use different layers, and cache that way. Is there some other way/something else which I am missing?

[hayd]

This could also be added:

RUN addgroup -g 1000 -S deno && \
    adduser -u 1000 -S deno -G deno && \
    mkdir /cache/ && \
    chown deno:deno /cache/
USER deno
ENV DENO_DIR /cache/

WORKDIR /app

[bartlomieju]

I believe that DENO_DIR should be controlled by the user, so it should be defined as late as possible. CC @zekth who has more experience with Docker

[zekth]

I believe that DENO_DIR should be controlled by the user,

I don't agree with this, we want to make sure the inner structure is owned by the dockerfile and could not be manipulated with the user. If the user wants to manipulate it i'd suggest to map it on the host or on a volume like:
docker run -v /MyLocalPathForCache/:/cache/ mydenocontainer

[hayd]

Should we use /deno-dir/ over /cache/ ?

[zekth]

Should we use /deno-dir/ over /cache/ ?

I think it's better to use the same naming yes.

[hayd]

I also create a deno USER, this could either be the default (it is now 😬 ) or have users set USER prior to deno execution (fetch/run).

[hayd]

I think this is sufficient now? @bartlomieju

Would probably be good to add an example of a multi container / shared volume ? I haven't done this myself / used multi container.

On re-reading is it you're saying it should be a directory shared with the host? Because I strongly disagree. I think the deps.ts is a good solution to minimize fetch/compile time... Sharing volumes with the host seems like an anti-pattern...?

[zekth]

@hayd depends. But the volume has to be documented, then if needed the user can share the host. For example it's fairly known to use this pattern with database containers.

[hayd]

Sharing with the host seems like a bad idea from a devops/production point of view 🤔, being self-contained as a container seems like a huge win! (see example)

I see why you may want to in a db container... though I'm in favor of stateless web applications and db as distinct server (and port map/forward to that).

Volumes are interesting: https://docs.docker.com/storage/volumes/
I think we can get away with just linking to them/suggesting they can be used?

[zekth]

Volumes are usable also in this case and can tackle the issue with sharing the volume i agree. But people tend to like mapping directly directories even if it's anti pattern. 🤷‍♂️