한발 한발 나아가기

in spring boot 2.X.X

@NoRepositoryBean
public interface JpaRepository<T, ID> extends PagingAndSortingRepository<T, ID>, QueryByExampleExecutor<T> {
	
	@Override
	List<T> findAll();
	...
}

• 2버전 JpaRepository는 PagingAndSortingRepository, QueryByExampleExecutor을 상속한다.

in spring boot 3.X.X

@NoRepositoryBean
public interface JpaRepository<T, ID> extends ListCrudRepository<T, ID>, ListPagingAndSortingRepository<T, ID>, QueryByExampleExecutor<T> {
	...
}

@NoRepositoryBean
public interface ListCrudRepository<T, ID> extends CrudRepository<T, ID> {

	<S extends T> List<S> saveAll(Iterable<S> entities);

	List<T> findAll();

	List<T> findAllById(Iterable<ID> ids);
}

@NoRepositoryBean
public interface ListPagingAndSortingRepository<T, ID> extends PagingAndSortingRepository<T, ID> {

	List<T> findAll(Sort sort);
}

• 3버전 JpaRepository는 ListCrudRepository, ListPagingAndSortingRepository, QueryByExampleExecutor을 상속한다.

why ListXXXRepository?

일반적인 조회, 수정, 삭제 기능은 CrudRepository로도 충분하지만, CrudRepository#findAll()은 Iteratable을 반환하기 때문에, 결과물을 List로 받고싶은 경우에는 번거롭다.

• JpaRepository는 List로 받을 수 있다.
• 페이징이나 정렬 등의 추가 기능이 필요하다면 JpaRepository를 사용하면 된다.

Spring 3.X.X부터는 List로 데이터를 받을 수 있도록 ListCrudRepository 인터페이스를 지원한다!

참고자료

• 스프링 공식 문서
• Announcing ListCrudRepository & Friends for Spring Data 3.0
• What is difference between CrudRepository and JpaRepository interfaces in Spring Data JPA?

배경

프로젝트를 퍼블리시 하는 과정에서 다음과 같은 에러가 발생하였다.

An exception occurred applying plugin request [id: 'org.jetbrains.kotlin.jvm', version: '1.4.20']

해결 방법

-- 터미널
brew install gradle@7
brew link gradle@7

-- 에러가 발생한 프로젝트 터미널
gradle wrap
gradle 리프레시 후 tasks / publishing / publishToMavenLocal

배경

ls -l /var/run/docker.sock
lrwxr-xr-x  1 root  daemon  44  5 24 10:25 /var/run/docker.sock -> /Users/choi-junyoung/.docker/run/docker.sock

내 컴퓨터에는 stella.jv와 choi-junyoung 두 개의 계정이 있다. 그런데 stella.jv 계정으로 접속했을 때, 저런 식으로 /var/run/docker.sock이 다른 사용자 계정을 바라보고 있었다.

처음에는 왜 저런지 전혀 알지 못했지만, 구글링 하다보니 심볼릭 링크와 관련되어 있다는 것을 알 수 있었다.

키워드를 파악하니 해결책을 쉽게 찾을 수 있었다.

해결 방법

sudo ln -s /Users/stella.jv/.docker/run/docker.sock /var/run/docker.sock

기존 /var/run/docker.sock을 삭제한 뒤, 위의 명령어를 입력하여 stella.jv 계정를 바라보도록 하였다.

그 다음 도커로 실행시켜보니, 내 docker desktop으로 정상적으로 확인할 수 있게 되었다.

아래 명령어에 pod 대신 deployment, namespace 등의 오브젝트를 사용해도 된다.

kubectl apply -f [yaml 파일] : deployment.yaml과 같은 파일로부터 새로운 파드 생성

kubectl get pods : 파드 목록 확인

• -o wide : 파드가 실행중인 워커노드 확인
• --show-labels : 라벨을 함께 출력
• -n [네임스페이스 이름] : 특정 네임스페이스에 존재하는 파드 목록 확인. 기본적으로 default 사용.

kubectl describe pods [파드 이름] : 해당 오브젝트의 상세 정보 확인

kubectl exec : 파드의 컨테이너에 명령어 전달

• ex) kubectl exec -it pod-name bash : 컨테이너 접속 후 배시 셸 실행 및 유지

kubectl logs pods : 파드의 로그 확인

kubectl delete pod [파드 이름] : 특정 파드 삭제

