Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

Docker Bake is Now Generally Available in Docker Desktop 4.38!

We’re excited to announce the General Availability of Docker Bake with Docker Desktop 4.38! This powerful build orchestration tool takes the hassle out of managing complex builds and offers simplicity, flexibility, and performance for teams of all sizes.

2400x1260 docker evergreen logo blog C 1

What is Docker Bake?

Docker Bake is an orchestration tool that streamlines Docker builds, similar to how Compose simplifies managing runtime environments. With Bake, you can define build stages and deployment environments in a declarative file, making complex builds easier to manage. It also leverages BuildKit’s parallelization and optimization features to speed up build times.

While Dockerfiles are excellent for defining image build steps, teams often need to build multiple images and execute helper tasks like testing, linting, and code generation. Traditionally, this meant juggling numerous docker build commands with their own options and arguments – a tedious and error-prone process.

Bake changes the game by introducing a declarative file format that encapsulates all options and image dependencies, referred to as targets. Additionally, Bake’s ability to parallelize and deduplicate work ensures faster and more efficient builds.

Why should you use Bake?

Challenges with complex Docker Build configuration:

  • Managing long, complex build commands filled with countless flags and environment variables.
  • Tedious workflows for building multiple images.
  • Difficulty declaring builds for specific targets or environments.
  • Requires a script or 3rd-party tool to make things manageable

Docker Bake tackles these challenges with a better way to manage complex builds with a simple, declarative approach.

Key benefits of Docker Bake

  • Simplicity: Replace complex chains of Docker build commands and scripts with a single docker buildx bake command while maintaining clear, version-controlled configuration files that are easy to understand and modify.
  • Flexibility: Express sophisticated build logic through HCL syntax and matrix builds, enabling dynamic configurations that adapt to different environments and requirements while supporting custom functions for advanced use cases.
  • Consistency: Maintain standardized build configurations across teams and environments through version-controlled files and inheritance patterns, eliminating environment-specific build issues and reducing configuration drift.
  • Performance: Automatically parallelize independent builds and eliminate redundant operations through context deduplication and intelligent caching, dramatically reducing build times for complex multi-image workflows.
Blog Bake After 1068x673 1

Figure 1: One simple Docker buildx bake command to replace all the flags and environment variables.

Use cases for Docker Bake

1. Monorepo and Image Bakery

Docker Bake can help developers efficiently manage and build multiple related Docker images from a single source repository. Plus, they can leverage shared configurations and automated dependency handling to enforce organizational standards.

  • Development Efficiency: Teams can maintain consistent build logic across dozens or hundreds of microservices in a single repository, reducing configuration drift and maintenance overhead.
  • Resource Optimization: Shared base images and contexts are automatically deduplicated, dramatically reducing build times and storage costs.
  • Standardization: Enforce organizational standards through inherited configurations, ensuring all services follow security, tagging, and testing requirements.
  • Change Management: A single source of truth for build configurations makes it easier to implement organization-wide changes like base image updates or security patches.

2. Compose users

Docker Bake provides seamless compatibility with existing docker-compose.yml files, allowing direct use of your current configurations. Existing Compose users are able to get started using Bake with minimal effort.

  • Gradual Adoption: Teams can incrementally adopt advanced build features while still leveraging their existing compose workflows and knowledge.
  • Development Consistency: Use the same configuration for both local development (via compose) and production builds (via Bake), eliminating “works on my machine” issues.
  • Enhanced Capabilities: Access powerful features like matrix builds and HCL expressions while maintaining compatibility with familiar compose syntax.
  • CI/CD Integration: Seamlessly integrate with existing CI/CD pipelines that already understand compose files while adding Bake’s advanced build capabilities.

3. Complex build configurations

Developers can use targets, groups, variables, functions, and matrix targets and many more tools in Bake to simplify their build configurations across projects and teams.

  • Cross-Platform Compatibility: Matrix builds enable teams to efficiently manage builds across multiple architectures, OS versions, and dependency combinations from a single configuration.
  • Dynamic Adaptation: HCL expressions allow builds to adapt to different environments, git branches, or CI variables without maintaining multiple configurations.
  • Build Optimization: Custom functions enable sophisticated logic for things like version calculation, tag generation, and conditional builds based on git history.
  • Quality Control: Variable validation and inheritance ensure consistent configuration across complex build scenarios, reducing errors and maintenance burden.
  • Scale Management: Groups and targets help organize large-scale build systems with dozens or hundreds of permutations, making them manageable and maintainable.

4. Docker Build Cloud

With Bake-optimized builds as the foundation, developers can achieve more efficient Docker Build Cloud performance and faster builds.

  • Enhanced Docker Build Cloud Performance: Instantly parallelize matrix builds across cloud infrastructure, turning hour-long build pipelines into minutes without managing build infrastructure.
  • Resource Optimization: Leverage Build Cloud’s distributed caching and deduplication to dramatically reduce bandwidth usage and build times, which is especially valuable for remote teams.
  • Cost Management: Save cost with DBC Bake’s precise target definitions mean you only consume cloud resources for exactly what needs to be built.
  • Developer Experience: Teams can run complex multi-architecture builds without powerful local machines, enabling development from any device while maintaining build performance.
  • CI/CD Enhancement: Offload resource-intensive builds from CI runners to Build Cloud, reducing CI costs and queue times while improving reliability.

What’s New in Bake for GA?

Docker Bake has been an experimental feature for several years, allowing us to refine and improve it based on user feedback. So, there is already a strong set of ingredients that users love, such as targets and groups, variables, HCL Expression Support, inheritance capabilities, matrix targets, and additional contexts. With this GA release, Bake is now ready for production use, and we’ve added several enhancements to make it more efficient, secure, and easier to use:

  • Deduplicated Context Transfers: Significantly speeds up build pipelines by eliminating redundant file transfers when multiple targets share the same build context.
  • Entitlements: Enhances security and resource management by providing fine-grained control over what capabilities and resources builders can access during the build process.
  • Composable Attributes: Simplifies configuration management by allowing teams to define reusable attribute sets that can be mixed, matched, and overridden across different targets.
  • Variable Validation: Prevents wasted time and resources by catching configuration errors before the actual build process begins.

Deduplicate context transfers

When you build targets concurrently using groups, build contexts are loaded independently for each target. If the same context is used by multiple targets in a group, that context is transferred once for each time it’s used. This can significantly impact build time, depending on your build configuration.

Previously, the workaround required users to define a named context that loads the context files and then have each target reference the named context. But with Bake, this will be handled automatically now.

Bake can automatically deduplicate context transfers from targets sharing the same context. When you build targets concurrently using groups, build contexts are loaded independently for each target. If the same context is used by multiple targets in a group, that context is transferred once for each time it’s used. This more efficient approach leads to much faster build time. 

Read more about how to speed up your build time in our docs

Entitlements

Bake now includes entitlements to control access to privileged operations, aligning with Build. This prevents unintended side effects and security risks. If Bake detects a potential issue — like a privileged access request or an attempt to access files outside the current directory — the build will fail unless explicitly allowed.

To be consistent, the Bake command now supports the --allow=ENTITLEMENT flag to grant access to additional entitlements. The following entitlements are currently supported for Bake.

  • Build equivalents
    • --allow network.host Allows executions with host networking.
    • --allow security.insecure Allows executions without sandbox. (i.e. —privileged)
  • File system: Grant filesystem access for builds that need access files outside the working directory. This will impact context, output, cache-from, cache-to, dockerfile, secret
    • --allow fs=<path|*> Grant read and write access to files outside the working directory.
    • --allow fs.read=<path|*> Grant read access to files outside the working directory.
    • --allow fs.write=<path|*> Grant write access to files outside the working directory.
  • ssh
    • --allow ssh – Allows exposing SSH agent.

Composable attributes

Several attributes previously had to be defined in CSV (e.g. type=provenance,mode=min). These were challenging to read and couldn’t be easily overridden. The following can now be defined as structured objects:

