'docker'에 해당하는 글 11건

CodeBuild / CodePipeline

Server/AWS 2021. 12. 18. 00:09

aws-eks-ci-cd

 

EKS 에서의 CI / CD 를 고민중이다. AWS 리소스만을 이용하는 방법, 범용적인 CI/CD 를 사용하는 방법... ArgoCD, TerraForm, Jenkins 등 뭐가 많지만 되도록 AWS 리소스를 사용해 보기로 했다. 예전에 ECS 배포할 때는 gradle 에서 Docker 이미지 생성 / ECR 업로드 / 배포까지... 전부 해결했었다. 로컬에서 태스크만 실행하면 되니 build.gradle 만 기다랗게 작성하는 것 빼고는 별 문제가 없었다. 그 때의 애로사항은 배포하려는 개발자의 PC 에 Docker 가 실행되고 있어야 한다는 점. ECR 인증키가 git 에 포함된다는 점. 배포시 오류가 발생한다면 즉시 파악이 어려운 점... 트집을 잡자면 그 정도. 하지만 대부분의 개발자가 docker 를 사용하고, git 도 프라이빗, 배포시 오류는 알림으로 처리했었고... 라며 흡족하게는 썼었지만, 이번엔 왠지 도구를 이용해야만 할 것 같은 느낌적인 느낌. 시간 있으면 이것저것 다 써보는게 좋은거지. 싶어서 CodeCommit, CodeBuild, CodePipeline 을 사용해 보았다.

 

 

사용할 AWS CI/CD Resource

 

  • CodeCommit
    - git 저장소 / 소스 위치
  • CodeBuild
    - 소스코드를 가져와 Test/Build 실행.
    - 자체 컴퓨팅으로 docker 이미지 생성, ECR 이미지 업로드, EKS 배포에 관한 빌드사양 파일 작성(buildspec.yml)
  • CodePipeline
    - git 저장소에 소스코드 변경이 감지되었을 때, source 아티팩트 S3 업로드 후 CodeBuild 실행

 

 

CodeBuild 생성

 

AWS 관리콘솔에서 빌드 프로젝트 만들기

  • 관리형 이미지 컴퓨팅 선택
  • 역할 이름 : 여러 빌드 프로젝트를 관리한다면 하나로 재사용
  • 권한이 있음(privileged) : 도커 이미지를 빌드하거나 빌드의 권한을 승격시 필요
  • VPC / 컴퓨터 유형 선택 : 빌드 성능 결정
  • 환경 변수 : buildspec 에 노출하고 싶지 않은 키/값 지정
  • Buildspec 이름 : 실제 buildspec 파일의 경로 지정
  • 캐시 유형 : 로컬 (DockerLayerCache, SourceCache, CustomCache)
  • 나머지 기본값

 

 

buildspec.yml 파일 작성

 

빌드 프로젝트 생성시 설정한 경로에서 buildspec.yml 를 작성한다. 기본적으로 4개의 페이즈가 있다.

  • install : 빌드 환경 구성
  • pre_build : 빌드에 필요한 ECR 로그인이나 패키지 종속성 설치 등
  • build : 빌드 실행
  • post_build : 빌드 결과물 처리, ECR 이미지 푸시, 빌드 알림 등

 

페이즈 마다의 규칙이 있지는 않지만, 추후 구간별 처리 속도를 알 수 있으므로 구분하여 사용자 정의.

 

$ vi buildspec.yml

version: 0.2

phases:
  install:
    runtime-versions:
      java: corretto11
    commands:
      - curl -o kubectl https://amazon-eks.s3-us-west-2.amazonaws.com/1.21.2/2021-07-05/bin/linux/amd64/kubectl
      - chmod +x ./kubectl
      - mv ./kubectl /usr/local/bin/kubectl
      - aws --version
      - aws eks update-kubeconfig --region ap-northeast-2 --name example-cluster
      - kubectl get po -n exapi
  pre_build:
    commands:
      - echo pre_build Logging in to Amazon ECR...
      - $(aws ecr get-login --region $AWS_DEFAULT_REGION --no-include-email)
      - REPOSITORY_URI=${REPO_ECR}
      - COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
      - IMAGE_TAG=${COMMIT_HASH:=latest}
  build:
    commands:
      - echo Build started on `date`
      - gradle --version
      - chmod +x gradlew
      - ./gradlew :ApiFacility:build
      - docker build -t $REPOSITORY_URI:latest ./Api
      - docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
  post_build:
    commands:
      - echo Build completed on `date`
      - echo Pushing the Docker images...
      - docker push -a $REPOSITORY_URI
      #- kubectl apply -f ./AWS/example-deployment.yaml
      - kubectl rollout restart -f ./AWS/example-deployment.yaml

 

