标签 Bash 下的文章

从DevOps到日常脚本:聊聊Go语言的多面性

本文永久链接 – https://tonybai.com/2024/10/08/go-languages-versatility-from-devops-to-daily-scripts

2024年初,TIOBE编程语言排行榜上,Go再次进入了前十,并在之后又成功冲高至第七名

Go语言的排名上升,至少在Reddit Go论坛上帖子数量和在线人数上得到了体现,尽管目前与Rust热度仍有差距,但可见Go的关注度在提升:


2024年国庆节假期某天下午的实时在线数对比

随着Go语言人气的上升,论坛中的问题也变得愈发多样化。许多Gopher常常问及为何Go是DevOps语言Go适合用作脚本语言吗等问题,这些都反映了Go语言的多面性。

从最初的系统编程语言,到如今在DevOps领域的广泛应用,再到一些场合被探索用作脚本语言,Go展现出了令人惊叹的灵活性和适应性。在本篇文章中,我们将聚焦于Go语言在DevOps领域的应用以及它作为脚本替代语言的潜力,聊聊其强大多面性如何满足这些特定场景的需求。

1. Go在DevOps中的优势

随着DevOps的发展,平台工程(Platform Engineering)这一新兴概念逐渐兴起。在自动化任务、微服务部署和系统管理中,编程语言的作用变得愈发重要。Go语言凭借其高性能、并发处理能力以及能够编译成单一二进制文件的特点,越来越受到DevOps领域开发人员的青睐,成为开发DevOps工具链的重要组成部分。

首先,Go的跨平台编译能力使得DevOps团队可以在一个平台上编译,然后在多个不同的操作系统和架构上运行,结合编译出的单一可执行文件的能力,大大简化了部署流程,这也是很多Go开发者认为Go适合DevOps的第一优势:

$GOOS=linux GOARCH=amd64 go build -o myapp-linux-amd64 main.go
$GOOS=linux GOARCH=arm64 go build -o myapp-linux-arm64 main.go
$GOOS=darwin GOARCH=amd64 go build -o myapp-darwin-amd64 main.go
$GOOS=windows GOARCH=amd64 go build -o myapp-windows-amd64.exe main.go

其次,Go的标准库仿佛“瑞士军刀”,开箱即用,为DevOps场景提供了所需的丰富的网络、加密和系统操作功能库,大幅降低对外部的依赖,即便不使用第三方包生态系统,也可以满足大部分的DevOps功能需求。

此外,Go的goroutines和channels为处理高并发任务提供了极大便利,这在DevOps中也尤为重要。例如,以下代码展示了如何使用goroutines并发检查多个服务的健康状态:

func checkServices(services []string) {
    var wg sync.WaitGroup
    for _, service := range services {
        wg.Add(1)
        go func(s string) {
            defer wg.Done()
            if err := checkHealth(s); err != nil {
                log.Printf("Service %s is unhealthy: %v", s, err)
            } else {
                log.Printf("Service %s is healthy", s)
            }
        }(service)
    }
    wg.Wait()
}

并且,许多知名的DevOps基础设施、中间件和工具都是用Go编写的,如Docker、Kubernetes、Prometheus等,集成起来非常丝滑。这些工具的成功进一步证明了Go在DevOps领域的适用性。

2. Go作为脚本语言的潜力

在传统的DevOps任务中,Python和Shell脚本长期以来都是主力军,它们(尤其是Python)以其简洁的语法和丰富的生态系统赢得了DevOps社区的广泛青睐。然而,传统主力Python和Shell脚本虽然灵活易用,但在处理大规模数据或需要高性能的场景时往往力不从心。此外,它们的动态类型系统可能导致运行时错误,增加了调试难度。

随着Go的普及,它的“超高性价比”逐渐被开发运维人员所接受:既有着接近于脚本语言的较低的学习曲线与较高的生产力(也得益于Go超快的编译速度),又有着静态语言的高性能,还有单一文件在部署方面的便利性

