bridge

写于2013/08/07 一个问题困扰了我多年，相信也困扰了很多人多年！那就是Windows上使用OpenUOM时，通过隧道的包的源IP地址总是OpenUOM虚拟网卡网段的IP地址，由于Windows的路由选择是自动进行的，除非你在应用程序中bind一个地址，否则它选什么你用什么，配置路由时，你无法指定Linux的iproute2的src参数。因此只要是要通过TAP-Win32网卡走的包，其源地址均是TAP-Win32网卡上配置的虚拟IP地址！目前的解决方案有三种： 1.OpenUOM的2.3.0版本有NAT的配置选项： --client-nat snat|dnat network netmask alias 但是我不敢用，怕应用程序的校验码用到了原始IP信息； 2.可以用Windows的LSP来强制bind物理网卡的IP，但是我还是觉得不够完美； 3.在服务端做SNAT。然而为了WIndows客户端做定制，也不完美； 网络的问题就要网络自己解决，不要依赖太多上层的东西！虽然Windows网络不给力，但是想降伏它还是有办法的，大不了就搞NDIS啊！客户端自己的事情自己解决，别麻烦服务端，为了解决客户端的问题，在服务端加配置算什么事啊！ 写在前面 这篇文章 描述了Windows选择源IP地址的详细过程，另外微软的文档中也有介绍，这里就不多说了。总之，不管是强主机模式还是弱主机模式

在本篇文章里小编给大家整理了关于docker容器无法stop的解决办法，有需要的朋友们可以参考下。 解决方法如下： 1、强制删除容器 docker rm -f jenkins 2、清理此容器的网络占用 docker network disconnect --force bridge jenkins docker 无法stop，kill容器 最近在遇到docker无法删除，或者kill相应的容器，要么是运行完docker stop xxx后发现xxx仍然存在，要么就根本无法删除，或者发现会报错，提示 Error response from daemon: Conflict, cannot remove the default name of the container 这种情况的可能原因是在过去的某个时刻，已创建了一个命名容器，然后您已将其保持运行状态。之后，主机因任何原因重新启动，并且没有优雅地终止容器。剩下的文件现在似乎阻止你重新生成旧名称的新容器，因为系统认为旧容器仍然存在。 我们先使用docker ps -a 看看所有容器的运行记录，以异常方式退出的容器将具有非零状态代码。根据名称搜索需要的名称，然后使用实际的十六进制代码将其删除 docker rm xxxxxx。 但是，有时候发现-a并没有多余信息。则可用手动删除容器方法。即删除/var/lib/docker

1、 新建 并启动容器 使用以下 docker run命令即可新建并启动一个容器，该命令是最常用的命令，它有很多选项，下面将列举一些常用的选项。 -d选项：表示后台运行 -P选项：随机端口映射 -p选项：指定端口映射，有以下四种格式。 -- ip:hostPort:containerPort -- ip::containerPort -- hostPort:containerPort -- containerPort --net选项：指定网络模式，该选项有以下可选参数： --net=bridge: 默认选项 ，表示连接到默认的网桥。 --net=host:容器使用宿主机的网络。 --net=container:NAME-or-ID：告诉 Docker让新建的容器使用已有容器的网络配置。 --net=none：不配置该容器的网络，用户可自定义网络配置。 # docker run -d -p 91:80 nginx 这样就能启动一个 Nginx容器。在本例中，为 docker run添加了两个参数，含义如下： -d 后台运行 -p 宿主机端口:容器端口 #开放容器端口到宿主机端口 访问 http://Docker宿主机 IP:91/，将会看到nginx的主界面如下： 需要注意的是，使用 docker run命令创建容器时，会先检查本地是否存在指定镜像。如果本地不存在该名称的镜像，

