반응형
  • 컬랙션 객체임을 JPA 에 알려주는 Annotation.
    @Entity 
    public class Person { 
    	@Id 
        private Long id; 
        private String email; 
        
        @ElementCollection 
        @CollectionTable( name = "address", joinColumns = @JoinColumn(name = "person_id") ) 
        List<AddressInfo> addressInfoList = new ArrayList<>(); 
    }
  • Entity 와 라이프 싸이클을 같이 하며 독립적으로 사용 불가능 하다.
  • 부모 Entity가 삭제될 경우 같이 삭제된다. (실제 클래스에 cascade 를 설정하는 옵션이 없다.)
  • ElementCollection의 Fetch 전략은 기본이 Lazy 이다.
  • 실제 테이블은 FK 를 이용해서 생성된다.
    Hibernate: create table address (person_id bigint not null, address1 varchar(255), address2 varchar(255), zip_code varchar(255))
    Hibernate: create table person (id bigint not null, email varchar(255), primary key (id))
    Hibernate: alter table address add constraint FK81ihijcn1kdfwffke0c0sjqeb foreign key (person_id) references person
  • CollectionTable Annocation 을 사용하지 않을 경우에는 다음과 같이 테이블이 생성된다.
    Hibernate: create table person_address_info_list (person_id bigint not null, address1 varchar(255), address2 varchar(255), zip_code varchar(255))
728x90
반응형
반응형

JPA 가 엔티티 데이터에 접근하는 방식을 지정한다.

1. AccessType.FIELD : 필드에 직접 접근한다.

@Access(AccessType.FIELD)
private String address1;

2. AccessType.PROPERTY : 프로퍼트로 접근한다. 

@Access(AccessType.PROPERTY)
public String getAddress2() {
	return address1 + address2;
}

3. AccessType 이 지정되지 않은 경우는 @Id 위치에 따라 지정된다.

@Entity
public class OrderInfo {
    @Id
    private Long id;
    private String address1;
    @Transient
    private String address2;

    @Access(AccessType.PROPERTY)
    public String getAddress2() {
        return address1 + address2;
    }

    public void setAddress2(String address2) {
        this.address2 = address2;
    }
}

- @Id 위치가 필드에 있기때문에 기본적으로 AccessType.FIELD 가 적용된다. AccessType.PROPERTY를 같이 적용하기 위해서는 메소드 위에 AccessType.PROPERTY 를 넣어주면 된다.

4. 기타 설명들

@Access is used to specify how JPA must access (get and set) mapped properties of the entity. If access type is set to FIELD, the values will directly be read/set on the field, bypassing getters and setters. If set to PROPERTY, the getters and setters are used to access the field value.

FIELD 로 정의하면 다이렉트로 field를 read/set 하고 PROPERTY로 설정하면 getter, setter 메소드를 통해서 접근한다.
https://stackoverflow.com/questions/19264871/what-is-the-use-of-the-access-annoation-in-jpa-means-at-the-entity-level

 

If you use field-based access, your JPA implementation uses reflection to read or write your entity attributes directly. It also expects that you place your mapping annotations on your entity attributes. If you use property-based access, you need to annotate the getter methods of your entity attributes with the required mapping annotations. Your JPA implementation then calls the getter and setter methods to access your entity attributes.

5 reasons why you should use field-based access
Better readability of your code
Omit getter or setter methods that shouldn’t be called by your application
Flexible implementation of getter and setter methods
No need to mark utility methods as *@Transient*
Avoid bugs when working with proxies

https://thorben-janssen.com/access-strategies-in-jpa-and-hibernate/

 

 

728x90
반응형
반응형
  • Image 를 export 하는 방법

docker save [option] [tar filename] [image name]

REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
nginx        latest    fa5269854a5e   2 weeks ago   142MB

docker save -o test.tar fa5269854a5e

 

  • 실행중인 컨테이너를 export 하는 방법

docker export [container name or containter ID] > [tar filename]

