Versions Compared

Old Version 2

changes.mady.by.user Andrew Stuart

Saved on

compared with

New Version Current

changes.mady.by.user Charles Hasegawa

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Charles Hasegawa, Tim Levett, Andrew Stuart

 

Note
titleConversation

Charles:

Apologies if this isn't quite the place, but rather than 50 comments that will become stale, I figured I'd use this as a "forum" for figuring this out and take it out after we have...

I see Docker being used as:

  • supplement to the build system. If a developer has Docker, they don't need Java nor any of the other build tools to build artifacts nor test or play with uPortal
  • A way for users to try out new releases of uPortal (and for those moving to uPortal, a demo system)
  • A way to build release images of uPortal all bundled up for cloud deployments.

Andrew Stuart suggested having DockerHub+GitHub integration where DH will automatically build official images. That might work for demo system (or a baseline), but I think if Apereo wants to publish official Docker images of uPortal, it is probably better to setup something else. travis-ci.org might be an acceptable way to setup multiple jobs to build and push images (I don't think there is a right or wrong answer here and I don't have strong feelings one way or another nor about what system is used, I just think we are going to need to build a menu of images).

 

Potential document outline:
  • Why docker?
    • Pros
      • Rapid application deployment (also, simplify movement to the cloud)
      • Portability across machines - what runs and works in one environment (dev or ops machine) will run the same elsewhere
      • Sharing - quickly share new portlets, code changes, etc. Can ease acceptance of new code (pull requests etc) into the community base by providing a simplified way to demo changes.
      • Simplified maintenance and upgrades. Java patch fixes security holes? Deploying a whole new cluster of Docker images is much much simpler than trying to patch real servers and testing each. 
      • Minimize environment needed to build, test, and work with uPortal. Ops and developers could work without having to download (the right versions of) Java, maven, groovy, gradle, Tomcat or Jetty, etc
    • Cons
      • Security. Asking folks to blindly pull down an image and run it as production code means having to explain the WHOLE stack (what Linux Kernel and patches are involved, which versions of Java, Tomcat (or other Java Servlet container), etc are being run.
      • Licensing???
  • Build process
    • Potential processes
      • Jenkins
      • Docker hub
    • How many images are built?
      • uPortal
      • Quickstart Database
  • Customization/Deployment approaches
    • Build a separate container FROM jasig/uportal:5
    • Simply overlay customizations using volume mounts at deploy time
  • Customization process
    • Build FROM jasig/uportal:5
    • Etc
    • docker-compose.yaml
    • kubernetes
  • Deployment process
    • kubernetes deployments
    • docker-compose/docker app bundles
    • ecs task definitions