쿠버네티스는 기본적으로 API 요청이 오면 위와 같은 순서로 작업을 처리합니다.

그 중간에 Mutating admission 부분에 Webhook을

이용한 pod injection 예제로 pod injection 하는 부분을 알아보고

예제가 오래된 관계로 v1beta1인 예제를 v1으로 업데이트하는 부분까지 할 예정입니다.

Webhook의 작동 방식

  • 출처 mutating webhook tutorial 깃헙

MutatingWebhook은 요청이 etcd에 등록되기 전에 MutatingWebhookConfiguration 의 rule과

일치하는 request를 intercept 합니다.

MutatingWebhook은 webhook 서버에 승인을 요청하여

mutation ( injection이라던지 수정같은 작업) 을 수행합니다.

( webhook 서버는 API를 준수하는 일반 http 서버)

예제

https://github.com/morvencao/kube-mutating-webhook-tutorial

이 튜토리얼은 nginx 사이드카 컨테이너를 파드에 injection 하는 MutatingAdmissionWebhook을 빌드하고 배포하는 방법을 보여줍니다.

조건

  • git
  • go version v1.12+
  • docker version 17.03+
  • kubectl version v1.11.3+
  • kubernetes v1.11.3+ cluster with admissionregistration.k8s.io/v1beta1 API enabled
    • 처음은 v1beta1로 작업하고 추후에 v1으로 수정할 예정.

admissionregistration.k8s.io/v1beta1 API enabled 확인 방법

kubectl api-versions | grep admissionregistration.k8s.io

결과는 아래와 같이 나와야합니다.

admissionregistration.k8s.io/v1 admissionregistration.k8s.io/v1beta1

빌드

  1. Build binary

# make build

  1. Build docker image

# make build-image

  1. push docker image

# make push-image

deploy

  1. sidecar injector webhook이 배포될 sidecar-injector  namespace를 생성

# kubectl create ns sidecar-injector

  1. sidecar injector deployment에 사용될 secret 생성

    (이 시크릿은 cert와 key 정보를 가지고 있다):

# ./deployment/webhook-create-signed-cert.sh \\ --service sidecar-injector-webhook-svc \\ --secret sidecar-injector-webhook-certs \\ --namespace sidecar-injector

  1. 위에서 생성한 caBundle 값을 mutatingwebhook.yaml 에 패치를 한 결과를 mutatingwebhook-ca-bundle.yaml로 생성한다.:

# cat deployment/mutatingwebhook.yaml | \\ deployment/webhook-patch-ca-bundle.sh > \\ deployment/mutatingwebhook-ca-bundle.yaml

  1. 리소스들을 배포한다.:

# kubectl create -f deployment/nginxconfigmap.yaml # kubectl create -f deployment/configmap.yaml # kubectl create -f deployment/deployment.yaml # kubectl create -f deployment/service.yaml # kubectl create -f deployment/mutatingwebhook-ca-bundle.yaml

확인

  1. sidecar injector webhook이 잘 배포됬나 확인한다.

# kubectl -n sidecar-injector get pod NAME READY STATUS RESTARTS AGE sidecar-injector-webhook-deployment-7c8bc5f4c9-28c84 1/1 Running 0 30s # kubectl -n sidecar-injector get deploy NAME READY UP-TO-DATE AVAILABLE AGE sidecar-injector-webhook-deployment 1/1 1 1 67s

  1. injection namespace 생성 그리고  sidecar-injector=enabled로 라벨링 한다.

# kubectl create ns injection # kubectl label namespace injection sidecar-injection=enabled # kubectl get namespace -L sidecar-injection NAME STATUS AGE SIDECAR-INJECTION default Active 26m injection Active 13s enabled kube-public Active 26m kube-system Active 26m sidecar-injector Active 17m

  1. alpine app을 예제로 쿠버네티스 클러스터에 배포한다.

