Learning Platform Deployment and Operations

A command-line workflow that configures and launches the services behind a hosted learning environment.

A learning platform is more than its learner-facing site. Authoring tools, workers, databases and supporting services all need the right settings. Each also needs its own preparation first.

We brought that setup into one application deployment automation workflow on the command line. An operator saves the configuration and generates the deployment files. The platform then launches on Docker Compose or Kubernetes. The generated files stay on hand, so the standard deployment tools can still inspect them.

The challenge

Change a hostname or a database, and the edit can touch several config files and startup tasks. Update each one on its own, and it gets harder to tell whether the whole setup still agrees.

Changing the platform needed a route the team could maintain. An operator should be able to edit part of a template and rerun only the setup work it affects. There is no need to keep a separate copy of the whole template.

What we built

The launch command gathers settings, renders the files, prepares images, starts the services and runs the startup jobs. Behind it, saved choices, defaults, generated secrets and environment overrides all feed the same setup process.

Other commands cover logs, readiness, scaling and tasks run inside the containers. An operator can also switch off the bundled supporting services when a managed alternative takes their place.

Run preparation in a defined order

On Compose, startup work runs in one-off containers. On Kubernetes, the runner submits a Job and then waits for it to finish. Priorities set the order of the steps, while service and plugin filters limit which tasks get repeated.

Execution runs on Docker Compose, or on kubectl with Kustomize. Image builds move through a few separate stages. One stage handles dependencies, another the application code, and another the production or development output. BuildKit runs the build, with build contexts the team can configure.

Make extensions and operating limits visible

Plugins change templates through named patch points, filters and actions. Their callbacks belong to a plugin context. They are taken away when that plugin is switched off. These plugins run Python on the operator's own machine, so they need a trusted operator.

Upgrades follow steps tied to each release. Some are separate database actions, run when a major-version change calls for them. Generated credentials live in the config and the rendered files, so those files need filesystem protection.

The tooling does not supply every operating safeguard. A single-host install is not highly available on its own, and backups stay the operator's job.

Project success

The client has one config route into the application settings, the deployment files and the startup jobs. Operators can repeat a scoped setup task and inspect what it generated. They can also shape the output through extension points. Maintenance work gains a defined sequence, and credentials, upgrades and backups stay explicit responsibilities.

Technology stack

Tooling

Python, Click

Configuration

Jinja2, PyYAML

Deployment

Docker Compose, Kubernetes, Kustomize

Image builds

Docker BuildKit

Learning application

Django, Celery

Supporting services

MySQL, MongoDB, Redis, Meilisearch, Caddy