diff --git a/README.md b/README.md index b90350c..f520ffe 100644 --- a/README.md +++ b/README.md @@ -17,7 +17,7 @@ Runboat has the following main components: - A REST API to list builds and trigger new deployments as well as start, stop, redeploy or undeploy builds. - A GitHub webhook to automatically trigger new builds on pushes to branches and pull - requests of supported repositories. + requests of supported repositories and branches (configured via regular expressions). - A controller that performs the following tasks: - monitor deployments in a kubernetes namespaces to maintain the in-memory database; @@ -25,17 +25,14 @@ Runboat has the following main components: install dependencies, create the corresponding postgres database and install the addons in it; - initialization jobs are started concurrently up to a configured limit; - - when the initialization job succeeds, scale up the deployment, so it becomes - accessible; - - when the initializaiton job fails, flag the deployment as failed; + - when the initialization job succeeds, preserve the database, filestore, and virtual + environment, so everything is ready for an almost instantaneous startup; + - when the initialization job fails, flag the deployment as failed; - when there are too many deployments started, stop the oldest started; - when there are too many deployments, delete the oldest created; - when a deployment is deleted, run a cleanup job to drop the database and delete all kubernetes resources associated with the deployment. -When a deployment is stopped, the corresponding postgres database and filesystem volume -remain present, so deployments can restart almost instantly. - This approach allows the deployment of a very large number of builds which consume no memory nor CPU until they are started. The number of started deployment can also be high, by reserving limited CPU and memory resources for each, taking advantage of the @@ -68,8 +65,8 @@ For running the controller (runboat itself): - `kubectl` - A `KUBECONFIG` or an in-cluster service account that provides access to the namespace where the builds are deployed, with permissions to create and delete Service, Job, - Deployment, Ingress, Secret and ConfigMap resources as well as read and watch - Deployments and Jobs. + Deployment, PersistentVolumeClaim, Ingress, Secret and ConfigMap resources as well as + read and watch Deployments and Jobs. - Some sort of reverse proxy to expose the REST API. The controller can be run outside the kubernetes cluster or deployed inside it, or even @@ -82,7 +79,8 @@ All resources to be deployed in kubernetes for a build are in `kustomization.yaml` jinja template that leads to three possible resource groups depending on a `mode` variable in the jinja rendering context: -- `deployment` creates a kubernetes deployment with its associated service and ingress; +- `deployment` creates a kubernetes deployment with its associated resources (pvc, + service, ingress, ...); - `initialization` creates a job that creates the database; - `cleanup` creates a job that drops the database; @@ -137,7 +135,6 @@ Gunicorn also necessary so SIGINT/SIGTERM shutdowns after a few seconds. Since w `run_in_executor`, SIGINT/SIGTERM handling does not work very well, and gunicorn makes it more robust. https://bugs.python.org/issue29309 - ## Configuration See environment variables examples in [Dockerfile](./Dockerfile), diff --git a/src/runboat/controller.py b/src/runboat/controller.py index bd115d2..82202d8 100644 --- a/src/runboat/controller.py +++ b/src/runboat/controller.py @@ -96,7 +96,7 @@ class Controller: return self.db.count_by_status(BuildStatus.undeploying) async def deploy_commit(self, commit_info: CommitInfo) -> None: - """Deploy build for a commit, or do nothing if biuld already exist.""" + """Deploy build for a commit, or do nothing if build already exist.""" build = self.db.get_for_commit( repo=commit_info.repo, target_branch=commit_info.target_branch,