关于microsoft:Ubuntu-2204-中的-NET-6

3次阅读

共计 9172 个字符，预计需要花费 23 分钟才能阅读完成。

.NET 6 当初蕴含在 Ubuntu 22.04 (Jammy) 中，只需 apt install dotnet6 即可装置。此更改是 Ubuntu 用户的一项重大改良和简化。咱们还公布了带有 Chiseled Ubuntu 容器的 .NET，这是 Canonical 的一个新的小型且平安的容器产品。这些改良是 Canonical 和 Microsoft 之间单干的成绩。

以下是在 Ubuntu 22.04 上装置 .NET 6 SDK 的命令：

sudo apt update
sudo apt install dotnet6

咱们还发表 .NET 6 可用于 Chiseled Ubuntu 容器。咱们在 Canonical 的敌人开发了一种新的 chisel 办法来制作超小型容器图像。咱们对此感到非常高兴。Chiseled Ubuntu 图像比您之前应用的 Ubuntu 图像小 100MB！

上面是拉取新的 ASP.NET Chiseled 图像的命令：

docker pull mcr.microsoft.com/dotnet/nightly/aspnet:6.0-jammy-chiseled

咱们还更新了 dotnetapp 和 aspnetapp 示例，以便您能够尝试应用 Chiseled Ubuntu 容器中的 .NET。

这些新的容器图像显着改善了平安态势：
超小图像（减小尺寸和攻击面）
没有包管理器（防止一整类攻打）
无外壳（防止一整类攻打）
非 root（防止一整类攻打）

最重要的是，Canonical 和 Microsoft 致力于单干以确保新的 .NET 版本与新的 Ubuntu 版本一起很好地协同工作。这包含安全更新和容器图像的平安交付。咱们非常高兴 .NET 6 在 Ubuntu 22.04 中可用，并且 Canonical 抉择与咱们单干作为其 Chiseled Ubuntu 图像的公布合作伙伴。这就是 Canonical 对该我的项目所说的。

Canonical 产品经理 Valentin Viennot 说：“Ubuntu 当初领有从开发端到生产端的故事，从 .NET 平台开始，反对超小型容器图像。”“咱们认为这对咱们两个社区来说都是一个微小的提高；与 Microsoft 的 .NET 团队单干使咱们可能超过。

几个月前，Canonical 和 Microsoft 开始单干，指标是让 Ubuntu 成为更好的.NET 开发环境。

咱们有两个次要指标：

在 Ubuntu 上应用 .NET 进行简化。
缩短 Canonical 和 Microsoft 之间的供应链。

多年来，咱们都晓得许多 .NET 开发人员应用 Ubuntu。在咱们交谈之后，很显著咱们能够做一些事件来改善这种体验。让我告诉您咱们交付了什么。

您当初能够应用由 Canonical 通过 source-build 构建的 APT 装置 .NET 6。这些软件包可用于 Ubuntu 22.04 (Jammy) 及更高版本。这是降级到 Jammy 的一个很好的理由！

留神：当初 .NET 6 已蕴含在 Ubuntu 中，请查看咱们对于在 Ubuntu 22.04 上应用 packages.microsoft.com 的倡议。

有多个包：

dotnet6 — .NET 6 SDK（简称）。
dotnet-sdk-6.0 — 同上（全称）。
aspnet-runtime-6.0 — ASP.NET Core
dotnet-runtime-6.0 — .NET Runtime

我将向您展现如何应用 Docker 装置这些图像（雷同的模型实用于其余中央）：

rich@kamloops:~$ docker run --rm -it ubuntu:jammy
root@7d4dfca0ef55:/# apt update && apt install -y dotnet6
root@7d4dfca0ef55:/# dotnet --version
6.0.108

如果这不起作用，您须要在 /etc/apt/sources.list 中注册以下源：

deb http://archive.ubuntu.com/ubuntu/ jammy-updates universe