위에 정의한 사양은,

  • install : 자바환경, kubectl 설치, kubeconfig 구성
  • pre_build : ECR 로그인, ECR 경로, 이미지 태그명 정의
  • build : gradle 빌드, docker 이미지 생성
  • post_build : ECR 이미지 푸시, eks deployment 롤링 업데이트

 

또한, 위 사양처럼 REPO_ECR 등의 프라이빗 정보들은 빌드 프로젝트 구성시 환경변수로 지정한 변수명으로 사용할 수 도 있다. echo 나 이미지 태깅 관리 때문에 조금 길어지긴 했는데 필요에 맞게 사용자 정의...

 

 

CodePipeline 생성

 

AWS 관리콘솔에서 파이프라인 생성

  • 역할 이름 : 여러 파이프라인을 관리한다면 하나로 재사용
  • 아티팩트가 업로드 될 버킷 위치 수동 지정시
  • 소스 스테이지 : CloudWatch 로 변경 감지, 출력 아티팩트 형식은 기본값을 사용하여 zip 형식의 데이터를 사용해도 무방하지만 간단히 메타데이터만 전달하는 전체 복제 선택.(gitpull 권한 추가 필요)
  • 빌드 스테이지 추가 후 배포 스테이지 건너뛰기

 

 

배포 테스트

 

CodePipeline 이 생성되면 즉시 실행이 되는데, 아니면 수동으로 빌드하던지, git 소스를 푸시하던지... 해서 배포 롤링 업데이트 확인까지. 이제부터는 에러의 향연이다. CodeBuild 의 플로우를 보면 거의 모든 단계에 해당 리소스에 대한 권한이 필요하므로 생성한/된 codebuildrole 에 각 권한을 추가해 주면 된다. 

 

[에러 모음 링크]

 

마치 일부러 에러를 찾아내려는 듯한 치밀한 실수들이 많았다; awscli 버전이 1.2 라 추후 문제가 있을수도 있지 않을까 하는 걱정도 되고... CodeCommit, CodeBuild, CodePipeline, ECR, EKS 등 AWS 리소스 만으로 CI/CD 를 구성해 본 느낌은... 그냥 그렇다.ㅋ 뭔가 자동화 스러우면서도, 관리 포인트가 점점 늘어나는 찝찝한 느낌... 남은건 구성 완료에 대한 약간의 성취감? ㅋ


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

CodeBuild error

Server/AWS 2021. 12. 17. 22:56

 

CodeBuild 빌드 중에 발생한 에러 모음이다.

 

빌드 프로젝트 구성 validation

: 빌드 프로젝트 새로 구성시 한번이라도 validation 에 실패하면 재검증시 터무니없는 메시지가 출력됨. 사실 권한 및 정책이 검증과정에서 이미 생성되는데 같은 이름의 권한 및 정책이 존재한다는 메시지가 올바르나... 아무튼 자동 생성된 권한 및 정책을 삭제해도 마찬가지이고... 권한 및 삭제 뒤 빌드 프로젝트를 한번에 새로 구성하면 해결; (한번이라도 검증 실패시 아래 메시지 조우)

 

서비스 역할 이름이 잘못되었습니다. 유효한 문자는 꼬부랑꼬부랑 !@#$ㄲㅉㄸㄲㅉ

 

 

S3 소스 다운로드시 권한 없음

: AmazonS3ReadOnlyAccess 권한 추가로 해결

 

Waiting for DOWNLOAD_SOURCE
AccessDenied: Access Denied
    status code: 403, request id: VX7AKNM69P3N7123, host id: 123y3WpjIvTzVViVzHclfn4F3UfDg4mJA++8BSY6q0jQyEPCWr4cohc0dVJ+q08N/123LMNToEI= for primary source and source version arn:aws:s3:::source-artifact-temp/example/SourceArti/BwUEum1

 

 

buildspec.yml 경로 에러 발생

: 경로 확인으로 해결

 

