반응형
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
반응형
반응형

log4j 취약점 사태에 따라서 프로젝트에 log4j 라이브러리를 변경해야 했다.

실제 프로젝트에서는 logback 을 사용중이었고 boot 버전은 2.2.4를 사용하고 있었고 spring-boot-starter-logging 을 사용중이었다.  이 라이브러리의 dependency 는 아래와 같다.

ch.qos.logback » logback-classic 1.2.3 
org.apache.logging.log4j » log4j-to-slf4j 2.12.1
org.slf4j » jul-to-slf4j 1.7.30
출처 : https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-logging/2.2.4.RELEASE

 

1. sping-boot-starter-logging 을 제외하고 log4j 라이브러리를 추가했다.

configurations {
    all {
        exclude group: 'org.springframework.boot', module: 'spring-boot-starter-logging'
    }
}

dependencies{
    compile group: 'org.apache.logging.log4j', name: 'log4j-api', version: '2.15.0'
    compile group: 'org.apache.logging.log4j', name: 'log4j-to-slf4j', version: '2.15.0'
    .....
}

그리고 나서 어플리케이션을 실행시켜보니 다음과 같은 로그가 남았다.

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::        (v2.2.4.RELEASE)

SLF4J: Failed to load class "org.slf4j.impl.StaticMDCBinder".
SLF4J: Defaulting to no-operation MDCAdapter implementation.
SLF4J: See http://www.slf4j.org/codes.html#no_static_mdc_binder for further details.

처음에는 어플리케이션이 실행이 안된건줄 알았는데 알고보니 로그가 안올라간것이었다. 그럼 왜 로그가 안나오는것일까??

일단 정확하지는 않지만 확인해본 바로는 프로젝트에서는 logback 을 사용중이었는데 sping-boot-starter-logging 라이브러리를 제외하는 바람에 logback 관련 라이브러리가 dependency 에 추가지되 않아서라는 추측을 하게 되었다. 

2. 로그백 라이브러리 추가

dependencies{
	implementation group: 'ch.qos.logback', name: 'logback-classic', version: '1.2.7'
    implementation group: 'ch.qos.logback', name: 'logback-core', version: '1.2.7'
    ....
}

위와같이 로그백 라이브러리를 추가했다. 어플리케이션은 정상적으로 기동이 됐다. 그런데 다른 로컬 PC 에서 다시 SLF4J 관련 메세지가 나서 다시 수정을 했다.

3. sping-boot-starter-logging 제외 취소하고 log4j 만 추가.

configurations {
    all {
        exclude group: 'org.springframework.boot', module: 'spring-boot-starter-logging'
    }
}

1번에서 추가했던 위 부분을 삭제하고 2번에 추가했던 로그백 라이브러리도 삭제를 했다. 결과적으로는 log4j 라이브러리만 추가된 상황이다. 실제로 dependency를 확인해보면 다음과 같이 변경이 되어있다.

Gradle: org.apache.logging.log4j:log4j-api:2.15.0
Gradle: org.apache.logging.log4j:log4j-to-slf4j:2.15.0

어플리케이션도 정상적으로 잘 기동이 되었다.

이것때문에 구글에서 SLF4J 관련해서 계속 검색 하면서 삽질했는데 간단하게 해결이 됐다. ㅠㅠ 

 

728x90
반응형
반응형

많은 시간 개발을 하면서 시스템 아키텍처에 대해서 생각을 안해왔던것은 아니었다. 하지만 그런 지식들은 공부를 해서 생기는게 아니라 실제 경험으로 해봐야만 알수 있다는 생각을 많이 했었다. 그런데 요즘드는 생각은 이론으로 알고 실제 경험을 하면 더 많은것을 할수 있고 더 잘 할수 있을거라는 생각이 많이 들었다. 그래서 최근 책을 고를때에 아키텍트 관련 서적을 많이 골랐던것 같다.

개발을 하다가 나이 먹으면 아키텍트를 해야 한다 라는 그런 의견(?) 들이 많긴 한데 개발자에서 아키텍트로 간다는 것은 생각처럼 당연하지도 않고 쉽지도 않다. 지금도 물론 개발도 하고 아키텍트 역할도 하고 있지만 솔직히 그게 아키텍트로서의 역할이 맞는지, 아니면 개발자인지 구분이 안간다. 

그리고 매번 같은 방법, 같은 형식으로만 생각하다 보니 우물 안에 개구리처럼 생각이 닫혀버린 느낌이 많이 들었다. 아마도 관련 지식과 경험의 부족이라고 생각이 든다. 그래서 "개발자에서 아키텍트로" 되기 위해서는 어떤 것들이 필요한지 책을 통해서 조금이나마 알아가보기로 했다. 

이 책은 총 3개의 챕터로 구성이 되어있다.

1부. 소프트웨어 아키텍처

소프트웨어 아키텍처가 어떤 일을 하는 사람인지 알아보는 챕터이다. 그리고 디자인 마인드셋 (이해하기, 평가하기, 탐색하기, 실현하기)은 무엇인 알려준다. 

2부. 아키텍처 설계의 기초