CONTAINER ID   IMAGE          COMMAND                  CREATED          STATUS          PORTS                NAMES
791601bf0587   nginx:latest   "/docker-entrypoint.…"   33 minutes ago   Up 33 minutes   0.0.0.0:80->80/tcp   mystifying_benz

docker export 791601bf0587 > test.tar

 

 

728x90
반응형
반응형

지난달 CKA 자격증 취득에 이어서 CKAD 자격증도 따게 되었다. 이것도 작년에 사놓은 바우처가 올해 12월 까지 였는데 CKA 자격증 준비하면서 공부했으니 잊어버리기 전에 같이 해보는게 좋을것 같다는 생각을 했다. CKAD 를 먼저 본 분들의 후기를 보면 최근에 본 글들이 많이 없었다. 거의다 작년에 변경되기 전에 시험을 보신분들이 많았다. 일단 변경된 시험 범위는 아래 와 같다. 

출처 :&nbsp;https://github.com/cncf/curriculum/blob/master/CKAD_Curriculum_v1.23.pdf

  • CKA 와 CKAD 문제 구성의 차이점

- docker, heml

CKA 준비할때에는 k8s 의 리소스를 생성하고 수정하는 것은 많이 연습을 해봤는데 docker 나 helm 까지는 많이 해보지는 않았다. 그래서 부랴부랴 udemy 강의에서 변경된 부분에 대한 강의만 다시 들어보았다. 강의와 연결된 실습도 크게 어려움없이 풀었다. 문제에서는 이미지를 build 하고 이미지를 export 하는 문제가 나왔었다. 

- job, cronjob

job 을 생성하는 문제, cronjob 을 생성하는 문제들이 다양하게 섞어서 나왔다. 특히 job 에 대한 옵션들을 많이 주어지는데 그런 부분들을 다 반영해서 만들어야 한다. 

- probe

job 만큼이나 많이 나온 문제이다. probe 를 생성하는 문제, probe 때문에 pod 가 기동이 안되고 있는데 수정하라는 문제등의 문제가 나왔었다. 

- securtyContext

이부분은 serviceAccount와 연계해서 나온 문제들이었는데 sa를 생성해서 pod 에 정의해주라는 문제와 pod 로그를 보고 문제점을 해결하라는 문제였는데 그건 sa 이름이 실제와 이름이 달라서 생긴 문제였었다. 

  • 문제를 잘 읽자

CKA 시험과 마찮가지로 문제의 요구사항이 한가지가 아닌경우가 많다. 문제를 끝까지 읽어야 하고 주어진 조건을 반드시 모두 반영을 해야 한다. 그리고 문제에 Pod 를 수정하거나 삭제하지 말고 진행하라는 요구사항들도 주의깊게 봐야 한다. 영어를 번역하는데 헷갈린다면 구글 번역기 크롬 플러그인을 깔아서 확인해보는것도 방법이다. 이것은 문제 삼지 않는다.

  • 결과

총 16문제였는데 문제 하나하나 마다 대부분 배점이 높아서 정말 난감했다. 4점짜리는 많이 못본것 같다. 그리고 진짜 시간이 부족했다. 내가 몰라서 찾아본것이 있어서 그런것도 있겠지만 CKA 시험보다는 시간이 정말 빠듯했다. 그래서 마지막에 내가 완벽히 못푼 문제들의 배점을 세어봤다. 그랬더니 34점 점도가 됐었다. ㅡ,.ㅡ;;; 통과 점수는 66점인데 34점이면 완벽히 못푼 문제들을 제외하고 나머지는 다 맞아야 한다는 결론이었다. 이 34점 중에 8점자리 하나는 "맞겠거니" 라고 생각했던 문제가 있었는데 74점인거 보면 아마도 그게 맞지 않았나 싶다. 실제 결과는 알수가 없지만..

