How builds work: Dockerfile or runtime build

Narration uses an AI-generated voice.

[00:00] Where we're going

By the end of this video, you'll know the two ways ComputeSphere can build your code, and which one to pick. And we'll watch a real app build, both ways.

[00:10] What a build makes

A build turns your source code into a container image. Then ComputeSphere deploys that image, exactly like one you built yourself. You choose how the build happens. With your own Dockerfile, or with a runtime build, which follows your language's standard recipe. In the console, the Build method switch calls these Dockerfile, and Managed.

[00:35] Dockerfile build

First, the Dockerfile build. A Dockerfile is a text file of instructions for building an image. This one comes from a small sample app. It starts from a base image, a ready-made starting point. Here, that's Python. Then it copies in the code, and installs what the app needs. And it says how to start the app. Pick a Dockerfile build when you already have one that works. Or when you need system packages, a particular base image, or a multi-stage build. Or when you want the deployed image to match the one you test on your machine.

[01:11] Runtime build

Now the runtime build. No Dockerfile? Just pick your language, and its version. We'll choose Python, three point twelve. ComputeSphere fills in a build command, which installs your dependencies from the usual file. And a start command. This app doesn't follow the default, so we replace the start command. Pick a runtime build when your app follows the normal conventions for its language, and you'd rather not maintain a Dockerfile.

[01:40] Watch a real build

Let's build it. The code is in a public sample repository. So under Configuration, we choose Git Repository, then Public, the repository's address, and the main branch. The app listens on port five thousand, so that goes under Networking. Then, Deploy.

Open the service's Builds tab. The build is queued, waiting for a builder, and the service shows Building. Every line the build prints goes to its build log. Here it fetches the main branch, and installs the requirements. Flask, and gunicorn. Then the finished image is Deploying. And less than a minute after we chose Deploy, the service is Running. There's the app, on its own URL.

[02:26] The same app, with its Dockerfile

This repository also has a Dockerfile. So let's build it the other way. Choose Redeploy, keep Build and Deploy, and open Edit build settings. Here's the Build method switch. It's on Managed. We choose Dockerfile, then Redeploy. This time, the build follows the repository's own Dockerfile, step by step. From its Python base image, to copying the requirements, to installing them. Two methods, one result. A container image, deployed the same way.

[03:00] When a build fails

What if a build fails? Say there's a typo in the build command. The build fails, so nothing is deployed. Your previous version keeps serving, on the same URL. The next lesson shows how to read the log, and find what broke.

[03:16] Recap

So, a quick recap. A build turns your code into a container image. A Dockerfile build gives you full control, like installing system packages. A runtime build follows your language's standard recipe. And a failed build never replaces the version that's serving. Next, we'll read a build log together. I'll see you there.