Canonical 和 Microsoft 将单干确保这些软件包在每月的 .NET 团队公布打算中更新。这包含 Microsoft 在公开公布之前与 Canonical 共享 CVE 信息（形容和代码）。同样，Canonical 将在另一个方向共享平安信息。

留神:

咱们目前短少 Arm64 版本。这些很快就会到来。两家公司都是 Arm64 的动摇支持者。
.NET 7 版本尚不可用，并且可能要等到 .NET 7 GA 之后才会提供。
.NET SDK 工作负载在包中不可用（对于任何 Linux 发行版）。此外，Linux 不反对 .NET MAUI 工作负载。

.NET 在 Chiseled Ubuntu 容器中

您当初能够在 Chiseled Ubuntu 容器中应用 .NET。Chiseling 提供最小的容器占用空间，同时依然是您理解和信赖的 Ubuntu。它相似于传统的 distroless，带有一个为切片 .deb 包而定制的工具。

这些图像比咱们目前提供的 Ubuntu 图像小 100MB，而且不包含 root 用户！

咱们为 Arm64 和 x64 以及 .NET 6 和 7 提供三层 Chiseled Ubuntu 容器图像：

mcr.microsoft.com/dotnet/nightly/runtime-deps:6.0-jammy-chiseled

mcr.microsoft.com/dotnet/nightly/runtime:6.0-jammy-chiseled

mcr.microsoft.com/dotnet/nightly/aspnet:6.0-Jammy-chiseled

留神：图像将在咱们的 夜间 存储库中提供，而 chiseled 的产品处于预览状态。当它们在生产中失去反对时，咱们将公布另一个布告。这将是往年的某个时候，但咱们还没有抉择一个时间表，因为咱们始终专一于根本的启用。

Canonical 还通过 Docker Hub 公布实用于 .NET 的 Chiseled Ubuntu 容器图像，其中包含新的 APT 包：

https://hub.docker.com/r/ubun…
https://hub.docker.com/r/ubun…
https://hub.docker.com/r/ubun…

让咱们来看看规模性获胜。以下所有大小都是未压缩的（在磁盘上，不是注册表 / 线路大小）。
首先，runtime-deps 层。

Ubuntu 22.04 (Jammy): 112MB
Chiseled Ubuntu 22.04 (Jammy): 12.9MB

在频谱的另一端，aspnet 层。

Ubuntu 22.04 (Jammy): 213MB
Chiseled Ubuntu 22.04 (Jammy): 104MB

如许惊人的区别！Canonical 的人曾经想出了如何从这些图像中删除 100MB 的二进制文件和其余内容。当咱们第一次开始交谈时，咱们不晓得咱们会议论如此大的差别！

仔细的读者会留神到 chiseled aspnet 比现有的 runtime-deps 层小。这真是太好了。

征询 Alpine 的样子是正当的。这是一个较新的发行版，从一开始就设计为超小型和组件化。对于 runtime-deps:6.0-alpine，Alpine 为 9.84MB，对于 aspnet:6.0-alpine，为 100MB。这些是未压缩并且令人印象粗浅的数字。这是 Alpine 如此受欢迎的一个要害起因（也是咱们多年来为它公布 .NET 图像的起因）。

Alpine 很棒（咱们也是这些人的敌人），但它并不适宜所有人和每个应用程序，因为它应用 musl，一种不同（且不兼容）的 libc 变体。这仅在您的应用程序蕴含本机库时才重要。如果没有（大多数 .NET 应用程序没有），则无需放心此细节。.NET 产品自身很乐意与 musl 或 glibc 一起运行，并且每个 PR 都在 dotnet/runtime 测试上运行。

从这个角度来看，如果您应用 Ubuntu 进行开发并且始终心愿将小型 Ubuntu 投入生产，这的确是个好消息。您当初领有从开发盒到云的间接门路，没有任何发行版兼容性问题。看到 Ubuntu 与 Alpine 在同一个球场上，真是令人惊奇（也十分令人诧异）。向 Canonical 的人们致敬，感激他们在工程方面获得的巨大成就。

