심플코드

[K8s] minikube 란 무엇인가? macOS에서 설치하는 방법 알아보기

심플코드 — Sun, 2 Feb 2025 07:47:43 +0900

minikube가 필요한 이유

Minikube는 로컬 환경에서 Kubernetes(K8s) 클러스터를 실행할 수 있도록 도와주는 도구로, 이를 사용하면 Kubernetes 애플리케이션을 테스트 하기 위해 클라우드 환경을 사용하는 대신 로컬 환경을 사용할 수 있다.

이를 사용하면 클러스터를 간단히 실행할 수 있고, 클라우드 기반 Kubernetes 클러스터보다 빠르게 시작하고 재설정할 수 있어 Kubernetes의 학습을 할 때 적합하다.

macOS에서 minikube 설치하기

1. brew로 minikube 설치하기

참고: 공식 문서

brew로 minikube를 설치하기 위해서는 brew install minikube 명령어를 실행하면 된다.

brew install minikube

brew install minikube 실행 시 발생할 수 있는 오류

하지만 위 명령어를 실행했을 때 다음과 같은 오류가 일어날 수 있다.

Error: Permission denied @ apply2files - /opt/homebrew/lib/node_modules/truffle/node_modules/ganache/node_modules/@trufflesuite/bigint-buffer/build/node_gyp_bins/python3

이 오류는 현재 사용자가 Homebrew관련 디렉터리 /opt/homebrew 에 대한 권한이 없어서 생기는 문제로, 다음 명령어를 통해 권한을 부여할 수 있다.