그래서 예상을 하기에 66점으로 딱 pass하거나 떨어지면 근소한 차이로 또 떨어지겠거니 했는데 다행스럽게도 pass를 했다. 물론 만족할 만한 점수는 아니지만 그래도 붙어서 다행이다.

자격증을 땄다고 해서 그걸 잘 아는것은 아니기 때문에 앞으로도 더 공부를 해야 하겠지만 지난번 시험이후에 또 한가지 무언가를 했냈다는데에 큰 기쁨을 얻었다. 

728x90
반응형
반응형

K8S의 container 에 정의되는 args 와 command 에 대한 차이점은 다음과 같다. 

Docker image 빌드시에 ENTRYPOINT 와 CMD 를 정의 할 수 있다.

ENTRYPONT : 컨테이너가 실행될 때 반드시 default 로 실행된다. 따라서 컨테이너가 수행될 때 변경되지 않을 실행명령은 ENTRYPOINT 로 정의하는게 좋다.
CMD : 컨테이너 실행시 파라메터를 추가 하게 되면 추가된 파라메터를 실행시킨다. 

이때 k8s 에서 정의하는 args 는 Docker 이미지의 CMD 에 바인딩 되고 command 는 ENTRYPOINT 에 바인딩 된다. 이름때문에 command가 CMD 에 바인딩된다고 착가하면 안된다.

 

728x90
반응형
반응형

험난하고 많은 일이 있었던 CKA 자격증 시험을 준비하는 과정과 시험 과정에서 발생했던 어이없는(?) 상황에 대해서 이야기 해보려한다.

이야기 순서는 다음과 같다. 

1. CKA 시험 준비
2. 2번의 Fail.
3. 다시 바우처 구입과 재시험 & 시험봐야 하는데 Proctor는 어디에??
4. 합격 후기
5. 남겨진 문제들

그럼 이야기를 시작해보자.

1. CKA 시험준비

지금이 2022년이고 어느덧 4월이다. 나는 바우처를 작년 5월에 구입을 했다. 올해도 똑같은 해택을 줄지는 모르겠지만 작년에 있었던 Virtual KubeCon 을 참석한 혜택으로 50% 할인 가격으로 CKA 바우처를 구입할수 있었다. 그리고 나도 CKA를 응시했던 많은 분들이 들었던 Udemy 강의(Certified Kubernetes Administrator (CKA) with Practice Tests)도 구입해서 공부를 하기 시작했다. K8S 를 많이 사용하지는 않았지만 가끔 사용할 일이 있어서 관심은 있었고 뭔가 배우면서 재미있어서 공부를 했었다. 그러다가 시험을 봐야지 봐야지 하면서 미루다가 어느덧 바우처 만료일이 2022년 5월이라는것을 알고 다시 준비하기 시작했다. 강의에 있는 Mock Exam 도 풀어보고 여기저기 블로그의 글들도 많이 찾아봤다. 시험에 관련된것 보다는 아래 부분에서 불편함이 컸다. 

- 사이트가 느려도 너무 느리다.

바우처를 구매하고 시험을 신청하기 위해서는 시험 신청화면에서 Schedule 버튼을 누르게 되어있다. 그러면 아래와 같은 화면이 나온다.

저 화면에 나오기 전에 날짜와 타임존을 선택화면이 나오는데 거기서부터 인내심이 아주 많이 요구된다. 분명 달력 조회하는 화면인데 처음 하다보면 한번 조회할때마다 2~3분은 기본이다. 저 화면에서도 날짜를 선택하고 아래 Time 이 나오는데 저 결과도 당연히 바로바로 안나온다. 심지어 조회 결과가 누를때마다 다르게 나오는 경우도 있다. 스터디룸 예약시간하고 시험 시간을 맞춰야 해서 시험시간을 조회했는데 처음에는 없었던 Time 이 다시 조회하니깐 나오는 신기한 경우를 자주 목격했다. 그렇기 때문에 본인이 원하는 시간이 Time 항목에 없을 경우 다시 한번 조회를 시도해보는게 좋다. 

- 신분증

