Search the Community

Imagine you’re deep in the zone, coding away on a groundbreaking project. The ideas are flowing, the coffee’s still warm, and then — bam! An error message pops up, halting your progress like a red light at a busy intersection. We’ve all been there, staring at cryptic codes or vague advice, feeling more like ancient mariners navigating by the stars than modern developers armed with cutting-edge technology. This scenario is all too familiar in the world of software development. With an arsenal of tools, languages, platforms, and security protocols at our disposal, the complexity of our work environment has skyrocketed. For developers charting the unexplored territories of innovation, encountering errors can feel like facing a tempest with a leaky boat. But fear not, for Docker Desktop sails to the rescue with a lighthouse’s guidance: a new, intuitive prompt that sheds light on the mysterious seas of error messages. Enhancing Docker Desktop with advanced error management In our Docker Desktop 4.29 release, we’ve embarked on an ambitious journey to elevate the user experience by fundamentally redefining error management. This initiative goes far beyond simple bug fixes; it aims to create a development environment that is not only more efficient and reliable but also more satisfying for developers. At the heart of these enhancements is our unwavering commitment to empowering users and providing them with the tools they need to recover swiftly from any setbacks they may encounter. This strategic update is built around a core objective: pivoting Docker Desktop toward a model that supports self-service troubleshooting and fosters user resilience. By reimagining errors as opportunities for learning and growth, we’re doing more than just solving technical problems. We’re transforming how developers interact with Docker Desktop, enabling them to overcome challenges confidently and enhance their skills in the process. The changes introduced in Docker Desktop 4.29 signify a significant leap forward in our mission to address user issues and enhance their ability to navigate the complexities of software development with ease and efficiency. Bridging the gap: From frustration to resolution Previously, encountering an error in Docker Desktop could feel like reaching a dead end. Users were often greeted with cryptic error codes or minimal guidance, lacking the necessary context for a swift resolution. This outdated approach impeded user experience, efficiency, and overall satisfaction. The contrast with our new system couldn’t be more stark: Users now receive actionable insights when an error arises, ensuring every issue is a step toward a solution (Figure 1). Figure 1: Previous Docker Desktop error message: 4.28 and earlier did not provide intuitive instructions on how to remediate. Empowering users, reducing support tickets This latest update introduces an intuitive error management interface, direct diagnostic uploads, and self-service remediation options. These enhancements make troubleshooting more accessible and reduce the need for support inquiries, improving Docker Desktop’s usability and reliability specifically in the following ways: 1. Enhanced error interface: Introducing an updated error interface that combines raw error codes with helpful explanatory text, including links for streamlined support. This not only makes troubleshooting more accessible but also significantly enhances the support process. 2. Direct diagnostic uploads: Users can now easily collect and upload diagnostics directly from the error screen. This feature enhances our support and troubleshooting capabilities, making it easier for users to get the help they need without navigating away from the error context. 3. Reset and exit options: Recognizing that some situations may require more drastic measures, the updated error interface also allows users to reset the application to factory settings or exit the application directly from the error screen (Figure 2). Figure 2: New Docker Desktop error message: 4.29 release providing remediation information and diagnostic sharing options. 4. Self-Service Options: For errors within the user’s ability to remedy, the error message now provides a user-friendly technical error description accompanied by clear, actionable buttons for immediate remediation. This reduces the need for support tickets and fosters a sense of user empowerment. Figure 3: Error message displaying self-service remediation options. Conclusion This update is evidence of our continuous focus on refining and enhancing our Docker Desktop users’ experiences — and there are more updates to come. We’re committed to making every aspect of application development as intuitive and empowering as possible. Look for further improvements as we continue to advance the state of user support and error remediation that supports sky-rocketing your innovation trajectory and productivity. Learn more Read the Docker Desktop 4.29 announcement to learn more about the advancements in the latest release. Authenticate and update to receive your subscription level‘s newest Docker Desktop features. New to Docker? Create an account. Read the Docker Desktop Release Notes. Learn about Docker Build Cloud and how you can leverage cloud resources directly from Docker Desktop. Subscribe to the Docker Newsletter. Have questions? The Docker community is here to help. View the full article

