The CS Education community has developed many educational tools in recent years, such as interactive exercises. Often the developer makes them freely available for use, hosted on their own server, and usually they are directly accessible within the instructor's LMS through the LTI protocol. As convenient as this can be, instructors using these thirdparty tools for their courses can experience issues related to data access and privacy concerns. The tools typically collect clickstream data on student use. But they might not make it easy for the instructor to access these data, and the institution might be concerned about privacy violations. While the developers might allow and even support local installation of the tool, this can be a di cult process unless the tool carefully designed for third-party installation. And integration of small tools within larger frameworks (like a type of interactive exercise within an eTextbook framework) is also di cult without proper design.
This paper describes an ongoing containerization e ort for the OpenDSA eTextbook project. Our goal is both to serve our needs by creating an easier-to-manage decomposition of the many tools and sub-servers required by this complex system, and also to provide an easily installable production environment that instructors can run locally. This new system provides better access to developer-level data analysis tools and potentially removes many FERPA-related privacy concerns. We also describe our e orts to integrate Caliper Analytics into OpenDSA to expand the data collection and analysis services. We hope that our containerization architecture can help provide a roadmap for similar projects to follow. Copyright ©2021 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0)
Currently, the OpenDSA eTextbook project gives
instructors and students access to a hosted version of the
application for free. But this is not su cient for all institutional
users, or even for our own installation as demand and
subsequent computational load grows. In principle, OpenDSA
(being an open-source project) has supported users or
universities seeking to deploy their own copy. But this could
only be done by following a complex set of instructions.
This paper describes our work to simplify the installation
process. We have many motivations for this. At rst we
wanted to allow instructors to host this tool on their own,
both to reduce our server load and to avoid complications
when their University requires strong privacy restrictions.
Outsourcing in this way also lets them gain access to
additional student data that is being collected. So, this work
began as an e ort to create a new development environment
for OpenDSA that would work on any platform. Once we
saw the bene ts of this new development environment, and
realized the bene ts of keeping our development and
production environments as similar as possible, we started creating
the production environment described below. In particular,
we have now made it easy for the many students who work
on the project to easily spin up a complete development
environment for any part of the system, a great savings in
e ort for both those students and the project managers.
The OpenDSA system has two major parts that needed to
be containerized: a front-end content delivery server and a
back-end LTI and data collection server [
Containers are lightweight and portable packages of
software than can run anywhere their runtime is supported [
In order to containerize the existing OpenDSA architecture,
we rst had to investigate how the technologies that make
up the current stack could be split and containerized. The
current stack consists primarily of a Ruby on Rails
application (OpenDSA-LTI), a MySQL database, and an Nginx
web server along with several other tools and requirements.
Since OpenDSA and OpenDSA-LTI work by serving
content les to the LMS, these containers, described below in
Section 3.1, need to share a lesystem. Originally, these two
processes ran on the same host natively, so there were no
issues with where les were located as long as both
components were installed in the correct location [
The OpenDSA container includes the OpenDSA repository
(https://github.com/OpenDSA/OpenDSA). Python scripts
support compiling books to a speci c location on the shared
lesystem that OpenDSA will serve using the LTI container.
This repository also stores con gurations for the books to be
compiled from. The OpenDSA-LTI container contains the
code from https://github.com/OpenDSA/OpenDSA-LTI in a
Ruby container designed by Bitnami for Rails production
deployments [
OpenPOP's (https://github.com/OpenDSA/OpenPOP) container is structured in a way similar to the OpenDSA-LTI container. OpenPOP is an external tool that is used by OpenDSA through a di erent external tool, CodeWorkout, and this work includes OpenPOP in the installation rather than keeping it separate as it was done previously. OpenDSA uses MySQL as the database and provides that in a separate container.
In order to avoid negative impacts from using a database in
an ephemeral container, we use a Docker volume to mount
the database onto the host lesystem to preserve the data if
the container fails, and to allow the container to be restarted
separately for routine maintence. Finally, we include two
options for a web server container. For users who can acquire
their own SSL certi cates, this stack will have an option
to import those certi cates and use them in a Trae k web
server [
As the CS Education community grows, there is an increasing availability both for individual tools that need to be integrated into broader systems, and also integrated systems such as OpenDSA. In both cases, containerization can extend their use by other parties. As the number of these systems grow, the CS Education community needs to address how to keep all of these tools interoperable, and more available to instructors. We hope to provide a roadmap for other tools to follow to extend their reach. As issues around data access and privacy become more prevalent, hosting software on premises becomes more attractive to administrators, and the work presented here provides one method for doing so. In addition to the privacy bene ts, the roadmap explored in this paper provides a centralized data repository that is closer to the consumers and allows for greater access and additional analysis by the instructors. Containerization also provides a cloud-based install option using AWS or a more robust container orchestration system such as Kubernetes as a possibility.
While the e orts described in section 3 are ongoing, there
are several other future enhancements planned for the
platform. Currently, OpenDSA uses LTI 1.1, which is due to be
deprecated and will be upgraded into LTI 1.3. Along with
providing additional security, LTI 1.3 adds a new feature set
and an opportunity to connect OpenDSA with other
learning tools and platforms such as Caliper Analytics [