sudo chown -R $(whoami) $(brew --prefix)/*

이후 brew install minikube 명령어를 실행 해 재설치를 진행한다.

 brew install minikube

2. minikube 실행하기

1번의 설치가 완료됐으면 minikube start 명령어를 통해 minikube를 실행할 수 있다.

minikube start

시작 화면에서 약간의 시간이 걸리고 약간의 시작이 지나면 다음과 같이

3. 클러스터 확인하기

설치가 완료되면 클러스터를 조회하기 위해 kubectl get po -A 를 호출하면 된다.

kubectl get po -A

만약 kubectl이 설치되어 있지 않다면 minikube가 kubectl을 다운로드 해 실행하게 할 수도 있다.

minikube kubectl -- get po -A

[Docker] 컨테이너와 호스트 머신 간 통신하는 방법 한 번에 정리하기

심플코드 — Sat, 1 Feb 2025 07:37:07 +0900

컨테이너와 호스트 머신 간 통신 시 생기는 문제

우리가 로컬에서 여러 애플리케이션을 실행하면, 해당 애플리케이션들과 통신하기 위해 localhost를 사용한다. 하지만, 컨테이너 위에서 실행되는 애플리케이션은 격리된 네트워크망 내부에 있기 때문에 localhost를 사용하면 호스트 머신에서 실행되는 애플리케이션과 통신하지 못한다.

호스트 머신에서 실행 중인 웹 애플리케이션과 Mongo DB의 통신을 생각해보자. Mongo DB가 27017번 포트를 점유해 실행된다고 할 때, 웹 애플리케이션에서 Mongo DB에 접속하기 위해서는 다음 주소를 사용하면 된다.

mongodb://localhost:27017/[데이터 베이스 이름]

하지만 컨테이너 위에서 실행 중인 웹 애플리케이션과 호스트 머신에서 실행 중인 Mongo DB와 통신하려 할 때 위의 주소를 사용하면. 27017번 포트에서 실행 중인 Mongo DB를 찾지 못한다. 외부의 네트워크와 격리된 네트워크에서 실행 중이기 때문이다.

컨테이너와 호스트 머신 간 통신하기

이런 문제를 해결하려면 Docker에서 호스트 머신과 연결하기 위해 제공되는 호스트인 host.docker.internal을 사용해야 한다. 즉, 컨테이너 환경에서 실행 중인 웹 애플리케이션에서 호스트 머신의 Mongo DB에 접속하기 위해서는 다음 주소를 사용해야 한다.

mongodb://host.docker.internal:27017/[데이터 베이스 이름]

host.docker.internal의 한계

host.docker.internal는 Window와 macOS에서만 제공된다. 만약 Linux에서 사용하려면 해당 애플리케이션이 실행 중인 IP 주소를 확인해 통신해야 한다. IP 주소를 확인하려면 docker inspect 명령어를 쓰면 된다.

docker inspect mongodb

그러면 Network - bridge 섹션에 IPAddress가 나오는 것을 확인할 수 있다. 이를 사용해 통신하면 된다.

[Docker] docker network 사용해 컨테이너 간 통신하는 방법 완벽 정리

심플코드 — Fri, 31 Jan 2025 07:21:57 +0900

컨테이너간 통신

컨테이너는 외부 애플리케이션 혹은 호스트 머신과는 자유롭게 통신할 수 있지만, 컨테이너 간에는 기본적으로 서로 통신할 수 없다. 컨테이너끼리 통신할 수 있도록 하기 위해서는 컨테이너 내부에 네트워크를 만든 후 통신할 컨테이너들이 같은 네트워크에 속해 있도록 해야 한다. 지금부터 이 방법을 알아보자.

Docker의 네트워크 드라이버 종류와 bridge 드라이버

Docker는 다양한 네트워크 드라이버를 지원한다. 대표적으로 bridge, host, none 드라이버가 있으며 이 외에도 overlay, macvlan 같은 드라이버가 있다. 하지만, 대부분의 경우는 bridge를 사용해 통신하며 이곳에서는 bridge 드라이버를 사용하는 방법에 대해 다룬다.

bridge 드라이버는 Docker의 기본 네트워크 드라이버로, 독립적인 컨테이너 간 통신을 가능하게 하며, 컨테이너를 동일한 bridge 네트워크에 연결하면 서로 통신할 수 있다.

컨테이너 간 통신 설정하기

네트워크 생성 및 확인

"docker network create [네트워크 이름]"을 통해 네트워크를 생성할 수 있다. 예를 들어 다음 명령어를 통해 app-network라는 이름의 네트워크를 만들 수 있다.

docker network create app-network

생성된 네트워크는 docker network ls 명령어를 통해 확인 가능하다.

컨테이너가 특정 네트워크에 속하도록 만들기

컨테이너가 특정 네트워크에 속하도록 만들려면 docker run 시 "--network [네트워크 이름]" 옵션을 주면 된다. 예를 들어 mongodb 이미지를 실행할 때 mongodb가 app-network에 속하도록 하려면 다음과 같이 작성해 실행하면 된다.

docker run --name mongodb -v mongodbdata:/data/db --rm -d --network app-network mongo

컨테이너 간 통신하기

같은 네트워크(app-network_에 속한 웹 애플리케이션 컨테이너에서 위에서 만든 mongodb 컨테이너에 연결한다고 하자. 그러면 위에서 --name 프로퍼티에 mongodb를 설정했으므로 호스트 이름을 넣는 부분에 mongodb 를 넣으면 된다.

mongodb://[유저이름]:[비밀번호]@[호스트 이름]:27017/[데이터 베이스 이름]

즉, 다음과 같은 모양이 된다.

mongodb://[유저이름]:[비밀번호]@mongodb:27017/[데이터 베이스 이름]

기존에는 로컬에서 통신하면 저 부분이 다음과 같은 모양이었다.

mongodb://[유저이름]:[비밀번호]@localhost:27017/[데이터 베이스 이름]

Spring Boot 애플리케이션에서는 spring.data.mongodb.host에 이미지 이름을 설정하면 된다.

spring.data.mongodb.host=mongodb
spring.data.mongodb.port=27017
spring.data.mongodb.database=[데이터 베이스 이름]
spring.data.mongodb.username=[유저 이름]
spring.data.mongodb.password=[비밀 번호]

이렇게 하면 통신이 성공한다.

Docker Compose 사용 시 컨테이너 간 통신

Docker Compose를 사용하면 같은 yml 파일 내부에 있는 컨테이너들 간에는 네트워크가 자동으로 생성된다. 따라서 별도로 네트워크를 설정해주지 않아도 된다.

version: '3.8'
services:
  mongodb:
    image: mongo:latest
    container_name: mongodb
    ports:
      - "27017:27017"
    environment:
      MONGO_INITDB_ROOT_USERNAME: [유저 이름]
      MONGO_INITDB_ROOT_PASSWORD: [비밀번호]

  app:
    image: my-spring-app:latest
    depends_on:
      - mongodb
    environment:
      SPRING_DATA_MONGODB_HOST: mongodb
      SPRING_DATA_MONGODB_PORT: 27017
      SPRING_DATA_MONGODB_DATABASE: [데이터베이스 이름]
      SPRING_DATA_MONGODB_USERNAME: [유저 이름]
      SPRING_DATA_MONGODB_PASSWORD: [비밀번호]

networks:
  app-network:
    driver: bridge

다만 yml 파일 외부의 컨테이너와 통신해야 하는 경우에는 network를 사용해 네트워크를 명시적으로 설정해주면 된다.

version: '3.8'
services:
  mongodb:
    image: mongo:latest
    container_name: mongodb
    ports:
      - "27017:27017"
    environment:
      MONGO_INITDB_ROOT_USERNAME: [유저 이름]
      MONGO_INITDB_ROOT_PASSWORD: [비밀번호]
    networks:
      - app-network

  app:
    image: my-spring-app:latest
    depends_on:
      - mongodb
    environment:
      SPRING_DATA_MONGODB_HOST: mongodb
      SPRING_DATA_MONGODB_PORT: 27017
      SPRING_DATA_MONGODB_DATABASE: [데이터베이스 이름]
      SPRING_DATA_MONGODB_USERNAME: [유저 이름]
      SPRING_DATA_MONGODB_PASSWORD: [비밀번호]
    networks:
      - app-network

networks:
  app-network:
    driver: bridge

[Docker] Dockerfile내부, .env 파일 혹은 터미널을 사용해 환경 변수 설정하는 방법 한 번에 정리하기

심플코드 — Thu, 30 Jan 2025 07:49:45 +0900

Docker의 환경 변수

Docker는 컨테이너를 실행하면서 환경 변수를 쉽게 설정하고 관리할 수 있는 방법을 제공한다. 환경 변수는 애플리케이션의 동작을 제어하거나, 민감한 정보(예: 데이터베이스 연결 정보, API 키 등)를 외부에서 주입할 때 유용하며, Docker에서는 이를 Dockerfile내부, .env 파일 혹은 터미널을 통해 설정할 수 있도록 한다.

지금부터 각 방법을 살펴보자.

Docker 환경 변수 설정하기

Dockerfile에 설정하기

Dockerfile에 환경 변수를 설정하기 위해서는 다음과 같이 사용하면 된다.

ENV [KEY] [VALUE]

예를 들어 PORT라는 환경 변수를 8080으로 설정하고 싶은 경우 다음과 같이 사용하면 된다.

# 환경변수 설정
ENV PORT=8080

.env 파일에 설정하기

.env 파일을 사용하면 환경 변수를 별도의 파일에 정의해 관리할 수 있다. 이 방법은 특히 민감한 정보를 코드와 분리하거나, 여러 환경(개발, 테스트, 운영 등)에서 다른 설정을 사용해야 할 때 유용하다.

.env 파일을 작성하는 방법은 간단하다. 단순히 각 줄에 KEY=VALUE 형식으로 값을 작성하면 된다.

# .env 파일
PORT=8080
DB_HOST=localhost
DB_USER=root
DB_PASSWORD=secret

이렇게 설정된 .env 파일은 docker-compose.yml 파일 내부에서 서비스의 env_file 값으로 넘겨지는 방식으로 사용될 수 있다.

services:
  mongodb:
    image: mongo
    ...
    env_file:
      - ./.env

혹은 docker run 시에는 --env-file 다음과 같이 사용될 수 있다.

docker run --env-file [.env 파일 경로] [Image Name]

터미널 통해 설정하기

터미널을 통해 설정할 때는 -e 옵션과 함께 [Key]=[Value]를 넘기는 방식으로 사용하면 된다.

docker run -d -p 8080:8080 --name my-app -e PORT=8080 -e DB_HOST=localhost -e DB_USER=root -e DB_PASSWORD=secret [Image Name]

환경 변수의 우선순위

Docker는 환경 변수를 처리할 때 특정 우선순위를 따른다. 동일한 변수 이름이 여러 곳에서 정의된 경우, 다음 순서로 우선순위가 적용된다.

1. 터미널에서 명시적으로 설정한 환경 변수 (docker run 명령어의 -e 옵션)

2. .env 파일에 정의된 환경 변수

3. Dockerfile에 정의된 ENV 변수

예를 들어, Dockerfile에 ENV PORT=3000이 정의되어 있고 .env 파일에는 PORT=4000이, docker run 명령어로 -e PORT=5000을 전달하면 컨테이너 내부에서는 PORT=5000이 사용된다. 즉, 터미널에서 설정된 환경 변수가 가장 우선한다.

환경 변수 사용하기

Dockerfile 내부에서 사용하기

설정된 환경 변수는 Dockerfile 내부에서 ${KEY NAME}를 통해 접근할 수 있다.

ENV PORT=3000

EXPOSE $PORT

Docker Compose에서 사용하기

Docker Compose에서는 ${[Key Name]} 을 통해 환경 변수에 접근할 수 있다. 예를 들어 다음과 같이 사용할 수 있다.

version: '3.8'
services:
  app:
    image: my-spring-app:latest
    env_file:
      - ./.env
    ports:
      - "${HOST_PORT}:${INTERNAL_PORT}"
    environment:
      - APP_ENV=${APP_ENV}
      - DB_HOST=${DB_HOST}
      - DB_PORT=${DB_PORT}

[Docker] .dockerignore 사용해 컨테이너에 복사되지 말아야 할 파일 정의하기

심플코드 — Wed, 29 Jan 2025 07:40:59 +0900

.dockerignore을 사용하지 않을 때의 문제점

앞선 글 에서 만들어진 컨테이너 내부를 보면 다음과 같은 파일들이 추가된 것을 볼 수 있다.

이 중 build 폴더와 .git 폴더 그리고 .idea 폴더는 내부에서 자동으로 생성되거나 스프링 앱을 실행하는데 전혀 사용되지 않는 폴더들로 컨테이너로 복사하지 않아도 된다.

이런 폴더들을 복사하지 않기 위해 Dockerfile에서 COPY를 사용할 때 세밀하게 제어해도 괜찮지만, 가장 좋은 방법은 .dockerignore 파일을 사용하는 것이다.

.dockerignore 사용해 복사되지 말아야 할 파일과 폴더 정의하기

.dockerignore는 git의 .gitignore과 매우 비슷하다. 단순히 내부에 컨테이너로 복사되지 말아야 하는 경로나 파일을 추가하면 이 경로나 파일은 복사되지 않는다.

위 스크립트에서는 build/, .idea, .git 경로를 복사하지 않도록 설정했다.

.dockerignore 동작 확인하기

.dockerignore가 동작하는지 확인하기 위해 이미지를 다시 빌드해 컨테이너를 실행해보자.

그러면 다음과 같이 컨테이너 내부에 .git과 .idea 폴더가 없는 것을 확인할 수 있고, build 폴더는 스크립트가 실행돼 새로 빌드된 것을 확인할 수 있다.

[Docker] Bind Mount 통해 호스트 머신의 경로를 컨테이너 경로와 연결하기

심플코드 — Tue, 28 Jan 2025 07:21:56 +0900

Bind Mount의 필요성

Docker는 컨테이너화된 애플리케이션을 실행할 때 데이터의 유연한 관리와 공유를 지원하기 위해 여러 데이터 관리 방법을 제공한다. 대표적으로 앞서 다룬 Anonymous Volume과 Named Volume이 있다. 하지만 이 두 볼륨은 볼륨을 생성해 컨테이너의 디렉토리와 연결하는 방식을 사용하며, 호스트 머신의 경로를 컨테이너의 디렉토리와 연결하지는 못한다.

하지만 개발을 하다 보면, 호스트 머신의 변경 사항이 곧바로 애플리케이션에 반영돼야 하는 경우가 있다. 이런 문제를 해결하기 위해 Docker는 Bind Mount라는 기능을 제공한다.
Bind Mount는 호스트 머신의 디렉터리를 컨테이너의 특정 경로에 직접 연결해 데이터를 공유하거나 관리할 수 있도록 하는 기능으로, 이를 사용하면 호스트 머신에서 개발하면서 변경 사항을 실시간으로 적용되도록 만들어 테스트를 쉽게 할 수 있다.

Bind Mount 사용 방법

GitHub: https://github.com/seyoungcho2/DockerExample/tree/feature/2.volume-bindmount

GitHub - seyoungcho2/DockerExample: Docker 연습을 위한 저장소입니다.

Docker 연습을 위한 저장소입니다. Contribute to seyoungcho2/DockerExample development by creating an account on GitHub.

github.com

Bind Mount 사용 준비하기

Bind Mount이 제대로 동작하는지 확인하기 위해서는 코드의 변경 사항이 애플리케이션에 반영되는지 확인할 수 있어야 한다.

이를 위해 Spring Dev Tools를 사용하도록 build.gradle.kts를 변경한다.

dependencies {
    ...

    developmentOnly("org.springframework.boot:spring-boot-devtools")
}

Dockerfile도 곧바로 소스에서 빌드해야 하므로 다음과 같이 변경한다.

# JDK 17 이미지 사용하기
FROM eclipse-temurin:17

# 모든 명령이가 실행될 디렉토리 설정
WORKDIR /app

# build.gradle.kts, settings.gradle.kts 파일을 도커 컨테이너의 app 디렉토리에 복사
COPY build.gradle.kts settings.gradle.kts /app/

# 이미지 내부에 들어가야 할 경로 설정. 현재 경로의 모든 파일들이 도커 컨테이너의 app 디렉토리에 복사
CMD ["./gradlew","dependencies","--no-daemon"]

# 도커 컨테이너의 app 디렉토리에 있는 모든 파일들을 도커 컨테이너의 app 디렉토리에 복사
COPY . /app

# 도커 컨테이너 내부의 8080번 포트를 외부로 노출
EXPOSE 8080

# ENTRYPOINT를 사용해 컨테이너가 시작될 때 실행할 명령어를 지정
CMD ["./gradlew", "bootRun", "--no-daemon"]

이후 다음 명령어로 이미지를 빌드한다.

docker build -t bindmount:1.0.0 .

이제 모든 준비가 완료됐다. 이제 Bind Mount를 사용해 호스트 머신의 코드 변경 사항이 곧바로 반영되는지 알아보자.

Bind Mount 사용하기

현재 경로의 src/main 내부에 소스 코드가 있으므로 이 경로를 컨테이너의 소스 경로와 메핑 시켜야 한다.

이를 위해 -v $(pwd)/src/main:/app/src/main 옵션을 추가해 앞서 만든 bindmount:1.0.0 이미지로 컨테이너를 만들어 실행한다.

docker run -d --name springapp -p 8080:8080 -v $(pwd)/src/main:/app/src/main bindmount:1.0.0

이 명령어가 바로 bind mount를 실행하는 명령어이며, : 앞의 경로가 호스트 기기의 경로이고 : 이후의 경로가 컨테이너의 경로가 된다.

docker run -d --name springapp -p 8080:8080 -v [기기의 경로]:[컨테이너 경로] bindmount:1.0.0

그러면 기기 코드의 변경 사항이 곧바로 컨테이너 경로에 반영된다.

Bind Mount 설정이 마쳐졌다. 이제 실제 테스트를 해보자.

Bind Mount 적용 확인하기

기존의 SimpleController은 /hello 경로로 GET 요청 시 "Hello, Docker!"을 반환했다.

@RestController
class SimpleController {

    @GetMapping("/hello")
    fun hello(): String {
        return "Hello, Docker!"
    }
}

이제 이 코드를 당므과 같이 변경해 "Hello, Docker Bind Mount!" 를 반환하도록 수정하자.

@RestController
class SimpleController {

    @GetMapping("/hello")
    fun hello(): String {
        return "Hello, Docker Bind Mount!"
    }
}

약간의 시간이 지난 후 혹은 컨테이너 리스타트 이후에 http://localhost:8080/hello로의 GET 요청 시 변경된 문구가 적용된 것을 확인할 수 있다.

[Docker] Named Volume 이란 무엇인가? 사용 방법과 특징 정리

심플코드 — Mon, 27 Jan 2025 07:45:35 +0900

Named Volume 이란?

Named Volume은 사용자가 직접 이름을 지정해 관리하는 Docker 볼륨이다. 이 볼륨은 데이터를 영구적으로 저장하는 데 사용되며, 익명 볼륨과 달리 컨테이너의 수명과 독립적이다. 이름이 지정되어 있기 때문에 여러 컨테이너에서 쉽게 공유하거나 참조할 수 있다.

Named Volume 생성하고 사용하기

Named Volume 생성하기

Named Volume은 다음 명령어를 통해 생성할 수 있다.

docker volume create [Volume Name]

예를 들어 다음과 같이 "docker volume create postvolume" 명령어를 실행해 postvolume이라는 이름을 가진 Named Volume을 생성할 수 있다.

Named Volume 사용하기

컨테이너를 만들 때 Named Volume을 사용하기 위해서는 -v [Named Volume]:[컨테이너 디렉토리] 옵션을 넣어 volume과 컨테이너의 디렉토리를 연결해주면 된다.

docker run -p 8080:8080 -d --name postapp --rm -v [Named Volume]:[컨테이너 디렉토리] volume:1.0.1

예를 들어 다음과 같이 사용하면 앞서 만든 postvolume을 /app/post 경로에 연결시킬 수 있다.

docker run -p 8080:8080 -d --name postapp --rm -v postvolume:/app/posts volume:1.0.1

Named Volume에 데이터 넣기

이제 다음 요청으로 Named Volume에 데이터를 넣어보자.

### Make Post Request
POST http://localhost:8080/post
Content-Type: application/json

{
    "title": "My Second Post",
    "content": "This is my second post"
}

그러면 다음과 같이 b9a6aeff로 시작하는 아이디를 가진 포스트가 생성된 것을 볼 수 있다.

이제 docker desktop에서 postVolume을 확인하면 다음과 같이 포스트가 생성된 것을 확인할 수 있다.

Named Volume 유지 확인하기

앞서 우리가 "Named Volume 사용하기" 섹션에서 docker run을 할 때 --rm 옵션을 넣은 것을 기억해보자. 다음은 우리가 컨테이너를 실행할 때 사용한 스크립트이다.

docker run -p 8080:8080 -d --name postapp --rm -v postvolume:/app/posts volume:1.0.1

이제 이 postapp을 stop 하면, 볼륨은 유지되고(volume ls) 컨테이너는 지워진 것(docker ps -a)을 확인할 수 있다.

Named Volume의 주요 특징

영구성이 있음

컨테이너가 삭제돼도 Named Volume에 저장된 데이터는 삭제되지 않는다. 따라서 중요한 데이터를 저장하고 관리하는 데 적합하다.

이름 기반 참조가 가능함

사용자가 지정한 이름을 통해 볼륨을 쉽게 참조하고 관리할 수 있다. 앞에서 봤듯이 내부 경로랑 매핑할 때 단순히 볼륨 이름을 앞에 넣어주기만 하면 된다.

컨테이너 간 데이터 공유 시 사용 가능

동일한 Named Volume을 여러 컨테이너에 마운트 해서 같은 데이터를 공유할 수 있다.

[Docker] Anonymous Volume(익명 볼륨) 한 번에 정리하기

심플코드 — Sun, 26 Jan 2025 13:06:37 +0900

Docker의 볼륨

Docker의 컨테이너 내부에서 생성되는 데이터는 기본적으로 해당 컨테이너의 파일 시스템에 저장된다. 하지만, 이는 컨테이너가 삭제되면 데이터도 함께 삭제되는 한계가 있다. 이런 문제를 해결하기 위해 Docker는 볼륨(Volume)이라는 메커니즘을 제공한다.

이 글에서는 이러한 Volume 중 익명 볼륨(Anonymous Volume)에 대해 알아볼 것이다.

익명 볼륨이란?

익명 볼륨은 이름이 없는 볼륨으로, Docker가 자동으로 생성하고 관리한다. 이름이 지정되지 않았기 때문에 컨테이너 외부에서 직접 참조하거나 관리하기가 어렵지만, 컨테이너와 데이터의 분리를 통해 데이터 유실을 방지할 수 있는 장점이 있다.

익명 볼륨은 주로 아래와 같은 상황에서 사용될 수 있다.

특정 컨테이너 실행 중에만 데이터가 필요하고, 이후 관리가 필요하지 않은 경우.
테스트 컨테이너를 실행하면서 파일 시스템의 데이터를 격리하고자 할 때.
mounted volume의 영향을 받지 않는 하위 폴더를 구성해야 하는 경우

익명 볼륨 생성하기

컨테이너를 실행할 때 VOLUME 명령어나 docker run 명령어를 통해 익명 볼륨을 생성할 수 있다.

예를 들어 /posts 경로에 대한 익명 볼륨을 생성하고 싶다면 다음과 같은 명령을 Dockerfile에 추가하면 된다.

# 익명 볼륨 만들기
VOLUME /posts

혹은 다음과 같이 -v 옵션으로 익명 볼륨을 만들 경로를 지정하면 된다.

docker run -p 8080:8080 -v /posts volume:1.0.0

익명 볼륨 사용해 파일 저장 확인해보기

GitHub 코드: https://github.com/seyoungcho2/DockerExample/tree/feature/2.volume-anonymous

익명 볼륨 사용을 위한 준비

익명 볼륨을 사용해보기 위해 다음과 같은 스프링 컨트롤러를 만든다.

data class PostRequest(
    val title: String,
    val content: String
)

@RestController
class PostController {
    @PostMapping("/post")
    fun createPost(
        @RequestBody postRequest: PostRequest
    ): String {
        val postsDir = File("posts")
        if (!postsDir.exists()) {
            postsDir.mkdirs()
        }

        val id = randomUUID().toString()
        val file = File(postsDir, "$id.json")
        val postJson =
            """
            {
                "id": "$id",
                "title": "${postRequest.title}",
                "content": "${postRequest.content}"
            }
            """.trimIndent()
        file.writeText(postJson)

        return postJson
    }

    @GetMapping("/post")
    fun getPostById(
        @RequestParam id: String
    ): String {
        val file = File("posts/$id.json")
        return file.readText()
    }
}

이 컨트롤러는 Post를 저장하고 조회하기 위한 컨트롤러로 포스트를 생성하고, 가져올 수 있는 기능을 제공한다.

이렇게 만든 후 ./gradlew bootJar를 실행해 jar 파일을 만들고 다음과 같은 Dockerfile을 만든다.

# JDK 17 이미지 사용하기
FROM eclipse-temurin:17

# 모든 명령이가 실행될 디렉토리 설정
WORKDIR /app

# 익명 볼륨 만들기
VOLUME /app/posts

# 이미지 내부에 들어가야 할 경로 설정. 현재 경로의 모든 파일들이 도커 컨테이너의 app 디렉토리에 복사
COPY build/libs/SimpleApplication-0.0.1-SNAPSHOT.jar app.jar

# 도커 컨테이너 내부의 8080번 포트를 외부로 노출
EXPOSE 8080

# ENTRYPOINT를 사용해 컨테이너가 시작될 때 실행할 명령어를 지정
ENTRYPOINT ["java", "-jar", "app.jar"]

이제 모든 준비가 완료됐으면 다음 명령어를 통해 이미지를 빌드한다.

docker build -t volume:1.0.0 .

이제 이미지가 만들어졌으니 이 이미지를 사용해 컨테이너를 실행해보자. 실행 명령어는 다음과 같다.

docker run -p 8080:8080 volume:1.0.0

그러면 다음과 같은 실행 화면을 볼 수 있다.

포스트 만들기

포스트를 만들기 위해 .http 파일에 다음과 같이 작성해 요청을 실행한다.

POST http://localhost:8080/post
Content-Type: application/json

{
    "title": "My First Post",
    "content": "This is my first post"
}

그러면 다음과 같이 200응답과 함께 만들어진 포스트의 id가 온다.

이제 이 포스트가 잘 만들었는지 다음 요청을 실행해 확인해보자.

### Get Post by ID
GET http://localhost:8080/post?id=b5377945-9eb0-46fb-99a8-a52f6f2aa1d5

그러면 다음과 같이 포스트가 잘 만들어진 것을 확인할 수 있다.

이 포스트 파일은 익명 볼륨 /app/post에 저장된다.

익명 볼륨에 저장된 파일 확인하기

익명 볼륨에 저장된 파일을 확인하기 위해서는 다음 명령어를 실행해 콘솔을 켠 후

docker exec -it [컨테이너 Id] /bin/sh

app/posts 폴더에 해당 아이디에 해당하는 .json 파일이 있는지 확인하면 된다.

아래는 현재 컴퓨터에서 실행한 결과이고 b5377로 시작하는 파일이 잘 저장된 것을 볼 수 있다.

익명 볼륨 확인하기

익명 볼륨을 확인하기 위해서는 docker inspect 명령어를 사용하면 된다.

docker inspect [컨테이너 Id]

그러면 내부의 Mounts 섹션에 볼륨이 생성돼 있는 것을 볼 수 있다.

일반적으로 익명 볼륨은 /var/lib/docker/volumes/ 경로에 생성된다.

Docker Desktop에서 익명 볼륨 확인하기

익명 볼륨은 Docker Desktop의 Volumes 섹션에서도 확인할 수 있다.

이름을 더블 클릭해서 들어가면 다음과 같이 볼륨 내부도 확인할 수 있다.

익명 볼륨 사용 시 주의할 점

익명 볼륨은 컨테이너가 제거될 때 함께 제거되지 않는다

익명 볼륨은 기본적으로 컨테이너가 제거될 때 함께 제거되지 않는다. 예를 들어 위에서 다룬 컨테이너를 stop 해도, 제거 해도 volume은 그대로 남아있다. 이는 아래에서 확인할 수 있다. docker volume ls가 볼륨 목록을 확인하는 명령어이다.

이런 경우 사용하지 않는 익명 볼륨들이 시스템에 쌓일 수 있는데, docker volume prune 명령어를 통해 제거해주면 된다.

--rm 옵션과 함께 실행된 컨테이너가 제거될 때 익명 볼륨은 함께 제거된다.

--rm 옵션을 넣으면 컨테이너가 중지될 때 컨테이너가 삭제되고, 컨테이너에서 사용되는 리소스가 함께 정리된다. 이때 익명 볼륨도 함께 제거된다.

다음 콘솔에서는 --rm 옵션과 함께 이미지를 사용해 컨테이너를 생성 후 실행하고 docker을 중지한 다음(docker stop) 도커의 볼륨을 확인(docker volume ls)했다.

익명 볼륨이 자동으로 제거된 것을 확인할 수 있다.

익명 볼륨을 터미널에서 만들기

익명 볼륨을 Dockerfile에 지정하지 않더라도, 터미널에서 -v 명령어를 통해 지정할 수 있다.

docker run -p 8080:8080 -d --name postapp --rm -v /app/posts volume:1.0.1

Docker Hub에 이미지 업로드 하기

심플코드 — Sat, 25 Jan 2025 07:46:38 +0900

이번 글에서는 Docker Hub에 이미지를 배포하는 방법에 대해 알아보자.

1. Docker Hub에 저장소 만들기

Docker Hub에 이미지를 배포하기 위해서는 먼저 Docker Hub에 저장소를 만들어야 한다. 저장소를 만들기 위해 Create a repository 버튼을 클릭한다.

그러면 다음과 같은 창이 뜨는데 Repository Name 영역을 채운 후 오른쪽 하단의 Create 버튼을 누른다.

그러면 다음과 같이 저장소가 만들어진 것을 확인할 수 있다.

2. Docker Image 만들기

위의 1번에서 생성한 Repository Name과 동일하게 도커 이미지를 빌드해야 한다. 이를 위해 다음 명령어를 입력하자.

docker build -t [이미지 이름]:[버전] .

그러면 이미지가 만들어진다.

docker images를 통해 이미지가 잘 만들었는지 확인하자.

이미지가 잘 만들어졌다면 이미지 배포를 위한 준비가 끝났다.

3. Docker Hub에 Docker Image 배포하기

이제 docker push 명령어를 슨 다음 [유저 이름]/[저장소 이름]:버전을 쓰면 배포가 완료된다.

docker push [유저 이름]/[저장소 이름]:[버전]

실제로 배포된 파일을 다음 저장소에서 확인할 수 있다.

https://hub.docker.com/repository/docker/sydockermaster/springsample/general

hub.docker.com

3.1. unauthorized 애러가 뜰 경우 해결 방법

unauthorized 애러가 뜨면 docker login 명령어를 실행한 다음 다시 위의 단계를 진행하면 된다.

[Docker] 이미지 목록 확인하고 제거하는 방법 한 번에 정리하기

심플코드 — Fri, 24 Jan 2025 07:19:46 +0900

도커 이미지 목록 확인 방법

도커 이미지 목록을 확인하려면 다음 명령어를 사용하면 된다.

docker images

그러면 다음과 같이 만들어진 이미지 목록을 확인할 수 있다.

도커 이미지 지우기

도커 이미지를 지우려면 다음 명령어를 사용하면 된다.

docker rmi [Image ID]

예를 들어 755bc7cc5c96 라는 아이디를 가진 이미지를 지우려면 다음 명령어를 사용하면 된다.

docker rmi 755bc7cc5c96

참고로 rmi 명령어 뒤에는 Image Name이 들어가도 이미지가 지워진다.

docker rmi [Image Name]

예를 들어 myapp:v1 이미지를 지우고 싶다면 다음과 같이 쓰면 된다.

docker rmi myapp:v1

사용하지 않는 이미지 모두 지우기

더이상 사용하지 않는 이미지를 모두 지우려면 다음 명령어를 사용하면 된다.

docker image prune

prune이란 '가지치기' 혹은 '정리'라는 뜻으로 더이상 사용되지 않는 이미지를 정리하는 것을 뜻한다. 이 명령어를 사용할 경우, 이미지로 만들어진 컨테이너가 없는 경우 모두 정리된다.