AWS Elastic BeanStalk部署记录

Frank同志68687
536 阅读7分钟

错误1：

"During an aborted deployment, some instances may have deployed the new application version. To ensure all instances are running the same version, re-deploy the appropriate application version."

原因：就是因为新的版本部署失败了。需要看log。解决问题。如果部署失败，则还是用的老版本，因此会报错。所以，没有其他办法，就去看full log，为啥部署失败。

错误2:

如果忘记设置application 的loadblance，则也可以设置https；对应的如图， 记得保存设置。

image.png

image.png

前言

简单来讲后端部署分单机模式（monolithic）即一个server服务器，运维来部署反向代理（如ngnix）和BFF等资源；以及集群模式。

单机方式的缺点非常明显：更新配置或者部署新代码需要中断服务器，而且多个资源放到一个服务器上，对该单机的依赖非常高，万一宕机影响非常大；而且规模化也是有问题，没有办法做到自适应的扩容等。

于是著名的Kubernets（k8s）集群编排（orchestration）应运而生。所谓的编排这个英文单词的意思就是音乐指挥家，就是说这个软件的目的是协调服务器以及服务之间的资源达到统一自动化。

下面我们就简单的介绍一下k8s的几个概念。

  • 集群cluster：可以把它想象成一个 域名空间namespace，为了把一些硬件资源聚集到一起起个名字，比如几个服务器（可以是虚拟机，其实目前云服务商（阿里云，aws等）提供了也是虚拟机，比如aws叫做EC2，弹性计算，说白了就是一个虚拟计算机）；比如10台EC2可以是一个集群。
  • 节点node：可以理解成是一个虚拟计算机（EC2）
  • 容器pod：可以理解成一个docker容器（当然，pod可以包括多个docker，而且pod里面的容器不一定是用docker，只是docker比较流行）；总之可以理解成一个pod对应一个docker容器（这里理解对多少应用足够了）。
  • 镜像image：可以理解成代码的副本copy；就是把你最终的代码构建完成后，并且指定了怎么启动和使用这些代码（docker file），做了一个拷贝（一个镜像mirror）。

上面几个概念关系是什么呢？

我们从最底层网最上层来讲，从最小往最大来讲：

  • 镜像相当于一个图纸蓝本，上面说明了怎么盖房子，需要什么材料，怎么盖，图形结构是什么等；
  • docker instance实例是具体的房子，是按照蓝图（镜像）创建的新房子
  • 这个房子需要存在于一个物理空间，即你们村子的宅基地，也就是一个计算机（node）
  • 我造了好几个房子，但是需要有人来管理协调，这个管理人就是村长，即k8s；K8S来协调什么时候盖房子（比如有人结婚），什么时候拆房子（比如有人去世）。显然作为村长你也要有房子住，你的房子就是master node主节点，负责发号施令；其他人的房子是slave node从节点。
  • 你们整个村子就叫一个集群。

K8S和BeanStalk和云函数什么关系？

众所周知，k8s比较复杂，deployment部署，service服务，ip通讯等这些概念能够全部，搞定的话，还要考虑ssl证书，SLB负载均衡等等，不是一句话讲的清楚的。如果再加CICD的话，更复杂一些。所以，阿里云等服务商做了简化，比如ACK就可以帮你部署master主节点，你只需要负责从节点，这样大大降低了，操作和维护难度。

即使这样，k8s在aws上还是比较麻烦。

于是有了另外一个简化版本的k8s；叫做BeanStalk(简称BS），BS类似于Firebase，基本上提供了阉割版的k8s；可以实现自动扩容，支持cicd，支持https，支持负载均衡等。缺点是：它不太灵活，且支持的环境是固定的几个，比如Python，Node等，而且预装的版本也是固定的。

本例子，我们以node为准。

云函数相对而言是更简单的一个方式，它有自己定义的request和reponse范式，一般用来处理轻量级的，单一的，异步的功能；也对自动扩容友好。

一：部署BeanStalk？

第1步：创建application【非常重要！！！】

***血的教训，开始的时候千万不要直接选择创建env，而是要application，不然无法绑定https！！

2023-3.5日***

image.png

  • application可以理解成域名空间，group聚集多个environments（BS称为环境，其实就是部署）在一起。比如一个QA的BFF和一个PROD的BFF，一个前端部署在一个group下面。
  • 选择node 14 （最新的是16，14对我们的应用比较稳定，所以选择14）
  • 选择sample application，让aws自动部署一个示例的代码（没有必要选择upload your code上传代码，以为稍后我们选择CICD自动部署）
  • 可以terminate终结一个deployment，然后重新创建一个（可以自定义部署名称）
  • 创建之前，别忘了选择地区比如us-west-2

第2步：配置环境变量（这里的环境变量指的是node代码里面的环境变量）

image.png

  • 如果环境变量比较多的话，保存以后，可以选择save configurations，不然下次创建一个部署需要再手工输入一遍
  • 其他地方不用填

第3步：选择计算机容量

image.png

  • 为了省钱选择min=1 和max=1；因为是测试环境，一个EC2（节点，计算机）即可
  • 免费级别nano和micro不能运行nestjs，会报错限制内存不够用，因此使用small
  • 选择好后，点击** continue（不要点击apply）**因为apply会重启系统，需要很长时间

第4步：申请ssl

image.png

  • 免费选择AWS Certificate Manager的泛域名
  • 如果是在aws注册的域名，进入到ssl里面点击创建records

image.png

第5步：把api的二级域名指向服务器（即BS环境/部署）

image.png

第6步：把ssl绑定到负载均衡loadbalancer上面（重要！）

  • 回到BS设置页面
  • 添加443接口
  • 注意：这里的loadbalancer是application loadbalancer所以需要绑定到这里，而不是域名噢！！！

image.png

  • 此时http和https都可以用
  • 可以禁止http
  • 也可以把http转移到https，但是这里需要去EC2里面设置噢！（不是loadbalancer这里）
  • 为了简单，我们禁止http - 注意：开始创建的时候一定要选择application，这里的load balancer才是application 的，不然是CLB，会一堆错误，因为security group什么都不一样，无法绑定ssl成功！！

第7步：设置更新策略

假设我们有4个node，更新node时候有多个方案，有部分替换有全部替换等。如图，全部默认即可。

image.png

第8步：开通登录

image.png

  • 需要选择ssh key
  • 开通后可以登录EC2，查看log等

第9步：应用全部配置

二：部署CICD

有两个方案：

  1. 用aws的codePipeLine读取github的仓库，然后自动推送启动部署BS
  2. 用github的action以及aws cli或者BS cli (EB CLI)来自动化zip并上传到s3来重新部署BS（模拟手动upload code）

我们采用第一个方案，除非无法授权github代码库

第1步：创建pipeline

image.png

第2步：授权github给aws，选择代码库

image.png

第3步：跳过build

image.png

第4步：选择BS

image.png

三、修改代码

第1步：添加代码，解决BS没有yarn的问题

image.png

第2步：添加Procfile提供启动脚本

image.png

  • 先把TS构建成JS
  • 然后启动JS node服务
  • 然后运行migration

四、注意点

  • EB默认端口是3000
  • 可以选择不等到200代码就强制更新node（也可以选择如果500则停止更新，保留老版本）
  • api端口配置health check
  • 选择log查看错误的log （重点是web.stdout，即web log，可以打到SLS）

【完了】

avatar
文章
阅读
粉丝