studybook
  • Introduction
  • 실무 하며 깨닫는 부분 정리
    • 옵션에 대해서
    • 코드 작성의 순서
    • 자바 프로그램에 문제가 생겼다면
    • 장애 대처법
  • Logstash, Beats 정리
  • Zookeeper 정리
  • Message Queue 정리
    • RabbitMQ 삽질
  • Java 관련 정리
    • Java Primitive Wrapper class
    • Java NIO
    • Java8 Double colon operator
    • Effective Java
      • 4장
      • 5장
      • 6장 - Enum, Annotation
      • 7장 - Method
      • 8장 - 프로그래밍 일반
      • 9장 - Exception
    • Java8 Lambda expression
    • JDBC
    • Linux에서 WatchService 이상동작
  • Spring 관련 정리
    • Spring Bean init, destroy 순서
    • Spring Async Controller
    • Spring Executable jar 웹 개발 및 배포
    • Spring Boot Font 배포 에러
    • Spring AOP
      • Spring AOP로 모든 Request 로그 남기기
    • Spring Cache
    • Spring Cloud
      • Consul로 spring 설정 관리하기
    • Spring Test
      • Spring Test DirtiesContext
      • Spring Test MockBean, SpyBean
      • Spring Test Dynamic @Scheduled
    • Spring JDBC
    • Spring Validation
    • Spring Transaction Management
      • Spring with JTA 삽질
    • Spring에서 효율적으로 Static resource 관리하기
    • Zuul을 사용해서 Spring Reverse proxy 만들기
    • Spring Security
    • 스프링 어노테이션이 안 먹힐 때 의심해볼만한 것
    • Spring Data
    • Spring Webflux
      • Tobi 강연
  • 코드 리팩토링
    • 한번에 하나씩
  • 지속적 통합 (CI)
    • Jenkins pipeline 삽질기
  • Log Aggregator 정리
    • Flume 테스트
    • Fluentd 테스트
  • Web Socket 정리
  • Akka
    • Actor 모델
    • Supervision
  • IE 8 대응 정리
  • 함수형 프로그래밍
    • 모나드
  • Netty
    • Netty 기본 예제
    • Netty 주요 특징
    • Netty 부트스트랩
    • Netty 채널 파이프라인, 코덱
    • Netty 이벤트 모델
    • Netty 바이트 버퍼
  • 스칼라 관련 정리
    • Maven으로 컴파일하기
    • Scala def 괄호 여부의 차이
    • 스칼라 function, method 차이점
    • ScalaTest와 Spring 연동하기
    • Programming in Scala
  • J2S 컨퍼런스
  • Android
    • 테스트
    • NDK
  • DDOS
  • HTTP
  • HttpClient
  • Container
    • Image 개요
    • cri-o
    • kata containers
    • Open Container Initiative Image
    • Buildkit
  • Github pages
  • Static Website
  • Webhook
  • Service Discovery Tools
    • Etcd
    • Eureka
    • Consul
      • ACL
    • 비교
  • React
    • JSX
    • React Element
    • Components, Props
    • State, Lifecycle
    • Handling Event
    • Flux
  • Vagrant
    • SSH 접속
  • Linux
    • Systemd
    • Alternatives
  • Messaging protocols
    • XMPP
    • AMQP
  • Windows
    • Windows10 내장 우분투에 ssh 클라이언트로 접속하기
    • Windows10 Hyper-V와 Virtual Box가 충돌을 일으켰을 때
    • Hyper-V 기반 docker에서 Shared Drives 설정 실패할 때
    • 윈도우 개발환경 설정
    • Docker desktop 없이 docker 환경 세팅하기
    • UWP 앱을 항상 관리자권한으로 실행하는 바로가기 만들기
  • Spring camp 2017
    • Project Reactive
    • 이벤트 소싱
    • CQRS
  • Spring webflux
  • 리액티브 프로그래밍
  • Linux Settings
    • 홈서버 백업 및 복구기
    • 홈서버 트러블슈팅
  • Kubernetes
    • k3s 설치 및 삽질
    • pod resources
    • Argo workflow
    • 트러블 슈팅
      • Kubernetes namespace의 phase가 Terminating에서 멈춰있을 때
    • 쿠버네티스 마스터
    • Knative
    • Knative Pipeline
    • Aggrerated API server
    • Accessing the API
      • Authenticating
  • Sonarqube
  • HTTP/2
  • Go
    • Go Module
    • Go dependency injection
    • Go Error handling
    • Go in Action
      • 3장 패키지
      • 4장 배열, 슬라이스, 맵
      • 5장 GO의 타입 시스템
      • 6장 동시성
      • 7장 동시성 패턴
      • 8장 표준 라이브러리
      • 9장 테스트와 벤치마킹
    • Go Channel 사용법
  • Cloud Native
Powered by GitBook
On this page
  1. Container

Buildkit

PreviousOpen Container Initiative ImageNextGithub pages

