Deployment当中借助于ReplicaSet进行更新的策略反映在Deployment的对象定义所需字段可使用kubectl explain deploy，Deployment属于extension群组。在1.10版本中它被移至到apps群组。他与ReplicaSet相比增加了几个字段。 stratgy 重要字段，定义更新策略，它支持两种策略 重建式更新 Recreate与滚动更新RollingUpdate，如果type为RollingUpdate，那么RollingUpdate的策略还可以使用RollingUpdate来定义，如果type为Recreate，那么RollingUpdate字段无效。 默认值为RollingUpdate stratgy.RollingUpdate控制RollingUpdate更新力度 maxSurge 对应的更新过程当中，最多能超出目标副本数几个。有两种取值方式，为直接指定数量和百分比。在使用百分比时，在计算数据时如果不足1会补位1个。 maxUnavailable 最多有几个副本不可用。 revisionHistoryLimit 滚动更新后，在历史当中最多保留几个历史版本，默认10。 在使用Deployment创建Pod时，Deployment会自动创建ReplicaSet，而且Deployment名称是使用Pod模板的hash值，此值是固定的。 Deployment在实现更新应用时，可以通过编辑配置文件来实现，使用kubectl apply -f更改每次变化。每次的变化通过吧变化同步至apiserver中，apiserver发现其状态与etcd不同，从而改变etcd值来实现修改其期望状态，来实现现有状态去逼近期望状态。 kubectl explain deploy yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 apiVersion: apps/v1 kind: Deployment metadata: name: app-deploy namespace: default spec: replicas: 2 selector: matchLabels: app: deploy release: canary template: metadata: labels: app: deploy release: canary spec: containers: - name: my-deploy image: node01:5000/busybox:v1 ports: - name: http containerPort: 80 command: ["/bin/sh","-c","/bin/httpd -f -h /tmp"] 使用kubectl apply 声明式更新、创建资源对象。...

IngressController比较独特，它与DaemonSet、Deployment、Repliacaset不同，DaemonSet、Deployment等控制器是作为ControllerManager的子组件存在的。Ingress Controller是独立运行的一组Pod资源，通常是拥有七层代理、调度能力的应用程序。 通常在使用IngressController时有三种选择Nginx、Traefik、Envoy。 IngressController nginx运行在Pod中，其配置文件是在Pod中。后端代理的Pod随时会发生变动，IngressController需要watch API当中的后端Pod资源的改变。IngressController自身无法识别目前符合自己关联的（条件的）被代理的Pod资源有哪些，IngressController需借助service来实现。 因此要想定义一个对应的调度功能，还需要创建service，此service通过label selector关联至每一个upstream服务器组，通过此service资源关联至后端的Pod。此service不会被当做被代理时的中间节点，它仅仅是为Pod做分类的。此service关联的Pod，就将其写入upstream中。 在Kubernetes中有一种特殊资源叫做Ingress，当Pod发生改变时，其servcie对应的资源也会发生改变， 依赖于IngressResource将变化结果反应至配置文件中。 Ingress定义期望IngressController如何创建前段代理资源（虚拟主机、Url路由映射），同时定义后端池（upstream）。upstream中的列表数量，是通过service获得。 Ingress可以通过编辑注入到IngressController中，并保存为配置文件，且Ingress发现service选定的后端Pod资源发生改变，此改变会及时反映至Ingress中，Ingress将其注入到前端调度器Pod中，并触发Pod中的container主进程（nginx）重载配置文件。 要想使用Ingress功能，需要有service对某些后端资源进行分类，而后Ingress通过分类识别出Pod的数量和IP地址信息，并将反映结果生成配置信息注入到upstream中。 IngressController根据自身需求方式来定义前端，而后根据servcie收集到的后端Pod IP定义成upstream server，将这些信息反映在Ingress server当中，由Ingress动态注入到IngressController当中。 Ingress也是标准的Kubernetes资源，定义Ingress时同样类似于Pod方式来定义。使用kubectl explain Ingress查看帮助。 spec rules 规则，对象列表 host 主机调度 虚拟主机而非url映射 http paths 路径调度 backend path backend 定义被调度的后端主机，靠service定义，找到后端相关联的Pod资源。 serviceName 后端servcie名称，即用来关联Pod资源的service。 servicePort IngressController部署 namespace.yaml 创建名称空间 configmap.yaml 为nginx从外部注入配置的 rbac.yaml 定义集群角色、授权。必要时让IngressController拥有访问他本身到达不了的名称空间的权限 ingress.yaml yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 apiVersion: extensions/v1beta1 kind: Ingress metadata: name: ingress-myapp namespace: defualt # 与deployment和要发布的service处在同一名称空间内 annotations: kubernetes....

基于web的UI前端，认证是由Kubernetes完成的。登陆dashboard的密码是k8s的账号和密码，和dashboard自身没有关系。dashboard自身不做认证。 text 1 kubectl patch svc kubernetes-dashboard -p'{"spec":{"type":"NodePort"}}'-n kube-system 如使用域名访问，CN一定要与域名保持一致。 text 1 2 3 4 (umask 077; openssl genrsa -out dashboard.key 2048) openssl req -new -key dashboard.key -out dashboard.csr -subj "/O=test/CN=dashboard" openssl req -in dashboard.csr -noout -text openssl x509 -req -in dashboard.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out dashboard.crt -days 3650 Certificate Attributes 要想穿透集群边界，从集群外访问集群内部某一服务或Pod上的容器的应用，有两种方式 nodePort、NodeBlanc 或ingress text 1 2 3 4 5 kubectl create secret generic \ dashboard-cert \ -n kube-system \ --from-file=dashboard....