下面是一个简单的文件处理脚本,用于向大家展示Go的简单易学:

package main

import (
    "bufio"
    "fmt"
    "os"
    "strings"
)

func main() {
    file, err := os.Open("input.txt")
    if err != nil {
        fmt.Println("Error opening file:", err)
        return
    }
    defer file.Close()

    scanner := bufio.NewScanner(file)
    for scanner.Scan() {
        line := scanner.Text()
        if strings.Contains(line, "ERROR") {
            fmt.Println(line)
        }
    }
}

这个示例虽然要比同等功能的Python或shell代码行数要多,但由于Go的简单和直观,多数人都很容易看懂这段代码。

此外,Go的静态强类型系统可以在编译时捕获更多错误,避免在运行时的调试,提高了脚本在运行时的可靠性。

开发运维人员眼中的脚本语言,如Shell脚本和Python脚本,通常是直接基于源代码进行解释和运行的。实际上,Go语言同样可以实现这一点,而其关键工具就是go run命令。这个命令允许开发者快速执行Go代码,从而使Go源码看起来更像是“脚本”,下面我们就来看看go run。

3. go run:桥接编译型语言与脚本语言的利器

我们知道go run命令实际上是编译和运行的组合,它首先编译源代码,然后立即执行生成的二进制文件。这个过程对用户来说是透明的,使得Go程序可以像脚本一样方便地运行。这一命令也大大简化了Go程序的开发流程,使Go更接近传统的脚本语言工作流。可以说,通过go run,Go语言向脚本语言的使用体验更靠近了一步。

此外,go run与go build在编译阶段的行为并不完全相同:

  • go run在运行结束后,不保留编译后的二进制文件;而go build生成可执行文件并保留。

  • go run编译时默认不包含调试信息,以减少构建时间;而go build则保留完整的调试信息。

  • go run可以使用-exec标志指定运行环境,比如:

$go run -exec="ls" main.go
/var/folders/cz/sbj5kg2d3m3c6j650z0qfm800000gn/T/go-build1742641170/b001/exe/main

我们看到,如果设置了-exec标志,那么go run -exec=”prog” main.go args编译后的命令执行就变为了”prog a.out args”。go run还支持跨平台模拟执行,当GOOS或GOARCH与系统默认值不同时,如果在\$PATH路径下存在名为”go_\$GOOS_\$GOARCH_exec”的程序,那么go run就会执行:

$go_$GOOS_$GOARCH_exec a.out args

比如:go_js_wasm_exec a.out args
  • go run通常用于运行main包,在go module开启的情况下,go run使用的是main module的上下文。go build可以编译多个包,对于非main包时只检查构建而不生成输出

  • go run还支持运行一个指定版本号的包

当指定了版本后缀(如@v1.0.0或@latest)时,go run会进入module-aware mode(模块感知模式),并忽略当前目录或上级目录中的go.mod文件。这意味着,即使你当前的项目中存在依赖管理文件go.mod,go run也不会影响或修改当前项目的依赖关系,下面这个示例展示了这一点:

$go run golang.org/x/example/hello@latest

go: downloading golang.org/x/example v0.0.0-20240925201653-1a5e218e5455
go: downloading golang.org/x/example/hello v0.0.0-20240925201653-1a5e218e5455
Hello, world!

这个功能特别适合在不影响主模块依赖的情况下,临时运行某个工具或程序。例如,如果你只是想测试某个工具的特定版本,或者快速运行一个远程程序包,而不希望它干扰你正在开发的项目中的依赖项,这种方式就很实用。

不过有一点要注意的是:go run的退出状态并不等于编译后二进制文件的退出状态,看下面这个示例:

// main.go成功退出
$go run main.go
Hello from myapp!
$echo $?
0

// main.go中调用os.Exit(2)退出
$go run main.go
Hello from myapp!
exit status 2
$echo $?
1