# kubectl run alpine --image=alpine --restart=Never -n injection --overrides='{"apiVersion":"v1","metadata":{"annotations":{"sidecar-injector-webhook.morven.me/inject":"yes"}}}' --command -- sleep infinity

  1. sidecar container가 injected 됬는지 확인한다.

# kubectl get pod NAME READY STATUS RESTARTS AGE alpine 2/2 Running 0 1m # kubectl -n injection get pod alpine -o jsonpath="{.spec.containers[*].name}" alpine sidecar-nginx

admissionregistration.k8s.io/v1beta1 를 v1으로 업그레이드 하기

webhook의 작동방식부분에서 mutatingadmissionwebhook 부분과 webhook 서버를 보면

admissionReview를 요청하고 응답받는것을 보실수 있습니다.

v1beta1버전에서는 요청에 대한 응답시 kind와 apiversion 을 넣지 않아도 응답을 정상으로 판단 했습니다.

하지만 v1버전에서는 요청에 대한 응답시 kind와 apiversion 버전을 추가시켜줘야 합니다.

https://github.com/morvencao/kube-mutating-webhook-tutorial/blob/e72f4d5e501d61f22023efb26e16cda35a335941/cmd/webhook.go#L296

위 빈 라인에 아래와 같이 요청으로 들어온 api version 과 kind , uid를 그대로 review 응답에 넣어줍니다.

admissionReview.Response.UID = ar.Request.UID admissionReview.APIVersion = ar.APIVersion admissionReview.Kind = ar.Kind

위와 같이 할 경우 v1beta1로 요청이 들어왔을 경우 그대로 v1beta1로 응답하며

v1로 요청이 왔을 경우 그대로 v1로 응답이 갑니다.

그 후 deployment/mutatingwebhook.yaml 을 수정합니다.

apiVersion: admissionregistration.k8s.io/v1 kind: MutatingWebhookConfiguration metadata: name: sidecar-injector-webhook-cfg labels: app: sidecar-injector webhooks: - name: sidecar-injector.morven.me clientConfig: service: name: sidecar-injector-webhook-svc namespace: sidecar-injector path: "/mutate" caBundle: ${CA_BUNDLE} rules: - operations: ["CREATE", "UPDATE"] apiGroups: [""] apiVersions: ["v1"] resources: ["pods"] namespaceSelector: matchLabels: sidecar-injection: enabled admissionReviewVersions: ["v1"] sideEffects: None

위와 같이 수정하면 v1로 업데이트 완료입니다.

Injection 수정하기

webhook 서버에서 injection 처리 부분은 webhook.go 파일 입니다.

https://github.com/morvencao/kube-mutating-webhook-tutorial/blob/e72f4d5e501d61f22023efb26e16cda35a335941/cmd/webhook.go#L234

webhook.go 안에 createPatch 부분이 injection 할 내용을 생성하는 부분입니다.

이 부분으로 생성 후 apiserver로 다시 요청을 응답하는 작업이 이루어집니다.

이때 이 부분도 같이 response에 담겨서 응답하게 됩니다.

createPatch 부분을 참고하셔서 수정하시면 자신만의 injection 을 만드실수 있습니다.

createPath의 추가적인 참고는 하단의 tumblr github을 참고해주세요.

https://github.com/tumblr/k8s-sidecar-injector/blob/2478960ca6686798d26319956354b48e37108c29/pkg/server/webhook.go#L448

정리

mutating webhook은 추가적인 변경이나, 검증을 쉽게 제공해줘서 go를 처음접하는 저로써도

손쉽게 수정하여 저만의 injection 을 만들수 있었습니다.

다만 v1beta1에서 v1 patch부분이나 인증서 관련 부분은 삽질이 좀 필요해서 글로 남기게 됬습니다.

인증서 부분과 webhook 소스내부 설명은 다음글에 남겨보도록 하겠습니다.

'개발 > Kubernetes' 카테고리의 다른 글

왜 apiversion이 변경되어 있을까  (0) 2021.06.11
컨테이너 런타임  (0) 2021.03.07
쿠버네티스의 클러스터 구성  (0) 2021.01.28
k8s 에서 spring boot jib image command 수정  (0) 2020.12.24
클러스터 구성  (0) 2020.09.13

 

