Developing Einstein 2.0

My last blog on Docker was on configuring a docker image for the main system (the web server and database). This one is (mostly) going to be above configuring a container to run user scripts. My main revelation since I wrote my last post was learning that docker containers were disposable thing not intended for data storage. For data persistence you need volumes where file and folders are mounted on to a docker. So I added a named volume to store the database, Django migrations and the secret key. Using a named volume means we're not dependent on the existence of a particular path within the host system to store the data, which make it easier to run on different operating systems. Running user submitted scripts was always going to the trickiest part of designing Einstein 2.0. So it always made sense to run them in separate docker containers from the main one. Our original plan was to control one of more containers from the main container using Docker's command line inter...

Having opted for a project which entails having one Dockerised application run another, getting to grips with Docker an inevitability. The first item on the agenda was to get something resembling a production environment running inside a container. Instinctively I opted for doing with within a single container. I started by basing the container/image on Alpine Linux a popular light-weight distribution which uses Busybox. While we had originally proposed to use MySQL for our production database, a little research on the topic showed that the Django developers recommend PostgreSQL. (They express far fewer caveats about it at any rate). FROM alpine:3 # apache runs on port 80 by default EXPOSE 80 # install system packages RUN apk add --no-cache python3 py3-pip postgresql15 apache2 apache2-ctl \ apache2-mod-wsgi py3-psycopg2 Using Alpine also allows us to take advantage of its convenient package manager apk . Here where thing got a little sticky however as apk installs an older...