Skip to content

Latest commit

 

History

History
233 lines (154 loc) · 7.97 KB

PRESENTATION.md

File metadata and controls

233 lines (154 loc) · 7.97 KB
Raw
title theme revealOptions
SPARC in a bottle
night
transition
slide

SPARC in a bottle

Containerizing SPARCRequest

Disclaimer

I have no relevant personal/professional/financial relationship with products or companies presented today.

whoami

$ finger -s benton
Email            Name         Idle  Login  Office
[email protected]  Erik Benton   28d  Aug 31 OHSU OCTRI CRI Apps

Clinical Research Informatics - Applications

Oregon Clinical & Translational Research Institute

Oregon Health & Science University

Container crash course

(What is a container?)

  • Not a Virtual Machine
  • Virtualizes the OS and network but not hardware
  • Keeps things smaller, faster and portable

Note: Containers are a method of packaging an application and its dependencies into a single artifact that can be run on any system.

As opposed to a VM containers rely on the underlying host OS, making them more lightweight and quicker to run. Better resource allocation where as a hypervisor must partition its resources to each VM, containers use only the resources necessary

Security: VMs have more stringent security controls due to the complete independence of resource, but containers if run correctly can offer many of the same protections

Handy Definitions

  • Image - Executable package that contains all the necessary components of an application
  • Container - A running instance of an image

Docker logo

Docker

Note: Main developers/drivers of container technologies. Started in 2013 provided tools to take advantage of a number of Linux kernel features to make containers a reality and easy to use by a wide audience.

Why use it?

Consistency of environment and dependencies

Better resource utilization

Ease of deployment

Simplify developer experience

Why use it for SPARCRequest?

Note: Stack is not consistent with our other tools. Packaging as an image makes it easier to run with all the necessary tools included

Simplify packaging and deployment to servers

Environment isolation

How do we use it?

Two image build processes

  • octri.ohsu.edu/sparc-request-base
  • octri.ohsu.edu/sparc-request

octri.ohsu.edu/sparc-request-base

FROM ruby:2.5

ARG SPARC_VERSION=3.7.1
ENV LANG=en_US.UTF-8
# Add dependencies for Rails and the Paperclip gem
RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg \
      | apt-key add - && \
    echo "deb https://dl.yarnpkg.com/debian/ stable main" \
      | tee /etc/apt/sources.list.d/yarn.list && \
    apt-get update && \
    apt-get install -y \
    ghostscript \
    imagemagick \
    yarn \
    && rm -rf /var/lib/apt/lists/*

RUN curl -L -o sparc-request.tgz \
    https://github.com/sparc-request/sparc-request/archive/release-${SPARC_VERSION}.tar.gz && \
  tar xvf sparc-request.tgz && \
  mv sparc-request-release-${SPARC_VERSION} /sparc && \
  rm sparc-request.tgz

WORKDIR /sparc

RUN gem install bundler && \
    bundle install --without="development test" && \
    yarn install

EXPOSE 3000
CMD ["rails", "s", "-b", "0.0.0.0"]

Note:

  • Base image has no customization just vanilla build instructions
  • Checkout tag from Github

octri.ohsu.edu/sparc-request

FROM octri.ohsu.edu/sparc_request_base:3.7.1

COPY ./deps/sparc/assets/images/blank_logo.jpg /sparc/app/assets/images/logos/blank_logo.jpg
COPY ./deps/sparc/assets/images/octri_logo.jpg /sparc/app/assets/images/logos/octri_logo.jpg
COPY ./deps/sparc/database.yml /sparc/config/database.yml
COPY ./deps/sparc/development.rb /sparc/config/environments/development.rb
COPY ./deps/sparc/staging.rb /sparc/config/environments/staging.rb
COPY ./deps/sparc/production.rb /sparc/config/environments/production.rb
COPY ./deps/sparc/locales/*.yml /sparc/config/locales/
COPY ./deps/sparc/reports/*.rb /sparc/app/lib/reports/
COPY ./deps/sparc/tasks/*.rake /sparc/lib/tasks/
COPY ./deps/sparc/remote_service_notifier_job.rb /sparc/app/jobs/remote_service_notifier_job
...

Note: Maintain a development branch. Mostly back-ports of fixes, reports, localization files, etc.

Jenkins CI

  1. Build base image
  2. Build OCTRI image
  3. Merge all changes to main branch prior to release
  4. Job builds main branch
  5. Deploy to production

Note:

  • OCTRI image is built with every commit to the development branch
  • Maintaining separate development and master branches allows us to maintain versions and cherry-pick commits into our production instance

Kubernetes

Kubernetes

Note: Beyond simply running the container we use a container orchestration system, in this case a Kubernetes cluster, which runs on both VMs and physical systems. This ensures that the application is available and scaled appropriately.

What we learned

External configuration is crucial

SPARCRequest is opinionated

Delayed Jobs require their own container

Ruby on Rails make customization "easy"

Note:

  1. All configuration should be available to be set in the environment - a number of the configuration files required customization to use environment variables hence we maintain a set of patches to correct this

  2. SPARC must be run from the root context of a domain - much of the coffee script is context aware and thus prevents alternative deployment approaches.

  3. The delayed_jobs required its own container, because of various factors in the app it stopped working for us as a Cron - required by upgrade to 3.6 - delays in emails and calculations

  4. Because Ruby/Rails we are successfully able to customize our images to run in our environment.

Packaging in a container helps insulate our changes and requirements from the original SPARC software allow us to adjust SPARC to our needs rather than forcing the original SPARC code to adapt to us. It means we don't have to pollute our systems with a bunch of dependencies that we have to manage over time and allows us to use an immutable version of SPARC directly from the source.

References

Thank you!

[email protected]