The release of Docker Desktop 4.29 introduces enhancements to secure and streamline the development process and to improve error management and workflow efficiency. With the integration of Enhanced Container Isolation (ECI) with Docker socket mount permissions, the debut of Moby 26 within Docker Desktop, and exciting features such as Docker Compose enhancements via synchronized file shares reaching beta release, we’re equipping developers with the essential resources to tackle the complexities of modern development head-on. Dive into the details to discover these new enhancements and get a sneak peek at exciting advancements currently in beta release. Enhanced Container Isolation with Docker socket mount permissions We’re pleased to unveil a new feature in the latest Docker Desktop release, now in General Availability to Business subscribers, that further improves Desktop’s Enhanced Container Isolation (ECI) mode: Docker socket mount permissions. This update blends robust security with the flexibility you love, allowing you to enjoy key development tools like Testcontainers with the peace of mind provided by ECI’s unprivileged containers. Initially launched in beta with Docker Desktop 4.27, this update moves the ECI Docker socket mount permissions feature to General Availability (GA), demonstrating our commitment to making Docker Desktop the best modern application development platform. The Docker Engine socket, a crucial component for container management, has historically been a vector for potential security risks. Unauthorized access could enable malicious activities, such as supply chain attacks. However, legitimate use cases, like the Testcontainers framework, require socket access for operational tasks. With ECI, Docker Desktop enhances security by default, blocking unapproved bind-mounting of the Docker Engine socket into containers. Yet, recognizing the need for flexibility, we introduce controlled access through admin-settings.json configuration. This allows specified images to bind-mount the Docker socket, combining security with functionality. Key features include: Selective permissions: Admins can now specify which container images can access the Docker socket through a curated imageList, ensuring that only trusted containers have the necessary permissions. Command restrictions: The commandList feature further tightens security by limiting the Docker commands approved containers can execute, acting as a secondary defense layer. While we celebrate this release, our journey doesn’t stop here. We’re continuously exploring ways to expand Docker Desktop’s capabilities, ensuring our users can access the most secure, efficient, and user-friendly containerization tools. Stay tuned for further security enhancements, including our beta release of air-gapped containers. Update to Docker Desktop 4.29 to start leveraging the full potential of Enhanced Container Isolation with Docker socket mount permissions today. Advanced error management in Docker Desktop We’re redefining error management to significantly improve the developer experience. This update isn’t just about fixing bugs; it’s a comprehensive overhaul aimed at making the development process more efficient, reliable, and user-friendly. Central to this update is our shift toward self-service troubleshooting and resilience, transforming errors from roadblocks into opportunities for growth and learning. The new system presents actionable insights for errors, ensuring developers can swiftly move toward a resolution. Key enhancements include: An enhanced error interface: Combining error codes with explanatory text and support links, making troubleshooting straightforward. Direct diagnostic uploads: Allowing users to share diagnostics from the error screen, streamlining support. Reset and exit options: Offering quick fixes directly from the error interface. Self-service remediation: Providing clear, actionable steps for users to resolve issues independently (Figure 1). Figure 1: Error message displaying self-service remediation options. This update marks a significant leap in our commitment to enhancing the Docker Desktop user experience, empowering developers, and reducing the need for support tickets. Read Next-Level Error Handling: How Docker Desktop 4.29 Aims to Simplify Developer Challenges to dive deeper into these enhancements in our blog and discover how Docker Desktop 4.29 is setting a new standard for error management and developer support. New in Docker Engine: Volume subpath mounts, networking enhancements, BuildKit 0.13, and more In the latest Docker Engine update, Moby 26, packaged in Docker Desktop 4.29, introduces several enhancements aimed at enriching the developer experience. Here’s the breakdown of what’s new: Volume subpath mounts: Responding to widespread user requests, we’ve made it possible to mount a subdirectory as a named volume. This addition enhances flexibility and control over data management within containers. Detailed guidance on specifying these mounts is available in the docs. Networking enhancements: Significant improvements have been made to bolster the stability of networking capabilities within the engine, along with preliminary efforts to support future IPv6 enhancements. Integration of BuildKit 0.13: Among other updates, this BuildKit version includes experimental support for Windows Containers, ensuring builds remain dependable and efficient. Streamlined API: Deprecated API versions have been removed, concentrating on quality enhancements and promoting a more secure, reliable environment. Multi-platform image enhancements: In this release, you’ll see an improved docker images UX as we’ve combined image entries for multi-platform images. Beta release highlights Docker Debug in Docker Desktop GUI and CLI Docker Debug (Beta), a recent addition to Docker Desktop, streamlines the debugging process for developers. This feature, accessible in Docker Pro, Teams, and Business subscriptions, offers a shell for efficiently debugging both local and remote containerized applications — even those that fail to run. With Docker Debug, developers can swiftly pinpoint and address issues, freeing up more time for innovation. Now, in beta release, Docker Debug introduces comprehensive debugging directly from the Docker Desktop CLI for active and inactive containers alike. Moreover, the Docker Desktop GUI has been enhanced with an intuitive option: Click the toggle in the Exec tab within a container to switch on Debug mode to start debugging with the necessary tools at your fingertips. Figure 2: Docker Desktop containers view showcasing debugging a running container with Docker Debug. To dive into Docker Debug, ensure you’re logged in with your subscription account, then initiate debugging by executing docker debug <Container or Image name> in the CLI or by selecting a container from the GUI container list for immediate debugging from any device local or in the cloud. Improved volume backup capabilities With our latest release, we’re elevating volume backup capabilities in Docker Desktop, introducing an upgraded feature set in beta release. This enhancement directly integrates the Volumes Backup & Share extension directly into Docker Desktop, streamlining your backup processes. Figure 3: Docker Desktop Volumes view showcasing new backup functionality. This release marks a significant step forward, but it’s just the beginning. We’re committed to expanding these capabilities, adding even more value in future updates. Start exploring the new feature today and prepare for an enhanced backup experience soon. Support for host network mode on Docker Desktop for Mac and Windows Support for host network mode (docker run –net=host), previously limited to Linux users, is now available for Mac and Windows Docker Desktop users, offering enhanced networking capabilities and flexibility. With host network mode support, Docker Desktop becomes a more versatile tool for advanced networking tasks, such as dynamic network penetration testing, without predefined port mappings. This feature is especially useful for applications requiring the ability to dynamically accept connections on various ports, just as if they were running directly on the host. Features include: Simplified networking: Eases the setup for complex networking tasks, facilitating security testing and the development of network-centric applications. Greater flexibility: Allows containers to use the host’s network stack, avoiding the complexities of port forwarding. Figure 4: The host network mode enhancement in Preview Beta reflects our commitment to improving Docker Desktop and is available after authenticating against all Docker subscriptions. Enhancing security with Docker Desktop’s new air-gapped containers Docker Desktop’s latest beta feature, air-gapped containers, is now available in version 4.29, reflecting our deep investment in security enhancements. This Business subscription feature empowers administrators to limit container access to network resources, tightening security across containerized applications by: Restricting network access: Ensuring containers communicate only with approved sources. Customizing proxy rules: Allowing detailed control over container traffic. Enhancing data protection: Preventing unauthorized data transfer in or out of containers. The introduction of air-gapped containers is part of our broader effort to make Docker Desktop not just a development tool, but an even more secure development environment. We’re excited about the potential this feature holds for enhancing security protocols and simplifying the management of sensitive data. Compose bind mount support with synchronized file shares We’re elevating the Docker Compose experience for our subscribers by integrating synchronized file shares (SFS) directly into Compose. This feature eradicates the sluggishness typically associated with managing large codebases in containers. Formerly known as Mutagen, synchronized file shares enhances bind mounts with native filesystem performance, accelerating file operations by an impressive 2-10x. This leap forward is incredibly impactful for developers handling extensive codebases, effortlessly streamlining their workflow. With a Docker subscription, you’ll find that Docker Compose and SFS work together seamlessly, automatically optimizing bind mounts to significantly boost synchronization speeds. This integration requires no additional configuration; Compose intelligently activates SFS whenever a bind mount is used, instantly enhancing your development process. Enabling synchronized file shares in Compose is simple: Log into Docker Desktop. Under Settings, navigate to Features in development and choose the Experimental features tab. Enable Access experimental features and Manage Synchronized file shares with Compose. Once set up via Docker Desktop settings, these folders act as standard bind mounts with the added benefit of SFS speed enhancements. Figure 5: Docker Desktop settings displaying the option to turn on synchronized file shares with Docker Compose. Figure 6: Demonstration of compose up creating and synching shares in the terminal. If your Compose project relies on a bind mount that could benefit from synchronized file shares, the initial share creation must be done through the Docker Desktop GUI. Embrace the future of Docker Compose with Docker Desktop’s synchronized file shares and transform your development workflow with unparalleled speed and efficiency. Try Docker Desktop 4.29 now Docker Desktop 4.29 introduces updates focused on innovation, security, and enhancing the developer experience. This release integrates community feedback and advances Docker’s capabilities, providing solutions that meet developers’ and businesses’ immediate needs while setting the stage for future features. We advise all Docker users to upgrade to version 4.29. Please note that access to certain features in this release requires authentication and may be contingent upon your subscription tier. We encourage you to evaluate your feature needs and select the subscription level that best suits your requirements. Join the conversation Dive into the discussion and contribute to the evolution of Docker Desktop. Use our feedback form to share your thoughts and let us know how to improve the Hardened Desktop features. Your input directly influences the development roadmap, ensuring Docker Desktop meets and exceeds our community and customers’ needs. Learn more Authenticate and update to receive the newest Docker Desktop features per your subscription level. New to Docker? Create an account. Read the Docker Desktop Release Notes. Read Next-Level Error Handling: How Docker Desktop 4.29 Aims to Simplify Developer Challenges. Learn about Docker Build Cloud and how you can leverage cloud resources directly from Docker Desktop. Subscribe to the Docker Newsletter. Have questions? The Docker community is here to help. View the full article

