docker 运行nodejs,如何做到自动化部署,难道只能停止容器->删除容器->删除旧镜像->打包新镜像->容器运行新镜像?
发布于 4 个月前 作者 ganshiqingyuan 1948 次浏览 来自 问答

我直接pm2 reload不香吗,,,是我手法有问题吗,,github action远程ssh 执行docker这一堆脚本

21 回复

可以pm2 reload,新镜像是因为更好进行版本管理

@cctv1005s 对啊,主要是版本管理,想的是github action执行服务器中的docker 脚本,重新pull -> install -> pm2 reload。。但是如果部署在docker中的话,这一套脚本真麻烦啊,,docker我不是太熟,,所以在想有没有更简单的脚本来实现这一需求

复用原来容器不销毁也可以,看你选择

@zy445566 如何复用原来容器呢,,原来容器中的镜像代码版本是旧的,,如何做到复用容器且更新代码重新打包呢。

@ganshiqingyuan WORKDIR设置好,写个这样的脚本就好了

docker exec  xxxx git pull
docker exec  xxxx npm install
docker exec  xxxx pm2 reload all  

但这样不可避免每次都要npm install,但是如果你打镜像,把package.json放到前一步,提前做成镜像,docker就会自动跳过npm这一步

不打镜像就没意义了,无法快速回滚止血

@zy445566 这样确实也可以,,但是总感觉怪怪的,,好像破坏了镜像原本的状态,而且镜像也没法复用,因为他里面还是原本的版本代码。。

@atian25 意思是每次还都是重新打镜像是吗,,然后定时任务删除旧的镜像这样??容器的话一直都停止删除运行新的?

镜像不删,构建阶段是打镜像的。 部署阶段其实就拉一个特点的镜像启动而已。 至于怎么平滑重启,这些 k8s 等基础设施都搞定了。

@atian25 我擦,,那一个nodejs镜像就1个g,,二十几次就给云盘干满了

@ganshiqingyuan 用 alpine 做基础镜像,小很多

@ganshiqingyuan

  1. 镜像是分层的,几个之间是会复用底层的,不会大多少吧。
  2. 基础镜像大小是可以优化的。
  3. 留几份镜像看你业务对稳定性的需求。
  4. 新发布后,线上出问题时,最快的止血方式就是回滚镜像,而不是慢吞吞的(P3 变 P1)重新打一个新的然后上线(还不一定能跑起来)

我觉得你说的整个流程上就有问题,下面是我个人见解哈,首先自动化部署流程应该是 pull code–>build docker image–> push docker image(这个都是在运维机器上做的,并且打tag), 服务器机器: pull docker image–>start docker image(如果是docker-compose 管理的话是省去停止容器的那步的) 如果出问题,立马重启老的docker image. pm2 reload是香,但是你如何保证快速的回滚?服务器机器和你的代码repo的网络是通的?这些在一些公司是不可以的,而且docker的本意是解决各个环境不兼容问题,不是说快速重启问题。。

@hyj1991 没找到centos的 alpine镜像

@luanxuechao 我的就一台机器,,,,全都打到本地,,,

@ganshiqingyuan 恩也没关系,基于各个场景吧,你现在的疑问主要是因为你杀鸡用宰牛刀,所以你觉得费事,就类比就两三个服务上不上K8S一样。能业务做大的时候,你会觉得用容器很香。

@ganshiqingyuan 看一下 https://github.com/gliderlabs/docker-alpine 文档,都是镜像,不可能嵌套的。

@i5ting 感谢狼叔指点!,,我发现我还是没理解精髓,,看来用docker打镜像的主要作用是像天猪说的快速止血了,,我这种只留一个镜像的做法确实有点杀鸡用牛刀了。。顺便问一嘴狼叔,,像数据库啥的是不是最好不要放到docker中,,,

@ganshiqingyuan 如果日常只用mysql这种,其实不必要的,以前没有容器化的时候都是这样玩的。如果经常有隔离环境构建,用docker更好。

回到顶部