go run使用退出状态1来表示其运行程序的异常退出状态,但这个值和真实的exit的状态值不相等。

到这里我们看到,go run xxx.go可以像bash xxx.sh或python xxx.py那样,以“解释”方式运行一个Go源码文件。这使得Go语言在某种程度上具备了脚本语言的特性。然而,在脚本语言中,例如Bash或Python等,用户可以通过将源码文件设置为可执行,并在文件的首行添加适当的解释器指令,从而直接运行脚本,而无需显式调用解释器。这种灵活性使得脚本的执行变得更加简便。那么Go是否也可以做到这一点呢?我们继续往下看。

4. Go脚本化的实现方式

下面是通过一些技巧或第三方工具实现Go脚本化的方法。对于喜欢使用脚本的人来说,最熟悉的莫过于shebang(即解释器指令)。在许多脚本语言中,通过在文件的第一行添加指定的解释器路径,可以直接运行脚本,而无需显式调用解释器。例如,在Bash或Python脚本中,通常会看到这样的行:

#!/usr/bin/env python3

那么Go语言支持shebang吗? 是否可以实现实现类似的效果呢?我们下面来看看。

4.1 使用“shebang(#!)”运行Go脚本

很遗憾,Go不能直接支持shebang,我们看一下这个示例main.go:

#!/usr/bin/env go run 

package main

import (
    "fmt"
    "os"
)

func main() {
    s := "world"
    if len(os.Args) > 1 {
        s = os.Args[1]
    }
    fmt.Printf("Hello, %v!\n", s)
}

这一示例的第一行就是一个shebang解释器指令,我们chmod u+x main.go,然后执行该Go“脚本”:

$./main.go
main.go:1:1: illegal character U+0023 '#'

这个执行过程中,Shell可以正常识别shebang,然后调用go run去运行main.go,问题就在于go编译器视shebang这一行为非法语法!

常规的shebang写法行不通,我们就使用一些trick,下面是改进后的示例:

//usr/bin/env go run $0 $@; exit

package main

import (
    "fmt"
    "os"
)

func main() {
    s := "world"
    if len(os.Args) > 1 {
        s = os.Args[1]
    }
    fmt.Printf("Hello, %v!\n", s)
}

这段代码则可以chmod +x 后直接运行:

$./main.go
Hello, world!
$./main.go gopher
Hello, gopher!

这是因为它巧妙地结合了shell脚本和Go代码的特性。我们来看一下第一行:

//usr/bin/env go run $0 $@; exit

这一行看起来像是Go的注释,但实际上是一个shell命令。当文件被执行时,shell会解释这一行,/usr/bin/env用于寻找go命令的路径,go run \$0 \$@ 告诉go命令运行当前脚本文件(\$0)以及所有传递给脚本的参数(\$@),当go run编译这个脚本时,又会将第一行当做注释行而忽略,这就是关键所在。最后的exit确保shell在Go程序执行完毕后退出。如果没有exit,shell会执行后续Go代码,那显然会导致报错!

除了上述trick外,我们还可以将Go源码文件注册为可执行格式(仅在linux上进行了测试),下面就是具体操作步骤。

4.2 在Linux系统中注册Go为可执行格式

就像在Windows上双击某个文件后,系统打开特定程序处理对应的文件一样,我们也可以将Go源文件(xxx.go)注册为可执行格式,并指定用于处理该文件的程序。实现这一功能,我们需要借助binfmt_misc。binfmt_misc是Linux内核的一个功能,允许用户注册新的可执行文件格式。这使得Linux系统能够识别并执行不同类型的可执行文件,比如脚本、二进制文件等。

我们用下面命令将Go源文件注册到binfmt_misc中:

echo ':golang:E::go::/usr/local/bin/gorun:OC' | sudo tee /proc/sys/fs/binfmt_misc/register

简单解释一下上述命令:

  • :golang::这是注册的格式的名称,可以自定义。
  • E:::表示执行文件的魔数(magic number),在这里为空,表示任何文件类型。
  • go:::指定用于执行的解释器,这里是go命令。
  • /usr/local/bin/gorun:指定用于执行的程序路径,这里是一个自定义的gorun脚本
  • :OC:表示这个格式是可执行的(O)并且支持在运行时创建(C)。

当你执行一个Go源文件时,Linux内核会检查文件的类型。如果文件的格式与注册的格式匹配,内核会调用指定的解释器(在这个例子中是gorun)来执行该文件。

gorun脚本是我们自己编写的,源码如下:

#!/bin/bash

# 检查是否提供了源文件
if [ -z "$1" ]; then
  echo "用法: gorun <go源文件> [参数...]"
  exit 1
fi

# 检查文件是否存在
if [ ! -f "$1" ]; then
  echo "错误: 文件 $1 不存在"
  exit 1
fi

# 将第一个参数作为源文件,剩余的参数作为执行参数
GO_FILE="$1"
shift  # 移除第一个参数,剩余的参数将会被传递

# 使用go run命令执行Go源文件,传递其余参数
go run "$GO_FILE" "$@"

将gorun脚本放置带/usr/local/bin下,并chmod +x使其具有可执行权限。

接下来,我们就可以直接执行不带有”shebang”的正常go源码了:

// main.go
package main

import (
    "fmt"
    "os"
)

func main() {
      s := "world"
      if len(os.Args) > 1 {
          s = os.Args[1]
      }
      fmt.Printf("Hello, %v!\n", s)
}

直接执行上述源文件:

$ ./main.go
Hello, world!
$ ./main.go gopher
Hello, gopher!

4.3 第三方工具支持

Go社区也有一些将支持将Go源文件视为脚本的解释器工具,比如:traefik/yaegi等。

$go install github.com/traefik/yaegi/cmd/yaegi@latest
go: downloading github.com/traefik/yaegi v0.16.1
$yaegi main.go
Hello, main.go!

yaegi还可以像python那样,提供Read-Eval-Print-Loop功能,我们可以与yaegi配合进行交互式“Go脚本”编码:

$ yaegi
> 1+2
: 3
> import "fmt"
: 0xc0003900d0
> fmt.Println("hello, golang")
hello, golang
: 14
>

类似的提供REPL功能的第三方Go解释器还包括:cosmos72/gomacrox-motemen/gore等,这里就不深入介绍了,感兴趣的童鞋可以自行研究。

5. 小结

在本文中,我们探讨了Go语言在DevOps和日常脚本编写中的多面性。首先,Go语言因其高性能、并发处理能力及跨平台编译特性,成为DevOps领域的重要工具,助力于自动化任务和微服务部署。其次,随着Go语言的普及,其作为脚本语言的潜力逐渐被开发运维人员认识,Go展现出了优于传统脚本语言的高效性和可靠性。

我们还介绍了Go脚本的实现方式,包括使用go run命令,它使得Go程序的执行更像传统脚本语言,同时也探讨了一些技巧和工具,帮助开发者将Go源码文件作为可执行脚本直接运行。通过这些探索,我们可以看到Go语言在现代开发中的灵活应用及其日益增长的吸引力。

随着AI能力的飞速发展,使用Go编写一个日常脚本就是分分钟的事情,但Go的特性让这样的脚本具备了传统脚本语言所不具备的并发性、可靠性和性能优势。我们有理由相信,Go在DevOps和脚本编程领域的应用将会越来越广泛,为开发者带来更多的可能性和便利。

6. 参考资料


Gopher部落知识星球在2024年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。同时,我们也会加强代码质量和最佳实践的分享,包括如何编写简洁、可读、可测试的Go代码。此外,我们还会加强星友之间的交流和互动。欢迎大家踊跃提问,分享心得,讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落,享受coding的快乐! 欢迎大家踊跃加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

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

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily
  • Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed

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

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

本文永久链接 – 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}

img{512x368}
img{512x368}
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语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats