1874

摘要： 所谓OOM就是当系统上的应用申请内存资源时，发现申请不到内存，这个时候Linux内核就会启动OOM，内核将给系统上的所有进程进行评分，通过评分得分最高的进程就会被系统第一个干掉，从而腾出一些内存空间，如果腾出的内存空间还是不够该应用使用，它会继续杀得分第二高的，直到应用有足够的内存使用；一旦发生OOM，任何进程都有可能被杀死，包括docker daemon在内，为此，docker特定调整了docker daemon的oom优先级，以免发生oom被内核杀死，但是容器的oom优先级并未做任何调整； 阅读全文

摘要： docker-compose项目是docker官方的开源项目，负责实现对docker容器集群的快速编排；所谓编排我们可以理解为像ansible里面的"剧本"；我们把需要启动的容器，每个容器之间的依赖关系，每个容器的网络、存储等等都定义在一个配置文件中，然后通过一个工具去读取这个配置文件，从而实现快速部署一个应用，方便管理的一个堆docker容器；对于docker-compose来讲，这个配置文件必须交docker-compose.yml，并且通过docker-compose来管理docker容器，它默认就会去找这个配置文件，所以在执行docker-compose命令时，通常我们都是在docker-compose.yml所在目录下执行； 阅读全文

摘要： docker-distribution搭建的仓库非常简陋，它甚至连一个用户认证都没有，更别提多用户；今天我们来介绍另外一款docker仓库工具harbor；harbor这款工具相对docker-distribution来讲功能上丰富了许多；它支持多租户，可扩展的API和web ui ，支持跨多个harbor实例的镜像复制，支持身份集成和基于角色的访问控制等等特征； 阅读全文

摘要： docker仓库就是用来存放镜像的地方；其实docker registry我们理解为存放docker镜像仓库的仓库比较准确吧；因为docker的镜像仓库通常是把同一类的镜像用不同的版本来区别，而registry则是用来存放这些仓库的仓库；默认安装docker都是从dockerhub镜像仓库下载镜像；其实在生产环境中，我们很少去公有仓库上下载镜像，原因之一是公有仓库中的镜像在生产环境中使用，有些不适配，通常我们是去公有仓库下载基础镜像，然后基于基础镜像构建适合自己生产环境中的镜像；其次公有仓库镜像有很多都不是安全的镜像，这么说吧，我们不确定自己下载的镜像是否有后门，是否有挖矿代码，所以基于种种因素，我们还是有必要搭建自己私有的镜像仓库； 阅读全文

摘要： 之所以要延迟多少秒做健康状态检查是因为，docker运行为容器以后，会立刻把该容器的状态标记为running状态，而对于有些初始化比较慢的容器，如果马上对它做健康状态检查，可能是不健康的状态，这样一来我们对了解容器是否健康就不是很准确了；如果配合某些工具，很可能存在检测到容器不健康就把该容器删除，然后重新创建，以此重复；这样就会导致我们的容器启动不起来； 阅读全文

摘要： 用CMD或RUN指令运行命令时，如果直接在CMD或RUN指令后面接命令，这种方式通常会被解释为启动一个shell子进程运行命令，RUN指令表现形式就是后面的命令可以使用shell特性的语法格式的命令，比如大括号展开等等；而CMD指令表现形式就是启动为容器后，它默认会把我们指定运行的命令当作参数传给“/bin/sh”来运行；CMD或RUN指令加中括号的形式就表示使用json数组格式方式运行命令；这种方式运行命令在CMD中表现形式是我们运行的命令的选项都要当作参数传给该命令；RUN指令表现形式是不能使用shell特性的命令；如果非要使用shell特性的命令格式，我们需要把我们的命令当作参数传给“/bin/sh”,当然前提是我们的基础镜像shell支持shell特性的语法； 阅读全文

摘要： dockerfile的格式，dockerfile是一个纯文本文件，我们可以理解为构建镜像的源码；不同于其他编程语言，dockerfile里没有if else 没有循环，它里面仅仅有注释和构建镜像的指令；对于dockerfile注释就是以井号开头的行为注释，这个和shell和其他配置文件的语法一样；除此之外dockerfile里就只有指令了；严格的讲指令是不区分字符大小写的，通常我们约定俗成指令都是纯大写；除此之外在dockerfile的第一非注释行必须是FROM开头来明确的说明我们在基于那个镜像为基础镜像做镜像； 阅读全文

摘要： docker容器把资源抽象成对象；作为客户端，docker这个命令其实就是在对这些抽象出来的资源对象做增删查改的操作；docker的API是RESTful风格的API，所以它支持类似像http协议里的GET、POST、PUT、DELETE等操作；RESTful风格的API有这样的特点；1、每一个URI代表1种资源；2、支持类似http里的GET、POST、PUT、DELETE；GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源；3、通过操作资源的表现形式来操作资源；4、资源的表现形式是XML或者HTML；5、客户端与服务端之间的交互在请求之间是无状态的，从客户端到服务端的每个请求都必须包含理解请求所必需的信息。 阅读全文

摘要： 卷为docker提供了独立于容器的数据管理机制；我们可以把镜像想象成静态文件，例如程序，把卷类比成动态内容，比如数据，于是镜像可以复用，而卷可以共享；卷实现了程序（镜像）和数据（卷）的分离；实现了容器之间的数据共享和复用，使得容器间传递数据变得高效方便；对数据卷内数据的修改会立马生效，无论是在容器中修改还是在本地操作；docker有两种类型的卷，每种类型都在容器中存在一个挂载点，但其在宿主机上的位置有所不同而已；bind mount volume这种卷是由用户指定目录把存储上的一个目录挂载到容器内部的某个目录；docekr-managed volume这种卷是docker自己管理的卷，通常表现形式上把宿主机上的/var/lib/docker/vfs/dir/某个卷的ID 挂载到容器内部某个目录下； 阅读全文

摘要： 默认情况下启动docker容器都是bridge网络，桥接到docker0桥；对于docker容器来讲，各个容器之间的网络上相互隔离的；相互隔离就表示在第一个容器里监听某个端口，对于第二个容器是不可见的；对于宿主机来讲，两个容器的网络都是共享docker0桥的网络；同时在宿主机上的网络名称空间中是可以看到两个容器的虚拟接口是连接到docker0桥的；所以默认情况启动的容器相互之间是可以基于docker0来通信；我们可以把docker0桥理解成连接两个容器的交换机； 阅读全文

摘要： 在docker容器里运行的服务必须前台运行，如果后台运行会导致容器一启动就退出了，原因是容器内部本身就只有一个进程在跑，如果你后台运行，就没有进程在前台，所以docker会认为该容器已经宕机；其实我们可以理解为容器内部前台跑的程序是支撑整个容器为运行态的重要骨架； 阅读全文

摘要： 在docker容器里通常只会有一个进程和该进程的子进程，通常该进程的进程编号为1，这也就说明了如果docker容器里进程编号为1的进程宕了，那么该容器也就随之宕掉；docker的镜像是采用的一种“分层构建，联合挂载”的方式实现；将不同功能的镜像通过一定的层次结构进行挂载，组合成一个新的镜像；在docker启动为容器时，它会在该镜像的最上层加上一个可写层；这使得我们可以在容器内部修改某些数据；而保存修改后的数据只会对当前容器有效，如果在用同一镜像启动为其他容器时，我们修改的数据在后面的容器是不存在的，原因就是镜像的每一层都是只读的；只有镜像运行为容器时才会有一层可写层，而该可写层只针对该容器生效； 阅读全文

摘要： 前一篇博文中主要说了下，lxc容器在Linux上的简单管理，回顾请参考https://www.cnblogs.com/qiuhom-1874/p/12901493.html；今天我们来介绍下lxc的图像管理工具LXC WEB Panel; 　　项目下载地址：https://github.com/lxc-webpanel/LXC-Web-Panel.git； 　　1、安装python-flask 阅读全文

摘要： 什么是容器？在生活中我们常见的容器有各种瓶瓶罐罐、各种能够容纳其它物料的东西叫容器；容器的特点就是有着很好的隔离作用，使得不同的物料互相隔离；除此之外容器还方便运输、方便储存；这是生活中所说的容器，以及它的特点；在计算机领域中，所谓容器不外乎也有同生活中的容器的特点，隔离，方便“运输”（计算机中的运输我们叫移植，从系统A到系统B），方便“存储”（这里指程序以及运行所依赖的库文件打包，即程序及运行时环境打包）； 阅读全文

摘要： 首先我们来看一下haproxy的https的配置；https是什么我这里就不过多阐述了，有关证书的申请相关说明请参考https://www.cnblogs.com/qiuhom-1874/p/12237944.html；在haproxy的配置文件中，我们要明确的声明监听某个端口，该端口需要ssl协议来访问，类似nginx里的listen 443 ssl配置；除此之外我们还需要用crt来指定证书；不同于nginx里的配置是haproxy的证书内容包含私钥信息；所以在我们申请好证书后，还需要把证书文件内容同私钥文件做合并； 阅读全文

摘要： ACL（access control list）翻译过来就是访问控制列表；相信ACL这个词对大家都不是太陌生；Linux里的权限里有ACL，httpd、nginx、varnish里都有ACL的概念；访问控制列表(ACL)的使用提供了一个灵活的解决方案来执行内容切换，并通常根据从请求、响应或任何环境状态提取的内容做出决策。haproxy中访问控制实现和httpd、nginx、varnish中的访问控制类似，都是先扑捉用户的请求报文或响应报文，或者其他环境状态的信息来把客户端分类；然后把该ACL作为条件判断，把不同类别或者说符合我们定义ACL的客户端做其他操作； 阅读全文

摘要： errorloc和errorloc302都是同样的效果，都是以临时重定向到指定的url上；这里还需要注意一点，这两种方式都是跳转前请求的方法是什么，跳转对应url也是同样的方法；这样一来对于其他非GET方法请求出现403错误码的时候，对应的错误页就无法正常处理（通常只允许GET方法去请求别的URL）；比如跳转前用PUT方法，出现错误403后，按照上面的配置，对应指定的错误页的url也会用PUT方法去请求；为了解决这样的问题，我们这里需要用到errorloc303来指定；该指令的意思是返回303响应码；如果请求前非GET方法，而出现对应错误后，用GET方法去请求对应错误状态码指定的URL； 阅读全文

摘要： 作为代理服务器，在完成一次http事务的过程中，报文的流向是这样的；首先用户端的请求会到达haproxy，haproxy收到用户的请求，对其进行拆包分析，然后根据用户请求报文的某些首部的特征，然后模拟用户的请求去请求对应后端server，此时haproxy就扮演着客户端角色去请求后端服务器；后端服务器收到haproxy的请求，然后响应资源内容给haproxy，haproxy收到后端服务器的响应，然后再次拆包，分析，然后封装响应报文响应客户端；在这样的一个过程中，对于客户端的请求报文是否能够到达后端服务器或者后端服务器的响应报文是否能够到达客户端这个需要haproxy说了算 阅读全文

摘要： cookie就是用来让服务端辨识客户端的一种机制；而对于haproxy来讲，基于cookie来做会话保持的原理就是通过对后端服务器响应报文中的cookie信息中插入(或覆盖的方式)一个键值对，在客户端下次访问时，检查对应cookie首部的信息，从而让haproxy能够判断把该请求调度在那个后端服务器上；通常我们会在server上设置一个cookie的值，在listen或backend中设置一个cookie的键，明确说明以怎样的方式设置cookie的键；通过listen或backend中设置的cookie的键结合server后面的cookie的值组成的cookie信息，从而实现不同的cookie信息调度到不同的server上去； 阅读全文

摘要： roundrobin：动态轮询；支持权重的运行时调整，支持慢启动，每个后端中最多支持4095个server；什么意思呢？动态调整权重就是说不重启服务的情况下调整权重；慢启动说的是，前端的流量不会一下子全部给打进来，而是一部分一部分的打到后端服务器上；这样可以有效防止流量过大时一下子把后端服务器压垮的情况；后端最多支持4095个server表示在一个backend或listen中使用该算法最多只能定义4095个server； 阅读全文