2부에서는 1부에서 말한 마인드셋 영역별로 아키텍처 설계를 어떻게 해야 하는지 기초 지식에 대해서 알아볼 수 있다. 요구사항 분석부터 설계, 패턴, 시각화, 문서화, 그리고 평가까지 기본적으로 알아야 할 내용들이 담겨있다. 그리고 요구사항 분석 이전에 이해관계자들과는 어떻게 대화를 해야 하는지도 알려준다. 

아래 그림은 아키텍처 패턴 부분에서 설명에 추가되어있는 그림과 표이다. 실체 패턴이 어떻게 구성되는지 알수있고 각 컴포넌트들이 어떤 역할을 하고 있는지 쉽게 알수 있다. 

 

3부. 아키텍처의 은빛 도구상자

3부는 지금까지 배운 내용에 대한 실습 과제를 해보는 부분이다. 총 38가지의 주제를 가지고 팀 활동을 해볼수 있다. 그리고 팀 활동도 위에서 말한 마인드셋 영역별로 4가지 주제를 가지고 나눠져 있다. "문제를 이해하고 싶을때", "해결책을 찾고 싶을때", "손에 잡히는 설계를 만들고 싶을때", "설계 대안을 평가하고 싶을때". 

활동의 목적이 무엇인지, 그리고 이 활동을 함으로써 얻을수 있는 장, 단점, 시간, 절차, 예시까지 아주 꼼꼼히 설명이 되어있다. 그리고 설계에 대한것 뿐만 아니라 앞에서 말한 4가지 주제에 해서도 활동이 있기 때문에 책에서 읽은 부분들을 충분히 경험해 볼수 있다. 

개발자가 아키텍트 역량을 키우기 위해 어떻게 해야 하는지 업주적인 내용부터 기술적인 내용까지 두루 살펴볼수 있는 책이다. 그리고 실습해볼수 있는 주제들을 통해 책의 이론을 경험해 불수 있다는 것이 무엇보다도 좋은 부분이었던 것 같다.

 "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

728x90
반응형
반응형

https://openinfradays.kr/session/10

 

OpenInfra Community Days Korea 2021

손석호 Speaker's bio 한국전자통신연구원(ETRI)에서 클라우드 컴퓨팅을 연구하며, Kubernetes와 Cloud-Barista 등의 오픈소스에 기여하고 있습니다. [Kubernetes] - SIG-Docs Korean Localization Team Leader - Kubernetes/websi

openinfradays.kr

위 영상을 보면서 간략하게 메모한 내용입니다.
 
Github contribute Workflow

Upstream Repository -> Origin Repository -> Local Repository -> Working copy

1. Fork : Upstream Repository 에서 Fork 받으면  Origin Repository 로 이동
2. Clone : Origin Repository 에서 Local Repository 로 이동
3. git remote add upstream (upstream repository 를 알수 있도록 설정)
4. git fetch upstream
5. git checkout 현재_최신_브랜치
6. feature 브랜치 생성해서 작업 진행후 commit
8. git fetch upstream (내가 작업하는 도중에 변경되는것을 확인하기 위해)
9. git rebase upstream/현재_최신_브랜치
7. local -> origin 으로 push (본인 저장소)
8. Pull Request 생성

 

 

728x90
반응형

'Development > Git' 카테고리의 다른 글

git cherry pick  (0) 2024.01.05
다른 브랜치에서 pull 하면 어떻게 될까???  (0) 2020.12.07
github page 에 테마 설치  (0) 2020.10.20
github 에 page 만들기  (0) 2020.10.15
Git local, remote branch 삭제  (0) 2020.09.08
반응형

투자에 대해서 모르지만 그래도 기본은 알아야 겠다 싶어서 읽기 시작한 책. 
주식을 투자하면서 알아야 할 많은 것들이 있었는데 설명은 쉬웠지만 내가 이책을 한번 읽고 다 이해하기에는 역부족이었다. 
그래서 그 많은 내용들 중에 딱 한가지만 뽑았다.

정말 읽으면서 이것만은 꼭 기억하자 라고 하면서 적어놨다.

주식 매도해야할때 베스트6

  1. 처음 생각한 적정 주가 수준이면 분할매도(1/3 정도)
  2. 고점에서 대량의 거래가 이루어지고 장대음봉발생하면 매도
    • 고점일 가능성이 큼
    • 주가를 끌어 올렸던 주체의 보유주식을 대량 처분할때 나타나는 차트 모습
  3. 세번째 전고점 돌파 실패하면 매도
    • 그 가격대에 매물이 쌓이며 저항이 심하다는걸 의미한다.
  4. 기대하던 뉴스가 나오면 매도
    • 내가 주식을 살때 기대했던 일이 실제로 일어났을때 매도
  5. 테마주는 대장주가 꺾이면 매도
  6. 전체 장에 대한 판단이 서면 매도
    • 대세 상승국면, 박스횡보, 대세하락 국면인지 판단하고 매도 결정
    • 대세 상승 : 섣불리 팔지말고 보유후 천천히 매도
    • 박스 : 목표 수익률을 낮추고 짧게 끊어서 매도
    • 대세 하락 : 반등을 이용해서 매도

그냥 1독으로 끝내버리기에는 좀 내가 알아야 할게 너무 많아서 조만간 용어나 이론적인 부분만 빠르게 다시 한번 읽어봐야겠다.

 

728x90
반응형
반응형

docker 실행시 컨테이너 내부에서 컨테이너 외부 파일을 연결할수 있는 방법이 있다.

docker run 실행시 -v [호스트경로]:[컨테이너경로] 를 추가해주면 호스트 경로와 컨테이너 경로가 연결되게 된다. 한가지 중요한 점은 호스트 경로의 상태가 컨테이너 경로에 덮어써진다는 것이다. 

➜  docker docker run --name nginx-mounts -d -p 8081:80 -v /Users/Workspaces/docker:/usr/share/nginx/html nginx
Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
7d63c13d9b9b: Pull complete 
15641ef07d80: Pull complete 
392f7fc44052: Pull complete 
8765c7b04ad8: Pull complete 
8ddffa52b5c7: Pull complete 
353f1054328a: Pull complete 
Digest: sha256:dfef797ddddfc01645503cef9036369f03ae920cac82d344d58b637ee861fda1
Status: Downloaded newer image for nginx:latest
f1aa047705f563a0db1f76abbadddf74ea2fff7542e55601a84eccf43dc207b4
➜  docker curl localhost:8081                          
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.21.4</center>
</body>
</html>

위에서는 docker를 실행할 때 /Users/Workspaces/docker 경로를 컨테이너 안에 /usr/share/nginx/html 에 바인드 시켰다. 기본적으로 nginx의 /usr/share/nginx/html 경로에는 index.html 파일이 존재하지만 현재 호스트의 /Users/Workspaces/docker 경로에는 아무것도 없는 빈 디렉토리이기 때문에 403 이 나온다.

 

728x90
반응형
반응형

시스템의 mac 주소를 확인할때 사용한다. 

root@myserver-001:~# arp
Address                  HWtype  HWaddress           Flags Mask            Iface
10.32.0.2                ether   e2:be:6b:98:75:27   C                     weave
10.32.0.3                ether   c2:2b:4a:0f:0b:5b   C                     weave
10.36.0.1                ether   02:84:38:18:ac:31   C                     weave
10.36.0.2                ether   8e:21:c9:42:d3:da   C                     weave
10.36.0.3                ether   a2:7f:5e:83:5b:c4   C                     weave
10.44.0.4                ether   2a:54:11:6b:1f:fe   C                     weave
10.44.0.5                ether   b6:bb:2c:98:2b:7b   C                     weave
_gateway                 ether   02:50:56:56:44:52   C                     ens160
192.168.0.2                      (incomplete)                              ens160
myserver-002             ether   00:50:56:99:e5:ba   C                     ens160
10.44.0.1                ether   46:bf:dd:bc:51:8a   C                     weave
192.168.30.18                    (incomplete)                              docker0
10.44.0.2                ether   e6:4a:dc:2d:f4:e7   C                     weave
myserver-003             ether   00:50:56:99:1e:4d   C                     ens160
10.44.0.3                ether   96:38:40:ba:ac:a0   C                     weave

다음과 같이 뒤에 host 명을 붙여주면 해당 host 의 정보만 출력한다.

root@myserver-001:~# arp myserver-002
Address                  HWtype  HWaddress           Flags Mask            Iface
myserver-002             ether   00:50:56:99:e5:ba   C                     ens160

 

728x90
반응형

'Development > Linux' 카테고리의 다른 글

xargs 명령어  (0) 2024.01.17
[리눅스 명령어] nohup  (0) 2021.06.09
[리눅스 명령어] 디스크 관련 명령어  (0) 2021.06.04
파일 찾기, 파일 날짜별 삭제  (0) 2021.05.21
[리눅스 명령어] IP 관련 명령어  (0) 2021.03.08
반응형

1. docker inspect container_id
명령어를 치면 굉장히 많은 정보를 확인할 수 있다. 그래서 grep 으로 조회하면 좀 수월하다.
docker inspect container_id | grep IP

"LinkLocalIPv6Address": "",
"LinkLocalIPv6PrefixLen": 0,
"SecondaryIPAddresses": null,
"SecondaryIPv6Addresses": null,
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"IPAddress": "192.168.0.1",
"IPPrefixLen": 16,
"IPv6Gateway": "",
        "IPAMConfig": null,
        "IPAddress": "192.168.0.1",
        "IPPrefixLen": 16,
        "IPv6Gateway": "",
        "GlobalIPv6Address": "",
        "GlobalIPv6PrefixLen": 0,

2. docker exec -it container_id /bin/bash
위 명령어를 사용하면 컨테이너 내부로 접속이 가능하다. 내부로 접속을 해서 ip addr 이나 ifconfig, hostname -I 등을 사용해서 확인 가능하다. 

3. docker exec container_id command
exec 만 사용을 하고 후에 명령어를 치면 컨테이너 내부에 명령어를 보내 실행이 가능하다. 

 

728x90
반응형

+ Recent posts