expected webhook response of admission.k8s.io/v1, Kind=AdmissionReview, got /, Kind=

 

  • 에러 내용

expected webhook response of admission.k8s.io/v1, Kind=AdmissionReview, got /, Kind=

 

  • 에러 원인

admission 의 webhook 응답이 기대한것과 다름.

나는 v1을 요청했으나 응답이 v1으로 오지 않았다는 것.

 

  • 해결

v1beta1은 따로 응답에 kind나 apiversion 을 기술하지 않아도 됬었는데

v1부터는 kind와 apiversion을 응답에 같이 넣어주면 된다.

 

	requestedAdmissionReview := v1.AdmissionReview{}
	responseAdmissionReview := v1.AdmissionReview{}

	if _, _, err := deserializer.Decode(body, nil, &requestedAdmissionReview); err != nil {
		level.Warn(a.logger).Log("msg", "Unable to deserialize request", "err", err)
		responseAdmissionReview.Response = toAdmissionResponseFailure("Unable to deserialize request", []error{err})
	} else {
		responseAdmissionReview.Response = admit(requestedAdmissionReview)
	}

	responseAdmissionReview.Response.UID = requestedAdmissionReview.Request.UID
	responseAdmissionReview.APIVersion = requestedAdmissionReview.APIVersion
	responseAdmissionReview.Kind = requestedAdmissionReview.Kind

	respBytes, err := json.Marshal(responseAdmissionReview)
  • 소스 출처 prometheus-operator github

 

 

블랙커피 블로그 스터디 3기를 시작하는 김에 뭐를 올릴까 고민을 했었습니다.

그렇게 고민하다가

"쿠버네티스를 점점 까먹고 있으니 복습을 해보자"

라고 마음먹고 쿠버네티스 관련 글을 적어보자고 결심했습니다.

저는 처음 쿠버네티스를 공부할때 클러스터의 기본구성을 먼저 공부하고

기본구성을 바탕으로 세세하게 공부했을때 효과가 꽤 괜찮았던 경험이 있어서

복습도 처음학습과 동일하게 가져갈 생각으로 클러스터의 구성을 먼저 복습하게 되었습니다.

쿠버네티스의 클러스터 구성

 

크게 쿠버네티스의 클러스터는 마스터노드 ( Control Plane ) 과 워커 노드 들로 이루어져 있습니다.

컨트롤 플레인

일명 마스터노드 라고 불리는 컨트롤 플레인입니다.

API Server와 Etcd , Scheduler , Controller manager 로 이루어져 있습니다.

보통 3대, 5대 구성을 많이합니다.

API Server

API Server가 제공하는 api를 이용하여 컨트롤 플레인과 워커 노드들은

이 api를 사용하여 서로가 통신할수 있게 됩니다.

ETCD

모든 클러스터 내의 정보를 담고 있는 저장소 입니다.

클러스터의 상태나 설정 정보를 저장하며 키 밸류 형태로 이루어져 있습니다.

스케줄러

리소스 생성시 노드에 알맞게 할당을 해주는 역할을 합니다.

컨트롤러 매니저

컨트롤러를 생성하고 이를 각 노드에 배포하며 관리하는 역할을 합니다.

컨트롤러

클러스터의 상태를 읽고 어떠한 작업을 실행하는 역할입니다.

노드

kublet과 kube-proxy , container-runtime 으로 이루어져 있습니다.

kubulet

클러스터의 각 노드에서 실행되는 에이전트로 API 서버와 통신을 하면서

노드의 상태를 전달하거나 마스터 노드로부터 명령을 받아 작업을 수행하는 역할입니다.

kube-proxy

클러스터의 각 노드에서 실행되는 네트워크 프록시로서 역할을 수행합니다.

userspace, iptables, ipvs, kernelspace 모드가 존재하며 현재는 iptables를 사용합니다.