Phase context status code: YAML_FILE_ERROR Message: stat /codebuild/output/src123816321/src/git-codecommit.ap-northeast-2.amazonaws.com/v1/repos/example/Api/buildspec.yml: no such file or directory

 

 

ecr 로그인 에러

: AmazonEC2ContainerRegistryPowerUser 권한 추가로 해결

 

Running command aws --version
aws-cli/1.20.58 Python/3.9.5 Linux/4.14.252-195.483.amzn2.x86_64 exec-env/AWS_ECS_EC2 botocore/1.21.58

Running command $(aws ecr get-login --region $AWS_DEFAULT_REGION --no-include-email)

An error occurred (AccessDeniedException) when calling the GetAuthorizationToken operation: User: arn:aws:sts::123151105123:assumed-role/exampleCodeBuildServiceRole/AWSCodeBuild-ccf3e123-4123-4123-9ba1-1231fc6797b8 is not authorized to perform: ecr:GetAuthorizationToken on resource: * because no identity-based policy allows the ecr:GetAuthorizationToken action

Command did not exit successfully $(aws ecr get-login --region $AWS_DEFAULT_REGION --no-include-email) exit status 255
Phase complete: PRE_BUILD State: FAILED
Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: $(aws ecr get-login --region $AWS_DEFAULT_REGION --no-include-email). Reason: exit status 255

 

 

gradle 구문 에러

: 기본 gradle 버전 호환 오류로 스크립트 수정으로 해결 gradle build -> ./gradlew build

 

Running command gradle --version
------------------------------------------------------------
Gradle 5.6.4
------------------------------------------------------------
...
* What went wrong:
An exception occurred applying plugin request [id: 'org.springframework.boot', version: '2.6.0']
> Failed to apply plugin [id 'org.springframework.boot']
   > Spring Boot plugin requires Gradle 6.8.x, 6.9.x, or 7.x. The current version is Gradle 5.6.4

Command did not exit successfully gradle :Api:build exit status 1
Phase complete: BUILD State: FAILED
Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: gradle :Api:build. Reason: exit status 1

 

 

Dockerfile 경로 에러

: 경로 수정으로 해결 . -> ./AWS/Dockerfile

 

Running command docker build -t $REPOSITORY_URI:latest .
unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /codebuild/output/src368940192/src/git-codecommit.ap-northeast-2.amazonaws.com/v1/repos/kps/Dockerfile: no such file or directory

 

 

eks cluster 조회 권한 에러

: AmazonEKSWorkerNodePolicy 권한 수정 및 바인딩 추가로 해결

 

Running command aws eks update-kubeconfig --region ap-northeast-2 --name example

An error occurred (AccessDeniedException) when calling the DescribeCluster operation: User: arn:aws:sts::123151105123:assumed-role/exampleCodeBuildServiceRole/AWSCodeBuild-123e955a-545c-42c6-8d21-67215aef0123 is not authorized to perform: eks:DescribeCluster on resource: arn:aws:eks:ap-northeast-2:123151105123:cluster/example

Command did not exit successfully aws eks update-kubeconfig --region ap-northeast-2 --name example exit status 255
Phase complete: INSTALL State: FAILED
Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: aws eks update-kubeconfig --region ap-northeast-2 --name example. Reason: exit status 255

 

 

kubectl 권한 에러

: 사용자나 역할에 대한 aws-auth ConfigMap 수정으로 해결

 

Running command kubectl get po -n namespace1
error: You must be logged in to the server (Unauthorized)

Command did not exit successfully kubectl get po -n namespace1 exit status 1
Phase complete: INSTALL State: FAILED
Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: kubectl get po -n namespace1. Reason: exit status 1
Error from server (Forbidden): error when retrieving current configuration of:
Resource: "apps/v1, Resource=deployments", GroupVersionKind: "apps/v1, Kind=Deployment"
Name: "my-deploy", Namespace: "namespace1"
from server for: "./AWS/example-deployment.yaml": deployments.apps "my-deploy" is forbidden: User "system:node:AWSCodeBuild-fccb1123-1235-49c9-1238-b11cf05bc0c8" cannot get resource "deployments" in API group "apps" in the namespace "namespace1"
Running command kubectl rollout restart -n example-namespace deployment my-deploy
error: failed to patch: deployments.apps "my-deploy" is forbidden: User "system:node:AWSCodeBuild-a0f27123-b1fc-4e12-1e3f-0eac123f5123" cannot patch resource "deployments" in API group "apps" in the namespace "namespace1"

