Docker rolls out initial support for Apple Silicon Macs

AppleInsider

Software development specialist Docker on Thursday released a new preview build of Docker Desktop that incorporates support for Apple Silicon.

The latest preview version of Docker Desktop includes support for M1 Macs -- MacBook Air, 13-inch MacBook Pro and Mac mini -- a hotly anticipated addition for developers looking to package containers on Apple's latest hardware.

Docker's latest preview version also incorporates GPU support on WSL 2.

Docker Desktop is restricted to members of the developer preview program, which as of today is open to all comers. Previously, the program was invite only, though that restriction was lifted with today's announcement that the company's "Stable" and "Edge" software distribution channels will be combined into a single release stream.

Also announced is a change to software updates that, beginning with Docker Desktop 3.0, will be provided as small-size deltas that are downloaded in the background.

Developers have been awaiting an M1-compatible Docker release since Apple unveiled the first Apple Silicon Macs in November. The software company in a blog post last month said it was working on a solution that involved adaptations for Apple's new hypervisor framework. Docker was also waiting for Go and Electron, software on which the service relies, to make similar changes.

frantisek

I think this is very important and welcomed news for developer community and Apple Silicon platform   Very important piece of puzzle.

rayz2016

frantisek said:

I think this is very important and welcomed news for developer community and Apple Silicon platform   Very important piece of puzzle.

Yes, a very important step forward if Apple wants to stay in enterprise software development. 

abracadabra

And Docker is what exactly? A whale tracking software?

edited December 2020

beowulfschmidt

abracadabra said:

And Docker is what exactly? A whale tracking software?

Yes, by all means, mock something about which you seem to know nothing.  I'm sure you'll appear clever for having done so.

https://lmgtfy.app/?q=what+is+docker

neilm

beowulfschmidt said:

abracadabra said:

And Docker is what exactly? A whale tracking software?

Yes, by all means, mock something about which you seem to know nothing.  I'm sure you'll appear clever for having done so.

The OP was clearly not mocking Docker, but rightly calling out this article about software that most ordinary Mac users will never have heard of. AI didn't bother to explain what Docker is or why it should matter to anyone. As such it's a poorly constructed article.

zimmie

abracadabra said:

And Docker is what exactly? A whale tracking software?

To actually answer the question asked, Docker is really a couple of things. Primarily, it's a tool for packaging software meant to run on a server. The idea is to bundle the application itself together with all of the other software it depends on (like a specific version of OpenSSL) so that in this one bundle, you have everything needed to run the software with only minimal requirements from the OS it's on. When you go to deploy the software, a bundle like this makes the deployment perfectly reproducible. You don't have to deal with making sure the server has anything else already installed. The bundle just includes the correct version of all of your dependencies right there.

To a lesser extent, it is also a "container runtime" which takes the bundles produced by the first part and lets you actually run them. There's no real installation of the bundle, you just tell it to run. This part has limitations, because it runs mostly on Linux, which doesn't have a real concept of containers. On Linux, it uses a combination of namespaces and cgroups to provide a semi-private environment for the bundle to run in, but there's little to no isolation between multiple bundles running on the same system. If they want to mess with each other, they generally are able to. The runtime on Windows uses Hyper-V containers or Hyper-V hardware VMs, both of which separate things much more strictly. Given the talk about Apple's hypervisor framework, I expect the macOS runtime basically builds whole hardware VMs.

The Docker runtime is mostly important so developers can test the bundles they build.

danox

Never heard of Docker until some Geek types said that the Apple M1 cpu is worthless because it (Apple) doesn’t support it. And they wouldn’t be buying it.

cloudguy

neilm said:

beowulfschmidt said:

abracadabra said:

And Docker is what exactly? A whale tracking software?

Yes, by all means, mock something about which you seem to know nothing.  I'm sure you'll appear clever for having done so.

The OP was clearly not mocking Docker, but rightly calling out this article about software that most ordinary Mac users will never have heard of. AI didn't bother to explain what Docker is or why it should matter to anyone. As such it's a poorly constructed article.

Huh?

Software development specialist Docker ... a hotly anticipated addition for developers looking to package containers on Apple's latest hardware. I am sorry. Everything that was necessary for "most ordinary Mac users" was in the article. And I believe that there are as many or more Mac users who rely on Docker as the Adobe Premier/Lightroom, Final Cut Pro, Logic Pro or other creative community stuff that we hear endlessly about. Compare the number of software developers, QA testers, system administrators etc. to the number of people who have real content creation needs. As macOS and iOS are considered the primary platforms for content creators, the answer to this explains Apple's general 5% to 15% market share.

cloudguy

danox said:

Never heard of Docker until some Geek types said that the Apple M1 cpu is worthless because it (Apple) doesn’t support it. And they wouldn’t be buying it.

