1. 컨테이너 오케스트레이션
1) 개요
다수의 컨테이너를 유기적으로 연결 및 실행할 뿐만 아니라 상태를 추적하고 보전하는 등 컨테이너를 안정적으로 사용할 수 있게 만들어주는 것
2) 솔루션
- docker swarm
**:** 간단하고 설치도 용이한데 기능이 다양하지 않아서 소규모 환경에서는 유용하지만, 대규모 환경에서는 거의 사용하지 않음
- meos
: 아파치의 오픈 소스 프로젝트로 트위터, AirBnb, Apple, Uber 등에서 사용한 검증된 솔류션으로 대규모 서버 환경에서 자원을 유연하게 공유하고 하나의 자원처럼 관리하는 DC/OS의 지원으로 매우 간결하지만 기능이 충분하기는 한데 여러 가지 솔루션을 유기적으로 구성을 해야 하는 부담이 있음.
- nomad
: 베이그런트를 만든 해시코프 사에서 만든 솔루션으로 특징은 **docker swarm**과 거의 유사함.
- 쿠버네티스
: 다른 솔루션보다는 진입 장벽이 높음
2. 쿠버네티스
1)개요
=>컨테이너 기반의 애플리케이션을 개발하고 배포할수 있도록 설계된 오픈 소스 플랫폼으로 컨테이너 오케스트레이션 도구의 일종
=>k8s라고도 하는데 이유는 kubernetes 에서 k와 s 사이에 8글자가 있어
=>kubernetes 는 일반적인 프로그래머가 사용하지 하지 않음
-대규모 시스템을 개발하는 프로그래머가 대규모 서버 군을 직접 관리하는 일은 드뭄
-어떤 일을 할 수 있는가에 대한 지식을 시스템을 개발할 때 유용
-클라우드 환경을 개발하거나(퍼블릭이나 프라이빗 클라우드 구축) 클라우드 환경의 애플리케이션을 관리하는 경우에는 필수 항목 중의 하나
대규모 배치 처리를 해야 하는 상황
- 운영체제 차원에서 가능=>서버환경이 linux
- python에 airflow 에서 가능=>개발자들이 접근하기 쉬움
- kubernetes 의 cron 기능 =>kubernetes 가 하는 경우가 더 효율적
=>kubernetes 는 여러 대의 물리적 서버에 걸쳐 실행되는 것을 전제로 함: 네트워크 지식이 어느정도 갖춰줘야 함
2)리소스
=>node:컨테이너가 배치되는 서버
=>namespace: 쿠버네티스 클러스터 안의 가상 클러스터
=>pod:컨테이너 집합 중 가장 작은 단위 - Micro Service 단위
=>replicaset:같은 스펙을 갖는 파드의 집합
=>deployment:레플리카 세트의 리비전을 관리
=>service: 파드에 접근하기 위한 경로
=>ingress:서비스를 쿠버네티스 클러스터 외부에 노출 =>이부분이 도커가 가장 다른 부분.
=>configmap:설정 정보를 정의해서 pod 에 전달
=>persistent volume:파드가 사용할 스토리지
=>persistent volume claim:퍼시스턴트 볼륨을 동적으로 확보
=>storage class:스토리지 종류
=>stateful set:같은 스펙으로 동일한 파드를 여러 개 생성 및 관리하는 것
=>job:상주 실행(계속 구동중인 서비스)를 목적으로 하지 않는 피드를 여러개 생성하고 정상적인 종료를 보장
=>cron job:스케쥴링
3)노드
=>쿠버네티스 리소스 중에서 가장 큰 개념
=>쿠버네티스의 관리 대상으로 등록된 컨테이너가 배치되는 대상
=>쿠버네티스 클러스터 전체를 관리하는 마스터 노드가 1개 이상 배치되고 그 안에 여러개 의 노드(워커 노드)가 배치되서 하나의 클러스터를 이루게 됩니다
=>워커노드는 컨테이너 런타임이 설치된 환경에서 컨테이너 또는 도커를 실행하고 유지 및 관리하는 노드
Linux -> Docker Engine -> 각종 container 들이 배치(파드)
4)파드와 컨테이너
=>파드는 쿠버네티스에서 생성할 수 있는 가장 작은 배포 단위
=>파드 외에 서비스,볼륨,네임스페이스를 묶어서 오브젝트라고 합니다.
=>파드는 하나 이상의 컨테이너로 구성됨
=>도커는 컨테이너 단위로 배포를 하고 쿠버네티스는 파드 단위로 배포
5)특징
=>무중단 서비스: 서비스 중단 없이 애플리케이션을 업그레이드 할 수 있음
=>클라우드 벤더 종속성 해결(Lock-in: 특정 벤더에 접속)
현재 서비스 중인 모든 public cloyd vender 가 Docker와 Kubernetes 를 위한 서비스를 제공
=>효율적인 자원 관리:컨테이너나 파드를 사용하면 OS 자원 소모를 줄인 상태에서 서비스 들의 독립성을 보장할 수 있음:VM과 비교
=>유연한 확장성: 파드의 개수를 늘리거나 줄이는 것이 쉽다.
=>항상 바람직한 상태를 유지
-쿠버네티스는 파드를 항상 바람직한 상태가 되도록 자동 관리
-도커 컴포즈는 복제를 할 때 복제할 개수를 정하는 것 말고는 아무런 기능도 수행하지 않음
-쿠버네티스는 모니터링 기능을 탑재하고 있습니다
하나의 파드가 중지되면 자동으로 새로운 파드를 생성해서 파드의 개수를 유지
6)기본 구조 - 클라우드 환경을 구축하는 경우는 중요
=>클러스터
-마스터 노드
쿠버네티스 클러스터 전체를 관리하는 시스템으로 control plane
마스터 노드가 되는 컴퓨터에는 kubectl 을 설치해야 하는데kubectl 이 명령어 해석기
-워커 노드
마스터 노드의 명령을 받아서 파드를 생성하고 서비스하는 머신
-컨테이너 런타임
파드를 실행하는 엔진으로 도커가 가장 많이 사용
-영구 스토리지
데이터를 반 영구적으로 저장하기 위한 저장소
=>컴포넌트:마스터 노드에 존재
-API Server
클러스터로 요청이 들어왔을 때 그 요청이 유효한지 검증하는 컴포넌트
사용자의 권한 확인 및 명령어를 검증하는 부분
명령이 유효하면 워커 노드에게 파드 생성을 지시 - 파드는 만들어지지 않음
-etcd
API 서버는 파드를 생성한다는 사실을 etcd 에 알리는데 이 떄 클러스터의 상태를 저장
상태 정보를 저장하고 있는 컴포넌트
key-value 형태로 저장하고 사용자에게 파드가 생성되었다고 알려주지만 아직 파드는 생성되지 않은 상태
-scheduler
파드를 어떤 워커 노드에 위치시킬 것인가 하는 것을 확인하고 그 사실을 API 서버에게 알리고 API 서버는 이 사실을 etcd 에 알려서 저장
파드를 어떤 노드에 할당할지를 결정하는데 이 때 CPU 나 메모리의 사용량을 참조해서 결정
쿠버네티스와 도커는 GO로 만들어져 있어서 GO 를 알아야 함. 클라우드 개발자들은 일반 개발은 가능하나, 보통 CPU 나 메모리의 사용량 알고리즘 계산에 특화되어있음
-kubelet
워커 노드에 존재해서 API 서버로부터 파드의 생성 정보를 전달받아서 파드를 생성하고 운영을 수행하는 컴포넌트
파드를 생성하면 그 정보를 API 서버에게 전달하고 API 서버는 그 정보를 다시 etcd 에 저장
-Controller Manager
다양한 컴포넌트의 상태를 지속적으로 모니터링하고 실행상태를 유지하도록 해주는 컴포넌트
Public Cloud 에서는 이 부분을 별도의 서비스로 만들어서 제공
가장 유명한 서비스가 AWS 의 EKS
-Proxy
클러스터의 모든 노드에서 동작하는 네트워크의 프록시
네트워크의 규칙을 관리
클러스터 내부와 외부의 통신을 담당
-컨테이너 런타임
도커로 주로 사용되었는데 최근에 버전에서는 더이상 도커를 지원하지 않고 containerd 제공
7)외부 서비스:Public cloud 서비스 제공업체들은 PaaS 형식의 서비스 제공,Private Cloud를 사용하면 지접 설치를 해야지만 Public Cloud 를 사용하는 경우는 제공되는 서비스를 이용 가능
=>AWS 의 EKS
=>MS의 AKS
=>Google의 GKE
=>NHN의 NKS
=>KAKAO의 DKOS
=>Suse의 Rancher
=>Redhat의 Openshift
8)경량 버전의 쿠버네티스
=>k3s:Rancher 사에서 개발한 쿠버네티스의 경량 버전
=>minikube:단일 노드의 쿠버네티스 클러스터 환경을 제공
명령형 도구 설치:https://kubernetes.io/tasks/tools/
3.Pod
1)개요
=>Pod 는 Kubernetes 의 기본 배포 단위
=>하나의 pod 에 여러 개의 컨테이너를 포함시킬 수 있는데 이러한 패턴을 Sidecar 패턴이라고 합니다
=>Sidecar 패턴은 기본 기능을 하는 컨테이너와 부가 기능을 하는 컨테이너가 결합하는 방식
=>하나 이상의 컨테이너로 애플리케이션을 구현하다 보면 서로 강한 결합을 갖는 방식이 나은 경우가 종종 있어서 이런 경우 하나의 파드로 묶어서 일괄 배포
MySQL <-> Go <-> Nginx
이렇게 3개의 컨테이너가 필요한 경우 이 컨테이너 간의 관계를 조사
MySQL은 GO에서 사용을 하고 다른 컨테이너에서도 사용
Go 프로그램은 Nginx 에서만 사용하는 경우
배포방식은 3가지 정도
1.모든 컨테이너를 별개로 배포하고 각 컨테이너의 포트를 전부 오픈
2.3개의 컨테이너를 하나의 pod 로 묶어서 한꺼번에 배포하고 MySQL만 외부와 연결해서 사용하도록 하기
3.MySQL만 별도의 컨테이너로 배포하고 Go 와 Nginx는 하나의 파드로 묶어서 배포 -> 가장 좋은 방식
-되도록이면 같이 사용되는 것 끼리 묶는 것이 좋지만 목적이 공용인 것이 있다면 별도의 컴포넌트 또는 파드로 배포하는 것이 좋습니다
2)생성 방법
=>명령어를 직접 입력해서 생성
=>yaml 파일을 만들어서 생성 - 권장
최근에는 인프라를 만든 것을 수동으로 하지말고 코드로 수행하는 것(IaC)을 권장
3)명령어를 이용해서 pod 생성
=>생성 명령
-kubectl create:생성
-kubectl apply: create 와 replace 의 혼합으로 생성과 변경
=>아파치 웹서버(httpd)_를 하나만 복제해서 80번 포트를 개방하는 형태로 pod 생성
kubectl create deployment my-httpd --image=httpd --replicas=1 -- port=80
-deployment: 스테이트리스 형태의 pod 생성
-my-https:디플로이먼트 이름
- --image=httpd:pod 생성할 때 사용하는 이미지
- --replicas=1:실행 상태로 유지될 pod 개수
- --port=80: pod 에 접근할 때 사용할 포트 번호
=>Stateless 와 Stateful
- stateless: 사용자가 애플리케이션을 사용할 떄 상태나 세션을 저장해둘 필요가 없는 애플리케이션을 생성할 때 사용하는 옵션
-stateful: 사용자가 애플리케이션을 사용할 때 상태나 세션을 별도의 데이터베이스에 저장해야하는 애플리케이션에 사용
웹 애플리케이션이 여기에 해당
http나 https은 상태를 저장하지 않고 유지하지 않음
Cookie를 활용해서 상태를 저장함. 유일무이 키값을 넣어놓으면 상태를 저장함
Cookie 의 문제점
1.client 한테 저장되있음 => 보안에 취약함
2.요청할때마다 전송됨 => 보내기 싫은게 있어도 계속 보내야 함
이 문제점을 해결하기 위해 sever 쪽에 cookie 를 저장함 => 이게 session
연결을 유지하기 위해서 어떤 정보를 저장한다? => session
session이 있으려면 cookie가 있어야함
session을 보관하는 방법
1. memory 에 보관 -> 많은 유저들을 저장할 수 없음.
2. database 에 보관 ->RDBMS 는 느림. 따라서 In-Memory DB(Redis)를 활용.
session은 문자열만 저장가능 . 다른걸 저장하고 싶을 때 web storage 랑 web sql 랑indexed DB. 얘네는 javascript. storage는 key -value 저장하고 web sql은 sqlite3 indexed DB 는 NoSQL. 얘네는 문자열 말고 다른것도 저장 가능.
Cookie는 무조건 서버에 가져가야 하나, 위의 3개는 내가 선택해서 가져갈 수 있음
항상 시스템은 클라이언트가 요청 , 서버가 응답을 함
2가지를 생각해보기.
똑같은 요청을 보내면 똑같은 응답 2번 보내면 이건 자원의 낭비. 트래픽 낭비가 됨.
똑같은 정보를 안받으려면 client 쪽에 저장해놓고 똑같은 정보 다운안받게 요청함.
client -server 시스템은 인테넷이 기본.
굳이 서버랑 연결할께 아니라 내부에다가 저장해놓으면 인터넷없이 사용가능함.
chatting은 빠르게 왔다갔다 해야함.
요청과 응답을 계속하면 너무 속도가 느림.
이런것은 web socket 을 활용해서 응답해야함
추천시스템 만드는 것은 좋지만 영화가 업데이트되면 내가 알려줄꺼같음.
추천을 해서 고객이 오게 하는게 아니라 먼저 광고를 해야 고객을 유치할 수 있음.
=>deployment 가 제대로 되었는지 확인
kubectl get deployment
-NAME은 이름
-READY는 레플리카의 개수
-UP-TO-DATE:최신 상태로 업데이트 된 레플리카의 개수
-AVAILABLE:사용 가능한 레플리카의 개수
-AGE:실행되고 있는 시간
=>자세한 정보 출력
kubectl get deployment -o wide
-이미지 이름이나 컨테이너 이름도 출력
=>파드 정보 확인:deployment 대신에 pod 사용
kubectl get pod
=>deployment 삭제
kubectl delete deployment my-httpd
4)pod에 접속
=>파드 생성
kubectl create deployment my-httpd --image=httpd --replicas=1 --port=80
=>파드 내부에 접속(kubectl get pod로 파드 이름 확인)
kubectl exec -it 접속할 파드의 이름 -- /bin/bash
=>pod 로그 관리:모니터링 할 때 이용 - 대부분의 클라우드 사업자는 이 로그를 GUI 환경에서 볼수 있는 기능을 제공
kubectl logs 파드의 이름
4.Deployment
1)개요
=>kubenetes 에서 상태가 없는 애플리케이션 배포에 사용
=>레플리카 셋의 상위 개념
파드 -> 레플리카 셋 -> 디플로이먼트
=>Pod(Kubernetes 의 배포 단위) 배포에 관한 객체
=>Pod 를 배포하고 몇 개의 Pod 를 실행할 지 결정할 수 있음
Pod:여러 개의 컨테이너를 묶어서 쿠버네티스에서 배포하는 단위
-Deployment 나 Replicatset 을 이용하면 여러개의 pod 를 생성할 때 직접 명령어를 입력할 필요가 없음
-Pod 는 문제가 발생해서 종료되면 자동으로 다시 배포로 이루어짐/ 항상 바람직한 상태를 유지
2)업데이트 할 떄 배포 전략
=>Rolling Update
-Kubernetes 의 기본 배포 전략
-새 버전의 애플리케이션을 배포할 때 새 버전의 애플리케이션은 하나씩 늘려가고 기존 버전의 애플리케이션은 하나씩 줄여가는 방식
v1을 2개 배포하고 새로운 v2 가 새로 배포되는 경우
v1,v1 -> v1,v1,v2 -> v1,v2,v2 -> v2,v2
=>안정적인 배포 방식이지만 업데이트가 느리다는 단점이 있음
=>배포할 때 maxSurge 와 maxUnavailable 옵션을 이용해서 최대로 생성하는 파드의 개수와 최대로 삭제할 피드의 개수를 설정하도록 합니다
stratety:
type: RollingUpdate
rollingUpdate:
maxSurge:25%
maxUnavailable:25%
소스 코드 -> 코드 repository -> 이미지 build -> docker 나 쿠버네티스 배포
소스 코드 차원에서 이전 commit 으로 되돌려서 push를 하면 이전 commit으로 롤백된 효괄르 만들 수 있음
update v1
update v2
update v3
=>쿠버네티스는 이전 버전을 기억하고 있어 롤백이 가능
kubectl rollout undo [Deployment 이름]
-이전 상태로 되돌아감
=>recreate 업데이트
-예전에 On-Premiss 에서 많이 사용하던 방식으로 모든 파드를 중지시키고 새로운 버전으로 재생성하는 방식
-빠르게 업데이트가 가능
-새로운 버전의 pod에 문제가 발생하면 대처가 늦어짐
=>Blue/Green 업데이트
- 애플리케이션의 이전 버전과 최신 버전을 같이 운영
-서비스 목적으로는 최신 버전에만 이루어지며 이전 버전은 테스트 목적으로만 사용
-새로운 버전의 pod 에 문제가 발생할 때 빠르게 대응할 수 있습니다
-자원 소모가 심함
=>Canary 업데이트
-블루 그린과 유사
-새로운 기능을 테스트할 때 주로 이용
-두개의 버전을 모두 배포하는데 새로운 버전에는 트래픽을 조금씩 증가시키고 50 %까지 도달하면 업데이트가 중지
-테스트가 끝나면 이전 버전은 모두 제거 가능
-sticky session을 이용하면 사용자가 한번 접속한 서버에 계속 접속하도록 하는 것도 가능
V1,V1 ->V1,V1,V2,V2
업데이트를 수행하고 처음에는 V2에는 5%정도의 traffic 만 흘려보냄
설정에 따라 일정 비율씩 V2에 트래픽 증가
50 % 에 도달하면 업데이트 일시 중
안정화가 되면 둘 중 하나의 버전을 제거
A/B 테스트 할때 아주 유용함. 두개를 동시에 테스트하면서 일정부분은 v1, 일정부분은 v2을 누르게해서 A/B 테스트 하게함. sticky session을 활용하면 처음에 V1 에 간 유저는 V1 으로 가게만 하고 , V2 에 간 유저는 V2 에 가게 함.
우리 서비스에는 어떤 업데이트가 잘 어울릴지 잘 생각해야함.
3)nginx 배포
=>도커나 쿠버네티스 공부할 때 처음 연습은 apache(httpd)나 nginx 를 가지고 많이 합니다.
=>배포를 위한 yaml 파일 작성
=>배포
kubectl apply -f 야믈파일경로
=>상태 확인
kubectl get deployments
kubectl get pods
=>Pod, Replicaset ,Deployment
Deployment(배포) -> Replicaset (파드의 개수 설정 및 관리)->Pod(컨테이너의 집합)
하나의 microservice 를 구현하면 Pod 단위로 배포
2)service
=>Pod 는 만들어지더라도 외부에서 접속할 수 없습니다
=>Pod 를 외부에서 접속할 수 있도혹 해주는 것이 kubernetes 의 Service
=>Service 를 외부에 노출하면 외부에서 Pod 에 접속할 수 있습니다
일종의 Port Forwarding 의 역할
3)앞에서 배포한 Pod 를 외부에서 사용할 포트 연결한 yaml파일 생성
=>야믈파일 실행
kubectl apply -f 파일경로
=>서비스확인
kubectl get svc
4)Rollback
=>쿠버네티스는 Rolling Update와 더불어 Rollback 기능을 제공
Rolling update:업데이트를 할 때 기존 버전을 일단 그대로 두고 업데이트되는 새로운 pod 을 추가하고 이 파드가 정상적으로 동작하면 기존 버전의 Pod 를 하나 제거하고 또 새로운 버전의 Pod 를 추가해나가는 방식
이 업데이트 방식은 Public cloud 에서는 직접 구현할 필요가 없으며 Kubernetes 에서도 직접 구현할 필요도 없이 Container service 에서 선택만 해주면 됩니다
잘못된 컨테이너를 생성해달라고 요청을 하면 서비스 중단없이 롤백이 가능
개발자는 배포가 되었는지만 확인하면 됨
5)롤백 기능 확인
=>현재 배포된 파드의 이미지를 변경
kubectl set image deployment.v1 apps/nginx-deploy nginx=nginx:1.16.1
=>배포된 내용을 확인
kubectl describe deploy nginx-deploy
=>이미지 변경을 하는데 없는 이미지 버전으로 변경
kubectl set image deployment.v1.apps/nginx-deploy nginx=nginx:1.200
-기존 파드 2개는 존재하고 새로운 파드가 하나 추가되서 업데이트를 시도: 무중단 서비스
=>상태 확인
kubectl rollout status deployment/nginx-deploy
=>deployment 상태 확인
kubectl get deployment nginx-deploy
=>이전 상태로 롤백
kubectl rollout undo deployment/nginx-deploy
=>deployment 상태 확인
kubectl get deployment nginx-deploy
=>배포 버전 확인
kubectl rollout history deployment/nginx-deploy
=>특정 버전으로 롤백
kubectl rollout undo deployment/nginx-deploy --to-revision=버전번호
-docker-compose 와 다른 점은 이렇게 배포한 내역을 저장하고 있기 떄문에 필요한 버전으로 롤백이 쉽고 업데이트 한 내역을 보유하고 있습니다
-이렇게 변경내역을 관리하는 것을 형상(Configuration)관리라고 합니다
git 을 사용하는 가장 큰 이유는 코드의 형상 관리입니다
전에는 코드의 변경이나 운영 환경의 변경이 생기면 문서화를 했는데 이러한 문서화 작업 떄문에 오버헤드가 커짐
2.Replicaset
1)개요
=>일정한 개수와 동일한 Pod 가 항상 실행되도록 관리를 하기 위한 컴포넌트
=>쿠버네티스에서는 Replicaset 을 설정하게 되면 항상 Pod 의 개수가 일정하게 유지되도록 해줍니다
어떤 이유로 Pod 가 정상적으로 동작할 수 없는 경우 Pod 을 자동 생성해서 항상 바람직한 상태를 유지하도록 합니다
Public Cloud 회사 중 Region이나 가용영역이 많은 회사(Available Zone - Region 보다 작은 개념)을 선택하는 이유이기도 합니다
2)replicaset 동작 확인
=>야믈 파일 작성 - replicaset.yml
=>yaml 파일 생성: kubectl apply -f replicaset.yml
=>replicaset 잘만들어졌는지 확인:kubectl get pods
=>파드 삭제
kubectl delete pod 파드이름
=>파드 확인
kubectl get pods
-이전 파드가 삭제되자마자 새로운 파드가 만들어집니다
-Pod 가 삭제되거나 중지되는 것에 크게 신경 쓸 필요가 없어집니다
-개발자 입장에서 운영은 이전에 비해서 점점 쉬워집니다
=>Pod 개수 조정
kubectl scale replicaset/이름 --replicas=개수
이렇게 Pod 개수를 조정하기 쉽게 되있음
3.DaemonSet
Daemon:시스템이 실행될 떄 백그라운드에서 실행되서 사용자의 요청을 처리해주는 것
Docker 로 컨테이너를 만들어서 실행하는경우에 계속해서 서비스가 실행되어야 하면 Daemon으로 실행해야 합니다
서버라고 부르는 애플리케이션은 전부 데몬으로 실행되어야 합니다
=>모든 노드에 Pod 를 실행할 때 사용
=>모든 노드에 필요한 모니터링 용도로 사용
=>Private Cloud 를 구축해서 노드의 상태라던가 pod 의 상태를 모니터링 할 때 사용
public cloud 에는 우리가 설정하지 않아도 상태를 감시해서 모니터링 할 수 있도록 만들어져 있습니다
=>AWS 에서는 프로메테우스 + 그라파나 사용을 권장합니다
=>로그 수집을 목적으로 하는 경우 ELK(Elastic Search + Logstash + Kibana + Filebeats )Stack 사용을 권장
4.Job
=>cronjob: 주기적으로 어떤 액션을 발생시키는 잡
스케쥴 지정하는 방법은 이전 Linux 의 스케쥴 지정하는 방법과 동일
분 시간 일 월 요일
주기적으로 작업하는 Batch Processing (일괄 처리) 라고 합니다
=>yaml 파일 생성- cronjob.yml
=>yaml 파일 실행
kubectl create -f cronjob.yml
=>확인
kubectl get cronjob hello
kubectl get cronjob -w
**개발자나 서비스를 운영하는 입장에서 알아 둘 개념
=>Pod,ReplicaSet, Deployment:서비스 배포
=>Service:서비스를 외부에 노출
=>Cronjob:일정한 주기를 가지고 작업을 수행해야 하는 경우 - Linux 명령이나 Airflow 나 Spring Batch 같은 batch 작업 Framework를 이용하기도 합니다.
'Study > Cloud,Docker,Kubernetes' 카테고리의 다른 글
| Docker(4)-DockerCompose (0) | 2024.04.06 |
|---|---|
| Docker(3)-Dockerfile (0) | 2024.04.04 |
| Docker(2) (0) | 2024.04.03 |
| Docker(1) (0) | 2024.04.02 |
| Cloud(1)-개요 (0) | 2024.04.01 |
