2023-04-28 14:29:58 +00:00
|
|
|
# Tutor provides the `tutor MODE do JOB ...` CLI as a consistent way to execute jobs
|
2023-07-10 12:58:24 +00:00
|
|
|
# across the dev, local, and k8s modes. To support jobs in the docker compose modes
|
2023-04-28 14:29:58 +00:00
|
|
|
# (dev and local), we must define a `-job` variant service in which jobs could be run.
|
|
|
|
|
|
2023-07-10 12:58:24 +00:00
|
|
|
# When `tutor local do JOB ...` is invoked, we `docker compose run` each of JOB's
|
2023-04-28 14:29:58 +00:00
|
|
|
# tasks against the appropriate `-job` services, as defined here.
|
|
|
|
|
# When `tutor dev do JOB ...` is invoked, we do the same, but also include any
|
|
|
|
|
# compose overrides in ../dev/docker-compose.jobs.yml.
|
|
|
|
|
|
|
|
|
|
# Note that these services will all be `run` rather than `start`ed and `exec`ed.
|
|
|
|
|
# This is because jobs are often used for initialization tasks, which may need to
|
|
|
|
|
# happen before the service can be successfully `start`ed.
|
|
|
|
|
|
2022-04-15 08:51:19 +00:00
|
|
|
version: "{{ DOCKER_COMPOSE_VERSION }}"
|
Improve job running in local and k8s
Running jobs was previously done with "exec". This was because it
allowed us to avoid copying too much container specification information
from the docker-compose/deployments files to the jobs files. However,
this was limiting:
- In order to run a job, the corresponding container had to be running.
This was particularly painful in Kubernetes, where containers are
crashing as long as migrations are not correctly run.
- Containers in which we need to run jobs needed to be present in the
docker-compose/deployments files. This is unnecessary, for example when
mysql is disabled, or in the case of the certbot container.
Now, we create dedicated jobs files, both for local and k8s deployment.
This introduces a little redundancy, but not too much. Note that
dependent containers are not listed in the docker-compose.jobs.yml file,
so an actual platform is still supposed to be running when we launch the
jobs.
This also introduces a subtle change: now, jobs go through the container
entrypoint prior to running. This is probably a good thing, as it will
avoid forgetting about incorrect environment variables.
In k8s, we find ourselves interacting way too much with the kubectl
utility. Parsing output from the CLI is a pain. So we need to switch to
the native kubernetes client library.
2020-03-25 17:47:36 +00:00
|
|
|
services:
|
|
|
|
|
|
|
|
|
|
mysql-job:
|
2020-07-21 07:13:00 +00:00
|
|
|
image: {{ DOCKER_IMAGE_MYSQL }}
|
2020-09-17 10:53:14 +00:00
|
|
|
depends_on: {{ [("mysql", RUN_MYSQL)]|list_if }}
|
2020-07-21 07:13:00 +00:00
|
|
|
|
Improve job running in local and k8s
Running jobs was previously done with "exec". This was because it
allowed us to avoid copying too much container specification information
from the docker-compose/deployments files to the jobs files. However,
this was limiting:
- In order to run a job, the corresponding container had to be running.
This was particularly painful in Kubernetes, where containers are
crashing as long as migrations are not correctly run.
- Containers in which we need to run jobs needed to be present in the
docker-compose/deployments files. This is unnecessary, for example when
mysql is disabled, or in the case of the certbot container.
Now, we create dedicated jobs files, both for local and k8s deployment.
This introduces a little redundancy, but not too much. Note that
dependent containers are not listed in the docker-compose.jobs.yml file,
so an actual platform is still supposed to be running when we launch the
jobs.
This also introduces a subtle change: now, jobs go through the container
entrypoint prior to running. This is probably a good thing, as it will
avoid forgetting about incorrect environment variables.
In k8s, we find ourselves interacting way too much with the kubectl
utility. Parsing output from the CLI is a pain. So we need to switch to
the native kubernetes client library.
2020-03-25 17:47:36 +00:00
|
|
|
lms-job:
|
2020-07-21 07:13:00 +00:00
|
|
|
image: {{ DOCKER_IMAGE_OPENEDX }}
|
Improve job running in local and k8s
Running jobs was previously done with "exec". This was because it
allowed us to avoid copying too much container specification information
from the docker-compose/deployments files to the jobs files. However,
this was limiting:
- In order to run a job, the corresponding container had to be running.
This was particularly painful in Kubernetes, where containers are
crashing as long as migrations are not correctly run.
- Containers in which we need to run jobs needed to be present in the
docker-compose/deployments files. This is unnecessary, for example when
mysql is disabled, or in the case of the certbot container.
Now, we create dedicated jobs files, both for local and k8s deployment.
This introduces a little redundancy, but not too much. Note that
dependent containers are not listed in the docker-compose.jobs.yml file,
so an actual platform is still supposed to be running when we launch the
jobs.
This also introduces a subtle change: now, jobs go through the container
entrypoint prior to running. This is probably a good thing, as it will
avoid forgetting about incorrect environment variables.
In k8s, we find ourselves interacting way too much with the kubectl
utility. Parsing output from the CLI is a pain. So we need to switch to
the native kubernetes client library.
2020-03-25 17:47:36 +00:00
|
|
|
environment:
|
|
|
|
|
SERVICE_VARIANT: lms
|
2022-04-12 14:07:48 +00:00
|
|
|
DJANGO_SETTINGS_MODULE: lms.envs.tutor.production
|
Improve job running in local and k8s
Running jobs was previously done with "exec". This was because it
allowed us to avoid copying too much container specification information
from the docker-compose/deployments files to the jobs files. However,
this was limiting:
- In order to run a job, the corresponding container had to be running.
This was particularly painful in Kubernetes, where containers are
crashing as long as migrations are not correctly run.
- Containers in which we need to run jobs needed to be present in the
docker-compose/deployments files. This is unnecessary, for example when
mysql is disabled, or in the case of the certbot container.
Now, we create dedicated jobs files, both for local and k8s deployment.
This introduces a little redundancy, but not too much. Note that
dependent containers are not listed in the docker-compose.jobs.yml file,
so an actual platform is still supposed to be running when we launch the
jobs.
This also introduces a subtle change: now, jobs go through the container
entrypoint prior to running. This is probably a good thing, as it will
avoid forgetting about incorrect environment variables.
In k8s, we find ourselves interacting way too much with the kubectl
utility. Parsing output from the CLI is a pain. So we need to switch to
the native kubernetes client library.
2020-03-25 17:47:36 +00:00
|
|
|
volumes:
|
2021-11-16 10:42:40 +00:00
|
|
|
- ../apps/openedx/settings/lms:/openedx/edx-platform/lms/envs/tutor:ro
|
|
|
|
|
- ../apps/openedx/settings/cms:/openedx/edx-platform/cms/envs/tutor:ro
|
|
|
|
|
- ../apps/openedx/config:/openedx/config:ro
|
2023-09-04 17:08:15 +00:00
|
|
|
{%- for mount in iter_mounts(MOUNTS, "openedx", "lms-job") %}
|
2023-04-27 18:25:20 +00:00
|
|
|
- {{ mount }}
|
|
|
|
|
{%- endfor %}
|
2022-04-11 15:26:17 +00:00
|
|
|
depends_on: {{ [("mysql", RUN_MYSQL), ("mongodb", RUN_MONGODB)]|list_if }}
|
2020-07-21 07:13:00 +00:00
|
|
|
|
Improve job running in local and k8s
Running jobs was previously done with "exec". This was because it
allowed us to avoid copying too much container specification information
from the docker-compose/deployments files to the jobs files. However,
this was limiting:
- In order to run a job, the corresponding container had to be running.
This was particularly painful in Kubernetes, where containers are
crashing as long as migrations are not correctly run.
- Containers in which we need to run jobs needed to be present in the
docker-compose/deployments files. This is unnecessary, for example when
mysql is disabled, or in the case of the certbot container.
Now, we create dedicated jobs files, both for local and k8s deployment.
This introduces a little redundancy, but not too much. Note that
dependent containers are not listed in the docker-compose.jobs.yml file,
so an actual platform is still supposed to be running when we launch the
jobs.
This also introduces a subtle change: now, jobs go through the container
entrypoint prior to running. This is probably a good thing, as it will
avoid forgetting about incorrect environment variables.
In k8s, we find ourselves interacting way too much with the kubectl
utility. Parsing output from the CLI is a pain. So we need to switch to
the native kubernetes client library.
2020-03-25 17:47:36 +00:00
|
|
|
cms-job:
|
2020-07-21 07:13:00 +00:00
|
|
|
image: {{ DOCKER_IMAGE_OPENEDX }}
|
Improve job running in local and k8s
Running jobs was previously done with "exec". This was because it
allowed us to avoid copying too much container specification information
from the docker-compose/deployments files to the jobs files. However,
this was limiting:
- In order to run a job, the corresponding container had to be running.
This was particularly painful in Kubernetes, where containers are
crashing as long as migrations are not correctly run.
- Containers in which we need to run jobs needed to be present in the
docker-compose/deployments files. This is unnecessary, for example when
mysql is disabled, or in the case of the certbot container.
Now, we create dedicated jobs files, both for local and k8s deployment.
This introduces a little redundancy, but not too much. Note that
dependent containers are not listed in the docker-compose.jobs.yml file,
so an actual platform is still supposed to be running when we launch the
jobs.
This also introduces a subtle change: now, jobs go through the container
entrypoint prior to running. This is probably a good thing, as it will
avoid forgetting about incorrect environment variables.
In k8s, we find ourselves interacting way too much with the kubectl
utility. Parsing output from the CLI is a pain. So we need to switch to
the native kubernetes client library.
2020-03-25 17:47:36 +00:00
|
|
|
environment:
|
|
|
|
|
SERVICE_VARIANT: cms
|
2022-04-12 14:07:48 +00:00
|
|
|
DJANGO_SETTINGS_MODULE: cms.envs.tutor.production
|
Improve job running in local and k8s
Running jobs was previously done with "exec". This was because it
allowed us to avoid copying too much container specification information
from the docker-compose/deployments files to the jobs files. However,
this was limiting:
- In order to run a job, the corresponding container had to be running.
This was particularly painful in Kubernetes, where containers are
crashing as long as migrations are not correctly run.
- Containers in which we need to run jobs needed to be present in the
docker-compose/deployments files. This is unnecessary, for example when
mysql is disabled, or in the case of the certbot container.
Now, we create dedicated jobs files, both for local and k8s deployment.
This introduces a little redundancy, but not too much. Note that
dependent containers are not listed in the docker-compose.jobs.yml file,
so an actual platform is still supposed to be running when we launch the
jobs.
This also introduces a subtle change: now, jobs go through the container
entrypoint prior to running. This is probably a good thing, as it will
avoid forgetting about incorrect environment variables.
In k8s, we find ourselves interacting way too much with the kubectl
utility. Parsing output from the CLI is a pain. So we need to switch to
the native kubernetes client library.
2020-03-25 17:47:36 +00:00
|
|
|
volumes:
|
2021-11-16 10:42:40 +00:00
|
|
|
- ../apps/openedx/settings/lms:/openedx/edx-platform/lms/envs/tutor:ro
|
|
|
|
|
- ../apps/openedx/settings/cms:/openedx/edx-platform/cms/envs/tutor:ro
|
|
|
|
|
- ../apps/openedx/config:/openedx/config:ro
|
2023-09-04 17:08:15 +00:00
|
|
|
{%- for mount in iter_mounts(MOUNTS, "openedx", "cms-job") %}
|
2023-04-27 18:25:20 +00:00
|
|
|
- {{ mount }}
|
|
|
|
|
{%- endfor %}
|
2022-01-18 13:37:07 +00:00
|
|
|
depends_on: {{ [("mysql", RUN_MYSQL), ("mongodb", RUN_MONGODB), ("elasticsearch", RUN_ELASTICSEARCH), ("redis", RUN_REDIS)]|list_if }}
|
2020-07-21 07:13:00 +00:00
|
|
|
|
2021-04-13 20:14:43 +00:00
|
|
|
{{ patch("local-docker-compose-jobs-services")|indent(4) }}
|
