坏掉的牙

坏掉的牙 查看完整档案

北京编辑  |  填写毕业院校  |  填写所在公司/组织填写个人主网站
编辑

自己笔记中的内容更新在这里,对一些内容的理解可能存在偏差,希望有什么理解不对的能及时被指出来?

个人动态

坏掉的牙 收藏了文章 · 2020-05-25

tcp的半连接与完全连接队列

队列及参数

图片描述

server端的半连接队列(syn队列)

在三次握手协议中,服务器维护一个半连接队列,该队列为每个客户端的SYN包开设一个条目(服务端在接收到SYN包的时候,就已经创建了request_sock结构,存储在半连接队列中),该条目表明服务器已收到SYN包,并向客户发出确认,正在等待客户的确认包(会进行第二次握手发送SYN+ACK 的包加以确认)。这些条目所标识的连接在服务器处于Syn_RECV状态,当服务器收到客户的确认包时,删除该条目,服务器进入ESTABLISHED状态。
该队列为SYN 队列,长度为 max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog) ,在机器的tcp_max_syn_backlog值在/proc/sys/net/ipv4/tcp_max_syn_backlog下配置。

server端的完全连接队列(accpet队列)

当第三次握手时,当server接收到ACK 报之后, 会进入一个新的叫 accept 的队列,该队列的长度为 min(backlog, somaxconn),默认情况下,somaxconn 的值为 128,表示最多有 129 的 ESTAB 的连接等待 accept(),而 backlog 的值则应该是由 int listen(int sockfd, int backlog) 中的第二个参数指定,listen 里面的 backlog 可以有我们的应用程序去定义的。

当Client发送SYN包之后挂了(syn flood攻击)

Client发送SYN包给Server后挂了,Server回给Client的SYN-ACK一直没收到Client的ACK确认,这个时候这个连接既没建立起来,也不能算失败。这就需要一个超时时间让Server将这个连接断开,否则这个连接就会一直占用Server的SYN连接队列中的一个位置,大量这样的连接就会将Server的SYN连接队列耗尽,让正常的连接无法得到处理。

目前,Linux下默认会进行5次重发SYN-ACK包,重试的间隔时间从1s开始,下次的重试间隔时间是前一次的双倍,5次的重试时间间隔为1s, 2s, 4s, 8s, 16s,总共31s,第5次发出后还要等32s都知道第5次也超时了,所以,总共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 63s,TCP才会把断开这个连接。由于,SYN超时需要63秒,那么就给攻击者一个攻击服务器的机会,攻击者在短时间内发送大量的SYN包给Server(俗称 SYN flood 攻击),用于耗尽Server的SYN队列。对于应对SYN 过多的问题,linux提供了几个TCP参数:tcp_syncookies、tcp_synack_retries、tcp_max_syn_backlog、tcp_abort_on_overflow 来调整应对。

net.ipv4.tcp_synack_retries #内核放弃连接之前发送SYN+ACK包的数量
net.ipv4.tcp_syn_retries #内核放弃建立连接之前发送SYN包的数量

为了应对SYNflooding(即客户端只发送SYN包发起握手而不回应ACK完成连接建立,填满server端的半连接队列,让它无法处理正常的握手请求),Linux实现了一种称为SYNcookie的机制,通过net.ipv4.tcp_syncookies控制,设置为1表示开启。简单说SYNcookie就是将连接信息编码在ISN(initialsequencenumber)中返回给客户端,这时server不需要将半连接保存在队列中,而是利用客户端随后发来的ACK带回的ISN还原连接信息,以完成连接的建立,避免了半连接队列被攻击SYN包填满。

当syn队列满的情况(tcp_abort_on_overflow)

对于SYN半连接队列的大小是由(/proc/sys/net/ipv4/tcp_max_syn_backlog)这个内核参数控制的,有些内核似乎也受listen的backlog参数影响,取得是两个值的最小值。当这个队列满了,不开启syncookies的时候,Server会丢弃新来的SYN包,而Client端在多次重发SYN包得不到响应而返回(connection time out)错误。但是,当Server端开启了syncookies=1,那么SYN半连接队列就没有逻辑上的最大值了,并且/proc/sys/net/ipv4/tcp_max_syn_backlog设置的值也会被忽略。

Client端在多次重发SYN包得不到响应而返回connection time out错误

查看

netstat -s | grep LISTEN
4375 SYNs to LISTEN sockets dropped

当accept队列满的情况

当accept队列满了之后,即使client继续向server发送ACK的包,也会不被响应,此时ListenOverflows+1,同时server通过/proc/sys/net/ipv4/tcp_abort_on_overflow来决定如何返回,0表示直接丢弃该ACK,1表示发送RST通知client;相应的,client则会分别返回read timeout 或者 connection reset by peer

client则会分别返回read timeout 或者 connection reset by peer

查看

root@b5dbe93bcb04:/opt# netstat -s | grep listen
22438 times the listen queue of a socket overflowed

accept队列满了,对 syn队列也有影响,在代码 net/ipv4/tcp_ipv4.c :

int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
{
    /*tcp_syncookies为2 进行syn cookie
      tcp_syncookies为1 且request队列满了 进行syn cookie处理
      tcp_syncookies为0 且request队列满了 将该syn报文drop掉
    */
    if ((sysctl_tcp_syncookies == 2 ||
         inet_csk_reqsk_queue_is_full(sk)) && !isn) {
        want_cookie = tcp_syn_flood_action(sk, skb, "TCP");
        if (!want_cookie)
            goto drop;
    }

    /* Accept backlog is full. If we have already queued enough
     * of warm entries in syn queue, drop request. 
     */
    if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1) {
        NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS);
        goto drop;
}

accept队列大多数情况下会比较小,所以会出现SYN 队列没有满,而ACCEPT 队列满了的情况,此时会按照tcp_aborton_overflow来决定直接丢弃,还是返回拒绝RST。 而如果启用了syncookies,那么syncookies会开启,限制SYN包进入的速度。

当系统丢弃最后的 ACK,而系统中还有一个 net.ipv4.tcp_synack_retries 设置时,Linux 会重新发送 SYN ACK 包。而客户端收到多个 SYN ACK 包,则会认为之前的 ACK 丢包了。于是促使客户端再次发送 ACK ,在 accept队列有空闲的时候最终完成连接。若 accept队列始终满员,则最终客户端收到 RST 包。

doc

查看原文

坏掉的牙 收藏了文章 · 2020-05-25

面试官,不要再问我三次握手和四次挥手

最新发布https://yuanrengu.com/2020/77eef79f.html

三次握手和四次挥手是各个公司常见的考点,也具有一定的水平区分度,也被一些面试官作为热身题。很多小伙伴说这个问题刚开始回答的挺好,但是后面越回答越冒冷汗,最后就歇菜了。

见过比较典型的面试场景是这样的:

面试官:请介绍下三次握手
求职者:第一次握手就是客户端给服务器端发送一个报文,第二次就是服务器收到报文之后,会应答一个报文给客户端,第三次握手就是客户端收到报文后再给服务器发送一个报文,三次握手就成功了。
面试官:然后呢?
求职者:这就是三次握手的过程,很简单的。
面试官:。。。。。。
(番外篇:一首凉凉送给你)

记住猿人谷一句话:面试时越简单的问题,一般就是隐藏着比较大的坑,一般都是需要将问题扩展的。上面求职者的回答不对吗?当然对,但距离面试官的期望可能还有点距离。

希望大家能带着如下问题进行阅读,收获会更大。

  1. 请画出三次握手和四次挥手的示意图
  2. 为什么连接的时候是三次握手?
  3. 什么是半连接队列?
  4. ISN(Initial Sequence Number)是固定的吗?
  5. 三次握手过程中可以携带数据吗?
  6. 如果第三次握手丢失了,客户端服务端会如何处理?
  7. SYN攻击是什么?
  8. 挥手为什么需要四次?
  9. 四次挥手释放连接时,等待2MSL的意义?

