相关疑难解决方法(0)

我以为我了解Docker.我把它理解为一种打包具有大量依赖性的软件的方法......基本上创建了一个小小的世界,绝对一切都是为一块软件而处理的.然后我在DockerHub上偶然发现了这个

https://hub.docker.com/_/busybox/

这是BusyBox的一个图像,它是一个用于嵌入式系统的小型Linux二进制文件.然后最热门的评论说

"Busybox很棒:)到目前为止整个注册表中每个字节最有用的容器."

但我完全不明白为什么这个图像存在,这让我觉得我实际上并不理解为什么Docker存在.BusyBox docker图像有什么意义？

最近，在尝试解决“大”DNS 查询（当答案大于 512M 时）时，我们在 EKS 上遇到了一些基于 Alpine 图像（节点：12.18.1-alpine）的微服务的 DNS 问题。

所以我尝试运行这个脚本来测试 DNS 解析：

var dns = require('dns');
var w3 = dns.lookup('hugedns.test.dziemba.net', function (err, addresses, family) {
  console.log(addresses);
});

每个图像有 2 个不同的场景

1. 节点：12.18.1-高山

• 在我的笔记本电脑上运行图像 - 成功解决
• 在 EKS 1.16 上运行映像 - 无法解决

2. 节点：12.18.1-slim

• 在我的笔记本电脑上运行图像 - 成功解决
• 在 EKS 1.16 上运行镜像 - 成功解决

从我看到的情况来看，Alpine 正在使用 musl（它不支持 DNS 来使用 TCP？）库而不是 glibc，因为 DNS 协议使用的是 UDP，并且仅在查询大于 512M 时才尝试回退到 TCP。所以我的理论是这是根本原因，但由于它对我有用并且在 EKS 上失败让我想知道问题在哪里可以传递......

有什么想法吗？

EKS v1.16 coredns:v1.6.6

BTW，这是我的第一篇文章，如果需要任何信息，请告诉我

我阅读了一些Docker 和 Node.js 最佳实践文章，例如https://github.com/nodejs/docker-node/blob/main/docs/BestPractices.md或使用 Docker 容器化 Node.js Web 应用程序的 10 个最佳实践，或者Node 和 NPM 的 Dockerfile 良好实践。所有这些文章至少是在 2021 年写或更新的，我不列出 2021 年之前写的文章，但也有不少。

他们都反对CMD ["npm", "run", "start"]。主要原因是 npm 会吞掉SIGTERM 和 SIGINT 等退出信号，因此我的节点应用程序中的正常关闭代码将无法运行。

我猜旧的 npm 就是这种情况（虽然我没有测试它），但我已经测试了 node14+npm6 和 node16+npm8，我可以验证 npm6/8 不会吞下这些事件和我的优雅关闭代码正在运行。不确定这是否是因为 npm 修复了它。

因此，唯一的问题仍然是还有 1 个进程 npm 需要运行，即 NPM 作为PID 1运行。一些文章说问题是“PID 1 不会响应 SIGINT”，但据我证实，情况并非如此。

许多文章（例如这个nodejs文档）建议只是，CMD [ "node", "server.js" ]但也在https://github.com/nodejs/docker-node/blob/main/docs/BestPractices.md#handling-kernel-signals …

我的目标是理解为什么会有nginx图像和nginx:alpine图像。

我知道的：

1. nginx更大，52.79 MB。
2. nginx使用debian:bullseye-slim.
3. nginx:alpine较小，为 9.51 MB。
4. nginx:alpine使用alpine.
5. 两个图像都可以很好地运行静态 htmldocker run -p 8080:80 -v ${PWD}:/usr/share/nginx/html nginx:alpine

我无法理解为什么默认图像使用debian:bullseye-slim而不是alpine.