신분증은 보통 여권을 사용하는게 좋다고 했는데 난 이미 여권이 만료되어서 여권을 따로 만들어야 하나 생각을 했었다. 그러다가 신용카드를 보여줘도 괜찮다는 글들이 있어서 여권은 안만들기로 했다. Proctor 가 id 를 요구할때 운전면허증과 신용카드를 차례대로 보여줬다. 운전면허증만 보여줘서는 안되는것 같고 반드시 영문으로 적힌 이름이 있는 ID 가 필요한것 같다. 그리고 카드를 보여준후 뒷면의 사인 부분도 보여달라고 한다. 난 사인이 내 한글 이름으로 써있는데 그것까지는 문제삼지 않았다. 

2. 2번의 Fail

위 결과를 보면 알수 있듯이 난 1개의 바우처에서 사용할수 있는 2번의 기회를 다 놓쳤다. Score 를 보면 처음에는 62, 두번째는 64 였다. 처음 시험보고 62가 나와서 내가 좀 갸웃거렸던 문제들을 다시 생각해서 좀 찾아보고 다시 재시험을 봤다. 그런데 최소한 첫번째 시험보다는 두번째에서 더 풀었다고 생각했었는데 점수차이가 별로 나지 않았다. (참고로 나같은 경우는 첫시험과 두번째 시험이 거의 동일하게 나왔다. 매번 그러는지는 모르겠으나 나중에 3번째 시험볼때도 거의 비슷하게 나왔다.) 결론적으로 비슷한 문제를 다시 비슷하게 풀어서.. 같은 문제 또 틀렸다는 이야기이다. 대체 왜?? 처음 시험보다 몇개는 더 결과를 냈기 때문에 최소한 2점보다는 더 오를거라 생각은 했는데 이모양이라니.?

2번의 시험을 다 떨어지고 망연자실 하다가 다시 인터넷을 검색해봤다. 내가 풀었던 문제들의 키워드 중심으로 검색을 다시 해봤는데 비슷한 문제풀이를 해놓은 블로그들이 있었다. 그래서 그 글들을 천천히 읽다 보니 문제점이 뭐였는지 알게 되었다. 문제점은 다름 아닌 영어 해석을 잘못했거나 조건을 끝까지 보지 않아서 잘못본것이다. 정말 그렇게 찾아보고 나니 더 허탈한 마음을 지울수가 없었다. 약간 멘탈이 나갔다고 해야 하나.

바우처를 다시 사서 해야 하나 아니면 할인을 기다릴까 라는 고민들이 깊어질 찰라에 25% 할인을 해서 일단 바우처를 구매를 했다. 그리고 시험을 언제볼까하다가 다시 한번 도전했다. 3주에 걸쳐서 주말마다 시험을 봤다. 이제는 기필고 완료하겠다는 다음을 하고 지난 주말 토요일 오전에 스터디룸에 가서 시험을 보게 되었다. 그런데 정말 가장 황당한 일이 이때 벌어졌다. 

3. 시험봐야 하는데 Proctor는 어디에??

내가 예약한 시간은 오전 11시부터 오후 1시였다. Take Exam 버튼은 15분 전에 활성화가 되기 때문에 10시 45분에 접속을 했다. 두번째 시험때에는 시험시간전에 미리 접속을 했더니 Proctor 가 시험시작시간 전에 id 체크랑 룸 체크를 해서 그생각을 하고 미리 접속했다. 그런데 이번에는 11시 전에 아무 반응이 없었다. 아래 보여지는 화면만 볼수 있었다. 그래서 이번 Proctor 는 정시부터 시작하려나?? 생각하고 있었다. 