Container Runtime

컨테이너를 실행을 담당하는 소프트웨어입니다.

대표적으로 Docker, containerd, CRI-O가 있으며 Docker는 1.23버전부터 제거될 예정입니다.

'개발 > Kubernetes' 카테고리의 다른 글

왜 apiversion이 변경되어 있을까  (0) 2021.06.11
컨테이너 런타임  (0) 2021.03.07
Mutating Webhook 를 이용한 pod injection  (0) 2021.02.16
k8s 에서 spring boot jib image command 수정  (0) 2020.12.24
클러스터 구성  (0) 2020.09.13

jib buildTar 옵션으로 빌드 후 tar로 떨궈지면

tar파일 안에 config.json 파일이 있다.

 

이 파일에 entrypoint가 있는데 이 entrypoint의 classpath경로가

우리가 빌드한 springboot의 spring boot classpath다.

 

jib는 jar로 패키징하는 단계를 skip 하고 바로 이미지로 빌드시킨다.

이유는 더 빠르기때문이다. ( jar패키징 단계를 skip해서 )

더 자세한이유는 참조링크확인.

 

따로 jar로 패키징하는 옵션도 줄수있다.

 

대충 entrypoint를 보면 java -cp [classpath] 일것이다.

k8s에서

docker의 entrypoint 는 command이고

docker의 cmd는 args다.

 

jib에 entrypoint밖에 없었으므로 command에 똑같이 넣어주자.

만약 -D옵션이나 jvm옵션을 k8s에서 직접 주고싶다면.

java jvm옵션 -D옵션을 주고 -cp [classpath] 이런식으로 작성하자.

 

이 옵션들은 모두 pom.xml의 jib plugin 옵션에서 설정할수 있다.

 

ps. jib의 default image는 distroless/java 다.

이 이미지에는 쉘이없다..

exec로 쉘 접근하고 싶다면 base image를 변경시켜줘야한다.

 

ps2. base image를 로컬에 있는걸 쓰고 싶다면 이미지이름 앞에 docket://를 붙여주면된다.

 

 

참조

https://github.com/GoogleContainerTools/jib/blob/master/docs/faq.md

https://kubernetes.io/ko/docs/tasks/inject-data-application/define-command-argument-container/#참고사항

'개발 > Kubernetes' 카테고리의 다른 글

왜 apiversion이 변경되어 있을까  (0) 2021.06.11
컨테이너 런타임  (0) 2021.03.07
Mutating Webhook 를 이용한 pod injection  (0) 2021.02.16
쿠버네티스의 클러스터 구성  (0) 2021.01.28
클러스터 구성  (0) 2020.09.13

기본구성

  • 마스터 - 노드1 - 노드2
  • VirtualBox를 이용해 CentOs7로 마스터 노드1 노드2 서버를 설치함.
  • 네트워크는 어댑터에 브릿지로 설정하여 마스터 노드 노드2의 아이피를 각각 다르게설정
  • 마스터는 192.168.35.30 노드는 31 노드2는 32
  • 마스터에 calico plugin 와 dashboard plugin 설치

트러블 슈팅

  • 처음에 강의처럼 192.168.0.x로 했다가 timed out이 발생
  • 그 이유는 내 호스트OS의 내부ip가 192.168.35.x 인걸 확인 후 수정
  • 마스터에서 kubernetes를 reset하는 상황이 발생
    • master 에서 자기자신을 node로 등록하려는 실수이후 node에서 master로 join이 안됨
    • 그래서 master에서 kubernetes를 reset함
    • reset 후 init로 초기실행하고 node들을 master에 join 시킴.
    • 하지만 master 에서 권한 문제가 생김
    • KUBECONFIG=/etc/kubernetes/admin.conf 이런식으로 쿠베컨피그에 설정하니 권한잘됨

참조

1. 설치 관련

https://www.cubrid.com/blog/3820603

https://kubetm.github.io/practice/appendix/installation_case2/

2. 2번 문제

