da Agency

Microsoft announces next evolution of Azure VMware Solution

Today, I’m excited to announce the preview of the next generation of Azure VMware Solution, designed, built, and supported by Microsoft and endorsed by VMware.

With the current economic environment, many organizations face new challenges to find rapid and cost-effective solutions that enable business stability, continuity, and resiliency. The new Azure VMware Solution empowers customers to seamlessly extend or completely migrate their existing on-premises VMware applications to Azure without the cost, effort, or risk of re-architecting applications or retooling operations. This helps our customers gain cloud efficiency and enables them to innovate at their own pace with Azure services across security, data, and artificial intelligence, as well as unified management capabilities. Customers can also save money with Windows Server and SQL Server workloads running on Azure VMware by taking advantage of Azure Hybrid Benefits.

Microsoft first party service

The new Azure VMware Solution is a first party service from Microsoft. By launching a new service that is directly owned, operated, and supported by Microsoft, we can ensure greater quality, reliability, and direct access to Azure innovation for our customers while providing you with a single point of contact for all your needs. With today’s announcement and our continued collaboration with VMware, the new Azure VMware Solution lays the foundation for our customers’ success in the future.

Sanjay Poonen, Chief Operating Officer at VMware commented, “VMware and Microsoft have a long-standing partnership and a shared heritage in supporting our customers. Now more than ever it is important we come together and help them create stability and efficiency for their businesses. The new Azure VMware Solution gives customers the ability to use the same VMware foundation in Azure as they use in their private data centers. It provides a consistent operating model that can increase business agility and resiliency, reduces costs, and enable a native developer experience for all types of applications.”

These comments were echoed by Jason Zander, Executive Vice President at Microsoft, who said, “This is an amazing milestone for Microsoft and VMware to meet our customers where they are today on their cloud journey. Azure VMware Solution is a great example of how we design Azure services to support a broad range of customer workloads. Through close collaboration with the VMware team, I’m excited that customers running VMware on-premises will be able to benefit from Azure’s highly reliable infrastructure sooner.”

The new solution is built on Azure, delivering the speed, scale, and high availability of our global infrastructure. You can provision a full VMware Cloud Foundation environment on Azure and gain compute and storage elasticity as your business needs change. Azure VMware Solution is VMware Cloud Verified, giving customers confidence they're using the complete set of VMware capabilities, with consistency, performance, and interoperability for their VMware workloads.

Access to VMware technology and experiences

Azure VMware Solution allows you to leverage your existing investments, in VMWare skills and tools. Customers can maintain operational consistency as they accelerate a move to the cloud with the use of familiar VMware technology including VMWare vSphere, HCX, NSX-T, and vSAN. Additionally, the new Azure VMware Solution has an option to add VMware HCX Enterprise, which will enable customers to further simplify their migration efforts to Azure including support for bulk live migrations. HCX also enables customers running older versions of vSphere on-premises to move to newer versions of vSphere seamlessly running on Azure VMware Solution.

Seamless Azure integration

Through integration with Azure management, security, and services, Azure VMware Solution provides the opportunity for customers to continue to build cloud competencies and modernize overtime. Customers maintain the choice to use the native VMware tools and management experiences they are familiar with, and incrementally leverage Azure capabilities as required.

As we look to meet customers where they are today, we are deeply investing in support for hybrid management scenarios, and automation that can streamline the journey. We are excited to announce more about future hybrid capabilities as they relate to Azure VMware Solution, soon.

Leverage Azure Hybrid Benefit pricing for Microsoft workloads

Take advantage of Azure as the best cloud for your Microsoft workloads running in Azure VMware Solution with unmatched pricing benefits for Windows Server and SQL Server. Azure Hybrid Benefit extends to Azure VMware Solution allowing customers with software assurance to maximize the value of existing on-premises Windows Server and SQL Server license investments when migrating or extending to Azure. In addition, Azure VMware Solution customers are also eligible for three years of free Extended Security Updates on 2008 versions of Windows Server and SQL Server. The combination of these unmatched pricing benefits on Azure ensures customers can simplify cloud adoption with cost efficiencies across their VMware environments.

In addition, at general availability Reserved Instances will also be available for Azure VMware Solution customers, with one-year and three-year options on dedicated hosts.

Global availability and expansion

The Azure VMware Solution preview is initially available in US East and West Europe Azure regions. We expect the new Azure VMware Solution to be generally available in the second half of 2020 and at that time, availability will be extended across more regions. Plans on regional availability for Azure VMware Solution will be made available here as they are disclosed.

To register your interest in taking part in the Azure VMware Solution preview, please contact your Microsoft Account Representative or contact our sales team.

Learn more about Azure VMware Solution on the Azure website.
Quelle: Azure

da Agency

Docker Desktop: WSL 2 Best practices

Docker Desktop WSL 2 backend has now been available for a few months for Windows 10 insider users and Microsoft just released WSL 2 on the Release Preview channel (which means GA is very close). We and our early users have accumulated some experience working with it and are excited to share a few best practices to implement in your Linux container projects!

