TXGLJ使用netflow监控网络流量

 按各地的ISP如各大运营商是要把流量发到TXGLJ进行JK的，具体手段就是运营商的交换机上配置netflow把监控的流量采集发送到TXGLJ要求的IP上，然后TXGLJ就可以进行流量分析了。

．交换机上配置下面归纳一下实施流量监控的步骤（以 Cisco 6000 系列交换机为例） : 1 ）在 Cisco 6509 上配置 NetFlow （或其他网络设备），并输出到指定到 ossim 采集器（ lp ）的固定 UDP 端口。 2 ）采集器软件为 ossim 系统的 F10W 一 tooll 具，该软件监听 UDP 端口，接收进入的 NetFlow 数据包并存储为特定格式。 3 ）使用 Nfsen 等软件包中的工具对 NetFlow 源文件进行读取，转换成可读的 AS 1 Cll 格式，再用 ossim 内的 Perl 程序对 NetFlow 进行分析和规范格式的操作，并将读取的 NetFlow 信息存储入 Ossim 数据库中。 4 ）依据蠕虫和。。 05 攻击等异常报文的流量特征，在分析程序中预设各种触发条件，定时运行，从中发现满足这些条件的「 low 。 5 ）将分析结果在 Web 客户端中展示，或者通过


如果设奋不支持 Nettlow ，怎么对流量进行检测呢？对于这样的环境也有相应的解决方法，那就是使用 Fprobe 。利用 Fprobe 来生成 Netflow 报文，其默认格式为 VS 版本。最初「 probe 是一款在 BSO 环境下运行的软件，目前在 UNIX / Linux 平台上均可运行。它可以将 NIC 接口收到的数据转化为 Netflow 数据，并发送至 Netflow 分析端。我们可以通过部署这样一台 Ossim 服务器，将网络流量镜像至 Ossim 服务器，实现网络流量分析。 Ossim 服务器中的 Netflow 分析器，由下列三个工具组成：1 Fprobe ：从远程主机发送数据流；2 Nfsen : NetFlow 的分析图形前端；3 Nfdump : NetFlow 采集模块；有关 Ossim 结构大家可以先参看本书第 14 章，这里介绍 Netflow 分析数据包的过程。首先，在网络接口接收网络数据，然后由「 probe 程序将收集的数据按照一定规则和格式进行转换 ( Netflow 格式），再发到系统的 555 端口（查看／ etc / d efa u It / fp 「 0 be 能得知详情），再由 Nfsen 系统中的 Nfdump 程序将转换后的数据统计

华为EPON OLT开局配置

配置思路：1. 登录olt（console进去之后配地址）2.配置上联口（配vlan和起三层地址互联路由的lan口）3.epon接分光器，分光器下接光猫4.自动发现光猫、配置DBA数据和线路模板5.注册光猫6.提交保存。  在 MA5680T上配置：

 telnet到MA5680T

 >>User name:root

>>User password:admin

 MA5680T>enable

MA5680T#config    

MA5680T(config)#sysname Ueusiuee_MA5680T   //修改系统名，根据实际设备修改 

Ueusiuee_MA5680T(config)# time 2010-07-15 09:00:11  //修改系统时间

Ueusiuee_MA5680T(config)# switch language-mode   //切换中文模式

  当前语言模式已切换到本地语种

 Ueusiuee_MA5680T(config)#display board  0 //查看所有单板状态

Ueusiuee_MA5680T(config)#board confirm 0      //确认所有单板 

 BaiZiMen_MA5680T(config)#interface epon 0/1  

BaiZiMen_MA5680T(config-if-epon-0/1)#port 0 ont-auto-find enable   //开启0端口的自动发现

BaiZiMen_MA5680T(config-if-epon-0/1)#port 1 ont-auto-find enable   //开启1端口的自动发现

 BaiZiMen_MA5680T(config-if-epon-0/1)#display ont autofind  0        //查看0端口发现的onu

Ueusiuee_MA5680T(config)#vlan 39 smart          //创建网管vlan 39  类型为smart

Ueusiuee_MA5680T(config)#port vlan 39 0/18 0        //透传vlan 到上行口

Ueusiuee_MA5680T(config)# vlan 2064 to 2095 smart   //创建从vlan号2094到2095的smart类型的宽带业务vlan

Ueusiuee_MA5680T(config)# vlan 3304 smart    //创建窄带语音vlan

Ueusiuee_MA5680T(config)# port vlan 3304 0/18 0    //透传窄带语音vlan

Ueusiuee_MA5680T(config)# port vlan 2064 to 2095 0/18 0

Ueusiuee_MA5680T(config)#interface vlanif  39     

Ueusiuee_MA5680T(config-vlanif39)# ip address 192.18.33.125 255.255.255.0        //配置网管地址

Ueusiuee_MA5680T(config)#quit

Ueusiuee_MA5680T(config)#ip route-static 0.0.0.0 0.0.0.0 192.18.33.254          //配置默认路由，172.18.33.254为网关

配置DBA模板和线路模板：

BaiZiMen_MA5680T(config)#display DBA-profile all   //查看所有创建过的dba模板

BaiZiMen_MA5680T(config)#DBA-profile add profile-id 13 profile-name MA5616 type3 assure 102400  max  15360 // 创建模板id为13； 模板名为MA5616；

Assure: 保证带宽10M ；  max：最大带宽15M；

BaiZiMen_MA5680T(config)#display ont-lineprofile epon all    //查看所有创建过的线路模板

BaiZiMen_MA5680T(config)#ont-lineprofile epon profile-id 13 profile-name 5616  //创建线路模板 

BaiZiMen_MA5680T(config-epon-lineprofile-13)#llid dba-profile-id 13   //线路模板中绑定dba模板ID为13的dba模板

BaiZiMen_MA5680T(config-epon-lineprofile-13)#commit //保存模板（此处必须保存否则将丢失模板配置）

BaiZiMen_MA5680T(config-epon-lineprofile-13)#quit

注册onu

BaiZiMen_MA5680T(config)#display  ont autofind  all                       

   ————————————————————————–  

   序列号          : 1                                                         

   框/槽/端口      : 0/1/0                                                     

   ONT MAC         : 286E-D487-3BB2                                            

   密码            : 00000000000000000000000000000000                          

   生产厂商ID      : HWTC                                                       

   ONT型号         : MDU                                                       

   ONT软件版本     : V8R306C01B053                                             

   ONT硬件版本     : MA5616                                                     

   ONT自动发现时间 : 2010-12-03 16:47:51

BaiZiMen_MA5680T(config-if-epon-0/1)#display ont autofind  0    //查看0端口发现的onu

BaiZiMen_MA5680T(config-if-epon-0/1)#ont add 0 0 mac-auth  286E-D487-3BB2   snmp ont-lineprofile-id 13 desc TO:JinHaiAnQingChuanLou_MA5616   // 注册端口为0 ;onu编号为0 ;  mac地址为0018-82B3-A4D7的onu ;   管理方式为snmp;    线路模板为13 ; desc:描述此onu所处位置以及设备型号

BAIZIMEN_MA5680T(config-if-gpon-0/1)#  ont ipconfig 0 0 ip-address 172.18.39.5 mask 255.255.255.0  gateway 192.18.39.1 manage-vlan 39  //给onu   0下发ip地址

BaiZiMen_MA5680T(config-if-gpon-0/1)# quit

配置业务虚接口：

service-port  vlan 39 epon 0/1/0 ont 0 multi-service user-vlan 39 tag-transform translate   //配置管理的业务虚接口

service-port  vlan 3304 epon 0/1/0 ont 0 multi-service user-vlan 3304 tag-transform translate  //配置语音的业务虚接口

service-port  vlan 2064 epon 0/1/0 ont 0 multi-service user-vlan 2064 tag-transform translate     //配置宽带的业务虚接口

……

service-port  vlan 2095 epon 0/1/0 ont 0 multi-service user-vlan 2095 tag-transform translate     //配置宽带业务虚接口

保存数据：

Ueusiuee_MA5680T(config)#save  （必须保存，否则设备重启后数据会丢失）

此为有管理的配置，如果私人的OLT不用snmp，那就

ont add 0 0 mac-auth  286E-D487-3BB2 oam ont- lineprofile-id 10 ont-

H3C交换机配置

买了个H3C的万M交换机，先一直跑不上万M，进端口后强制 万M才能跑起来

speed 10000 强制万M，

undo speed 取消

然后，可以用qos命令对端口限速

qos apply polixcy 7400M outbound 限速下午

qos apply polixcy 7400M inbound 限速上行

undo qos apply polixcy 7400M inbound 取消限速上行

其它命令：

display cu 查看当前配置

sys 进入系统视图

shutsdown 关闭端口

undo shutsdown 开启端口

一个硬盘上双系统安装

用PE，如老毛桃，可以直接在硬盘的不同分区安装不同的WIN11，

但在启动界面会有显示两个一样的win10 pro

如果找不到启动文件又想改变启动时显示的系统名字，可以

WIN+R，输入cmd，在窗口中输入cd /，目的在于打开根目录，然后再输入bcdedit

会显示所有的启动项目，

标识符<default>和<current>分别代表默认系统和当前系统

你可以根据标识符来修改显示的系统名字，如：

bcdedit /set {default} description “aaaa – WIN10”

bcdedit /set {current} description “aaaa – WIN7”

也可下载工具easybcd来修改

什么是云原生？容器，docker-compose和k8s区别

我们先从云计算说起。在云计算普及之前，一个应用想要发布到互联网，就需要企业自己先买几台服务器，找一个IDC机房，租几个机架，把服务器放进去。接下来就是装Linux系统，部署应用。我们就假定用Java写了Web应用，怎么部署上去呢？先配置Tomcat服务器，在把编译好的war包上传到服务器，有用FTP的，安全意识高一点的会选SCP，然后配置Nginx、MySQL这些服务，最后一通调试，把应用跑起来，就算齐活。

这种物理机配合自搭网络环境、自搭Linux、自配环境的方式，有很多缺点，但最主要的问题有这么几个：

  1. 扩容和维护难，因为是物理机，需要先采购后跑机房，遇到双十一业务量猛增是来不及扩容的，用行话讲就是计算资源缺乏弹性；
  2. 安全性太差，熟悉Linux的运维工程师本来就少，精通SELinux的更是凤毛麟角，而且，系统安全性仅仅是一个方面，应用部署的权限、流程造成的安全漏洞更大；
  3. 部署流程不规范，开发、测试和运维脱节，缺少自动化测试和部署，无法快速迭代业务。

解决方案是上云。上云不能解决所有问题，但部分解决了前两个问题：

  1. 云服务商提供的是虚拟机，比起物理机，虚拟机的创建、维护、销毁比物理机简单了太多，且随时可以扩容，很大程度上解决了“弹性计算”的问题，至于弹性程度有多大，还得看应用的架构和设计水平；
  2. 和绝大多数中小企业相比，云服务商在网络和服务器安全方面要强若干个数量级。只要选择合适的官方镜像，配合防火墙规则，系统级别的安全问题大大减少，可以将重点放到应用本身的安全性上。

但是如果仅仅满足上云，把物理机换成虚拟机，把物理网换成虚拟专用网（VPC），是远远不够的。这些是计算资源和网络资源层面的简化。应用方面，如果延续旧的一套开发、测试、部署流程，做不到快速迭代。

要做到快速迭代，敏捷开发，就需要DevOps，即开发运维由一个团队负责，开发阶段，就要把部署、运维的工作考虑进去，而不是发布一个war包或者jar包后扔给运维不管了。

重开发、轻部署，直接后果就是缺少自动化发布流程。想要把部署规范化，就需要整体考虑一系列问题。

还是以Java应用为例，如果是手动部署，那么就上传war包到服务器，覆盖原有的版本，重启Tomcat，再测试。如果发现有严重问题要回滚怎么办？把老版本再传一遍，然后重启Tomcat。

手动部署，每次部署都是一次生死考验，所以最好不要安排在半夜，以免手抖敲错了命令，本来中断10分钟的服务，变成了灾备恢复，中断3天。

稍微靠谱一点的是写脚本部署，但各家写出来的脚本都有各家特色，不通用，不易维护，所以更好的方式是用成熟的部署方案，比如Ansible，把脚本标准化，比如做成蓝绿发布，把服务器分组，比如A、B两组，先把流量切到B组，升级A组服务器，有问题就回滚，没问题了，再把流量切到A组，升级B组服务器，最后，恢复正常流量，整个部署完成。

但是回滚这个事情，远没有那么简单。做过开发的同学都知道，升级新版本，一般要加配置，改配置，如果回滚到旧版本，忘了把配置改回去，那旧版本可能也不能正常工作。

上云，除了物理变虚拟，简化运维外，最重要的特点——弹性计算，一定要充分利用。

理论指导实践，实践完善理论。如果我们分析大多数基于互联网的应用，可以看到，一个应用，通常用到的资源如下：

  1. 存储资源，通常对应着一个或多个数据库，例如MySQL、Oracle、PostgreSQL等；
  2. 计算资源，以Java应用为例，就是一个或多个Web应用，跑在Tomcat，或者通过SpringBoot自带嵌入式服务器；
  3. 网关，通常是Nginx之类的服务器，对外作为统一的服务入口，对内提供反向代理；
  4. 其他支撑业务的组件，例如，为提升应用性能采用的Redis集群作为缓存，应用内部各组件通信使用的消息系统如Kafka等，以及随着业务不断扩大增加的ES集群、日志分析和处理的集群等。

上云后，云服务商通常都提供托管的数据库，以及大规模存储系统（S3），可解决存储资源问题。通过云服务商提供的负载均衡（Load Balancer），也无需自行部署Nginx等网关，免去了运维的问题。各种标准的业务组件如Redis、Kafka等，均可直接租用云服务商提供的资源。

我们重点讨论计算资源，也就是云上的虚拟机资源。对于应用来说，可以设计成有状态和无状态两种。一个应用在一台虚拟机内跑着，如果有本地文件的修改，它就是有状态的。有状态的应用既不利于扩展，也不利于部署。反过来，如果一个应用在运行期数据总是存在数据库或者缓存集群，本地文件无任何修改，它就是无状态的。

无状态的应用对应的虚拟机实际上就是不变的计算资源。这里的“不变”非常重要，它是指，一台虚拟机通过一个固定的镜像（预先内置好必要的支持环境，如JRE等）启动后，部署一个应用（对应一个war包或者jar包），该虚拟机状态就不再变化了，直接运行到销毁。

有的同学会问：如果给这台虚拟机重新部署一个新的应用版本，它的状态不就发生了变化？

确实如此。为了确保虚拟机的不变性，一旦启动后部署了某个版本，就不允许再重新部署。这样一来，对虚拟机这种计算资源来说，就具有了不变性。不变性意味着某个虚拟机上的应用版本是确定的，与之打包的配置文件是确定的，不存在今天是版本1，明天变成版本2，后天回滚到版本1的情况。

计算资源不变，能确保启动一台虚拟机，对应发布的应用版本和配置是确定的且不变的，对于运维、排错非常重要。

那么如何在保持计算资源不变的前提下发布新版本？

我们以AWS的CodeDeploy服务为例，假设一组正在运行的某应用v1集群包含3台虚拟机：

   ┌─────────────────────────────────────┐
   │                 VPC                 │
   │           ┌────────────────────────┐│
   │           │      Target Group      ││
┌──┴──┐        │┌──────┐┌──────┐┌──────┐││
│ ELB │───────▶││EC2:v1││EC2:v1││EC2:v1│││
└──┬──┘        │└──────┘└──────┘└──────┘││
   │           └────────────────────────┘│
   └─────────────────────────────────────┘

现在，我们要把应用从v1升级到v2，绝不能直接把现有的3台虚拟机的应用直接升级，而是由CodeDeploy服务启动3台新的一模一样的虚拟机，只是部署的应用是v2。现在，一共有6台虚拟机，其中3台运行v1版本，另外3台运行v2版本，但此刻负载均衡控制的网络流量仍然导向v1集群，用户感受不到任何变化：

   ┌─────────────────────────────────────┐
   │                 VPC                 │
   │           ┌────────────────────────┐│
   │           │      Target Group      ││
┌──┴──┐        │┌──────┐┌──────┐┌──────┐││
│ ELB │───────▶││EC2:v1││EC2:v1││EC2:v1│││
└──┬──┘        │└──────┘└──────┘└──────┘││
   │           └────────────────────────┘│
   │           ┌────────────────────────┐│
   │           │      Target Group      ││
   │           │┌──────┐┌──────┐┌──────┐││
   │           ││EC2:v2││EC2:v2││EC2:v2│││
   │           │└──────┘└──────┘└──────┘││
   │           └────────────────────────┘│
   └─────────────────────────────────────┘

v2集群部署成功后，做一些自动化冒烟测试和内网测试，如果有问题，直接销毁，相当于本次部署失败，但无需回滚。如果没有问题，通过负载均衡把流量从v1集群切到v2，用户可无感知地直接访问v2版本：

   ┌─────────────────────────────────────┐
   │                 VPC                 │
   │           ┌────────────────────────┐│
   │           │      Target Group      ││
┌──┴──┐        │┌──────┐┌──────┐┌──────┐││
│ ELB │───┐    ││EC2:v1││EC2:v1││EC2:v1│││
└──┬──┘   │    │└──────┘└──────┘└──────┘││
   │      │    └────────────────────────┘│
   │      │    ┌────────────────────────┐│
   │      │    │      Target Group      ││
   │      │    │┌──────┐┌──────┐┌──────┐││
   │      └───▶││EC2:v2││EC2:v2││EC2:v2│││
   │           │└──────┘└──────┘└──────┘││
   │           └────────────────────────┘│
   └─────────────────────────────────────┘

稳定一段时间（例如15分钟）后，销毁v1集群。至此，整个升级完成。

上述的蓝绿部署就是CodeDeploy的一种标准部署流程。CodeDeploy也支持灰度发布，适用于更大规模的应用。

把计算资源不可变应用到部署上，实际上是充分利用了弹性计算这个优势，短时间创建和销毁虚拟机，只有上云才能做到，并且针对云计算，把部署流程变得更加简单可靠，每天发几个版本甚至几十、几百个版本都变得可能，DevOps能落地，有点“云原生”的味道了。

说到AWS的CodeDeploy，最早我使用AWS时，对于它的计费采用Reserved Instance预付模型感到很不理解，租用一台虚拟机，按国内阿里云、腾讯云包年包月预付享折扣不是更直观吗？如果仅仅把上云变成租用虚拟机，那就完全丧失了弹性计算的优势，相当于租用了一台虚拟机在里面自己折腾。AWS的Reserved Instance计费并不绑定某一台虚拟机，而是一种规格的虚拟机。我们还是举例说明，如果我们有1台2v4G规格的虚拟机，并购买了1年的Reserved Instance，那么，我随时可以销毁这台虚拟机，并重新创建一台同样规格的新的虚拟机，Reserved Instance计费会自动匹配到新的虚拟机上，这样才能实现计算资源不变，频繁实施蓝绿部署，真正把部署变成一种云服务。最近阿里云终于推出了节省计划的付费模式，有点真正的云计算的付费味道了，但是腾讯云、华为云还停留在包年包月和按量付费这两种原始租赁模型。

讲了这么多自动化部署，实际上一个指导思想就是如何充分利用云的弹性计算资源。从充分利用云的弹性资源为出发点，设计一整套开发、部署、测试的流程，就是云原生。弹性资源利用得越充分，云原生的“浓度”就越高，就越容易实施小步快跑的快速迭代。

那么虚拟机是不是弹性最好的计算资源呢？从应用的角度看，显然容器是一种比虚拟机更具弹性，更加抽象，也更容易部署的计算资源。

容器和虚拟机相比，它实际上是一种资源隔离的进程，运行在容器中的应用比独占一个虚拟机消耗的资源更少，启动速度更快。此外，容器的镜像包含了完整的运行时环境，部署的时候，无需考虑任何额外的组件，比其他任何部署方式都简单。使用容器，开发部署流程就变成了开发，生成镜像，推送至Docker Hub或云服务商提供的Registry，直接启动容器，整个过程大大简化。

使用容器比使用CodeDeploy部署还要更加简单，因为CodeDeploy需要在虚拟机镜像中预置Agent，由于没有统一的发布标准，还需要配置CodeDeploy，告诉它去哪拉取最新版本，这又涉及到一系列权限配置。而容器作为标准的部署方案，连发布系统都以Registry对各个镜像版本进行了有效管理，所以部署非常简单。

容器作为一种弹性计算资源，也应遵循计算不变性，即不要给容器挂载可变的存储卷。一组不变的容器集群才能更容易地升级。容器的运行方式本身就遵循了不变性原则，因为通过一个镜像启动一个容器，在运行过程中，是不可能换一个镜像的。容器本身也强烈不建议应用写入数据到文件系统，因为重启后这些修改将全部丢失。

容器的启动和销毁非常容易，不过，容器的管理却并不简单。容器的管理涉及到创建、调度、弹性扩容、负载均衡、故障检测等等，Kubernetes作为事实上的容器编排标准平台，已经成为各个云服务商的标配。

如果要直接使用K8s，在云环境中首先要有一组虚拟机资源作为底层资源，然后搭建K8s环境，定义好容器编排并启动容器。云服务商几乎都提供托管的K8s服务，但直接管理K8s仍然需要非常熟悉K8s的工程师。

还有一种更简单的使用容器的方式，即完全将底层虚拟机和K8s托管给云服务商，企业客户只需关心如何部署容器，底层的K8s和虚拟机对企业不可见或者无需关心。AWS的Elastic Container和阿里云的弹性容器均为此类服务。对于中小规模的应用来说，计算资源直接使用容器，再配合云服务商提供的负载均衡，托管的数据库、消息系统、日志系统等组件服务，应该是目前最“云原生”的一种方案。

最后，我们总结一下云原生的特点：

所谓云原生，就是在上云的过程中，充分发挥云平台的弹性计算、弹性存储的优势，尽量把应用设计成适合云计算的架构，把部署设计成简单易用的流程，这样才能实现业务快速上线，快速迭代。

云原生是一个大方向，在上云的过程中，逐步改造应用架构和部署流程，从手动往自动转，逐步增加计算资源的弹性，就能把云原生一步步落地。

云原生之所以解释不清楚，是因为云原生没有确切的定义，云原生一直在发展变化之中，解释权不归某个人或组织所有。

何谓云原生？

技术的变革，一定是思想先行，云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。

Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念；2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性；到了2017年，Matt Stine在接受InfoQ采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。

2015年云原生计算基金会（CNCF）成立，CNCF掺和进来后，最初把云原生定义为包括：容器化封装+自动化管理+面向微服务；到了2018年，CNCF又更新了云原生的定义，把服务网格(Service Mesh)和声明式API给加了进来。

可见，不同的人和组织对云原生有不同的定义，相同的人和组织在不同时间点对云原生也有不同的定义，真是乱的一匹，搞得鄙人非常晕菜，我的应对很简单，选一个我最容易记住和理解的定义：DevOps+持续交付+微服务+容器。

总而言之，符合云原生架构的应用程序应该是：采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。

容器入门：Docker、Pod初探

01容器是什么？

– 容器是一种计算单元

作为一种计算单元，容器与线程、进程、虚拟机、物理机一样（如下图所示）。在连续尺度上，越往左隔离性、安全性和开销越低，越往右则越高。而容器则恰恰是介于进程和虚拟机之间的一种计算单元。

但并非所有的应用都适合选择容器，开发者可以根据自己应用的特点和需求选择最适合的计算单元。例如，你的应用是高性能、互信的，且处于同一个管理区域，那么用线程或者进程就可以满足；但如果你的应用是多租户的，并且和其他应用运行在同一个空间，那么你就需要考虑如何将这些应用安全地隔离开，使得数据不会被泄露或性能受到影响。那么这时，容器也许就是一个不错的选择了。

因为容器是一个「高度隔离的进程」，它在一般进程的隔离基础上又增加了新的隔离机制，这些隔离机制是使用Linux的内核提供的，它包括一些命名空间（Name Spaces）和CGroup。命名空间可以分为网络、存储和计算三大类。其中，最为重要的是网络命名空间。它保证了容器的网络是独立于其他容器网络的。每个容器自己看到的文件系统和其他容器的是不共享的，每个容器只能看到自己的进程ID，而进程编号也是连续的。

而说到容器与虚拟机最大的区别，刘俊辉认为，相对于虚拟机，容器最大的特征是它没有自己独立的操作系统，而是共享其宿主机上的一个操作系统；而虚拟机则运行在「一台独立的服务器上」。因此，容器相比于虚拟机的成本会小，但隔离性却有所欠缺。

– 容器是一种应用的包装形式

有过应用开发经验的人都知道，应用并不是一个单一的可执行文件，一个稍微复杂一点的应用包括多个部分，包括：代码、可执行文件、配置依赖、外部依赖（动态链接库）等。

所以在应用发行包装的时候，需要考虑目标操作系统的版本、系统架构以及它所依赖的模块等因素。否则应用安装时会改动系统的不同部分。

而容器作为一个应用的包装，它最大的特点就是实现了应用的独立和便携，容器本身包含了应用所有的依赖，这使得它可以再任意的基础设施上运行，不会因为系统版本、架构的问题，而导致各种意外。

02Docker是什么？

简单来说，Docker可以看作是一个非常成功的容器管理平台。Docker最重要的部分就是它的运行管理环境

正如上面所说，容器是一个计算单元，那么Docker的运行环境就是用来创建、管理和销毁这些计算单元的。在创建和管理这些计算单元的时候，需要用到计算单元的包装（也就是它的软件发行包），这些包装以容器镜像的方式存放在它的运行环境中，所有的容器计算单元都是通过这些镜像来创建的。

但镜像本身会有版本的发布、升级等需求，这就涉及到Docker的另一个重要组成部分DockerHub了。DockerHub有点像苹果的App Store，它是一个非常大的「容器市场」，所有常用的软件都可以在DockerHub上找到。

最后一个Docker的重要模块，就是用户界面和管理工具，它们用来向容器的运行环境发布命令或查看状态。只需要用一个Docker的命令加上一些参数，就可以实现创建、删除、查看容器的运行情况等操作。

接下来我们就来看看Docker的实际操作情况，我们会以运行一个Hello World的容器为例，讲讲Docker的使用情况。其实，只需要安装好Docker就可以尝试运行这个Hello World的容器了。

通过下面代码，我们来看看Docker做了些什么：

首先我们看到Docker在本地要去找Hello World最新版本的镜像，它发现本地并没有这个镜像后去DockerHub上把这个镜像给下载了下来。然后，这个镜像就被运行了，之后Docker后台就创建了这样一个容器。

Docker的出现，让容器应用管理变得非常轻松，运行容器只需要一个命令就可以实现。而从DockerHub上下载镜像、创建各种各样的隔离环境、创建容器与外部的网络通信环境都可以由Docker来完成。可以说Docker可以管理容器的整个生命周期。

Pod，一种增强型容器

Pod是一种组合的多容器运行单元，也是Kubernetes里的一个基础单元。你可以把它看作是一种容器的扩展或者增强型的容器。Pod里面包括一个主容器和数个辅助容器，它们共同完成一个特定的功能。把多个进程（容器也是一种隔离的进程）打包在一个Name Space里的时候，就构成了一个Pod。Pod里面不同进程的应用包装仍然是独立的（每个容器都会有自己的镜像）。

Pod的意义在于，它可以既保持主容器和辅助容器的的密切关系，又保持主容器的独立性。由于主容器和辅助容器的生命周期相同，可以同时被创建和销毁，因此把它们放在一个Pod中，可以使他们的交互更加高效。

而另一方面，主容器需要完成一些主要的工作，而另一些工作可能是有共性的，就可以单独打包由辅助容器来运行。

在K8S里，编排调度的最小单位并不是容器，而是Pod。有了Docker容器，为什么还需要一个Pod? 前面我们说Docker容器就好比云计算操作系统中的应用，K8S相当于操作系统，那Pod就是进程组：即Pod是对一组容器（一个或多个）的抽象。之所以做这样一层抽象，是因为在 Borg 项目的开发和实践过程中，Google 公司的工程师们发现，他们部署的应用，往往都存在着类似于“进程和进程组”的关系。在同一个Pod中，可以直接通过localhost通信，并且可以共享网络栈和Volume

非常推荐大家去一个叫Katacoda的网站，它上面有大量免费的在线实验，包括Docker及Docker Image等动手操作项目，而且现在是完全免费的。大家不妨去这里动手实操起来。

docker-compose

Dockerfile可以让用户管理一个单独的应用容器，而compose则允许用户在一个模板（yaml格式）中定义一组相关联的应用容器（被称为一个project，即项目）
例如一个web服务再加上后端的数据库服务容器等

为什么要使用docker-compose
使用一个Dockerfile模板文件，可以让用户很方便的定义一个单独应用容器。在工作中，经常会碰到需要多个容器相互配合来完成某项任务的情况，例如要实现一个web项目，除了web服务容器本身，往往还需要再加上后端的数据库服务容器，甚至还包括负载均衡容器等。
compose允许用户通过一个单独docker-compose.yml模板文件（YAML格式）来定义一组相关联的应用容器为一个项目（project）

docker-compose项目由python编写，调用docker服务提供的API来对容器进行管理，因此， 只要所操作的平台支持docker-API，就可以在其上利用conpose来进行编排管理。
简单来说：就是来管理多个容器的，定义启动顺序的，合理编排，方便管理。

docker-compose和k8s的区别

Docker Compose是一个基于Docker的单主机容器编排工具.适合开发、测试和暂存环境

而k8s是一个跨主机的集群部署工具,是大型生产级部署的更好选择

网络排查工具MTR

常用的 ping，tracert，nslookup 一般用来判断主机的网络连通性，其实 Linux 下有一个更好用的网络联通性判断工具，它可以结合ping nslookup tracert 来判断网络的相关特性，这个命令就是 mtr。mtr 全称 my traceroute，是一个把 ping 和 traceroute 合并到一个程序的网络诊断工具。

traceroute默认使用UDP数据包探测，而mtr默认使用ICMP报文探测，ICMP在某些路由节点的优先级要比其他数据包低，所以测试得到的数据可能低于实际情况, 参数 -U 使用UDP数据包探测 。

安装方法

1.Windows系统可以直接在https://cdn.ipip.net/17mon/besttrace.exe下载BestTrace工具并安装。也可以在https://github.com/oott123/WinMTR/releases GitHub上下载MTR专用工具，该工具为免安装，下载后可以直接使用。

2.Linux可以直接运行命令进行安装。

1.# Debian/Ubuntu 系统
2.apt install mtr
3.
4.# RedHat/CentOS 系统
5.yum install mtr

3.Apple客户端可以在App store搜索Best NetTools下载安装

4.Android客户端：可以在Google Play上下载TracePing，但是由于国内Google Play无法访问，笔者自行下载下来，可以直接访问 https://dwz.cn/KCdNPH4c 下载TracePing。

使用

MTR使用非常简单，查看本机到 http://qq.com 的路由以及连接情况直接运行如下命令：

1.mtr qq.com

MTR http://qq.com 测试界面

具体输出的参数含义为：

  • 第一列是IP地址
  • 丢包率：Loss
  • 已发送的包数：Snt
  • 最后一个包的延时：Last
  • 平均延时：Avg
  • 最低延时：Best
  • 最差延时：Wrst
  • 方差（稳定性）：StDev

参数说明

-r or –report

使用 mtr -r http://qq.com 来打印报告，如果不使用 -r or –report 参数 mtr 会不断动态运行。使用 report 选项， mtr 会向 http://qq.com 主机发送 10 个 ICMP 包，然后直接输出结果。通常情况下 mtr 需要几秒钟时间来输出报告。mtr 报告由一系列跳数组成，每一跳意味着数据包通过节点或者路由器来达到目的主机。

一般情况下 mtr 前几跳都是本地 ISP，后几跳属于服务商比如 腾讯数据中心，中间跳数则是中间节点，如果发现前几跳异常，需要联系本地 ISP 服务提供上，相反如果后几跳出现问题，则需要联系服务提供商，中间几跳出现问题，则需要联系运营商进行处理

默认使用 -r 参数来生成报告，只会发送10个数据包，如果想要自定义数据包数量，可以使用 -c 参数

-s or –packetsize

使用 -s 来指定ping数据包的大小

1.mtr -s 100 qq.com

100 bytes 数据包会用来发送，测试，如果设置为负数，则每一次发送的数据包的大小都会是一个随机数。

-c

指定发送数量

1.mtr -c 100 qq.com

-n

不进行主机解释

使用 -n 选项来让 mtr 只输出 IP，而不对主机 host name 进行解释

1.mtr -n qq.com

MTR结果分析

当我们分析 MTR 报告时候，最好找出每一跳的任何问题。除了可以查看两个服务器之间的路径之外，MTR 在它的七列数据中提供了很多有价值的数据统计报告。Loss% 列展示了数据包在每一跳的丢失率。Snt 列记录的多少个数据包被送出。使用 –report 参数默认会送出10个数据包。如果使用 –report-cycles=[number-of-packets] 选项，MTR 就会按照 [number-of-packets] 指定的数量发出 ICMP 数据包。

Last, Avg, Best 和 Wrst 列都标识数据包往返的时间，使用的是毫秒（ ms ）单位表示。Last 表示最后一个数据包所用的时间， Avg 表示评价时间， Best 和 Wrst 表示最小和最大时间。在大多数情况下，平均时间（ Avg）列需要我们特别注意。

最后一列 StDev 提供了数据包在每个主机的标准偏差。如果标准偏差越高，说明数据包在这个节点的延时越不相同。标准偏差会让您了解到平均延时是否是真的延时时间的中心点，或者测量数据受到某些问题的干扰。

例如，如果标准偏差很大，说明数据包的延迟是不确定的。一些数据包延迟很小（例如：25ms），另一些数据包延迟很大（例如：350ms）。当10个数据包全部发出后，得到的平均延迟可能是正常的，但是平均延迟是不能很好的反应实际情况的。如果标准偏差很高，使用最好和最坏的延迟来确定平均延迟是一个较好的方案。

在大多数情况下，您可以把 MTR 的输出分成三大块。根据配置，第二或第三跳一般都是您的本地 ISP，倒数第二或第三跳一般为您目的主机的ISP。中间的节点是数据包经过的路由器。

当分析 MTR 的输出时，您需要注意两点：loss 和 latency。

网络丢包

如果在任何一跳上看到 loss 的百分比，这就说明这一跳上可能有问题了。当然，很多服务提供商人为限制 ICMP 发送的速率，这也会导致此问题。那么如何才能指定是人为的限制 ICMP 传输 还是确定有丢包的现象？此时需要查看下一跳。如果下一跳没有丢包现象，说明上一条是人为限制的。如下示例：

人为限制MTR丢包

在此例中，第4跳发生了丢包现象，但是接下来几条都没任何丢包现象，说明第二跳的丢包是人为限制的。如果在接下来的几条中都有丢包，那就可能是第二跳有问题了。请记住，ICMP 包的速率限制和丢失可能会同时发生。

MTR丢包截图

从上面的图中，您可以看从第13跳和第17跳都有 10% 的丢包率，从接下来的几跳都有丢包现象，但是最后15,16跳都是100%的丢包率，我们可以猜测到100%的丢包率除了网络糟糕的原因之前还有人为限制 ICMP。所以，当我们看到不同的丢包率时，通常要以最后几跳为准。

还有很多时候问题是在数据包返回途中发生的。数据包可以成功的到达目的主机，但是返回过程中遇到“困难”了。所以，当问题发生后，我们通常需要收集反方向的 MTR 报告。

此外，互联网设施的维护或短暂的网络拥挤可能会带来短暂的丢包率，当出现短暂的10%丢包率时候，不必担心，应用层的程序会弥补这点损失。

网络延迟

除了可以通过MTR报告查看丢包率，我们也还可以看到本地到目的之间的时延。因为是不通的位置，延迟通常会随着条数的增加而增加。所以，延迟通常取决于节点之间的物理距离和线路质量。

MTR查看网络延迟

从上面的MTR报告截图中，我们可以看到从第11跳到12跳的延迟猛增，直接导致了后面的延迟也很大，一般有可能是11跳到12跳属于不通地域，物理距离导致时延猛增，也有可能是第12条的路由器配置不当，或者是线路拥塞。需要具体问题进行具体的分析。

然而，高延迟并不一定意味着当前路由器有问题。延迟很大的原因也有可能是在返回过程中引发的。从这份报告的截图看不到返回的路径，返回的路径可能是完全不同的线路，所以一般需要进行双向MTR测试。

注：ICMP 速率限制也可能会增加延迟，但是一般可以查看最后一条的时间延迟来判断是否是上述情况。

根据MTR结果解决网络问题

MTR 报告显示的路由问题大都是暂时性的。很多问题在24小时内都被解决了。大多数情况下，如果您发现了路由问题，ISP 提供商已经监视到并且正在解决中了。当您经历网络问题后，可以选择提醒您的 ISP 提供商。当联系您的提供商时，需要发送一下 MTR 报告和相关的数据。没有有用的数据，提供商是没有办法去解决问题的。

然而大多数情况下，路由问题是比较少见的。比较常见的是因为物理距离太长，或者上网高峰，导致网络变的很慢。尤其是跨越大西洋和太平洋的时候，网络有时候会变的很慢。这种情况下，建议就近接入客户的节点。

centos网络命令

在CentOS系统上，目前有NetworkManager和network两种网络管理工具。如果两种都配置会引起冲突，而且NetworkManager在网络断开的时候，会清理路由，如果一些自定义的路由，没有加入到NetworkManager的配置文件中，路由就被清理掉，网络连接后需要自定义添加上去。

目前在CentOS上的NetworkManager版本比较低，而且比较适合有桌面环境的系统，所以服务器上保留network服务即可，将NetworkManager关闭，并且禁止开机启动。

systemd管理上：

systemctl status NetworkManager #查看状态

systemctl stop NetworkManager

systemctl disable NetworkManager #enable 表示开机自启 disable 表示开启不启动

如果NetworkManager没有运行，则可以通过简单运行来启动它。

# systemctl start NetworkManager

停止NetworkManager

要出于某种原因停止或停用NetworkManager，请发出以下命令。

# systemctl stop NetworkManager

启用NetworkManager后我们可以用以下图形命令来配置网络

nmtui

ifconfig -a 查处网络情况

查看网关和路由表(路由就是选路)
命令:route

跟踪数据包的转发路径
命令：traceroute

查看网络连接状态
命令：netstat
选项: -t tcp
-u udp
-p 进程
-a 所有
-n 数字形式显示

重启网络服务的方法
service network restart

ifconfig eth0 up （启用网卡） 或者ifup eth0

ifconfig eth0 down （禁用网卡） 或者 ifdown eth0

	同一个网络接口可以使用子接口的方式设置多个IP地址
	[root@centos ~]#  ifconfig eno33554984:2 192.168.146.152 netmask 255.255.255.0 up

	当服务器重启或网络服务重启后，子接口配置将消失，如需重启后依然生效，可以将配置子接口命令加入开机自动执行文件/etc/rc.local文件中。

（如果设置后还没有开机自动执行，是因为有的centos版本/etc/rc.d/rc.local没有执行权限，于是执行    chmod +x /etc/rc.d/rc.local就可以了)