target "app" {
		attest = [
			{ type = "provenance", mode = "max" },
			{ type = "sbom", disabled = true}
		]

		cache-from = [
			{ type = "registry", ref = "user/app:cache" },
			{ type = "local", src = "path/to/cache"}
		]

		cache-to = [
			{ type = "local", dest = "path/to/cache" },
		]

		output = [
			{ type = "oci", dest = "../out.tar" },
			{ type = "local", dest="../out"}
		]

		secret = [
			{ id = "mysecret", src = "path/to/secret" },
			{ id = "mysecret2", env = "TOKEN" },
		]

		ssh = [
			{ id = "default" },
			{ id = "key", paths = ["path/to/key"] },
		]
}

As such, the attributes are now composable. Teams can mix, match, and override attributes across different targets which simplifies configuration management.

 target "app-dev" {
    attest = [
			{ type = "provenance", mode = "min" },
			{ type = "sbom", disabled = true}
		]
  }

  target "app-prod" {
    inherits = ["app-dev"]

    attest = [
			{ type = "provenance", mode = "max" },
		]
  }

Variable validation

Bake now supports validation for variables similar to Terraform to help developers catch and resolve configuration errors early. The GA for Bake also supports the following use cases.

Basic validation

To verify that the value of a variable conforms to an expected type, value range, or other condition, you can define custom validation rules using the validation block.

variable "FOO" {
  validation {
    condition = FOO != ""
    error_message = "FOO is required."
  }
}

target "default" {
  args = {
    FOO = FOO
  }
}

Multiple validations

To evaluate more than one condition, define multiple validation blocks for the variable. All conditions must be true.

variable "FOO" {
  validation {
    condition = FOO != ""
    error_message = "FOO is required."
  }
  validation {
    condition = strlen(FOO) > 4
    error_message = "FOO must be longer than 4 characters."
  }
}

target "default" {
  args = {
    FOO = FOO
  }
}

Dependency on other variables

You can reference other Bake variables in your condition expression, enabling validations that enforce dependencies between variables. This ensures that dependent variables are set correctly before proceeding.

variable "FOO" {}
variable "BAR" {
  validation {
    condition = FOO != ""
    error_message = "BAR requires FOO to be set."
  }
}

target "default" {
  args = {
    BAR = BAR
  }
}

New Bake options

In addition to updating the Bake configuration, we’ve added a new –list option. Previously, if you were unfamiliar with a project or wanted a reminder of the supported targets and variables, you would have to read through the file. Now, the list option will allow you to quickly query a list of them. It also supports the JSON format option if you need programmatic access.

List target

Quickly get a list of the targets available in your Bake configuration.

  • docker buildx bake --list targets
  • docker buildx bake --list type=targets,format=json

List variables

Get a list of variables available for your Bake configuration.

  • docker buildx bake --list variables
  • docker buildx bake --list type=variables,format=json

These improvements build on a powerful feature set, ensuring Bake is both reliable and future-ready.

Get started with Docker Bake

Ready to simplify your builds? Update to Docker Desktop 4.38 today and start using Bake. With its declarative syntax and advanced features, Docker Bake is here to help you build faster, more efficiently, and with less effort.

Explore the documentation to learn how to create your first Bake file and experience the benefits of streamlined builds firsthand.

Let’s bake something amazing together!

Docker Desktop 4.33: GA Releases of Docker Debug and Docker Build Checks Plus Enhanced Configuration Integrity Checks   

Key features of the Docker Desktop 4.33 release include: 

Docker Desktop 4.33 is packed with powerful new features designed to elevate your container development experience. Docker Desktop 4.33 includes GA releases of Docker Debug and Docker Build checks, and significant UX improvements to the Configuration integrity check. These features provide robust tools for debugging, building, and maintaining containerized applications, ensuring a more efficient and user-friendly development environment.

2400x1260 4.33 rectangle docker desktop release

Docker Debug GA released

Developers face significant hurdles when debugging their applications within containers. Traditionally, debugging slim containers or those without a shell has been a challenging task. Developers have had to rebuild images or use workarounds to gain visibility into container internals, which is time-consuming and error-prone. The most common existing method, docker exec -it, comes with significant limitations, particularly for modern slim containers that remove basic tools like ping or Vim, hindering efficient debugging processes.