Command did not exit successfully kubectl rollout restart -n namespace1 deployment my-deploy exit status 1
Phase complete: POST_BUILD State: FAILED
Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: kubectl rollout restart -n namespace1 deployment my-deploy. Reason: exit status 1

 

- codebuild 에 사용된 역할 추가

$ kubectl edit configmap aws-auth -n kube-system

mapRoles: |
...
  - rolearn: arn:aws:iam::123151105123:role/exampleCodeBuildServiceRole
    username: system:node:{{SessionName}}
    groups:
    - system:bootstrappers
    - system:nodes
    - eks-console-dashboard-full-access-group

 

- 클러스터 역할 바인딩 생성

$ vi eks-console-full-access.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: eks-console-dashboard-full-access-clusterrole
rules:
- apiGroups:
  - ""
  resources:
  - nodes
  - namespaces
  - pods
  verbs:
  - get
  - list
  - patch
- apiGroups:
  - apps
  resources:
  - deployments
  - daemonsets
  - statefulsets
  - replicasets
  verbs:
  - get
  - list
  - patch
- apiGroups:
  - batch
  resources:
  - jobs
  verbs:
  - get
  - list
  - patch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: eks-console-dashboard-full-access-binding
subjects:
- kind: Group
  name: eks-console-dashboard-full-access-group
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: eks-console-dashboard-full-access-clusterrole
  apiGroup: rbac.authorization.k8s.io

 

$ kubectl apply -f eks-console-full-access.yaml
clusterrole.rbac.authorization.k8s.io/eks-console-dashboard-full-access-clusterrole created
clusterrolebinding.rbac.authorization.k8s.io/eks-console-dashboard-full-access-binding created

 

 

codebuild

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

Spring Boot 프로젝트의 jar 배포 테스트를 위해 구동 테스트를 했다.

  1. bootRun (O)
  2. cmd - bootJar 실행 (X)
  3. docker - bootJar 실행 (O)

 

bootRun 을 통과하고 bootJar 를 만들어 cmd 에서 실행을 했는데 db connection 타이밍에 에러가 발생했다.

 

> java -jar example-0.0.1-SNAPSHOT.jar
...
com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Starting...
com.zaxxer.hikari.pool.HikariPool        : HikariPool-1 - Exception during pool initialization.

java.sql.SQLNonTransientConnectionException: Could not create connection to database server. Attempted reconnect 3 times. Giving up.
Caused by: com.mysql.cj.exceptions.CJCommunicationsException: Communications link failure.
...
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)

 

mysql-ssl

 

ㅋㅋ 아니 뭐 요점만 간단히 알려주든가, '왜' 에러 났는지를 알려줘야지 거참...

 

bootRun 은 되는데, jar 실행에서 db 연결이 안된다? ... ㅡㅡ;; 우선 구글을 겁나 뒤졌다. 하... 그 많은 게시물들 중 DB 연결해 놓고 jar 실행한 사람이 하나 없냐... 다들 톰캣 띄운 Hello World... 나도 헬로월드 좋아하긴 하지만... 개발군 헬창들... 저 에러메시지는 너무 광범위하고, 내 상황을 검색어로 표현하기는 더 어려웠다. 구글 검색 페이지를 넘기다넘기다 중국말까지 나오기 시작했다. 아니... 이 아이러니한 상황이 납득이가 안갔다. 이렇게 시간을 낭비할 수는 없어 docker 를 일단 돌려봤다. 엥... 도커는 또 잘됨; 최종 목적이 도커라 로컬은 그냥 넘겨도 되지만 또또... 오늘한 삽질이 아까워 그 끝을 보기로 했다.

 

spring-boot-starter-web
spring-boot-starter-data-jdbc
mysql-connector-java:8.0.25

 

우선 톰캣만 띄웠더니 문제없다. 바로 dataSource 연결했더니 똑같은 오류...! 아니 원래 로컬에서 DB 연결이 안됐었나; 더 해볼게 없었지만 마지막으로, 혹시나 하는 마음에 connector 버전을 바꿔보았다.

 

mysql-connector-java:5.1.49

 

당연히 같은 자리에서 오류가 발생하기는 했는데, 해결책이 나왔다!

 