• kubectl delete -f [my-pod.yaml]를 사용해도 된다.
• -all : 모든 파드 삭제

kubectl create namespace [생성할 ns 이름] : 네임스페이스 생성

kubectl create secret generic [생성할 secret 이름] --from-literal key1=value1 : key1=value1을 데이터로 가지는 시크릿 생성

기타 옵션

-c [컨테이너 이름] : exec, logs 등과 같이 사용하며, 파드의 어떤 컨테이너에 대해 명령어를 수행할지 명시

쿠버네티스에서는 컨테이너 애플리케이션의 기본 단위를 파드라고 부른다.

쿠버네티스가 파드를 사용하는 이유는, 대표적으로 여러 리눅스 네임스페이스를 공유하는 여러 컨테이너들을 추상화된 집합으로 사용하기 위함이다. 그 말은 즉, 파드에 속한 여러 개의 컨테이너들은 동일한 네트워크 환경을 가진다는 것을 의미한다.

왜 하나의 파드에 여러 개의 컨테이너가 포함되는지 의문을 가질 수 있다. 실제로 대부분은 하나의 파드를 하나의 컨테이너로 구성한다.

하나의 파드는 하나의 완전한 애플리케이션이라는 점을 주목하자. 가령 어떤 Nginx 컨테이너가 로그 수집과 같은 부가적인 기능을 필요로 할 수 있다. 이런 경우 주 컨테이너는 Nginx로 하되, 기능 확장을 위한 사이드카 컨테이너를 파드에 포함시키면 된다. 

이것이 도커 컨테이너와 쿠버네티스 파드의 차이점이다.

참고자료

• 시작하세요! 도커/쿠버네티스 책

지속적인 보완이 필요한 글

Dockerfile이란 이미지 생성을 위해 컨테이너에 설치해야 하는 패키지, 추가해야 하는 소스코드, 실행해야 하는 명령어와 셸 스크립트 등의 일련의 작업들을 기록한 파일이다. 애플리케이션 개발 용도 이외에도, 도커 허브에 이미지 대신 생성 방법을 기록한 도커파일을 배포하는 경우도 있다.

초기 이미지를 바탕으로, 컨테이너 내부에서 애플리케이션을 위한 환경을 구성한 뒤에 커밋하는 방법도 있다. 하지만 아래의 장점으로 인해, Dockerfile을 사용하는 것이 좋다.

1. 이미지 생성 방법의 기록. 패키지 생성과 같이, 애플리케이션에 필요한 일련의 과정을 명확하게 표현할 수 있음
2. 이미지 생성 자동화
3. 쉽게 배포 가능

참고자료

• 시작하세요! 도커/쿠버네티스
• 도커 공식문서

컨테이너에 변경 사항을 저장하면, 컨테이너 삭제 시 데이터가 함께 삭제된다. 컨테이너와 무관하게 데이터를 관리하고 싶다면, 볼륨을 사용한다.

볼륨을 활용하는 방법으로는 1) 호스트와 볼륨을 공유, 2) 볼륨 컨테이너 활용, 3) 도커가 관리하는 볼륨을 생성하는 방법이 있다. 사실 세 방법 모두 호스트의 파일 디렉토리를 사용하며, 방법에 따라 조금씩 차이가 있을 뿐이다.

앞의 두 가지 방법도 나쁘지 않지만, 도커가 관리하는 볼륨을 사용하면 더욱 편리하다.

사용 방법

1. docker volume create —name [볼륨 이름] 으로 볼륨 생성
2. docker volume ls 로 생성된 볼륨 확인
3. docker run -it -v [볼륨 이름]:[컨테이너의 공유 디렉터리] image 명령어를 통해, 컨테이너가 실행될 때 볼륨을 마운트해준다.
4. docker inspect --type volume [볼륨 이름] 명령어를 통해, 볼륨이 저장되는 위치 등의 여러 정보를 확인할 수 있다. 참고로 inspect는 컨테이너, 이미지 등 도커의 모든 구성 단위의 정보를 확인할 때 사용할 수 있다.

-v 옵션 대신 —mount 옵션을 사용할 수도 있다. 서로 기능은 같되, 볼륨의 정보를 나타내는 방법이 다르기 때문에 편한 옵션으로 사용하면 된다.

참고자료

• 시작하세요! 도커/쿠버네티스
• 도커 공식문서

이미지 관리