Docker Desktop with the WSL 2 backend can be used as before from a Windows terminal. We focused on compatibility to keep you happy with your current development workflow.

But to get the most out of Windows 10 2004 we have some recommendations for you.

Fully embrace WSL 2

The first and most important best practice we want to share, is to fully embrace WSL 2. Your project files should be stored within your WSL 2 distro of choice, you should run the docker CLI from this distro, and you should avoid accessing files stored on the Windows host as much as possible.

For backward compatibility reasons, we kept the possibility to interact with Docker from the Windows CLI, but it is not the preferred option anymore.

Running docker CLI from WSL will bring you…

Awesome mounts performance

Both your own WSL 2 distro and docker-desktop run on the same utility VM. They share the same Kernel, VFS cache etc. They just run in separate namespaces so that they have the illusion of running totally independently. Docker Desktop leverages that to handle bind mounts from a WSL 2 distro without involving any remote file sharing system. This means that when you mount your project files in a container (with docker run -v ~/my-project:/sources <…>), docker will propagate inotify events and share the same cache as your own distro to avoid reading file content from disk repeatedly.

A little warning though: if you mount files that live in the Windows file system (such as with docker run -v /mnt/c/Users/Simon/windows-project:/sources <…>), you won’t get those performance benefits, as /mnt/c is actually a mountpoint exposing Windows files through a Plan9 file share. 

Compatibility with Linux toolchains and build scripts

Most reasonably sized projects involving Linux containers come with a bunch of automation scripts. Those scripts are often developed for Linux first (because most of the time, CI/CD pipelines for those projects run on Linux), and developers running on Windows are often considered second-class citizens. They are often using less polished versions of those scripts, and have to deal with subtle behavioral differences.

By fully embracing WSL 2, Windows developers can use the exact same build and automation scripts as on Linux. This means that Windows-specific scripts don’t need to be maintained anymore. Also, that means that you won’t experience issues with different line endings between Windows and Mac/Linux users!

What about my IDE?

If you want an IDE for editing your files, you can do that even if they are hosted within your WSL 2 distro. There are 3 different ways:

Use Visual Studio Code Remote to WSL extension

If your IDE is Visual Studio Code, using Remote to WSL is the best way to continue working on your project. Visual Studio Code architecture is based on a client/server approach where pretty much everything except rendering and input processing is done in a server process, while the UI itself runs in a client process. Remote to WSL leverages that to run the whole server process within WSL while the UI runs as a classic win32 process.

That means that you get the same experience as before, but all your language services, terminals etc. run within WSL.

For more information, see Microsoft’s VS Code Remote to WSL documentation.

Point your IDE to your distro network share

WSL provides a network share for each of your running distros. For example, if I have a project in my Ubuntu distro at `~/wall-e`, I can access it from Windows Explorer (and from any Windows Process) via the special network share `wsl$Ubuntuhomesimonwall-e`. 

Run an X11 server on Windows, and run a Linux native IDE

The setup is a bit more complicated, but you always have the possibility to run an X11 server on Windows (VcXsrv, X410,…) and configure your DISPLAY environment variable such that GUI apps on Linux get rendered properly.

Use BuildKit and multi-stage builds

Docker Desktop WSL 2 backend has access to all your CPU cores. To leverage this as much as possible (and also to get access to the latest build features), you should enable BuildKit by default.

The easiest way to do that is to add the following line to your ~/.profile file:

export DOCKER_BUILDKIT=1.

This way, anytime you run docker build, it will run the build with the awesome BuildKit which is capable of running different build stages concurrently.

Use resource limits

Docker Desktop WSL 2 backend can use pretty much all CPU and memory resources on your machine. This is awesome for most cases, but there is a category of workloads where this can cause issues. Indeed, some containers (mainly databases, or caching services) tend to allocate as much memory as they can, and leave other processes (Linux or Win32) starving. Docker provides a way to impose limits in allocatable memory (as well as quotas on CPU usage) by a container. You can find documentation about it here: https://docs.docker.com/config/containers/resource_constraints/.

Reclaim cached memory

WSL 2 automatically reclaims memory when it is freed, to make it available to Windows processes. However, if the kernel decides to keep content in cache (and with Docker, it tends to happen quite a lot), the amount of memory reclaimed might not be sufficient.

To reclaim more memory, after stopping your containers, you can run echo 1 > /proc/sys/vm/drop_caches as root to drop the kernel page cache and make WSL 2 reclaim memory used by its VM.

What next

We are excited for people to use Docker Desktop with WSL 2 and hope that the tips and tricks in this article will help you get the best performance for all of your workloads. 

If you have another tip or idea you want to share with us for using Docker send us a tweet @docker or if you have feedback on our implementation then raise a ticket against our Github Repo.
The post Docker Desktop: WSL 2 Best practices appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/