secret、configMap特殊类型的存储卷，多数情况下不是为Pod提供存储空间来用的，而是给管理员或用户提供了从集群外部向Pod内部应用注入配置信息的方式。 工作实现 configMap 在集群内部存在一个名称空间，在名称空间当中拥有一个可正常运行的Pod，当镜像启动时使用的配置文件在做镜像之前就确定了，并且做完镜像就不能修改了。除非在做镜像时使用entryPoint脚本去接受用户启动容器时传入环境变量进来，将环境变量的数据替换到配置文件中去，从而使应用程序在启动之前就能获得一个新的配置文件而后得到新的配置。当需要修改配置文件时是很麻烦的。而配置中心只需将集中的配置文件修改，并通知给相应进程，让其重载配置文件。而Kubernetes的应用也存在此类问题，当配置文件修改后就需要更新整个镜像。因此无需将配置信息写死在镜像中。而是引入一个新的资源，这个资源甚至是整个Kubernetes集群上的一等公民（标准的K8S资源）。这个资源被叫做configMap configMap当中存放的配置信息，随后启动每一个Pod时，Pod可以共享使用同一个configMap资源，这个资源对象可以当存储卷来使用，也可以从中基于环境变量方式从中获取到一些数据传递给环境变量，注入到容器中去使用。 因此configMap扮演了Kubernetes中的配置中心的功能。但是configMap是明文存储数据的。因此和configMap拥有同样功能的标准资源secret就诞生了。与configMap所不同之处在于，secret中存放的数据是用过编码机制进行存放的。 核心作用：让配置信息从镜像中解耦，从而增强应用的可移植性与复用性。使一个镜像文件可以为应用程序运行不同配置的环境而工作。简单来讲，一个configMap就是一系列配置数据的集合。这些数据可以注入到Pod对象中的容器所使用。 在configMap中，所有的配置信息都保存为key value格式。V只是代表了一段配置信息，可能是一个配置参数，或整个配置文件信息都是没有问题的。 配置容器化应用的方式 自定义命令行参数 args [] 把配置文件直接陪进镜像； 环境变量 Cloud Native的应用程序一般可直接通过环境变量加载配置 通过entrypoint脚本来预处理变量为配置文件中的配置信息。 存储卷 配置文件注入方式： 将configMap做存储卷 使用env docker config contioners env name 变量名 value 变量值 valueFrom 数据不是一个字符串，而是引用另外一个对象将其传递给这个变量。 configMapKeyRef configMap中的某个键 fieldRef 某个字段。此资源可以是Pod自身的字段。如metadata.labels status.hostIP status.podIP resourceFieldRef 资源需求和资源限制。 secreKeyRef 引用secre configMap无需复杂描述，因此没有spec字段 text 1 2 3 4 apiVersion kind data binaryData 一般情况下data与binaryData只使用其中一种。 创建简单的configMap还可以使用 kubectl create configMap来创建。如需要长期使用，可以定义为配置清单文件。 text 1 2 3 kubectl create configmap nginx-config \ --from-literal=nginx_port=80 \ --from-literal=servername=test.com 使用文件创建...

RPM概述 RPM (Red Hat Package Manager)，几乎所有的 Linux 发行版本都使用这种形式的软件包管理安装、更新和卸载软件。对于最终用户来说，使用RPM所提供的功能来维护系统是比较容易和轻松的。安装、卸载和升级RPM软件包只需一条命令就可以搞定。RPM维护了一个所有已安装的软件包和文件的数据库，可以让用户进行查询和验证工作。在软件包升级过程中，RPM会对配置文件进行特别处理，绝对不会丢失以往的定制信息。对于程序员RPM可以让我们连同软件的源代码打包成源代码和二进制软件包供最终用户使用。 一般而言制作一个RPM包包含以下几个步骤 计划你想要建立什么 收集软件包 根据需要修补软件 计划升级旧有的包 创建可重现的软件构建 概述任何依赖关系 构建rpm 测试rpm（能否安装、升级） RPM capability 能力 运行或安装需要依赖于其他的RPM包本身或所提供的文件为基础的现象被称之为依赖关系。但在制作RPM包时，依赖关系有两类编译依赖与安装依赖。 自身名字所包含的意义 它提供的文件也有可能被其他软件所依赖，文件本身也能识别成一种能力 编译依赖和安装依赖 每一个RPM包都提供一种能够完成任务的功能，此种能力很可能被其他RPM所依赖，此能力大多数情况下和RPM名字是相同的。 制作RPM包的纲要有如下四部 设定RPM包制作的目录结构（制作车间） 将原材料（源码包、配置文件、补丁包）放置规划好的目录当中。 创建spec文件，指挥如何使用原材料将其制作成rpm包。 编译源代码生成rpm包 在一个特定的目录中提供如下5个子目录 redhat上默认在/usr/src/reahat BUILD 源代码解压以后放置的位置，仅需提供目录。 RPMS 放置制作完成后的RPM包 SOURCES 原材料放置目录（配置文件、源码包、补丁包） SPECS 放置spec文件（纲领性文件）的。 SRPMS SRC rpm包存放位置 RPM优缺点 优点： 集中管理：RPM可以集中管理安装、升级和删除软件包，保证系统的干净和稳定。 精确控制：RPM提供详细的软件包信息，可以对软件包的安装路径、依赖关系、版本等进行精确控制，使得软件安装更加灵活便捷。 简单易用：RPM提供了一套完整的命令行工具和图形化管理工具，对于普通用户来说，使用起来非常方便。 更新机制：RPM可以根据用户需要进行更新，包括安全更新、功能更新和修复错误等，可以更好地保证系统安全与稳定性。 缺点： 依赖管理：RPM虽然可以管理软件包的依赖关系，但其解决依赖的方式容易出现问题，可能会出现某些软件包的依赖关系无法解决的情况。 更新速度：由于需要对软件包进行依赖检查等操作，升级软件包可能需要较长时间，特别是当软件包依赖比较复杂时。 存在问题：有时候使用RPM安装的软件包出现问题，需要手动卸载并重新安装，这会导致一些无法预测的麻烦。 兼容性：RPM采用了特定的软件包管理标准，要求安装的软件包必须符合这些标准。因此，RPM可能不太适用于其他Linux系统或自定义的软件包格式。 SPEC文件 制作RPM软件包的关键在于编写SPEC软件包描述文件。要想制作一个rpm软件包就必须写一个软件包描述文件（SPEC）。这个文件中包含了软件包的诸多信息，如软件包的名字、版本、类别、说明摘要、创建时要执行什么指令、安装时要执行什么操作、以及软件包所要包含的文件列表等等。 SPEC文件通常包括以下几个部分： 头文件：包括软件包的名称、版本、发布号、授权等信息。 %description：包括软件包的描述、依赖关系、构建环境等信息。 %prep：指定源代码的来源和如何解压缩及准备源代码。 %build：指定如何编译源代码。 %install：指定如何安装编译好的软件包。 %check：指定测试源代码的特定部分，通常是用来运行单元测试。 %clean：指定清除构建过程中产生的临时文件和目录的方法。 %files：指定哪些文件应该包括在最终的RPM文件中。 %changelog：记录软件包的变更历史。 SPEC文件中常用的宏变量 宏变量 说明 %{name} 软件包的名称，如 myapp。 %{version} 软件包的版本号，如 1....