值得一提的是，Chainguard 正在寻找最小的容器图像，以确保将来的平安。该我的项目已用完 distroless GitHub org。咱们正在关注这个我的项目，很快乐看到人们对更小、更平安的容器图像更感兴趣。咱们置信最小 + 非 root 容器图像是将来。

就像咱们的 Alpine 图像一样，咱们抉择不包含 ICU。它可能会使图像的大小增加一倍。这意味着咱们启用了全球化不变模式。对于某些应用程序来说，这很好，而且规模上的胜利也很棒。对于其他人来说，这是一个交易破坏者。咱们可能须要依据反馈调整这部分打算。咱们曾经记录了将 ICU 增加到图像中的模式。

让我略微演示一下这些图像，以阐明这些图像是如何（无意）受到限制的。

% docker run --rm mcr.microsoft.com/dotnet/nightly/runtime-deps:6.0-jammy-chiseled-amd64
docker: Error response from daemon: No command specified.
See 'docker run --help'.

让咱们再试一次。

% docker run --rm mcr.microsoft.com/dotnet/nightly/runtime-deps:6.0-jammy-chiseled-amd64 bash
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "bash": executable file not found in $PATH: unknown.

嗯？这是怎么回事？他们不工作！这才是重点。这些是相似设施的容器图像。它们被剥离到最低限度。他们只是做你设计他们要做的事件。这就是使它们更平安的起因。如果这种体验不难受，您能够随时应用惯例的 Ubuntu 图像。咱们将持续提供它们。他们不会隐没。

对于 runtime 和 aspnet 图像，咱们决定应用 dotnet –info 作为 ENTRYPOINT，以使体验更加敌对和有用。

% docker run --rm mcr.microsoft.com/dotnet/nightly/runtime:6.0-jammy-chiseled

        global.json file:
  Not found

Host:
  Version:      6.0.8
  Architecture: arm64
  Commit:       55fb7ef977

.NET SDKs installed:
  No SDKs were found.

.NET runtimes installed:
  Microsoft.NETCore.App 6.0.8 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Download .NET:
  https://aka.ms/dotnet-download

Learn about .NET Runtimes and SDKs:
  https://aka.ms/dotnet/runtimes-sdk-info

咱们不提供 chiseled SDK 图像。因为并没有显著的强烈需要。事实上，chiseled SDK 图像在某些状况下可能很难应用。您能够持续应用现有的 Jammy SDK 图像：mcr.microsoft.com/dotnet/sdk:6.0-jammy。如果须要 chiseled SDK 图像，咱们很乐意重新考虑。

对于大多数应用程序来说，应用这些新的容器图像不会对 Dockerfile 的外观产生任何显着影响。咱们更新了咱们的示例以应用这些新的容器图像：

dotnetapp
aspnetapp

我将向您展现应用 dotnetapp 是很容易的事件。
Dockerfile 简直没有什么不同。

FROM mcr.microsoft.com/dotnet/sdk:7.0-jammy AS build
WORKDIR /source
# 复制 csproj 并复原为不同的层
COPY *.csproj .
RUN dotnet restore --use-current-runtime
# 复制和公布应用程序和库
COPY . .
RUN dotnet publish -c Release -o /app --use-current-runtime --self-contained false --no-restore
# 最初阶段 / 图像
FROM mcr.microsoft.com/dotnet/nightly/runtime:7.0-jammy-chiseled
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["dotnet", "dotnetapp.dll"]

只有最初的 FROM 语句与咱们的规范 Ubuntu Dockerfile 真正不同。

我当初将构建示例：