We are pleased to announce that Docker Debug, initially introduced as a beta feature in Docker Desktop 4.27, is now generally available (GA) in Docker Desktop 4.33. This powerful feature is accessible to all Docker users with a Pro, Teams, or Business license.

Docker Debug revolutionizes the debugging process by providing a seamless and efficient way to get a shell into any container (regardless of state) or image, even those that are slimmed down and lack a shell. This capability is crucial for maintaining the security and performance of containerized applications without compromising the ability to troubleshoot issues effectively. Now, you can access a dedicated shell for quick issue resolution directly from the Docker Desktop CLI or GUI for efficient debugging, targeting both local and remote applications.

dd433 f1
Figure 1: Docker Debug is now generally available.

Key benefits of Docker Debug

Improved productivity

  • Simplified commands: The docker debug command simplifies attaching a shell to any container or image. This reduces the cognitive load on developers, allowing them to focus on solving problems rather than configuring their environment.
  • Dynamic port forwarding: Break the isolation between the container and the host OS, making it easier to troubleshoot network-related issues.

Enhanced debugging capabilities

  • Shell access: Docker Debug provides a robust debug shell equipped with essential tools by default, such as Vim, Nano, htop, curl, and more. This makes it easy to inspect and modify container contents.
  • Support for slim containers: Even if a container does not include a shell, Docker Debug allows you to attach a debug shell, facilitating troubleshooting without needing to modify the container image.
  • Persistent customizations: Customize your debugging environment with additional tools using the built-in NixOS package manager. These customizations persist across debug sessions, enhancing your workflow efficiency.

Seamless integration

  • Integration with existing workflows: Docker Debug integrates seamlessly with your existing Docker workflows. Whether you are working with running containers, stopped containers, or just images, Docker Debug provides a consistent and intuitive interface for debugging.
  • Remote debugging: Use Docker Debug to troubleshoot containers running on remote Docker instances, enhancing your ability to manage and debug applications deployed across different environments.

Docker Debug is a game-changer for developers working with containerized applications. By simplifying and enhancing the debugging process, Docker Debug empowers developers to maintain secure, performant, and reliable applications. Upgrade to Docker Desktop 4.33 today and experience the power of Docker Debug.

For more details, refer to the Docker Debug docs.

Docker Build checks GA released 

Docker Desktop is more than a simple containerization tool — it’s a comprehensive solution designed to support developers at every stage of the development process. With Docker Build checks in Docker Desktop 4.33, we’ve enhanced BuildKit — the powerful engine behind Docker Build and Docker Build Cloud — to ensure Dockerfiles meet the highest standards. 

Ensuring that Dockerfiles adhere to best practices can be challenging for development teams. Evaluating and maintaining the quality of Dockerfiles across local and CI workflows — including complex multi-stage builds, which leads to inefficient builds, increased build times, and potential security vulnerabilities — can be difficult. 

Docker Build checks guide developers in writing optimized Dockerfiles, improving efficiency and reducing build times. We have enhanced BuildKit, our build engine behind Docker Build and Docker Build Cloud, to support guiding you on best practices for writing great Dockerfiles. Driving your team to follow best practices enhances security and reduces your build times in Docker Build Cloud.

By using Docker Build checks to evaluate all stages of your local and CI workflows, including multi-stage builds and bake, and deep-dive in Docker Desktop Builds view, you ensure that your Dockerfiles are set up to leverage the full potential of Docker Build Cloud. This new feature not only saves you time in maintaining your Dockerfiles, but also enhances your overall build performance in Docker Build Cloud. 

To fully benefit from Docker Build Cloud, we encourage you to authenticate and explore how Docker Build checks can elevate your development experience and drive you toward more efficient and high-quality container builds. 

dd433 f2
Figure 2: Build checks warnings in Docker Desktop Build view.

Configuration integrity check 2.0 

