动态部署实施
前言
博客本地搭建好后, 就想直接在云服务器跑, 但云服务器系统的选择逼死了强迫症
centos 老牌 精简 软件源老
Ubuntu 用的人多 软件较新
二者在软件的安装方式, 安装的软件的版本非常不同, 让人心力交瘁.
两边都尝试过后, 起了使用docker心.
1 直接硬跑
选择了用的人多的 Ubuntu 作为操作系统后, git clone + npm install + hexo g 跑通博客 实现远端访问
2 docker
考虑到了云服务器的系统多样和软件安装版本问题, 开始了在docker中搭建自己的博客.
2.0 介绍
Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中, 然后发布到任何流行的 Linux 机器上
2.1 docker镜像中从头搭建环境
用docker下载Ubuntu镜像, 并在其中安装 git + nodejs, 生成ssh证书并在托管网站上添加, 下载项目, 构建, 发布
优点
避免了系统对项目的干扰
缺点
如果迁移主机
要不ssh手动依次执行一下上述命令, 这和直接重新搭建自己的主机没有本质区别 (相对不用那么繁琐的软件安装 如
node+npm)要不拷贝1个多G的镜像, 这和拷贝系统没有本质区别 (相对更小一些 更纯粹一些)
并不简单 快速
2.2 Dockerfile搭建环境
使用官方命令集 在node镜像中直接复制主机的ssh证书, 下载项目, 构建, 发布
优点
避免了手动执行命令或拷贝镜像的麻烦
可以不需要项目 仅需Dockerfile 根据证书容器自己更新
缺点
需要在镜像中安装nginx 本质还是一个大虚拟服务器 关联性太强 容器也很大
2.3 docker-compose组合node nginx
使用node镜像复制本地项目资源 node负责项目的构建发布 nginx负责反向代理
优点
仅有一个nginx容器运行 更小
项目和docker关联性强
缺点
项目的更新需要自己手动
每次重新更新需要重建镜像, 构建, 发布 很慢
2.4 docker-compose在容器更新
使用node镜像复制本地项目资源 node先构建一遍 后续每次重启都更新, 构建, 发布, nginx负责反向代理
优点
随着容器重启自动更新(从镜像创建点 相对完全更新更快) 更自动化 不用自己更新本地项目
缺点
当更改docker配置修改时自己不能主动构建镜像 会导致上述重启无意义
2.5 docker-compose关联目录 容器仅执行命令
使用node镜像关联本地项目 每次容器重启都从本地缓存中继续更新, 构建, 发布, nginx负责反向代理
优点
利用容器代理本地命令执行任务, 几乎和本地命令执行一致, 没有创建新的镜像. 非常快
缺点
会和本地文件一样 有很多中间或生成文件
尾巴
每一步都是进步 但都会出现新的问题
这些进步不是无意义的 新的问题都是影响更小的