Docker Desktop 4.28 introduces updates to file-sharing controls, focusing on security and administrative ease. Responding to feedback from our business users, this update brings refined file-sharing capabilities and path allow-listing, aiming to simplify management and enhance security for IT administrators and users alike. Along with our investments in bringing access to cloud resources within the local Docker Desktop experience with Docker Build Cloud Builds view, this release provides a more efficient and flexible platform for development teams. Introducing enhanced file-sharing controls in Docker Desktop Business As we continue to innovate and elevate the Docker experience for our business customers, we’re thrilled to unveil significant upgrades to the Docker Desktop’s Hardened Desktop feature. Recognizing the importance of administrative control over Docker Desktop settings, we’ve listened to your feedback and are introducing enhancements prioritizing security and ease of use. For IT administrators and non-admin users, Docker now offers the much-requested capability to specify and manage file-sharing options directly via Settings Management (Figure 1). This includes: Selective file sharing: Choose your preferred file-sharing implementation directly from Settings > General, where you can choose between VirtioFS, gRPC FUSE, or osxfs. VirtioFS is only available for macOS versions 12.5 and above and is turned on by default. Path allow-listing: Precisely control which paths users can share files from, enhancing security and compliance across your organization. Figure 1: Display of Docker Desktop settings enhanced file-sharing settings. We’ve also reimagined the Settings > Resources > File Sharing interface to enhance your interaction with Docker Desktop (Figure 2). You’ll notice: Clearer error messaging: Quickly understand and rectify issues with enhanced error messages. Intuitive action buttons: Experience a smoother workflow with redesigned action buttons, making your Docker Desktop interactions as straightforward as possible. Figure 2: Displaying settings management in Docker Desktop to notify business subscribers of their access rights. These enhancements are not just about improving current functionalities; they’re about unlocking new possibilities for your Docker experience. From increased security controls to a more navigable interface, every update is designed with your efficiency in mind. Refining development with Docker Desktop’s Builds view update Docker Desktop’s previous update introduced Docker Build Cloud integration, aimed at reducing build times and improving build management. In this release, we’re landing incremental updates that refine the Builds view, making it easier and faster to manage your builds. New in Docker Desktop 4.28: Dedicated tabs: Separates active from completed builds for better organization (Figure 3). Build insights: Displays build duration and cache steps, offering more clarity on the build process. Reliability fixes: Resolves issues with updates for a more consistent experience. UI improvements: Updates the empty state view for a clearer dashboard experience (Figure 4). These updates are designed to streamline the build management process within Docker Desktop, leveraging Docker Build Cloud for more efficient builds. Figure 3: Dedicated tabs for Build history vs. Active builds to allow more space for inspecting your builds. Figure 4: Updated view supporting empty state — no Active builds. To explore how Docker Desktop and Docker Build Cloud can optimize your development workflow, read our Docker Build Cloud blog post. Experience the latest Builds view update to further enrich your local, hybrid, and cloud-native development journey. These Docker Desktop updates support improved platform security and a better user experience. By introducing more detailed file-sharing controls, we aim to provide developers with a more straightforward administration experience and secure environment. As we move forward, we remain dedicated to refining Docker Desktop to meet the evolving needs of our users and organizations, enhancing their development workflows and agility to innovate. Join the conversation and make your mark Dive into the dialogue and contribute to the evolution of Docker Desktop. Use our feedback form to share your thoughts and let us know how to improve the Hardened Desktop features. Your input directly influences the development roadmap, ensuring Docker Desktop meets and exceeds our community and customers’ needs. Learn more Authenticate and update to receive the newest Docker Desktop features per your subscription level. New to Docker? Create an account. Read our latest blog on synchronized file shares. Read about what rolled out in Docker Desktop 4.27, including synchronized file shares, Docker Init GA, a private marketplace for extensions, Moby 25, support for Testcontainers with ECI, Docker Build Cloud, and Docker Debug Beta. Learn about Docker Build Cloud. Subscribe to the Docker Newsletter. View the full article

