通常，在Docker内部使用pm2是没有意义的。
PM2和Docker都是进程管理器，它们都可以执行日志转发、重新启动崩溃的工作者和许多其他操作。如果您在Docker容器中运行pm2，您将隐藏服务的潜在问题，至少如下：
1)如果使用pm2在每个容器中运行一个进程，除了增加内存消耗外，您不会获得太多好处。可以使用restart policy的纯docker进行重启。其他基于docker的环境（如ECS或Kubernetes）也可以这样做。
2)如果你运行多个进程，你将使监控更加困难。CPU/内存指标不再直接用于你的封闭环境。
3)单个PM2进程的运行状况检查请求将分布在工作进程中，这可能会隐藏不健康的目标
4)工作机崩溃被pm2隐藏了起来，你几乎不可能从你的监控系统（比如CloudWatch）中知道它们。
5)负载平衡变得更加复杂，因为您实际上将拥有多个级别的负载平衡。
在一个docker容器中运行多个进程也与docker的每个容器只运行一个进程的理念相矛盾。
我能想到的一种情况是，如果您对Docker环境的控制非常有限，那么运行pm2可能是控制工作调度的唯一选择。

更新日期：

您可能不赞成在Docker中使用pm2，但有时应用程序要求不同，您可能需要在一个Docker容器中运行两个节点应用程序，因此，如果您希望在同一容器中运行前端和后端应用程序，则在pm2工作良好的情况下，然后使用其他变通方法。
现在我们有了在前台运行docker进程的**pm2-runtime**，您的应用程序将使用pm2在前台运行，您可以期待与不使用pm2运行时相同的结果。
所以对于pm2-运行时间

• 您可以在Docker容器中运行多个节点应用程序
• 您现在可以在前台运行应用程序
• 您可以与key metrics集成
• 您可以生成自定义指标
• 与没有PM2但具有PM2的容器相同的性能具有这些优点。
• 你现在可以控制重启行为，（如果进程崩溃，pm2将自动重启，如果禁用，则容器将终止）
• 在像mount这样的开发环境中，您不需要重新启动container，只需重新启动pm2进程pm2 restart all即可，这将保存开发时间。

FROM node:alpine
RUN npm install pm2 -g
CMD ["pm2-runtime", "app.js"]

或者如果你想在一个容器中运行多节点应用程序，那么你可以处理.yml

FROM node:alpine
RUN npm install pm2 -g
CMD ["pm2-runtime", "process.yml"]

process.yml文件您还可以创建YAML格式的生态系统文件。例如：

这将允许容器运行多个已处理的节点。

apps:
  - script   : ./api.js
    name     : 'api-app'
    instances: 4
    exec_mode: cluster
  - script : ./worker.js
    name   : 'worker'
    watch  : true
    env    :
      NODE_ENV: development
    env_production:
      NODE_ENV: production

如果要使用Keymetrics运行。
Keymetrics.io 是构建在PM2之上的监控服务，允许轻松地监控和管理应用程序（日志、重启、异常监控...）。一旦您创建了一个基于Keymetrics的Bucket，您将获得一个公钥和一个私钥。

FROM node:alpine
RUN npm install pm2 -g
CMD ["pm2-runtime", "--public", "XXX", "--secret", "YYY", "process.yml"]

禁用自动重新启动：

使用此标志，如果nodejs进程由于错误或异常而被终止或停止，则容器将被终止。有时我们不自动重启进程，但我们希望重启容器。

FROM node:alpine
RUN npm install pm2 -g
CMD ["pm2-runtime","app.js","--no-autorestart"]

无pm2运行时

作为一个经验法则，每个容器只有一个进程。所以记住这一点，你在容器内使用node start server.js启动你的进程，就像你没有docker一样。如果nodejs服务器崩溃，会发生什么？在这种情况下，你的容器将被杀死。哪一个应该避免这样做。
只要nodejs服务器出现故障，您的容器就会被终止，因为主进程将出现故障，而该进程应该作为容器的主进程出现在前台。
所以最终有pm2来实现这一点。这就是你如何一起使用pm2和supervisord来实现这一点。
如果你也在寻找一个例子，这里是dockerfile和所需的配置文件.使用2 MB的阿尔卑斯山最轻量级的图像.

FROM alpine:3.7
COPY supervisord.conf /etc/supervisord.conf
#installing nodejs and supervisord
RUN apk add  --no-cache --repository http://dl-cdn.alpinelinux.org/alpine/v3.7/main/ \
    --repository http://dl-cdn.alpinelinux.org/alpine/v3.7/community/ \  
   sudo supervisor nodejs>=8 
RUN npm i pm2  -g
COPY pm2.conf  /etc/supervisord.d/pm2.conf

监督会议

[unix_http_server]
file = /tmp/supervisor.sock
chmod = 0777
chown= nobody:nogroup

[supervisord]
logfile = /tmp/supervisord.log
logfile_maxbytes = 50MB
logfile_backups=10
loglevel = info
pidfile = /tmp/supervisord.pid
nodaemon = true
umask = 022
identifier = supervisor

[supervisorctl]
serverurl = unix:///tmp/supervisor.sock

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[include]
files = /etc/supervisord.d/*.conf

pm2.conf文件

[supervisord]
    nodaemon=true
    
    [program:pm2]
    command:pm2 start pm2_processes.yml --no-daemon
    startretries:5

我想当在没有负载平衡器的情况下在单个示例上运行AWS Elastic Beanstalk时，这可能会很有用。
如果您在没有负载平衡器的情况下使用EB，并且Docker容器中出现了致命错误，那么它会退出并且EB不会重新启动它，这会给您留下一个损坏的应用，如my question on the topic中所述。通过在容器中运行pm2，您可以避免这种情况，并让容器自行重新启动。
现在的问题是，“我不能只使用pm2 * 而不使用 * Docker吗？”答案是肯定的，但是您仍然可以从Docker提供的抽象中获益，因此同时使用Docker * 和 * pm2可能是有意义的。