Docker Desktop 4.26: Rosetta, PHP Init, Builds View GA, Admin Enhancements, and Docker Desktop Image for Microsoft Dev Box

We’re happy to announce the release of Docker Desktop 4.26, which delivers the latest breakthroughs in Rosetta for Docker Desktop optimization, transforming the Docker experience for all users. The new release also boosts developer productivity by solving common issues such as Node.js freezes and PHP segmentation faults and supercharges performance with speed enhancements and a new view into your Docker Desktop builds.

Read on to learn how Rosetta slashes Linux kernel build times, accelerates PHP projects, and optimizes image building on Apple silicon. Additionally, we are introducing PHP support in Docker Init and enabling administrators to manage access to Docker Desktop Beta and Experimental Features.

Upgrade to Docker Desktop 4.26 and explore these updates, which enable smoother development experiences and seamless containerization for diverse tech stacks.

Rosetta for Docker Desktop

Docker Desktop 4.26 ensures a smoother Rosetta for Docker Desktop experience:

Node.js freezing for extended periods? Fixed.

PHP encountering segmentation faults? Resolved.

Programs dependent on chroot? Also addressed.

Rosetta hangs on Sonoma 14.0? No more.

Moreover, our team has been hard at work improving Rosetta’s performance in specific scenarios. Consider, for example, building projects like PostHog for both AMD64 and Arm64. Previously clocking in at 17 minutes, it’s now achieved in less than 6 minutes. 

You will now be able to experience the power of Rosetta for Docker Desktop as it reduces Linux kernel build time from 39 minutes to 17 minutes with just 10 CPUs and QEMU. 

PHP and Composer users will discover that building Sylius Standard from scratch now takes only 6 minutes (down from 20) with Docker Desktop’s default configuration on Rosetta.

While building AMD64 images on Apple silicon with Rosetta is faster than ever, native Arm64 images remain the speediest option. Docker Hub hosts a variety of Arm64 images for your preferred language, ensuring fast performance for your projects. 

Introducing PHP support in Docker Init

We want to ensure that we continue making Docker easier for all of our users and all languages. Based on user insights, we’ve launched Docker Init (Beta) — simplifying containerization for various tech stacks. (Read “Docker Init: Initialize Dockerfiles and Compose files with a single CLI command” to learn more.)

Docker Init automatically generates Dockerfiles, Compose YAML, and `.dockerignore` files by detecting your application’s language and runtime specifics. Initially supporting Golang, Python, Node, Rust, and ASP.NET Core, Docker Init offers PHP web application support in Docker Desktop 4.26 (Figure 1).

Figure 1: Docker Init showing available languages, now including PHP.

Users can now create Dockerfiles for PHP projects, covering Apache-based web applications using Composer for managing dependencies.

Get started by ensuring you have the latest Docker Desktop version. Then, execute docker init in your project directory through the command line. Let Docker Init handle the heavy lifting, allowing you to concentrate on your core task — building outstanding applications.

Introducing Docker Desktop’s Builds view GA

For engineers focused on innovation, build issues can be a major roadblock. That’s why we’re happy to announce the general availability of the Builds view, offering detailed insights into build performance. Get live updates on your builds, analyze past performance, and troubleshoot errors and cache issues.

The Builds view simplifies troubleshooting by retaining past build data, ensuring you can diagnose failures long after losing terminal logs. Easily explore runtime context, including arguments and the complete Dockerfile. Access the full build log directly from the UI, eliminating the need to re-run builds for a detailed overview (Figure 2).

Figure 2: The build history view showing timing information, caching information, and completion status for historic builds of the same image.

Read the announcement blog post to learn more about the Builds view GA release.

Admin update: Managing access to Docker Beta and Experimental Features 

At Docker, we continuously experiment and deliver the latest features directly into the hands of our users and customers. We’re dedicated to empowering Docker administrators by offering increased control over how these innovations are introduced within their development organizations. Through the flexibility of the admin-settings.json, administrators can now fine-tune feature accessibility (Figure 3).