We’re pleased to announce Docker Desktop 4.27, packed with exciting new features and updates. The new release includes key advancements such as synchronized file shares, collaboration enhancements in Docker Build Cloud, the introduction of the private marketplace for extensions (available for Docker Business customers), and the much-anticipated release of Moby 25. Additionally, we explore the support for Testcontainers with Enhanced Container Isolation, the general availability of docker init with expanded language support, and the beta release of Docker Debug. These updates represent significant strides in improving development workflows, enhancing security, and offering advanced customization for Docker users. Docker Desktop synchronized file shares GA We’re diving into some fantastic updates for Docker Desktop, and we’re especially thrilled to introduce our latest feature, synchronized file shares, which is available now in version 4.27 (Figure 1). Following our acquisition announcement in June 2023, we have integrated the technology behind Mutagen into the core of Docker Desktop. You can now say goodbye to the challenges of using large codebases in containers with virtual filesystems. Synchronized file shares unlock native filesystem performance for bind mounts and provides a remarkable 2-10x boost in file operation speeds. For developers managing extensive codebases, this is a game-changer. Figure 1: Shares have been created and are available for use in containers. To get started, log in to Docker Desktop with your subscription account (Pro, Teams, or Business) to harness the power of Docker Desktop synchronized file shares. You can read more about this feature in the Docker documentation. Collaborate on shared Docker Build Cloud builds in Docker Desktop With the recent GA of Docker Build Cloud, your team can now leverage Docker Desktop to use powerful cloud-based build machines and shared caching to reduce unnecessary rebuilds and get your build done in a fraction of the time, regardless of your local physical hardware. New builds can make instant use of the shared cache. Even if this is your first time building the project, you can immediately speed up build times with shared caches. We know that team members have varying levels of Docker expertise. When a new developer has issues with their build failing, the Builds view makes it effortless for anyone on the team to locate the troublesome build using search and filtering. They can then collaborate on a fix and get unblocked in no time. When all your team is building on the same cloud builder, it can get noisy, so we added filtering by specific build types, helping you focus on the builds that are important to you. Link to builder settings for a build Previously, to access builder settings, you had to jump back to the build list or the settings page, but now you can access them directly from a build (Figure 2). Figure 2: Access builder settings directly from a build. Delete build history for a builder And, until now you could only delete build in batches, which meant if you wanted to clear the build history it required a lot of clicks. This update enables you to clear all builds easily (Figure 3). Figure 3: Painlessly clear the build history for an individual builder. Refresh storage data for your builder at any point in time Refreshing the storage data is an intensive operation, so it only happens periodically. Previously, when you were clearing data, you would have to wait a while to see the update. Now it’s just a one-click process (Figure 4). Figure 4: Quickly refresh storage data for a builder to get an up-to-date view of your usage. New feature: Private marketplace for extensions available for Docker Business subscribers Docker Business customers now have exclusive access to a new feature: the private marketplace for extensions. This enhancement focuses on security, compliance, and customization, and empowering developers, providing: Controlled access: Manage which extensions developers can use through allow-listing. Private distribution: Easily distribute company-specific extensions from a private registry. Customized development: Deploy customized team processes and tools as unpublished/private Docker extensions tailored to a specific organization. The private marketplace for extensions enables a secure, efficient, and tailored development environment, aligning with your enterprise’s specific needs. Get started today by learning how to configure a private marketplace for extensions. Moby 25 release — containerd image store We are happy to announce the release of Moby 25.0 with Docker Desktop 4.27. In case you’re unfamiliar, Moby is the open source project for Docker Engine, which ships in Docker Desktop. We have dedicated significant effort to this release, which marks a major release milestone for the open source Moby project. You can read a comprehensive list of enhancements in the v25.0.0 release notes. With the release of Docker Desktop 4.27, support for the containerd image store has graduated from beta to general availability. This work began in September 2022 when we started extending the Docker Engine integration with containerd, so we are excited to have this functionality reach general availability. This support provides a more robust user experience by natively storing and building multi-platform images and using snapshotters for lazy pulling images (e.g., stargz) and peer-to-peer image distribution (e.g., dragonfly, nydus). It also provides a foundation for you to run Wasm containers (currently in beta). Using the containerd image store is not currently enabled by default for all users but can be enabled in the general settings in Docker Desktop under Use containers for pulling and storing images (Figure 5). Figure 5: Enable use of the containerd image store in the general settings in Docker Desktop. Going forward, we will continue improving the user experience of pushing, pulling, and storing images with the containerd image store, help migrate user images to use containerd, and work toward enabling it by default for all users. As always, you can try any of the features landing in Moby 25 in Docker Desktop. Support for Testcontainers with Enhanced Container Isolation Docker Desktop 4.27 introduces the ability to use the popular Testcontainers framework with Enhanced Container Isolation (ECI). ECI, which is available to Docker Business customers, provides an additional layer of security to prevent malicious workloads running in containers from compromising the Docker Desktop or the host by running containers without root access to the Docker Desktop VM, by vetting sensitive system calls inside containers and other advanced techniques. It’s meant to better secure local development environments. Before Docker Desktop 4.27, ECI blocked mounting the Docker Engine socket into containers to increase security and prevent malicious containers from gaining access to Docker Engine. However, this also prevented legitimate scenarios (such as Testcontainers) from working with ECI. Starting with Docker Desktop 4.27, admins can now configure ECI to allow Docker socket mounts, but in a controlled way (e.g., on trusted images of their choice) and even restrict the commands that may be sent on that socket. This functionality, in turn, enables users to enjoy the combined benefits of frameworks such as Testcontainers (or any others that require containers to access the Docker engine socket) with the extra security and peace of mind provided by ECI. Docker init GA with Java support Initially released in its beta form in Docker 4.18, docker init has undergone several enhancements. The docker init command-line utility aids in the initialization of Docker resources within a project. It automatically generates Dockerfiles, Compose files, and .dockerignore files based on the nature of the project, significantly reducing the setup time and complexity associated with Docker configurations. The initial beta release of docker init only supported Go and generic projects. The latest version, available in Docker 4.27, supports Go, Python, Node.js, Rust, ASP.NET, PHP, and Java (Figure 6). Figure 6. Docker init will suggest the best template for the application. The general availability of docker init offers an efficient and user-friendly way to integrate Docker into your projects. Whether you’re a seasoned Docker user or new to containerization, docker init is ready to enhance your development workflow. Beta release of Docker Debug As previously announced at DockerCon 2023, Docker Debug is now available as a beta offering in Docker Desktop 4.27. Figure 7: Docker Debug. Developers can spend as much as 60% of their time debugging their applications, with much of that time taken up by sorting and configuring tools and setup instead of debugging. Docker Debug (available in Pro, Teams, or Business subscriptions) provides a language-independent, integrated toolbox for debugging local and remote containerized apps — even when the container fails to launch — enabling developers to find and solve problems faster. To get started, run docker debug <Container or Image name> in the Docker Desktop CLI while logged in with your subscription account. Conclusion Docker Desktop’s latest updates and features, from synchronized file shares to the first beta release of Docker Debug, reflect our ongoing commitment to enhancing developer productivity and operational efficiency. Integrating these capabilities into Docker Desktop streamlines development processes and empowers teams to collaborate more effectively and securely. As Docker continues to evolve, we remain dedicated to providing our community and customers with innovative solutions that address the dynamic needs of modern software development. Stay tuned for further updates and enhancements, and as always, we encourage you to explore these new features to see how they can benefit your development workflow. Upgrade to Docker Desktop 4.27 to explore these updates and experiment with Docker’s latest features. Learn more Read the Docker Desktop Release Notes. Install and authenticate against the latest release of Docker Desktop. Learn more about synchronized file shares. Check out Docker Build Cloud. Read Streamline Dockerization with Docker Init GA Read Docker Init: Initialize Dockerfiles and Compose files with a single CLI command. Have questions? The Docker community is here to help. New to Docker? Get started. View the full article

