• David Johnson's avatar
    Replace the Docker entrypoint/cmd/env implementation for augmented images. · a986a085
    David Johnson authored
    (Also, add support for user to change container entrypoint at runtime.
    Note also that the server side now stores the entrypoint/cmd/env
    attributes as base64url-encoded virt_node_attributes, so that we can
    just use the existing table_regex for those values.)
    We add a new runit service (/etc/service/dockerentrypoint) to
    clientside/tmcc/linux/docker/dockerfiles/common to handle the
    entrypoint/cmd/env/workingdir/user emulation.  From the comments:
      Docker's semantics for ENTRYPOINT/CMD vary depending on if those
      values are specified as arrays of string, or simple as single strings
      (which must be interpreted by /bin/sh -c).
      Handling all the quoting possibilities in the shell is a major pain.
      So, this script handles the basic stuff (in particular, sourcing env
      vars, because we want the shell to interpret them!) -- then execs our
      perl companion script (run.pl) to deal with the entrypoint/command
      files that libvnode_docker::emulabizeImage and
      libvnode_docker::vnodeCreate populated.
      libvnode_docker creates these single-line files in /etc/emulab/docker
      as either string:hexstr(<entrypoint-or-cmd-string>), or
      array:hexstr(a[0]),hexstr(a[1])... .  This allows us to preserve the
      original type of the image's entrypoint/cmd as well as the runtime
      entrypoint/cmd, and to preserve the exact bytes for the eventual final
      call to exec.
      The static files builtin to an emulabized image are
      /etc/emulab/docker/{entrypoint.image,cmd.image}, and those created
      dynamically at runtime if user changes the entrypoint or cmd are
      bind-mounted to /etc/emulab/docker{entrypoint.runtime,cmd.runtime}.
      Given the presence (or absence!) of those files, this script
      implements the emulation, based upon the content in those files.
GeniCM.pm.in 265 KB