以下看下如何配置网卡固定IP等

例如网卡设备名称为eth0, 用vi命令编辑网卡配置文件, 设置IP，掩码，网关，DNS。其中NAME和DEVICE 后面的名字按实际的网卡名字填写。

# cd /etc/sysconfig/network-scripts

然后ls 看到里面有网卡配置文件 ifcfg-eth0

# vi ifcfg-eth0

打开文件后按“i”键切换至编辑模式，修改以下相关内容，标颜色的部分按实际情况修改。编辑完成后，按”Esc”退出编辑模式，输入“: wq” 保存退出。

TYPE=Ethernet

DEVICE=eth0

NAME=eth0

BOOTPROTO=static

ONBOOT=yes

IPADDR=192.168.1.200

NETMASK=255.255.255.0

GATEWAY=192.168.1.1

DNS1=114.114.114.114

修改完成后重启网络服务

# systemctl restart network

Centos7中利用docker搭建openwrt旁路由

https://blog.csdn.net/ndd1996/article/details/109185747

1.查询当前网卡名称(以下均以网卡名eth0为例,请注意替换)

2.打开网卡混杂模式

3.创建虚拟网络

4.拉取openwrt镜像(以lean大神的openwrt为例)

拉取完毕之后查看一下拉取结果

5.创建并运行openwrt容器