Figure 3: User experience after an administrator has restricted access to Beta features.

This update enables precise customization, allowing admins to align Docker’s Beta and Experimental Features with their organization’s specific requirements. Whether restricting access to individual tabs or implementing comprehensive controls across the board, this enhancement caters to diverse development practices, providing the flexibility needed to optimize the Docker experience for every user (Figure 4).

Figure 4: User experience after an administrator has restricted access to Experimental features.

Refer to the documentation for more on configuration settings management.

Develop in the cloud with Docker Desktop and Microsoft Dev Box

In addition to running Docker Desktop from the comfort of your personal computer, you can now leverage this familiar experience within the cloud with Microsoft Dev Box. In a Microsoft Ignite session and a recent blog post, developers got their first glimpse of how easy it can be to create containers in the cloud with Docker Desktop and Microsoft Dev Box.  

We invite you to navigate to the Azure Marketplace to download the public preview of the Docker Desktop-Dev Box compatible image and start developing in the cloud with a native experience. Additionally, this image can be activated with your current subscription, or you can buy a Docker Business subscription directly on Azure Marketplace.

Conclusion

Stay tuned for more groundbreaking developments and optimizations to streamline your Docker experience. Your feedback fuels our progress, and we’re committed to delivering solutions that simplify development and empower every user.

Upgrade to Docker Desktop 4.26 to explore these updates and experiment with Docker’s latest features.

Learn more

Read the Docker Desktop Release Notes.

Install the latest release of Docker Desktop.

Learn about Docker Desktop Now in Microsoft Dev Box.

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.

Quelle: https://blog.docker.com/feed/

Announcing Builds View in Docker Desktop GA

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.

Quelle: https://blog.docker.com/feed/

AWS kündigt die Null-ETL-Integration von Amazon Aurora PostgreSQL in Amazon Redshift an (öffentliche Vorversion)

Die Null-ETL-Integration von Amazon Aurora in Amazon Redshift ermöglicht Analysen und Machine Learning (ML) nahezu in Echtzeit; hierbei wird Amazon Redshift für Petabyte von Transaktionsdaten aus Aurora verwendet. Datenbankcluster der mit Amazon Aurora PostgreSQL kompatiblen Edition können jetzt (in der öffentlichen Vorversion) als Quelle für Null-ETL-Integrationen verwendet werden. Innerhalb von Sekunden, nachdem die Transaktionsdaten in Aurora geschrieben wurden, sind die Daten in Amazon Redshift verfügbar. Sie müssen keine komplexen Datenpipelines erstellen und verwalten, um ETL (Extract, Transform, Load)-Vorgänge durchzuführen.
Quelle: aws.amazon.com

AWS kündigt Vektorsuche für Amazon MemoryDB für Redis an (Vorschau)

Amazon MemoryDB für Redis unterstützt jetzt die Vektorsuche in der Vorschau. Dabei handelt es sich um eine neue Funktion, mit der Sie Vektoren speichern, indexieren und suchen können. MemoryDB ist eine Datenbank, die In-Memory-Leistung mit Multi-AZ-Zuverlässigkeit kombiniert. Mit der Vektorsuche für MemoryDB können Sie mithilfe der beliebten Open-Source-Redis-API Machine Learning (ML)- und generative KI-Anwendungen mit höchsten Leistungsanforderungen in Echtzeit entwickeln. Die Vektorsuche für MemoryDB unterstützt das Speichern von Millionen von Vektoren mit einstelligen Millisekunden-Antwortzeiten für Abfragen und Aktualisierungen sowie Zehntausenden Abfragen pro Sekunde (QPS) mit einem Recall von über 99 %. Sie können Vektoreinbettungen mithilfe von KI/ML-Services wie Amazon Bedrock und SageMaker generieren und in MemoryDB speichern.
Quelle: aws.amazon.com