go-charts v1.1.0 版本发布,增加支持雷达图与漏斗图
go-chartsv1.1.0版本正式发布,增加支持雷达图与漏斗图,以及新增ant-design主题色,现已支持五种基本图表以及四种基本配色方案,快速高效的生成SVG或PNG图表。 新增的两种图表效果如下: 具体的使用方法以及参考示例可查看项目说明,地址如下:https://github.com/vicanso/go-charts
我夜以继日,加班加点开发了一个最简单的 Go Hello world 应用,虽然只是跑了打印一下就退出了,但是老板也要求我上线这个我能写出的唯一应用。
项目结构如下:
.
├── go.mod
└── hello.go
hello.go 代码如下:
package main
func main() {
println("hello world!")
}
并且,老板要求用 docker 部署,显得咱们紧跟潮流,高大上一点。。。
我在拜访了一些武林朋友之后,发现把整个过程丢到 docker 里面去编译一下就好了,一番琢磨之后,我得到了如下 Dockerfile:
FROM golang:alpine
WORKDIR /build
COPY hello.go .
RUN go build -o hello hello.go
CMD ["./hello"]
构建镜像:
$ docker build -t hello:v1 .
搞定,让我们凑近了看看。
docker run -it --rm hello:v1 ls -l /build
total 1260
-rwxr-xr-x 1 root root 1281547 Mar 6 15:54 hello
-rw-r--r-- 1 root root 55 Mar 6 14:59 hello.go
好家伙,我好不容易写出来的代码也在里面,看来代码不能写的烂,不然运维妹子偷看了要笑话我。。。
我们再看看镜像到底有多大,据说大了拉取镜像就会比较慢呢
$ docker docker images | grep hello
hello v1 2783ee221014 44 minutes ago 314MB
哇,居然有314MB,难道 docker build 一下变 Java 了吗?不是什么东西都是越大越好的。。。
让我们看看为啥这么大!
看看,我们跑第一个指令(WORKDIR)前就已经300+MB了,有点猛啊!
不管怎么说,我们先跑一下看看
$ docker run -it --rm hello:v1
hello world!
没问题呀,好歹可以工作嘛~
经过一番烟酒,加上朋友指点,发现原来我们用的那个基础镜像实在太大了。
$ docker images | grep golang
golang alpine d026981a7165 2 days ago 313MB
并且朋友告诉我可以把代码先编译好,再拷贝进去,就不用那个巨大的基础镜像了,不过说起来容易,我还是好好花了点功夫的,最后 Dockerfile 长这样:
FROM alpine
WORKDIR /build
COPY hello .
CMD ["./hello"]
跑一下试试
$ docker build -t hello:v2 .
...
=> ERROR [3/3] COPY hello . 0.0s
------
> [3/3] COPY hello .:
------
failed to compute cache key: "/hello" not found: not found
不对,hello 找不到,忘记先编译一下 hello.go 了,再来~
$ go build -o hello hello.go
再跑 docker build -t hello:v2 .,没问题,走两步试试。。。
$ docker run -it --rm hello:v2
standard_init_linux.go:228: exec user process caused: exec format error
失败!好吧,格式不对,原来我们开发机不是 linux 呀,再来~
$ GOOS=linux go build -o hello hello.go
重新 docker build 终于搞定了,赶紧跑下
$ docker run -it --rm hello:v2
hello world!
没问题,我们来看看内容和大小。
docker run -it --rm hello:v2 ls -l /build
total 1252
-rwxr-xr-x 1 root root 1281587 Mar 6 16:18 hello
里面只有 hello 这个可执行文件,再也不用担心别人鄙视我的代码了~
docker images | grep hello
hello v2 0dd53f016c93 53 seconds ago 6.61MB
hello v1 ac0e37173b85 25 minutes ago 314MB
哇,6.61MB,绝对可以!
看看,我们跑第一个指令(WORKDIR)前面只有 5.3MB 了,开心啊!
一顿炫耀之后,居然有人鄙视我,说现在流行什么多阶段构建,那么第二种方式到底有啥问题呢?细细琢磨之后发现,我们要能从 Go 代码构建出 docker 镜像,其中分为三步:
Go 代码,如果牵涉到 cgo 跨平台编译就会比较麻烦了docker 镜像shell 脚本或者 makefile 让这几步通过一个命令可以获得多阶段构建就是把这一切都放到一个 Dockerfile 里,既没有源码泄漏,又不需要用脚本去跨平台编译,还获得了最小的镜像。
爱学习,追求完美的我最终写出了如下 Dockerfile,多一行则肥,少一行则瘦:
FROM golang:alpine AS builder
WORKDIR /build
ADD go.mod .
COPY . .
RUN go build -o hello hello.go
FROM alpine
WORKDIR /build
COPY --from=builder /build/hello /build/hello
CMD ["./hello"]
第一个 FROM 开始的部分是构建一个 builder 镜像,目的是在其中编译出可执行文件 hello,第二个 From 开始的部分是从第一个镜像里 copy 出来可执行文件 hello,并且用尽可能小的基础镜像 alpine 以保障最终镜像尽可能小,至于为啥不用更小的 scratch,是因为 scratch 真的啥也没有,有问题连上去看一眼的机会都没有,而 alpine 也才 5MB,对我们的服务不会构成多少影响。
我们先跑了验证一下:
$ docker run -it --rm hello:v3
hello world!
没问题,正如预期!看看大小如何:
$ docker images | grep hello
hello v3 f51e1116be11 8 hours ago 6.61MB
hello v2 0dd53f016c93 8 hours ago 6.61MB
hello v1 ac0e37173b85 8 hours ago 314MB
跟第二种方法构建的镜像大小完全一样。再看看镜像里的内容:
$ docker run -it --rm hello:v3 ls -l /build
total 1252
-rwxr-xr-x 1 root root 1281547 Mar 6 16:32 hello
也是只有一个可执行的 hello 文件,完美!
跟第二个最终镜像基本是一致的,但我们简化了流程,只需要一个 Dockerfile,跑一条命令就好了,不需要我去整那些晦涩难懂的 shell 和 makefile 了。
至此,团队小伙伴都觉得完美,纷纷给我点赞!但是,既追求完美,又喜欢偷懒(摸鱼)的我觉得吧,每次都让我写出这么个增一行则肥,减一行则瘦的 Dockerfile,我还是觉得挺烦的,于是我瞒着老板写了个工具,我来秀一秀~~
# 安装一下先
$ GOPROXY=https://goproxy.cn/,direct go install github.com/zeromicro/go-zero/tools/goctl@latest
goctl migrate —verbose —version v1.3.1
# 一键编写 Dockerfile
$ goctl docker -go hello.go
搞定!看看生成的 Dockerfile 哈
FROM golang:alpine AS builder
LABEL stage=gobuilder
ENV CGO_ENABLED 0
ENV GOOS linux
ENV GOPROXY https://goproxy.cn,direct
WORKDIR /build
ADD go.mod .
ADD go.sum .
RUN go mod download
COPY . .
RUN go build -ldflags="-s -w" -o /app/hello ./hello.go
FROM alpine
RUN apk update --no-cache && apk add --no-cache ca-certificates tzdata
ENV TZ Asia/Shanghai
WORKDIR /app
COPY --from=builder /app/hello /app/hello
CMD ["./hello"]
其中几点可以了解下:
cgoGOPROXY-ldflags="-s -w" 以减小镜像尺寸ca-certificates,这样使用 TLS证书就没问题了我们看看用这个自动生成的 Dockerfile 构建出的镜像大小:
$ docker images | grep hello
hello v4 a7c3baed2706 4 seconds ago 7.97MB
hello v3 f51e1116be11 8 hours ago 6.61MB
hello v2 0dd53f016c93 8 hours ago 6.61MB
hello v1 ac0e37173b85 9 hours ago 314MB
略微大一点,这是因为我们安装了 ca-certificates 和 tzdata。验证一下:
我们看看镜像里有啥:
$ docker run -it --rm hello:v4 ls -l /app
total 832
-rwxr-xr-x 1 root root 851968 Mar 7 08:36 hello
也是只有 hello 可执行文件,并且文件大小从原来的 1281KB 减到了 851KB。跑一下看看:
$ docker run -it --rm hello:v4
hello world!
好了好了,不再纠缠于 Dockerfile 了,我要去学习其它知识了~
https://github.com/zeromicro/go-zero
https://gitee.com/kevwan/go-zero
觉得不错吗?欢迎打赏吆,打赏只需点亮 GitHub 小星星⭐️
关注『微服务实践』公众号并点击 交流群 获取社区群二维码。
微信关注我们
转载内容版权归作者及来源网站所有!
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。
Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。
Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。
Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。