Hey all,

~2 years ago @lued wrote a Docker container to run ITFlow (again, thank you lued!).

There are a few issues around cron and email that need to be worked out. I don't really have the time or interest to maintain or support the container version. I am 99% sure @johnny feels the same. There's no point in keeping it around if it doesn't work as it's just frustrating for others.

Moving forward, we can either:

  • Get together a couple of community members that are willing to to help maintain it, or
  • Archive the repo

Is anyone interested in taking a look (and potentially looking after it in the longer term)?

wrongecho stickied the discussion .

With the exception of DockerFile not installing the whois package which would throw some errors during the cron tasks I can't see anything wrong with it. It installs packages with apt-get then entrypoint.sh sets up the VirtualHost, gits the repo and restarts apache.

    magixnetworks Hey! Wasn't aware of the whois issue. Cron isn't setup at all based on the issues raised there. Please do feel free to have a go at fixing it! 🙂

      Cron is being installed but much like the non-docker version setup would have to be done post-install after the cron key is generated. The problem with that is restarting the container will remove the cron job.
      The cron key would have to be generated earlier so it can go into entrypoint.sh to make it persistent.

      That being said the consensus is largely not to run cron inside a docker container anyway as it has to run as root and that's bad.

      a month later

      Bumping this again to see if there's any interest before archiving the repo.

      I spent a bit of time on this and was able to get cron to work but it would be lost as soon as the container is restarted.
      Cron is wiped if the container is recreated for any reason, the encryption key is generated too late in the setup process to recreate cron in entrypoint and cron itself can't be stored in a volume.

      The cron tasks themselves have to run as root inside the container so it would end up looking like this (Ignore the timings as I changed it to make it trigger faster)

      * * * * root /usr/bin/php /var/www/html/cron.php REDACTED
      * * * * * root /usr/bin/php /var/www/html/cron_ticket_email_parser.php REDACTED
      * * * * * root /usr/bin/php /var/www/html/cron_mail_queue.php REDACTED

      This was enough to get it working without any errors (including mailing out) but it's running as root…

      Whois and php-gd are both missing,
      Whois is easily fixed but even after installing php-gd the checks in setup.php still say it isn't installed.
      PHP is also outdated but this doesn't appear to impact much of anything

      Making this work would require ITFlow to generate the key much earlier or be able to supply your own key which would require I expect significant dev work on your side.

      I don't have alot of time currently to invest into it but in saying that the work needed on the docker itself is pretty minimal, but even then cron tasks running as root is enough for me to not use it in a docker anyway.

      @magixnetworks This is interesting, appreciate the effort you've put in.

      We are probably going to remove the requirement for a cron key in future versions. 25.1 will move cron scripts to the scripts subdirectory. Eventually we can use the logic we use in update_cli.php to ensure that php is invoked from the command line (in addition to .htaccess). But like you say, it's still running as root.

      The issue, to put it bluntly, is that neither Johnny or I are really interested in maintaining the Docker version. There are just so many extra considerations with Docker that I just don't care enough about. My experience with Docker containers like paperless-ngx is that I do a docker compose up and everything "just works". The docker version either needs to be a first-party citizen in the project and provide that "just works" functionality (ideally with some people that are willing to help support others using it) or we archive it.

      As you can see, I'm leaning towards archive. It can be unarchived at a later date, or maybe forked, but for now it's not something that I'm willing to volunteer any time towards.

        wrongecho Without the cron key it would be much easier to maintain, only have to be concerned about changes that require package updates (EG: php8.2 to 8.3). I could handle that.

        The docker side itself doesn't need much work, just needs php-gd to work and update to 8.2. The rest should work pretty seamlessly with ITFlow as it is..

        While testing it the functionality itself was as good as using a vm.

          I will take this project on and maintain the docker

          I will see if there is anything I can do about cron until such time as the key requirement is removed. And fix up the outdated/missing packages.

          Update

          I spent some time and created an updated Dockerfile and docker-compose.yml

          These are currently just on my github account, @wrongecho , do you have a preference on how this is managed?
          Either I merge my fork with your repo when there are changes or if you can make me a contributor to the existing repo I can maintain it directly.

          Changes:

          • The new build uses an Ubuntu 24.04 base and PHP 8.3.6
          • whois and php-gd are now installed by default and working
          • php.ini changes are made for upload/post size and execution time

          To do:

          • Cron tab
          • Upload new image to DockerHub (Currently building out of Dockerfile)

          Future:

          • Change base image to Alpine for a smaller footprint (Ubuntu is bigger but it just works)

          @magixnetworks

          Thank you for stepping up & sharing your Docker knowledge! I've added you as a contributor to the repo 🙂

          I have no idea if we have a DockerHub account or not. If we need one, my preference would be to create one under an @itflow.org email.

            Fantastic @magixnetworks Thank you for volunteering to be the maintainer of the docker repo. This will take a burden off of us to continue rapidly developing ITFlow.

            I agree with switching to alpine for a smaller base, it may also be worth bumping to the latest MariaDB and PHP 8.4 for an extra performance kick

            wrongecho

            Having a DockerHub account would be preferred. Users can build the image using the Dockerfile in the repo but updating this is a pain as there is no reference point for it to know when it needs updating.

                magixnetworks

                Nice updates to the repo so far, thank you! I've created a docker invite and invited you. The invite collaborator process is a little clunky so I have no idea if the invite made it to you - please let me know? 🙂

                    Your docker username is definitely magixnetworks?