Kubernetes API Object 在Kubernetes线群中，Kubernetes对象是持久化的实体（最终存入etcd 中的数据），集群中通过这些实体来表示整个集群的状态。前面通过kubectl来提交的资源清单文件，将我们的YAML文件转换成集群中的一个API对象的，然后创建的对应的资源对象。 Kubernetes API是一个以JSON为主要序列化方式的HTTP服务，除此之外支持Protocol Buffers序列化方式（主要用干集群内年件间的通信）。为了api的可扩展性，Kubemetes在不同的API路径（/api/v1或/apis/batch）下面支持了多个API版本，不同的API版本就味不同级别稳定性和支持。 Alpha ：例如v1Alpha：默认情况下是禁用的，可以随时删除对功能的支持。 Beta：例如 v2beta1 默认是启用的，表示代码已经经过了很好的测试，但是对象的语义可能会在施后的版本中以不兼咨的方式更改 Stable：例如：v1 表示已经是稳定版本，也会出现在后续的很多版本中。 在Kubernetes集群中，一个API对象在Etcd 里的完整资源路径，是由：group （API组）、 version （API版本） 和 Resource API资源类型）三个部分组成。通过这种的结构，整个Kubernetes 中所有API对象，就可以用如下的树形结构表示出来： Kubernetes API Object的使用 API对象组成查看：kubectl get --raw / 通常，KubernetesAPI支持通过标准HTTP P0ST、PUT、DELETE 和 GET 在指定PATH路径上创建、更新、删除和检索操作，并使用JSON作为默认的数据交互格式。 如要创建一个Deployment对象，那YAML文件的声明就需： yaml 1 2 apiVersion: apps/v1 # kind: Deployment Deployment就是这个API对象的资源类型（Resource），apps就是它的组（Group），v1就是它的版本（Version）。API Group、Version 和资源满唯一定义了一个HTTP路径，然后在kube-apiserver 对这个url进行了监听，然后把对应的请求传递给了对应的控制器进行处理。 API对象参考文档 授权插件分类 Node 由节点来认证。 ABAC 基于属性的访问控制，RBAC之前的授权控制的插件算法 RBAC Role-based Access Control。 Webhook 基于http的回调机制来实现访问控制。 RBAC 基于角色的访问控制可以理解为，角色（role）反而是授权的机制，完成了权限的授予、分配等。角色是指一个组织或者任务工作中的位置，通常代表一种权利、资格、责任等。在基于角色的访问控制中还有一种术语叫做 ==许可==（permission）。 简单来讲就如同上图描述，使用户去扮演这个角色，而角色拥有这个权限，所以用户拥有这个角色的权限。所以授权不授予用户而授予角色。 RBAC 使用 rbac.authorization.k8s.ioAPI组来驱动鉴权操作，允许管理员通过 Kubernetes API 动态配置策略。...

近期因 centos 6.x 默认 openssh 扫描存在大量漏洞，基于安全考虑，需要将 openssh_5.3p1 升级为最新版，网上查了很多教程，发现 openssh 存在大量依赖，不解决依赖问题很难保证其他服务政策。而 openssl 又被大量程序依赖。实在是头疼。最后发现一个不破坏各种依赖又可以完美升级的方案 注：curl wget yum 等依赖 openssl gitlab依赖 openssh 因卸载 openssh 与 openssl 编译安装导致各种依赖程序被破坏，虽然最后升级成功，但是wget curl 和代码库被破坏。 下载 openssh-7.7p 源码包 下载地址 下载之后解压看 README 和 INSTALL text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 1. Prerequisites ---------------- A C compiler. Any C89 or better compiler should work....