It was less a "geek type" than someone who actually needs it for their job. However, that person was just making excuses because he had to know that Docker support was on the way. A legit issue is the 16 GB RAM limit. I recently had to solve RAM issues on one of my machines by upgrading it to 32 GB. For a person doing practically anything with Docker 16 GB is the absolute minimum, and they would almost certainly prefer a device that has - or can be upgraded to - 24 or 32 GB and M1 Macs don't offer that ability right now.

However, that being said, Docker getting this out on the entry level Macs now means that when the Pro Macs that offer more memory come out next year, devs will alrready have tools like this and Python - which just released an M1 Mac version earlier this week - ready to go.

edited December 2020

marvin

zimmie said:

abracadabra said:

And Docker is what exactly? A whale tracking software?

To actually answer the question asked, Docker is really a couple of things. Primarily, it's a tool for packaging software meant to run on a server. The idea is to bundle the application itself together with all of the other software it depends on (like a specific version of OpenSSL) so that in this one bundle, you have everything needed to run the software with only minimal requirements from the OS it's on. When you go to deploy the software, a bundle like this makes the deployment perfectly reproducible. You don't have to deal with making sure the server has anything else already installed. The bundle just includes the correct version of all of your dependencies right there.

To a lesser extent, it is also a "container runtime" which takes the bundles produced by the first part and lets you actually run them. There's no real installation of the bundle, you just tell it to run. This part has limitations, because it runs mostly on Linux, which doesn't have a real concept of containers. On Linux, it uses a combination of namespaces and cgroups to provide a semi-private environment for the bundle to run in, but there's little to no isolation between multiple bundles running on the same system. If they want to mess with each other, they generally are able to. The runtime on Windows uses Hyper-V containers or Hyper-V hardware VMs, both of which separate things much more strictly. Given the talk about Apple's hypervisor framework, I expect the macOS runtime basically builds whole hardware VMs.

The Docker runtime is mostly important so developers can test the bundles they build.

I feel like there's an opportunity for a company to bring the benefit that Apple's app model had for mobile to servers. Docker improves on the standard model of installing server apps but it still requires a lot of technical capability to setup, run and maintain.

Apple (or another company) could have a server app store that has things like PHP, MySQL, Ruby, Node, Exim, Exchange, Nginx, Apache etc as apps/services and it would be a tap to install each. They'd be sandboxed from each other like iOS but could access both shared and contained data space.

The apps could be monetized by the people maintaining them and allow different versions to be installed at the same time and each could provide services to other running apps/services like an image app could be given requests for image compression from a scripted app and app devs like Pixelmator/Affinity/Adobe could provide an app/service like that.

A small business like a dental practise that wants to run an internal server without pushing everything to a cloud host could buy a Mac, install a few of these apps and it would be up and running on an internal network in no time. Easy to update, maintain and backup with no technical knowledge needed beyond using iOS.

It could clean up a lot of the messy structure under the hood in Mac OS where it ships with versions of PHP, Python etc that get outdated quite quickly and are not easily upgraded leaving people to rely on things like macports and homebrew or indivdual installers from provider websites.

It would make it easier to be able to setup and run PCI compliant servers for e-commerce and secure data. There can be encryption services for protecting database content and hosted files and easy sync services for redundancy (app profile duplication and data sync). Touch/Face ID can be used for authenticated server management vs SSH logins.

Companies could even replace apps that they've become heavily dependent on like Slack, Teams, Zoom, which send private data to the cloud and they would probably run faster on the local network, especially for video sharing.

People would be able to pay for hosting and the apps can be done as monthly fees. An app might be $0.99/month or some might choose to offer free options. If Apple offers a filesystem path translation API, a traditional unix app could address absolute paths internally without much trouble so /usr/local/whatever would be translated to AppRoot/Resources/usr/local/whatever, making it easier to port and maintain unix software.

Small development studios can setup shared git repos without using cloud services and setup office VPNs. Film studios can setup servers to handle file compression and management.

It's hard to get any footing in servers with a different OS than Linux/Windows and expensive hardware but the ARM hardware changes things a bit and the popularity of Docker (they say 11 million monthly active users) suggests there's a decent market for easier to use server software. It wouldn't have to be Apple that does it but Apple would likely do the best job of it as far as ease of use.

zimmie

Marvin said:

zimmie said:

abracadabra said:

And Docker is what exactly? A whale tracking software?

To actually answer the question asked, Docker is really a couple of things. Primarily, it's a tool for packaging software meant to run on a server. The idea is to bundle the application itself together with all of the other software it depends on (like a specific version of OpenSSL) so that in this one bundle, you have everything needed to run the software with only minimal requirements from the OS it's on. When you go to deploy the software, a bundle like this makes the deployment perfectly reproducible. You don't have to deal with making sure the server has anything else already installed. The bundle just includes the correct version of all of your dependencies right there.