docker images : 도커 엔진에 존재하는 이미지의 목록 출력

docker pull [이미지 이름] : 원격 저장소(레지스트리)에 있는 이미지 다운

docker push [이미지 이름] : 원격 저장소에 로컬 이미지 업로드

docker build -t [생성할 이미지 이름]:[태그] [도커파일 경로] : Dockerfile을 바탕으로 이미지를 생성

• ex) docker build --platform linux/amd64 -t doforme524/withus ./
• -t : 생성할 이미지 이름 설정

docker rmi [이미지 이름]:[태그] : 이미지 삭제

docker search [이미지 이름] : 원격 저장소에서 이미지 검색. 별도의 레지스트리 명시 없으면 도커허브로 설정됨.

컨테이너 관리

docker run [이미지]:[태그] : 이미지로 컨테이너를 생성 및 실행. -it 옵션과 함께 사용하면 컨테이너 내부로 바로 접속된다.

• ex) docker run -it -p 8080:80 --name myContainer image:2.7
• -i : 상호 입출력
• -t : tty를 활성화해서 배시셸을 사용하도록 설정
• -p [호스트의 포트]:[컨테이너의 포트] : 외부에서 컨테이너에 접근할 수 있도록, 호스트와 컨테이너 간에 포트를 바인딩. ip도 지정할 수 있다.
• -d : 입출력이 없는 상태로 컨테이너 실행. 포그라운드 프로그램이 실행되지 않으면 컨테이너는 종료됨.
• -e : 컨테이너 내부의 환경변수 설정.
• -v [볼륨의 이름]:[컨테이너의 공유 디렉토리] : 볼륨 마운트
• —name [부여할 컨테이너 이름] : 컨테이너 이름 지정
• —link : 재시작시 매번 변경되는 컨테이너의 ip를 알 필요 없이, 항상 컨테이너 별명으로 접근하도록 설정한다.

docker start [컨테이너 이름 / 컨테이너 id] : 생성되어 있는 컨테이너 실행

docker stop [컨테이너 이름 / 컨테이너 id] : 실행중인 컨테이너 중단

docker rm [컨테이너 이름 / 컨테이너 id] : 중단된 컨테이너 삭제

• -f : 실행 중인 컨테이너도 삭제

docker prune : 모든 컨테이너 삭제

docker exec : 컨테이너 내부에서 실행한 명령어의 결과 반환

• docker exec -it [container] /bin/bash 의 형태로 사용하면, 컨테이너 내부의 셸을 사용할 수 있다.

docker logs [컨테이너 이름 / 컨테이너 id] : 컨테이너 내부의 출력을 보여준다.

docker ps : 정지되지 않은 컨테이너만 출력

• -a : 정지된 컨테이너를 포함한 모든 컨테이너 출력

볼륨

docker volume create [볼륨 이름] : 볼륨 생성

docker volume ls : 볼륨 나열

docker volume inspect [볼륨 이름] : 볼륨 상세 정보 확인

docker volume rm [볼륨 이름] : 볼륨 삭제

상세 정보 확인

docker inspect [컨테이너, 이미지, 네트워크, 볼륨 등] : 상세 정보 확인

• --type [container, image, volume 등] : 이름 중복 시 컨테이너가 가장 먼저 수행되므로, 타입 명시

도커 엔진은 애플리케이션을 빌드하고 컨테이너화하기 위한 오픈 소스 컨테이너화 기술이다. 클라이언트는 도커 데몬을 통해 컨테이너 빌드, 실행 등의 무거운 작업을 수행한다.

도커 데몬

도커 데몬(dockerd)은 Docker API 요청을 수신하고 이미지, 컨테이너, 네트워크 및 볼륨과 같은 Docker 객체를 관리한다. 데몬은 다른 데몬과 통신하여 Docker 서비스를 관리할 수도 있다.

도커 클라이언트

도커 클라이언트(docker)는 대다수의 도커 사용자가 도커와 통신하는 주요 방법이다. docker run과 같은 명령어를 입력하면, 클라이언트는 해당 명령어를 도커 데몬으로 전송한다. Docker API를 사용하며, 도커 클라이언트는 여러 데몬과 통신할 수 있다.

도커 데스크탑

