zoukankan      html  css  js  c++  java
  • docker support for inner loop

    Inner Loop vs Outer Loop

    https://opensource.com/article/21/6/open-source-developer-tools

    inner loop是开发者的最常做的事情, 编码 运行 验证 调试

    outer loop是我们经常提及的CI/CD, 从代码提交入库, 到CI进行测试,测试通过后构建,构建成功后, 进入CD, 或者发布版本, 或者在发布后部署到产品环境中。

    The industry is still working on perfecting how a developer's time is spent. We can divide a developer's major tasks into two different "loops":

    • Inner loop: These are the most common tasks developers do, the ones that fully utilize their skillsets: code, run, validate, and debug. This is the classical developer loop.

    innerloop.png

    Inner loop developer tasks

    (Nimisha Mukherjee, CC BY-SA 4.0)

    • Outer loop: This is where a developer's code goes through continuous integration and continuous delivery (CI/CD) and gets deployed to production. On Gitlab and similar platforms, a developer's pull request (PR) gets merged to the main branch, CI/CD kicks in and creates the build, runs the necessary tests, and deploys to the specified environments. This is a DevOps loop.

    outerloop.png

    Outer loop developer tasks

    docker practice

    https://docs.docker.com/ci-cd/best-practices/

    docker一般被认为是部署工具

    即, 在开发者开发完毕代码, 提交到版本库中, 自动进行测试 构建 部署的过程。

    但是这并不符合 DEVOPS文化, 其要求开发者的开发环境 和 部署环境要求一致。

    所以docker 就提供了 这种功能, 在本地开发者可以通过构造与部署相同的容器环境,在此环境中进行本地化的构建和测试。

    Inner and outer loops

    To get started, one of the most important things when working with Docker and any CI/CD is to understand when you need to test with the CI, and when you can do this locally. At Docker, we think about how developers work in terms of their inner loop (code, build, run, test) and their outer loop (push changes, CI build, CI test, deployment).

    CI/CD inner and outer loop

    Before you think about optimizing your CI/CD, it is important to think about your inner loop and how it relates to the outer loop (the CI). We know that most users don’t prefer ‘debugging through the CI’. Therefore, it is better if your inner loop and outer loop are as similar as possible. We recommend that you run unit tests as part of your docker build command by adding a target for them in your Dockerfile. This way, as you are making changes and rebuilding locally, you can run the same unit tests you would run in the CI on your local machine using a simple command.

    The blog post Go development with Docker is a great example of how you can use tests in your Docker project and re-use them in the CI. This also creates a shorter feedback loop on issues and reduces the amount of pulls and builds your CI needs to do.

    docker技术点

    https://docs.docker.com/develop/develop-images/multistage-build/

    在dockerfile中支持多target定义。

    # syntax=docker/dockerfile:1
    FROM golang:1.16 AS builder
    WORKDIR /go/src/github.com/alexellis/href-counter/
    RUN go get -d -v golang.org/x/net/html  
    COPY app.go    ./
    RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .
    
    FROM alpine:latest  
    RUN apk --no-cache add ca-certificates
    WORKDIR /root/
    COPY --from=builder /go/src/github.com/alexellis/href-counter/app ./
    CMD ["./app"]  

    运行只运行其中一个target

     docker build -t alexellis2/href-counter:latest .

    样例

    https://www.docker.com/blog/containerize-your-go-developer-environment-part-1/

    https://www.docker.com/blog/containerize-your-go-developer-environment-part-2/

    在dockerfile中定义 unittest test

    # syntax = docker/dockerfile:1-experimental
    
    FROM --platform=${BUILDPLATFORM} golang:1.14.3-alpine AS base
    WORKDIR /src
    ENV CGO_ENABLED=0
    COPY go.* .
    RUN go mod download
    COPY . .
    
    FROM base AS build
    ARG TARGETOS
    ARG TARGETARCH
    RUN --mount=type=cache,target=/root/.cache/go-build \
    GOOS=${TARGETOS} GOARCH=${TARGETARCH} go build -o /out/example .
    
    FROM base AS unit-test
    RUN --mount=type=cache,target=/root/.cache/go-build \
    go test -v .
    
    FROM scratch AS bin-unix
    COPY --from=build /out/example /
    ...

    在makefile中定义unittest target, 对应docker build unittest

    all: bin/example
    test: unit-test
    
    PLATFORM=local
    
    .PHONY: bin/example
    bin/example:
        @docker build . --target bin \
        --output bin/ \
        --platform ${PLATFORM}
    
    .PHONY: unit-test
    unit-test:
        @docker build . --target unit-test

    K8S for INNER LOOP

    https://medium.com/geekculture/developing-on-kubernetes-the-inner-outer-loop-6957f9597f7a

    出处:http://www.cnblogs.com/lightsong/ 本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接。
  • 相关阅读:
    U3D不同平台载入XML文件的方法——IOS MAC Android
    C++使用规范小记
    设置角色对象可见性
    编辑器菜单操作
    U3D资源动态加载异步方案探究
    Animation动画
    Unity3D失去焦点时继续渲染
    C#打开当前目录
    组件模式代码实践(C#版本)
    Unity3D批处理脚本
  • 原文地址:https://www.cnblogs.com/lightsong/p/15735785.html
Copyright © 2011-2022 走看看