DevOpts for Rails Training

During the week of January 9-12th Rob Kaufman of notch8 led a class on dev-opts attended by developers and sys-admins from the digital library programming group, library IT and central ITS. The focus was on deployment strategies for rails based applications. The class began with an overview the basic components behind applications – servers (apache and nginx), rails modules such as passenger, standalone rails servers (puma, unicorn, thin, and webrick), database components (mysql, postgres, oracle), digital repository (fedora), and index applications (solr). The overview was also framed in terms of 12 factors – codebase, dependencies, config, backing services, build, processes, binding, concurrency, disposability, dev/prod parity, logs, and admin processes. Architecture of the application components was also key to understanding the parts and their various connections.

Deployment workflow traditionally has been a primarily manual process using ssh and command line for codebase, configuration, and server startup. Here we discussed more effective and efficient strategies in depth, namely capistrano, ansible, and docker. Capistrano is a methodology defining servers and basic commands for application code deployment so they’re encapsulated in basic commands. Ansible takes a role based approach that leverages recipes for the building of server components. Docker is a process that runs on top of the operating system kernel where “containers” consisting of the application and server environment are built, shipped and installed using using a basic domain language. In this context we explored continuous integration whereby these processes are integrated across the various environments (development, test, staging, and production) from which a living and breathing application is deployed using the code repositories and server configuration.

For the remainder of the course the class took a deep dive into creating deployment strategies for the main rails applications in the library: quicksearch and findit. As an exercise we broke up into groups and began working on docker implementations. Here we leveraged existing scripts currently in use in vagrant virtual-machine environments and translated them into docker containers. The challenges were many. First, as docker is layer based and built upon existing docker layers, we learned how to search the docker hub as a starting point for building the container, informed by choice of operating system, language, application, and their respective versions. Then through native package managers such as yum and apt-get, we exercised the process of getting all of the native libraries installed. Then the rails application code, including its dependencies in the form of ruby ‘gems’ were bundled in total creating a working docker image. Finally this image and images for external components (such as fedora,solr, mysql, and postgres), and environmental variables were orchestrated together using the docker-compose tool and stack-car convenience API to create a working application. By the end of the week a basic proof of concept for deploying containers using ansible and docker was generated, a pretty significant achievement! It is anticipated that the technology put in place through this week of training will be refined and expanded and what was once a laborious process will be optimized to the benefit all parties involved, developers, sys-admins, and most importantly the end user.

Print Friendly, PDF & Email