Docker things to get used to (and avoid surprises)

Docker cheat sheet

restart just one container (sample is for the WeBWorK app container, while DB/R stay running):

• docker-compose restart app

containers

• docker container ps # ls can be used as a synonym for ps
• docker container ps -a # need -a to list stopped containers
• docker container rm ....

images

• docker images
• docker rmi ......
• docker rmi -f ....

volumes

• docker volume ls
• docker volume rm ....

a useful alias

• Type dockerbash in the directory containing the docker file and you will be "logged in" via a terminal window to the running docker container. The webworkID may need to be adjusted -- but webwork2_app_1 is the default. Place this alias in your .bashrc file, or where ever you keep your command line aliases.

alias dockerbash="docker container exec -it webwork2_app_1 bash"

Once logged in your experience should be the same as if you had logged in to your local webwork development or production machine on the command line.

Docker containers and file persistence

Docker stores the code and data included when the "image" is created at a different (read-only) level from changes to data/code which occur in a running "container" unless those files are on persistent storage.

Changes which are not saved to persistent storage will disappear after a docker-compose down.

• For example, if you access bash inside the running WeBWorK Docker container and then install a new package from Ubuntu, it will disappear after the next restart of the container.
• To get an additional package into the image, add additional lines in the Dockerfile near the bottom to add them into the static image of the container. (Putting them near the end will save time by avoiding rerunning the prior steps of the image build.)
• If you want to add an SSL certificate into a Docker image, it would need to be added via either the Dockerfile (COPY command) or at run-time by inclusion from persistent storage.

At present, the default configuration for using WeBWorK inside Docker makes the following persistent:

• The data of the MariaDB mysql databases
  • originally in webwork2/.data/db/ via bind mount,
  • was moved to a named Docker volume so it will also work on Docker CE for Windows.
  • the named volume is usually webwork2_mysql and can be found by running docker volume ls
• The courses directory
  • originally was bind mounted from the host machine webwork2/.data/courses
  • now bind mounted from the host machine ww-docker-data/courses where ww-docker-data is a subdirectory of webwork2's parent directory.
  • That keeps the courses data totally outside of the webwork2 tree.
• Optional - no longer by default - the webwork2 code tree
  • bind mounted from the host machine webwork2/ directory no longer done by default

It is possible to uncomment lines in docker-compose.yml so that

• the webwork2 code will be bind mounted
• the pg code will be bind mounted
• a PC hosted version of the OPL will be used instead of the one inside the static Docker image.

Host PC access to the courses data

• Change into your webwork2 subdirectory of you webwork_docker directory (wherever you put it).
• Change into the parallel ../ww-docker-data/courses subdirectory.
• Warning: some symbolic links may be to locations which exist only inside the Docker container.

Host PC access to the OPL

• By default the OPL is installed only internally inside the Docker image, so you need to use a command shell running inside the Docker container to access it. (That only works when the container is running.)
• As noted above, it can also be "bind mounted" and then shared between the Docker container and your PC.
  • There seem to be some performance issues when this is done.
• The https://github.com/openwebwork/webwork2/wiki/Docker-newbie-instructions explains how to do this in the section on running OPL-update: https://github.com/openwebwork/webwork2/wiki/Docker-newbie-instructions#running-opl-update
  • Essentially you need to do as follows, where webwork_app_1 is assumed to be the proper container name

docker container ls      # find the name
docker container exec -it webwork_app_1 bash

• and then you should probably see the correct subdirectory of /opt/webwork which should be /opt/webwork/libraries/

Access to the SQL databases

mysql is available from in both docker containers (when they are running), but the startup command is a bit different in the app container, as it needs to give the "-h" option. The following works for me:

• DB container:
  • docker container exec -it webwork2_db_1 bash
  • mysql -u webworkWrite -p webwork
  • The database password is given in the Dockerfile and by default is passwordRW.
• APP container:
  • docker container exec -it webwork2_app_1 bash
  • mysql -u webworkWrite -p webwork -h db
  • The database password is given in the Dockerfile and by default is passwordRW.