服务治理之 容器 基础镜像 Base Image 规范

Posted by 董江 on Monday, November 7, 2022

容器 基础镜像 Base Image 规范

应用Application打包到镜像Image中形成业务镜像Application Image,往往需要一个基础镜像Base Image作为我们应用服务的外部环境.

那么问题来了,基础镜像从何而来?

官方推荐: 直接从官网仓库pull一个,但由于官网被墙的比较厉害,所以这里介绍一些官方提供以及个人方法。

1. 基础镜像分类

基础镜像(base image)规范两大类:

  1. build base image: 将代码 通过外挂Volume 挂载到 基础镜像(build base image)进行编译

  2. runtime base image:将编译产物 外挂Volume 放入 基础镜像(runtime base image) 或者 基于标准容器(runtime base image)构建业务容器

1.1 外挂Volume 挂载到 基础镜像

apiVersion: v1
kind: Pod
metadata:
  name: ext-volume
spec:
  containers:
  - image: centos:7 #base image
    name: ext-volume
    command: [ "/test-data/bin/application", "-m", "release" ]
    volumeMounts:
    - mountPath: /test-data
      name: bin-volume
  volumes:
  - name: bin-volume
    hostPath:
      path: /data/bin
      type: Directory

外部的二进制文件,通过volume的方式挂载到base image中,执行pod

优势: 1.基础镜像可随时替换,不需要重新制作新镜像(比如:image中出现安全问题、更换国产化OS等) 2.业务部署方式统一, 机器上的镜像数量少,占用空间少,不会因为image的大小导致磁盘不可用 劣势: 1.yaml设计规范统一问题(一般需要云平台统一支持) 2.加大管理复杂性,业务application二进制多版本管理的问题

1.2 基于基础镜像 构建 业务镜像

FROM scratch  # 基础镜像
ADD application /
CMD ["/application", "-m", "release"]
apiVersion: v1
kind: Pod
metadata:
  name: inner-docker
spec:
  containers:
  - image: application:latest # application image
    name: inner-docker

基于基础镜像 base image 构建 业务镜像 application image

优势: 1.yaml设计灵活 2.application image 可以通过 register hub 进行版本离 劣势: 1.基础镜像可随时替换,需要重新制作新镜像(比如:image中出现安全问题、更换国产化OS等) 2.业务部署方式不统一, 机器上的镜像数量多,占用空间多,因为image的对导致磁盘空间满

2. 限制 alpine 使用; scratch 不推荐使用

alpine 避免长期使用,本身基础镜像有安全漏洞,减少维护成本,限制业务使用

scratch 是空镜像,特殊的一种说明,推进不使用(除非是基础C语言软件)

3. 基础镜像构建方式

3.1 build base image

golang为例:

FROM centos:7

ENV DEBIAN_FRONTEND noninteractive

RUN apt-get update && \
    apt-get install --yes \
          gcc curl strace \
          ca-certificates netbase \
          procps lsof psmisc \
          openssh-server

RUN mkdir /usr/local/go-bootstrap && \
    curl --silent https://storage.googleapis.com/go-builder-data/gobootstrap-linux-arm64.tar.gz | \
    tar -C /usr/local/go-bootstrap -zxv

ENV GOROOT_BOOTSTRAP /usr/local/go-bootstrap
RUN curl -o  /usr/local/bin/stage0 https://storage.googleapis.com/go-builder-data/buildlet-stage0.linux-arm64 && \
    chmod +x /usr/local/bin/stage0

ENV GO_BUILD_KEY_DELETE_AFTER_READ true
ENV GO_BUILD_KEY_PATH /buildkey/gobuildkey

编译为基础的 golang:1.x.x-centos-7 编译基础镜像

业务可以通过的Dockerfile 使用此镜像进行代码镜像内编译

# Build the manager binary
FROM golang:1.x.x-centos-7 as builder

RUN apk add --no-cache gcc musl-dev libc6-compat

WORKDIR /workspace
COPY go.mod go.mod
COPY go.sum go.sum

# Copy the go source
COPY cmd/ cmd/
COPY pkg/ pkg/
COPY vendor/ vendor/

# Build
RUN CGO_ENABLED=0 go build -ldflags "-linkmode external -extldflags -static" -o /application./cmd/main.go

3.2 runtime base image

统一的runtime base image 需要对基础的os添加必要的lib包.

举个例子: 添加基础的lib包

FROM centos:7

RUN \
	mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup && \
	curl -Lo /etc/yum.repos.d/CentOS-Base.repo http://mirrors.cloud.tencent.com/repo/centos7_base.repo && \
	curl -Lo /etc/yum.repos.d/epel-7.repo http://mirrors.cloud.tencent.com/repo/epel-7.repo && \
	yum clean all && \
	yum makecache && \
	yum update -y && \
	yum install -y automake autoconf readline libtool make which gcc-c++ cmake3 ccache python-devel cargo glibc-static gperf man flex bison autoconf-archive git patch libstdc++ libstdc++-devel libstdc++-static yasm

ENV \
	TZ=Asia/Shanghai \
	LANG=en_US.utf8 \
	LC_ALL=en_US.utf8 \
	PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/local/lib64/pkgconfig:$PKG_CONFIG_PATH \
	LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
	
WORKDIR $GOPATH

CMD ["/bin/bash"]

「如果这篇文章对你有用,请随意打赏」

Kubeservice博客

如果这篇文章对你有用,请随意打赏

使用微信扫描二维码完成支付