Docker, part 2: The Pointless Sequel

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 interface.

In practice the complexity of trying to coordinate more than one docker container was too much, and the overhead of running a script using docker run or docker exec was just too high for speedy script execution so an alternative method had to be found, such as using rsh or ssh or similar. Ultimately I opted for writing a execution daemon which would live on the "dirty" container and execute userscripts directly. The execution daemon acts like a shell but communicated in JSON. The other mode of communicate between the two containers is a shared temporary directory in which the script daemon can write files for the execution daemon to execute.

The now single "dirty" container is much simpler that the main container. It just contains enough to run the execution daemon and whatever scripts students are asked to write in - at the moment only Python and Java. Like the main container it also uses an Alpine Linux image.

    FROM alpine:3

    # install some packages
    RUN apk add --no-cache python3 openjdk17-jdk

    # copy scripts
    COPY *.sh *.py /usr/local/bin/
    RUN sh -c "chmod 755 /usr/local/bin/*.sh /usr/local/bin/*.py"

    STOPSIGNAL SIGINT

    # entry point
    CMD init.sh

Most of the action happens in the compose.yaml file which sets the tcp/ip port and volume options for both containers

    services:
      clean:
        image: einstein:latest
        container_name: bohr
        volumes:
          - einstein_tmp:/einstein_temp
          - einstein_run:/var/run/execution_daemon
          - einstein_storage:/einstein
        ports:
          - 8000:80
        environment:
          - EINSTEIN_TEMP=/einstein_temp/
        restart: "no"
      dirty:
        image: einstein_script_server:latest
        container_name: niels
        volumes:
          - einstein_tmp:/einstein_temp
          - einstein_run:/var/run/execution_daemon
        environment:
          - EINSTEIN_TEMP=/einstein_temp/
        restart: "no"
    volumes:
      einstein_storage:
        external: true
      einstein_tmp:
      einstein_run:

I also use named volumes for some shared folders - einstein_tmp and einstein_run. Ideally these would use some kind of disposable temporary directories. Unfortunately, while docker does support tempfs folders, they are only supported on Linux and they can't be shared between containers.

Comments

Post a Comment

Popular posts from this blog

Image
 We are making good progress, we have all the "models" set-up, we have a basic user-interface, a basic User Account System. Users are able to view their modules, labs and exercises. Instructors are able to create and edit Modules etc. We started brainstorming a system that would allow a student to enrol into a module. We thought about ways of automating the process of registering a large amount of students. In this way the system would be similar to the actual Einstein system, in that, students wouldn't need to do anything themselves. We finally decided on creating a system similar to poodle or moodle, where a student would need a code, usually given by the lecturer, to enrol themselves in a module and view its contents.
Read more

Docker, Part I

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...
Read more

Emails and User Registration

In our project’s function specification, we said user registration would work though emails. This would have worked in a manner we are all familiar with. User registering would need to confirm that a given email address was theirs by entering a code or clicking on a link they received via email. It was also envisaged that instructors when creating a class would enter a list of their students’ emails addresses. Somethings are easier to describe than code. In order to write this system, we would have needed some kind of stub email system to make up for the fact that we don’t have easy access to smtp servers. Accordingly, we have opted for a simpler system where students can register for a class by using a unique registration code. This simplifies development and registration and could always be supplemented by an email and/or system authentication plugins were development to proceed further. Another change we have made was to rename the class "class" to "module...
Read more