https://github.com/kubernetes/kubeadm/issues/1721

https://stackoverflow.com/questions/61072700/issues-after-running-kubeadm-reset

https://github.com/kubernetes/kubeadm/issues/1721

효과적인 리팩토링 , TDD 연습방법.

의식적으로 연습해라 이것에 대한 7가지 원칙

  1. 효과적인 훈련 기법이 수립되어 있는 기술을 연마
  2. 개인의 컴포트 존을 벗어난 지점에서 진행, 자신의 현재 능력을 살짝 넘어가는 작업을 지속적으로 시도
  3. 명확하고 구체적인 목표를 가지고 진행
  4. 신중하고 계획적이다. 즉 개인이 온전히 집중하고 의식적으로 행동할것을 요구
  5. 피드백과 피드백에 따른 행동 변경을 수반해야 한다.
  6. 효과적인 심적 표상을 만들어내는 한편으로 심적 표상에 의존
  7. 기존에 습득한 기술의 특정 부분을 집중적으로 개선함으로써 발전시키고 수정하는 과정을 수반

1단계 - 단위테스트 연습

내가 사용하고 있는 api들을 이용하여 테스트

  • java String class의 다양한 메소드 사용법
  • java ArrayList에 데이터를 추가 수정 삭제하는 방법

효과

  • 단위테스트 방법을 학습할 수 있다.
  • 단위테스트 도구의 사용법을 익힐수 있다.
  • 사용하는 API에 대한 학습효과가 있다.

2단계 - tdd 연습

  • 실제 프로젝트 말고 토이프로젝트에서 연습하자.

  • 웹 모바일 ui나 db에 의존관계를 가지지않는 요구사항으로 연습한다.

  • 리팩토링 시 메소드를 분리를 잘해야 한다.

  • 메소드는 한가지 일만 하게 만든다.

    • 들여쓰기를 1단계만 허용한다.
    • 2단계부터는 메소드로 분리해서 리팩토링
    • else를 쓰지않는다.
  • 로컬 변수가 필요한지도 고민해본다.

  • Compose method 패턴 적용

    • 메소드의 의도가 잘 드러나도록 동등한 수준의 작업을 하는 여러단계로 나눈다.
  • Compose method 패턴으로 동등한 수준의 기능들을 각각의 메소드로 만들어서

  • 한눈에 무슨기능을 하는지 알수있게 하고 그 기능들이 어떻게 구현되는지 보려면

  • 메소드를 보는 방식으로 하고 메소드의 기능을 알려면 모든 코드를

  • 확인할 필요가 없는 장점이 있다.

  • 3개이상의 인스턴스 변수를 사용하지 않는다.

  • 인자의 갯수를 최소한으로 조절

  • 클래스도 가능한 작게 만들어라

영상

https://www.youtube.com/watch?v=cVxqrGHxutU&ab_channel=OKKY

문서

https://www.slideshare.net/OKJSP/okkycon-tdd

'개발 > java' 카테고리의 다른 글

공변 불변 반공변  (0) 2021.04.26
JVM 구조 복습 - 1  (0) 2020.08.03
enum 사용시 주의할점  (0) 2020.05.13
멤버변수의 초기화 시기와 순서  (0) 2020.04.15

www.notion.so/OAuth-1ac11441fca1492191283ef70c589b89

 

OAuth

OAuth

www.notion.so

OAuth

 

  1. OAuth

아이디나 암호가 노출되지 않고 api의 접근을 위임하는 방식

인증과 인가를 사용하는 방식

 

써드파티에 아이디 비밀번호를 넘기는건 위험하므로 api 토큰을 써드파티가 사용하게함

써드파티 어플리케이션이 api 토큰으로 api 서비스 정보를 요청하고 받아올수 있음

 

Request Token 의 요청과 발급이 이루어지고

사용자 인증 페이지 호출

사용자 로그인 완료

사용자의 권한 요청 및 수락

Access Token 발급

Access Token 을 이용해 서비스 정보를 요청

 

