Provide a Docker/OCI packaging example

[plaird]

Internally at Salesforce, we don't do anything super elaborate when we package up Spring Boot services into Docker containers. But we have some nice idioms that could be helpful for others.

We probably shouldn't create anything we will maintain, but having some code samples/docs would be nice. We have about a dozen attributes we pass into our docker packaging rule.

In addition, there are two specific techniques for Spring Boot applications in Docker images. This article explains them:

• Spring Boot apps should be extracted upon copy into the Docker image. Running from the executable jar is slower.
• Once we implement the layer layout for the springboot rule (#69) we should suggest how to write the Dockerfile to take advantage of that

I think it would be best to do this example in a new branch, much like the Kotlin example branch.

Also consider an alternate example that uses the CloudNative buildpack for Spring Boot:

• https://github.com/paketo-buildpacks/spring-boot

[plaird]

Note that there is example code for building a docker image provided in the discussion of Issue #69.

[plaird]

This is the param doc for our internal docker image rule. I have replaced sensitive info with 'xyz' in the below:

 Required arguments:

   name: the name of this rule

   maintainer: email address of team owning this docker image
               (will be set as "maintainer" label)

   srcs: list of file producing labels, to include in the docker image. For
          typical Scone services, this list should include a reference to
          the springboot target defined in the same BUILD file

   ports: list of ports the service listens on

   runtime_jdk: points to the JDK binary to copy into, and use in, the docker
               image.  This is a Bazel label //tools/jdk:xyz-jdk11

 Optional arguments:

  jarname: the executable jar to run as entrypoint. If this argument is not
           specified, the jar used will be defaulted based on the specified
           srcs.

  java_opts: array of string arguments specified before the jar name, including
             system properties. Be sure to escape regex characters (such as /)
             with a backslash (\/)

  main_args: array of string arguments specified at the end of the cmdline (ie
             passed do your service's main method)

  env: dictionary of environment variables to set in docker image

  directory: the directory to copy the docker file into, defaults to /home/xyz-user

  workdir: the working directory to run the entrypoint in, if unset, defaults
           to the value of the 'directory' attribute

  logic_snippets:  bash shell scripts that are inserted into the standard entrypoint prior
           to launching the service

  makedirs: list of directories (paths) to create under /var/xyz_files.
            /var/xyz_files is the only writable location for the xyz-user
            user.

  base:      the base docker image to use

  user:      defaults to xyz-java, the default user in the default base docker
             image. Should only be set if a custom base docker image is
             specified

 For other optional arguments that you may set, see:
   https://github.com/bazelbuild/rules_docker

 Some other useful arguments are:

 data_path: Set to "." to preserve directories in relative paths.
            For example, if you have srcs = ["src/main/blah/MyFile"], by
            default MyFile will be copied to the docker image without its
            leading path. With data_path = "." set, the leading path will
            also be copied to the docker image

 Note that we do not allow some arguments to be set, such as:
   - entrypoint
   - main_class
   - tars

 If you have a good use-case for needing to set these, please come and talk
 to us.

 The following environment variables are honored (see entrypoint.sh):

 - JAVA_OPTS - if set, the value of ${JAVA_OPTS} is added to the java cmdline,
               before the jar name.
 - MAIN_ARGS - if set, the value of ${MAIN_ARGS} is added to the java cmdline,
               after the jar name