We are happy to announce that Mutagen’s file-sharing technology, acquired by Docker, has been seamlessly integrated into Docker Desktop, and the synchronized file shares feature is available now in Docker Desktop. This enhancement brings fast and flexible host-to-VM file sharing, offering a performance boost for developers dealing with extensive codebases. Synchronized file shares overcome the limitations of traditional bind mounts, providing native file system performance, so developers can enjoy 2-10x faster file operation speeds. Simply log in to Docker Desktop with your subscription account (Docker Pro, Teams, or Business) to experience this new time-saving feature. Improving the developer experience Synchronized file shares transform the backend developer experience by increasing developer productivity with the time saved compared to traditional file-sharing systems. Synchronized file sharing is ideal for developers who: Manage large repositories or monorepos with more than 100,000 files, totaling significant storage. Utilize virtual file systems (such as VirtioFS, gRPC FUSE, or osxfs) and face scalability issues with their workflows. Encounter performance limitations and want a seamless file-sharing solution without worrying about ownership conflicts. To get started, go to Settings and navigate to the File sharing tab within the Resources section (Figure 1). You can learn more about the functionality and how to use it in our documentation. Figure 1: File sharing — shares have been created and are available for use in containers. How Docker solves the problem Using synchronized file system caches to improve bind mount performance isn’t a new idea, but this functionality has never been available to developers as an ergonomic first-party solution. With Docker’s acquisition of Mutagen, we’re now in a position to offer an easy-to-use and transparent mechanism with potentially order-of-magnitude improvements to developer workflows. Bind mounts are the mechanism that Linux uses to make files (like code, scripts, and images) available to containers. They’re what you get when you specify a host path to the -v/--volume flag in docker run or docker create commands (or a host path under volumes: in Compose). If folders are bind-mounted in read/write mode (the default), they also allow containers to write back to the host file system, which is great for getting files (like build products) out of containers. When using containers natively on Linux, for example with Docker Engine, this functionality is enabled by the Linux kernel and comes with no performance impact. When using a cross-platform solution like Docker Desktop, the necessity of virtualization means that an additional file-sharing mechanism between the host system, and the Linux VM is required to enable bind mounts. Historically, Docker has used a number of virtual file system solutions to enable this host/VM file sharing, with different solutions available based on the host platform. The most recent of these mechanisms, VirtioFS, provides an excellent out-of-the-box file-sharing solution for most developers and projects, and we’re continuing to invest in further performance improvements. These virtual file systems operate by running a file server on the host, providing files on demand via FUSE-backed file systems within the VM. Although virtual file systems work great for most cases, there are projects where additional performance is required. In cases where a project contains many thousands (or even millions) of files totaling hundreds of megabytes or gigabytes, the demanding system calls used by development tools can lead to extremely slow behavior. Your project might fall into this category even if it contains only a single file — look at the staggering tree of dependencies that modern frameworks bring into your node_modules directory, for example. Modern developer tools like compilers, dynamic language runtimes, and package managers love to traverse file systems, issuing thousands or millions of readdir(), stat(), and open()/read()/write()/close() calls. With virtual file systems, each of these system calls has to be sent across the host/VM boundary (in addition to incurring the standard round trips between kernel space and user space within the Linux VM when using the FUSE stack). Using synchronized file shares This is where synchronized file shares come into play. With synchronized file shares, developers can create ext4-backed caches of host file system locations inside the Docker Desktop VM. This means all those expensive file system calls are now handled directly by the Linux kernel on a native file system. These caches are kept in sync with the host file system using the Mutagen file synchronization engine, so the files are propagated bidirectionally with ultra-low latency. For most developers, there should be no perceptible difference in the file-sharing experience, other than improved performance! So what’s the trade-off? Well, you’ll pay to store the files twice (the originals on the host and the cache inside the VM). Given the relatively low cost of disk space, compared with the high cost of developer time, this trade-off is usually a no-brainer. To keep you in control of what gets synced, we’ve made synchronized file shares a granular, opt-in experience (we don’t want to sync your entire hard drive by default). We’ve worked hard to make this step as easy as possible — select Create share in the File sharing settings pane and choose the location you want. The opt-in nature of synchronized file shares also makes it easy to adopt either gradually or selectively — there’s no need to impose changes on your entire team. Any bind mount that can’t be provided by synchronized file shares’ caches will fall back to your default virtual file-sharing mechanism, meaning there’s no change to your existing workflows. Team members can opt-in to synchronized file shares as necessary, using the functionality as a strategic optimization for specific parts of a codebase. Conclusion We’re excited about this latest time-saving feature and what it means to you — freeing up time, increasing productivity, and enabling a focus on innovation. Docker Desktop continues investing in modernizing the developer experience, and synchronized file shares is the latest enhancement. Learn more Read the synchronized file shares documentation. Read the Docker Desktop release notes. Get the latest release of Docker Desktop. New to Docker? Get started. Have questions? The Docker community is here to help. View the full article

