Containerizing Torque
Created by: Nolski
Overview
I was thinking about this over the weekend and wanted to write down my thoughts on it. I couldn't find any existing issues on containerization although I know there was a discussion on it so @frankduncan feel free to direct me there as I know this issue has already been discussed on some level :)
The Problem
Developing torque either requires a VM, server, or machine running debian. Currently, I'd say OTS's development environment is running a server and either
- Making changes on the server via SSH, restarting any server bits, and syncing them down locally where you can commit using a secure ssh key or
- Making changes locally, committing, pushing, pulling, restarting any server bits that need to be restarted and repeat.
This requires developers to have a fair amount of knowledge to run a server, push and pull files between them fairly easily, and running through our ansible setup defined in a separate repository (which admittedly is fairly straightforward so long as you know which ansible scripts to run.)
My Proposal
We containerize both mediawiki with torquedataconnect and torque.
Containerizing medaiwiki w/ TDC:
Mediawiki already has a maintained container on dockerhub. We can easily extend that container by listing it as a dependency as in a stubbed out dockerfile below:
FROM mediawiki:latest
# Install any addons torque may need here
We would have a separate container for our torque server and perhaps further containers for databases as well which could easily be switched out for managed databases (such as AWS RDS). Running these services in tandem for development can easily be configured using something like docker-compose or if we want to not use docker we can use the kubernetes alternative kompose.
This allows us to have all of the development server hosting & configuration stored in version control, automatically set up in essentially one command for developers (i.e. docker-compose up
) and allow developers to easily change and test code without needing to host remotely.
I think containerization could potentially make maintaining our production servers easier as well by simplifying our deployment process to dumping an image into a VM. @kfogel @frankduncan do either of you have thoughts on this?
What would be needed
Obviously containers are new tech and would require some learning to be able to easily use. I think the net benefit would be worth the investment in the long run, especially if we ever want to have volunteer contributors. I am by no means an expert in setting up containerized applications, I'm also not a dev-ops person. However, I have containerized some applications in the past as well as helped configure some small Kubernetes clusters. It'd be great to hear if other OTS team members are interested in utilizing containers as well.