项目地址：https://github.com/weaveworks/weave 注：weave公司与2024年关门 weaves说明 Weave是由weaveworks公司开发的解决Docker跨主机网络的解决方案，它能够创建一个虚拟网络，用于连接部署在多台主机上的Docker容器，这样容器就像被接入了同一个网络交换机，那些使用网络的应用程序不必去配置端口映射和链接等信息。 外部设备能够访问Weave网络上的应用程序容器所提供的服务，同时已有的内部系统也能够暴露到应用程序容器上。Weave能够穿透防火墙并运行在部分连接的网络上，另外，Weave的通信支持加密，所以用户可以从一个不受信任的网络连接到主机。 weaves实现原理 weave launch初始化时会自动下载三个docker容器来辅助运行，并且创建linux网桥与docker网络 weave 运行了三个容器： weave 是主程序，负责建立weave网络，收发数据，提供 DNS 服务等。 weavevolumes容器提供卷存储 weavedb容器提供数据存储 sh 1 2 3 4 5 6 $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE weaveworks/weavedb latest 15c78a9b1895 4 weeks ago 698B weaveworks/weaveexec 2.4.0 bf0c403ea58d 4 weeks ago 151MB weaveworks/weave 2.4.0 7aa67bc6bc43 4 weeks ago 96.7MB 自动创建网桥 sh 1 2 3 4 5 $ brctl show bridge name bridge id STP enabled interfaces docker0 8000....

默认情况下，容器没有任何资源限制，因此几乎耗尽docker主机之上，内核可分配给当前容器的所有资源。可以使用主机内核调度程序允许的尽可能多的给定资源。在此基础上Docker provides提供了控制容器可以使用多少内存，CPU或块IO的方法，设置docker run命令的运行时配置标志。 容器得以实现主要依赖于内核中的两个属性namespace cgroup。其中许多功能都要求您的内核支持Linux功能。要检查支持，可以使用docker info命令。 Memory OOME 在Linux主机上，如果内核检测到没有足够的内存来执行重要的系统功能，它会抛出OOME或Out of Memory Exception异常，并开始终止进程以释放内存资源。一旦发生OOME，任何进程都有可能被杀死，包括docker daemon自身在内。为此，Docker特地调整了docker daemon的OOM优选级，以免它被内核“正法”，但容器的优选级并未被调整。 工作逻辑为 在宿主机上跑有很多容器并包括系统级进程。系统级进程也包括docke daemon自身。当内核执行系统管理操作，如内核需要使用内存，发现可以内存已经为空，会启动评估操作，评估谁占用内存高。我们认为哪个资源占用内存高就该将其kill来释放内存空间。（需要注意的是占用内存高的进程也不一定被kill掉。A进程分配10G已使用5G，进程B分配1G已使用1G。A只使用50%内存，而B已经耗尽所有内存）。内核会提供这些进程进行评分，按照优先级逆序强制kill，直至可使用内存空间足够。此时内核就可以使用内存资源创建其他进程。 每一个进程被计算之后会有一个oom scores，得分越高就会被优先kill。得分是由内存申请分配空间等一系列复杂计算得知。当进程得分最高也不能被kill掉时，如docker daemon，此时需要调整优先级。每一个进程有一个oom.adj的参数，将优先级调整越低，计算的分数就越少。 在docker run时可以直接调整容器的OOM.adj参数。如果想限制容器能使用多少内存资源、或CPU资源，有专门的选项可以实现。非常重要的容器化应用需要在启动容器时调整其OOM.adj，还可以定义容器的策略，一旦被kill直接restart Limit a container’s resources 限制一个容器能使用多少内存资源或CPU资源docker有专门的选项来实现 -m 限制容器可用RAM空间。选项参数可以使用KB M G等作为接受单位使用。可单独使用。 --memory-swap 设置容器可用交换分区大小。使用swap允许容器在容器耗尽可用的所有RAM时将多余的内存需求写入磁盘。--memory-swap是一个修饰符标志，只有在设置了–memorys时才有意义。 --memory-swap --memory-swap --memory 功能 正数S 正数 M 容器可用总空间为S，其中可用ram为M 0 正数 M相当于未设置swap（unset） unset（未设置） 正数 M 若主机（Docker Host）启用了swap，则容器的可用swap为 2*M -1 正数M 若主机（Docker Host）启用了swap，则容器可使用交换分区总空间大小为宿主机上的所有swap空间的swap资源 注意：在容器内使用free命令可以看到的swap空间并不具有其所展现出的空间指示意义。 –memory-swappiness 用来限定容器使用交换分区的倾向性。 –memory-reservation 预留的内存空间 –oom-kill-disable 禁止oom被kill掉 默认情况下，每个容器对主机CPU周期的访问权限是不受限制的。可以设置各种约束来限制给定容器访问主机的CPU周期。大多数用户使用和配置默认CFS调度程序。在Docker 1.13及更高版本中，还可以配置实时调度程序。 CPU Limit a container’s resources 内核中进程管理子系统当中最重要的组件为进程角度器scheduler，非实时优先级,有效范围为100-139[-20,19]。因此每个进程的默认优先级为120。实时优先级0-99。调度100-139之间的进程有个非常重要的调度器CFS scheduler（完全公平调度器），公平调度每一个进程在需要执行时，去分配scores到这个进程上。...

修改logging.properties text 1 /usr/local/apache-tomcat-8.5.32/conf/logging.properties bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 ############################################################ # Handler specific properties. # Describes specific configuration info for Handlers. ############################################################ 1catalina.org.apache.juli.AsyncFileHandler.level = FINE 1catalina.org.apache.juli.AsyncFileHandler.directory = /data/logs 1catalina.org.apache.juli.AsyncFileHandler.prefix = catalina. 2localhost.org.apache.juli.AsyncFileHandler.level = FINE 2localhost.org.apache.juli.AsyncFileHandler.directory = /data/logs 2localhost.org.apache.juli.AsyncFileHandler.prefix = localhost. 3manager.org.apache.juli.AsyncFileHandler.level = FINE 3manager.org.apache.juli.AsyncFileHandler.directory = /data/logs 3manager.org.apache.juli.AsyncFileHandler.prefix = manager. 4host-manager.org.apache.juli.AsyncFileHandler.level = FINE 4host-manager....