In the past, Docker Desktop users have encountered disruptive warning messages about configuration issues, which can interrupt their workflow and lead to repeated and ineffective repair attempts. To improve the overall user experience and ensure smoother operation of Docker Desktop, a more user-friendly and efficient way to alert users about configuration problems, provide actionable guidance, and handle errors has been needed. Our latest release includes a new and improved UX for the Configuration integrity check for macOS, with:

  • Banner migrated to Notification Center: The warning is now less obtrusive and appears as an alert in the Notification Center.
  • Actionable alert: The Notification Center will read Find out more instead of Repair. Clicking it will open a pop-up with details on configuration changes (such as incorrect or missing symlinks) and the option to repair.
  • Error-handling improvements: Introducing an error dialogue with a diagnostic upload option if the check fails, operating system checks, and preventing the Integrity Repair from running multiple times if the user clicks Repair in quick succession.

If you ignore the notification, it will be shown again only at the next Docker Desktop startup. If you choose to repair your configuration, you won’t be prompted again.

If you want to switch off Configuration integrity check notifications, navigate to Docker Desktop’s Settings and in the General tab, and clear the Automatically check configuration setting.

Fill out the feedback form if you have feedback on how to improve the Configuration integrity check feature further.

dd433 f3
Figure 3: Clicking the notification will open a pop-up with details on configuration changes and the option to repair.

Conclusion 

Docker Desktop 4.33 is another milestone in our commitment to providing an industry-leading container development suite. By introducing features like Docker Debug, Docker Build checks, and improved Configuration integrity check, we empower development teams to write better Dockerfiles, troubleshoot applications with ease, and maintain optimal configurations. These enhancements drive productivity and streamline workflows, solidifying Docker Desktop as your launchpad for engineering excellence. Upgrade to Docker Desktop 4.33 today and experience the future of container development. 

Learn more

Introducing Docker Build Checks: Optimize Dockerfiles with Best Practices

Today, we’re excited to announce the release of Docker Build checks with Docker Desktop 4.33. Docker Build checks help your team learn and follow best practices for building container images. When you run a Docker Build, you will get a list of warnings for any check violations detected in your build. Taking a proactive approach and resolving Build warnings and issues early will save you time and headaches downstream. 

banner how to set up the weaviate vector database on docker

Why did we create Docker Build checks?

During conversations with developers, we found that many struggle to learn and follow the best practices for building container images. According to our 2024 State of Application Development Report, 35% of Docker users reported creating and editing Dockerfiles as one of the top three tasks performed. However, 55% of respondents reported that creating Dockerfiles is the most selected task they refer to support. 

Developers often don’t have the luxury of reading through the Docker Build docs, making the necessary changes to get things working, and then moving on. A Docker Build might “work” when you run docker build, but a poorly written Dockerfiles may introduce quality issues, such as they are:

  • Hard to maintain or update
  • Contain hidden and unexpected bugs 
  • Have sub-optimal performance

In our conversations with Docker users, we heard that they want to optimize their Dockerfiles to improve build performance, aren’t aware of current best practices, and would like to be guided as they build. 

Investigating and fixing build issues wastes time. We created Docker Build checks to empower developers to write well-structured Dockerfiles from the get-go and learn from existing best practices. With Build checks, your team spends less time on build issues and more on innovation and coding.   

Why should you use Docker Build checks? 

You want to write better Dockerfiles and save time! 

We have collected a set of best practices from the community of build experts and codified them into Docker Build tooling. You can use Docker Build checks to evaluate all stages of your local and CI workflows, including multi-stage builds and Bake, and deep dive in the Docker Desktop Builds view. You can also choose which rules to skip. 

You can access Docker Build checks in the CLI and in the Docker Desktop Builds view. 

More than just linting: Docker Build checks are powerful and fast 

Linting tools typically just evaluate the text files against a set of rules. As a native part of Docker Build, the rules in Docker Build checks are more powerful and accurate than just linting. Docker Build checks evaluate the entire build, including the arguments passed in and the base images used. These checks are quick enough to be run in real-time as you edit your Dockerfile. You can quickly evaluate a build without waiting for a full build execution. 