그런데 시험시간인 11시가 되어도 위 화면만 계속 나왔다. 그렇게 한 20분정도 보냈다. 그러다가 안되겠다 싶어서 위에 적힌 전화번호중 첫번째 번호로 전화를 했다. 전화를 하니 당연히 영어로 나온다. 한참 듣다가 psi support 어쩌고 하길래 그건가 싶어서 번호를 누르고 기다렸다. 다행히 상담원이 전화를 받는데 당연히 외국인이다. 짧은 영어로 상황을 설명하고 나니 뭔가 체크를 했다. 내 운영체제랑 os 버전등. 아마도 jira 같은걸로 상담을 관리하는데 거기에 적어야 되는 항목인것 같았다. 그런데 이야기를 하다보니 내 노트북에 공유 문제인것 같은 체크를 계속 하길래 전에도 동일한 시험을 동일한 장소에서 동일한 노트북으로 했고 내 장비에는 문제가 없다고 이야기를 했다. 그리고 한참 이야기를 하더니만 공유프로그램 깔아달라고 해서 깔아주고 상담원이 내 노트북에 원격 접속해서 체크를 했다. 

체크 결과 당연히 내 장비에는 문제가 없었다. 그리고 쫌만 기다려 달라고 계속 하고 뭔가 상황이 나아지지는 않았다. 왜 Proctor 가 안온건지, 아니면 할당이 안된건지, 지금 시험을 진행할수 있는 Proctor 가 있는지 물어봤지만 정확히 대답을 해주지는 않았다. 

그러다가 내 노트북 원격으로 지원은 연결된 채로 전화가 끊겼다. 그때가 한시간정도 통화할때쯤이었다. 그래서 화면이 공유되고 있었기 때문에 내 노트북 브라우저에 핸드폰 전화번호를 적었다. 전화해달라고.. 그런데 한 10분 기다려도 전화가 안오길래 다시 전화를 했다. 그랬더니 다른 상담원이 전화를 받아서 처음에 했던 일을 반복하는 것이었다. 이때 상담원이 issue id 라는것을 말해줬는데 그 issue 아이디를 기존 상담원이 볼수 있도록 브라우저에 적었다. 그리고 나서 좀 이따가 상담원이 기존 상담원이 다시 전화를 할꺼라면서 전화를 끊었다. 그리고 몇분 있다가 다시 처음 상담을 했던 상담원에게 전화가 왔다. 

상담원이 다시 연결되고 일을 어떻게 처리 하는지는 모르겠지만 일단 기다렸다. 그리고 오늘 시험을 볼수 있냐고 물어봤더니 볼수 있다고 해서 난 그저 기다릴 수밖에 없었다. 그리고 시간이 더 흘러서 12시 45분쯤 되서 시험이 다시 시작되었다. 내가 예약한 스터디룸 시간이 10시 30분부터 1시 30분까지였는데 시험을 보기에는 충분치 않았고 2시 이후에 예약이 이미 잡혀있어서 바로 옆 룸을 예약해서 시험을 보게 되었다. 옆에 룸마저 예약이 되어있었다면 어찌 됐을지...

우여곡절끝에 12시 45분부터 사전체크를 하고 난 1시부터 120분간 시험을 보게 되었다. 이미 장시간 영어 통화로 인해서 기운이 다 빠진 상태였으나 일단 시험은 무난하게 잘 봤다. 시험을 끝내고 나니 기운이 다 빠졌다. 

4. 합격 후기

이상한 일을 겪긴 했지만 시험은 패스를 했다. 93을 예상했지만 85점인거 보니 내가 생각했던 문제 이외에 다른 문제도 틀렸나보다. 틀린것을 예상한 문제는 Ingress 를 생성해서 service 랑 연결하는 문제였는데 아무리 생각해도 제대로 한것 같은데 Ingress 의 ADDRESS 가 바인딩이 되지 않았다. 그래서 이문제는 틀리겠구나 싶었는데 그것 이외에도 다른 문제가 틀렸다니.. 뭐가 틀렸는지 궁금하긴 하지만 알 방법이 없다.

5. 남겨진 문제들

