Release/1.0.0

[BlackthornYugen]

TODO:

• [x] Use node18
• [x] Multi-arch build (dockerx)
• [ ] Update Dockerfile to use slim image
• [x] Manual tests

[BlackthornYugen]

@rtritto @shakaran if you have time to try it out, I've got a test image available on the Github Container Repo:

docker pull ghcr.io/blackthornyugen/mongo-express-docker:v1.0.0

@dozoisch after we are sure this is ready would you be able to provide us with permissions/credentials to publish to DockerHub and NPM?

[rtritto]

Instead of Docker, I'm using podman (v4.2.0) and on Windows with client v4.2.1.

After:

podman run -d -p 8081:8081 --name=mongo-express ghcr.io/blackthornyugen/mongo-express-docker:v1.0.1-rc

I get:

Error: crun: executable file `tini` not found in $PATH: No such file or directory: OCI runtime attempted to invoke a command that was not found

Note: Correctly work with mongo-express v1.0.0-alpha.4.

[BlackthornYugen]

@rtritto can you test ghcr.io/blackthornyugen/mongo-express-docker:v1.0.0 ?

I see that v1.0.0-rc is broken now. It has to do with how test/1.0.1-rc is trying to do a multistage build. I thought was using it earlier but I guess I was still using v1.0.0.

[BlackthornYugen]

Building v1.0.1-rc again from mongo-express master now.

https://github.com/BlackthornYugen/mongo-express-docker/actions/runs/3017751073

[rtritto]

With v1.0.0 I haven't the error of v1.0.1-rc

[dozoisch]

@BlackthornYugen yes! happy to grant NPM access... unfortunately for docker, I do not have publish access myself

[BlackthornYugen]

@BlackthornYugen yes! happy to grant NPM access... unfortunately for docker, I do not have publish access myself

Thanks!

If you are able to grant repo access for mongo-express-docker, I belive this MR will be able to push containers to the Github Container Registry for now. That's currently what's happening on my fork.

[BlackthornYugen]

@rtritto it looks like the build on my test branch is broken, I probably won't have time to fix test/1.0.1-rc today but I'll let you know when it works. If you have some minutes you should be able to build it with podman build --tag localhost/mongo-express . but it looks like apt install is failing for some reason.

[rtritto]

Can you try this?

Dockerfile

...
- RUN apk -U add --no-cache bash tini
...
- ENTRYPOINT [ "tini", "--", "/docker-entrypoint.sh"]
+ ENTRYPOINT [ "/docker-entrypoint.sh"]
...

Edit: I buit the image correctly

[dozoisch]

@BlackthornYugen I've tweaked the settings on GitHub to grant access to the docker repo in the docker team you created, and I've sent you an email to the address on your profile for NPM access!

[shakaran]

@BlackthornYugen I've tweaked the settings on GitHub to grant access to the docker repo in the docker team you created, and I've sent you an email to the address on your profile for NPM access!

Would be nice if you can add me as maintainer in mongo-express and rtritto if he wants too, since we are together pushing to new version hard ;)

[rtritto]

Would be nice if you can add me as maintainer in mongo-express and rtritto if he wants too, since we are together pushing to new version hard ;)

Sure, I will continue to support!

[shakaran]

Changing to master branch in the dockerfile I can build the lastest. See my fork branch

https://github.com/mongo-express/mongo-express-docker/compare/master...shakaran:mongo-express-docker:master

https://github.com/shakaran/mongo-express-docker/blob/master/Dockerfile

[rtritto]

We must use yarn instead of npm because the mongo-express project is yarn based (yarn.lock file instead of package-lock.json). yarn is already installed in node image.

[BlackthornYugen]

Changing to master branch in the dockerfile I can build the lastest. See my fork branch

master...shakaran:mongo-express-docker:master

https://github.com/shakaran/mongo-express-docker/blob/master/Dockerfile

Looks good, but I don't think the cp config.default.js config.js is needed since the logic now uses the union of config.default.js and config.js. config.js doesn't need to exist if we are not modifying default config.

[MahdiAbbasi95]

@BlackthornYugen If you need any help on this task, I have time to contribute on it.

[BlackthornYugen]

@BlackthornYugen If you need any help on this task, I have time to contribute on it.

Thanks! I’m pretty sure I can get it figured out once I am able to get on a keyboard for more than 5 minutes but that is probably a few days away. I’ve given access to push changes to this branch so that I’m not holding this up. 😅

I expect to have more time on Thursday and Friday.

[rtritto]

@BlackthornYugen @shakaran @MahdiAbbasi95 I did some changes and seems that it works! (Please take a look and test if needed) A rebase is needed.

[MahdiAbbasi95]

@BlackthornYugen @shakaran @MahdiAbbasi95 I did some changes and seems that it works! (Please take a look and test if needed) A rebase is needed.

I did other changes and it was ok in my tests. please check it. Also, the size of the Image is decreased to 380MB ( the previous size was 421MB )