Check your local builds

A good practice is to evaluate a new or updated Dockerfile before committing or sharing your changes. Running docker build will now give you an overview of issues and warnings in your Dockerfile.

build checks 433 f1
Figure 1: A Docker Build with four check warnings displayed.

To get more information about these specific issues, you can specify the debug flag to the Docker CLI with docker --debug build. This information includes the type of warning, where it occurs, and a link to more information on how to resolve it. 

build checks 433 f2
Figure 2: Build debug output for the check warnings.

Quickly check your build

Running these checks during a build is great, but it can be time-consuming to wait for the complete build to run each time when you’re making changes or fixing issues. For this reason, we added the --check flag as part of the build command. 

# The check flag can be added anywhere as part of your build command
docker build . --check
docker build --check .
docker build --build-arg VERSION=latest --platfrom linux/arm64 . --check

As illustrated in the following figure, appending the flag to your existing build command will do the same full evaluation of the build configuration without executing the entire build. This faster feedback typically completes in less than a second, making for a smoother development process. 

build checks 433 f3
Figure 3: Running check of build.

Check your CI builds

By default, running a Docker build with warnings will not cause the build to fail (return a non-zero exit code). However, to catch any regressions in your CI builds, add the following declarations to instruct the checks to generate errors. 

# syntax=docker/dockerfile:1
# check=error=true

FROM alpine
CMD echo "Hello, world!"

Checking multi-stage builds in CI

During a build, only the specified stage/target, including its dependent, is executed. We recommend adding a stage check step in your workflow to do a complete evaluation of your Dockerfile. This is similar to how you would run automated tests before executing the full build.

If any warnings are detected, it will return a non-zero exit code, which will cause the workflow to fail, therefore catching any issues.

docker build --check .

Checking builds in Docker Build Cloud

Of course, this also works seamlessly with Docker Build Cloud, both locally and through CI. Use your existing cloud builders to evaluate your builds. Your team now has the combined benefit of Docker Build Cloud performance with the reassurance that the build will align with best practices. In fact, as we expand our checks, you should see even better performance from your Docker Build Cloud builds.

build checks 433 f4
Figure 4: Running checks in Docker Build Cloud.

Configure rules

You have the flexibility to configure rules in Build checks with a skip argument. You can also specify skip=all or skip=none to toggle the rules on and off. Here’s an example of skipping the JSONArgsRecommended and StageNameCasing rules:

# syntax=docker/dockerfile:1
# check=skip=JSONArgsRecommended,StageNameCasing

FROM alpine AS BASE_STAGE
CMD echo "Hello, world!"

Dive deep into Docker Desktop Builds view

In Docker Desktop Builds view, you can see the output of the build warnings. Locating the cause of warnings in Dockerfiles and understanding how to resolve them quickly is now easy.

As with build errors, warnings are shown inline with your Dockerfile when inspecting a build in Docker Desktop:

build checks 433 f5
Figure 5: Build checks warnings in Docker Desktop Builds view.

What’s next? 

More checks

We are excited about the new Builds checks to help you apply best practices to your Dockfiles, but this is just the start. In addition to the current set of checks, we plan on adding even more to provide a more comprehensive evaluation of your builds. Further, we look forward to including custom checks and policies for your Docker builds.

IDE integration

The earlier you identify issues in your builds, the easier and less costly it is to resolve them. We plan to integrate Build checks with your favorite IDEs so you can get real-time feedback as you type.

build checks 433 f6
Figure 6: Check violations displaying in VS Code.

GitHub Actions and Docker Desktop

You can already see Build checks warnings in Docker Desktop, but more detailed insights are coming soon to Docker Desktop. As you may have heard, we recently announced Inspecting Docker Builds in GitHub Actions’s beta release, and we plan to build on this new functionality to include support for investigating check warnings.

Get started now

To get started with Docker Build checks, upgrade to Docker Desktop 4.33 today and try them out with your existing Dockerfiles. Head over to our documentation for a more detailed breakdown of Build checks. 

Learn more

❌