시험을 보고난 저녁에 LinuxFoundation 쪽에 문의 를 보냈다. 왜 이런 상황이 발생했는지. 그리고 내가 한시간넘게 통화한 국제 통화료는 처리가 될지 를 포함해서 문의를 보냈다. 통신사에 문의를 해보니 발생한 통화료는 55000원 정도, 부가세를 포함하면 6만원 정도가 된다. 한시간 넘게 통화한거라서 정말 많이 나올줄 알았는데 그래도 생각보다 덜나오긴 한것 같다. 일단 현재는 문의만 한 상태이고 처리에 대한 응답은 받지 못한 상태이다. 

참고 ) 1,2 차 탈락 후 광탈 한 후에 참고하게 된 사이트들 (시험에 나왔던 단어들 키워드로 검색한 결과.....문제가 다시 나온다는 보장은 모르겠음..)

https://daintree.tistory.com/18
https://ls-altr.tistory.com/82
https://programs.wiki/wiki/kubernetes-k8s-s-17-requirements-practice-tests.html

728x90
반응형
반응형

Network Policy 에 관한 설정들 참고할 만한것 몇가지 작성해본다.

아래 두개의 NetworkPolicy 는 아래 조건을 만족한다.

  • test1 네임스페이스에서 pod 끼리는 전부 호출 가능하다
  • test1 네임스페이스에서 test2로만 호출가능하며 포트는 80 포트를 사용한다. 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np
  namespace: test1
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
     - namespaceSelector:
        matchLabels:
         kubernetes.io/metadata.name: test2
  - ports:
    - port: 80
      protocol: TCP
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np
  namespace: test2
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
   - from:
     - namespaceSelector:
        matchLabels:
         kubernetes.io/metadata.name: test1

위에 정의된 부분을 확인해보자면 다음과 같다.

  • podSelector: {} : 해당 네임스페이스의 모든 pod 에서는 호출 가능하다.
  • egress.to.namespaceSelector : 네임스페이스의 라벨을 정의함으로써 라벨이 일치하는 네임스페이스로 호출가능하다.
  • ingress.from.namespaceSelector : 일치하는 라벨의 네임스페이스에서반 inbound 접근이 가능하다.
  •  

확인을 위해서는 curl 을 이용한다.

  • 우선 서비스의 도메인 이름은 서비스이름.네임스페이스.svc.cluster.local 로 정의된다. 
  • 도메인에 대한 정보는 pod 의  /etc/resolv.conf 로 확인 가능하다.
728x90
반응형
반응형
Add a spring.config.import=configserver: property to your configuration.
If configuration is not required add spring.config.import=optional:configserver: instead.
To disable this check, set spring.cloud.config.enabled=false or 
spring.cloud.config.import-check.enabled=false.

Spring Cloud Config Server 랑 Client 구성하다가 위와 같은 에러를 보게 되었다... 분명 라이브러리랑 맞게 들어간것 같은데.

gradle 에 설정된 dependency는 다음과 같이 정의 했다.

implementation 'org.springframework.boot:spring-boot-starter-web'
implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
implementation 'org.springframework.boot:spring-boot-starter-validation'
implementation 'org.springframework.boot:spring-boot-starter-actuator'
implementation 'org.springframework.cloud:spring-cloud-starter-config'
implementation 'org.springframework.cloud:spring-cloud-config-client'

우선 찾아보니 내가 bootstrap.yml을 로드하는 과정에서 문제가 있던 거였다. 다음과 같이  bootstrap.yml 을 정의해놨었다.

spring:
  application:
    name: myapp
  profiles:
    active:
      dev
  cloud:
    config:
      server:
        uri: http://localhost:8888

그런데 이걸 로드하기 위해서는 라이브러리가 추가로 필요했던 거였다.

To use the legacy bootstrap way of connecting to Config Server, bootstrap must be enabled via a property or the spring-cloud-starter-bootstrap starter.