三次握手和四次挥手.png

1. 三次握手

三次握手(Three-way Handshake)其实就是指建立一个TCP连接时,需要客户端和服务器总共发送3个包。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口,建立TCP连接,并同步连接双方的序列号和确认号,交换TCP窗口大小信息。

刚开始客户端处于 Closed 的状态,服务端处于 Listen 状态。
进行三次握手:

  • 第一次握手:客户端给服务端发一个 SYN 报文,并指明客户端的初始化序列号 ISN(c)。此时客户端处于 SYN_SENT 状态。

    首部的同步位SYN=1,初始序号seq=x,SYN=1的报文段不能携带数据,但要消耗掉一个序号。

  • 第二次握手:服务器收到客户端的 SYN 报文之后,会以自己的 SYN 报文作为应答,并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值,表示自己已经收到了客户端的 SYN,此时服务器处于 SYN_RCVD 的状态。

    在确认报文段中SYN=1,ACK=1,确认号ack=x+1,初始序号seq=y。

  • 第三次握手:客户端收到 SYN 报文之后,会发送一个 ACK 报文,当然,也是一样把服务器的 ISN + 1 作为 ACK 的值,表示已经收到了服务端的 SYN 报文,此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后,也处于 ESTABLISHED 状态,此时,双方已建立起了连接。

    确认报文段ACK=1,确认号ack=y+1,序号seq=x+1(初始为seq=x,第二个报文段所以要+1),ACK报文段可以携带数据,不携带数据则不消耗序号。

发送第一个SYN的一端将执行主动打开(active open),接收这个SYN并发回下一个SYN的另一端执行被动打开(passive open)。

在socket编程中,客户端执行connect()时,将触发三次握手。

三次握手.png

1.1 为什么需要三次握手,两次不行吗?

弄清这个问题,我们需要先弄明白三次握手的目的是什么,能不能只用两次握手来达到同样的目的。

  • 第一次握手:客户端发送网络包,服务端收到了。
    这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的。
  • 第二次握手:服务端发包,客户端收到了。
    这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
  • 第三次握手:客户端发包,服务端收到了。
    这样服务端就能得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常。

因此,需要三次握手才能确认双方的接收与发送能力是否正常。

试想如果是用两次握手,则会出现下面这种情况:

如客户端发出连接请求,但因连接请求报文丢失而未收到确认,于是客户端再重传一次连接请求。后来收到了确认,建立了连接。数据传输完毕后,就释放了连接,客户端共发出了两个连接请求报文段,其中第一个丢失,第二个到达了服务端,但是第一个丢失的报文段只是在某些网络结点长时间滞留了,延误到连接释放以后的某个时间才到达服务端,此时服务端误认为客户端又发出一次新的连接请求,于是就向客户端发出确认报文段,同意建立连接,不采用三次握手,只要服务端发出确认,就建立新的连接了,此时客户端忽略服务端发来的确认,也不发送数据,则服务端一致等待客户端发送数据,浪费资源。

1.2 什么是半连接队列?

服务器第一次收到客户端的 SYN 之后,就会处于 SYN_RCVD 状态,此时双方还没有完全建立其连接,服务器会把此种状态下请求连接放在一个队列里,我们把这种队列称之为半连接队列

当然还有一个全连接队列,就是已经完成三次握手,建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

这里在补充一点关于SYN-ACK 重传次数的问题:
服务器发送完SYN-ACK包,如果未收到客户确认包,服务器进行首次重传,等待一段时间仍未收到客户确认包,进行第二次重传。如果重传次数超过系统规定的最大重传次数,系统将该连接信息从半连接队列中删除。
注意,每次重传等待的时间不一定相同,一般会是指数增长,例如间隔时间为 1s,2s,4s,8s......

1.3 ISN(Initial Sequence Number)是固定的吗?

当一端为建立连接而发送它的SYN时,它为连接选择一个初始序号。ISN随时间而变化,因此每个连接都将具有不同的ISN。ISN可以看作是一个32比特的计数器,每4ms加1 。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送,而导致某个连接的一方对它做错误的解释。

三次握手的其中一个重要功能是客户端和服务端交换 ISN(Initial Sequence Number),以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果 ISN 是固定的,攻击者很容易猜出后续的确认号,因此 ISN 是动态生成的。

1.4 三次握手过程中可以携带数据吗?

其实第三次握手的时候,是可以携带数据的。但是,第一次、第二次握手不可以携带数据

为什么这样呢?大家可以想一个问题,假如第一次握手可以携带数据的话,如果有人要恶意攻击服务器,那他每次都在第一次握手中的 SYN 报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常,然后疯狂着重复发 SYN 报文的话,这会让服务器花费很多时间、内存空间来接收这些报文。

也就是说,第一次握手不可以放数据,其中一个简单的原因就是会让服务器更加容易受到攻击了。而对于第三次的话,此时客户端已经处于 ESTABLISHED 状态。对于客户端来说,他已经建立起连接了,并且也已经知道服务器的接收、发送能力是正常的了,所以能携带数据也没啥毛病。

1.5 SYN攻击是什么?

服务器端的资源分配是在二次握手时分配的,而客户端的资源是在完成三次握手时分配的,所以服务器容易受到SYN洪泛攻击。SYN攻击就是Client在短时间内伪造大量不存在的IP地址,并向Server不断地发送SYN包,Server则回复确认包,并等待Client确认,由于源地址不存在,因此Server需要不断重发直至超时,这些伪造的SYN包将长时间占用未连接队列,导致正常的SYN请求因为队列满而被丢弃,从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。

检测 SYN 攻击非常的方便,当你在服务器上看到大量的半连接状态时,特别是源IP地址是随机的,基本上可以断定这是一次SYN攻击。在 Linux/Unix 上可以使用系统自带的 netstats 命令来检测 SYN 攻击。

netstat -n -p TCP | grep SYN_RECV

常见的防御 SYN 攻击的方法有如下几种:

  • 缩短超时(SYN Timeout)时间
  • 增加最大半连接数
  • 过滤网关防护
  • SYN cookies技术

2. 四次挥手

建立一个连接需要三次握手,而终止一个连接要经过四次挥手(也有将四次挥手叫做四次握手的)。这由TCP的半关闭(half-close)造成的。所谓的半关闭,其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。

TCP 的连接的拆除需要发送四个包,因此称为四次挥手(Four-way handshake),客户端或服务器均可主动发起挥手动作。

刚开始双方都处于 ESTABLISHED 状态,假如是客户端先发起关闭请求。四次挥手的过程如下:

  • 第一次挥手:客户端发送一个 FIN 报文,报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。
    即发出连接释放报文段(FIN=1,序号seq=u),并停止再发送数据,主动关闭TCP连接,进入FIN_WAIT1(终止等待1)状态,等待服务端的确认。
  • 第二次挥手:服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 +1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于 CLOSE_WAIT 状态。
    即服务端收到连接释放报文段后即发出确认报文段(ACK=1,确认号ack=u+1,序号seq=v),服务端进入CLOSE_WAIT(关闭等待)状态,此时的TCP处于半关闭状态,客户端到服务端的连接释放。客户端收到服务端的确认后,进入FIN_WAIT2(终止等待2)状态,等待服务端发出的连接释放报文段。
  • 第三次挥手:如果服务端也想断开连接了,和客户端的第一次挥手一样,发给 FIN 报文,且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
    即服务端没有要向客户端发出的数据,服务端发出连接释放报文段(FIN=1,ACK=1,序号seq=w,确认号ack=u+1),服务端进入LAST_ACK(最后确认)状态,等待客户端的确认。
  • 第四次挥手:客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答,且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值,此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态,服务端收到 ACK 报文之后,就处于关闭连接了,处于 CLOSED 状态。
    即客户端收到服务端的连接释放报文段后,对此发出确认报文段(ACK=1,seq=u+1,ack=w+1),客户端进入TIME_WAIT(时间等待)状态。此时TCP未释放掉,需要经过时间等待计时器设置的时间2MSL后,客户端才进入CLOSED状态。

