Next version: simplify down and use .s3cfg

[nickbreen]

It's easier to just use .s3cfg rather than fiddling with all the env vars.

E.g. this actually works!

  environment:
    S3_CFG: |
      [default]
      access_key = XXXX
      secret_key = XXXX
      bucket_location = ap-southeast-2
      default_mime_type = application/x-gzip
    CRON_D_BACKUP: |
      @reboot root ln -s /etc/container_environment/S3_CFG /root/.s3cfg

      @daily root (tar cz --verbose /var/www/wp-content/uploads | /usr/local/bin/s3cmd --verbose put - $$(cat /etc/container_environment/BUCKET)uploads.tar.gz) 2>&1 | logger --tag uploads

      @daily root (/usr/bin/mysqldump -uwordpress -pwordpress -hdb -B wordpress | gzip | /usr/local/bin/s3cmd --verbose put - $$(cat /etc/container_environment/BUCKET)db.tar.gz) 2>&1 | logger --tag db

There's a @reboot job that sets up the user's .s3cfg file, which all the other jobs use.

This allows for far simpler cron job spec's and permits trivial specification of arbitrary jobs and arguments.

[nickbreen]

/backup.sh and /restore.sh can just be refactored to use command line arguments as well as environment variables to make them useful in this situation.

[nickbreen]

Also, rely on S3 versioning rather than timestamping filenames.