tomcat介绍 Tomcat 服务器是一个免费的开放源代码的Web 应用服务器，Tomcat是Apache 软件基金会（Apache Software Foundation）的Jakarta 项目中的一个核心项目，它早期的名称为catalina，后来由Apache、Sun 和其他一些公司及个人共同开发而成，并更名为Tomcat。 java体系结构 java程序设计语言（编程） java类文件格式 java api java vm java 纯面向对象语言 obj：以指令为中心，围绕指令组织数据 面向对象：以数据为中心，围绕数据组织指令 Tomcat核心组件： Catalina：servlet container在tomcat中用于实现servlet代码的被称作Catalina Coyote：一个http连接器，能够接受http请求并相应http请求的web服务器 jasper：JSP Engine jsp翻译器 Tomcat组成部分 Tomcat支持Servlet和JSP1的规范，它由一组嵌套的层次和组件组成，一般可分为以下四类： 顶级组件：位于配置层次的顶级，并且彼此间有着严格的对应关系； 连接器：连接客户端（可以是浏览器或Web服务器）请求至Servlet容器， 容器：包含一组其它组件； 被嵌套的组件：位于一个容器当中，但不能包含其它组件； tomcat常见组件 服务器(server) 服务器(server)顶级组件：Tomcat的一个实例，通常一个JVM只能包含一个Tomcat实例；因此，一台物理服务器上可以在启动多个JVM的情况下在每一个JVM中启动一个Tomcat实例，每个实例分属于一个独立的管理端口。这是一个顶级组件。 server相关属性 className：用于实现此Server容器的完全限定类的名称，默认为 org.apache.cataliana.core.StandardServer; port：接收shutdown指令的端口，默认仅允许通过本机访问，默认为8005 shutdown：发往此Server用于实现关闭tomcat实例的命令字符串，默认为SHUTDOWN 服务(service) Service主要用于关联一个引擎和此引擎相关的连接器，每个连接器通过一个特定的端口和协议接收入站请求将其转发至关联的引擎进行处理，因此，Service要包含一个引擎（Engine）、一个或多个连接器（Connector）。 定义一个名为Catalina的Service，此名字也会产生相关的日志信息时记录在日志文件当中。 xml 1 <Service name="Catalina"> Service相关属性 className：用于实现service的类名，一般都是 org.apache.catalina.core.StandardService name：此服务的名称，默认为Catalina。 连接器(connectors) 分析并接收用户请求，并把它转换成本地jsp文件代码的请求。负责连接客户端（可以是浏览器或Web服务器）请求至Servlet容器内的Web应用程序，通常指的是接收客户发来请求的位置及服务器端分配的端口。 默认端口通常是HTTP协议的8080，管理员也可以根据自己的需要改变此端口。一个引擎可以配置多个连接器，但这些连接器必须使用不同的端口。默认的连接器是基于HTTP/1.1的Coyote。同时，Tomcat也支持AJP、JServ和JK2连接器。 进入Tomcat的请求可以根据Tomcat的工作模式分为如下两类： Tomcat作为应用程序服务器：请求来自于前端的web服务器，这可能是Apache IIS Nginx。 Tomcat作为独立服务器：请求来自与web浏览器。 Tomcat应该考虑工作情形并为相应情形下的请求分别定义好需要的连接器才能正确接收来自于客户端的请求，一个引擎可以有一个或多个连接器，以适应多种请求方式。 定义连接器可以使用多种属性，有些属性也只是适用于某种特定的连接器类型， 一般来说，常见于server.xml中的连接器类型通常有4种： HTTP连接器 SSL连接器 AJP 1.3连接器 proxy连接器 xml 1 2 3 <Connector port="8080" protocol="HTTP/1....

关于vlan说明 Macvlan和ipvlan是Linux网络驱动程序，它们将底层或主机接口直接暴露给在主机中运行的VM或容器。 Macvlan允许单个物理接口使用macvlan子接口具有多个mac和ip地址。这与使用vlan在物理接口上创建子接口不同。使用vlan子接口，每个子接口使用vlan属于不同的L2域，所有子接口都具有相同的mac地址。使用macvlan，每个子接口将获得唯一的mac和ip地址，并将直接暴露在底层网络中。Macvlan接口通常用于虚拟化应用程序，每个macvlan接口都连接到Container或VM。每个容器或VM可以直接从公共服务器获取dhcp地址，就像主机一样。这将有助于希望Container成为传统网络的客户使用他们已有的IP寻址方案。Macvlan有4种类型(Private, VEPA, Bridge, Passthru)。常用的类型是Macvlan网桥，它允许单个主机中的端点能够在没有数据包离开主机的情况下相互通信。对于外部连接，使用底层网络。下图显示了两个使用macvlan网桥相互通信以及外部世界的容器。两个容器将使用Macvlan子接口直接暴露在底层网络中。 使用mavvlan构建docker网络 Macvlan，MACVLAN或MAC-VLAN允许您在单个物理接口上配置多个第2层（即以太网MAC）地址。 Macvlan允许您配置父物理以太网接口（也称为上层设备）的子接口（也称为从设备），每个接口都有自己唯一的（随机生成的）MAC地址，因此也有自己的IP地址。然后，应用程序、VM和容器可以绑定到特定的子接口，以使用自己的MAC和IP地址直接连接到物理网络。 Mavlan子接口不能直接与父接口通信，即VM不能直接与主机通信。如果需要VM主机通信，则应添加另一个macvlan子接口并将其分配给主机。 Macvlan子接口使用 eth0.20@eth0 表示法来清楚地识别子接口及其父接口。子接口状态绑定到其父级状态。如果eth0关闭，则 eth0.20@eth0 也会关闭。 配置macvlan先决条件 至少需要Linux内核版本3.9以上，建议使用4.0或更高版本。 环境准备 主机名 IP地址 地位 软件环境 物理机 10.0.0.1 物理机 windows10 网关 10.0.0.2 宿主机网关 vmvare网关 c1 10.0.0.3 容器01 docker c2 10.0.0.4 容器02 docker node01 10.0.0.15 宿主机01（vm虚拟机） centos 7.3/docker-ce1806 node02 10.0.0.16 宿主机02（vm虚拟机） centos 7.3/docker-ce1806 2.3 启动网卡混合模式 两台主机网卡使用桥接模式,网卡混杂模式开启全部允许。 主机上配置的eth0网卡和创建的vlan网卡,均需要开启混杂模式。如果不开启混杂模式会导致macvlan网络无法访问外界,具体在不使用vlan时,表现为无法ping通路由,无法ping通同一网络内其他主机。 sh 1 2 ip link set eth0 promisc on ip link set eth0 promisc off 开启后查看网卡状态 sh 1 2 3 4 5 6 7 $ ip addr 2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:0c:29:84:f3:29 brd ff:ff:ff:ff:ff:ff inet 10....

