开发者学堂课程【4天 Docker 实战-1024程序员节创造营公益课：docker 的实际运用 】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/892/detail/14273
docker 的实际运用
一、数据持久化的场景
1.文件需要永久存储：
配置文件，日志文件，应用数据，缓存文件
2. 数据持久化类型
方式一：volumes
存于主机文件系统中的某个区域，
由 Docker 管理（/var/lib/docker/volumes/ ）。非 Docker 进程不应该修改这些数据。你可以把它当做容器数据持久化专门的磁盘分区。
特点：
1：volumes 是 Docker 中持久化数据的最好方式。因为和容器解耦度更高。
2：多个容器可以同时访问一个 volumes 。
3：远程主机或非本地常用该方式。（架构）
4：首先需要创建。之后再进行使用。
使用：
docker volume create test1
docker run -itd -p 8800:80 -v test1:/usr/share/nginx/html nginx:v1
方式二：bind—mount
将宿主机中的文件、目录 mount 到容器上。
特点：
1：它更像1对1的夫妻。耦合度较高。
2：一些监控类 container，通过读取宿主机固定文件中的数据实现监控等。
3：常用于临时共享文件（如配置文件等）或源码文件。
使用：
dockerrun-itd-p8801:80-v /var/log/cont/apache1:/var/log/httpd/
apache:new2
方式三：tmpfs
将数据存于宿主机内存中。
特点：
1：仅限 Linux 系统。
2：较少用，常见用于对于访问有大量读写，或安全层面考虑。
3：不会持久化，生命周期限于容器启动时。
4：多容器无法共享同一个 tmpfs
使用：
docker run -itd --name tmptest --tmpfs /root nginx:latest
二、harbor 仓库
1.概念
Docker 容器应用的开发和运行离不开可靠的镜像管理，虽然 Docker 官方也提供了公共的镜像仓库，但是从安全和效率等方面考虑，部署私有环境内的 Registry也是非常必要的。
Harbor 是由 VMware 公司开源的企业级的 Docker Registry 管理项目，它包括权限管理 (RBAC)、LDAP、日志审核、管理界面、自我注册、镜像复制和中文支持等功能
Harbor 是由 VMware 公司开源的企业级的 Docker Registry 管理项目，相比 docker 官方拥有更丰富的权限权利和完善的架构设计，适用大规模 docker 集群部署提供仓库服务。
2.作用
1：企业级镜像仓库，根据企业需求创建的镜像，可以通过 harbor 实现
管理和使用。
2：主要特点功能包括：基于角色的访问控制，基于镜像的复制策略，
图形化用户界面，审计管理等。
3. 安装
1：安装并启动 docker（略）
2：安装 docker-compose1.18 以上版本。
（ docker 单机容器编排工具）
•wget
https://github.com/docker/compose/releases/download/1.29.2/
docker-compose-Linux-x86_64
#从官网下载 docker-compose 二进制文件
•chmod +x docker-compose-Linux-x86_64
#添加执行权限
•mv docker-compose-Linux-x86_64 /usr/bin
#移动到系统指令目录下
tar -xvf harbor-offline-installer-v2.3.1.tgz
#解压
•cp harbor/harbor.yml.tmpl harbor/harbor.yml
#复制官方配置文件案例。
•vim harbor.yml
#修改配置文件中 hostname 和 https 字段。
•bash prepare && bash install.sh
#初始化并安装
4. 使用
一：web 页面中操作新建项目、新建人员并设置权限、匹配人员和项目。
二：将本地刚刚做的镜像推送到 harbor 共用项目仓库中。
dockertagapache:new1 192.168.28.131/library/apache:new1
使用 harbor•vim /etc/docker/daemon.json
（信任 harbor 端 IP）
{
"registry-mirrors": ["https://f9dk003m.mirror.aliyuncs.com"],
"insecure-registries":["192.168.28.131"]
}
•docker login 192.168.28.131
•docker push 192.168.28.131/library/apache:new1
三、微服务
1.概念
微狭义来讲就是体积小、著名的"2 pizza 团队"很好的诠释了这一解释（2 pizza 团队最早是亚马逊 CEO Bezos 提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了 ）。 而所谓服务，一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。
微服务是一种架构模式，它提倡的是将单体应用拆分成各个模块，充分解耦，独立构建部署，
相互之间可以协调，配合。
2. 特点
小：颗粒度小，且专注一件事情。
独：单独的进程。美韩中国
轻：轻量级的通信机制。德
松：松耦合，独立部署
3. 性质
（复杂性）
困境：
系统会随着业务的发展，增加越来越多的特性和功能，使得系统复杂到没有一个人能全面理解，没有一个人敢
去修改原有的功能或代码。
微服务：
微服务提出以业务边界作为模块划分原则，每个模块独立进程。一个业务由很多独立的小业务组合而成，系
统也是由独立的小系统组合而成，这样的好处是每个小系统都很容易被理解，一个大系统可以根据业务组合微服务，或者逐渐发展独立的微服务
代价：
微服务为了降低单个微服务的复杂性，导致整体系统的复杂性急剧增加。微服务之间的连接更加复杂，网络通讯不可靠和性能损耗，协议匹配，接口对接和转换，版本协作，微服务注册和发现，编排和调度，分布式业务和数据一致性等等复杂性都是单体架构不需要考虑的。
经验要求、k8s
（隐匿性）
困境：
软件在没有应用到业务之前，各种信息和思考大多在每个人的脑海里，很难完全呈现和想象出来。客户只是知道自己想要更多新英雄，但并不知道要具体什么样的英雄；开发设计人员知道怎么做英雄，但又不能完全理解用户需求；运维知道部署服务和上线，但又不能完全理解业务逻辑。单体架构中的各个模块隐藏在大系统的页面下，在交付
之前对外界是不可见的。 导致没有人能看清全貌，各自都想把事情做到最好，但组合起来却不是客户想要的东西。
微服务：
微服务架构并没有改变软件开发过程中的隐匿性，而是通过缩短从需求到交付这段软件开发周期，减少隐匿时间，来降低软件工程总体的隐匿性。
代价：
组织必须要具备自动部署持续交付能力。假如一个系统上线需要3个小时进行部署，如果我们要持续部署，每
天都部署一次，那就需要每天拿出3小时做部署，这个成本是不能接受的。
Devops
（耦合性）
困境：
假如系统从零开始做的话，头三个月开发会比较慢，因为需要搭建和熟悉一些开发、测试、部署基础设施，随着基础设施和公共组件的完善，接下来的半年到一年开发会加速，但是再往后开发速度又会逐渐降低。因为那些一开始提高开发效率的接口、共享表、依赖组件都变成了复杂网络缠绕在一起，变成了所谓的牵一发而动全身，改一行代码都不知道会影响到什么地方。
微服务：
微服务系统的耦合性问题总是在一个可控的范围内。比如微服务独立数据库表结构，那我们根据业务需要改表结构的时候就不需要去考虑会不会影响到其他业务，因为其他业务和这个表结构完全没关系。
代价：
单纯从接口协同一致上来说，微服务架构比较糟糕。 单体架构的接口之间配合是相同的编程语言，基本上在编
译时就能发现错误。而微服务的接口往往是远程服务，验证增加难度。
运维观战
（易变性）
困境：
比如某个模块的流量突然增加，或者需要大内存，单体架构只能为极少的模块增加整个系统的计算资源，又因为增加整个系统的计算资源成本很高、实施时间长，导致性能需求迟迟不能得到满足。
微服务：
微服务要求独立进程，可以完全根据需求定制不同类型的计算资源，更精细化分类的利用内存、IO、CPU 。因为小，可以更快水平扩展响应性能需求变化。更关键是，微服务小，强调独立业务价值。小团队直接面对客户需求做决策，所有信息和想法在小范围内快速交流，业务价值流动更容易可见，更快速的响应变化。后期可以弹性扩容。
代价：
微服务架构需要改变组织结构小团队充分授权、业务交付模式。对传统组织而言，这点是最难的，尤其是大公司往往采用层级组织结构。公司层面
4. 总结
1：单体应用的困境，是现在普遍的困境。新的团队有了理念后，会在万丈高楼平地起时就采用该架构，避免单体应
用困境。
2：微服务是趋势，现在某些大型公司难以实现只是时间问题。除非它不需要拓展业务和更变业务。
3：18 年前后 k8s 的出现，短短三年就被世界各互联网公司所接受和使用，就足以说明微服务的重要性。对运维人员和
开发人员来说，这是个大的挑战和机遇。
4：遇到风口，不进则退。