To a lesser extent, it is also a "container runtime" which takes the bundles produced by the first part and lets you actually run them. There's no real installation of the bundle, you just tell it to run. This part has limitations, because it runs mostly on Linux, which doesn't have a real concept of containers. On Linux, it uses a combination of namespaces and cgroups to provide a semi-private environment for the bundle to run in, but there's little to no isolation between multiple bundles running on the same system. If they want to mess with each other, they generally are able to. The runtime on Windows uses Hyper-V containers or Hyper-V hardware VMs, both of which separate things much more strictly. Given the talk about Apple's hypervisor framework, I expect the macOS runtime basically builds whole hardware VMs.

The Docker runtime is mostly important so developers can test the bundles they build.

I feel like there's an opportunity for a company to bring the benefit that Apple's app model had for mobile to servers. Docker improves on the standard model of installing server apps but it still requires a lot of technical capability to setup, run and maintain.

Apple (or another company) could have a server app store that has things like PHP, MySQL, Ruby, Node, Exim, Exchange, Nginx, Apache etc as apps/services and it would be a tap to install each. They'd be sandboxed from each other like iOS but could access both shared and contained data space.

The apps could be monetized by the people maintaining them and allow different versions to be installed at the same time and each could provide services to other running apps/services like an image app could be given requests for image compression from a scripted app and app devs like Pixelmator/Affinity/Adobe could provide an app/service like that.

A small business like a dental practise that wants to run an internal server without pushing everything to a cloud host could buy a Mac, install a few of these apps and it would be up and running on an internal network in no time. Easy to update, maintain and backup with no technical knowledge needed beyond using iOS.

It could clean up a lot of the messy structure under the hood in Mac OS where it ships with versions of PHP, Python etc that get outdated quite quickly and are not easily upgraded leaving people to rely on things like macports and homebrew or indivdual installers from provider websites.

It would make it easier to be able to setup and run PCI compliant servers for e-commerce and secure data. There can be encryption services for protecting database content and hosted files and easy sync services for redundancy (app profile duplication and data sync). Touch/Face ID can be used for authenticated server management vs SSH logins.

Companies could even replace apps that they've become heavily dependent on like Slack, Teams, Zoom, which send private data to the cloud and they would probably run faster on the local network, especially for video sharing.

People would be able to pay for hosting and the apps can be done as monthly fees. An app might be $0.99/month or some might choose to offer free options. If Apple offers a filesystem path translation API, a traditional unix app could address absolute paths internally without much trouble so /usr/local/whatever would be translated to AppRoot/Resources/usr/local/whatever, making it easier to port and maintain unix software.

Small development studios can setup shared git repos without using cloud services and setup office VPNs. Film studios can setup servers to handle file compression and management.

It's hard to get any footing in servers with a different OS than Linux/Windows and expensive hardware but the ARM hardware changes things a bit and the popularity of Docker (they say 11 million monthly active users) suggests there's a decent market for easier to use server software. It wouldn't have to be Apple that does it but Apple would likely do the best job of it as far as ease of use.

You just described Joyent’s SmartOS. It’s a distribution of illumos (when Oracle bought Sun, they killed OpenSolaris, so the community forked OpenSolaris into illumos) specifically built as a hypervisor platform. Their management system, Triton, is also mostly open source (they have a few optional proprietary modules), and they offer a Docker API endpoint, so you can use Docker the packaging tool to deploy your bundles to a SmartOS cluster. It provides better isolation than Linux (because its isolation is based on Solaris zones), and there are prebuilt images for a lot of software.

It’s heavily image-based. Each VM is built from an image and a config file. The images are ZFS datasets. ZFS is a copy-on-write filesystem with support for snapshots, so each VM you build from the image takes up only the space of its differences from the image. It’s really slick.

Zones are around 50 times faster at I/O-heavy tasks than full hardware VMs. They support software built for Solaris in a zone, and they have Linux emulation (called “LX-branded zones”). Zones also have excellent debugging support from DTrace (it was originally a Solaris feature, after all). Other operating systems can be built in a hardware VM which runs under KVM or bhyve. Hardware VMs don’t get the same performance and debugability, but they’re no slower than other hardware VM platforms like ESX.

The config files tell the system how to build the zone. Even hardware VMs are each inside their own zone to mitigate the impact of guest escape. It specifies things like how many cores of processor time the zone is allowed to use, how much disk space it’s allowed to use, what IP addresses it should have, its DNS configuration, and so on. It also has a section for application-specific configuration, so you can use it to configure a database service in a VM without ever logging into that VM.

It’s not Mac App Store easy, but it’s about as close as a VM management platform can really be.