（转自： https://blog.csdn.net/kv110/article/details/47919913 ） ebtables是与iptables类似的命令， 区别在于ebtables用于对以太网帧的过滤，iptables用于对ip数据包的过滤。 过滤流程见图 1. 命令格式 ebtables [-t table ] -[ACDI] chain rule specification [match extensions] [watcher extensions] target ebtables [-t table ] -P chain ACCEPT | DROP | RETURN ebtables [-t table ] -F [chain] ebtables [-t table ] -Z [chain] ebtables [-t table ] -L [-Z] [chain] [ [--Ln] | [--Lx] ] [--Lc] [--Lmac2] ebtables [-t table ] -N chain [-P ACCEPT| DROP| RETURN] ebtables [-t table ] -X [chain] ebtables [-t table ] -E old-chain-name new-chain-name ebtables [-t table ] -

　　上一篇博客我们主要聊了下docker镜像相关的说明以及怎样基于现有镜像制作镜像、分发镜像到docker仓库中的相关测试；回顾请参考 https://www.cnblogs.com/qiuhom-1874/p/12941508.html ；今天我们来聊一聊docker的网络相关说明； 　　在使用vm虚拟机时，我们知道一个虚拟机可以有三种虚拟网络接口，第一种网络是桥接网络，第二种是NAT网络，第三种是仅主机网络；这三种虚拟网络接口后面对应的都是一个个不同的虚拟网络；我们要想让虚拟机在那个网络中工作就把对应接口更换成那个接口即可；相对于docker来讲，docker内部也有三种虚拟网络接口，它们分别是bridge,host,none这三种；bridge是docker容器默认的网络类型，启动容器不指定网络时默认是bridge，该网络类型是桥接到宿主机的docker0桥上的，而docker0桥上一个NAT桥；host在docker里不是仅主机网络类型，它这里的意思是共享宿主机网络，即同宿主机共享同一网络名称空间；none表示空网络类型，在docker的网络中表现形式就是我们启动容器指定网络类型为none，在容器内部除了lo接口就没有别的其他网络接口，这意味着该容器网络只能自己和自己通信，有点类似vm里的仅主机网络；其实除了以上三种网络，docker也支持自定义网络

1. 虚拟化分类 1.1 虚拟化 　　虚拟化是指通过虚拟化技术将一台计算机虚拟为多台逻辑计算机。在一台计算机上同时运行多个逻辑计算机，每个逻辑计算机可运行不同的操作系统，并且应用程序都可以在相互独立的空间内运行而互相不影响，从而显著提高计算机的工作效率。 虚拟化使用软件的方法重新定义划分 IT 资源，可以实现 IT 资源的动态分配、灵活调度、跨域共享，提高 IT 资源利用率，使 IT 资源能够真正成为社会基础设施，服务于各行各业中灵活多变的应用需求。 1.2 虚拟化层次种类 完全虚拟化 ： 　　最流行的虚拟化方法使用名为 hypervisor 的一种软件，在虚拟服务器和底层硬件之间建立一个抽象层。 VMware 和微软的VirtualPC 是代表该方法的两个商用产品，而基于核心的虚拟机 (KVM) 是面向 Linux 系统的开源产品hypervisor 可以捕获 CPU 指令，为指令访问硬件控制器和外设充当中介。因而，完全虚拟化技术几乎能让任何一款操作系统不用改动就能安装到虚拟服务器上，而它们不知道自己运行在虚拟化环境下。主要缺点是， hypervisor 给处理器带来开销。 准虚拟化 ： 　　完全虚拟化是处理器密集型技术，因为它要求 hypervisor管理各个虚拟服务器，并让它们彼此独立。减轻这种负担的一种方法就是，改动客户端操作系统，让它以为自己运行在虚拟环境下

桥接模式 目录 桥接模式 模式定义 模式动机 UML类图 源码实现 优点 缺点 总结 模式定义 桥接模式(Bridge), 将抽象部分与它的实现部分分离，使他们都可以独立的变化。 什么叫抽象与他的实现分离，这并不是说让抽象类与其派生类分离，因为这没有任何意义。实现指的是抽象类和它的派生类用来实现自己的对象。 模式动机 解决继承带来的问题 对象的继承关系是在编译时就定义好的，所以无法再运行时改变从父类继承的实现。子类的实现与他的父类有非常紧密的依赖关系，以至于父类实现中的任何变化必然会导致子类发生变化。当你需要复用子类时，如果继承下来的实现不适合解决新的问题，则父类必须重写或被其他更适合的类替换。这种依赖关系限制了灵活性并最终限制了复用性。 合成/聚合复用原则（CARP） 合成（组合）和聚合都是关联的特殊种类。 聚合表示一种弱的‘拥有’关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分；合成则是一种强的‘拥有’关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。 聚合关系在继承关系不适用的情况下可以做替代。其实 只要真正深入的理解了设计原则，很多设计模式其实就是原则的应用而已，或许在不知不觉中就在使用设计模式了。 设想如果要绘制矩形、圆形、椭圆、正方形，我们至少需要4个形状类，但是如果绘制的图形需要具有不同的颜色，如红色、绿色、蓝色等，此时至少有如下两种设计方案

