docker从入门到入土（进阶篇）_docker koko

Hello~大家好，这里是KOKO！

之前我们学习了docker的基础篇内容，今天我们来深入了解进阶篇的内容。

在学习进阶篇之前，请大家务必保证基础篇的那些常用命令都进行了练习并且已经熟练掌握！

docker复杂安装详说

安装mysql主从复制

主从复制原理

日志的互相读写；
此处不详细讲解原理，可自行查阅相关资料。

主从搭建步骤

• 新建主服务器3307(3306为docker实例里的端口)

docker run -p 3307:3306 --name mysql-master
-v /mydata/mysql-master/log:/var/log/mysql
-v /mydata/mysql-master/data:/var/lib/mysql
-v /mydata/mysql-master/conf:/etc/mysql
-e MYSQL_ROOT_PASSWORD=root
-d mysql:5.7
1
2
3
4
5
6

• 进入/mydata/mysql-master/conf目录下新建my.cnf

cd /mydata/mysql-master/conf
vim my.cnf

##设置server_id，局域网中需要唯一
server_id=101
##指定不需要同步的数据库名称
binlog-ignore-db =mysql
##开启二进制日志功能
log-bin=mall-mysql-bin
##设置二进制日志使用内存大小（事务）
binlog_cache_size=1M
##设置使用的二进制日志格式（mixed,statement,row）
binlog_format=mixed
##二进制日志过期清理时间。默认值为0，表示不自动清理
expire_logs_days=7
##跳过主从复制中遇到的所有错误或指定类型的错误，避免slave端复制中断。
##如：1062错误是指一些主键重复，1032错误是因为主从数据库数据不一致
slave_skip_errors=1062
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

• 修改完配置后重启master

docker restart mysql-master
1

• 进入mysql-master容器

docker exec -it mysql-master /bin/bash
mysql -uroot -p 
root
1
2
3

• master容器实例内创建数据同步用户

CREATE USER'slave'@'%'IDENTIFIED BY'123456';
GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO 'slave'@'%';
1
2

• 新建从服务器3308

docker run -p 3308:3306 --name mysql-slave
-v /mydata/mysql-slave/log:/var/log/mysql
-v /mydata/mysql-slave/data:/var/lib/mysql
-v /mydata/mysql-slave/conf:/etc/mysql
-e MYSQL_ROOT_PASSWORD=root
-d mysql:5.7
1
2
3
4
5
6

• 进入/mydata/mysql-slave/conf目录下新建my.cnf

cd /mydata/mysql-slave/conf
vim my.cnf

##设置server_id，局域网中需要唯一
server_id=101
##指定不需要同步的数据库名称
binlog-ignore-db =mysql
##开启二进制日志功能，以备slave作为其他数据库实例的master时使用
log-bin=mall-mysql-slave1-bin
##设置二进制日志使用内存大小（事务）
binlog_cache_size=1M
##设置使用的二进制日志格式（mixed,statement,row）
binlog_format=mixed
##二进制日志过期清理时间。默认值为0，表示不自动清理
expire_logs_days=7
##跳过主从复制中遇到的所有错误或指定类型的错误，避免slave端复制中断。
##如：1062错误是指一些主键重复，1032错误是因为主从数据库数据不一致
slave_skip_errors=1062
##relay_log配置中继日志
relay_log=mall-mysql-relay-bin
##log_slave_updates表示slave将复制事件写进自己的二进制日志
log_slave_updates=1
##slave设置为只读（具有super权限的用户除外）
read_only=1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

• 修改完配置后重启slave实例

docker restart mysql-slave
1

• 在主数据库中查看主从同步状态

show master status
1

• 进入mysql-slave容器

docker exec -it mysql-slave /bin/bash
mysql -uroot -p 
root
1
2
3

• 在从数据库中配置主从复制

change master to master_host='宿主机ip',master_user='slave',master_password='123456',master_port=3307,master_log_file='mall-mysql-bin.000001',master_log_pos=617,master_connect_retry=30;
1

参数说明：
master_host:主数据库的IP地址
master_user:在主数据库创建的用于同步数据的用户账号
master_password:在主数据库创建的用于同步数据的用户账号master_port:主数据库的运行端口
master_log_file:指定从数据库要复制数据的日志文件，通过查看主数据的状态，获取File参数
master_log_pos:指定从数据库从哪个位置开始复制数据，通过查看主数据的状态，获取Position参数
master_connect_retry:连接失败重试的时间间隔，单位为秒

• 在从数据库中查看主从同步状态

show slave status \G;
1

主要看Slave_IO_Running和Slave_SQL_Running

• 在从数据库中开启主从同步

start slave
1

• 查看从数据库状态发现已经同步
  Slave_IO_Running和Slave_SQL_Running参数从NO变为YES

• 主从复制测试
  主机新建库-使用库-新建表-插入数据，ok
  从机使用库-查看记录，ok

安装redis集群（P6~P7工程案例和场景设计类必考题目）

cluster（集群）模式-docker版
哈希槽分区进行亿级数据存储

案例题目：
1~2亿条数据需要缓存，请问如何设计这个存储案例

单机单台100%不可能，肯定是分布式存储！

哈希取余分区

2亿条记录就是2亿个k,v，我们单机不行必须要分布式多机，假设有3台机器构成一个集群，用户每次读写操作都是根据公式：hash(key)%N个机器台数，计算出哈希值，用来决定数据映射到哪一个节点上。

优点：
简单粗暴，直接有效，只需要预估好数据规划好节点，例如3台，8台，10台，就能保证一段时间的数据支撑。使用Hash算法让固定的一部分请求落到同一台服务器上，这样每台服务器固定处理一部分请求（并维护这些请求的信息），起到负载均衡+分而治之的作用。

缺点：
原来规划好的节点，进行扩容或者缩容比较麻烦。不管扩缩，每次数据变动导致节点有变动，映射关系需要重新进行计算，在服务器个数固定不变的时没有问题，如果需要弹性扩容或故障停机的情况下，原来的取模公式就会发生变化；Hash(key)/3会变成Hash(key)/?，此时地址经过取余运算的结果将发生很大变化，根据公式获取的服务器也会变得不可控。
某个redis机器宕机了，由于台数数量变化，会导致hash取余全部数据重新洗牌。

一致性哈希算法分区

一致性哈希算法：

在1997年由麻省理工学院中提出，设计目标是为了解决分布式缓存数据变动和映射问题，某个机器宕机了，分母数量改变了，自然取余数就不OK了。

目的：

当服务器个数发生变动时，尽量减少影响客户端到服务器的映射关系。

三大步骤：

算法构建一致性哈希环
服务器IP节点映射
key落到服务器的落键规则

一致性哈希环：
一致性哈希算法必然有个hash函数并按照算法产生hash值，这个算法的所有可能哈希值会构成一个全量集，这个集合可以成为一个hash空间[0,2^32-1],这个是一个线性空间，但是在算法中，我们通过适当的逻辑控制将它首尾相连（0=2^32），这样让它逻辑上形成了一个环形空间。
本方法也是按照取余的方法，对2^32取余,也就是0点左侧的第一个点代表2^32-1，0和232-1在零点中方向重合，我们把这个2^32个点组成的圆环成为Hash环。

节点映射：
将集群中各个IP节点映射到环上的某一个位置。
将各个服务器选择其IP或主机名作为关键字使用Hash确定其在哈希上的位置；当我们需要存储一个kv键值对时，首先计算key的hash值，将这个key使用相同的函数Hash计算出哈希值并确定此数据在环上的位置，从此位置沿环顺时针“行走”，第一台遇到的服务器就是其应该定位到的服务器，并将该键值对存储在该节点上。

优点

一致性哈希算法的容错性：
假如有ABCD四个节点，当C宕机后，受到影响的只有BC直接的数据，且BC之间的数据会转移到D上存储。

一致性哈希算法的扩展性：
当数据量增加，需要增加一台节点NodeX，X的位置在A和B之间，那受到影响的也只有AX之间的数据，重新把AX的数据录入到X上即可，不会导致hash取余全部数据重新洗牌。

缺点

一致性哈希算法的数据倾斜问题：
一致性哈希算法在服务点太少时，容易因为节点分布不均匀而造成数据倾斜（被缓存的对象大部分集中缓存在某一台服务器上）问题。

哈希槽分区

为什么出现

一致性哈希算法存在数据倾斜问题。哈希槽实质就是一个数组，数组[0,2^14-1]形成hash slot空间。

能干什么

解决均匀分配问题，在数据和节点之间又加入了一层，把这层称为哈希槽（slot)，用于管理数据和节点之间的关系，现在就相当于节点上放的是槽，槽里放的是数据。
槽解决的是粒度问题，相当于把粒度变大了，这样便于数据移动。

多少个hash槽

一个集群只能有16384个槽，编号0-16384(0-2^14-1)。<多了占内存，少了不够用>
这些槽会分配给集群中的所有主节点，分配策略没有要求，可以指定哪些编号的槽分配给哪个主节点。集群会记录节点和槽的对应关系。解决了节点和槽的关系后，接下来就需要对key求哈希值，然后对16384取余，余数是几key就落入对应的槽里。
slot=CRC16(key)%16384。
以槽为单位移动数据，因为槽的数目是固定的，处理起来比较容易，这样数据移动问题就解决了。

哈希槽计算

slot=CRC16(key)%16384
根据节点数目N，将哈希槽的数组均分为N段，这样哈希槽即可和节点完成映射。

dockerfile解析

是什么

dockerfile是用来构建docker镜像的文本文件，是由一条条构建镜像所需的指令和参数构成的脚本。

官网：
https://docs.docker.com/engine/reference/builder/

构建三步骤：
编写dockerfile文件；
docker build命令构建镜像；
docker run依镜像运行容器

dockerfile构建过程解析

dockerfile内容基础知识

每条保留字指令都必须为大写字母且后面要跟随至少一个参数；

指令按照从上到下，顺序执行；

#表示注释；

每条指令都会创建一个新的镜像层并对镜像进行提交；

docker执行dockerfile的大致流程

docker从基础镜像运行一个容器；

执行一条指令并对容器做出修改；

执行类似docker commit的操作提交一个新的镜像层；

docker再基于刚提交的镜像运行一个新容器；

执行dockerfile中的下一条指令直到所有指令都执行完成；

从应用软件的角度来看，dockerfile，docker镜像和docker容器分别代表软件的三个不同阶段：
dockerfile是软件的原材料
docker镜像是软件的交付品
docker容器则可以认为是软件镜像的运行态，也即依照镜像运行的容器实例
dockerfile面向开发，docker镜像成为交付标准，docker容器则涉及部署与运维，三者缺一不可，合力充当docker体系的基石。

• dockerfile，需要定义一个dockerfile,dockerfile定义了进程所需要的一切东西。dockerfile涉及的内容包括执行代码或者是文件、 环境变量、依赖包、运行时环境、动态链接库、操作系统的发行版、服务进程和内核进程（当应用进程需要和系统服务和内核进程打交道，这时需要考虑如何设计namespace的权限控制）等等。

• docker镜像，在用dockerfile定义一个文件之后，docker build时会产生一个docker镜像，当运行docker镜像时会真正开始提供服务。

• docker容器，容器是直接提供服务的。

dockerfile保留字简介

dockerfile的文件中红色的即为关键保留字

FROM

基础镜像，当前镜像是基于哪个镜像的，指定一个已经存在的镜像作为模板，第一条必须是from；

MAINTAINER

镜像维护者的姓名和邮箱地址；

RUN

容器构建时需要运行的命令；

两种格式：
shell格式：RUN<命令行命令> 等同于在终端操作的shell命令 eg:RUN yum -y install vim 在容器构建时，一构建就执行安装vim的命令
exec格式：RUN ["可执行文件","参数1","参数2"] eg:RUN ["./test.php",“dev”,“offline”] 等价于 RUN ./test.php dev offline

EXPOSE

当前容器对外暴露出的端口；

WORKDIR

指定在创建容器后，终端默认登陆的进来工作目录，一个落脚点；

USER

指定该镜像以什么样的用户去执行，如果都不指定，默认是root；

ENV

用来在构建镜像过程中设置环境变量；
这个环境变量可以在后续的任何RUN指令中使用，这就如同在命令前面指定了环境变量前缀一样；
也可以在其他指令中直接使用这些环境变量；

VOLUME

容器数据卷，用于数据保存和持久化工作；

ADD

将宿主机目录下的文件拷贝进镜像且会自动处理URL和解压tar压缩包；
相当于copy+解压；

COPY

类似ADD，拷贝文件和目录到镜像中；
将从构建上下文目录中<源路径>的文件/目录复制到新的一层的镜像内的<目录路径>位置；

CMD

指定容器启动后要干的事情；

CMD容器启动命令
CMD指令格式和RUN相似，也是两种格式：
shell格式：CMD<命令>
exec格式：CMD[“可执行文件”,“参数1”,“参数2”…]
参数列表格式：CMD[“参数1”,“参数2”…]。在指定了ENTRYPOINT指令后，用CMD指定具体的参数。

注意：
dockerfile中可以有多个CMD指令，但只有最后一个生效，CMD会被docker run之后的参数替换；

它和RUN命令的区别：
CMD是在docker run时运行；
RUN是在docker build时运行；

ENTRYPOINT

也是用来指定一个容器启动时要运行的命令的；

类似于CMD指令，但是ENTRYPOINT并不会被docker run后面的命令覆盖，而且这些命令行参数会被当作参数送给ENTRYPOINT指令指定的程序；

命令格式：ENTRYPOINT["","","",…]
ENTRYPOINT可以和CMD一起使用，一般是变参才会用CMD，这里的CMD等于是在给ENTRYPOINT传参。
当指定了ENTRYPOINT后，CMD的含义就发生了变化，不再是直接运行其命令而是将CMD的内容作为参数传递给ENTRYPOINT指令，他两个组合会变成"";