docker的四种网络模式 Bridge模式（默认） 当Docker进程启动时，会在宿主机上创建一个名为docker0的虚拟网桥，此主机上启动的Docker容器会连接到这个虚拟网桥上。虚拟网桥的工作方式和物理交换机类似，这样主机上的所有容器就通过交换机连在了一个二层网络中。 默认ip段172.17.0.1/16；从docker0子网中分配一个IP给容器使用，并设置docker0的IP为容器的默认网关。在主机上创建一对虚拟网卡veth pair设备，Docker将veth pair设备的一端放在新创建的容器中，并命名为eth0（容器的网卡），另一端放在主机中，以vethxxx这样类似的名字命名，并将这个网络设备加入到docker0网桥中。可以通过brctl show命令查看。 使用 docker run -p 时，docker实际是在iptables做了DNAT规则，实现端口转发功能。可以使用 iptables -t nat -nL 查看。 host模式 启动容器的时候使用host模式，那么这个容器将不会获得一个独立的Network Namespace，而是和宿主机共用一个Network Namespace。容器将不会虚拟出自己的网卡，配置自己的IP等，而是使用宿主机的IP和端口。但是，容器的其他方面，如文件系统、进程列表等还是和宿主机隔离的。 none模式 使用none模式，Docker容器拥有自己的Network Namespace，但是，并不为Docker容器进行任何网络配置。也就是说，这个Docker容器没有网卡、IP、路由等信息。需要我们自己为Docker容器添加网卡、配置IP等。 container模式 这个模式指定新创建的容器和已经存在的一个容器共享一个 Network Namespace，而不是和宿主机共享。新创建的容器不会创建自己的网卡，配置自己的 IP，而是和一个指定的容器共享 IP、端口范围等。同样，两个容器除了网络方面，其他的如文件系统、进程列表等还是隔离的。两个容器的进程可以通过 lo 网卡设备通信。 容器外部访问原理 bash 1 2 3 4 5 6 7 8 docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 0.0.0.0 inet6 fe80::42:a5ff:fe59:2034 prefixlen 64 scopeid 0x20<link> ether 02:42:a5:59:20:34 txqueuelen 0 (Ethernet) RX packets 56986 bytes 2746876 (2.6 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 64106 bytes 503304169 (479....

参数 说明 -i, –interactive 即使不是交互模式也保持stdin打开 -d, –detach 后台运行容器并打印容器ID -t, –tty 分配一个伪TTY 添加自定义主机映射 bash 1 2 3 4 5 6 $ docker run -tid --add-host docker-node:10.0.0.1 centos 61d5824c720f1a32c743a3d0f434e17a7f6860dba1cb5559653a80c064da8073 $ docker exec 61d5824c720f1a32c cat /etc/hosts ff02::2 ip6-allrouters 10.0.0.1 docker-node 172.17.0.2 61d5824c720f 添加linux功能 linux内核特性，提供权限访问控制。如需要特殊权限，不赋权限容器将不能正常运行。 将容器pid写入一个文件内 bash 1 2 3 4 $ docker run -itd --cidfile /tmp/pid centos 458d9f4b3cc51a4f0f3abffbc78c643b98a89eef3cdfe263e762ac05d3f5f47d $ cat /tmp/pid 458d9f4b3cc51a4f0f3abffbc78c643b98a89eef3cdfe263e762ac05d3f5f47d 将主机列表添加到容器中 bash 1 --device list 设置自定义dns bash 1 2 3 4 5 $ docker run -it centos cat /etc/resolv....

Docker Overlay Network Overlay网络是指在不改变现有网络基础设施的前提下，通过某种约定通信协议，把二层报文封装在IP报文之上的新的数据格式。这样不但能够充分利用成熟的IP路由协议进程数据分发；而且在Overlay技术中采用扩展的隔离标识位数，能够突破VLAN的4000数量限制支持高达16M的用户，并在必要时可将广播流量转化为组播流量，避免广播数据泛滥。 因此，Overlay网络实际上是目前最主流的容器跨节点数据传输和路由方案。 要想使用Docker原生Overlay网络，需要满足下列任意条件 Docker 运行在Swarm 使用键值存储的Docker主机集群 使用键值存储搭建Docker主机集群 使用键值存储的Docker主机集群，需满足下列条件： 集群中主机连接到键值存储，Docker支持 Consul、Etcd和Zookeeper 集群中主机运行一个Docker守护进程 集群中主机必须具有唯一的主机名，因为键值存储使用主机名来标识集群成员 集群中linux主机内核版本在3.12+,支持VXLAN数据包处理，否则可能无法通行 部署docker内置的OverLAY网络 环境准备说明 host ip- node01 10.0.0.15 node02 10.0.0.16 安装Consul 下载地址：Download Consul 启动命令 bash 1 2 3 4 5 6 7 8 consul agent -server -bootstrap -ui -data-dir /data/docker/consul \ -client=10.0.0.16 -bind=10.0.0.16 docker run -d -p 8400:8400 -p 8500:8500 -p 8600:53/udp -h consul progrium/consul -server -bootstrap -ui-dir /ui #-ui : consul 的管理界面 #-data-dir : 数据存储 配置docker链接consul bash 1 2 3 4 5 ExecStart=/usr/bin/dockerd \ -H tcp://0....

一、使用前提 通用镜像未必与应用程序和配置是符合我们需要的。 1.1 常见镜像制作方式 常见制作镜像方式有两种 基于容器 基于镜像制作：编辑一个Dockerfile，而后根据此文件制作； 二、Dockerfile概述 Dockerfile只是构建Docker镜像的源代码，docker可以通过读取Dockerfile中的指令自动构建图像。Dockerfile是一个文本文档，其中包含用户可以在命令行上调用以组合图像的所有命令。用户可以使用 docker build 创建连续执行多个命令行指令的自动构建。 2.1 Dockerfile的工作模式 基于Dockerfile制作镜像时，需在专用目录放置Dockerfile文件，并且文件首字母必须大写。基于Dockerfile中打包的文件必须奇基于工作目录往下走的路径。在打包镜像时，.dockeringore 文件本身与所有包含在 .dockeringore 文件中的路径，都不被打包进去。在Dockerfile制作环境为底层镜像启动容器时所能够提供的环境。 2.2 环境变量替换 制作镜像中还可以使用环境变量。环境变量（使用ENV语句声明）也可以在某些指令中使用，因为Dockerfile环境变量在 Dockerfile 中以 $variable_name 或${variable_name}标记。 语法还支持一些标准`bash修饰符 ${variable:-word} 表示如果设置了变量，那么结果将是该值。如果未设置变量，那么word将是结果。 ${variable+word} 表示如果设置了变量，则word将是结果，否则结果为空字符串。 三、Dockerfile指令说明 特别说明：Dockerfile中每一条指令都会生成一个新的镜像层。 FROM FROM指令（最重要的一个），必须为Dockerfile文件开篇的第一个非注释行，用于为镜像文件构建过程指定基准镜像，后续的指令运行于此基准镜像所提供的运行环境。基准镜像可以是任何可用镜像文件，默认情况下，docker build会在docker主机上查找指定的镜像文件，在其不存在时，则会从 Docker Hub Registry 上拉取所需的镜像文件。如果找不到指定的镜像文件，docker build 会返回一个错误信息 Syntax: sh 1 FROM repository[:tag] sh 1 FROM registry/repository[:tag] bash 1 FROM resository@[digest] #←相同名称时，可以使用resository@镜像hush码指定镜像。 参数 说明- reposotiry 某一个镜像的仓库，如redis镜像仓库。 registry docker镜像仓库，如docker hub，docker registry包含很多reposotiry，如nginx php tomcat等。不指定registry，默认从docker hub下载。 tag image的标签，为可选项，省略时默认为latest。 MAINTANIER(depreacted) MAINTANIER（depreacted）用于让Dockerfile制作者提供本人的详细信息。Dockerfile并不限制MAINTAINER指令可在出现的位置，但推荐将其放置于FROM指令之后。...

使用docker-compose构建LNMP环境 编写Dockerfile 这里采用的是先将nginx php打包为rpm包，然后做成镜像。与直接在容器里编译安装同理的。 nginx Dockerfile bash 1 2 3 4 5 6 7 8 FROM centos MAINTAINER lc RUN yum install -y gcc gcc-c++ openssl-devel make pcre-devel ADD nginx-1.13.9-1.el7.centos.x86_64.rpm /tmp/ RUN cd /tmp/ && rpm -ivh nginx-1.13.9-1.el7.centos.x86_64.rpm ADD nginx.conf /etc/nginx/ EXPOSE 80 CMD ["/usr/sbin/nginx", "-g", "daemon off;"] php Dockerfile bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 FROM centos MAINTAINER LC RUN curl -o /etc/yum....

Compose是一个定义和管理多容器的工具，使用Python语言编写。使用Compose配置文件描述多个容器应用的架构，比如使用 什么镜像、数据卷、网络、映射端口等；然后一条命令管理所有服务，比如启动、停止、重启等。 1、Linux安装Compose 参考网址：Releases · docker/compose · GitHub 下载二进制文件 bash 1 2 3 curl -L \ https://github.com/docker/compose/releases/download/1.22.0/docker-compose-\ `uname -s`-`uname -m` -o /usr/local/bin/docker-compose 对二进制文件添加可执行权限 bash 1 chmod +x /usr/local/bin/docker-compose 测试安装 docker-compose –version 也可以使用pip工具安装：pip install docker-compose 2、使用compose 参考文档：Docker Compose | Docker Documentation compose语法详解：Compose file version 3 reference | Docker Documentation Docker compose file 中文参考文档 - CSDN博客 2.1 Compose常用命令选项 参数 介绍 build 构建或修改Dockerfile后重建服务 config 验证和查看compose文件语法 -q,只验证配置，不输出。 当配置正确时，不输出任何内容，当文件配置错误，输出错误信息。 --services,打印服务名，一行一个 create down 停止和删除容器、网络、卷、镜像，这些内容是通过docker-compose up命令创建的. 默认值删除 容器 网络。 logs 打印compose service日志输出。 ps 打印compose进程，-q只打印pid 更多参数参考：Docker-compose命令详解 - CSDN博客...

对于docker来讲，作为容器运行的底层引擎，在组织及运行容器时每个容器内只运行一个程序及子程序。对于这个容器来讲，启动时依赖于 底层镜像联合挂载启动而成。 底层能够存储此类分层构建并联合挂载镜像的文件系统。最上层构建读写层。对于此读写层来说。所有对容器的操作都保存在最上层之上。而下层内容的操作需要使用写时复制。 Docker镜像由多个只读层叠加而成，启动容器时，Docker会加载只读镜像层并在镜像栈顶部添加一个读写层，如果运行中的容器修改了现有的一个已经存在的文件，那该文件将会从读写层下面的只读层复制到读写层，该文件的只读版本仍然存在，只是已经被读写层中该文件的副本所隐藏，此即 写时复制（COW）机制。此机制对IO较高的应用在实现持久化存储时，势必对在底层应用数据存储时性能要求较高。要想绕过使用限制，可以使用存储卷机制。 Why Data Volume？ 宿主机的主机文件系统直接与容器内部的文件系统之上的某一访问路径建立绑定关系。 在宿主机上目录和容器内文件系统建立绑定关系的目录相对于容器来讲被称为volume。容器内所有有效数据都是保存在存储卷，从而脱离容器自身文件系统。当容器关闭并删除时，只要不删除与宿主机与之绑定的存储目录，就能实现数据脱离容器的生命周期而持久化。docker的存储卷默认情况下使用其所在宿主机之上的本地文件系统目录的。 关闭并重启容器，其数据不受影响；但删除Docker容器，则其更改将会全部丢失 存在的问题 存储于联合文件系统中，不易于宿主机访问； 容器间数据共享不便 删除容器其数据会丢失 解决方案：“卷（volume）” “卷”是容器上的一个或多个“目录”，此类目录可绕过联合文件系统，与宿主机上的某目录“绑定（关联）” 在docker中如果需要动刀存储卷时，不必要手动创建，Volume于容器初始化之时即会创建，由base image提供的卷中的数据会于此期间完成复制 Volume的初衷是独立于容器的生命周期实现数据持久化，因此删除容器之时既不会删除卷，也不会对哪怕未被引用的卷做垃圾回收操作； Data volumes ·卷为docker提供了独立于容器的数据管理机制 ·可以把“镜像”想像成静态文件，例如“程序”，把卷类比为动态内容，例如“数据 “；于是，镜像可以重用，而卷可以共享； ·卷实现了“程序（镜像）”和“数据（卷）”分离，以及“程序（镜像）”和“制作镜像的主机 “分离，用户制作镜像时无须再考虑镜像运行的容器所在的主机的环境； Docker有两种类型的卷，每种类型都在容器中存在一个挂载点，但其在宿主机上的位置有所不同； Bind mount volume 绑定挂载卷 在宿主机指定一个特定路径，在容器内指定一个特定路径，二者已知路径建立关联关系。 a volume that points to a user-specified location on the host file system Docker-managed volume docker管理卷 指定容器内的挂载点，与之关联的是宿主机的目录由docker daemon引擎自行创建空目录，或者使用已存在目录与存储卷路径建立关联关系。 the Docker daemon creates managed volumes in a portion of the host’s file system that’s owned by Docker 在容器中使用Volumes 为docker run命令使用一v选项即可使用Volume...

docker registry介绍 Registry用于保存docker镜像，包括镜像的层次结构和元数据，用户可自建Registry，也可使用官方的Docker Hub 分类 Sponsor Registry：第三方的registry，供客户和Docker社区使用 Mirror Registry：第三方的registry，只让客户使用 Vendor Registry：由发布Docker镜像的供应商提供的registry Private Registry：通过设有防火墙和额外的安全层的私有实体提供的registry 一个docker Registry上拥有两种功能： 提供镜像存储的仓库。 提供用户获取镜像时的认证功能。 同时提供当前服务器上所有可用镜像的搜索索引。 一个docker镜像仓库有仓库的名称，等同于yum的repostory。通常简称为repo。为了使的镜像和应用程序版本之间有意义上的关联关系。在docker一个仓库通常只存放一个应用程序的镜像。因此，这个仓库名就是应用程序名。通过给每个镜像额外添加一个组件叫tag，来标识每一个镜像。通常镜像名称:标签repo_name:tag才能唯一标识一个镜像。 为了可以快速创建registry，docker专门提供了一个程序包 docker-distribution 。https://hub.docker.com/r/distribution/registry/ regustry自身运行在容器中，而容器的文件系统会随着容器生命周期终止而删除，因此需要给registry定义存储卷，使用网络存储。 在yum的extras仓库有一个docker-registry的程序包。docker-distribution的主配置文件在 /etc/docker-distribution/registry/config.yml，所有上传的镜像存放在/var/lib/registry 。 sh 1 2 3 4 5 6 7 8 9 10 11 12 $ yum info docker-registry Available Packages Name : docker-registry Arch : x86_64 Version : 0.9.1 Release : 7.el7 Size : 123 k Repo : extras/7/x86_64 Summary : Registry server for Docker URL : https://github....