From d76f1d7b3219adc0d64c08395b010713c1307317 Mon Sep 17 00:00:00 2001 From: Steven Polley Date: Sun, 31 May 2020 00:25:46 +0000 Subject: [PATCH] Why containers --- README.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/README.md b/README.md index b2dcdf0..8d513f0 100644 --- a/README.md +++ b/README.md @@ -23,6 +23,12 @@ The project is broken into two parts: * Master - This can be thought of as the server, it's the portal that users interact with to upload .blend files and tweak render parameters. * Slave - This can be thought of as a client, and it handles rendering the images which get stitched together to create an animation. There can be as many instances of the slave as you want, the more slaves, the more simultaneous frames can be rendered. +#### Why Containers? + +That's the secret sauce of the whole operation. Containers provide a unit of deployment. What does that give you? It gives you an easy way to launch an application, anywhere, across as many machines as you need to. Sign up for a cloud provider, most support running containers natively. Many providers make it as easy as pasting in the URL to download your container from a registry, and putting a number for how many instances you want to run. + +You can also run containers on your own equipment utilizing an orchestrator such as Kubernetes. + #### Web interface When you run the master, it listens on port 8097. Here's a screenshot of the web interface on the status page for an ongoing render job: