Docker | Tony Bai

标签 docker 下的文章

使用Docker Compose构建一键启动的运行环境

十一月 26, 2021
0 条评论

本文永久链接 – https://tonybai.com/2021/11/26/build-all-in-one-runtime-environment-with-docker-compose

如今，不管你是否喜欢，不管你是否承认，微服务架构模式的流行就摆在那里。作为架构师的你，如果再将系统设计成个大单体结构，那么即便不懂技术的领导，都会给你送上几次白眼。好吧，妥协了！开拆！“没吃过猪肉，还没见过猪跑吗！”。拆不出40-50个服务，我就不信还拆不出4-5个服务^_^。

终于拆出了几个服务，但又犯难了：以前单体程序，搭建一个运行环境十分easy，程序往一个主机上一扔，配置配置，启动就ok了；但自从拆成服务后，开发人员的调试环境、集成环境、测试环境等搭建就变得异常困难。

有人会说，现在都云原生了？你不知道云原生操作系统k8s的存在么？让运维帮你在k8s上整环境啊。一般小厂，运维人员不多且很忙，开发人员只能“自力更生，丰衣足食”。开发人员自己整k8s？别扯了！没看到这两年k8s变得越来越复杂了吗！如果有一年不紧跟k8s的演进，新版本中的概念你就可能很陌生，不知源自何方。一般开发人员根本搞不定(如果你想搞定，可以看看我的k8s实战课程哦，包教包会^_^)。

那怎么办呢？角落里曾经的没落云原生贵族docker发话了：要不让我兄弟试试！

1. docker compose

docker虽然成了“过气网红”，但docker依然是容器界的主流。至少对于非docker界的开发人员来说，一提到容器，大家首先想到的还是docker。

docker公司的产品推出不少，开发人员对多数都不买账也是现实，但我们也不能一棒子打死，毕竟docker是可用的，还有一个可用的，那就是docker的兄弟：docker compose。

Compose是一个用于定义和运行多容器Docker应用程序的工具。使用Compose，我们可以使用一个YAML文件来配置应用程序的所有服务组件。然后，只需一条命令，我们就可以创建并启动配置中的所有服务。

这不正是我们想要的工具么! Compose与k8s很像，都算是容器编排工具，最大的不同：Compose更适合在单节点上的调试或集成环境中（虽然也支持跨主机，基于被淘汰的docker swarm)。Compose可以大幅提升开发人员以及测试人员搭建应用运行环境的效率。

2. 选版本

使用docker compose搭建运行环境，我们仅需一个yml文件。但docker compose工具也经历了多年演化，这个文件的语法规范也有多个版本，截至目前，docker compose的配置文件的语法版本就有2、2.x和3.x三种。并且不同规范版本支持的docker引擎版本还不同，这个对应关系如下图。图来自docker compose文件规范页面：

选版本是最闹心的。选哪个呢？设定两个条件：

docker引擎版本怎么也得是17.xx
规范版本怎么也得是3.x吧

这样一来，版本3.2是最低要求的了。我们就选3.2：

// docker-compose.yml
version: "3.2"

3. 选网络

docker compose默认会为docker-compose.yml中的各个service创建一个bridge网络，所有service在这个网络里可以相互访问。以下面docker-compose.yml为例：

// demo1/docker-compose.yml
version: "3.2"
services:
  srv1:
    image: nginx:latest
    container_name: srv1
  srv2:
    image: nginx:latest
    container_name: srv2

启动这个yml中的服务：

# docker-compose -f docker-compose.yml up -d
Creating network "demo1_default" with the default driver
... ...

docker compose会为这组容器创建一个名为demo1_default的桥接网络:

# docker network ls
NETWORK ID          NAME                     DRIVER              SCOPE
f9a6ac1af020        bridge                   bridge              local
7099c68b39ec        demo1_default            bridge              local
... ...

关于demo1_default网络的细节，可以通过docker network inspect 7099c68b39ec获得。

对于这样的网络中的服务，我们在外部是无法访问的。如果要访问其中服务，我们需要对其中的服务做端口映射，比如如果我们要将srv1暴露到外部，我们可以将srv1监听的服务端口80映射到主机上的某个端口，这里用8080，修改后的docker-compose.yml如下：

version: "3.2"
services:
  srv1:
    image: nginx:latest
    container_name: srv1
    ports:
    - "8080:80"
  srv2:
    image: nginx:latest
    container_name: srv2

这样启动该组容器后，我们通过curl localhost:8080就可以访问到容器中的srv1服务。不过这种情况下，服务间的相互发现比较麻烦，要么借助于外部的发现服务，要么通过容器间的link来做。

开发人员大多只有一个环境，不同服务的服务端口亦不相同，让容器使用host网络要比单独创建一个bridge网络来的更加方便。通过network_mode我们可以指定服务使用host网络，就像下面这样：

version: "3.2"
services:
  srv1:
    image: bigwhite/srv1:1.0.0
    container_name: srv1
    network_mode: "host"

在host网络下，容器监听的端口就是主机上的端口，各个服务间通过端口区别各个服务实例(前提是端口各不相同)，ip使用localhost即可。

使用host网络还有一个好处，那就是我们在该环境之外的主机上访问环境中的服务也十分方便，比如查看prometheus的面板等。

4. 依赖的中间件先启动，预置配置次之

如今的微服务架构系统，除了自身实现的服务外，外围还有大量其依赖的中间件，比如：redis、kafka(mq)、nacos/etcd(服务发现与注册）、prometheus(时序度量数据服务)、mysql(关系型数据库)、jaeger server(trace服务器)、elastic(日志中心)、pyroscope-server(持续profiling服务)等。

这些中间件若没有启动成功，我们自己的服务多半启动都要失败，因此我们要保证这些中间件服务都启动成功后，再来启动我们自己的服务。

如何做呢？compose规范中有一个迷惑人的“depends_on”，比如下面配置文件中srv1依赖redis和nacos两个service：

version: "3.2"
services:
  srv1:
    image: bigwhite/srv1:1.0.0
    container_name: srv1
    network_mode: "host"
    depends_on:
      - "redis"
      - "nacos"
    environment:
      - NACOS_SERVICE_ADDR=127.0.0.1:8848
      - REDIS_SERVICE_ADDR=127.0.0.1:6379
    restart: on-failure

不深入了解，很多人会认为depends_on可以保证先启动依赖项redis和nacos，并等依赖项ready后再启动我们自己的服务srv1。但实际上，depends_on仅能保证先启动依赖项，后启动我们的服务。但它不会探测依赖项redis或nacos是否ready，也不会等依赖项ready后，才启动我们的服务。于是你会看到srv1启动后依旧出现各种的报错，包括无法与redis、nacos建立连接等。

要想真正实现依赖项ready后才启动我们自己的服务，我们需要借助外部工具了，docker compose文档对此有说明。其中一个方法是使用wait-for-it脚本。

我们可以改变一下自由服务的容器镜像，将其entrypoint从执行服务的可执行文件变为执行一个start.sh的脚本：

// Dockerfile
... ...
ENTRYPOINT ["/bin/bash", "./start.sh"]

这样我们就可以在start.sh脚本中“定制”我们的启动逻辑了。下面是一个start.sh脚本的示例：

#! /bin/sh

./wait_for_it.sh $NACOS_SERVICE_ADDR -t 60 --strict -- echo "nacos is up" && \
./wait_for_it.sh $REDIS_SERVICE_ADDR -- echo "redis is up" && \
exec ./srv1

我们看到，在start.sh脚本中，我们使用wait_for_it.sh脚本等待nacos和redis启动，如果在限定时间内等待失败，根据restart策略，我们的服务还会被docker compose重新拉起，直到nacos与redis都ready，我们的服务才会真正开始执行启动过程。

在exec ./srv1之前，很多时候我们还需要进行一些配置初始化操作，比如向nacos中写入预置的srv1服务的配置文件内容以保证srv1启动后能从nacos中读取到自己的配置文件，下面是加了配置初始化的start.sh：

#! /bin/sh

./wait_for_it.sh $NACOS_SERVICE_ADDR -t 60 --strict -- echo "nacos is up" && \
./wait_for_it.sh $REDIS_SERVICE_ADDR -- echo "redis is up" && \
curl -X POST --header 'Content-Type: application/x-www-form-urlencoded' -d dataId=srv1.yml --data-urlencode content@./conf/srv1.yml "http://127.0.0.1:8848/nacos/v1/cs/configs?group=MY_GROUP" && \
exec ./srv1

我们通过curl将打入镜像的./conf/srv1.yml配置写入已经启动了的nacos中供后续srv1启动时读取。

5. 全家桶，一应俱全

就像前面提到的，如今的系统对外部的中间件“依存度”很高，好在主流中间件都提供了基于docker启动的官方支持。这样我们的开发环境也可以是一个一应俱全的“全家桶”。不过要有一个很容易满足的前提：你的机器配置足够高，才能把这些中间件全部运行起来。

有了这些全家桶，我们无论是诊断问题(看log、看trace、看度量数据），还是作性能优化（看持续profiling的数据），都方便的不要不要的。

6. 结合Makefile，简化命令行输入

docker-compose这个工具有一个“严重缺陷”，那就是名字太长^_^。这导致我们每次操作都要敲入很多命令字符，当你使用的compose配置文件名字不为docker-compose.yml时，更是如此，我们还需要通过-f选项指定配置文件路径。

为了简化命令行输入，减少键盘敲击次数，我们可以将复杂的docker-compose命令与Makefile相结合，通过定制命令行命令并将其赋予简单的make target名字来实现这一简化目标，比如：

// Makefile

pull:
    docker-compose -f my-docker-compose.yml pull

pull-my-system:
    docker-compose -f my-docker-compose.yml pull srv1 srv2 srv3

up: pull-my-system
    docker-compose -f my-docker-compose.yml up

upd: pull-my-system
    docker-compose -f my-docker-compose.yml up -d

up2log: pull-my-system
    docker-compose -f my-docker-compose.yml up > up.log 2>&1

down:
    docker-compose -f my-docker-compose.yml down

ps:
    docker-compose -f my-docker-compose.yml ps -a

log:
    docker-compose -f my-docker-compose.yml logs -f

# usage example: make upsrv service=srv1
service=
upsrv:
    docker-compose -f my-docker-compose.yml up -d ${service}

config:
    docker-compose -f my-docker-compose.yml config

另外服务依赖的中间件一般都时启动与运行开销较大的系统，每次和我们的服务一起启停十分浪费时间，我们可以将这些依赖与我们的服务分别放在不同的compose配置文件中管理，这样我们每次重启自己的服务时，没有必要重新启动这些依赖，这样可以节省大量“等待”时间。

7. .env文件

有些时候，我们需要在compose的配置文件中放置一些“变量”，我们通常使用环境变量来实现“变量”的功能，比如：我们将srv1的镜像版本改为一个环境变量：

version: "3.2"
services:
  srv1:
    image: bigwhite/srv1:${SRV1_VER}
    container_name: srv1
    network_mode: "host"
  ... ...

docker compose支持通过同路径下的.env文件的方式docker-compose.yml中环境变量的值，比如：

// .env
SRV1_VER=dev

这样docker compose在启动srv1时会将.env中SRV1_VER的值读取出来并替换掉compose配置文件中的相应环境变量。通过这种方式，我们可以灵活的修改我们使用的镜像版本。

8. 优点与不足

使用docker compose工具，我们可以轻松拥有并快速启动一个all-in-one的运行环境，大幅度加速了部署、调试与测试的效率，在特定的工程环节，它可以给予开发与测试人员很大帮助。

不过这样的运行环境也有一些不足，比如：

对部署的机器/虚拟机配置要求较高；
这样的运行环境有局限，用在功能测试、持续集成、验收测试的场景下可以，但不能用来执行压测或者说即便压测也只是摸底，数据不算数的，因为所有服务放在一起，相互干扰；
服务或中间件多了以后，完全启动一次也要耐心等待一段时间。

“Gopher部落”知识星球正式转正（从试运营星球变成了正式星球）！“gopher部落”旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！部落目前虽小，但持续力很强，欢迎大家加入！

img{512x368}

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展；短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。2020年4月8日，中国三大电信运营商联合发布《5G消息白皮书》，51短信平台也会全新升级到“51商用消息平台”，全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite
“Gopher部落”知识星球：https://public.zsxq.com/groups/51284458844544

微信赞赏：
img{512x368}

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Go语言之父谈Go编程语言与环境

十月 6, 2021
0 条评论

本文永久链接 – https://tonybai.com/2021/10/06/the-go-programming-language-and-environment

2021年中旬，Go语言联合创始人Rob Pike应邀在线出席由UNSW Computing(悉尼新南威尔士大学计算机)组织主办的John Lions Distinguished Lectures，会上Rob Pike以Go之父身份讲述了究竟是什么将Go语言塑造成今天的这个样子以及进入Go生态系统的其他一些事物。

Rob Pike关于Go的观点总是高屋建瓴的，从这个talk中我们可以了解Go语言演化的来龙去脉，这对于我们理解Go、理解Go演化方向、理解Go生态会有较大帮助。由于仅有视频资料，这里将视频中的slide截图按顺序贴在这里，并配以slide中没有但talk中有的一些rob pike的重要观点，供大家参考。

Rob Pike：

(谦虚的说)Go还不能算是主流语言，但Go在全世界范围的影响力与发展远超当初预期。
我们知道：在众多编程语言中，Go可能不是那种interesting的语言。在当时，Go甚至不是一种有技术优势的语言。我们并没有试图推动编程语言理论或设计甚至实践的进步。我们对此并不介意，因为这不是我们的目标。
不知何故，这种语言已经成功地接管了云世界。它是主导docker、kubernetes以及基本上云原生计算基金会中的所有东西的开发语言，当然也包括这之外的其他很多项目。
多年前，有人预测Go是云计算基础设施语言，但现在这已经成为现实。

那么问题来了：一种本质上无人喜欢的语言是如何最终变得如此重要了呢？究竟发生了什么？

Rob Pike给出答案：

一门编程语言的成功取决于很多东西，而不仅仅是语言本身。
Go团队从一开始就知道这一点，于是他们不再局限于创造一门新编程语言，而是将目标定为创造一种编写软件的更好的方法上。因此这门新编程语言将被用于处理当时所用语言所解决不了的诸多问题：包括上面slide中列举的诸多问题。
虽然编程语言本身可以解决上面的一些问题，但仅语言本身还远不够。

Rob Pike：

我们遇到的一个最大的问题就是scale，并且scale拥有多个维度(数轴axes)，包括concurrency、engineering、dependencies。

Rob Pike：
- 这就是我们几个第一次碰面设计一门新编程语言时讨论的话题。

Rob Pike：
- 这就是Go实现的一个生产就绪的Web server的代码。
- 下面探讨fmt.Fprintf的第一个参数的类型，它很特殊，它是一个io.Writer接口类型。

Rob Pike：
- Go代码中充满了这种仅有一两个方法甚至是零个方法的接口类型，这些构成了Go文化之一。
- 我们相信，接口不应该为你所构建的整个世界预先定义，而应该在程序开发过程中有机地产生。让编译器解决一个接口是否好的问题，实际上是比强迫程序员优先解决这些问题更有效的进行软件演化的方式。(because we believe that interfaces should not be predefined for the entire world you are building. but instead should arise organically through program development. and having the compiler work out whether an interface is good or not is an actually more effective way to grow software than forcing the programmers to work it all out a priori)。

Rob Pike：
- 不同于其他编程语言，这些整型不能混合在一起运算(译注：需显式转型)。

Rob Pike：

我们的想法是，从概念上讲，处理并行性和并发性的开销在Go中是非常轻的。这是该语言的一个重要卖点。

Rob Pike：

一旦你把channel/select这些和goroutines结合起来，你就可以完全简单地、正交地把它们放在过程语言(procedure language)之上。并使并发变得简单，让那些以前我承认有时害怕它的人可以使用。

Rob Pike：

我们做了很多努力来建立一套非常好的核心库，允许你做一些事情，如网络、密码学、文本处理、格式化的IO，我们建立了一套核心库，建立在这些简单的接口的想法上，并使用这些接口和其他我们可以使用的机制，如并发性和内存安全属性等等。我们建立了基础库，这样你就可以写一个程序，只使用核心库，这将起到有效的作用，它也可以在生产中启动，并能够处理成千上万并发进行的负载。我们已经看到运行在内部启动的数百万个goroutine的二进制文件，因为它们是轻量级的，它们可以扩展。

Rob Pike：

也许Go的成功最重要的部分是这种兼容性承诺(Go1兼容性承诺)。
更重要的是，我们向用户承诺，如果你的代码今天能用，十年后也能用，而且确实如此。这种对用户社区的承诺是Go应用的一个巨大特点。实际上，在曲线上有一个膝盖型突起，你可以看到采用率的上升，工业界现在可以开始依赖它，因为他们知道，如果他们投资于它，它就会工作。书的作者也可以写书，他们知道十年后书中内容仍然有意义，这是我们故事的一个主要部分。

Rob Pike：

因此，所有这些元素都有一个主题，这个主题就是，如果你想发展一种语言或一个系统，特别是在开源世界中，你必须让别人容易进来。这并不仅仅意味着接受每一个他人提出的pull request，这更意味着创建一个系统，在这个系统中，大家可以很容易使用一种语言，比如：易于解析，易于用支持它的工具进行分析。可以单独工作的库，但被设计成可以相互协作以建立更大的系统。用于高质量工具开发的包，易于理解的开发，高速执行，简单的部署，易于移植。一个模块系统让每个人都能舒适地分享他们的代码，也包括一种鼓励人们共同成长的文化。