设计模式 1. 根据目的来分 根据模式是用来完成什么工作来划分，这种方式可分为创建型模式、结构型模式和行为型模式 3 种。 创建型模式：用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使用分离”。GoF 中提供了单例、原型、工厂方法、抽象工厂、建造者等 5 种创建型模式。 结构型模式：用于描述如何将类或对象按某种布局组成更大的结构，GoF 中提供了代理、适配器、桥接、装饰、外观、享元、组合等 7 种结构型模式。 行为型模式：用于描述类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，以及怎样分配职责。GoF 中提供了模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器等 11 种行为型模式。 2. 根据作用范围来分 根据模式是主要用于类上还是主要用于对象上来分，这种方式可分为类模式和对象模式两种。 类模式：用于处理类与子类之间的关系，这些关系通过继承来建立，是静态的，在编译时刻便确定下来了。GoF中的工厂方法、（类）适配器、模板方法、解释器属于该模式。 对象模式：用于处理对象之间的关系，这些关系可以通过组合或聚合来实现，在运行时刻是可以变化的，更具动态性。GoF 中除了以上 4 种，其他的都是对象模式。 3.设计模式的功能 1、FACTORY 工厂方法：追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西

01 准备环境 环境：ubuntu 16.04 环境（物理 or 虚拟） 确认 CPU 是否支持虚拟化： # egrep -o '(vmx|svm)' /proc/cpuinfo # vmx 如果不支持，开启 KVM 嵌套虚拟化之后再重启。 1.1 安装 KVM 环境 sudo apt - get install -y qemu -kvm qemu -system libvirt -bin virt -manager bridge -utils vlan 1.2 安装 Ubuntu 图形化界面 sudo apt - get install -y xinit gdm kubuntu -desktop 02 创建 KVM 虚拟机 使用 virt-manager 创建 KVM 虚拟机，方法比较简单，由于篇幅有限，大家可以查阅相关资料自行了解。 创建完之后用 virsh list --all 查看创建的 VM： Id Name State ---------------------------------------------------- - kvm1 shut off - kvm2 shut off - kvm3 shut off 我们的实验拓扑如下： image 图中创建了 2 个 Linux Bridge：brvlan1 和 brvlan2，宿主机的物理网卡 eth0

spring boot 各版本中使用 log4j2 记录日志 前言 Spring Boot中默认日志工具是 logback ，只不过我不太喜欢 logback 。为了更好支持 spring boot 框架，我使用 log4j 。 spring boot 各版本与 log4j 的支持情况 1. spring boot 1.2.X 版本 spring boot 1.2.X 版本一般建议使用默认日志工具(logback)，也可以使用 log4j。 但，注意的是： Spring Boot 1.2.4.RELEASE 包含一个bug， github上关于该问题的解释 。所以，当你通过 application.properties 定义日志级别时，该错误会更改父记录器级别，在最差情况下会更改根记录器级别。虽然这个bug是修复在 1.2.6.RELEASE ，我建议至少使用 1.2.8.RELEASE (如果你想坚持1.2.x)。 因为 spring boot 现在仍然在快速发展阶段，版本更新较快，有时候就会因为版本问题而出现各种奇奇怪怪的bug。 2. spring boot 1.3.X 版本 spring boot 从 1.3.X 版本开始支持 slf4j + log4j/log4j2 。 * 首先，先解决为什么使用 SL4J Facade？ 对于这个问题，网上已经有许多精彩地点答案了