Establishing SSL connection without server's identity verification is not recommended. According to MySQL 5.5.45+, 5.6.26+ and 5.7.6+ requirements SSL connection must be established by default if explicit option isn't set. For compliance with existing applications not using SSL the verifyServerCertificate property is set to 'false'. You need either to explicitly disable SSL by setting useSSL=false, or set useSSL=true and provide truststore for server certificate verification.

 

Mysql 5.5.45+, 5.6.26+, 5.7.6+ 부터는 ssl 접속이 default 라서, useSSL=false 를 명시하지 않으면 자동으로 ssl 접속을 시도한다는 것이다.

 

jdbc:mysql://example.ap-northeast-2.rds.amazonaws.com:3306/example?...&useSSL=false

 

설마 이거 때문일 줄은 몰랐다. 이렇게 해결되니, 그래도 편히 눈을 감을 수 있게 됐다. 친절한 mysql connector 구버전에게 감사를 표한다.하지만 여전히 황당하기는 하다. ssl 이유라면 bootRun 으로도 되지 말았어야지. 도커에서도 되지 말았어야지...ㅜ

 

지금 보니 처음 발생했던 에러의 저 마지막 줄이 힌트긴 했네...

 

Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)

 

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  2개가 달렸습니다.
  1. 이남균 2022.03.28 10:18
    만세!!!! 감사합니다 ㅠ.ㅠ
    제 경우는 sts에서는 되는데 intelij 에서는 안되더라구요.
secret

Kubernetes 란

Tool/Kubernetes 2019. 3. 12. 00:10


쿠버네티스는 운영 수준에서 컨테이너 오케스트레이션(컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리) 기능을 하는 오픈소스 시스템이다. GO 언어로 구현이되었으며, 구글에서 설계를 했지만 오픈소스로서 특정 벤더나 플랫폼에 종속되지 않기 때문에, 대부분의 클라우드/온프레미스 등에 사용이 가능하다. 비슷한 기능을 하는 솔루션으로 Docker Swarm, Mesosphere, OpenStack, CloudFoundry 등이 있지만 Kubernetes 로 표준화되어 가고 있다. 쿠버네티스(Kubernetes) 는 K8s 라고도 하는데 K"ubernete"s 가운데 8글자를 "8"로 대체한 약어이다. 우선 쿠버네티스가 실전에서 어떻게 사용되는지를 먼저 보는 것이 쿠버네티스의 용도를 파악하기 쉬울 것 같다.


쿠버네티스를 사용한 어플리케이션 여러 배포 방법 중 하나의 과정을 적어봤다.


  1. 뚝딱뚝딱 서비스할 어플리케이션(A) 만들기.
  2. 쿠버네티스를 제공하는 클라우드 서비스에서 어플리케이션(A)가 운영될 클러스터 생성 및 리소스 설정
  3. 어플리케이션(A)을 컨테이너화하고 쿠버네티스에 배포 <- 운영 시작
  4. 스케일링 설정으로부터 파드(Pod) 수를 조절하며 업데이트 및 롤백 가능


큰 그림 위주의 단계만 적어놓아 이해에 부족함이 있을지도 모르겠다. 위 단계처럼 쿠버네티스는 배포 시스템이며, 안정적으로 운영을 하기 위한 여러 기능을 제공하고 있다. 기존 웹서버에 ELB 와 오토스케일링을 붙이는 방식보다 컨테이너 배포 시스템이 더 나은 점은 빠르고 안정적인 배포와 확장이다. 규모가 커질수록 컨테이너 방식이 월등하다. 다운될 일이 전혀 없는 작은 서비스를 운영하고 있고, 앞으로도 큰 서비스를 개발할 계획이 절대 없다면 이러한 컨테이너 서비스를 사용할 필요가 없다. 제대로 사용하기까지 드는 시간과 노력의 비용이 훨씬 많이 들기 때문이다. 쿠버네티스에 일찍 올라타진 못했지만 많은 사람들이 컨테이너 오케스트레이션 중에는 쿠버네티스를 가장 선호하고 있으며, GitKube 나 Jenkins X 등 Kubernetes 를 더 편리하게 사용할 수 있도록 많은 툴들이 확장되고 있다. 컨테이너 서비스에 관심이 많거나, 최소 트래픽 분산 환경의 웹서버를 운영하는 종사자, 또는 앞날이 창창한 신입 개발자들에게 반드시 도움이 되는 시스템이라고 생각한다.