As an engineer in a product development team, your primary focus is innovating new services to push the organization forward. We know how frustrating it is to be blocked because of a failing Docker build or to have the team be slowed down because of an unknown performance issue in your builds. Due to the complex nature of some builds, understanding what is happening with a build can be tricky, especially if you are new to Docker and containerization. To help solve these issues, we are excited to announce the new Builds view in Docker Desktop, which provides detailed insight into your build performance and usage. Get a live view of your builds as they run, explore previous build performance, and deep dive into an error and cache issue. What is causing my build to fail? The Builds view lets you look through recent and past builds to diagnose a failure long after losing the logs in your terminal. Once you have found the troublesome build, you can explore all the runtime context of the build, including any arguments and the full Dockerfile. The UI provides you with the full build log, so you no longer need to go back and re-run the build with --progress=plain to see exactly what happened (Figure 1). Figure 1: A past Docker build’s logs showing an error in one of the steps. You can see the stack trace right next to the Dockerfile command that is causing the issues, which is useful for understanding the exact step and attributes that caused the error (Figure 2). Figure 2: A view of a Dockerfile with a stack trace under a step that failed. You can also check whether this issue has happened before or look at what changed to cause it. A jump in run time compared to the baseline can be seen by inspecting previous builds for this project and viewing what changed (Figure 3). Figure 3: The build history view showing timing information, caching information, and completion status for historic builds of the same image. What happened to the caching? We often hear about how someone in the team made a change, impacting the cache utilization. The longer such a change goes unnoticed, the harder it can be to locate what happened and when. The Builds view plots your build duration alongside cache performance. Now, it’s easy to see a spike in build times aligned with a reduction in cache utilization (Figure 4). Figure 4: Enlarged view of the build history calling out the cache hit ratio for builds of the same image. You can click on the chart or select from the build history to explore what changed before and after the degradation in performance. The Builds view keeps all the context from your builds, the Dockerfile, the logs, and all execution information (Figure 5). Figure 5: An example of a Dockerfile for a historic build of an image that lets you compare what changed over time. You can even see the commit and source information for the build and easily locate who made the change for more help in resolving the issue (Figure 6). Figure 6: The info view of a historic build of an image showing the location of the Git repository being used and the digest of the commit that was built. An easier way to manage builders Previously, users have been able to manage builders from the CLI, providing a flexible method for setting up multiple permutations of BuildKit. Although this approach is powerful, it would require many commands to fully inspect and manage all the details for your different builders. So, as part of our efforts to continuously make things easier for developers, we added a builder management screen with Docker Desktop (Figure 7). Figure 7: The builder inspection view, showing builder configuration and storage utilization. All the important information about your builders is available in an easy-to-use dashboard, accessible via the Builds view (or from settings). Now, you can quickly see your storage utilization and inspect the configuration. Figure 8: Conveniently start, stop, and switch your default builder. You can also switch your default builder and easily start and stop them (Figure 8). Now, instead of having to look up which command-line options to call, you can quickly select from the drop-down menu. Get started The new Builds view is available in the new Docker Desktop 4.26 release; upgrade and click on the new Builds tab in the Dashboard menu. We are excited about the new Builds view, but this is just the start. There are many more features in the pipeline, but we would love to hear what you think. Give Builds view a try and share your feedback on the app. We would also love to chat with you about your experience so we can make the best possible product for you. Update to Docker Desktop 4.26 to get started! Learn more Read the Builds view documentation. Upgrade to Docker Desktop 4.26. Read the Docker Desktop Release Notes. Get the latest release of Docker Desktop. Have questions? The Docker community is here to help. View the full article

We’re excited to share Docker Desktop’s latest advancements that promise to elevate your experience, enhance productivity, and increase speed. The Docker Desktop 4.25 release supports the GA of Rosetta for Linux, a feature that furthers the speed and productivity that Docker Desktop brings. We’ve also optimized the installation experience on Windows and simplified Docker Scout image analysis settings in this latest Docker Desktop release… View the full article

Today we are excited to announce the general availability of Docker Desktop for Mac [Apple Silicon], continuing to support developers in our community with their choice of local development environments. First, we want to say a big thank you to our community. The excitement you have shown about being able to run Docker Desktop on the new M1 chip has been tremendous and hugely motivating to us. Your engagement on testing builds and reporting problems has been invaluable. As soon as Apple announced the new M1 chip, you let us know on our public roadmap that this was a high priority for you, and it quickly became by far our most upvoted roadmap item ever. You also responded very positively to our previous blog posts. After the M1 machines were publicly available, those of you on our developer preview program tested some very early builds. And then as we moved into public tech previews and release candidates, many more of you joined in with testing your enormous variety of use cases, and reporting bugs. In total we have had 45,000 downloads of the various preview builds, and 140 tickets raised on our public bug tracker, not to mention countless messages on our community Slack. We know that Docker Desktop is an essential part of the development process for so many of you. We are very grateful that we have such an active and supportive community, and that you have shared both your excitement and your feedback with us. We couldn’t have gotten here without you. Thank you! Where can you get it? Download it here! Release notes can be found here! Looking for support? Did you know that you can get Premium Customer Support for Docker Desktop with a Pro or Team subscription? With this GA release, we’re now ready to officially help support you if you’re thinking about using Docker Desktop for Mac [Apple Silicon], for Mac [Intel] or for Windows. Check out our pricing page to learn more about what’s included in a Pro or Team subscription, and if it’s right for you. Have you tried multi-platform builds? Many developers are going to experience multi-platform development for the first time with the Macs powered by the M1 chip. This is one of the key areas where Docker shines. Docker has had support for multi-platform images for a long time, meaning that you can build and run both amd64(Intel) and arm64 (Apple Silicon) images on Docker Desktop today. The new Docker Desktop for Apple Silicon is no exception; you can build and run images for both x86 and ARM architectures without having to set up a complex cross-compilation development environment. Docker Hub also makes it easy to identify and share repositories that provide multi-platform images. Using docker buildx you can also easily integrate multi-platform builds into your build pipeline. Try it today. Join Us for DockerCon LIVE 2021 Join us for DockerCon LIVE 2021 on Thursday, May 27. DockerCon LIVE is a free, one day virtual event that is a unique experience for developers and development teams who are building the next generation of modern applications. If you want to learn about how to go from code to cloud fast and how to solve your development challenges, DockerCon LIVE 2021 offers engaging live content to help you build, share and run your applications. Register today at https://dockr.ly/2PSJ7vn The post Released: Docker Desktop for Mac [Apple Silicon] appeared first on Docker Blog. View the full article

Today we are pleased to announce the release of Docker Desktop 3.3. We’ve been listening to your feedback on our Public Roadmap and we are consistently asked for three things: smaller downloads, more flexible installation options, and more frequent feature releases, bug fixes, and security updates. We also heard from our community that the smaller updates are appreciated, requiring immediate installation is not convenient, and automatic background downloads are problematic for developers on constrained or metered bandwidth. We’ve heard you and are changing how updates to Docker Desktop work, while still maintaining the ability to provide you with smaller, faster updates. We are also providing additional flexibility to developers with Pro or Team subscriptions. Flexibility for Updates With Docker Desktop 3.3, when a new update to Docker Desktop is available, it will no longer be automatically downloaded and installed on your next restart. You can now choose when to start the download and installation process. To encourage developers to stay up to date, we have built in increasingly persistent reminders after an update has become available. If you use Docker Desktop at work you may need to skip a specific update. For this reason, Pro or Team subscription developers can skip notifications for a particular update when a reminder appears. Finally, developers in larger organizations, who don’t have administrative access to install updates to Docker Desktop, or are only allowed to upgrade to IT-approved versions, there is now an option in the Settings menu to opt out of notifications altogether for Docker Desktop updates if your Docker ID is part of a Team subscription. It’s your positive feedback that helps us continue to improve the Docker experience. We truly appreciate it. Please keep that feedback coming by raising tickets on our Public Roadmap. See the release notes for Docker Desktop for Mac and Docker Desktop for Windows for the complete set of changes in Docker Desktop 3.3 including the latest Compose release, update to Linux Kernel 5.10, and several other bug fixes and improvements you’ve been waiting for. And check out our Tech Preview page for the latest updates on support for Apple Silicon (there’s an RC3!). Interested in learning more about what else is included with a Pro or Team subscription in addition to more flexible update options? Check out our pricing page for a detailed breakdown. The post Changing How Updates Work with Docker Desktop 3.3 appeared first on Docker Blog. View the full article

