小编Hie*_*roB的帖子

我正在运行 alpine 的 docker swarm 管理器节点上安装 aws-cli（Linux 0317632a4ad9 4.9.59-moby #1 SMP Thu Mar 1 20:54:00 UTC 2018 x86_64 Linux）。Alpine 的 aws-cli 包目前列在边缘分支 (1.18.55.r0) 的社区存储库中。我修改了/etc/apk/repositories为针对此 repo。

安装过程中寻找 py3-urllib3，但我解决了这个问题，最后得到了一个没有错误的全新安装，如下所示：

  ~ $ sudo apk add aws-cli@edge-comm
    fetch http://dl-cdn.alpinelinux.org/alpine/edge/community/x86_64/APKINDEX.tar.gz
    ERROR: unsatisfiable constraints:
      py3-urllib3-1.25.9-r0:
        masked in: @edge
        satisfies: py3-botocore-1.16.12-r0[py3-urllib3<1.26]

    ~ $ sudo apk add py3-urllib3@edge aws-cli@edge-comm
    (1/23) Installing groff (1.22.3-r1)
    (2/23) Installing py3-six (1.10.0-r6)
    (3/23) Installing py3-dateutil (2.6.0-r1)
    (4/23) Installing libpng (1.6.37-r0)
    (5/23) Installing freetype (2.7.1-r2)
    (6/23) Installing libjpeg-turbo (1.5.3-r2)
    (7/23) Installing lcms2 …

我打算使用 Docker 来部署 node.js 应用程序。该应用程序有几个需要 node-gyp 的依赖项。Node-gyp 根据交付平台上的编译库构建这些模块（例如 canvas、lwip、qrcode），根据我的经验，这些构建可能高度依赖于 o/s 版本和安装的库，并且它们经常破坏简单的npm 安装.

那么从 node:version构建我的 Dockerfile是正确的方法吗？到目前为止，这似乎是我发现的每个 Docker/Node 教程中显示的方法。但是如果我从一个节点镜像构建，当我部署容器时会发生什么？如何确保目标主机具有编译 node-gyp 模块所需的库？

我正在考虑的另一种方式是从 ubuntu:version构建 Dockerfile 。但我认为这意味着将 nodeJS 安装到 Ubuntu 映像中，整个事情会大得多。

有没有其他方法来处理这个问题？

我创建了一个 Web Component 类来扩展div，并用于customElements.define()定义它：

class Resize_Div extends HTMLDivElement {
  constructor(){
      super();
      this.cpos = [0,0];
      <etc.>
  }
  connectedCallback() {
    console.log( 'connected' );
  }
  <etc.>
}

customElements.define('resize-div', Resize_Div, { extends:'div'} );

如果我在 html 中测试，as <div is:'resize-div'> </div>，它工作正常。

现在我想使用 createElement 以编程方式创建一个实例，使用声明is 的选项，如下所示：

let dv = document.createElement('ul', { is: 'resize-div' })

浏览器开发者工具显示已创建，outerHTML如下：

outerHTML: "<div is="resize-div"></div>"

如文档所述，“新元素[具有]一个is属性，其值是自定义元素的标签名称。”

现在我设置 id、class 和 style，并通过以下方式将新元素附加到 DOM：

document.getElementById( parent ).appendChild( dv );

现在再看一遍：is属性被剥离，它不再充当 Web 组件：

attributes: NamedNodeMap
0: …

我有一个命名卷容器，将共享资源部署到集群中的工作节点以进行生产发布。它似乎已部署，但不会填充指定卷。

该容器的图像如下所示：

FROM alpine
RUN mkdir $HOME/node_modules
COPY ./node_modules $HOME/node_modules
VOLUME $HOME/node_modules

构建后，镜像会将当前的模块集从开发机器复制到容器中的一层中。然后，该容器作为服务部署在工作节点上，在 compose 文件中定义为：

      version: "3"
      services:
        nmod_core:
          image: nmod_core:1.0.0
          environment:
            - HOME=/root
          volumes:
            - nmod_core:$HOME/node_modules
          deploy:
            replicas: 2
            placement:
              constraints: [node.role == worker] 
            restart_policy:
              condition: on-failure
              max_attempts: 1

在部署时，docker 根据此脚本在每个工作节点上创建一个命名卷。创建命名卷意味着它在 /var/lib/docker/volumes/nmod_core/_data 处创建一个主机目录，并将容器的 node_modules 内容复制到该目录中。

容器退出，因为它没有正在进行的进程。因此，我将重新启动限制设置为 1，这样服务就不会继续尝试重新启动它。数据保留在主机目录中，因为它是一个命名卷——这就是目标——同一节点上的其他容器应该能够挂载它。

设置了私有注册表的凭据后，我通过以下方式部署堆栈：

docker stack deploy -c docker-compose.yml myapp --with-registry-auth

我看着服务被创建。当我登录到工作节点时，docker image ls显示已从注册表中提取了正确的映像。据推测，这些容器确实已运行，因为docker volume ls显示已在每个节点上创建了名为 myapp_nmod_core 的命名卷。我可以检查这些卷，它们将安装位置报告为 /var/lib/docker/volumes/myapp_nmod_core/_data。但是，该位置不存在于该节点上。

尽管如此，我可以通过以下方式将此命名卷安装到容器中：

docker run -v myapp_nmod_core:/nmod -it alpine
#/ ls /nmod …