简要的线上环境部署概览

时间 2020-07-14

标签简要线上环境部署概览繁體版

原文原文链接

　　谈到线上环境，通常开发同窗，不太容易接触到。即便接触到，也只是其中的冰山一角！html

　　因此，其实提及线上环境的部署，我们好像都有点懂，可是又都不必定彻底懂！网上的知识无穷无尽，但每每都是各司一职，对于普通同窗，很难窥其全貌！前端

　　因此，我今天就来讲说，一些普通的线上环境的部署步骤，和一些脚本小技巧吧。只但愿经过这篇文章，可以让你们有一个运维的全局观！java

　　我将会分几条线来整理我们的运维思路！linux

1、从理论上讲，咱们应该怎么作？

1. 针对的是什么样的用户群体，体量大概会有多少？

　　这是一个部署规划的前题。为啥呢？nginx

　　1、若是你针对的是后台管理员，人数也很少，那么你可能只须要一个服务器就能够了，先后端也均可以部署在同一台服务器上；若是稍微考虑下单点故障问题，则顶多两台服务器搞定！程序员

　　2、若是针对的是前端普通用户，那么，每每就会考虑多机部署，先后端分离，单点问题，负载均衡了；至于具体要部署多少台，则要根据你的用户状况来定了，固然，前期通常不必部署不少台服务器！更多的考虑是横向扩展的能力。只要能支持横向扩展，则短时间内，每每不用担忧性能和架构问题！web

2. 为支持预估的用户量，大概须要多少的带宽？

　　有访问就会有流量产生，而预估的用户量，则是一个带宽资源需求的一个决断依据！redis

　　通常针对前期用户不太肯定的场景，能够先买个 10M 左右的共享带宽，基本可以应付；通过一段时间的观察后，再进行带宽的变动也能够；docker

　　固然，考虑带宽，天然也会存在一个公网IP的问题，由于流量是从IP进来的。shell

　　而在IP以前，则是域名的访问。域名问题则又涉及到DNS，没必要细说！

　　公网IP能够是直接指向机器的，也能够是指向负载均衡器的。若是想要支持横向扩展，则IP的指向必定是一个负载均衡器。由于只有这样，当遇到流量突增，或者作活动的时候，才能更快速的进行扩容！

3. 数据库规划如何？

　　数据在当下时代，算是重中之重了。机器没了能够再买，代码没了能够再写，可是数据没了就完蛋了！

　　数据库通常要听从几个基本原则: 1、带宽要大； 2、运算速度要快； 3、要能承受足够大的运算空间；（即：带宽足够大/cpu核数够多/内存容量够大/最大并发链接数/...）

　　因此，通常不要在数据库上省钱，能多点就多点！

　　另外，也不要什么样的数据都往数据库（关系型数据库）存，搞清楚各种型数据库的强项与弱项，作出明智的选择。不然会带来不少没必要要的麻烦！

4. 应用要基于操做系统来部署仍是基于容器来部署？

　　这是个决策性的问题！基于操做系统的部署，是一种比较传统和常见的部署方式。优势是，不少系统工具都是完善的，只要你大概知道要部署什么，部署下来通常不会有太多问题，由于这是个完整的系统。

　　可是，因为系统与系统之间可能不能彻底一致，有各类各样的差别，因此，你在这个机器上运行成功的东西，在另外的机器上则不必定能成功。所以，基于系统的部署将会使咱们的问题排查难度大大增长，并且移值性会不好。好比你在机器A上安装了10个软件，你可能配置了n个选项，可是，当你在安装B机器的时候，你并不能很好的利用原有的配置，你还得从头一个个地来！

　　所以，有另外一个部署方案，基于容器的部署（我这里是基于docker容器的部署）。docker就相似于一个个的虚拟机，可是它更加轻量级，当一个docker部署好后，你能够任意复制到其余机器上运行，看起来很诱人吧。不过，docker只是入门级容器，对于大量集群容器的管理，仍是显得力不从心，固然你很容易找到另外一个方案: Kubernetes (K8s); 你只要花上少量的时间了解下，你就能够应用了！固然了，使用容器的方案，有没有什么缺点呢？应该是有的，好比原本能够基于系统的监控方案，由于接入容器后，监控指标则不必定适用了，固然现成的方案仍是有的，不过得另外再花点时间研究了。再好比：若是容器出了问题，是否能排查出来，这也是另外一个问题！

5. 都有些什么样的基础设施或者中间件？

　　想要运行应用程序，天然是先考虑运行环境的。好比：应用须要 nginx 来作http服务器，用 tomcat 来作java web应用服务器，用redis来作缓存中间件，用zk来作应用协调中间件，用rabbitmq来作消息中间件，等等！

　　所以，要在代码跑起来以前，先要把这些环境给准备好咯。

　　准备这些中间件或基础设施以前，也要问下当下的形势，是否有高性能高可用应用需求？好比：是否须要集群部署，或者单机部署？每每集群部署又会依赖其余的中间件！也更复杂！
　　固然，这些都不是事。事儿是在出问题以后，可以有意识，可以猜想到问题发生的点！

6. 应用代码应该怎样部署？

　　当基础环境就绪后，就应该让主角上场了。应用代码怎么部署？

　　最简单的: 经过ftp上传代码到服务器上后，一个个部署！这种方案是最原始的，也是在没有办法搞更好的方案的时候使用的，不该长期使用；

　　稍微好点的: 使用集成工具(如jenkins)进行打包，而后上传一个私有yum镜像服务器（yum 源）。而后在线进行yum 安装；这种方式，借助了集成工具，几个好处:

　　　　1. 能够检测代码合法性如：单元测试、代码规范（可能须要插件）；
　　　　2. 对任何的改动有简单留档，能够备查的同时，也为代码的回滚提供了可能；
　　　　3. 减小了手动上传致使的包破坏的可能性；
　　　　4. 适合大规模应用；

　　再成熟点的: 再日后面，手动 yum 安装也已经太累了，因此急需一个部署平台，实现自动化部署；（这里的自动化部署可能就是基于CI集成部署的一种升级版）。总之，大大减少了人工参与程序，提高了效率，同时也保证了质量！固然，这种部署平台已经通过了严格的测试，出错的可能性也比较小了！

7. 服务器的安全性？

　　不考虑服务器的安全性的应用，无异于自暴自弃。黑客无处不在，不过幸亏如今系统也是愈来愈完善，只要稍加控制，即不那么容易被攻破了。可是若是放弃安全防御，则随便来一个菜鸟程序员就把你搞死了，那时的损失就大了。

　　网络安全是个很专业的领域，我不敢造次去谈它。不过咱们能够简单的作下防御: 如防火墙、受权操做、病毒库等等。固然，若是使用xx云服务，则轻松方便多了，在后台点点设置几下搞定！

8. 服务的可监控性？

　　无监控，不上线！

　　这是一个警示，若是线上服务没有监控，则全部线上的东西，都成了盲区，这对程序员GG们来讲，简直太糟糕了，虽然他们很自信！

　　监控分两个方面：一是系统级别的监控；二是应用级别的监控；(通常忽略其余监控: 如网络)

　　系统级别的监控通常能够安装第三方的软件来解决: 如 zabbix, grafana ...

　　而应用级别的监控，则须要本身拥有一套监控代码了，而这对初期项目，则每每比较吃力。固然，若是引入一些开源的解决方案也是能够的，好比 ELK, 作到分布式日志中心的做用的同时，也能够根据日志作相应的应用报错监控！然而这又涉及另外的机器费用和人力成本问题，也显得不那么简单了。

　　而若是使用xx云服务，则每每都会自带服务器监控的，能够很方便地查看到服务器状况，站在高层次预估应用是否存在潜藏的问题！