(출처 : https://docs.spring.io/spring-cloud-config/docs/current/reference/html/)

위 글에서처럼 bootstrap 방법으로 Config Server 를 접근하기 위해서는 spring-cloud-starter-bootstrap 을 추가해줘야 한다고 되어있다. 그래서 다음과 같이 build.gradle 파일에 라이브러리를 추가했다.

implementation 'org.springframework.cloud:spring-cloud-starter-bootstrap'

그런데 위 글을 보면 뭔가 이상한 점이 있다. 잘 보면 legacy bootstrap way 라고 되어있다. 음.. legacy 라니. 그럼 이제는 이렇게 안써도 되는건가. 위 링크를 찾아가서 위로 살짝 올라가면 다음과 같은 글이 또 있다. 

Spring Boot 2.4 introduced a new way to import configuration data via the spring.config.import property. This is now the default way to bind to Config Server.
To optionally connect to config server set the following in application.properties:
application.propertiesspring.config.import=optional:configserver:
This will connect to the Config Server at the default location of "http://localhost:8888". Removing the optional: prefix will cause the Config Client to fail if it is unable to connect to Config Server. To change the location of Config Server either set spring.cloud.config.uri or add the url to the spring.config.import statement such as, spring.config.import=optional:configserver:http://myhost:8888. The location in the import property has precedence over the uri property.

정리하면 이렇다. 

1. bootstrap.yml 을 이용해서 Config Server 를 찾는 경우

  • spring-cloud-starter-bootstrap 라이브러리가 필요하다.
  • spring-cloud-starter-bootstrap 는 spring.cloud.bootstrap.enabled=true 로 설정하면서 bootstrap 에 정의 해놓은 spring.cloud.config.uri 를 통해 Config Server 를 찾는다.

2. bootstrap.yml 을 이용하지 않는 경우

  • application.yml 파일에  spring.config.import=optional:configserver 라고 정의를 하면 default 로 http://localhost:8888 주소로 Config Server 를 찾는다.
  • 주소를 변경하고 싶으면 spring.config.import=optional:configserver:http://host:port 로 정의해주면 된다.

그래서 난 2번 방법으로 application.yml 파일에 다음과 같이 정의했다.

spring:
  application:
    name: tuja
  profiles:
    active: dev
  config:
    import: optional:configserver:http://localhost:8888

 

728x90
반응형
반응형
  • 엔컴퓨터 디바이스로 이루어진 네트워크는 신뢰할 수 있다.
    • 네트워크 실패 가능성을 고려하지 않으면 도착하지 않는 응답을 기다리며 멈춰있을 수 있다.
  • 요청을 보내거나 요청을 처리해 돌려 받을 때 시간 지연이 없다. (제로 레이턴시)
    • 패킷 손실을 무시하면 트래픽 양이 늘어나 대역폭을 낭비하거나 패킷 손실 비율이 높아질 수 있다.
  • 네트워크 대역폭에는 제한이 없다.
    • 너무 많은 데이터를 보내거나 너무 많은 요청을 보내면 가용 네트워크 대역폭이 점점 줄어들어 언젠가는 병목이 생기고 스룻풋(throughput - 시간당 처리할수 있는 데이터 양) 도 줄어든다.
  • 전체 네트워크는 내부나 외부 공격으로부터 안전하다.
  • 네트워크상의 컴퓨팅 디바이스의 위치나 배열은 결코 바뀌지 않는다.
    • 네트워크 변경이나 디바이스 변경은 대역폭이나 지연시간에 영향을 줄 수 있다.
  • 모든 요소마다 관리자가 단 한명 씩 존재한다.
    • 여러관리자가 존재하며 서로 상충되는 보안 정책이 있을 수 있다. 
  • 통신 비용은 0이다.
    • 네트워크 구축, 운용비용은 0이 아니다.
  • 네트워크 전체가 균일하다.

출처 : 엔터프라이즈 자바 마이크로 서비스

2020.07.01 - [Enjoy Life/책을 읽자!!] - [나는 리뷰어다] 엔터프라이즈 자바 마이크로 서비스

728x90
반응형

+ Recent posts