CLAassistant
commented
6 months ago
All committers have signed the CLA.
Closed TheRealGramdalf closed 6 months ago
CLAassistant
commented
6 months ago
All committers have signed the CLA.
TheRealGramdalf
commented
6 months ago FYI: I haven't thoroughly tested that the image runs as intended; for a more in-depth review, I recommend using dive with Show Aggregated Changes (ctrl + a) and Hide Unmodified (ctrl + u). This should show a complete list of all files changed relative to the base image (FROM). The image builds successfully, running the WebUI has not been tested.
marcelfolaron
commented
6 months ago Thank you. This looks great! I didn't know that calling RUN multiple times had an impact on image size!
TheRealGramdalf
commented
6 months ago Apologies if it wasn't clear, but this doesn't actually fix https://github.com/Leantime/leantime/issues/778 (yet) - this was mostly just cleaning things up in preparation for migrating baseimages. I still need to actually make the switch to lsiobase/nginx.
In order to do so, however, I need to know the answers to the following questions - it probably wasn't clear in the PR message itself.
cableman0408 (Discord): I can confirm that leantime runs fine on PHP 8.3 🙂
apk packages) and list what each of them is used for? For example, are libzip-dev and zip actually required at runtime, or are they only needed for installation (e.g. unzipping the release tarball from github (this specific case uses tar, which is part of coreutils, but you get the idea))The reason multiple RUN directives have such an impact is because each layer stores whatever files have been changed, in their entirety - if you RUN chmod +x on a 700GB file, the resulting image will be 1.4TB, since the new layer (which has the +xd file) stores a complete copy - which is the main difference between overlay2 and other CoW filesystems like ZFS/BTRFS (and I suppose bcachefs now as well), which only store the delta (and backreference unchanged blocks).
This only really affects image size if you modify a single file in multiple layers - this is most prominent with php-ext-install, since it modifies the opcache files, storing a new copy each time. Again, take a look at dive leantime/leantime:3.0.7 for a more visual idea if you like.
marcelfolaron
commented
5 months ago Hey,
Sorry this may have been me as well. To answer your questions:
The LSIO team typically sticks to whatever version alpine has in it's repositories - in this case the most pertinent would be PHP. Their NGINX baseimage runs on PHP 8.3, whereas afaik Leantime currently runs on 8. Is version 8.1 needed specifically, or would migrating to 8.3 be fine?
In terms of future updates, are you okay to just follow LSIO (and therefore alpines' PHP updates), or would you prefer to build the base image yourself?
Is apache needed for any particular reason? LSIO already has an alpine-nginx baseimage which has PHP pre installed - since leantime already works with nginx, it might make sense to just use that instead (unless there are licensing issues etc) - the LSIO team considers NGINX to be more popular, at least among the self-hosted community
Dependencies: Are you able to go through the list of dependencies (both PHP plugins and apk packages) and list what each of them is used for? For example, are libzip-dev and zip actually required at runtime, or are they only needed for installation (e.g. unzipping the release tarball from github (this specific case uses tar, which is part of coreutils, but you get the idea))
PHP: mbstring - for all string manipulation do/mysql - database gdlib (could move to imagick as well not sure which one is easier/better) curl to talk to server for plugins and updates bcmath opcache ldap (for our ldap connector) zip XML (we use simple_xml() for all kinds of xml management) Phar (readonly) plugins are packaged as phar files
Server libzip (for unzipping plugins) image manipulation (gd or imagick) curl (talk to server for plugins, marketplace and updates) json/xml openssl (for some light encryption) ldap (ldap connection management) mysql client
Not sure if this covers it all but I think it should address the most important ones.
Sincerely, Marcel
On Tue, Mar 12, 2024 at 2:15 PM TheRealGramdalf @.***> wrote:
Apologies if it wasn't clear, but this doesn't actually fix Leantime/leantime#778 https://github.com/Leantime/leantime/issues/778 (yet) - this was mostly just cleaning things up in preparation for migrating baseimages. I still need to actually make the switch to lsiobase/nginx https://github.com/linuxserver/docker-baseimage-alpine-nginx.
In order to do so, however, I need to know the answers to the following questions - it probably wasn't clear in the PR message itself.
Versioning:
The LSIO team typically sticks to whatever version alpine has in it's repositories - in this case the most pertinent would be PHP. Their NGINX baseimage runs on PHP 8.3, whereas afaik Leantime currently runs on 8.1.
cableman0408 (Discord https://discord.com/channels/990001288026677318/990001288626466868/1214683811124879420): I can confirm that leantime runs fine on PHP 8.3 🙂
Is version 8.1 needed specifically, or would migrating to 8.3 be fine?
In terms of future updates, are you okay to just follow LSIO (and therefore alpines' PHP updates), or would you prefer to build the base image yourself?
- Is apache needed for any particular reason? LSIO already has an alpine-nginx https://hub.docker.com/r/lsiobase/alpine.nginx baseimage which has PHP pre installed - since leantime already works with nginx https://docs.leantime.io/#/installation/configuration?id=nginx-configuration, it might make sense to just use that instead (unless there are licensing issues etc) - the LSIO team considers NGINX to be more popular, at least among the self-hosted community
- Dependencies:
- Are you able to go through the list of dependencies (both PHP plugins and apk packages) and list what each of them is used for? For example, are libzip-dev and zip actually required at runtime, or are they only needed for installation (e.g. unzipping the release tarball from github (this specific case uses tar, which is part of coreutils, but you get the idea))
The reason multiple RUN directives have such an impact is because each layer stores whatever files have been changed, in their entirety - if you RUN chmod +x on a 700GB file, the resulting image will be 1.4TB, since the new layer (which has the +xd file) stores a complete copy - which is the main difference between overlay2 and other CoW filesystems like ZFS/BTRFS (and I suppose bcachefs now as well), which only store the delta (and backreference unchanged blocks).
This only really affects image size if you modify a single file in multiple layers - this is most prominent with php-ext-install, since it modifies the opcache files, storing a new copy each time. Again, take a look at dive leantime/leantime:3.0.7 for a more visual idea if you like.
— Reply to this email directly, view it on GitHub https://github.com/Leantime/docker-leantime/pull/73#issuecomment-1992275476, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALG4EFU642DE7ZH3VCXCFITYX5A43AVCNFSM6AAAAABEJPWMRCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJSGI3TKNBXGY . You are receiving this because you modified the open/close state.Message ID: @.***>
This is phase one of my attempt to fix https://github.com/Leantime/leantime/issues/778. Changes include:
Dockerfileto become more linearcurltotar(incl. setting permissions)apk add --no-cachedoes not requireapk updateRUNdirective to reduce sizedThe image should be functionally identical, as space savings were purely with layer/command optimization. Future phases may include a rebase to https://github.com/linuxserver/docker-baseimage-alpine-nginx to facilitate PGID/PUID mappings and regular base OS updates if the Leantime Team is amenable.