2. OAuth 1 과 2 의 차이점

2는 SSL을 사용함

2는 Client에서 암호화를 위한 코드를 삽입할 필요가 없음 (SHA1등)

 

1은 인증을 얻기 위해 web 환경만 지원

2는 web 말고 다른 환경도 지원함.

 

1은 보안토큰이 2개 사용되고 2는 하나만 사용됨

 

3. OAUTH2 기준 구현 방식이 뭐가 있고 어떤 시나리오에 적합한가

 

시나리오

적합한 시나리오는 서드파티 나 다른 어플리케이션 , 모바일 어플리케이션 또는

웹의 SPA 방식에서 아이디와 비밀번호를 노출하지않고 토큰으로 리소스를 가져오는 것

구현 방식

security에서 oauth 설정

인증 서버 클래스 설정

인가 서버 클래스 설정

(자세하게 추가 필요)

 

4. OAUTH2 기반으로 JWT 라는 게 있는데 이거는 뭐고 어떤 경우에 좋고 어떤 고려사항이 있는가

 

JWT 란

 

토큰을 JSON 방식으로 만들고 모든 정보 ( 토큰의 기본 정보 , 유저 정보, 토큰이 검증됐다는것을 증명해주는 시그니쳐 정보 ) 를 가지고 있고 헤더나 url에 넣어서 전달이 가능함.

총 3가지 부분으로 나뉘어져 있는데 . 으로 그것을 구분하며

 

첫번째 헤더 부분 은 토큰의 타입과 해싱 알고리즘이 등록 되어있고

 

두번째 내용 (페이로드 ) 부분은 등록된 클레임 , 공개 클레임 , 비공개 클레임이 등록되어있습니다.

 

등록된 클레임 은 서비스에서 필요한 정보들이 아닌 토큰에 대한 정보들을 담기위하여 이름이 이미 정해진 클레임들입니다.

예) 토큰발급자 iss , 토큰 제목 sub , 토큰 대상자 aud 토큰 만료시간 exp 등

 

공개 클레임은 충돌이 방지된 이름을 가지고 있어야 하므로 클레임 이름을 URI 형식으로 짓습니다.

예) "https://xxxx.xxx/aa/aa" : true

 

비공개 클레임은 클라이언트와 서버의 협의하에 사용되는 클레임 이름들입니다.

공개 클레임과는 달리 이름이 중복되어 충돌이 될수 있습니다.

예) "username" : "aaaa"

 

payload 예)

 

{

    "iss": "velopert.com",
    "exp": "1485270000000",
    "https://velopert.com/jwt_claims/is_admin": true,
    "userId": "11028373727102",
    "username": "velopert"
}

 

세번째 부분은 시그니쳐 부분입니다.

이 시그니쳐 부분은 헤더의 base64 인코딩 값 정보의 base64 인코딩 값을 합친 후 주어진 비밀키로 해쉬를 하여 생성.

 

JWT의 장점

jwt 발급 후 토큰 검증만 하면 되기 때문에 추가 저장소가 필요 없음

토큰 기반으로 하는 다른 인증 시스템에 접근이 가능

 

JWT의 고려사항

토큰의 페이로드에 3종류의 클레임을 저장하기 때문에 토큰의 길이가 엄청나게 길어질경우

네트워크에 부하를 줄수가 있다.

 

페이로드 인코딩은 자체 암호화가 아니라 base64인코딩이므로 중간에 탈취되서 디코딩하면

데이터가 보인다. 시그니쳐는 비밀키로 sha 해싱하기 때문에 알수가 없음.

 

stateless 무상태이기 때문에 제어 (임의 삭제, 수정 등) 이 불가 하므로 토큰 만료시간을 꼭 넣어줘야한다.

 

토큰은 클라이언트 측에서 관리해야 하기 때문에, 토큰을 저장해야 한다.

 

 

 

