咱们有一个 iOS ipa 托管平台,其性能相似 fir.im 和蒲公英的托管平台,只是性能很繁多,就是上传下载性能
为了服务稳定性,曾经拓展到多台打包机更不便,咱们应用 docker 对立治理,这里记录容器化过程
Dockerfile 文件编写
首先将网站工程代码拿到本地,放到一个 ferris_wheel 文件夹下, 这个文件夹同级目录创立 Dockerfile 文件,因为工程是 node 工程,因而镜像咱们抉择 node:latest
FROM node:latest
LABEL maintainer="lichanghong"
WORKDIR /ferriswheel
COPY ./ferris /ferriswheel
ENTRYPOINT ["npm", "start"]
docker-compose.yml 服务编写
packing_ferris:
build: ./ferris_wheel
container_name: packing_ferris
hostname: packing_ferris
user: root
volumes:
- /Users/lch/Desktop/ferris:/ferriswheel/upload:rw
restart: always
networks:
- packing_net
功能测试
间接执行docker-compose up -d
,node 不存在就会主动执行 docker pull 拉取镜像,期待拉取实现。后果拉取太慢始终失败,于是删除 docker 下载最新版本,再去阿里云来个减速,而后执行飞速胜利!
想到俩问题:
1,工程的端口用的是 3003,现有的打包机通过什么映射到 80 的
2,iOS 下载必须要用 https,这个现有性能通过什么搭建的
3,本地如何测试整个流程
定位端口映射
首先 mac 自带的 apache 并没有开启,查到 brew 装置了 nginx,通过 brew info nginx
查到配置入口/usr/local/etc/nginx/
在这个目录下找到了 nginx 配置的 443 端口映射到 3003 端口,并且域名和 ssl 证书都在这里配置
最初就是本地如何测试整个性能,先依照打包机 nginx 服务配置,在本地 docker 中的 nginx 镜像中也配置一下,而后本地跑起来看看成果,最终测试胜利!
论断
把一个 node 网站服务 docker 容器化,应用 docker-compose 一键装置治理,不仅易扩大,最次要的是易保护
文章最后发版在合伙鸭官方网站