* 더 도움이 되는 사이트

쿠버네티스 공식 문서(부분 한글) - https://kubernetes.io/docs/home/

조대협(조병욱) 님의 블로그 - https://bcho.tistory.com/1255




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

운영 서버에서 docker 를 사용하다 보면 사용하지 않는 image 및 container 등이 늘어나 디스크 공간을 차지하기 마련이다. 그래서 아래의 명령을 cron 으로 스케줄링하여 무쓸모 image 및 container 는 삭제하는 것이 좋다. (참고로 AWS ECS 에서는 ECS 컨테이너 에이전트가 컨테이너 인스턴스에서 사용하지 않은 이미지/컨테이너 등을 자동으로 정리해 준다. 오홍~)


$ docker rm $(docker ps -a)

$ docker rmi $(docker images -a)


하지만 로컬 호스트의 경우 운영 서버와는 다르게 각종 이미지들이 쌓여 있을 것이고 지워야 할 것들과 지우지 말아야 할 것들을 구분해야 한다. 위 명령으로 실행중이지 않은 모든 이미지와 컨테이너를 삭제해도 큰 문제는 없지만 다시 필요한 이미지를 생성하거나 다운받아야 하는 불편함이 생길 수 있다. 혹여라도 대기 중인 image 를 삭제하지 않게 prune 명령을 사용하여 dangling 이미지, 컨테이너, 볼륨, 네트워크를 삭제하는 것이 좋다.


$ docker container prune -f

$ docker image prune -f



Prune images


$ docker image prune -f
cs


컨테이너에서 태그가 지정되지 않고 어느 컨테이너에서도 참조하지 않는 dangling image 를 삭제한다. 모든 이미지 리스트(docker images -a) 에서 repository 와 tag 가 <none> 으로 설정되어 있는 이미지 중 어느 컨테이너에서도 참조하고 있지 않은 이미지를 dangling image 라고 한다. 이 dangling image 는 별다른 설정이 없다면 다시 사용되지 않을 이미지들이며, 동일한 repository:tag 로 이미지가 생성되어 기존 이미지에 덮어씌워질 때 나타난다.

docker rmi $(docker images -f "dangling=true") 명령과 동일하다. 이 명령으로 이미지가 삭제되지 않았다면 다른 컨테이너에서 참조 중이거나 이미 실행중인 것이다. --force(-f) 플래그는 강제 삭제가 아닌 프롬프트 무시 플래그이다.


$ docker image prune -a -f
cs


컨테이너가 생성되지 않은(실행 및 중지 상태가 아닌) 모든 이미지를 삭제한다. 종료되었지만 프로세스에 남아있는 컨테이너의 이미지는 삭제하지 못한다. docker rmi -f $(docker images -a) 명령은 위 명령과 비슷하지만, 프로세스에 남아있는 종료된 컨테이너의 이미지도 삭제한다.


이미지가 많아서 필터링이 필요한 경우는 아래와 같이 --filter 플래그를 사용할 수 있다. --filter "key=value" 형식이며, 여러 개의 --filter 플래그를 같이 사용할 수 있다. 필터링에 사용할 수 있는 key 는 특정 시간 이전에 생성된 이미지를 지정하는 until 과 label 일치 여부로 비교하는 label 이 있다.


$ docker image prune -f -a --filter "until=24h"
$ docker image prune -a --force --filter "until=2017-01-04T00:00:00"
$ docker image prune --filter="label=deprecated"
$ docker image prune --filter="label=maintainer=john"
$ docker image prune --filter="label!=maintainer"
$ docker image prune --filter="label!=maintainer=john"
cs



Prune containers


컨테이너는 docker run 으로 시작할 때 --rm 플래그를 지정하지 않으면 컨테이너 중지시에 자동으로 제거되지 않는다. docker ps -a 명령으로 호스트의 모든 컨테이너, 실행 중이거나 중지된 모든 컨테이너를 확인할 수 있으며, 중지된 컨테이너의 디스크 공간을 확보하기 위해 docker container prune 명령을 사용할 수 있다. 위 docker image prune 과 마찬가지로 필터링을 사용할 수 있다.


$ docker container prune
$ docker container prune --filter "until=24h" 
cs


마찬가지로 volume 과 network 도 prune 명령으로 제거할 수 있다.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret