Building¶
To build the Docker version of MiGrid, the repository provides a Makefile that helps you out.
Overview¶
Before you can build an image, you need to select which MiGrid services you would like to run. This choice will lead you to select or configure an environment file that suit your particular choice. There are different predefined environments available in this repository (e.g. development.env or production.env).
After choosing an environment and adapting it to your needs, you can enable it by creating an .env symlink that points to your particular environment configuration. For instance, if you want to build the MiGrid image with the default environment settings, this is achieved by the Makefile init target, which will automatically create a symlink from development.env to the expected .env file. If this behaviour is not wanted, a symlink has to be manually created before make is called to link the designated environment file to the .env file. For instance:
ln -s my-custom-environment.env .env
Be aware that .env itself is excluded from the git repository via .gitignore.
Quick Start¶
If you just want to get started right away without any configuration changes you can use the default development environment by simply running make with the corresponding target inside the docker-migrid directory:
make up
The Makefile takes care of creating all the necessary files, builds a migrid image and starts up the services. The entire process should be successfully completed, when the following lines have been printed:
[+] Running 15/15
✔ Network docker-migrid_default Created 0.0s
✔ Container devdns Started 0.0s
✔ Container migrid Started 10.6s
✔ Container devmail Started 0.0s
✔ Container migrid-sftp Started 0.2s
✔ Container migrid-openid Started 0.2s
✔ Container migrid-ftps Started 0.2s
✔ Container nginx-proxy Started 0.0s
✔ Container migrid-webdavs Started 0.0s
Additional Details¶
When building the Docker MiGrid container image, several things are being done in addition to just producing the target docker-migrid image. An indication of this can be seen by investigating the Makefile itself.
For starters, when make is being executed within the directory the required helper directories and any missing symlinks are created before the build commences. This involves executing the init target, which initializes the docker-migrid directory. Specifically, it will create the required directories, both for the build and the runtime itself. These required directories includes the certs, httpd, mig, and state directories.
- certs
The certs directory will be populated by the MiGrid container with the security certificates generated by the build. In general there should be no reason to touch these after it has been created.
- httpd
The httpd directory contains the state and configuration files for the Apache webserver which is run by the MiGrid service.
- mig
The mig directory contains the actual MiG source code directory, like if it had been cloned from the original MiG upstream repository.
- state
The state directory, contains all MiG site state directories, such as user home directories, archives, logs and the likes.
All of these directories will be populated by the container when the Docker MiGrid service is deployed. The result of executing the init Makefile target can be seen below:
$:docker-migrid username$ make init
mkdir -p certs
mkdir -p httpd
mkdir -p mig
mkdir -p state
Finally, once the repository directory has been initialized, the Docker MiGrid image is ready to be built. This is achieved with the build target inside the Makefile. By executing this, the image build process will commence, an example of this can be seen below:
docker-compose build
WARNING: Python-dotenv could not parse statement starting at line 5
devdns uses an image, skipping
nginx-proxy uses an image, skipping
Building migrid
[+] Building 38.6s (13/75)
...
After this is complete, you should be ready to deploy the MiGrid service with Docker.
In between builds one can request basic clean up with the clean target to remove any old code and outdated configuration data that might be hanging around from previous builds. It does ‘’not’’ remove the state folder with user data, log files, etc.
In case you want a complete reset to the pristine checkout state during development you can use the distclean target to achieve that. IMPORTANT: Please beware of the potential data loss if using that command on production sites.