Last updated 1 year ago

  1. buildkit

    moby 프로젝트의 일환으로 2017년부터 분리하여 개발 시작. 2018년 도커 18.09버전부터 도커엔진에 정식으로 탑재됨. 모비 엔진 빌드 기능의 성능, 스토리지 관리, 확장성 개선을 목표로 함. 기존의 docker build를 완전히 대체하는 것을 목표로 개발되고 있음 ()

    DOCKER_BUILDKIT=1 docker build .

    docker buildx build

  2. LLB (Low-Level Builder)

    {
      "Op": {
        "Op": {
          "source": {
            "identifier": "docker-image://docker.io/library/alpine:latest"
          }
        },
        "platform": {
          "Architecture": "amd64",
          "OS": "linux"
        },
        "constraints": {}
      },
      "Digest": "sha256:665ba8b2cdc0cb0200e2a42a6b3c0f8f684089f4cd1b81494fbb9805879120f7",
      "OpMetadata": {
        "caps": {
          "source.image": true
        }
      }
    }

    LLB는 저수준 바이너리 포맷으로, 빌드에 필요한 의존성 그래프를 그리는 것에 사용됨. LLB와 Dockerfile의 관계가 LLVM IR과 C언어의 관계와 동일하다고 보면 됨. LLB의 경우 특정 플랫폼에 구애받지 않아 다양한 문법으로 구현할 수 있음. Dockerfile 외에도 Mockerfile이라던가 Gockerfile, HLB와 같은 LLB를 지원하는 여러 문법들이 존재하고 있고, 아예 코드를 짜서 이미지를 빌드하는것도 가능함.

  3. 개선점

    1. 자동화된 GC

      주어진 gcpolicy에 따라 저장된 layer들을 자동으로 정리하는 기능이 추가됨

      [worker.oci]
        [[worker.oci.gcpolicy]]
          keepBytes = 512000000
          keepDuration = 172800
          filters = [ "type==source.local", "type==exec.cachemount", "type==source.git.checkout"]
        [[worker.oci.gcpolicy]]
          all = true
          keepBytes = 1024000000
    2. 손쉬운 Multi-Platform 빌드 지원

      platform=linux/amd64,linux/arm64와 같이 platform을 지정해서 이미지를 빌드할 수 있게 추가되었음. 단, 사용자의 Dockerfile에 이미 관련 내용이 추가되어있어야 함. FROM **--platform=$BUILDPLATFORM** golang:1.17-alpine AS build

    3. 병렬 빌드 지원

      multi-staged 빌드의 경우 각 stage가 모두 병렬로 실행되며 만약 서로 다른 두 **stage 사이에 의존 관계가 있는 경우에만 완료를 기다림.

    4. 개선된 캐시 기능

      LLB 각 operation의 checksum과 마운트된 데이터를 비교해서 사용하는 새로운 캐싱 시스템이 적용됨. 이에 따라 좀 더 빠르고 정확한 캐싱이 가능함. 또한 캐시의 export/import를 지원함. 캐시를 로컬 저장소 뿐만 아니라 registry에 저장하여 여러 buildkit daemon들이 cache를 공유하게 하는 것도 가능해짐.

    5. 새로운 빌드 기능 제공

      이미지를 빌드할 때 캐시 전용 공간이나 secret 등을 mount 할 수 있는 기능이 추가되었고, network mode나 security context를 설정하는 기능등 다양한 기능들을 새로운 Dockerfile 문법과 함께 제공 중.

    6. rootless로 사용 가능

  4. buildkit에 최적화된 Dockerfile 작성방법

    1. 최대한 stage를 잘게 나눠서 사용하기

      stage를 나눠서 구성했을 때 buildkit의 병렬 빌드 기능을 최대한 활용할 수 있음. 뿐만 아니라 완성된 이미지의 크기를 좀 더 작게 관리할 수 있음.

      1. base stage를 만들어 여러 stage에서 공유하기

        FROM ubuntu AS base
        RUN apt-get update && apt-get install git
        
        FROM base AS src1
        RUN git clone …
        
        FROM base AS src2
        RUN git clone …
      2. 불필요한 stage는 건너뛸 수 있게 구성하기

        ARG BUILD_VERSION=1
        
        FROM alpine AS base
        RUN …
        
        FROM base AS branch-version-1
        RUN touch version1
        
        FROM base AS branch-version-2
        RUN touch version2
        
        FROM branch-version-${BUILD_VERSION} AS after-condition
        
        FROM after-condition
        RUN …
    2. dependency를 저장할 때는 --mount=cache를 활용하기

      # syntax=docker/dockerfile:1.2
      # Build Stage
      FROM maven as builder
      
      COPY pom.xml ~/pom.xml
      RUN --mount=type=cache,target=~/.m2,id=java-sample-cache,uid=500,gid=500 \
          mvn -Dmaven.repo.local=/home1/irteam/.m2/repository dependency:go-offline
      
      COPY src ~/src
      RUN --mount=type=cache,target=~/.m2,id=java-sample-cache,uid=500,gid=500 \
          mvn -Dmaven.repo.local=~/.m2/repository install
      
      # Main Stage
      ARG DEPENDENCY=~/build/dependency
      COPY --from=builder ${DEPENDENCY}/BOOT-INF/lib ~/apps/spring-boot-app/lib
      COPY --from=builder ${DEPENDENCY}/META-INF ~/apps/spring-boot-app/META-INF
      
      COPY entrypoint.sh ~/entrypoint.sh
      ENTRYPOINT ["~/entrypoint.sh"]
https://github.com/moby/moby/issues/40379