如上，就是一些我的以为的在部署一整套线上环境的时候，须要考虑的事项！从理论上讲解了下我的看法，不对之处，请赐教！

2、接下来，我将给到一些实际的操做捷径或提示？(linux)

1. 免密登陆服务器？

　　在n服务器之间跳转，若是每次都要求输入密码，那确实太烦了。尤为在密码通常还很不容易记住的状况下！

　　因此，能够将一台服务器做为跳板机，在这台服务器上，能够免密地登陆到容许的n台子服务器；

　　操做步骤有二：

# 1. 先使用 ssh-keygen 生成本机的key ssh-keygen -t rsa # 若是已生成不要重复生成 # 2. 使用 ssh-copy-id 将本机的 key 发送到须要免密登陆的服务器，首次copy时会要求输入密码，后续则免密了 ssh-copy-id -i ~/.ssh/id_rsa.pub root@172.1.2.111

2. 服务器之间文件（夹）拷贝？

　　拷贝文件的目的有不少，好比：代码同步，文件同步，资源同步，甚至是会话同步。。。

# 1. 使用scp 拷贝文件 scp /home/ol-web.war root@xxx.com:/www/tomcat/wepapps/ # 从本机拷贝到远程 scp /home/ol-web.war root@xxx.com:/www/tomcat/wepapps/ # 从远程拷贝到本机 scp -r /www/nginx/html/ root@$1.2.3.2:/www/nginx/html/ # 从本机拷贝文件夹到远程 # 2. 使用 rsync 同步文件，（可能须要安装 rsync 服务） rsync -av --delete /www/nginx/html/ root@$1.2.3.1:/www/nginx/html/        # 同步全部属性，本地删除的文件也同步远程删除

其中，scp通常是系统自带的命令，而rsync则须要自行安装服务。

scp复制你能够认为是增量复制，因此远程文件每每会愈来愈大，垃圾文件愈来愈多。

而rsync则是保持两端彻底一致，可能会符合应用场景！可是，别忘了把rsync服务加入到开机启动项中！

3. 快捷使用 ssh 等等命令，使用 tab 键进行信息补全？

　　当使用 ssh / scp 等等命令操做的时候，其操做对象每每 1.2.3.x 这样的ip显示，若是不能友好点，那确实太累了！咱们能够以下操做，以实现 ssh 也能更好的记忆：

# 在文件 /root/.bashrc 中，添加脚本以下，使自动补全添加 ssh # auto complete ... complete -W "$(echo $(grep -v '^$|#' .ssh/config | sort -u | sed 's/^ssh //'))" ssh # 在文件 /root/.ssh/config 中，添加须要自动补全的服务器， Host 172.2.3.5 server-api-01 Host 172.2.3.6 server-api-02 # 以上服务器名字须要在 /etc/hosts 文件中添加相应解析
# 而登陆 server时，只需， ssh server-api-01 便可

　　如上补全工做，无需在全部服务器上进行操做，只需在相应的跳板机上提供功能便可！

4. 简要 saltstack 搭建指南？

　　salt 是个方便易用的集群管理工具，好比你能够用于批量重启服务，全局搜索日志等等；

# 1. 安装, 仅需到相应机器上安装便可 yum install salt-master salt-minion # 2. 配置 /etc/salt/master /etc/salt/minion, 最简单的，只需修改 minion 配置，指向 master 的ip便可； #指定master，冒号后有一个空格, minion master: 172.1.2.22
    id: server-api-01 user: root # 3. 启动全部节点, status, restart systemctl start salt-master # 162机器可用 systemctl start salt-minion /etc/init.d/salt-master start # 155机器可用 /etc/init.d/salt-minion start # 4. 将全部salt-minion 添加到 master 集群管理 salt-key -A # 5. 登陆跳板机 api_01, 运行salt 操做，执行集群管理工做 salt server-api-02 cmd.run 'lsof -i:80' salt '*' test.ping

5. 简要集群复制shell脚本？

　　有时，你可能须要将你的应用发布到n台服务中，你能够直接改以下shell,也能够依赖于salt这样的高级工具进行发布！shell 参考以下：

#!/bin/bash # find out my ip to exclude... MY_MERCHINE_IP=`ifconfig eth0 |awk -F "[: ]+" '/inet addr/{print $4}'`; MERCHINE_IP_LIST="172.1.2.7 172.1.3.4"; for m_ip in $MERCHINE_IP_LIST; do
        if [[ $m_ip != $MY_MERCHINE_IP ]]; then
                echo "- Installing apps to mechine@${m_ip} ..."; # install api apps scp /www/test/hello-1.0.0-SNAPSHOT.jar root@${m_ip}:/www/test/ rsync -av --delete /www/html/ root@${m_ip}:/www/html/
                echo "- Install apps to merchine@${m_ip} done."; fi; done;

6. 简要docker搭建指南？

　　docker 做为一个容器化的基石，一出世就被追棒。包括如今的 k8s ，也是基于docker的。docker 可让你在一处搭建，到处运行，从而避免每次新买机器就要搞好久的尴尬局面；其搭建也是很简单的（简单应用）：
　　为方便任意发挥，咱们能够基于centos这种系统级别的镜像进行建立本身的image;

# docker 安装: yum install docker service docker start # 拉取 centos6 的 docker 镜像 docker pull centos:6 docker images # 构建一个 image, 建立空目录，编辑 Dockerfile vim Dockerfile # 内容可变 FROM centos:6 MAINTAINER oom <w@163.com> # move all configuration files into container # RUN yum install -y lsof # EXPOSE 80 # CMD ["sh","-c","service httpd start;bash"] # 建立镜像 docker build -t tmp_image:1.0 . # 建立并运行容器 docker run -h tmp_container -itd --name tmp_container -v /opt/docker/webapps:/www/webapp tmp_image:1.0 # 进入容器，至关于进入 centos 操做系统 docker exec -it tmp_container bash # 保存容器修改到images 　　docker commit -m 'web final.' 49d79fc19eaa tmp_image:1.2 # 备份容器修改后的docker镜像 　　docker save > /opt/images/images_final/tmp_image.final.tar tmp_image:1.2 # 恢复你的备份镜像，即全网发布 # 能够在任何装 docker 的地方加载保存的镜像 　　docker load -i /opt/images/images_final/tmp_image.final.tar

7. 定制你的登陆欢迎语？

　　因为可能存在线上环境与测试环境共存的状况，一不当心的切换错误，就可能致使不可挽回的损失。因此，若是咱们能在登陆的时候，作一个简单的提示，那么就会少一点出错的可能性。因此，订制你的登陆欢迎语吧！

# 修改登陆欢迎语 vim /etc/motd *****************************************************************
!!! WARNING:  欢迎来到线上机器: service-api-01 ，请谨慎操做哦 !!!
*****************************************************************

　　这样，用户登陆后，就会清楚的知道本身是在操做生产环境了！

8. 更方便的查看nginx的访问日志？

　　对于后端的日志而言，每每都是主动打印到某个固定位置，从而开发人员能够直接使用 tail -f xxx.log 进行日志的查看！

　　然而对于前端的代码而言，则每每没有相应的开发日志，惟一能够借助的就是 http 服务器的日志来排查问题了！

　　因此，好比使用 nginx 做为 http 服务器，那么就应该把尽量多的有用日志打印出来。那么，如何快速查看 nginx 日志，则是有必要的！好比咱们能够这样：

# vim /usr/bin/log_nginx_host , 使用 log_nginx_host 直接查看全部 nginx 日志 tail -f /var/log/nginx/access.log /var/log/nginx/error.log

如上，将会把访问日志与错误日志一块儿打印出来，从而快速定位问题！

　　。。。

原文出处：https://www.cnblogs.com/yougewe/p/10327217.html