맥, 윈도우 또는 리눅스 환경을 위한 애플리케이션으로, 컨테이너화된 애플리케이션 및 마이크로서비스를 구축하고 공유할 수 있다. 도커 데스크탑에는 도커 데몬(dockerd), 도커 클라이언트(docker), 도커 컴포즈, 도커 content trust, 쿠버네티스 및 credential helper가 포함된다.

도커 레지스트리

도커 이미지를 저장하는 곳이다. 크게 공개 레지스트리와 사설 레지스트리가 있다.

• 도커 허브는 누구나 사용할 수 있는 공개 레지스트리이며, 도커는 기본적으로 도커 허브에서 이미지를 찾도록 되어있다.

이미지

컨테이너를 생성 지침이 포함된 읽기 전용 템플릿이다. 이미지를 만들어 사용할 수도 있고, 레지스트리에 저장된 이미지를 받아와 사용할 수도 있다.

• 이미지를 만들기 위해서는 Dockerfile을 작성해야 한다.
• [저장소 이름]/[이미지 이름]:[태그]의 형태로 구성된다. 저장소 이름 생략 시 도커 허브로 지정된다.

컨테이너

이미지로부터 실행 가능한 인스턴스인 컨테이너를 생성할 수 있다. 또한, 이미지와 컨테이너는 1:N 관계이다.

컨테이너를 생성하면, 이미지의 목적에 맞는 파일이 들어있는 파일 시스템과 격리된 시스템 자원 및 네트워크를 사용할 수 있는 독립적인 공간이 생성된다. 설정에 따라 네트워크, 스토리지 또는 기타 기본 하위 시스템이 다른 컨테이너 또는 호스트 시스템에서 얼마나 격리되는지 제어할 수 있다.

컨테이너는 이미지를 읽기 전용으로 사용하고, 변경된 사항만 컨테이너에 저장한다. 즉, 컨테이너에 무엇을 하든 원래 이미지는 영향을 받지않는다.

참고 자료

• 시작하세요! 도커/쿠버네티스 책
• 도커 공식문서

도커는 애플리케이션을 개발하고, 전달하고, 실행하기 위한 오픈소스 플랫폼이다. 

기존의 가상화 기술은 하이퍼바이저를 이용해 여러 개의 운영체제를 하나의 호스트에서 생성하는 방식이었다. 해당 방식은 완벽한 운영 체제를 생성할 수 있다는 장점은 있지만, 일반 호스트에 비해 성능 손실이 있고 이미지의 크기가 커서 배포하기 부담스럽다는 단점을 가지고 있다.

• 성능 손실은, 각종 시스템 자원을 가상화하고 독립된 공간을 생성하는 작업이 하이퍼바이저를 반드시 거쳐야 하기 때문에 발생한다.
• 큰 이미지 크기는, 게스트 운영체제를 사용하기 위한 라이브러리와 커널 등을 모두 포함하기 때문이다.

이에 비해 도커 컨테이너는 이미지로 만들어 배포하는 시간이 가상 머신에 비해 빠르고, 성능 손실이 거의 없다는 장점이 있다.

• 리눅스 자체 기능인 chroot, 네임스페이스, cgroup을 사용함으로써 프로세스 단위의 격리 환경을 만들기 때문에 성능 손실이 거의 없다.
• 컨테이너는 호스트의 커널을 공유해 사용하고, 애플리케이션을 구동하는데 필요한 라이브러리 및 실행 파일만 존재하기 때문에 이미지 의의 용량이 대폭 줄어들었다.

이러한 컨테이너 기술을 사용함으로써 애플리케이션의 개발과 배포가 편리해지고, 여러 애플리케이션의 독립성과 확장성이 높일 수 있다.

• 개발할 때 사용하던 환경을 다른 서버에서의 컨테이너에서 똑같이 복제가 가능하기 때문에, 그저 개발하고 이미지로 만들어 운영 환경으로 전달하기만 하면 된다.
• 오늘날 대규모 서비스에서는 확장성과 유연성을 위해 마이크로서비스 구조를 많이 사용한다. 가령 데이터베이스에 데이터를 적재하는 모듈과 적재된 데이터를 가공하는 모듈을 서로 다른 컨테이너로 분리했다고 가정해보자. 이러면 모듈 간의 이미지 버전을 따로 가져갈 수 있어서 유지 보수가 용이해지고, 특정 모듈의 컨테이너 수만을 늘려 부하를 분산할 수도 있다.

참고 링크

• 시작하세요! 도커/쿠버네티스 책
• 도커 공식문서