Open MoisesGSalas opened 1 year ago
@MoisesGSalas, do you propose that we add the restart: on-failure
the permission configuration has to our init job?
Since it is a feat and it should go through a product review, I tag @Alec4r and @santiagosuarezedunext
@MaferMazu, sorry I didn't quite get what you meant.
The idea, similar to the openedx-permission
container, is to use an additional docker-compose service that runs a single command (in our case, it would be the codejail_apparmor_loader
image running the loader
command). We then define this service as a dependency of the main codejailservice
(like: https://github.com/overhangio/tutor/blob/master/tutor/templates/local/docker-compose.yml#L36-L37) to ensure it's always run before the main service.
We use restart: on-failure
to avoid permanently restarting the container because the command in the image should run and exit with a 0 status code (the default is to always restart the container). After that we should delete all the job definitions and hooks.
Is your feature request related to a problem? Please describe.
To use the codejail service is necessary to load an AppArmor profile in the host machine. To do so, the plugin uses an initialization job that runs on a privileged container and must be run as part of the initialization of the service (i.e.
tutor do init -l codejail
). There are several ways in which the AppArmor Profile can be unloaded:apparmor_parser -R ...
or by rebooting the host machine, which requires you to run the initialization job again.Describe the solution you'd like
Refactoring the init job into an initialization container similar to the
openedx-permissions
might be a more appropriate approach ensuring that the profile is loaded before starting the codejailservice container.