上面是两种计划的简要形容。
传统部署
形式
通过配置 nginx
端口到目录的转发。
具体可查看上一篇文章
特点
须要对外开放子利用对应的端口,将编译好的利用文件放到对应的配置目录。
docker 部署
形式
首先构建主利用与子利用的 docker
镜像,通过 docker run
或者 docker-compose
的形式启动容器。
通过配置 nginx
转发规定,匹配拜访门路子利用容器端口。
假如服务器 ip
是 192.168.2.192
,主利用容器端口是 8889
,子利用容器端口是 7100
、7101
。
其中利用容器在构建镜像时是实现了 web
服务的,容器跑起来之后在服务器上是能够通过 127.0.0.1:7100
来拜访利用的。
因为前端子利用须要注册到主利用上,须要填写子利用的入口地址。
// index.js
registerMicroApps(
[
{
name: 'app1',
entry: process.env.NODE_ENV === 'production' ? '//192.168.2.192:7100' : '//localhost:7100',
container: '#subapp-viewport',
loader,
activeRule: '/app1',
},
{
name: 'app2',
entry: process.env.NODE_ENV === 'production' ? '//192.168.2.192:7101' : '//localhost:7101',
container: '#subapp-viewport',
loader,
activeRule: '/app2',
}
]
}
此时服务器须要凋谢的端口是主利用的 8889
,子利用的 7100
、7101
。
为了缩小对外开放的端口数,咱们要对 8889
端口进行 nginx
门路匹配转发。
批改子利用注册信息:
// index.js
registerMicroApps(
[
{
name: 'app1',
entry: process.env.NODE_ENV === 'production' ? '//192.168.2.192:8889/app1' : '//localhost:7100',
container: '#subapp-viewport',
loader,
activeRule: '/app1',
},
{
name: 'app2',
entry: process.env.NODE_ENV === 'production' ? '//192.168.2.192:8889/app2' : '//localhost:7101',
container: '#subapp-viewport',
loader,
activeRule: '/app2',
}
]
}
以后子利用在主利用配置的入口地址 entry
是 192.168.2.192:8889/app1
,理论通过 nginx
代理拜访的是 127.0.0.1:7100
,即理论拜访的是运行在服务器的子利用。
配置 nginx
代理规定:
# nginx.conf
http {
server {
listen 8889;
server_name 192.168.2.192;
location /app1 {
proxy_pass 127.0.0.1:7100
try_files $uri $uri/ /index.html;
}
}
server {
listen 8889;
server_name 192.168.2.192;
location /app2 {
proxy_pass 127.0.0.1:7101
try_files $uri $uri/ /index.html;
}
}
}
主利用拜访子利用流程图:
如果子利用部署在其余服务器,还需在其余服务器配置
nginx
的跨域问题
特点
拜访权限规定由 nginx
的转发配置决定,可凋谢较少端口,对外开放的端口只有主应用服务的端口。