Merge pull request #18610 from dvdksn/hb-ga

hb ga

content/build/building/env-vars.md

@@ -10,7 +10,7 @@ You can set the following environment variables to enable, disable, or change
 the behavior of features related to building:
 
 | Variable                                                                    | Type              | Description                                          |
-|-----------------------------------------------------------------------------|-------------------|------------------------------------------------------|
+| --------------------------------------------------------------------------- | ----------------- | ---------------------------------------------------- |
 | [BUILDKIT_COLORS](#buildkit_colors)                                         | String            | Configure text color for the terminal output.        |
 | [BUILDKIT_HOST](#buildkit_host)                                             | String            | Specify host to use for remote builders.             |
 | [BUILDKIT_PROGRESS](#buildkit_progress)                                     | String            | Configure type of progress output.                   |
@@ -250,4 +250,4 @@ Usage:
 
 ```console
 $ export BUILDX_NO_DEFAULT_LOAD=1
-```
+```

content/build/building/multi-platform.md

@@ -39,8 +39,8 @@ You can build multi-platform images using three different strategies,
 depending on your use case:
 
 1. Using the [QEMU emulation](#qemu) support in the kernel
-2. Building on [multiple native nodes](#multiple-native-nodes) using the same
-   builder instance
+2. Building on a single builder backed by
+   [multiple nodes of different architectures](#multiple-native-nodes).
 3. Using a stage in your Dockerfile to [cross-compile](#cross-compilation) to
    different architectures
 
@@ -58,7 +58,8 @@ loads it through a binary registered in the `binfmt_misc` handler.
 > Emulation with QEMU can be much slower than native builds, especially for
 > compute-heavy tasks like compilation and compression or decompression.
 >
-> Use [cross-compilation](#cross-compilation) instead, if possible.
+> Use [multiple native nodes](#multiple-native-nodes) or
+> [cross-compilation](#cross-compilation) instead, if possible.
 
 For QEMU binaries registered with `binfmt_misc` on the host OS to work
 transparently inside containers, they must be statically compiled and
@@ -78,10 +79,13 @@ $ docker run --privileged --rm tonistiigi/binfmt --install all
 ### Multiple native nodes
 
 Using multiple native nodes provide better support for more complicated cases
-that are not handled by QEMU and generally have better performance. You can
-add additional nodes to the builder instance using the `--append` flag.
+that QEMU can't handle, and also provides better performance.
 
-Assuming contexts `node-amd64` and `node-arm64` exist in `docker context ls`;
+You can add additional nodes to a builder using the `--append` flag.
+
+The following command creates a multi-node builder from Docker contexts named
+`node-amd64` and `node-arm64`. This example assumes that you've already added
+those contexts.
 
 ```console
 $ docker buildx create --use --name mybuild node-amd64
@@ -90,9 +94,25 @@ $ docker buildx create --append --name mybuild node-arm64
 $ docker buildx build --platform linux/amd64,linux/arm64 .
 ```
 
-For information on using multiple native nodes in CI, with GitHub Actions,
-refer to
-[Configure your GitHub Actions builder](../ci/github-actions/configure-builder.md#append-additional-nodes-to-the-builder).
+While this approach has advantages over emulation, managing multi-node builders
+introduces some overhead of setting up and managing builder clusters.
+Alternatively, you can use [Docker Build Cloud](/build/cloud/), a service that
+provides managed multi-node builders on Docker's infrastructure. With Docker
+Build Cloud, you get native multi-platform Arm and X86-64 builders without the
+burden of maintaining them. Using cloud builders also provides additional
+benefits, such as a shared build cache.
+
+After signing up for Docker Build Cloud, add the builder to your local
+environment and start building.
+
+```console
+$ docker buildx create --driver cloud <ORG>/<BUILDER_NAME>
+cloud-<ORG>-<BUILDER_NAME>
+$ docker buildx build --builder cloud-<ORG>-<BUILDER_NAME> \
+  --platform linux/amd64,linux/arm64,linux/arm/v7 \
+  --tag <IMAGE_NAME> \
+  --push .
+```
 
 ### Cross-compilation
 

content/build/cloud/_index.md

@@ -0,0 +1,68 @@
+---
+title: Docker Build Cloud
+description: Get started with Docker Build Cloud
+keywords: build, cloud, cloud build, remote builder
+aliases:
+  - /hydrobuild/
+---
+
+Docker Build Cloud is a service that lets you build your container images
+faster, both locally and in CI. Builds run on cloud infrastructure optimally
+dimensioned for your workloads, no configuration required. The service uses a
+remote build cache, ensuring fast builds anywhere and for all team members.
+
+## How Docker Build Cloud works
+
+Using Docker Build Cloud is no different from running a regular build. You invoke a
+build the same way you normally would, using `docker buildx build`. The
+difference is in where and how that build gets executed.
+
+By default when you invoke a build command, the build runs on a local instance
+of BuildKit, bundled with the Docker daemon. With Docker Build Cloud, you send
+the build request to a BuildKit instance running remotely, in the cloud. The
+build request is transmitted over a secure, end-to-end encrypted connection.
+
+The remote builder executes the build steps, and sends the resulting build
+output to the destination that you specify. For example, back to your local
+Docker Engine image store, or to an image registry.
+
+Docker Build Cloud provides several benefits over local builds:
+
+- Improved build speed
+- Shared build cache
+- Native multi-platform builds
+
+And the best part: you don't need to worry about managing builders or
+infrastructure. Just connect to your builders, and start building.
+
+> **Note**
+>
+> Docker Build Cloud is currently only available in the US East region. Users
+> in Europe and Asia may experience increased latency compared to users based
+> in North America.
+>
+> Support for multi-region builders is on the roadmap.
+
+## Get Docker Build Cloud
+
+To get started with Docker Build Cloud, [create a Docker
+account](../../docker-id/_index.md) and sign up for the free plan on the
+[Docker Build Cloud Dashboard](https://build.docker.com/).
+
+> **Note**
+>
+> If your organization isn't already on a paid Docker subscription, you will
+> need to provide a payment method to sign up for Docker Build Cloud. If you
+> select the free plan, there will be no charges on the provided payment
+> method, it's only required for verification purposes.
+
+Once you've signed up and created a builder, continue by [setting up the
+builder in your local environment](./setup.md).
+
+For more information about the available subscription plans, see [Docker Build Cloud
+subscriptions and features](/subscriptions/build-details).
+
+## Frequently asked questions
+
+The [Docker Build Cloud FAQ](./faq.md) page lists common questions and answers about
+Docker Build Cloud.