Okteto Build service

Every time you build your images with Okteto, your build is executed in a remote BuildKit server running in your cluster, deployed automatically by Okteto. The image is also pushed to the Okteto Registry. The following image illustrates this process:

The Okteto Build service addresses common issues that often slow down image builds such as limited local resources, inefficient emulation, and the lack of reusing images and cache layers already computed by other team members.

How to build your images

The Okteto CLI is automatically configured to interact with the Okteto Build service (follow our docs to install and configure the Okteto CLI). For example, if your have the following Okteto Manifest:

okteto.yaml

build:
  api:
    context: api
    dockerfile: Dockerfile
    args:
      GO_VERSION: 1.20

The command okteto build will build and push the api image to the Okteto Registry using the Okteto Build service:

okteto build

 i  Using cindy @ okteto.example.com as context
 i  Building 'api/Dockerfile' in tcp://buildkit.okteto.example.com:443...
 ...
 ✓  Image 'registry.okteto.example.com/cindy/api:okteto' successfully pushed

Read our documentation about the build section and the okteto build command for more information.

Smart Builds

Buildkit comes with a local cache to reuse cache layers between image builds. You can configure the Buildkit cache size and storage class when installing Okteto to optimize the BuildKit cache behavior.

But the Buildkit cache has its own limitations. Even if every Dockerfile instruction is cached, you might wait 1 or 2 minutes until your build context is sent to Buildkit, Buildkit pulls your base image, detects that each Dockerfile instruction can be cached, and push the final image again to the Okteto Registry.

Smart Builds is an Okteto's feature designed to solve this problem. For each image you build, Okteto computes a hash based on the build context and the rest of build parameters. Okteto uses this hash to detect if the image has been already built by any other developer. If the image was already built, the build is skipped and the previous image is reused almost immediately.

Smart Builds are implemented by pushing a tag with the value of the hash to the namespace okteto in the Okteto Registry. For example, if you build the following image:

okteto.yaml

build:
  api:
    context: api
    dockerfile: Dockerfile
    args:
      GO_VERSION: 1.20

okteto build

 i  Using cindy @ okteto.example.com as context
 i  Building 'api/Dockerfile' in tcp://buildkit.okteto.example.com:443...
 ...
 => pushing manifest for registry.okteto.example.com/okteto/api:09f8e
 ✓  Image 'registry.okteto.example.com/cindy/api:okteto' successfully pushed

As you can see in the following image, the image is pushed to okteto/api:09f8e:

Also, cindy/api:okteto is re-tagged to okteto/api:09f8e to remember the last build performed in a given namespace. The following image illustrates this process:

If another user, David, builds the same image with the same build context and parameters, the same hash 09f8e is computed.

okteto build

 i  Using david @ okteto.example.com as context
 i  Okteto Smart Builds is skipping build of "api" because it's already built

Smart builds detects that the tag okteto/api:09f8e already exists and skips the build. Instead, the image david/api:okteto is re-tagged to okteto/api:09f8e to remember the last build performed in the David's namespace:

Skipping Smart Builds behavior

You can force the build of your images and skip the Smart Build optimization by running the following command:

okteto build --no-cache

 i  Using cindy @ okteto.example.com as context
 i  Building 'api/Dockerfile' in tcp://buildkit.okteto.example.com:443...
 ...
 => pushing manifest for registry.okteto.example.com/okteto/api:09f8e
 ✓  Image 'registry.okteto.example.com/cindy/api:okteto' successfully pushed

The --no-cache flag will also disable the Buildkit local cache.

You can also disable Smart Builds by setting the environment variable OKTETO_SMART_BUILDS_ENABLED=false. If you define OKTETO_SMART_BUILDS_ENABLED=false as an Admin Variable, Smart Builds is disabled for all the image builds for all developers in your organization. Admin variables are equivalent to defining that variable on every developer's machine.

Advanced timeouts configuration

The following environment variables can be useful for handling timeouts from the Okteto CLI when communicating with the Okteto Build Service. You can configure them as Admin Variables if needed:

• OKTETO_KEEPALIVE_CLIENT_TIME_MS: After this duration of time, if the client doesn't see any activity it will ping the server to see if the transport is still alive. If set below 10s, a minimum value of 10s will be used (default value is infinity.)
• OKTETO_KEEPALIVE_CLIENT_TIMEOUT_MS: After sending a keepalive ping, the client waits for this duration of time and if no activity is seen even after that the connection is closed. (default value is 20 seconds.)
• OKTETO_KEEPALIVE_CLIENT_PERMIT_WITHOUT_STREAM: If true, the client sends keepalive pings even with no active RPCs. If false, when there are no active RPCs, Time and Timeout will be ignored and no keepalive pings will be sent (defaults to false.)