Optimising Dockerfile

[modem7]

Heya, great project! Looking forward to using it, hope you don't mind the PR!

Changes

• Optimised Dockerfile for BUILDKIT (approx 35% buildtime improvement)
• Fixed Dockerize (was using Ubuntu version, not Alpine) + raised an issue (https://github.com/jwilder/dockerize/issues/180) about UID:GID.
• Changed how Dockerize was downloaded to reduce the amount of steps/layers.
• Added VOLUME for frontend so if a user inputs something wrong in the compose file, it'll still create a volume and function.
• Added requirements.txt as this allows for easier updating via automated github tools such as dependabot/renovate.

---

Things to note:

• There is an issue here where the output is "Error starting command: "-wait - exec: "\"-wait": executable file not found in $PATH" (on current version and also tested on ghcr.io/eugeny/tabby-web:latest just in case it was my build) https://github.com/Eugeny/tabby-web/blob/156341173a42de346b1785602961da40d77a3c66/backend/manage.sh#L2
• Cryptography package seems quite out of date? Current version is 37.0.4. It also seems to be built twice, once in pip + once in poetry? As a note, for multiarch builds, cryptography takes to build ages on ARM under QEMU.
  • Potentially consider a Pypi index (such as https://wheel-index.linuxserver.io/alpine-3.16/ or https://github.com/modem7/PyPI) to reduce pip package build times if you go down the multi-arch route in ghcr.
  • As an addendum, using the index method, I managed to reduce the Borgmatic project build times from ~1 hour to ~6 minutes.
• Image is optimised for buildkit/buildx. This may cause a problem with users building their dockerfiles unless they do DOCKER_BUILDKIT=1

---

Happy to discuss any changes/concerns!

[Eugeny]

Wow, this is fantastic! Nice trick with <<EOF, I'll use it in my other projects :D

• The cryptography package that is now in requirements.txt is a dependency of poetry, and at the time, latest cryptography required Rust to build and didn't have wheels available (it's not used in the runtime anyway).
• The manage.sh is a bug indeed - before dockerize there used to be a wait script in /wait.
• I'll mention the buildkit requirement in the Readme
• I don't have a machine to test arm64 builds on unfortunately but will be happy to merge

P.S. check out the build failure, the new dockerize URL isn't available for arm64

[modem7]

Wow, this is fantastic! Nice trick with <<EOF, I'll use it in my other projects :D

• The cryptography package that is now in requirements.txt is a dependency of poetry, and at the time, latest cryptography required Rust to build and didn't have wheels available (it's not used in the runtime anyway).
• The manage.sh is a bug indeed - before dockerize there used to be a wait script in /wait.
• I'll mention the buildkit requirement in the Readme
• I don't have a machine to test arm64 builds on unfortunately but will be happy to merge

P.S. check out the build failure, the new dockerize URL isn't available for arm64

Heya, glad it's acceptable!!

• For cryptography, do you know if we can use the latest version? (I'm thinking more about build speed rather than anything else)

• Unfortunately I can't test arm builds on my machine, I can only build em! The curse of QEMU :-P.

• Hmmmm, I'll play around with that dockerize URL, that shouldn't be the case, probably a weirdo typo.

  • Given dockerize isn't going to be getting any updates (looks like a dead project), is it worthwhile going back to a wait.sh or similar as it's more maintainable?

[modem7]

Instead of Dockerise, would something like https://github.com/vishnubob/wait-for-it be a better solution (which I'm guessing is similar to what you used to have)?

This would both reduce dependencies on an extra (outdated) binary, and make things lighter as well (and kill two birds with one stone).

[Eugeny]

wait-for-it looks pretty good - I don't have any specific preference as long as it works

As for cryptography, going for a more recent version is fine (the one that's explicitly installed in the Dockerfile is only used in the build stage anyway)

[modem7]

Heya,

What I'll do for now is revert the Dockerize URL so it downloads.

Then we can create another PR/do more testing on wait-for-it.sh etc etc etc in another PR.

That way we don't change too much too quickly causing issues if we need to revert.

Mostly also because work is taking up a lot of my time at the mo, so additional testing will take a while for me to investigate.

I'd say priority wise:

• Look at potentially merging our current changes,
• Update cryptography/poetry and see if it's happy
• Look at wait-for-it etc

At some point, the dockerfile really needs investigating properly as building the backend + frontend like that may (read: probably will) cause issues later down the line. The last stage in the multistep build should be a single image with everything running together (if doing multi-service in one).

I'd say it should be relatively simple to just use the start script to start both services at once.