收到一个FIN只意味着在这一方向上没有数据流动。客户端执行主动关闭并进入TIME_WAIT是正常的,服务端通常执行被动关闭,不会进入TIME_WAIT状态。

在socket编程中,任何一方执行close()操作即可产生挥手操作。
image.png

2.1 挥手为什么需要四次?

因为当服务端收到客户端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当服务端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉客户端,"你发的FIN报文我收到了"。只有等到我服务端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四次挥手。

2.2 2MSL等待状态

TIME_WAIT状态也成为2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL(Maximum Segment Lifetime),它是任何报文段被丢弃前在网络内的最长时间。这个时间是有限的,因为TCP报文段以IP数据报在网络内传输,而IP数据报则有限制其生存时间的TTL字段。

对一个具体实现所给定的MSL值,处理的原则是:当TCP执行一个主动关闭,并发回最后一个ACK,该连接必须在TIME_WAIT状态停留的时间为2倍的MSL。这样可让TCP再次发送最后的ACK以防这个ACK丢失(另一端超时并重发最后的FIN)。

这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间,定义这个连接的插口(客户的IP地址和端口号,服务器的IP地址和端口号)不能再被使用。这个连接只能在2MSL结束后才能再被使用。

2.3 四次挥手释放连接时,等待2MSL的意义?

MSL是Maximum Segment Lifetime的英文缩写,可译为“最长报文段寿命”,它是任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃。

为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失,从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK,接着客户端再重传一次确认,重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL,而是在发送完ACK之后直接释放关闭,一但这个ACK丢失的话,服务器就无法正常的进入关闭连接状态。

两个理由:

  1. 保证客户端发送的最后一个ACK报文段能够到达服务端。
    这个ACK报文段有可能丢失,使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认,服务端超时重传FIN+ACK报文段,而客户端能在2MSL时间内收到这个重传的FIN+ACK报文段,接着客户端重传一次确认,重新启动2MSL计时器,最后客户端和服务端都进入到CLOSED状态,若客户端在TIME-WAIT状态不等待一段时间,而是发送完ACK报文段后立即释放连接,则无法收到服务端重传的FIN+ACK报文段,所以不会再发送一次确认报文段,则服务端无法正常进入到CLOSED状态。
  2. 防止“已失效的连接请求报文段”出现在本连接中。
    客户端在发送完最后一个ACK报文段后,再经过2MSL,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失,使下一个新的连接中不会出现这种旧的连接请求报文段。

2.4 为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态?

理论上,四个报文都发送完毕,就可以直接进入CLOSE状态了,但是可能网络是不可靠的,有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文

3. 总结

《TCP/IP详解 卷1:协议》有一张TCP状态变迁图,很具有代表性,有助于大家理解三次握手和四次挥手的状态变化。如下图所示,粗的实线箭头表示正常的客户端状态变迁,粗的虚线箭头表示正常的服务器状态变迁。

TCP状态变迁图.jpg

以后面试官再问你三次握手和四次挥手,直接把这一篇文章丢给他就可以了,他想问的都在这里。

参考:《TCP/IP详解 卷1:协议》

欢迎关注猿人谷.png

查看原文

坏掉的牙 赞了回答 · 2019-07-23

redis 的 monitor 的信息能过滤吗?

redis-cli -h IP monitor |grep 'xxx'

关注 3 回答 2

坏掉的牙 收藏了文章 · 2019-06-17

搭建 etcd 集群 - 暴走漫画容器实践系列 Part3

etcd 是一个高可用的分布式 key-value(键值) 存储系统。在暴漫我们用他用来做配置管理和服务发现。

这一次我们主要介绍关于 etcd 集群的搭建与管理。

1. etcd 集群概述

首先我们需要理解,etcd 是一个分布式的 key-value 存储系统,所以其基本原理和前面我们介绍过的
分布式数据库相关理论 是一致的。

两种不同的 node(节点)

值得注意的是,为了方便使用,etcd 引入了 proxy 的概念,所以 etcd 的节点分为两种:集群节点代理节点

集群节点代理节点 在使用上几乎没有任何区别。这使得我们可以在每台机器上都安装 etcd,进而把 etcd 当作本地服务来使用(通过 0.0.0.0)。
他们的区别在于:内部原理不同。
集群节点是真正的 etcd 集群的构成者,这些节点负责数据存取,集群管理等等。
代理节点可以理解为一个反向代理,它只是简单的接受请求,转发请求给 etcd 集群。

集群大小与容错

集群的大小指集群节点的个数。根据 etcd 的分布式数据冗余策略,集群节点越多,容错能力(Failure Tolerance)越强,同时写性能也会越差。
所以关于集群大小的优化,其实就是容错和写性能的一个平衡。

另外, etcd 推荐使用 奇数 作为集群节点个数。因为奇数个节点与和其配对的偶数个节点相比(比如 3节点和4节点对比),
容错能力相同,却可以少一个节点。

所以综合考虑性能和容错能力,etcd 官方文档推荐的 etcd 集群大小是 3, 5, 7。至于到底选择 3,5 还是 7,根据需要的容错能力而定。

关于节点数和容错能力对应关系,如下表所示:

集群大小最大容错
10
31
41
52
62
73
83
94

2. etcd 集群的搭建(初始化一个 etcd 集群)

这里说的搭建指“从无到有”搭建。关于在已有集群中添加减少集群节点,属于下面"第3节:etcd 集群的管理"的内容。

etcd 集群的搭建有三种方式,包括:static 方式,etcd discovery 方式 和 DNS discovery。

这里,我们以一个例子来讲解 etcd 集群各种方式的搭建。假设我们需要搭建一个3节点的 etcd 集群。这三个节点的 name(我们需要给每个节点取个名字)和 ip 分别是:

nameip
etcd010.0.0.10
etcd110.0.0.11
etcd210.0.0.12

2.1 static 方式

static 方式是最简单的一种搭建 etcd 的方式。
不像其他两种方式, static 方式不需要任何额外的服务,只需要你知道你准备用来运行 etcd 的所有节点(的name和ip)。

本例中,我们来看看如何在3个节点上构建 etcd 集群。

首先我们需要构造一个描述集群所有节点的参数,这个参数可以以命令行参数的方式传给 etcd 程序,也可以以环境变量的方式

如果用命令行参数,应该将下列参数附在 etcd 的启动命令后面:

-initial-cluster etcd0=http://10.0.1.10:2380,etcd1=http://10.0.1.11:2380,etcd2=http://10.0.1.12:2380 \
  -initial-cluster-state new

其中 -initial-cluster-state new 表示这是在从无到有搭建 etcd 集群。
-initial-cluster 参数描述了这个新集群中总共有哪些节点,其中每个节点用 name=ip的形式描述,节点之间用,分隔。

如果用环境变量,应该在启动 etcd 时,加入如下环境变量:

ETCD_INITIAL_CLUSTER="etcd0=http://10.0.1.10:2380,etcd1=http://10.0.1.11:2380,etcd2=http://10.0.1.12:2380"
ETCD_INITIAL_CLUSTER_STATE=new

ETCD_INITIAL_CLUSTER 变量和 -initial-cluster 作用相同,
ETCD_INITIAL_CLUSTER_STATE 变量和 -initial-cluster-state 作用相同。

接着,分别在3个节点上启动 etcd,以命令行参数方式启动为例:

$ etcd -name etcd0 -initial-advertise-peer-urls http://10.0.1.10:2380 \
  -listen-peer-urls http://10.0.1.10:2380 \
  -listen-client-urls http://10.0.1.10:2379,http://127.0.0.1:2379 \
  -advertise-client-urls http://10.0.1.10:2379 \
  -initial-cluster-token my-etcd-cluster \
  -initial-cluster etcd0=http://10.0.1.10:2380,etcd1=http://10.0.1.11:2380,etcd2=http://10.0.1.12:2380 \
  -initial-cluster-state new
$ etcd -name etcd1 -initial-advertise-peer-urls http://10.0.1.11:2380 \
  -listen-peer-urls http://10.0.1.11:2380 \
  -listen-client-urls http://10.0.1.11:2379,http://127.0.0.1:2379 \
  -advertise-client-urls http://10.0.1.11:2379 \
  -initial-cluster-token my-etcd-cluster \
  -initial-cluster etcd0=http://10.0.1.10:2380,etcd1=http://10.0.1.11:2380,etcd2=http://10.0.1.12:2380 \
  -initial-cluster-state new
$ etcd -name etcd2 -initial-advertise-peer-urls http://10.0.1.12:2380 \
  -listen-peer-urls http://10.0.1.12:2380 \
  -listen-client-urls http://10.0.1.12:2379,http://127.0.0.1:2379 \
  -advertise-client-urls http://10.0.1.12:2379 \
  -initial-cluster-token my-etcd-cluster \
  -initial-cluster etcd0=http://10.0.1.10:2380,etcd1=http://10.0.1.11:2380,etcd2=http://10.0.1.12:2380 \
  -initial-cluster-state new

注意

值得注意的是,无论是 -initial-cluster参数,还是对应的环境变量,只有在第一次启动 etcd 的时候才起作用。
之后如果重启 etcd,这个参数或环境变量会被自动忽略。所以当成功初始化了一个 etcd 集群以后,你就不在需要这个参数或环境变量了。

2.2 etcd discovery 方式

很多时候,你只知道你要搭建一个多大(包含多少节点)的集群,但是并不能事先知道这几个节点的 ip,从而无法使用 -initial-cluster 参数。
这个时候,你就需要使用 discovery 的方式来搭建 etcd 集群。discovery 方式有两种:etcd discoveryDNS discovery

这里我们先介绍下 etcd discovery 方式,etcd discovery 有两种:自定义的 etcd discovery公共 etcd discovery

2.2.1 自定义的 etcd discovery 服务

这种方式就是利用一个已有的 etcd 集群来提供 discovery 服务,从而搭建一个新的 etcd 集群。

假设已有的 etcd 集群的一个访问地址是:myetcd.local,那么我们首先需要在已有 etcd 中创建一个特殊的 key,方法如下:

$ curl -X PUT https://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83/_config/size -d value=3

其中 value=3 表示本集群的大小,即: 有多少集群节点。而 6c007a14875d53d9bf0ef5a6fc0257c817f0fb83 就是用来做 discovery 的 token。

接下来你在 3 个节点上分别启动 etcd 程序,并加上刚刚的 token。
加 token 的方式同样也有 命令行参数环境变量 两种。

命令行参数:

-discovery https://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83

环境变量

ETCD_DISCOVERY=https://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83

命令行参数启动方式为例:

$ etcd -name etcd0 -initial-advertise-peer-urls http://10.0.1.10:2380 \
  -listen-peer-urls http://10.0.1.10:2380 \
  -listen-client-urls http://10.0.1.10:2379,http://127.0.0.1:2379 \
  -advertise-client-urls http://10.0.1.10:2379 \
  -discovery https://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83
$ etcd -name etcd1 -initial-advertise-peer-urls http://10.0.1.11:2380 \
  -listen-peer-urls http://10.0.1.11:2380 \
  -listen-client-urls http://10.0.1.11:2379,http://127.0.0.1:2379 \
  -advertise-client-urls http://10.0.1.11:2379 \
  -discovery https://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83
$ etcd -name etcd2 -initial-advertise-peer-urls http://10.0.1.12:2380 \
  -listen-peer-urls http://10.0.1.12:2380 \
  -listen-client-urls http://10.0.1.12:2379,http://127.0.0.1:2379 \
  -advertise-client-urls http://10.0.1.12:2379 \
  -discovery https://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83

2.2.2 公共 etcd discovery 服务

如果没有已有的 etcd 集群,也可以用 etcd 提供的公共服务: discovery.etcd.io
步骤和 2.2.1 节基本一致。

你得先创建一个用于 discovery 的 token,创建方式如下:

$ curl https://discovery.etcd.io/new?size=3

返回:

https://discovery.etcd.io/3e86b59982e49066c5d813af1c2e2579cbf573de

返回值作为启动节点时的 -discovery 参数或者 ETCD_DISCOVERY环境变量的值。

环境变量启动方式为例:

$ ETCD_DISCOVERY=https://discovery.etcd.io/3e86b59982e49066c5d813af1c2e2579cbf573de \
etcd -name etcd0 -initial-advertise-peer-urls http://10.0.1.10:2380 \
  -listen-peer-urls http://10.0.1.10:2380 \
  -listen-client-urls http://10.0.1.10:2379,http://127.0.0.1:2379 \
  -advertise-client-urls http://10.0.1.10:2379 \
  -discovery https://discovery.etcd.io/3e86b59982e49066c5d813af1c2e2579cbf573de
$ ETCD_DISCOVERY=https://discovery.etcd.io/3e86b59982e49066c5d813af1c2e2579cbf573de \
etcd -name etcd1 -initial-advertise-peer-urls http://10.0.1.11:2380 \
  -listen-peer-urls http://10.0.1.11:2380 \
  -listen-client-urls http://10.0.1.11:2379,http://127.0.0.1:2379 \
  -advertise-client-urls http://10.0.1.11:2379 \
  -discovery https://discovery.etcd.io/3e86b59982e49066c5d813af1c2e2579cbf573de
$ ETCD_DISCOVERY=https://discovery.etcd.io/3e86b59982e49066c5d813af1c2e2579cbf573de \
etcd -name etcd2 -initial-advertise-peer-urls http://10.0.1.12:2380 \
  -listen-peer-urls http://10.0.1.12:2380 \
  -listen-client-urls http://10.0.1.12:2379,http://127.0.0.1:2379 \
  -advertise-client-urls http://10.0.1.12:2379 \
  -discovery https://discovery.etcd.io/3e86b59982e49066c5d813af1c2e2579cbf573de

2.2.3 注意点

值得注意的是:如果实际启动的 etcd 节点个数大于 discovery token创建时指定的size
多余的节点会自动变为 proxy 节点。

2.3 DNS discovery 方式

这个方式没有实践,而且对于一般团队实用性也不高,所以就不做分享了。

2.4 后续

到这里为止,我们已经有一个3节点的 etcd 集群了,下一篇博客我会介绍如何进行 etcd 集群的管理

--

更多文章欢迎关注自由风暴博客

查看原文

坏掉的牙 发布了文章 · 2019-04-13

关于php trim方法的错误理解导致的问题

场景

php中的截取字符串前后字符包括有:ltrim,rtrim,trim三个方法

下面的例子中只以ltrim方法做举例
在我之前的认知中(当然我很水,从没看过这块源码),如果我想要删除字符串左边的空字符串,空制表符之类的,那么我就直接使用ltrim($str)即可

如果我想要删除指定字符的时候,比如说现在有个字符串helloworld,我要截取掉头部的h字符,直接var_dump(ltrim("helloworld", "h"));即可得到我期望的结果输出elloworld
以上的都是在我以为的范围内,我也一直都是这么使用的,直到有一次我们有个需求要在一些字符串上做openssl_encrypt加密,加密之后做个base64,然后拼接上我们的特殊的字符串前缀KO:,每次加密完成后拼接KO:字符,同样的,解密之前先把KO:拆出去在解密,结果发现解密怎么解都是失败,后来打了几个断点发现是ltrim的时候和预期结果不一样

复现

<?php
// 以下做一个简单的情景复现

$str = "abccabdefg";
$character_mask = “abc”;    

var_dump(ltrim($str,  $character_mask));    // 输出结果为 bdefg,而不是只截取前三位的abc

原因分析

经过上面的小demo,大家应该就知道原因是啥了,说的最简单通俗的就是它把前面的$str做一个轮训,一个字符一个字符的在后面的$character_mask里面看是不是在其中,如果是的话则进行截取,不在的话停止运行
ltrim代码形式的表达:

<?php 

$str = "abcccabdecbag";

$res = '';
$character_mask = 'abc';

$arrStr = str_split($str);        // 字符串转数组

for ($i=0; $i<=count($arrStr); $i++) {
        if(strpos($character_mask, $arrStr[$i]) !== false) {
                unset($arrStr[$i]);
        } else {
                break;
        }
}

echo ltrim($str, $character_mask);
echo "\r\n";
echo implode($arrStr);
echo "\r\n";

解决方案

解决方案就是使用php中的一些操作字符串函数,多加了基层判断

  if (substr($str, 0, strlen($character_mask)) == $character_mask) {
            echo substr($str, strlen($character_mask));
  }
查看原文

赞 2 收藏 2 评论 0

坏掉的牙 评论了文章 · 2019-04-13

关于php数据库事务的一个坑

在使用php的PDO扩展的时候发现的一个问题,在事务开启之后,如果php与mysql之间的连接断开了,会导致php直接记录一个warning的异常,而不是直接抛出一个Exception

流程如下:

/**
 * 一个用户财产变更的场景下
 */

try {
    // 1. 开启事务

    /**
     * 2. 变更用户财产,增加财产变更的流水记录
     */

    // 3. 提交事务
} catch (\Exception $e) {
    // 4. 回滚事务

    // 5. 记错误日志

    // 6. 抛出异常
}

// 7. 发布用户财产变更的广播

以上的操作可以简单的分成五类,在以前我的认知当中,操作事务的大致流程就是上面的样子,没有异常抛出则事务就是提交成功了的
但是直到有一天数据库异常,有一个事务已经开启了,处在上面的1-2的过程当中,数据库直接挂掉,那么在步骤3提交事务的时候会直接出现一个warning级别的错误,"SQLSTATE[HY000]: General error: 2006 MySQL server has gone away" ,没有捕获到异常
所以在步骤7的后续步骤中,其他业务方拿到了那条没有提交的流水id并进行了统计,但是实际上用户的财产并没有增加。从而导致了问题

百思不得其解的时候去看了下文档,发现了一个历史遗留很久的bug:https://bugs.php.net/bug.php?...

后来我们通过临时在事务的位置配置了set_error_handler解决了问题

查看原文

坏掉的牙 发布了文章 · 2019-04-12

关于php数据库事务的一个坑

在使用php的PDO扩展的时候发现的一个问题,在事务开启之后,如果php与mysql之间的连接断开了,会导致php直接记录一个warning的异常,而不是直接抛出一个Exception

流程如下:

/**
 * 一个用户财产变更的场景下
 */

try {
    // 1. 开启事务

    /**
     * 2. 变更用户财产,增加财产变更的流水记录
     */

    // 3. 提交事务
} catch (\Exception $e) {
    // 4. 回滚事务

    // 5. 记错误日志

    // 6. 抛出异常
}

// 7. 发布用户财产变更的广播

以上的操作可以简单的分成五类,在以前我的认知当中,操作事务的大致流程就是上面的样子,没有异常抛出则事务就是提交成功了的
但是直到有一天数据库异常,有一个事务已经开启了,处在上面的1-2的过程当中,数据库直接挂掉,那么在步骤3提交事务的时候会直接出现一个warning级别的错误,"SQLSTATE[HY000]: General error: 2006 MySQL server has gone away" ,没有捕获到异常
所以在步骤7的后续步骤中,其他业务方拿到了那条没有提交的流水id并进行了统计,但是实际上用户的财产并没有增加。从而导致了问题

百思不得其解的时候去看了下文档,发现了一个历史遗留很久的bug:https://bugs.php.net/bug.php?...

后来我们通过临时在事务的位置配置了set_error_handler解决了问题

查看原文

赞 7 收藏 6 评论 2

坏掉的牙 赞了文章 · 2019-04-10

30 分钟快速入门 Docker 教程

原文地址:梁桂钊的博客

博客地址:http://blog.720ui.com

欢迎关注公众号:「服务端思维」。一群同频者,一起成长,一起精进,打破认知的局限性。

30 分钟快速入门 Docker 教程

一、欢迎来到 Docker 世界

1. Docker 与虚拟化

在没有 Docker 的时代,我们会使用硬件虚拟化(虚拟机)以提供隔离。这里,虚拟机通过在操作系统上建立了一个中间虚拟软件层 Hypervisor ,并利用物理机器的资源虚拟出多个虚拟硬件环境来共享宿主机的资源,其中的应用运行在虚拟机内核上。但是,虚拟机对硬件的利用率存在瓶颈,因为虚拟机很难根据当前业务量动态调整其占用的硬件资源,因此容器化技术得以流行。其中,Docker 是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的 Linux 机器上。

image.png

Docker 容器不使用硬件虚拟化,它的守护进程是宿主机上的一个进程,换句话说,应用直接运行在宿主机内核上。因为容器中运行的程序和计算机的操作系统之间没有额外的中间层,没有资源被冗余软件的运行或虚拟硬件的模拟而浪费掉。

Docker 的优势不仅如此,我们来比较一番。

特性Docker虚拟机
启动速度秒级分钟级
交付/部署开发、测试、生产环境一致无成熟体系
性能近似物理机性能损耗大
体量极小(MB)较大(GB)
迁移/扩展跨平台,可复制较为复杂

2. 镜像、容器和仓库

Docker 由镜像(Image)、容器(Container)、仓库(Repository) 三部分组成。

Docker 的镜像可以简单的类比为电脑装系统用的系统盘,包括操作系统,以及必要的软件。例如,一个镜像可以包含一个完整的 centos 操作系统环境,并安装了 Nginx 和 Tomcat 服务器。注意的是,镜像是只读的。这一点也很好理解,就像我们刻录的系统盘其实也是可读的。我们可以使用 docker images 来查看本地镜像列表。

Docker 的容器可以简单理解为提供了系统硬件环境,它是真正跑项目程序、消耗机器资源、提供服务的东西。例如,我们可以暂时把容器看作一个 Linux 的电脑,它可以直接运行。那么,容器是基于镜像启动的,并且每个容器都是相互隔离的。注意的是,容器在启动的时候基于镜像创建一层可写层作为最上层。我们可以使用 docker ps -a 查看本地运行过的容器。

Docker 的仓库用于存放镜像。这一点,和 Git 非常类似。我们可以从中心仓库下载镜像,也可以从自建仓库下载。同时,我们可以把制作好的镜像 commit 到本地,然后 push 到远程仓库。仓库分为公开仓库和私有仓库,最大的公开仓库是官方仓库 Dock Hub,国内的公开仓库也有很多选择,例如阿里云等。

image.png

3. Docker 促使开发流程变更

笔者认为,Docker 对开发流程的影响在于使环境标准化。例如,原来我们存在三个环境:开发(日常)环境、测试环境、生产环境。这里,我们对于每个环境都需要部署相同的软件、脚本和运行程序,如图所示。事实上,对于启动脚本内容都是一致的,但是没有统一维护,经常会出问题。此外,对于运行程序而言,如果所依赖的底层运行环境不一致,也会造成困扰和异常。

image.png

现在,我们通过引入 Docker 之后,我们只需要维护一个 Docker 镜像。换句话说,多套环境,一个镜像,实现系统级别的一次构建到处运行。此时,我们把运行脚本标准化了,把底层软件镜像化了,然后对于相同的将要部署的程序实行标准化部署。因此,Docker 为我们提供了一个标准化的运维模式,并固化运维步骤和流程。

image.png

通过这个流程的改进,我们更容易实现 DevOps 的目标,因为我们的镜像生成后可以跑在任何系统,并快速部署。此外,使用 Docker 的很大动力是基于 Docker 实现弹性调度,以更充分地利用机器资源,节省成本。

哈哈,笔者在使用 Docker 过程中,还发现了一些很棒的收益点,例如我们发布回滚的时候只需要切换 TAG 并重启即可。还比如,我们对环境升级,也只需要升级基础镜像,那么新构建的应用镜像,自动会引用新的版本。(欢迎补充~~~)

二、从搭建 Web 服务器开始说起

1. 环境先行,安装 Docker

现在,我们需要安装以下步骤安装 Docker。

官方下载地址:(Mac):https://download.docker.com/mac/stable/Docker.dmg
阿里云下载地址(Mac):http://mirrors.aliyun.com/docker-toolbox/mac/docker-for-mac/
阿里云下载地址(Windows): http://mirrors.aliyun.com/docker-toolbox/windows/docker-for-windows/
  • 安装指南

这里,双击刚刚下载的 Doker.dmg 安装包进行安装。
image.png

安装完成后启动, Mac 顶部导航栏出现了一个图标,通过菜单可以进行 docker 配置和退出等操作。

image.png

官方指南:https://docs.docker.com/install/
阿里云指南(Linux):https://yq.aliyun.com/articles/110806?spm=5176.8351553.0.0.468b1991jdT95t
  • 设置加速服务

市面上有很多加速服务的提供商,如:DaoCloud,阿里云等。这里,笔者使用的是阿里云。(注意的是,笔者操作系统是 Mac,其他操作系列参见阿里云操作文档) 

image.png

右键点击桌面顶栏的 docker 图标,选择 Preferences ,在 Daemon 标签(Docker 17.03 之前版本为 Advanced 标签)下的 Registry mirrors 列表中将
https://xxx.mirror.aliyuncs.com 加到"registry-mirrors"的数组里,点击 Apply & Restart 按钮,等待 Docker 重启并应用配置的镜像加速器。

image.png

阿里云操作文档:https://cr.console.aliyun.com/cn-hangzhou/instances/mirrors
  • 查看版本

至此,我们已经安装完成了。这里,我们来查看版本。

docker version

查看结果,如下所示。

image.png

2. 实干派,从搭建 Web 服务器开始

我们作为实干派,那么先来搭建一个 Web 服务器吧。然后,笔者带你慢慢理解这个过程中,做了什么事情。首先,我们需要拉取 centos 镜像。

docker run -p 80 --name web -i -t centos /bin/bash

紧接着,我们安装 nginx 服务器,执行以下命令:

rpm -ivh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm

安装完 Nginx 源后,就可以正式安装 Nginx 了。

yum install -y nginx

至此,我们再输入 whereis nginx 命令就可以看到安装的路径了。最后,我们还需要将 Nginx 跑起来。

nginx

现在,我们执行 ctrl + P +  Q 切换到后台。然后,通过 docker ps -a 来查看随机分配的端口。

image.png

这里,笔者分配的端口是 32769 ,那么通过浏览器访问 http://127.0.0.1:32769 即可。

image.png

大功告成,哈哈哈~

3. 复盘理解全过程

现在,我们来理解下这个流程。首先,我们输入 docker run -p 80 --name web -i -t centos /bin/bash 命令会运行交互式容器,其中 -i 选项告诉 Docker 容器保持标准输入流对容器开放,即使容器没有终端连接,另一个 -t 选项告诉 Docker 为容器分配一个虚拟终端,以便于我们接下来安装 Nginx 服务器。(笔者备注:Docker 还支持输入 -d 选项告诉 Docker 在后台运行容器的守护进程)

Docker 会为我们创建的每一个容器自动生成一个随机的名称。事实上,这种方式虽然便捷,但是可读性很差,并且对我们后期维护的理解成本会比较大。因此,我们通过 --name web 选项告诉 Docker 创建一个名称是 web 的容器。此外,我们通过 -p 80 告诉 Docker 开放 80 端口,那么, Nginx 才可以对外通过访问和服务。但是,我们的宿主机器会自动做端口映射,比如上面分配的端口是 32769 ,注意的是,如果关闭或者重启,这个端口就变了,那么怎么解决固定端口的问题,笔者会在后面详细剖析和带你实战。

这里,还有一个非常重要的知识点 docker run 。Docker 通过 run 命令来启动一个新容器。Docker 首先在本机中寻找该镜像,如果没有安装,Docker 在 Docker Hub 上查找该镜像并下载安装到本机,最后 Docker 创建一个新的容器并启动该程序。

image.png

但是,当第二次执行  docker run 时,因为 Docker 在本机中已经安装该镜像,所以 Docker 会直接创建一个新的容器并启动该程序。

image.png

注意的是,docker run 每次使用都会创建一个新的容器,因此,我们以后再次启动这个容器时,只需要使用命令 docker start  即可。这里, docker start 的作用在用重新启动已存在的镜像,而docker run 包含将镜像放入容器中 docker create ,然后将容器启动 docker start ,如图所示。

image.png

现在,我们可以在上面的案例的基础上,通过 exit 命令关闭 Docker 容器。当然,如果我们运行的是后台的守护进程,我们也可以通过 docker stop web 来停止。注意的是,docker stop 和 docker kill 略有不同,docker stop 发送 SIGTERM 信号,而 docker kill 发送SIGKILL 信号。然后,我们使用 docker start 重启它。

docker start web

Docker 容器重启后会沿用 docker run 命令指定的参数来运行,但是,此时它还是后台运行的。我们必须通过 docker attach 命令切换到运行交互式容器。

docker attach web

4. 不止如此,还有更多命令

Docker 提供了非常丰富的命令。所谓一图胜千言,我们可以从下面的图片了解到很多信息和它们之前的用途。(可以直接跳过阅读,建议收藏,便于扩展阅读)

image.png

如果希望获取更多信息,可以阅读官方使用文档。

CommandDescription
docker attachAttach local standard input, output, and error streams to a running container
docker buildBuild an image from a Dockerfile
docker builderManage builds
docker checkpointManage checkpoints
docker commitCreate a new image from a container’s changes
docker configManage Docker configs
docker containerManage containers
docker cpCopy files/folders between a container and the local filesystem
docker createCreate a new container
docker deployDeploy a new stack or update an existing stack
docker diffInspect changes to files or directories on a container’s filesystem
docker engineManage the docker engine
docker eventsGet real time events from the server
docker execRun a command in a running container
docker exportExport a container’s filesystem as a tar archive
docker historyShow the history of an image
docker imageManage images
docker imagesList images
docker importImport the contents from a tarball to create a filesystem image
docker infoDisplay system-wide information
docker inspectReturn low-level information on Docker objects
docker killKill one or more running containers
docker loadLoad an image from a tar archive or STDIN
docker loginLog in to a Docker registry
docker logoutLog out from a Docker registry
docker logsFetch the logs of a container
docker manifestManage Docker image manifests and manifest lists
docker networkManage networks
docker nodeManage Swarm nodes
docker pausePause all processes within one or more containers
docker pluginManage plugins
docker portList port mappings or a specific mapping for the container
docker psList containers
docker pullPull an image or a repository from a registry
docker pushPush an image or a repository to a registry
docker renameRename a container
docker restartRestart one or more containers
docker rmRemove one or more containers
docker rmiRemove one or more images
docker runRun a command in a new container
docker saveSave one or more images to a tar archive (streamed to STDOUT by default)
docker searchSearch the Docker Hub for images
docker secretManage Docker secrets
docker serviceManage services
docker stackManage Docker stacks
docker startStart one or more stopped containers
docker statsDisplay a live stream of container(s) resource usage statistics
docker stopStop one or more running containers
docker swarmManage Swarm
docker systemManage Docker
docker tagCreate a tag TARGET_IMAGE that refers to SOURCE_IMAGE
docker topDisplay the running processes of a container
docker trustManage trust on Docker images
docker unpauseUnpause all processes within one or more containers
docker updateUpdate configuration of one or more containers
docker versionShow the Docker version information
docker volumeManage volumes
docker waitBlock until one or more containers stop, then print their exit codes
官方阅读链接:https://docs.docker.com/engine/reference/commandline/docker/

5. 进阶:仓库与软件安装的简化

还记得笔者在文章开头介绍的「镜像、容器和仓库」吗?Docker 的仓库用于存放镜像。我们可以从中心仓库下载镜像,也可以从自建仓库下载。同时,我们可以把制作好的镜像从本地推送到远程仓库。

首先,笔者先引入一个知识点:Docker 的镜像就是它的文件系统,一个镜像可以放在另外一个镜像的上层,那么位于下层的就是它的父镜像。所以,Docker 会存在很多镜像层,每个镜像层都是只读的,并且不会改变。当我们创建一个新的容器时,Docker 会构建出一个镜像栈,并在栈的最顶层添加一个读写层,如图所示。

image.png

现在,我们可以通过 docker images 命令查看本地的镜像。

docker images

查询结果,如图所示。

image.png

这里,对几个名词解释一下含义。

  • REPOSITORY:仓库名称。
  • TAG: 镜像标签,其中 lastest 表示最新版本。注意的是,一个镜像可以有多个标签,那么我们就可以通过标签来管理有用的版本和功能标签。
  • IMAGE ID :镜像唯一ID。
  • CREATED :创建时间。
  • SIZE :镜像大小。

那么,如果第一次我们通过 docker pull centos:latest 拉取镜像,那么当我们执行 docker run -p 80 --name web -i -t centos /bin/bash 时,它就不会再去远程获取了,因为本机中已经安装该镜像,所以 Docker 会直接创建一个新的容器并启动该程序。

事实上,官方已经提供了安装好 Nginx 的镜像,我们可以直接使用。现在,我们通过拉取镜像的方式重新构建一个 Web 服务器。首先,我们通过 docker search 来查找镜像。我们获取到 Nginx 的镜像清单。

docker search nginx

补充一下,我们也可以通过访问 Docker Hub (https://hub.docker.com/)搜索仓库,那么 star 数越多,说明它越靠谱,可以放心使用。

image.png

现在,我们通过 docker pull nginx 拉取最新的 Nginx 的镜像。当然,我们也可以通过 docker pull nginx:latest  来操作。

docker pull nginx

然后,我们创建并运行一个容器。与前面不同的是,我们通过 -d 选项告诉 Docker 在后台运行容器的守护进程。并且,通过 8080:80 告诉 Docker 8080 端口是对外开放的端口,80 端口对外开放的端口映射到容器里的端口号。

docker run -p 8080:80 -d --name nginx nginx

我们再通过 docker ps -a 来查看,发现容器已经后台运行了,并且后台执行了 nginx 命令,并对外开放 8080 端口。

image.png

因此,通过浏览器访问 http://127.0.0.1:8080 即可。

image.png

6. 其他选择,使用替代注册服务器

Docker Hub 不是软件的唯一来源,我们也可以切换到国内的其他替代注册服务器,例如阿里云。我们可以登录 https://cr.console.aliyun.com 搜索,并拉取公开的镜像。

image.png

image.png

现在,我们输入 docker pull 命令进行拉取。

docker pull registry.cn-hangzhou.aliyuncs.com/qp_oraclejava/orackejava:8u172_DCEVM_HOTSWAPAGEN_JCE

这里,笔者继续补充一个知识点:注册服务器的地址。事实上,注册服务器的地址是有一套规范的。完整格式是:仓库主机/容器短名[:标签]。这里,仓库主机是 registry.cn-hangzhou.aliyuncs.com,用户名是 qp_oraclejava,容器短名是 orackejava,标签名是 8u172_DCEVM_HOTSWAPAGEN_JCE。事实上,我们上面通过 docker pull centos:latest 拉取镜像,相当于 docker pull registry.hub.docker.com/centos:latest 。

三、构建我的镜像

通过上面的学习,笔者相信你已经对 Docker 使用有了一个大致的了解,就好比我们通过 VMware 安装了一个系统,并让它跑了起来,那么我们就可以在这个 Linux 系统(CentOS 或者 Ubuntu ) 上面工作我们想要的任何事情。事实上,我们还会经常把我们安装好的 VMware 系统进行快照备份并实现克隆来满足我们下次快速的复制。这里,Docker 也可以构建定制内容的 Docker 镜像,例如上面我们使用官方提供的安装好 Nginx 的 Docker 镜像。注意的是,我们通过基于已有的基础镜像,在上面添加镜像层的方式构建新镜像而已。

总结一下,Docker 提供自定义镜像的能力,它可以让我们保存对基础镜像的修改,并再次使用。那么,我们就可以把操作系统、运行环境、脚本和程序打包在一起,并在宿主机上对外提供服务。

Docker 构建镜像有两种方式,一种方式是使用 docker commit 命令,另外一种方式使用 docker build 命令和 Dockerfile 文件。其中,不推荐使用 docker commit 命令进行构建,因为它没有使得整个流程标准化,因此,在企业的中更加推荐使用 docker build 命令和 Dockerfile 文件来构建我们的镜像。我们使用Dockerfile 文件可以让构建镜像更具备可重复性,同时保证启动脚本和运行程序的标准化。

1. 构建第一个 Dockerfile 文件

现在,我们继续实战。这里,我们把一开始搭建的 Web 服务器构建一个镜像。首先,我们需要创建一个空的 Dokcerfile 文件。

mkdir dockerfile_test
cd dockerfile_test/
touch Dockerfile
nano Dockerfile

紧接着,我们需要编写一个 Dockerfile 文件,代码清单如下

FROM centos:7
MAINTAINER LiangGzone "lianggzone@163.com"
RUN rpm -ivh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm
RUN yum install -y nginx
EXPOSE 80

最后,我们通过 docker build 命令进行构建。

docker build -t="lianggzone/nginx_demo:v1" .

现在, 我们来通过 docker images 看下我们的新镜像吧。

image.png

2. 理解 Dockerfile 全过程

哇,我们通过编写一个 Dockerfile 文件顺利构建了一个新的镜像。这个过程简单得让人无法相信。现在,让我们来理解一下这个全过程吧。首先, FROM centos:7 是 Dockerfile 必须要的第一步,它会从一个已经存在的镜像运行一个容器,换句话说,Docker 需要依赖于一个基础镜像进行构建。这里,我们指定 centos 作为基础镜像,它的版本是 7 (CentOS 7)。然后,我们通过 MAINTAINER LiangGzone "lianggzone@163.com" 指定该镜像的作者是 LiangGzone,邮箱是 lianggzone@163.com。这有助于告诉使用者它的作者和联系方式。接着,我们执行两个 RUN 指令进行 Nginx 的下载安装,最后通过  EXPOSE 80 暴露 Dokcer 容器的 80 端口。注意的是,Docker 的执行顺序是从上而下执行的,所以我们要明确整个流程的执行顺序。除此之外,Docker 在执行每个指令之后都会创建一个新的镜像层并且进行提交。

我们使用  docker build 命令进行构建,指定 - t 告诉 Docker 镜像的名称和版本。注意的是,如果没有指定任何标签,Docker 将会自动为镜像设置一个 lastest 标签。还有一点,我们最后还有一个 . 是为了让 Docker 到当前本地目录去寻找 Dockerfile 文件。注意的是,Docker 会在每一步构建都会将结果提交为镜像,然后将之前的镜像层看作缓存,因此我们重新构建类似的镜像层时会直接复用之前的镜像。如果我们需要跳过,可以使用 --no-cache 选项告诉 Docker 不进行缓存。

3. Dockerfile 指令详解

Dockerfile 提供了非常多的指令。笔者这里特别整理了一份清单,建议收藏查看。

image.png

官方地址:https://docs.docker.com/engine/reference/builder/#usage

指令辨别一:RUN、CMD、ENTRYPOINT

RUN 、 CMD 、 ENTRYPOINT  三个指令的用途非常相识,不同在于,RUN 指令是在容器被构建时运行的命令,而CMD 、 ENTRYPOINT 是启动容器时执行 shell 命令,而 RUN 会被 docker run 命令覆盖,但是  ENTRYPOINT 不会被覆盖。事实上,docker run 命令指定的任何参数都会被当作参数再次传递给 ENTRYPOINT  指令。CMD 、 ENTRYPOINT 两个指令之间也可以一起使用。例如,我们 可以使用 ENTRYPOINT 的 exec 形式设置固定的默认命令和参数,然后使用任一形式的 CMD 来设置可能更改的其他默认值。

FROM ubuntu
ENTRYPOINT ["top", "-b"]
CMD ["-c"]

指令辨别二:ADD、COPY

ADD 、 COPY 指令用法一样,唯一不同的是 ADD  支持将归档文件(tar, gzip, bzip2, etc)做提取和解压操作。注意的是,COPY 指令需要复制的目录一定要放在 Dockerfile 文件的同级目录下。

4. 将镜像推送到远程仓库

远程仓库:Docker Hub 

镜像构建完毕之后,我们可以将它上传到 Docker Hub 上面。首先,我们需要通过 docker login 保证我们已经登录了。紧接着,我们使用 docker push 命令进行推送。

docker push lianggzone/nginx_demo:v1

这里,我们了解下它的使用,格式是 docker push [OPTIONS] NAME[:TAG] ,其中,笔者设置 NAME 是 lianggzone/nginx_demo,TAG 是 v1。 (笔者注:推送 Docker Hub 速度很慢,耐心等待) 最后,上传完成后访问:https://hub.docker.com/u/lianggzone/,如图所示。

image.png

远程仓库:阿里云

同时,我们也可以使用国内的仓库,比如阿里云。首先,在终端中输入访问凭证,登录 Registry 实例。如果你不知道是哪个,可以访问 https://cr.console.aliyun.com/cn-hangzhou/instances/credentials

docker login --username=帐号 registry.cn-hangzhou.aliyuncs.com

现在,将镜像推送到阿里云镜像仓库。其中, docker tag [IMAGE_ID] registry.cn-hangzhou.aliyuncs.com/[命名空间]/[镜像名称]:[版本] 和 docker push registry.cn-hangzhou.aliyuncs.com/[命名空间]/[镜像名称]:[版本] 命令的使用如下所示。

docker tag 794c07361565 registry.cn-hangzhou.aliyuncs.com/lianggzone/nginx_demo:v1
docker push registry.cn-hangzhou.aliyuncs.com/lianggzone/nginx_demo:v1

最后,上传完成后访问:https://cr.console.aliyun.com/cn-hangzhou/instances/repositories,如图所示。

image.png

5. Dockerfile 的 Github 源码地址

这里,附上我整理的 Dockerfile 的仓库。后面,笔者会陆续更新用到的一些常用文件,欢迎 star 关注。

https://github.com/lianggzone/dockerfile-images

附:参考资料

(完,转载请注明作者及出处。)

写在末尾

【服务端思维】:我们一起聊聊服务端核心技术,探讨一线互联网的项目架构与实战经验。同时,拥有众多技术大牛的「后端圈」大家庭,期待你的加入,一群同频者,一起成长,一起精进,打破认知的局限性。

更多精彩文章,尽在「服务端思维」!

查看原文

赞 146 收藏 109 评论 4

坏掉的牙 发布了文章 · 2018-02-01

虚拟IP

HA

高可用HA(high available),指的是通过尽量缩短因日常维护操作和突发的系统崩溃所导致的停机时间,以提高系统和应用的可用性。

其中一个实现高可用的方式就是采用两台机器完成同一个功能,比如数据库服务器。平时一台机器对外提供服务,另外一台机器作为热备,在主数据库服务器出现问题时,自动切换到热备的从服务器

故障检测

心跳,定时像服务器发送一个数据包进行请求,如果规定时间内服务器没有数据响应则认定为发生故障,实施切换到热备份的机器上

虚拟IP,就是一个未分配给真实主机的IP地址,就是说一个对外提供服务的数据库服务器除了有一个真实IP地址外还有一个虚拟IP,使用这两个IP中的任意一个都可以连接到这台主机。项目中的数据库连接项数据库地址都配置这个虚拟IP,当服务发生故障无法对外提供服务时,动态将这个虚IP切换到备用主机

虚拟IP原理

ARP是地址解析协议,作用是将一个IP地址转换为MAC地址,然后给传输层使用

每台主机都有一个ARP高速缓存,存储同一个网络内的IP地址和MAC地址的对应关系,以太网中的主机发送数据时会先从这个缓存中查询目标IP对应的MAC地址,会向这个MAC地址发送请求数据包。操作系统会自动维护这个缓存

比如在实际的业务中,存在物理机A(ip192.168.192.54)和物理机B(ip192.168.192.40),A作为对外的服务器(主服务器),B作为从服务器,两台机器之间的通信通过Heartbeat,就是说主服务器会定时的给备份服务器发送数据包,告知主服务器服务正常,当备份服务器没有收到主服务器的Heartbeat,就会认为主服务器宕机,则从服务器就会升级成为主服务器

假设物理机A的ARP缓存如下:

clipboard.png

B物理机的ARP缓存信息如下:

clipboard.png

当B机器通过Heartbeat得知A机器对外服务不可用的时候,会将自己的ARP缓存发送出去,来路由器修改路由表,告知虚拟地址应该指向我(物理机B),外界再次访问虚拟IP的时候,机器B会变成主服务器,而A降级为备份服务器。这样就完成了一次主从切换

查看原文

赞 0 收藏 0 评论 0

坏掉的牙 赞了回答 · 2017-04-20

解决如何防止网站图片被浏览

改造图片服务器,图片文件夹不直接对外暴露。 在图片服务器上架设一个Http代理服务,访问图片的url中必须有一个合法的token参数才允许访问,例如 http://www.imgserver.com/test.jpg?t=xT5112XabseFg0,

  • 其中t参数时你自己设定的加密算法生成的,里面含有这个参数的创建时间。

  • 服务器接收到这个请求后,解密token,拿到里面的时间戳,如果是10秒之内创建的(你可以设置你自己希望的有效期),就返回图片信息,否则拒绝访问。

这样一个图片链接就有了有效期概念,自己使用时加载带有合法t参数的图片就能正常展示给用户。用户此时自己拷贝这个图片地址在浏览器直接访问,很可能已经过了有效期,自然打不开了。

此外,还有个更简单的方法防盗链:(当然也可以和上面的方法结合用)

判断http请求发过来的referer信息,如果不等于你自己的网站域名或者为空(即,该图片请求不是在你的网站发起的),那么不允许访问。

关注 14 回答 11

认证与成就

  • 获得 51 次点赞
  • 获得 11 枚徽章 获得 0 枚金徽章, 获得 2 枚银徽章, 获得 9 枚铜徽章

擅长技能
编辑

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2016-03-29
个人主页被 1k 人浏览