The latest Docker Desktop release, 3.2, includes support for iTerm2 which is a terminal emulator that is highly popular with macOS fans. From the Containers/Apps Dashboard, for a running container, you can click `CLI` to open a terminal and run commands on the container. With this latest release of Docker Desktop, if you have installed iTerm2 on your Mac, the CLI option opens an iTerm2 terminal. Otherwise, it opens the Terminal app on Mac or a Command Prompt on Windows. Of note, this feature request to support additional terminals started from the Docker public roadmap. Daniel Rodriguez, one of our community members, submitted the request to the public roadmap. 180 people upvoted that request and we added it and prioritized it on our public roadmap. The public roadmap is our source of truth for community feedback on prioritizing product updates and feature enhancements. Not everything submitted to the public roadmap will end up as a delivered feature, but the support for M1 chipsets, image vulnerability scanning and audit logging – all delivered within the last year – all started as issues submitted via the roadmap. This is the easiest way for you to let us know about your pain points and what we can do to make Docker work better for your use cases. If you haven’t seen the public roadmap yet, check out the issues already submitted by others. If any of the submitted issues resonate with you, provide your comments, and/or add your vote. If you do not see an issue that you want to be addressed, go ahead and submit your own. We regularly review the new entries and the roadmap updates. If you have never done this before, please review the contributing guidelines. We have created these guidelines to make sure that we understand your needs and your use cases. Check out the public roadmap, take a look at what’s already on there and please give us your feedback! The post Desktop Support for iTerm2 – A Feature Request from the Docker Public Roadmap appeared first on Docker Blog. View the full article

Today with the release of Docker Desktop 3.0.0, we’re launching several major improvements to the way we distribute Docker Desktop. From now on we will be providing all updates as deltas from the previous version, which will reduce the size of a typical update from hundreds of MB to tens of MB. We will also download the update in the background so that all you need to do to benefit from it is to restart Docker Desktop. Finally, we are removing the Stable and Edge channels, and moving to a single release stream for all users. Changes Based on Your Feedback Many of you have given us feedback that our updates are too large, and too time consuming to download and install. Until now, we only provided complete installers, which meant that each update required downloading a file of several hundred MB. But from now on we will be providing all updates as deltas from the previous version, which will typically be only tens of MB per release. We have also heard that updates are offered at an inconvenient time, when you launch Docker Desktop or when you reboot your machine, which are times that you want to start work not spend several minutes downloading a new version. Now that updates are so small we are able to download them in the background, and only require a restart to start using the new version. At the same time, we are removing the Stable and Edge channels, and moving to a single, cumulative release stream for all users. The two channels date from the very early days of Docker Desktop and were designed to give users a choice between getting the very latest features at the cost of some instability, or a slower but more stable version. But in practice, lots of users have told us that the system was confusing and inflexible. It was hard to know when bug fixes would reach each version, making users confused why they were still seeing an issue when we said it had been fixed. Fixes arrived in Stable too slowly, but users didn’t want to switch to Edge to receive the fix they were waiting for because it meant resetting their containers and images. Furthermore, Edge meant accepting frequent, large updates from then on, which users found disruptive. Also, the two channels used parallel but separate version numbers, leading to confusion about which version was ‘later’. In summary, many users have told us that they find the two channels unfamiliar and confusing. “I don’t want to have to choose between stability and a fix for my bug, I want both” was typical of the comments we heard from our users. So going forward there will be only a single release stream that everyone will share. It will have all the latest fixes and experimental features so that everyone can benefit from them as early as possible. Updates will be cumulative so that there is no longer any confusion about which features have reached which builds. When we introduce an experimental feature, it will be available to everyone, but we will make it clear that it is experimental. Our vision is that you no longer have to choose between prompt fixes and low maintenance: from now on everyone will have the latest features and fixes, while receiving updates that are an order of magnitude smaller and are applied automatically. Join the Docker Developer Preview Program We know that many of our Edge users like to get even earlier notice of upcoming features and play with them before they’re ready for general consumption. For you, we’re today opening up our developer preview program more widely. It was previously by invitation only, but with the removal of the Edge channel, we’d like to invite anyone interested to join and get access to new features before they reach a public release. And today we have released to our preview users two exciting features that we know a lot of people have been waiting for: Docker Desktop on Apple M1 chips, and GPU support on WSL 2. To find out more about the Docker Developer Preview Program, read my colleague William Quiviger’s blog post. The Year in Desktop Innovation 2020 has been the busiest year ever for Docker Desktop, in line with our commitment at the end of last year to refocus our business on developers. During 2020, we have released: The Docker Dashboard, giving you access to your containers, applications and local and remote images in one UI; Docker Desktop for Windows 10 Home; The WSL 2 backend on Windows, giving a more native integration and vastly improved performance; docker compose for Azure Container Instances and Amazon Elastic Container Service; Partnership with Snyk on security scanning of local images and displaying the results of image scans from Docker Hub; New filesystems on both Windows and Mac; Substantial CPU improvements on Mac; Automatic, delta updates; And Docker Desktop is now fully supported. There’s lots more to come next year, but we are proud to label this release as version 3, and we invite you to download Docker Desktop 3.0.0 today and try it out! The post Docker Desktop 3.0.0: Smaller, Faster Releases appeared first on Docker Blog. View the full article

Last week, we announced that the Docker Desktop Stable release includes vulnerability scanning, the latest milestone in our container security solution that we are building with our partner Snyk. You can now run Snyk vulnerability scans directly from the Docker Desktop CLI. Combining this functionality with Docker Hub scanning functionality that we launched in October provides you with the flexibility of including vulnerability scanning along multiple points of your development inner loop, and provides better tooling for deploying secure applications. You can decide if you want to run your first scans from the Desktop CLI side, or from the Hub. Customers that have used Docker for a while tend to prefer starting from the Hub. The easiest way to jump in is to configure the Docker Hub repos to automatically trigger scanning every time that you push an image into that repo. This option is configurable for each repository, so that you can decide how to onboard these scans into your security program. (Docker Hub image is available only for Docker Pro and Team subscribers, for more information about subscriptions visit the Docker Pricing Page.) Once you enable scanning, you can view the scanning results either in the Docker Hub, or directly from the Docker Desktop app as described in this blog. From the scan results summary you can drill down to first view the more detailed data for each scan and get more detailed information about each vulnerability type. The most useful information in vulnerability data is the Snyk recommendation on how to remediate the detected vulnerability, and if a higher package version is available where the specific vulnerability has already been addressed. Detect, Then Remediate If you are viewing vulnerability data from the Docker Desktop, you can start remediating vulnerabilities, and testing remediations directly from your CLI. Triggering scans from Docker Desktop is simple – just run docker scan, and you can run iterative tests that confirm successful remediation before pushing the image back into the Hub. For new Docker users, consider running your first scans from the Desktop CLI. Docker Desktop Vulnerability Scanning CLI Cheat Sheet is a fantastic resource for getting started. The CLI Cheat Sheet starts from the basics, which are also described in the Docker Documentation page on Vulnerability scanning for Docker local images – including steps for running your first scans, description of the vulnerability information included with each scan result, and docker scan flags that help you specify the scan results that you want to view. Some of these docker scan flags are – --dependency-tree - displaying the list of all the package underlying dependencies that include the reported vulnerability --exclude base - running an image scan, without reporting vulnerabilities associated with the base layer --f - including the vulnerability data for the associated Dockerfile --json - displaying the vulnerability data in JSON format The really cool thing about this Cheat Sheet is that it shows you how to combine these flags to create a number of options for viewing your data – Show only high severity vulnerabilities from layers other than the base image: $ docker scan myapp:mytag --exclude-base \ --file path/to/Dockerfile --json | \ jq '[.vulnerabilities[] | select(.severity=="high")]' Show high severity vulnerabilities with an CVSSv3 network attack vector: $ docker scan myapp:mytag --json | \ jq '[.vulnerabilities[] | select(.severity=="high") | select(.CVSSv3 | contains("AV:N"))]' Show high severity vulnerabilities with a fix available: $ docker scan myapp:mytag --json | \ jq '[.vulnerabilities[] | select(.nearestFixedInVersion) | select(.severity=="high")]' Running the CLI scans and remediating vulnerabilities before you push your images to the Hub, reduces the number of vulnerabilities reported in the Hub scan, providing your team with a faster and more streamlined build cycle To learn more about running vulnerability scanning on Docker images, you can watch “Securing Containers Directly from Docker Desktop” session, presented during SnykCon. This is a joint presentation by Justin Cormack, Docker security lead, and Danielle Inbar, Snyk product manager, discussing what you can do to leverage this new solution in the security programs of your organization The post Combining Snyk Scans in Docker Desktop and Docker Hub to Deploy Secure Containers appeared first on Docker Blog. View the full article

About a month ago we talked about how we planned to make Docker Desktop more first class as part of our Pro and Team subscriptions. Today we are pleased to announce that with the latest release of Docker Desktop we are launching support for Docker Desktop for Pro and Team users. This means that customers on Pro plans or team members on Team plans will be able to get support outside of the community support in our Github repository, this will include installation support, issues in running Desktop and of course the existing support for Docker Hub. Along with this, we have our first Pro feature available in Docker Desktop! For Pro and Team users who have scanning enabled in Docker Hub, you will be able to see your scan results directly in the Docker Dashboard. This is the first step in releasing unique features for Pro and Team users on Docker Desktop. Along with this we are pleased to announce that in Docker Desktop 2.5 we have the GA release of the docker scan CLI powered by Snyk! To find out more about scanning images locally have a read of Marina’s blog post. For customers who want more control over their version of Desktop and don’t want to keep dismissing updates, we will be providing the ability to ‘ignore’ updates in Desktop until you choose to install the new version. Additionally, we allow for centralized deployment and management of Docker Desktop teams at scale through revised licensing terms for Docker Teams. This will allow larger deployments of Docker Desktop to be rolled out automatically rather than relying on individuals to install it on their own. We will be combining this with a new way to update Docker Desktop for all of our users, we will be moving to ‘delta’ updates. This means that the update size of Docker Desktop will reduce down from ~500mb to around ~20mb and will install faster as well. We are really excited to be able to offer some new unique features for our Pro and Team customers as well as continuing to improve Desktop for our millions of existing users. For more information on what is coming on Desktop check out our public roadmap. To get support you will need to submit a Desktop support ticket here, if you are not a Pro or Team plan member then have a look here at our offerings to get support today. To find out more about what else is included in our Pro and Team plans then have a look at our pricing page to find out more. Or to just get started with Docker Desktop download it here today to begin using Docker! The post Pro and Team Subscriptions Embrace Docker Desktop appeared first on Docker Blog. View the full article

In July we announced a new strategic partnership with Amazon to integrate the Docker experience you already know and love with Amazon Elastic Container Service (ECS) with AWS Fargate. Over the last couple of months we have worked with the community on the beta experience in Docker Desktop Edge. Today we are excited to bring this experience to our entire community in Docker Desktop stable, version 2.3.0.5. You can watch Carmen Puccio (Amazon) and myself (Docker) and view the original demo in the recording of our latest webinar here. What started off in the beta as a Docker plugin experience docker ecs has been pulled into Docker directly as a familiar docker compose flow. This is just the beginning, and we could use your input so head over to the Docker Roadmap and let us know what you want to see as part of this integration. There is no better time to try it. Grab the latest Docker Desktop Stable. Then check out my example application which will walk you through everything you need to know to deploy a Python application locally in development and then again directly to Amazon ECS in minutes not hours. Want more? Join us this Wednesday, September 16th at 10am Pacific where Jonah Jones (Amazon), Peter McKee (Docker) and myself will continue the discussion on Docker Run, our YouTube channel. For a live QA from our last webinar. We will be answering the top questions from the webinar and from the live audience. DockTalk Q&A: From Docker Straight to AWS The post ICYMI: From Docker Straight to AWS Built-in appeared first on Docker Blog. View the full article