6.查看openwrt容器运行状态，如果STATUS是UP则说明运行成功

7.进入openwrt容器

8.编辑配置文件

修改lan口内容

9.重启网络

docker中搭建openwrt到此结束，具体openwrt旁路由配置请参照百度或者google

CentOS7系统配置firewalld使用NAT方法将网络共享给内部局域网机器

1,用 Linux 打造路由器 zebra,

2,Linux系统下安装Vmware

3,linux+openwrt

4,firewalld+nat

5,iptables

自从用 HAProxy 对服务器做了负载均衡以后，感觉后端服务器真的没必要再配置并占用公网IP资源。
而且由于托管服务器的公网 IP 资源是固定的，想上 Keepalived 的话，需要挤出来 3 个公网 IP 使用，所以更加坚定了让负载均衡后端服务器释放公网 IP 的想法。
可是，后端服务器也不是简单释放公网 IP 就能正常工作的，正在运行的系统很多模块依然需要具有连接外网获取数据的能力。

所以就想到了用 CentOS 做一个软路由（内网 NAT 转发），如果能实现的话，就满足了我的需求。
搜索并试验了一番，目前发现用 iptables 是可行的，而且已经被我验证有效的方案。

由于用到了 iptables，需要停止并禁用内置的 firewalld 防火墙服务。

☼ 停止内置的 firewalld

systemctl stop firewalld
systemctl disable firewalld

☼ 打开系统的 IP 转发功能

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p

☼ 安装 iptables 服务

yum -y install iptables-services
# 移除 iptables 服务
#yum -y remove iptables-services

☼ 查看 iptables 规则

iptables -L

☼ 清空默认的 filter 表

iptables -F

☼ 清空默认的 nat 表

iptables -t nat -F

☼ 默认规则，禁止所有入站，允许所有出站

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT

☼ 默认规则，允许所有本地环回通信，出入站

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

☼ 重点，开启 NAT 功能

iptables -t nat -A POSTROUTING -j MASQUERADE

☼ 完整的命令

可以在命令行下粘贴批量执行

systemctl stop firewalld
systemctl disable firewalld


yum -y install iptables-services


iptables -F
iptables -t nat -F
iptables -P INPUT  DROP
iptables -P OUTPUT ACCEPT
iptables -t nat -A POSTROUTING -j MASQUERADE

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp -s 192.168.66.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 你的可信任远程管理IP -j ACCEPT


iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

iptables-save > /etc/sysconfig/iptables
systemctl restart iptables

☼ 其他

# 允许已建立的传入连接
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# 允许DHCP传入连接
iptables -A INPUT -i eth1 -p udp --dport 67:68 -j ACCEPT

# 默认禁止路由转发
iptables -P FORWARD DROP

# 允许内网路由转发
iptables -A FORWARD -s 192.168.66.0/24 -j ACCEPT

☼ 后记，补充 2017-12-13 20:28

捣鼓了一下午，NAT 转发当路由器供内网服务器上网终于搞定了，结果CentOS重启后，发现 iptables 的配置丢失，竟然没有永久保存？
太扯淡！

网上说这个问题的还很多，有人说可以制作自启动脚本，在启动时自动将 iptables 的规则重新注册一次，
也算是一个解决办法。

不过，思来想起，既然 CentOS 已经抛弃了 iptables ，那肯定是有一定道理的，firewalld 一定也有办法实现同样的功能吧！


firewall-cmd --permanent --zone=public --add-masquerade

# 调整防火墙策略，开放 vrrp 协议，给 Keepalived 使用
# 否则可能导致【脑裂】问题，争抢VIP，或者master挂掉之后backup无法正常工作
firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0 --in-interface ens33 --protocol vrrp -j ACCEPT
firewall-cmd --reload
#

搞定了。

当然其他功能端口的开放，这里就不啰嗦了 (0^0)。

other page1

环境介绍：

一台CentOS6 主机，双网卡，两网段

网口设定如下：

[root@CentOS ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 
DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=dhcp
[root@CentOS ~]# 

[root@CentOS ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=static

IPADDR=192.168.66.1
NETMASK=255.255.255.0

[root@CentOS ~]# service network restart


[root@CentOS ~]# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:0C:29:37:00:93  
          inet addr:172.16.20.183  Bcast:172.16.255.255  Mask:255.255.0.0

		  
eth1      Link encap:Ethernet  HWaddr 00:0C:29:37:00:9D  
          inet addr:192.168.66.1  Bcast:192.168.66.255  Mask:255.255.255.0

打开网卡转发

[root@CentOS ~]# vim /etc/sysctl.conf  
net.ipv4.ip_forward = 1

立即生效

[root@CentOS ~]# sysctl -p

转发规则：

[root@CentOS ~]# iptables -t nat -A POSTROUTING -s 192.168.66.0/24 -j SNAT --to 172.16.20.183 #出口为静态IP选这个
[root@CentOS ~]# iptables -t nat -A POSTROUTING -s 192.168.66.0/24 -o eth0 -j MASQUERADE #出口为动态IP选这个

查看/保存转发规则

[root@CentOS ~]# iptables -t nat -nL
[root@CentOS ~]# service iptables save

other page2

学校实验室有台服务器申请了固定的公网IP，能连接外部网络，同时该机器和其它几台内部服务器连接在一个路由器上。需要将该服务器的网络共享给其它内网服务器。进行如下设置即可。

首先，外网服务器有两根网线连接，一根和外网相连，一根和内网路由器相连。在外网服务器进行NAT转发设置：

第一种方法：
开启NAT转发
# firewall-cmd --permanent --zone=public --add-masquerade
开放DNS使用的53端口，否则可能导致内网服务器虽然设置正确的DNS，但是依然无法进行域名解析。
# firewall-cmd --zone=public --add-port=53/tcp --permanent
重启防火墙
# systemctl restart firewalld.service
# 检查是否允许NAT转发
firewall-cmd --query-masquerade
# 关闭NAT转发
firewall-cmd --remove-masquerade

第二种方法：
开启ip_forward转发
在/etc/sysctl.conf配置文件尾部添加
net.ipv4.ip_forward=1
然后让其生效
# sysctl -p
执行firewalld命令进行转发：
firewall-cmd --permanent --direct --passthrough ipv4 -t nat -I POSTROUTING -o enoxxxxxx -j MASQUERADE -s 192.168.1.0/24
注意enoxxxxxx对应外网网口名称。
重启防火墙
# systemctl restart firewalld.service

设置外网服务器的IP地址为192.168.1.1，然后，在内网服务器中对配置文件/etc/sysconfig/network-scripts/ifcfg-enxxxxxx进行修改，设置网卡的网关为外网服务器的IP地址：

ONBOOT=yes
IPADDR=192.168.1.2
PREFIX=24
GATEWAY=192.168.1.1
DNS1=119.29.29.29

重启内网服务器的网络服务，即可访问外网了。

# systemctl restart network.service