rich@MacBook-Air-2 dotnetapp % pwd
/Users/rich/git/dotnet-docker/samples/dotnetapp
rich@MacBook-Air-2 dotnetapp % docker build -t dotnetapp-chiseled -f Dockerfile.chiseled .
rich@MacBook-Air-2 dotnetapp % docker images | grep dotnetapp-chiseled
dotnetapp-chiseled
                 latest      bf7e125bd182   20 seconds ago   90.5MB

留神：我没有应用任何 .NET 修剪性能。当然，这个图像能够做得更小。让咱们启动容器：

rich@MacBook-Air-2 dotnetapp % docker run --rm dotnetapp-chiseled
         42
         42              ,d                             ,d
         42              42                             42 
,adPPYb,42  ,adPPYba, MM42MMM 8b,dPPYba,   ,adPPYba, MM42MMM
a8"`Y42 a8"     "8a  42    42P'   `"8a a8P_____42   42
8b       42 8b       d8  42    42       42 8PP"""""""42"8a,   ,d42 "8a,   ,a8"  42,   42       42 "8b,   ,aa   42,
 `"8bbdP"Y8  `"YbbdP"'   "Y428 42       42  `"Ybbd8"' "Y428

.NET 7.0.0-preview.7.22375.6
Linux 5.10.104-linuxkit #1 SMP PREEMPT Thu Mar 17 17:05:54 UTC 2022

OSArchitecture: Arm64
ProcessorCount: 4
TotalAvailableMemoryBytes: 3.83 GiB

而后，让咱们尝试进入：

rich@MacBook-Air-2 dotnetapp % docker run --rm --entrypoint bash dotnetapp-chiseled
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "bash": executable file not found in $PATH: unknown.
rich@MacBook-Air-2 dotnetapp % docker run --rm --entrypoint apt  dotnetapp-chiseled install -y bash curl
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "apt": executable file not found in $PATH: unknown.

我的“red team”技能让我悲观了。请留神，docker exec 将具备雷同的后果。当初我将更具体地形容 Chiseled 图像，正如您在理论中看到的那样。

Chiseled Ubuntu 容器是 Canonical 对 distroless 概念的诠释，最后由 Google 推广。在最后的实现中，散发被剥离，只装置了必要的包。Chiseling 更进一步，只在每个包中装置必要的目录和文件。

最后施行的另一个挑战是它不肯定失去任何一方的反对。Chiseled Ubuntu 容器是一流的 Canonical 可交付成绩。这意味着您能够应用超小型容器图像并作为 Canonical 客户取得反对。

感激 Google 让咱们所有人走上这条路线。

如前所述，这种办法有很多价值：

超小图像（减小尺寸和攻击面）
没有包管理器（防止一整类攻打）
无外壳（防止一整类攻打）

Chiseled Ubuntu 容器目前处于预览阶段。当它们稳固并在生产中失去反对时，咱们将另行发布公告。

咱们曾经应用非 root 用户配置了所有新的 .NET Chiseled Ubuntu 容器。这些图像不蕴含 root 用户或蕴含晋升 root 权限的命令，例如 sudo 或 su。这意味着无奈执行须要 root 的性能和操作。

除了删除像 bash 这样的 shell 之外，非 root 图像也是一种额定的平安缓解措施。非 root 图像在逻辑上是独立的，并且补充了没有 root 运行的守护程序。特权的每一次缩小都会有所帮忙。

如果您须要拜访特权资源，能够在 Dockerfile 中增加 root 用户。你不会被阻止，但这是您要做出的特定平安决定。

Chiseled 图像相似于设施，不是通用的。咱们感觉他们为咱们提供了最终交付非 root 图像的机会。这为咱们将来的政策提供了根据。相似设施的图像将作为非 root 用户交付，而通用图像将依据根本图像的策略（可能应用 root 用户配置）进行交付。然而，Canonical 的这个我的项目启发了咱们寻找一个两头选项，即提供不反对 root 的图像。