5. OAUTH 토큰을 어떤 식으로 전달하고 보관하는 것이 보안에 안전한가.

 

  1. 요청 헤더나 바디에 넣어서 전달하는 방법은 빠르나 보안에 매우 취약하다.
  1. 헤더에 쿠키를 담아 보내는 방법은 1번 보다는 안전하다 마찬가지로 탈취되면 보안에 취약함
    1. 계정정보가 담기지 않았으므로 1번보다는 안전하지만 탈취된 쿠키를 이용해 http 요청을 보내면 서버의 세션 저장소가 쿠키의 탈취 여부를 알수없어 그대로 정보를 제공함
      1. 해결책은 https 를 사용해 쿠키를 읽을수 없게 하거나 세션에 유효시간을 넣어준다.
      1. 세션 저장소를 사용하므로 서버에 어느정도 부하가 생김

       

  1. JWT 방식
    1. 장점
      1. stateless 하므로 따로 저장소를 사용하지 않습니다.
      1. 확장성이 뛰어나므로 토큰기반의 다른 인증시스템에 접근이 가능합니다. ( facebook, google 등)

         

    1. 단점
      1. claims가 많을수록 jwt가 길어짐. 요청이 많아질수록 자원낭비 발생함.
      1. 중요한 정보를 payload에 넣을수 없음. base64로 인코딩 되어있기때문에 손쉽게 디코딩해서 정보를 볼수가 있음.
      1. jwt 역시 탈취되면 유효기간이 지나기 전까지 정보가 탈취됨.
        1. AccessToken의 유효기간을 짧게하고 Refresh Token을 이용해 새롭게 인증을 요청시킬수 있게 변경해야함.

     

 

6. Resource Server

실질적으로 요청이 들어오면 access_token을 확인 후 유효한지 체크 하고

요청에 알맞는 리소스를 response 해주는 서버

 

 

 

 

 

참조 출처

 

Oauth2의 암시적 허용

https://docs.microsoft.com/ko-kr/azure/active-directory/develop/v2-oauth2-implicit-grant-flow

 

JWT

https://velopert.com/2389

 

JWT 고려사항

https://mangkyu.tistory.com/56

 

OAUTH 토큰 보안

https://tansfil.tistory.com/58

'개발 > etc' 카테고리의 다른 글

네트워크 복습 1  (0) 2020.08.14
JUnit5 에서 parameter 사용하기  (0) 2020.07.21
Lombok  (0) 2020.07.19
어플리케이션 아키텍처와 객체지향 영상 후기  (0) 2020.06.28
blob  (0) 2020.04.30

Notion Link

 

www.notion.so/Repository-Interface-Respoitory-6d78269d33d54e828ffb219153965eb7

 

Repository Interface에 @Respoitory가 없는 이유

@Repository 는 컴포넌트 스캔 뿐만이 아니라 JPA의 예외를 스프링에서 공통적으로 처리할수있는 예외로 변환하는 기능도 포함되어 있다.

www.notion.so

 

 

  • @Repository 는 컴포넌트 스캔 뿐만이 아니라 JPA의 예외를 스프링에서 공통적으로 처리할수있는 예외로 변환하는 기능도 포함되어 있다.

  • @Repository 를 생략가능한 이유는 컴포넌트 스캔을 스프링 데이터 JPA가 자동으로 처리해준다.

    • @EnableJpaRepositories 이 어노테이션이 그역할을 수행하고
      • 또 jpaRepository에 대한 설정정보를 자동으로 로딩함.
    • 부트는 EnableJpaRepositories 이 자동적용 되어있기 때문에 따로 할 필요가 없음.
  • 위에서 말한 JPA 예외를 스프링 예외로 변환하는 과정도 스프링 데이터 JPA가 자동으로 처리해준다.

 

 

참고

 

인프런 강의 - 김영한 실전 스프링 데이터 JPA

https://engkimbs.tistory.com/821

'개발 > jpa' 카테고리의 다른 글

post 와 comment 내가 선택한 출력 방식  (0) 2020.06.02
JPA  (0) 2020.03.03

+ Recent posts