https://github.com/BlackthornYugen/mongo-express-docker/blob/dockerfile/Dockerfile

[rtritto]

I did other changes and it was ok in my tests. please check it. Also, the size of the Image is decreased to 380MB ( the previous size was 421MB )

https://github.com/BlackthornYugen/mongo-express-docker/blob/dockerfile/Dockerfile

Nice. If some command fails, RUN should stop, so I replaced some ; with &&:

RUN set -eux; \
    tar xzf /app/${MONGO_EXPRESS_TAG}.tar.gz --strip-components 1; \
    rm -f /app/${MONGO_EXPRESS_TAG}.tar.gz \
    && chmod +x /docker-entrypoint.sh \
    && apk -U add --no-cache \
                bash \
                # grab tini for signal processing and zombie killing
                tini \
    && yarn install
    # && yarn run build     # prepublish already run build

[MahdiAbbasi95]

I did other changes and it was ok in my tests. please check it. Also, the size of the Image is decreased to 380MB ( the previous size was 421MB ) https://github.com/BlackthornYugen/mongo-express-docker/blob/dockerfile/Dockerfile

Nice. If some command fails, RUN should stop, so I replaced some ; with &&:

RUN set -eux; \
  tar xzf /app/${MONGO_EXPRESS_TAG}.tar.gz --strip-components 1; \
  rm -f /app/${MONGO_EXPRESS_TAG}.tar.gz \
  && chmod +x /docker-entrypoint.sh \
  && apk -U add --no-cache \
                bash \
                # grab tini for signal processing and zombie killing
                tini \
  && yarn install
  # && yarn run build     # prepublish already run build

Also, I've done a security scan on the new image which was created by the new version of Dockerfile and the result of the test was:

Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 1)

CRITICAL: AWS (aws-secret-access-key)
══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
AWS Secret Access Key
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 /app/Dockerfile:12
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  10    && curl -fSL "https://github.com/krallin/tini/releases/download/v${TINI_VERSION}/tini.asc" -o /usr/local/bin/tini.asc \
  11    && export GNUPGHOME="$(mktemp -d)" \
  12 [  && key=**************************************** \
  13    && ( gpg --batch --keyserver hkps://keyserver.ubuntu.com --recv-keys "$key" || gpg --batch --keyserver hkps://keys.openpgp.org --recv-keys "$key" ) \
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

The only issue was in the Dockerfile that is in the main repo (tag v1.0.0) that will be update on the main repo and it's not an issue in our new image, except this, we didn't have any security issue for the new image.

[BlackthornYugen]

@MahdiAbbasi95 seems like a false positive. Public keys are not sensitive. Does calling the variable something else, maybe public_key_handle get rid of the warning?

[BlackthornYugen]

I've tests that this works by tagging f329171 as v1.0.0 and triggering this action: https://github.com/BlackthornYugen/mongo-express-docker/actions/runs/3044909048/jobs/4905815573

We still need to rebase though right?

[BlackthornYugen]

The action also currently matches the repo name ( ghcr.io/blackthornyugen/mongo-express-docker:v1.0.0 ) , that'd be fine if we had this building from the mongo-express repo (future goal) but now now maybe it should be hard-coded to mongo-express.

[BlackthornYugen]

I think I understand how to update the official image now, so I've removed the workflow for ghcr from this change.

[bdupont-hvs]

Hi,

Ty for this new release :)

When can we expect to see this image on https://hub.docker.com/_/mongo-express ?

[BlackthornYugen]

Hi,

Ty for this new release :)

When can we expect to see this image on https://hub.docker.com/_/mongo-express ?

Thanks! Hopefully be available soon! This is still a bit of a learning experience for me. I think we just need to wait for the pull request to the docker library to be approved.

[rtritto]

The old method install mongo-express directly from npm registry (with no install devdependencies and no build step). The new method download from repo (more time to install devdependencies and build step). Is the old one better? @BlackthornYugen @shakaran @MahdiAbbasi95

[BlackthornYugen]

Might be better? My thought was that this way is more flexible. We can consider going back to the old way for the next release but I think we should try to get 1.0.0 out first.

[BlackthornYugen]

CC: @knickers

[rtritto]

Might be better? My thought was that this way is more flexible. We can consider going back to the old way for the next release but I think we should try to get 1.0.0 out first.

Better for less image space (no devdependencies) and less build time (no install devdependencies and no build step).

[BlackthornYugen]

Might be better? My thought was that this way is more flexible. We can consider going back to the old way for the next release but I think we should try to get 1.0.0 out first.

Better for less image space (no devdependencies) and less time (no install devdependencies and no build step).

I'm convinced. :)

I think it'll probably be at least another day before we get 1.0.0 done so if someone can make a PR to revert back to the NPM way lets do it. I'd also like to make sure basic auth is disabled for 1.0.0 by default. Having admin:pass as the default credential isn't really adding security and is going to cause issues for long term users that have already got authentication handled at a load balancer.