Contributing Dockerfile

[vluz]

Hello!
I'd like to contribute a Dockerfile to the project.
Tested under Docker and Podman.
Happy to modify for any purpose and answer questions.

# Dockerfile

# To build:
# docker or podman build -t puter-podman .

# To run:
# docker or podman run -id -p 4000:4000 localhost/puter-podman
# NOTE: -it allows to see console output as container runs
# Point browser at localhost:4000
# Smile :)


# Start from node over Alpine
FROM node:hydrogen-alpine3.18

# Authors TODO: Add puter authors and uncomment
#LABEL authors="first author,second author"

# Set labels
LABEL repo="https://github.com/HeyPuter/puter"
LABEL license="AGPL-3.0,https://github.com/HeyPuter/puter/blob/master/LICENSE.txt"
LABEL version="v1.2.40-beta"

# Add git
RUN apk add --no-cache git

# Clone puter repo and install
RUN git clone https://github.com/HeyPuter/puter \
&& cd puter \
&& npm install \
&& npm cache clean --force

# Set working dir as /puter
WORKDIR /puter

# Expose default port 4000
EXPOSE 4000

# Turn off healthcheck
HEALTHCHECK NONE

# Start puter
CMD npm start

[KernelDeimos]

Earlier I stated that it wasn't needed yet since the environment requirements are trivial, but I've since changed my mind about that due to popular demand for a Dockerfile to be included in the repo.

This is one I wrote earlier and shared on Discord:

FROM node:21-alpine
RUN apk add --no-cache bash # useful for debugging
RUN mkdir -p /opt/puter/app
WORKDIR /opt/puter/app
COPY . .
RUN chown -R node:node /opt/puter/app
USER node
RUN npm install
EXPOSE 4000
CMD [ "npm", "start" ]

In your Dockerfile, what's the rationale for cloning the repo as a step in the build? I think it would make it inconvenient for people to build docker images for forks or with local changes.

[KernelDeimos]

I suppose it depends on where the Dockerfile is being used. Is there specific software (like CI/CD pipelines etc) you use where cloning the repo is more suitable than copying files from where the Dockerfile resides? Maybe we'll end up having different Dockerfiles for different use cases. I'm only familiar with pipelines where the software knows what branch to checkout, and then spins up a container using the Dockerfile at the head of that branch.

"it's best/common practice" - I see this statement a lot and I find it ignores nuance; we can't do something only because everyone else is doing it the same way, we need to understand why others are doing it that way. I'd be curious to know why the COPY . . approach causes issues.

[vluz]

There are indeed. A good example would be large teams with complex pipelines.
Imagine a large team divided into devs, ops, systems, quality, security, networks, procs, front desk and end users.
Very common even simplistic, for the sake of this example so it doesn't get too long.
Add legal, management, documentation, etc., etc., to be closer to reality.
Each bit does not (and often refuse) to touch what isn't their job. Only procedure people will make the cogs rotate.
Devs are busy with development, they do not touch the rest of the process. Usually are in another task well before the code goes live.
As soon as something is ready for production, procs people take over and push it down the pipe.
Quality assurance and security are usually next, they run their tests, approvals, paperwork.
Procs people will then do the paperwork associated with change and run it.
When approved, systems will assign resources, approve and allow ops to start building, usually in coordination with networks.
It'll go live according to live policy, timings and after other team bits are notified. Procs is responsible to notify all in sequence as it runs.
Front desk people will be noted that there was a change and where to report eventual troubles, usually backwards into project teams.
Documentation has to be drawn up or modified, etc, etc, etc.
In this kind of environment there are a ton of people involved in a ever-running process, involving many apps/services in all stages of the pipeline.
As you'd imagine COPY . . is not even a thing, my workstation can't have code in it that's going live, it's a large no-no.
Code sits in it's own place, not my job, I just put it to production when it's my time to turn my cog.
My dockerfile isn't here either, it gets drawn up and published to it's on place so other can check it, turning their own cogs.

The funny side is that even on smaller teams people tend to default to these standards of operation usually because it's what they've seen forever.

Best practices are there to avoid common mistakes and known troubles.
They are not written in stone but usually someone will ask you why it deviated from practice docs, company rules, etc.
If there is no solid reason to do so, best practices and common practice wins.
If one does not like to redo stuff one sticks to what is proven to work.

In sum COPY . . has many dots and it is unpractical, prone to troubles and errors not to mention undocumented, etc, etc. ad nauseam.
None of this is relevant to this project, I know. I didn't even think to do it in any other way, it's mechanical by now.

[KernelDeimos]

Thanks for the detailed reply, I appreciate that you took the time to paint that image so well. What you're describing as best practice then is best practice for publishing on Dockerhub, or providing deployment configuration for operations teams; am I understanding correctly? From the developer perspective, it can also be very useful to have a Dockerfile within the repo which uses local files. For example Dockerfiles for build environments typically do this (some projects have build dependencies that are difficult to consolidate with different Linux distros and package managers), although in this case it's usually a bind mount rather than a copy so that would be a more suitable choice for my example Dockerfile as well. Some CI servers will also pull from a specified branch and use the Dockerfile there, so in that case having it pull the repo would be redundant.

Where would you expect to find a Dockerfile for the use-case your describing; in root of the repository or elsewhere?

[vluz]

I've seen projects doing it both ways, some just drop a Dockerfile into the root of the repo, some create a dir for it.
People wanting it will look around for it and also look for a docker specific bit in the readme.

It's down to preference of the project owners.

I'll give my example, saw the news of the project at HN, thought that it was wonderfully cool and wanted to have try.
Searched for Dockerfile in root and for a docker-compose dir. Did not find it and just wrote one.
Only after having it running and getting back to give to project, I saw the people wishing for it and a couple of discussions around it.
File above is CC0, public domain or no license, I just wanted to give back to a project that put a smile to me.

[jelveh]

Thank you for taking the time to write the dockerfile, explaining the reasoning, and for contributing to Puter 💪
We both haven't slept much since last night but we'll push dockerfile soon after a short break.

[KernelDeimos]

@vluz somebody PR'd a very simple Dockerfile that I just merged, but I'm going to go through your Dockerfile shortly and add the labels and cache clearing you contributed.

I've also added this poll to continue this discussion and make a decision with the community. I actually think this is really interesting.