Run Laravel schedule in docker image using supervisord

[JonathonReinhart]

This PR updates the docker image so that artisan schedule:run is executed every minute by a supervisord command.

Since it seems that Laravel Task Scheduling is preferred over creating various crontab entries, this should cover all of snipe-it's needs. If everyone can agree to this, then this effectively fixes issue #6344. If not, then I'll have to modify this to use cron (see below).

Cron

History:

• Issue Enable cron on Docker container/Enable automatic LDAP Imports on docker container. #5502 was an early issue opened about cron missing from the Docker image.
• PR Added cron to list of packages #5502 #5729 added the cron package but didn't arrange to actually run cron.
• PR Disable file browsing #5922 again added cron to the list of installed packages.

Using cron to run the Laravel schedule is problematic because cron doesn't preserve the outside environment variables. This is especially unfortunate for Docker containers where the Docker-provided environment is the key source of configuration.

While there is a method to access the docker-set environment variables from the cron job, the whole thing seemed overkill.

Supervisor

Rather than using tini, Supervisor is added to the docker image and is used to start apache2 and run the Laravel schedule in a simple sleep loop.

I also considered forego, which was preferred over supervisor by nginx-proxy/nginx-proxy#165. Unfortunately, it didn't work well; sending SIGINT to forego failed to properly shut down apache. Also, this wouldn't have provided as clean of a solution for the Laravel schedule.

Testing

I temporarily made the following change in my running Docker container.

diff --git a/app/Console/Kernel.php b/app/Console/Kernel.php
index 371362442..f84a00505 100644
--- a/app/Console/Kernel.php
+++ b/app/Console/Kernel.php
@@ -45,7 +45,7 @@ class Kernel extends ConsoleKernel
         $schedule->command('snipeit:inventory-alerts')->daily();
         $schedule->command('snipeit:expiring-alerts')->daily();
         $schedule->command('snipeit:expected-checkin')->daily();
-        $schedule->command('snipeit:backup')->weekly();
+        $schedule->command('snipeit:backup')->everyMinute()->appendOutputTo("/tmp/backup.log");
         $schedule->command('backup:clean')->daily();
     }

After a few minutes:

• I navigated to http://localhost:8888/admin/backups and saw that several backups had been created.
• I saw that the following had been written to /tmp/backup.log:

  Starting backup...
  Dumping database snipeit...
  Determining files to backup...
  Zipped 19 files...
  Copying 2019-01-19-063352.zip (size: 32.82 KB) to disk named local...
  Successfully copied .zip file to disk named local.
  Backup completed!
  

• I verified that the backups created in /var/lib/snipeit/dumps/ were owned by docker:staff
• I verified that I could still create a backup by clicking

[JonathonReinhart]

Interesting to note: there's also a Golang port of supervisord, which could help minimize the docker image size.

[snipe]

@uberbrady can you take a look at this when you get a moment?

[snipe]

I just realized this PR is against master. Can you make it against develop please, per the contributing documentation? Thanks!

[adoering-te]

@JonathonReinhart were you able to rerun the code against develop so that this could be merged? Would make fixing our gaps easier. Appreciate the PR by the way! :)

[snipe]

Thanks for this contribution. In the future, please try to follow the contributing documentation so we can merge these more quickly.