Canonical 制订了一个平安流程，可将 Ubuntu 虚拟机图像间接交付到 Azure 以供客户应用。咱们忽然想到，Canonical 能够对咱们用来构建基于 Ubuntu 的 .NET 图像（惯例和 Chiseled）的 Ubuntu 容器根底图像做同样的事件。这就是咱们当初应用的，而不是从 Docker Hub 中提取。咱们当初为所有具备已知保存 / 出处的 Canonical 资产建设了无效的零距离供应链。

咱们正在做与共享 CVE 修复相似的事件。咱们有一个共享的公有虚构单声道存储库，用于共享每月补丁。它也与 Red Hat 共享。这意味着咱们能够共同努力，以协调的形式在正确的工夫进行正确的修复。

.NET 容器图像尚未签名，但行将推出。咱们会定期努力提高咱们以平安为核心的能力。

Canonical 和 Microsoft 始终在单干，为您提供更好的体验。这包含反对。您能够在相熟的 .NET 存储库中报告问题，例如 dotnet/core 和 dotnet/runtime。如果您想要商业反对，您应该从 Canonical 反对开始。Canonical 是反对 Ubuntu 软件包的最佳场合。Canonical 可能会依据须要分割 Microsoft 以帮助解决问题。

在 Canonical 提供的 .NET 包中发现破绽的平安钻研人员依然有资格加入 Microsoft .NET Bounty Program。

Microsoft 持续在其 packages.microsoft.com 源代码中保护 Ubuntu 的 .NET 包，咱们打算在将来持续这样做。对于大多数用户，咱们倡议应用 Ubuntu Jammy+ 附带的 dotnet6 包。这就是我所做的。这与咱们为 Red Hat 用户提供的指南雷同。

留神：当初 .NET 6 已蕴含在 Ubuntu 中，请查看咱们对于在 Ubuntu 22.04 上应用 packages.microsoft.com 的倡议。

持续应用 Microsoft 软件包有两个次要起因：

您心愿应用来自 Microsoft 的 .NET 版本，而不是任何其余供应商。
Microsoft 软件包针对更高版本的 .NET SDK 性能频段（如 6.0.4xx），而源代码构建跟踪 6.0.1xx。这对 Windows 用户更相干，但对某些 Linux 用户可能很重要。

新软件包可用于 .NET 6+ 和 Ubuntu 22.04+。不反对以前的 .NET 和 Ubuntu 版本（应用新软件包）。您必须应用现有的 packages.microsoft.com 提要能力在晚期 Ubuntu 版本上应用 .NET。此外，Ubuntu 22.04 不反对晚期的 .NET 版本，因为它们不反对 OpenSSL v3。

咱们曾经发现了许多使 Canonical 更容易应用 .NET 源代码的机会。咱们将在短期内专一于这些。这些改良还将使其余从源代码构建和散发 .NET 的用户受害。

咱们最近为 .NET 设置了一个发行版保护组。Canonical 是该组的成员。咱们曾经开始在该论坛中探讨潜在的源代码构建改良。欢送其余发行版（从源代码构建 .NET）退出。无关详细信息，请分割 dotnet@microsoft.com。

Canonical 开始反对 x64 并将很快为 Arm64 增加 .NET 包。对于须要反对多种主线芯片架构的行业来说，这是一个激动人心的时刻。Ubuntu 和 .NET 在反对多种架构方面有着悠久的历史。

.NET 曾经开源 5 年多了。咱们与 Canonical 的单干在咱们 GitHub 我的项目的晚期阶段感觉是遥不可及。咱们曾经学到了很多对于如何构建 OSS 我的项目以便它成为 Linux 发行版候选者的常识。这要感激教给咱们很多货色的其余合作伙伴，尤其是 Fedora 和 Red Hat。回顾过去，很容易看出，当初开源、信赖和行业关系比咱们刚开始时更为重要。咱们很快乐也很荣幸能与 Canonical 单干。

点击这里理解更多~

正文完