Docker today introduced three new software development tools designed to marry the convenience and responsiveness of local development to the resources and connectivity of the cloud, effectively "blurring the boundaries between local and remote development," Docker CEO Scott Johnston said.

Most developers don't want to ship the entire contents of their laptop to the cloud, though inner loop development processes (code-build-test-debug) could benefit from the cloud's collaboration and capacity capabilities, for example. To bring the cloud to those preferably-remote development activities, Docker released Docker Scout in GA and the next generation of Docker Build and Docker Debug in public beta.

Based on feedback from its developer community and observations of fellow market players, Docker realized most development products follow an all-or-nothing strategy. "Either the product is 100% local or it's 100% cloud," Johnston told SDxCentral. The tools released today "are unique in that they meet the developer why they are by combining the best of local with the best of cloud," he said

These tools, each based on open source and open standards, are distributed in the containerization platform Docker Desktop but can be used independently. Johnston said the new products will "initially bring delight to existing users," but given their potential to "reduce the overall friction of using Docker, we expect this ease of use will, over time, attract new users."

Docker Scout is aimed at clarifying next steps for developers to improve the quality of their software amid the myriad of tools, processes and people in the software supply chain. This tool complements Docker's current content, build automation and software bill of materials (SBOM) tools while adding features like insights, policy evaluation and contextual remediation.

Using the cloud, for example, the tool collects and analyzes metadata from the software supply on images, continuous integration events, scanning results and common vulnerabilities and exposures (CVE) advisories. Based on that information, Docker Scout identifies what the developer is working on locally and only provides recommendations that are relevant to that work.

Docker Scout is compatible with Sysdig, JFrog Artifactor, Amazon Web Services (AWS) Elastic Container Registry (ECR), GitHub, GitLab, Jenkins and CircleCI.

To cut down on the time developers spend waiting for image builds to finish, Docker updated Docker Build to accelerate build time up to 39x. To do this, the tool automates the use of large, on-demand cloud servers and development team-wide build caching.

"There are currently no other services on the market exactly like next-gen Docker Build that offload inner loop builds seamlessly from the laptop to the cloud," Johnston said.

Alternative build options available on the market today are primarily outer loop builds, or CI. Using those tools, developers need to commit code changes to GitHub or GitLab to trigger the CI and wait for the results before conducting a build. The process can take anywhere from 15 minutes to an hour.

Docker Build, however, lets developers use local build tools, commands, Dockerfiles, and environment configurations while offloading the actual build itself to the cloud.

Docker Debug takes a different route to debugging, Johnston said. Rather than requiring developers to "jump into the container and work around the constraints of that container" or operate within a broken container, the tool runs a new container and "brings the broken container into its scope," he said.

A car mechanic, for example, might travel to a broken down vehicle with a few tools. Or the driver can take their vehicle right to the mechanic's garage. "Docker Debug is that garage," Johnston said.

The debugging container, which Docker calls a toolbox, mounts the broken container filesystem. "Because you're in the debugging container, you can have your tools, etc. It's your garage after all. We do some other things like analyzing entry points, validating the architecture of the binaries of the entry point or the CMD, and provide a better UX [user experience] around understanding what the problem might be," he said.

To create one filesystem that holds all of its debug tools, Docker Debug uses Nix, a package manager, to create a second filesystem with the tools that need to be overwritten or added. "Then, we use mergerfs to merge both filesystems: the original container filesystem and the debug tools filesystem. The result is a filesystem identical to the original container plus all the debugging tools."