Definition and publication of a Docker image

[ftomassetti]

It could be convenient for users to get access to a Docker image published in the official registry.

[joswarmer]

Good idea!

[joswarmer]

Would you prefer a docker image including Postgres + the repository-server, or just the repository-server?

[ftomassetti]

I would prefer to have one not including Postgres, as I guess one may want the flexibility to set it up in a particular way (and maybe use an installation running outside of Postgres). However I would not complaining if we had both docker images: one with LW Repo + Postgres and one with the LW repo alone (relying on an external Postgres)

[alessiostalla]

I think it's more common to have a separate image with just the application and to let the user combine it with other images (such as Postgres) possibly using something like Docker Compose. FWIW we built a Docker image of the Lionweb repository for development with the following Dockerfile:

FROM node
RUN git clone https://github.com/LionWeb-io/lionweb-repository.git
WORKDIR lionweb-repository
RUN git checkout a966193
RUN npm install
RUN npm run build
RUN npm run lint
WORKDIR packages/server
ENV PGHOST=postgres
CMD ["npm", "run", "dev"]

which has at least two issues: 1) it's referring to a random Git commit because there are no release tags 2) it's using npm run dev to launch the repo, I don't know what the command does but "dev" suggests it's not something for production :)

We then have a simple Docker Compose file to launch the Postgres DB and the Lionweb Model Repository together.

[joswarmer]

@alessiostalla Tnx, as I am new to docker and docker compose, could you also share the docker compose file?

[joswarmer]

I am running both images in the same container. From the hoist I can access both the database and the repository server. However the repository server still cannot connect to the postgres server: connect ECONNREFUSED 127.0.0.1:5432

[joswarmer]

Ok, got it running now, had to set the environment variable PGHOST in the compose file. Now the question is when and how often do we want to build the docker image and where do we want to publish it, so it is usable by others as well.

[joswarmer]

Could it be something like:

• always build and publish an image named "latest" when a PR is merged to main.
• build an image whenever a tag is created, named after the tag

[ftomassetti]

Could it be something like:

• always build and publish an image named "latest" when a PR is merged to main.
• build an image whenever a tag is created, named after the tag

I think both would be useful, but if I had to pick one I would prefer the second one (use tags), as to me having reproducible builds is what matters the most

[alessiostalla]

I agree with @ftomassetti , also I think – but I'm not super familiar with Docker either – that the "latest" tag is usually just a pointer to the latest tag e.g. "1.2.3". In other words "latest" points to a tag, not to the latest commit on the main branch. Maybe there's another name for that (say, "dev" or "nightly") but I'm not aware of it.

[alessiostalla]

Regarding our Compose file it's actually pretty simple and doesn't redeclare any env variables

[joswarmer]

@ftomassetti Can we close this?

[ftomassetti]

I think we have a local Dockerfile but we do not mention it in the Readme, and we do not publish it on the Docker registry (or I could not find it there):

[joswarmer]

Whenever you create a tag named version.* a docker image will be created and published on github. Could probably also publish on docker, but it would be under my own name. Docker is not easy to use for organisations, I therefore choose github.

[joswarmer]

It will show on the github homepage of the repository project under "packages", there is none now, but just try it.

[ftomassetti]

Would it makes sense to publish the first version? In this way we will have an example to refer to in the README. If I understand correctly one would need to:

• create the git tag version.0.1.0
• update the version in package.json to be 0.1.1

Is that correct? If it works for you I can do that

[joswarmer]

Yes, that sounds like a good idea.

[ftomassetti]

This is now done (I noticed the tag must be release.* to be picked up by the GitHub action doing a Docker release).

I created a PR to update the version (I did not feel like I could just commit on master) and I took advantage of the opportunity to add a few lines in the Readme about the release process and the docker image (#46 ).

I think this can now be closed. Thank you Jos!