분류 전체보기 검색 결과

108개 발견
  1. 미리보기
    2019.06.07

    스프링 부트 2.0 2/e 마이크로서비스와 리액티브 프로그래밍

  2. 미리보기
    2019.05.07

    Mastering Spring 5.0

  3. 미리보기
    2019.01.12

    ABKO 카일 광축 LED 텐키리스 키보드 K511 개봉기

  4. 미리보기
    2018.11.18

    Vagrant 관련 이슈 글 모음

  5. 미리보기
    2018.11.16

    게이트맨 SR 통합 리모콘 연동하기

  6. 미리보기
    2018.11.13

    Eclipse에서 Darkest Dark Theme 적용 후 추가로 해줄것

  7. 미리보기
    2018.11.09

    Eclipse와 Github 연동(2) - github에서 프로젝트 받기

  8. 미리보기
    2018.11.09

    Eclipse와 Github 연동(1) - 프로젝트를 github에 올리기

다음의 내용은 에이콘출판사의 나온 스프링 부트 2.0 2/e 마이크로서비스와 리액티브 프로그래밍(원서 제목은 Learning Spring Boot 2.0 Second Edition) 책을 일고 실습해가면서 몇몇 수정한 부분들에 대한 기록이다. 이전글인 Mastering Spring 5.0때와 상황이 비슷하다.   

이 책에서 사용한 Spring Boot 버전은 2.0.0.M5 이고 2019년 6월 7일 현재 이 글을 쓰는 시점에서 내가 사용하고 있는 Spring Boot 버전은 2.1.5.RELEASE 이다  

이전 글과 마찬가지로 순서는 책의 순서와는 맞지는 않으며 차후 수정이 계속 이루어질 것이며 수정과정에서 순서가 맞춰질수도 있다. Mastering Spring 5.0 때는 9장 공부하는 시점부터 문제가 생겼지만 이 책은 6장에서부터 문제가 시작되었다(사실 발생된 Chapter는 중요하진 않다. 실습하면서 문제가 생기는 시점은 책에서 Spring Cloud와 관련된 내용을 다루기 시작하는 시점에서부터 생기는거여서..)

 

● Gradle 에서 Spring Cloud Greenwich Dependency 설정

 

이 책의 254 페이지부터 스프링 클라우드 스트림 관련 설정이 소스 코드에 반영이 되어야 한다. 예전 글인 Mastering Spring 5.0 에서는 Maven 기반의 프로젝트로 샘플 코드가 만들어져 있었으나 이 책의 경우는 Gradle 기반의 프로젝트로 샘플 코드가 만들어져 있다. 그래서 단순히 책의 255 페이지에 있는 compile 구문만 추가해도 라이브러리가 추가되지 않는다. Mastering Spring 5.0 때와 마찬가지로 Spring Cloud Greenwich 설정을 Gradle에서 해주어야 라이브러리 다운로드가 가능하다. 다음의 내용을 build.gradle에 추가해주자.

 

buildscript {
    dependencies {
        classpath "io.spring.gradle:dependency-management-plugin:1.0.2.RELEASE"
    }
}

apply plugin: 'io.spring.dependency-management'

dependencyManagement {
    imports {
        mavenBom 'org.springframework.cloud:spring-cloud-dependencies:Greenwich.RELEASE'
    }
}

apply plugin: 'io.spring.dependency-management' 부분은 실습을 위해 Spring Boot Gradle 프로젝트를 만드는 과정에서 기본적으로 추가되어있을수 있다(내경우에는 그러했다) 이미 설정되어 있으면 하지 않아도 된다. buildscript, dependencyManagement 항목이 build.gradle의 어느 위치에 있어야 하는지는 정해져 있는건 없다(자신이 넣고 싶은 위치에 넣으면 된다는 뜻) 위의 내용을 넣고 책의 255 페이지에 있는 compile 부분을 build.gradle 에 추가하면 된다(정상적으로 처리되지 않았을 경우 책에서 실습한 RabbitMQ 관련 코드 부분들이 에러가 발생하기 때문에 정상적으로 라이브러리가 추가되었는지 아닌지 확인이 가능하다) 

 

이 글을 쓴 뒤에 책을 계속 읽어나가니 이 부분에 대한 설명이 책의 256 페이지에 있었다. 그러나 책에서 사용하는 스프링 클라우드 릴리스 트레인인 Finchley의 경우는 Spring Boot 2.0.X에 맞춰져 있어서 Spring Boot 2.1.X에는 맞지가 않다. 책과 같은 방법으로 이를 구현하려 할 경우 buildscript의 springCloudVersion 항목을 'Greenwich.REALEASE' 로 주면 된다.

 

● 257 페이지에 있는 CommentController 클래스 소스 코드의 CounterService 클래스에 대해..

 

CommentController 클래스 소스 코드를 보면 CounterService  클래스 객체를 멤버변수로 사용하고 있는데 CounterService 클래스는 이 샘플 프로젝트에서 실제 존재하는 클래스가 아니다.(github의 프로젝트 소스를 봐도 이 클래스 소스는 존재하지 않는다. github에 올라와 있는 프로젝트 소스에서 CommentController 클래스 소스를 보면 책과는 다르게 나와있다.) CounterService 관련 부분은 실습할때는 코딩하지 않도록 한다.

 

● 299 페이지 서킷 모니터링의 Hystrix

 

책에서는 299 페이지의 서킷 모니터링에서 Hystrix에 대한 설명을 하고 있다. Hystrix 설정에 대해서는 문제점은 없는데 다만 http://localhost:8080  주소를 브라우저로 한번도 접근하지 않은 상태에서 Hystrix Dashboard를 통해 http://localhost:8080/actuator/hystrix.stream 을 통해 모니터링을 시작하면 화면이 loading 만 나오고 아무 반응이 없다. 그래서 http://localhost:8080 주소를 브라우저로 한번 접근해야 hystrix 에서 모니터링 화면이 나오게 된다.

그러나 이 책에서 보면 Hystrix의 인위적인 장애상황을 테스트 하기 위해 CommentSilmulator 클래스를 수정해서 Comment가 자동으로 등록이 되는 작업과 http://localhost:8080 으로 접근한 효과를 나타내기 위해 HomeController의 index 메소드를 호출하고 있다. 그렇기 때문에 CommentSimulator 클래스를 수정한뒤에 simulator profile로 Images MicroService를 실행하게 되면 당연 Hystrix Dashboard 화면에서 브라우저로 http://localhost:8080 을 접근하지 않았어도 모니터링이 되는 화면이 나와야 하는데(CommentSimulator 클래스에서 HomeController의 index 메소드를 호출하고 있기 때문에..) 그러지를 않고 있다. 그래서 중단점을 걸어서 확인을 해보니 CommentSimulator 클래스를 통해 실행이 될 경우 Images MicroService에 있는 CommentHelper 클래스의 getComments 메소드가 실행되지 않는 것으로 확인이 되었다. 이 메소드에 HystixCommand 어노테이션을 걸었기 때문에 이 메소드가 실행이 안되면 Hystix Dashboard에서 모니터링이 되지 않는 것이다. 그러나 브라우저로 http://localhost:8080 으로 접근할 경우 CommentHelper 클래스의 getComments 메소드가 실행되는 것으로는 확인이 되었다. 이 차이가 왜 발생하는지는 현재는 파악하지 못한 상태이다. 

트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

프로그래밍/컴퓨터 서적 After Service 카테고리의 포스트 목록을 보여줍니다

Mastering Spring 5.0

2019.05.07 17:45

다음의 내용은 에이콘출판사의 Mastering Spring 5 책을 읽고 실습해나가면서 몇몇 수정한 부분들에 대한 기록이다. 책이 출판될 당시의 Spring Boot 관련 버전과 내가 책을 구매한 시점에서 사용되는 Spring Boot 관련 버전이 다른 관계로 인해 실습 코드에서 변화되는 부분이 있어서 이에 대한 기록을 남겨두려 한다.

 

이 책에서 사용한 Spring Boot 버전은 2.0.0.M1 이고 2019년 5월 7일 현재 이 글을 쓰는 시점에서 내가 사용하고 있는 Spring Boot 버전은 2.1.4.RELEASE 이다(당근 Springframework 버전도 차이가 나게 되는데 책은 5.0.0.RC1을 사용하고 있으나 내가 사용하고 있는 Springframework의 버전은 5.1.6 이다)

 

순서는 책의 순서와는 맞지는 않으며 차후 수정이 계속 이루어질 것이며 수정과정에서 순서가 맞춰질수도 있다(현재 이 책의 9장을 공부하던 도중에 이 문서를 작성해두어야겠다 는 생각이 들어서..)

 

9장 전까지는 실습하는데 있어서 큰 문제가 없었는데 9장의 클라우드로 넘어가면서 책의 내용으로 실제 실습을 진행해보니 맞지 않는 부분이 발생하기 시작했다. Spring Cloud의 경우는 Spring Boot 2로 넘어가면서 라이브러리 관리의 변화가 발생한 부분이 있었다. 그러다보니 pom.xml 에서의 설정이나 사용방법이 바뀐 부분이 생기게 되었다.

 

● 스프링 클라우드 컨피그 서버와 클라이언트 dependency 설정

 

책의 399페이지에 스프링 클라우드 컨피그 서버의 maven dependency 설정과 404 페이지와 405 페이지에 걸쳐서 스프링 클라우드 컨피그 클라이언트의 maven dependency 설정이 있는데 스프링 클라우드 컨피그 서버의 경우 399 페이지에 있는 설정만으로는 관련 어노테이션이 있는 jar를 갖고 오지 못한다. 405 페이지에 있는 의존성 관리 내용을 추가해 줘야 jar를 갖고 올 수 있다. 그러나 405 페이지에 있는 Dalston 버전은 Spring Boot 1.5.X과 호환성이 이루어지기 때문에 Spring Boot 2.X 버전에는 맞지 않는 현상이 있다. 그래서 Spring Boot 2.X에서 사용할 때는 Greenwich 를 사용하면 된다. 다음과 같이 설정해주면 된다

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-dependencies</artifactId>
      <version>Greenwich.RELEASE</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

● management.security.enabled 에 대해서

 

책의 401 페이지에서 이 항목에 대해 설정하는 내용이 있는데 별도의 설명이 없어서 나름 알아보게 되었다. 이 항목은 Spring Actuator와 Spring Security 이 두가지와 연관이 되어 있는데 Spring Actuator와 Spring Security를 동시에 사용할 경우 Spring Actuator에서 제공하는 몇몇 URL(정확한 용어로는 Endpoint)은 로그인 아이디와 비밀번호를 입력해야만 해당 화면을 볼 수 있게 된다. 별다른 설정을 안하면 Spring Security가 만드는 default 계정(아이디가 USER 이고 패스워드는 Spring Boot App이 실행되는 시점에 만들어진다)으로 로그인 해야만 볼 수 있게 되는데 이러한 기능을 사용하지 않을 경우 management.security.enabled 속성을 false로 지정해주면 된다. 그러나 Spring Security를 사용하지 않으면 이 속성의 값이 true/false 여부와는 상관없이 이 기능이 동작하지 않는다(즉 Actiator에서 제공되는 모든 URL을 별도의 인증과정 없이 볼 수 있다)

그러나 문제는 Spring Boot 2.X에서는 이 설정이 없어졌다(실제 Spring Boot Document를 보면 목차중에 Customizing the management server port 항목에서 이 설정에 대한 설명이 있는데 1.X 버전에는 이 설정에 대한 설명이 있지만 2.X 버전에서는 Customizing the management server port 항목에서 이 설정에 대한 설명이 빠져 있다.)

이 부분은 Spring Security에서 /actuator/** 경로로 접근하는 것에는 특정 Role(ex : ACTUATOR)이 있는 사용자만 접근이 되도록 설정하고 application.properties 에서 management.endpoint.health.roles 항목에 방금 언급했던 특정 Role을 지정해주면 된다. 관련 자료는 여기여기를 클릭하면 알 수 있다(첫번째 링크에서 두번째 링크를 같이 걸어놓았다) 그러나 이러한 설정을 일절 해주지 않으면 로그인 관련 인증 기능은 동작하지 않는다.

그러나 로그인 여부와는 상관없이 해당 Endpoint에 대한 접근제어 설정도 가능하다. 무슨 뜻이냐면 내가 로그인을 하든 안하든 모든 사용자에게 모든 Endpoint에 대한 접근 허용/금지, 특정 Endpoint에 대한 접근 허용/금지 설정이 가능하다. Spring 2.X 버전에서는 JMX를 통한 Endpoint는 shutdown을 제외하고는 모두 접근이 허용되어 있으나 web을 통한 접근은 health와 info를 빼고는 접근이 금지되어 있다. 이러한 설정을 수정할려면 management.endpoints.web.exposure.include 항목과 management.endpoints.web.exposure.exclude 항목을 이용해서 설정하면 된다. 예를 들어 다음과 같이 설정하면

management.endpoints.web.exposure.include = httptrace,logfile

management.endpoints.web.exposure.exclude = health

httptrace와 logfile은 각각 /actuator/httptrace 와 /actuator/logfile로 접근이 가능하며 health는 접근할 수 없게 된다.

전체를 의미하는 것으로 *을 사용할 수 있는데 만약 다음과 같이 사용하면

management.endpoints.web.exposure.include = *

management.endpoints.web.exposure.exclude = httptrace,logfile

httptrace와 logfile을 제외한 모든 Endpoint가 각각 /actuator/해당 Endpoint 이름 으로 web에서 접근이 가능해진다

(주의할 점이 있는데 properties 파일이 아닌 yml 파일로 환경설정을 할 경우 *를 설정할때는 "*" 이렇게 쌍따옴표로 감싸줘서 설정해줘야 한다)

 

Endpoint를 접근할때 앞에 /actuator란 경로가 붙는데 이것은 management.endpoints.web.base-path 항목이 default로 /actuator로 설정되어 있어서 그렇다(바꿔말하면 이 값을 바꿔주면 바꾼 경로로 접근이 가능하다)

 

● curl -X POST http://localhost:8080/refresh

 

책의 407 페이지를 보면 스프링 클라우드 버스에 대한 설명을 하면서 properties 파일의 항목 값을 변경했을 경우 이를 반영하기 위해 다음의 URL을 접근하도록 설명되어 있다. 그러나 막상 접근을 시도하면 404 Not Found로 나오게 되는데 그 이유는 위에서 설명한 Endpoint 경로가 앞에 /actuator가 붙게끔 기본적으로 설정이 되어 있기 때문이다. 그리고 위에서 설명했듯이 management.endpoints.web.exposure.include 항목에 refresh를 넣어주어서 Endpoint의 접근을 허용해주어야 한다. 그러나 이것만으로는 실제 동작이 이루어지지 않는다.

변경된 사항이 적용될려면 @RefreshScope 어노테이션이 붙어줘야한다. 책의 경우를 들자면 message 항목을 변경했기 때문에 message 항목을 출력하는 MessageController에 다음과 같이 붙어줘야 한다

@RestController 
@RefreshScope 
public class MessageController { 
    ... 
}

이렇게 해준뒤에 curl 명령어를 통해 갱신해주면 정상동작되는것을 확인 할 수 있다.

 

management.endpoints.web.exposure.include 항목에 대한 설정은 bootstrap.properties 에 해도 되고, Spring Cloud Server가 git 저장소에서 불러오는 application.properties 파일에서 해도 된다.

 

● 스프링 클라우드 버스를 사용해 구성 변경 전파

 

책의 408 페이지를 보면 스프링 클라우드 버스를 사용해 구성 변경 전파를 설명하는 항목이 있다. 구성이 변경되었을 경우 위에서 설명한 /actuator/refresh Endpoint를 각각 스프링 클라우드 클라이언트에서 실행해서 구성이 변경된 것을 적용하는게 아니라 RabiitMQ를 이용해서 일괄적용 하는 방법을 설명하는 부분이다. 이 부분에 대한 설명을 읽어보면 409 페이지에 있는 spring-cloud-starter-bus-amqp dependency 만 추가하는 것으로 모든게 다 되는거 마냥 설명하고 있는데 그렇지가 않다. 

이 지점에서 생각해보자. 클라우드 서버와 클라우드 클라이언트가 RabbitMQ를 매개체로 삼아서 구성 변경을 전파하려 한다면 당연 클라우드 서버도 RabbitMQ와 연동을 해야 한다. 그런데 여기서는 그러한 내용이 빠져 있다. 그리고 Spring Boot에서의 RabbitMQ의 설정 부분이 빠져있다(클라우드 서버든 클라우드 클라이언트든 RabbitMQ 를 연동하기위한 구체적인 설정 부분(RabbitMQ 서버의 ip 주소, 사용자명, 패스워드 등을 설정하는부분)이 있어야 한다) 이에 대한 부가설명은 쓰기엔 너무 길어서 일단 2개의 링크를 걸어두니 참조해서 설정하길 바란다. 이 설정 방법으로 구성 변경 사항이 모든 클라우드 클라이언트에 전달된 것을 테스트로 확인했다

 

Spring Cloud Config Server 및 Bus RabbitMQ 동기화

Spring Cloud Config Client 및 Bus RabbitMQ 동기화

 

지금부터는 위의 블로그에는 없는 내용을 설명하겠다. 

 

책 410 페이지를 보면 구성변경을 전파하기 위해 스프링 클라우드 클라이언트 중 하나에다가 다음의 Endpoint를 요청하고 있다.

 

curl -X POST http://localhost:8080/bus/refresh

 

그러나 위에서 설명했다시피 Endpoint 경로 앞에 /actuator 가 붙어야 한다. 그리고 refresh가 아닌 bus-refresh를 실행해야 한다. 그러다보니 위에서 스프링 클라우드 클라이언트에 설정했던 management.endpoints.web.exposure.include 항목에 refresh를 설정했듯이 bus-refresh도 같이 설정해야 한다

management.endpoints.web.exposure.include = refresh,bus-refresh

 

그래서 최종 요청 명령은 다음과 같이 된다

 

curl -X POST http://localhost:8080/actuator/bus/bus-refresh

 

그리고 스프링 클라우드 서버의 application.properties 에 다음의 설정을 추가한다

spring.cloud.bus.enabled = true

근데 이 설정은 default가 true 여서 설정을 하지 않아도 동작할거라 본다(Spring Boot Reference 문서에 보면 저 설정값이 default가 true이다. 그러나 테스트를 해보질 않아서 확인해보진 않았다)

 

나는 이부분에 대한 실습을 할때 docker에 rabbitmq:management-alpine 이미지를 컨테이너로 올려서 실습을 진행했다. 이 이미지를 사용하면 rabbitmq 서버의 관리자 화면을 브라우저를 통해 볼 수 있게 되는데 관리자 화면을 통해 connection을 보게 되면 하나의 인스턴스당 2개의 connection이 생성되는 것이 확인이 됐다(책의 예를 들어 설명하자면 spring cloud server 인스턴스 1개, microservice-a 인스턴스가 2개가 실행되기 때문에 RabbitMQ에서 connection은 총 6개가 생기는 것을 확인했다) 근데 이게 맞는건지 모르겠다. 근데 또 다시 rabbitmq 서버를 다시 재부팅해서 확인해보면 connection이 1개만 생기는 것으로 확인이 되어서 rabbitmq를 모르는 상태에서 보다보니 이 부분은 더 알기가 어려웠다

 

● Feign 라이브러리의 dependency 설정

 

책의 412 페이지를 보면 페인(Feign)을 사용하기 위해 pom.xml에 artifactId를 spring-cloud-starter-feign을 사용하도록 되어 있으나 현재는 spring-cloud-starter-openfeign 으로 바뀌었다.

 

● Ribbon 사용의 변경

 

책의 416 페이지를 보면 pom.xml에 립본(Ribbon) 라이브러리의 의존성을 추가하는 부분이 있다. artifactId를 spring-cloud-starter-ribbon을 사용하고 있으나 이 부분은 spring-cloud-starter-netflix-ribbon 으로 바뀌었다. 

 

책의 416 페이지를 보면 application.properties에 다음의 설정을 하는 부분이 있다.

random-proxy.ribbon.listOfServers=http://localhost:8080,http://localhost:8081

이 설정에 대한 구체적인 설명이 없어서 이 설정을 그대로 이용했을때 애로사항이 있었다. 처음 겪었던 애로사항은 random-proxy가 무엇인가였다. spring-cloud-starter-netflix-ribbon 을 추가했는데도 저 random-proxy를 application.properties에서 예약어로 잡히질 않았다. ribbon 이하의 설정 항목은 예약어로 잡히고 있으나 저 random-proxy는 잡히질 않았다. 그래서 알아보니 저 부분은 예약어가 아니었다. 책의 416 페이지를 보면 다음의 내용이 있다.

@FeignClient(name="microservice-a")
@RibbonClient(name="microservice-a")
public interface RandomServiceProxy

여기 설정을 보면 @RibbonClient 어노테이션에 name을 microservice-a로 주는게 있는데 바로 이 microservice-a를 random-proxy 대신 작성해야 한다. 그래서 다음과 같이 작성해야 한다.

microservice-a.ribbon.listOfServers=http://localhost:8080,http://localhost:8081

또 하나의 애로사항은 listOfServers 에 설정하는 값이다. 나는 이 설정값을 봤을때 properties 파일에서 해당 property에 ,(콤마)로 연결하며 서버 ip와 port 번호를 설정하길래 이것이 배열인줄 알았다. 그래서 application.yml 파일로 이 값을 설정할때 다음과 같이 했었다. 

microservice-a:
  ribbon:
    listOfServers:
      - http://localhost:8080
      - http://localhost:8081

yml 문법에서는 배열을 표기할때 -(하이픈)을 앞에 주어서 배열을 선언하게끔 되어 있다. 그러나 이렇게 설정을 하니 Spring Boot 어플리케이션에서 여기에 설정한 값을 찾지를 못하였다. 그래서 이에 대한 검색을 해보니 이게 배열이 아니었다. 즉 ,로 연결된 단일 문자열로 이 프로퍼티 항목이 값을 받아들이고 있었던 것이다. 그래서 이 부분을 yml로 설정할때는 다음과 같이 해야 된다.

microservice-a:
  ribbon:
    listOfServers: http://localhost:8080, http://localhost:8081

 

● Eureka 설정 변경

 

책의 423 페이지를 보면 유레카(Eureka) 라이브러리를 pom.xml에 설정하는 부분이 있다. 책에서는 artifactId를 spring-cloud-starter-eureka 로 하고 있지만 이걸로 하는게 아니라 립본과 마찬가지로 spring-cloud-starter-netflix-eureka-client로 설정해야 한다(netflix가 언급이 되는 식의..)

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

마찬가지로 책의 421 페이지와 같이 유레카 서버를 만들면 라이브러리가 다음과 같이 추가된다

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

책의 425 페이지에서 설명하는 유레카와 서비스 소비자 마이크로서비스 연결 항목에서도 위에서 설정한것과 같이 spring-cloud-starter-netflix-eureka-client를 사용해야 한다

 

● Eureka 사용하면서 알아낸 내용

 

책에 나와있는대로 Eureka 서버를 구성하면 브라우저에서 http://localhost:8761로 Spring이 제공하는 유레카 메인 화면을 볼 수 있다. 이 화면에서 보면 Instances currently registered with Eureka 항목에 Application 항목으로 MICROSERVICE-A가 2개(책에 나와 있는대로 설정해서 실행하면 microservice-a가 8080 포트와 8081 포트에 바인딩 된 상태로 2개)가 올라와 있고 SERVICE-CONSUMER가 1개 올라와 있다. 그리고 MICROSERVICE-A에 보면 STATUS 항목에 UP(2)로 표시되면서 localhost:microservice-a:8080과 localhost:microservice-a:8081에 링크가 걸려있다. 이 링크를 각각 클릭해보면 localhost:8080/actuator/info와 localhost:8081/actuator/info 로 이동하게 되는데 이 URL로의 접근이 되질 않는다. 이유는 스프링 클라우드 버스 실습을 위해 위에서 언급했던 management.endpoints.web.exposure.include 항목을 refresh와 bus-refresh로 설정해서 그런거였다. 그러나 원래 이 설정을 안하면 기본적으로 이 항목은 info와 health는 기본값으로 들어가게 되어 있다. 그래서 info와 health를 수동으로 추가해줘야 한다.

그러나 이 항목의 변경은 RabbitMQ를 이용한 refresh 대상이 되질 않는다. 이유는 위에서 얘기했다시피 변경사항을 적용시킬려면 @RefreshScope 어노테이션을 붙여줘야 하는데 application.yml 파일을 수정하는 것은 @RefreshScope 어노테이션의 감시대상에는 들어가고 있지 않기 때문이다(이 부분도 개념적으로 좀 1차적으로 정리해보자면 프로그래머가 만든 비즈니스 로직일 경우 그 로직을 직접 구현하는 쪽에다가 @RefreshScope 어노테이션을 붙이면 변경사항 적용이 가능하겠지만 application.yml 과 같은 스프링 설정과 관련된 변경사항일 경우엔 @RefreshScope 어노테이션을 붙일 마땅한 장소가 없다. 그렇기 때문에 변경사항 적용에 대한 부분은 어디까지나 비즈니스 로직쪽에 한정을 두는 것이 어떨까 하는게 나의 1차적인 결론이다) 

 

● Spring Cloud Sleuth AlwaysSampler Bean 선언

 

책의 437 페이지를 보면 스프링 클라우드 슬루스 설정과 이에 대한 Bean 생성에 대한 코드가 있다. pom.xml에 의존성 설정하는 부분은 맞지만 페이지의 하단에 있는 @Bean 어노테이션을 통한 AlwaysSampler Bean을 생성하는 코드는 Spring Cloud 2.0 으로 넘어가면서 Spring에서 제공하는 AlwaysSampler를 사용하는 것이 아니라 Brave에서 제공하는 Tracing Library를 사용하는 것으로 바뀌었다.

(관련내용)그래서 이에 대한 코드 변화가 발생하였다. microservice-a, service-comsumer, zuul-api-gateway-server의 Spring Boot Application 클래스(main 메소드가 있는 클래스)에 다음과 같이 코딩해준다

@Bean
public Sampler sampler() {
  return Sampler.ALWAYS_SAMPLE;
}

이렇게 코딩해주면 책의 로그 관련 설명에 대한 부분을 볼 수 있다. 이 부분도 부가 설명을 하자면 로그 내용이 동일하지는 않다. 다만 이 책에서 설명하는 핵심 내용인 요청을 추적하는데 사용되는 값에 대한 확인은 가능하다.

 

● Zipkin 서버 구축 및 이에 대한 설정과 연동

 

책의 441 페이지를 보면 Spring Boot 기반하에서 Zipkin 서버를 독자적으로 구동하는 방법이 나오는데, 이 부분이 개인적으로 파악하고 정리하는데 시간이 오래걸렸다. 맨 먼저 발생한 지점은 441 페이지를 보면 Spring Boot 프로젝트를 start.spring.io에서 만들때 Zipkin UI, Zipkin Stream, Stream Rabbit 이렇게 Dependency를 선택하는 그림이 있는데 문제는 현재 이 dependency 들이 존재하지 않았다는 점이다. 그래서 그림에서와 같이 Spring Boot의 버전을 1.5.2로 낮춰서 해보면 나올수 있을까 싶어서 이렇게 해보았지만서도 나오지를 않았다. 그래서 프로젝트를 만들때 lombok, devtools, actuator 만 추가해 놓고 수동으로 추가로 넣을수 있게끔 일단 만든 상태에서 조시해보았다. 구글에서 검색한 내용도 책과는 별 차이는 없었다. 대신 책과는 달리 검색을 해보면 pom.xml에 dependency를 넣는 부분이 text로 되어 있기 때문에 어떤 groupId와 artifactId를 사용해야 하는지는 확인할 수 있었다. 내가 참조한 게시물은 Spring Cloud and Spring Boot, Part 2: Implementing Zipkin Server For Distributed Tracing 글을 참조해서 만들어갔다. 이 글은 Spring Boot 2.1은 아니었지만 그래도 2.0.X를 사용하고 있었기 때문에 현재 Spring Cloud를 GreenWich로 사용하고 있는 나로서는 적합한 내용일것 같았다. 그러나 이렇게 했는데도 문제는 존재한게 있었다. 위의 글에서와 같이 pom.xml에 zipkin 관련 설정을 해두고 442 페이지에 있는 @EnableZipkinServer 어노테이션을 붙이면 이 어노테이션이 deprecated 된 것으로 나온다. 그리고 @EnableZipkinServer 어노테이션이 2개가 존재하는 것을 알 수 있다.(이 글을 쓰는 시점에서는 Zipkin 서버를 Spring Boot 를 통해 구현하지는 않았기 때문에 관련 소스를 지워서 패키지를 알 수는 없지만 위의 링크된 글대로 zipkin 관련 라이브러리를 pom.xml을 설정한 뒤에 IDE에서 @EnableZipkinServer를 타이핑 해보면 deprecated 된 것과 그렇지 않은거 이렇게 2개가 나타난다) 첨엔 deprecated 되지 않은 어노테이션을 붙여봤는데 Spring Boot로는 9411 포트는 열려져 있지만 콘솔 로그를 면 이 Zipkin Server가 8080 포트로 열리고 있었다. 그래서 http://localhost:9411 로는 브라우저에서 접근이 안되었고 http://localhost:8080 으로는 브라우저에서 접근이 되어서 책의 442 페이지와 같은 화면을 볼 수 있었다. 이것을 어떻게든 고쳐볼려고 여러모로 검색해보고 시도해봤지만 실패하고 말았는데 결국 이러한 작업을 접게끔 만들어준것은 deprecated 된 @EnableZipkinServer 어노테이션의 소스에 있는 javadoc 설명이었다. 여기 설명을 보면 다음의 내용이 있다.

 

Custom servers are possible, but not supported by the community. Please use our
 https://github.com/apache/incubator-zipkin#quick-start default server build first.

 

Zipkin Custom Server는 지원하지만 커뮤니티에서는 지원하지 않는다는 뜻이었다. 즉 기술적으로는 Zipkin Custom Server를 구축하는 것에는 문제는 없지만 이에 대한 기술적인 지원은 커뮤니티에서 하지 않는다는 것이다. 아마 Zipkin Custom Server 구축에 대한 기술적인 통로를 열어주면서 이에 대한 여러가지 형태의 Zipkin Server 구현체가 나오다보니 이에 대한 기술지원이 한계에 이르러서 그런듯 하다. 그래서 Custom Server를 만들때 이에 대한 문제점이 발생할 경우 그것은 전적으로 개발자 책임이란 식의 얘기를 덧붙이고 있다. 그러면서 마지막으로 Custom Server는 가능하지만 지원해주지는 않는다(custom servers are possible, but not supported)란 말로 마무리 짓고 있다. 그리고 stackoverflow 에서도 이에 대한 언급을 찾은것도 있었다.(여기  글에 대한 MyTwoCents의 답글에 Brian Devins 의 댓글을 보면 위의 설명과 같은 맥락으로 해설할 수 있다. 커뮤니티에서 이 Custom Server 제작과 관련된 기술을 열어둔 뒤 얼마나 이것에 대한 기술질문 들에 대해 시달렸으면 @EnableZipkinServer 사용을 권장하지 말라. 커뮤니티에 부담이 된다 라고 언급했을까..) 그래서 @EnableZipkinServer 어노테이션을 통한 Zipkin Server 구현은 접고서 Zipkin을 만들어서 배포하는 zipkin.io가이드라인에 따라 Zipkin Server를 열었다. Docker Image로도 Zipkin Server를 제공해주기 때문에 나는 Docker로 Zipkin Server를 열었다. 다음은 내가 이 실습을 위해 열은 Zipkin Server를 구동시키는 docker-compose.yml 파일 소스이다.

 

version: '2.1'

services:
  zipkin:
    image: openzipkin/zipkin
    container_name: zipkin
#    volumes:
#      - /vagrant_hosts/docker/alpine_nginx_docroot:/docroot:rw
    environment:
      - RABBIT_ADDRESSES=10.10.20.6:5672
      - RABBIT_USER=admin
      - RABBIT_PASSWORD=admin
    restart: always
    ports:
      - "9411:9411"
    networks:
      dockernet:
        ipv4_address: 10.10.20.7
networks:
  dockernet:
    external: true

여기서 보면 openzipkin/zipkin 이란 이미지를 사용하고 있고 이 이미지로 열었을 경우 zipkin 이란 이름으로 container가 만들어지도록 했다. 그리고 환경변수로 RABBIT_ADDRESSES, RABBIT_USER, RABBIT_PASSWORD 이렇게 3개가 있는데 이 3개의 항목은 RABBITMQ 서버와 관련된 항목이다. 책의 443 페이지를 보면 spring-cloud-sleuth-zipkin 라이브러리와 함께 spring-cloud-starter-bus-amqp 를 같이 추가해주고 있다. spring-cloud-starter-bus-amqp 의 경우는 스프링 클라우드 버스와 관련된 실습을 할때 microservice-a 어플리케이션에 이미 의존성을 추가해둔 상태이지만 443 페이지에서는 service comsumer 와 zuul-api-gateway-server 에도 추가해주도록 되어 있다. 이것은 sleuth를 통해 만들어진 추적 로그를 RabbitMQ를 통해서 Zipkin Server에 전달하기 위해 그런것이다. 책에서 보면 442 페이지에 스트림 레빗이 이와 같은 역할을 하는 것이었지만 현재 스프링은 더이상 이에 대한 지원은 하지 않기 때문에 Zipkin Server 에서 RabbitMQ로 연결하는 설정을 해주어야 하는 것이다. 그래서 이 3개의 환경변수 설정이 추가로 필요하게 되었다.

그리고 책에는 언급이 안되어 있는데 우리가 만든 microservice-a, service-comsumer, zuul-api-gateway-server가 zipkin과 연동이 되어야 하는데 이 부분에 대한 언급이 없다. 즉 어떤 zipkin server와 연동해야 할 것인지, 보내는 방법은 무엇을 사용할 것인지 등에 대한 설정을 해야 하는데 그에 대해서는 application.yml에 다음의 설정을 해주도록 하자

 

spring:
  zipkin:
    base-url: http://localhost:9411/
    sender:
      type: rabbit
    enabled: true
  rabbitmq:
    host: localhost
    username: admin
    password: admin
  sleuth:
    sampler:
      probability: 1

spring.zipkin.base-url에는 zipkin 서버 url을 설정해준다. spring.zipkin.sender.type 에는 rabbit을 설정함으로서 rabbitmq 서버를 통해 sleuth 를 통해 만들어진 추적 정보를 보내주게 된다. 그리고 해당 RabbitMQ 서버는 spring.rabbitmq에 관련 정보를 언급해두도록 하며 마지막의 spring.sleuth.sample.probability는 추적 로그를 샘플링 하는 비율이다. 예를 들어 이 값을 1로 설정하면 요청된 모든 사항에 대한 전체 샘플링을 하겠다는 뜻이다. 그러나 이것을 0.1로 할 경우 전체 요청의 10%만을 샘플링하겠다는 뜻이다. 이 샘플링 된 것들만이 Zipkin을 통해 추적이 가능하기 때문에 전체 사항을 추적해볼려면 1로 설정하는 것이 좋을듯 하나 실제로는 매번 요청할때마다 샘플링해서 zipkin 서버로 보내주어야 하기 때문에 이에 대한 부하도 분명 있을수 있다. 이것은 운영하면서 결정지어야 할 듯 하다. 지금은 테스트 용도니까 1로 주는 것으로 했다. 이러한 설정들을 마친뒤 docker-compose를 통해 Zipkin Server를 구동하고 각각의 Spring Boot 어플리케이션을 실행해보면 책에서 보여주고 있는 Zipkin UI 를 통해 이를 확인할 수 있다.

 

※ RabbitMQ Server 설정과 관련하여 이상하게 생각할 사람이 있을것 같아 추가로 더 언급해두고자 한다. 일단 나는 RabbitMQ Server와 Zipkin Server를 Docker 기반에서 실행되도록 하였다. 이 Docker의 경우는 Windows 10에 VirtualBox와 Vagrant를 설치한 후 이를 통해 centos 7 vagrant 컨테이너가 실행이 되는 기반에서 여기에 Docker를 설치하여 운영했다. RabbitMQ 서버에는 ip를 10.10.20.6 

으로 주고, Zipkin Server에는 10.10.20.7로 주었다. 그래서 Zipkin에서 RabbitMQ Server를 연동할때는 RABBIT_ADDRESSES 환경변수에 해당 ip를 직접 설정해주었다. 그러나 Spring Boot Application의 경우 Windows 10에서 실행되다보니 각 Server의 ip를 통해 접근하지는 않았고 대신 해당 Server가 사용하는 기본 port를 port forwarding 설정을 해줌으로써 localhost로 설정

하더라도 port forwarding 을 통해 기본 포트가 해당 Server로 통신이 이루어지도록 했다. 그래서 application.yml에서는 RabbitMQ Server를 언급할때 10.10.20.6이 아닌 localhost로 지정할 수 있었다. 

 

● @EnableHystrix 에 대하여

 

책의 446 페이지를 보면 Hystrix를 통한 마이크로서비스의 내결함성 구현에 대해 설명하고 있는데 이걸 할려면 의존성 정보를 다음과 같이 주는 식으로 수정해주어야 한다

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

그리고 책에서 보면  hystrix 자동설정을 @EnableHystrix 어노테이션을 사용하도록 되어 있다. 그러나 Spring Cloud 문서를 보면 @EnableHystrix가 아닌 @EnableCircuitBreaker 어노테이션을 사용하도록 되어 있다.

그러면 @EnableHystrix와 @EnableCircuitBreaker의 차이점을 언급해야 할 듯하다. 마이크로서비스의 내결함성을 위해 이른바 Circuit Breaker 패턴을 사용하게 되는데 @EnableHystrix는 Hystrix를 통해 Circuit Breaker 패턴을 구현하는 것이고, @EnableCircuitBreaker는 Circuit Breaker 패턴 구현을 Hystrix로 구현한 것이다.(이게 말이야 방구야..?)

이 두 문장의 의미는 현 시점에서는 동일하게 비쳐지지만 엄밀하게 따지면 다른 점이 있다. @EnableHystrix는 Hystrix에 우선을 둔다. 즉 Hystrix를 통해 Curcuit Breaker 패턴을 구현하기 때문에 ClassPath에 Hystrix 라이브러리가 없으면 동작하지 않는다. 그러나 @EnableCircuitBreaker 는 Circuit Breaker 패턴에  우선을 둔다. 즉 Circuit Breaker 패턴을 구현할 수 있는 라이브러리만 있다면 동작이 가능한 것이다. 즉 Circuit Breaker를 구현하기 위해 Hystrix를 사용한다면 이 두 어노테이션은 동일한 동작을 한다. 그러나 Circuit Breaker를 구현하기 위해 Hystrix가 아닌 다른 라이브러리(예를 들어 finagle이나 javaslang-circuitbreaker 등)을 사용한다면 @EnableCircuitBreraker는 사용 가능하지만 @EnableHystrix는 사용할 수 없게 된다.(관련 내용은 여기에서 참조했다) 그리고 여기를 보면 Spring Cloud 에서 조차도 @EnableHystrix을 삭제(deprecated가 아닌)하려는 움직임이 있어 보인다.

약간 추가적인 설명을 더 하자면 이 책에서 실습으로 사용되는 라이브러리는 Netflix가 사용하는 마이크로서비스 라이브러리가 그 중심이다. 그렇기 때문에 @EnableHystrix 대신에 @EnableCircuitBreaker 로 더 범용적인 설정을 사용하게끔은 하겠지만 그 이후에 사용하는 어노테이션인 @HystrixCommand 는 그대로 갈 것이다(@EnableHystrix가 없어진다고 해서 @HystrixCommand 도 없어지지는 않는다는 의미임) 왜냐면 @HystrixCommand는 Circuit Breaker 패턴을 Hystrix로 구현하겠다고 결정되어진 이후에 동작하는 어노테이션이기 때문이다. 만약 위에서 잠깐 언급한 finagle 이나 javaslang-circuitbreaker를 Spring Cloud가 지원하게 된다면 @HysrixCommand도 @EnableCircuitBreaker와 같이 좀더 범용적인 어노테이션으로 바뀔것이라 생각한다.

 

● Hystrix 모니터링

 

책에서는 다루지 않는 내용인데 Spring Cloud Greenwich Reference 문서를 보면 Hystrix를 모니터링 할 수 있는 Hystrix DashBoard를 설명한 부분이 있어서 이를 한번 구현해 보았다. 관련 내용은 여기를 보고 만들어봤다. 다만 이걸 만든뒤 실습을 할려면 책을 보고 만들었던 프로젝트에서 수정해야 할 것이 생겨서 이에 대한 설명을 하고자 한다.

우리가 Hystrix를 테스트 할 때는 microservice-a 인스턴스를 띄우지 않은 상태에서 service-consumer 인스턴스를 띄운뒤에 http://localhost:8100/add 메소드를 실행시켜 service-consumer 인스턴스가 microservice-a 인스턴스의 random 메소드를 실행시킬수 없게끔 동작 실패를 유도하는 식으로 Hystrix를 테스트했다. 여기서 우리는 hystrix를 모니터링 해야 하는 대상을 잡아야 하는데 hystrix를 모니터링 해야 하는 대상은 service-consumer 인스턴스이다(hystrix 관련 설정을 service-consumer에다가 했으니까..) 그래서 hystrix 모니터링 인스턴스가 service-consumer 인스턴스를 모니터링을 해야 하기 때문에 이를 모니터링 하기 위해 service-consumer 프로젝트에 몇몇 수정을 가해야 할 부분이 있다.

  1. Hystrix 모니터링은 Actuator 기반으로 움직이기 때문에 service-consumer의 pom.xml 에 Spring Actuator를 추가 해야 한다(책에서 스프링 클라우드 버스를 설명할때 이 Actuator를 microservice-a 의 pom.xml에만 추가했기 때문에 Spring Actuator에 대한 dependency 태그를 service-consumer의 pom.xml에 추가해야 한다)
  2. Spring Actuator를 이용해서 하는 것이기 때문에 Hystrix 모니터링에서 service-consumer로 접근할 Endpoint를 지정해야 한다. Hystrix 모니터링에서 사용할 Endpoint는 hystrix.stream 이다. 그래서 service-consumer의 application.yml에 다음의 내용을 추가해준다.
    management:
      endpoints:
        web:
          exposure:
            include: info, health, refresh, bus-refresh, hystrix.stream

    info와 health는 default로 include 되는 항목이고 refresh와 bus-refresh는 위에서 스프링 클라우드 버스때  설명했단 Endpoint이다. 마지막으로 hystrix.stream 이 바로 Hystrix 모니터링을 하기 위해 추가된 Endpoint이다

이렇게 한 뒤에 microservice-a 인스턴스는 일절 띄우지 말고 service-comsumer 인스턴스와 hystrix 모니터링 인스턴스를 띄운 상태에서 hystrix 모니터링 화면을 띄우고 http://localhost:8100/add 메소드를 반복적으로 호출해보자. 그러면 모니터링 화면에서 실패한 횟수가 점점 올라가는데 단지 몇번 실패한 걸로는 circuit이 close 된 상태를 유지하지만 한 20여번 실패하게 되면 circuit이 open 된 상태로 바뀌면서 아예 호출 자체를 막아버린다. 그런 뒤에 다시 microservice-a 인스턴스를 띄운 후 http://localhost:8100/add 메소드를 호출해서 정상 동작을 하게끔 해주면 다시 circuit이 close 되는 것을 확인할 수 있다.

 

 

 

트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

프로그래밍/컴퓨터 서적 After Service 카테고리의 포스트 목록을 보여줍니다

내 블로그에도 글을 올렸던 적이 있었는데 기존 사용하던 키보드는 스카이디지탈 NKey A1 레인보우 청축 키보드였다. 이 키보드가 구매해서 쓰고 있을 당시에는 괜찮았는데 1년이 넘어가니 자판 N이 스위치가 건들건들 거리기 시작했다. 그정도는 그렇게 써도 큰 불편은 없었던지라 그냥 넘어갈수는 있었는데 문제는 시간이 가면 갈수록 먹통이 되는 자판이 한개한개 늘어가기 시작했다. 즉 여러번 자판을 쳐야 인식이 되는 현상이 발생하는 것이었고 이런 자판이 점점 늘어가면서 더는 참고 쓰기엔 인내심에 한계가 도달했다(스타2를 하는 상황에서 단축키를 이용해 부대지정을 했다고 생각했는데 막상 부대 단축 번호를 입력하면 부대가 선택이 안되는 상황이 여러번 발생했다..이때의 답답함이란..) 그래서 키보드를 구매할 생각에 알아보던 중에 어느 유튜버 분이 가성비 3위에 꼽는 키보드로 오늘 소개할 K511 키보드를 소개해주게 되었다. 개인적으로 텐키리스를 한번도 써본적이 없었는데 지인분이 텐키리스를 써야 하는 이유를 설명해줘서 텐키리스를 이번에 써보기로 했다. 이 키보드는 인터넷에서 검색해보니 대륙의 실수..란 단어에 빗대어 ABKO의 실수..란 수식어가 붙어 다니고 있었다. ABKO 에서 제작된 많은 키보드들이 일반적으로 평이 그렇게 좋지는 않았는데 이 키보드 만큼은 평들이 좋은 축에 속했다. 그리고 광축을 한번도 써본적이 없어서 오테뮤 청축을 써온 나에게는 한번 새롭게 써보고 싶은 그런 키보드이기도 했다. 


이 제품은 클릭과 리니어 2개의 축 방식중 하나를 선택할 수 있고 키보드 모양에 따라 V1, V2로 갈리기 때문에 총 4가지의 제품군이 존재하게 된다. 클릭과 리니어, V1과 V2의 차이는 나 아닌 다른 블로거들이 키보드 리뷰하며 설명한 내용들이 많이 있어서 굳이 이 글에서는 설명하지는 않도록 하겠다. V2 리니어 제품이 워낙 인기가 좋아서인지 품절이어서 나는 V1 리니어 제품을 샀다. 개인적으로는 청축 스타일을 좋아해서 V1 클릭을 살려고 했지만 내가 방문을 닫고 자판을 치는데도 불구하고 울 어무이가 거실에서 시끄럽다고 말씀하셔서 결국 클릭은 사지 못했다.


하드웨어 리뷰 관련 글을 쓸땐 언제나 그러하듯 내 돈 주고 산것을 증명하는 것을 올린다. 이 제품은 쿠팡에서 구매했는데 현재 글을 쓰면서 쿠팡에서 보니 이 제품도 품절되었다.



쿠팡에서 1월 5일날 주문해서 로켓배송으로 1월 6일날 오후 2시 무렵에 받아볼 수 있었다. 제품은 운송장이 붙은 회색 비닐봉투에 담겨져서 왔다. 좀더 욕심을 내자면 박스를 뽁뽁이로 한번 감싸고 보내줬음 어땠을까 하는 생각도 들지만 나중에 박스를 열어서보니 그리 하지 않아도 되겠다는 생각이 드는 박스 내부 구조이긴 했다. 아래 사진은 비닐봉투에서 꺼냈을때의 제품 박스 사진이다.



박스를 보면 영문으로 카일 광축 게이밍 텐키리스로 밝혀주고 있다. Color Mix Keycap은 이 제품의 키보드 키캡 색상이 단색으로 통일된게 아니라 흰색, 회색, 붉은색의 조합으로 이루어져 있기 때문에 그렇다. 내가 산 키보드가 어떤것인지를 알 수 있는 방법은 박스의 옆면을 보면 알 수 있다. 아래 사진은 박스의 옆면을 찍은 것이다.



사진을 보면 오른쪽에 K511 V1과 K511 V2가 써있고 K511 V1에 체크되어 있다. 즉 V1 제품을 산 것임을 알 수 있다. 반대쪽 옆면은 다음과 같이 씌여져 있다.



아런 부류의 제품은 언제나 늘 그렇듯 제품 개봉시 반품 불가 란 어마무시한 씰이 붙어 있기 마련이다. 어차피 쓸 제품이기 때문에 망설이지 말고 과감하세 씰을 잘랐다. 박스를 열면 아래의 그림과 같이 나를 반겨주게 된다.



제품 자체를 반투명 스펀지 재질 종이로 감싸고 있다. 이제 이를 벗겨내면 아래와 같이 나온다.



키보드 덮개가 덮여있는 키보드가 모습을 드러낸다. 개인적으로는 키스킨을 좋아하지만 일반적인 키보드 자판보다는 높이가 높다는 생각이 들어서 키스킨 제작은 어렵겠다는 생각이 문득 들었다. 개인적으로 회사에서 쓰는 것은 노트북 같은 스타일의 펜타그래프 자판이기 때문에 자판의 높이가 낮다. 이런건 키스킨을 만들기 용이하지만 요런 형태의 키보드는 오히려 키보드 덮개가 더 낫지 싶다. 이 키보드를 들어낸뒤 바닥을 깔고 있는 종이를 들어내면 다음과 같은 것들이 들어있는 것을 볼 수 있다.



메뉴얼, 키캡 리무버, 키보드 청소용 솔, 그리고 스위치 리무버가 있다. 사진에는 안보이지만 PC방에서 사용할 경우 붙일만한 스티커도 한 장 포함되어 있다. 포장 상태는 비교적 양호한 편이다. 배송시 막 굴리는 그런 상황만 아니면 파손이 될 것 같지는 않아보이는 구조라고 생각한다(그렇다고 튼튼한 구조라는 뜻은 아니다. 일반적인 작은 충격에는 별 문제 없을 구조라는 뜻이다) 이제 이 키보드를 꺼내서 바닥에 놓아보자.



V1 제품을 구매했기 때문에 일반적인 자판은 회색, 기능성 키(ex : 백스페이스, 시프트, 엔터, 컨트롤 등)은 흰색으로 구성되어 있는 레이아웃이다. USB 단자는 금색도금이 되어 있는 상태다. 아래 사진은 컴퓨터 책생의 키보드 놓는 서랍에 셋팅한 후 컴퓨터 전원을 올린 뒤의 사진이다.



예전에 쓰던 키보드는 제품명에 레인보우 라고 써 있듯이 LED가 형형색색으로 다양하게 들어왔지만 이 제품은 흰색 하나만 들어오고 있다. 이것도 나름 괜찮은 것이 여러색으로 들어오는 것은 이쁘기는 하지만 LED 효과가 들어갈 경우 여러색이 번쩍거리다보니 산만한 느낌이 있는데 이 키보드는 단색이어서 그런 산만함은 별로 느끼질 못했다. 그리고 텐키리스다보니 공간도 작게 차지하고 앙증맞은 느낌도 있다. 다만 LED가 켜진 상태를 보면 마감이 살짝 아쉬운 느낌이 드는 부분이 있다. 예를 들어 한글의 경우 R 키에 있는 ㄲ 과 ㄱ 같이 한글이 한 키에 위와 아래로 쓰여져 있는 경우 아래에 있는 한글은 LED가 제대로 보이지 않고 잘려서 보이는 증상이 있다. LED가 비치는 범위가 한계가 있어서 범위를 넘어가면 안보이는 증상이 있다는 뜻이다. 위의 사진에서 R 키를 보면 ㄱ의 아래부분이 불이 안들어오는 것을 볼 수 있다. 그러나 머 이건 이만한 가격에서의 키보드에서는 개인적으로는 타협은 볼 수 있는 부분이기 때문에 마감이 아쉽다 머 이정도지 치명적인 약점이다..라고 말할 수준은 아니라고 생각한다.


나 말고도 다른 블로거들이 이 제품을 리뷰하면서 타건이나 소리에 대해서 언급들을 많이 한데다가 타건과 소리는 개인적인 취향이 강한 관계로 이 글에서는 언급하지는 않겠다. 다만 다른 글에서는 없을만한 개인적으로 겪은 내용에 대해 글을 쓰고자 한다. 나는 이 제품을 기존의 키보드를 제거한뒤 그 키보드가 끼어져 있던 USB 포트에 끼어 사용했었다. 이 제품을 구매하고 사용하면서 컴퓨터 부팅이 안되는 현상을 이 글을 쓰는 시점까지 3번을 겪었다. 내 컴퓨터의 경우 부팅이 시작되면 삑 소리가 한번 울리는데 처음 이 제품을 구매했을때 삑 소리가 나지 않으면서 모니터가 VGA 카드 출력 신호를 받지 못하는 상황이 발생했었다. 이때는 메모리를 한번 뺐다가 다시 끼니까 정상동작을 했다. 그리고 며칠 뒤에는 삑 소리가 나면서 부팅은 되지만 화면이 아무것도 들어오지 않는 증상이 발생했다. 이때는 VGA 카드의 DP 포트에 끼어져 있는 DP 모니터 케이블을 뺐다가 다시 끼었다. 그러고서 이 증상이 며칠 있다가 또 발생했는데 이때 모니터 케이블을 뺐다가 다시 끼어도 정상 동작이 이루어지지 않았다. 이 사이에 하드웨어가 바뀐것은 이 키보드 뿐이어서 USB 포트를 사용하는 제품간의 충돌현상인가 싶어 USB 제품들의 포트를 현재 끼어져 있는 구조에서 새로이 재배치했다. 그랬더니 다시 정상동작 하였다. 혹시나 키보드를 컴퓨터에 연결하고 부팅이 안되거나 화면이 안보이는 경우 나와 같은 방법을 써서 해결할 수 있기를 바란다





트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

사는 얘기/나의 흔적 카테고리의 포스트 목록을 보여줍니다

Docker 관련으로 된 글을 보던중 Vagrant를 알게 되어 Vagrant를 설치하게 되었다. Vagrant에 대한 설치는 도커 Docker 기초 확실히 다지기 이 글을 보고 Vagrant를 설치했다. 그러나 Vagrant를 설치 및 운영하다 보면 이슈사항이 나올것 같아서 개인 기록 및 공유 차원에서 이 글에 기록해두고자 한다. 그래서 이 글은 그런 이슈 사항이 나올때마다 갱신될 예정이다(근데 Vagrant 이건 발음이 어떻게 되나..베이그랜트? 바그랜트?)


1. Windows 10에서 위에 링크되어 있는 글을 보고 설치한뒤 centos/7 으로 VM을 하나 만들어서 vagrant ssh를 실행하니 vagrant@127.0.0.1: Permission denied (publickey,gssapi-keyex,gssapi-with-mic). 에러가 발생하면서 ssh에 대한 접속이 이루어지지 않았다. 이것에 대해 검색해보니 환경변수로 VAGRANT_PREFER_SYSTEM_BIN을 만든 뒤 이 변수에 값을 0을 주면 해결이 된다고 해서 이 방법을 써서 해결이 되었다. VAGRANT_PREFER_SYSTEM_BIN 환경변수가 궁금한 사람은 여기를 클릭해서 보면 된다.


2. 1번의 문제를 해결한뒤 ssh를 접속해보니 vagrant 란 계정을 디폴트로 만든뒤에 이 계정으로 접속이 되었다. 그러나 root 계정이 아니기 때문에 yum 명령을 이용해서 프로그램을 설치할려면 sudo 명령을 같이 써야 한다(ex: sudo yum ...) 이것이 불편해서 root 계정의 패스워드가 무엇인지 찾아봤는데 기본적으로 root 계정의 패스워드는 vagrant로 설정하고 있다. 그러나 현재는 Vagrantfile에서 root 계정의 패스워드를 설정하는 방법을 찾지는 못한 상황이다. VM을 만드는 시점에 root 계정의 패스워드를 지정하면 편할텐데 아직은 모르겠다.


3. Windows 10에서 Vagrant를 설치하니 Vagrant에서 box로 통하는 이미지들(docker로 하다보니 용어가 이미지로 되어버렸다)은 받아지는 위치의 기준이 C:\Users\사용자 계정\.vagrant.d 이 디렉토리 밑에 boxes라는 디렉토리에 받아지고 있었다. .vagrant.d 디렉토리가 Vagrant의 Home 디렉토리 역할을 하고 있다. 이 Home 설정 개념이 Java나 Maven과는 약간 다른데 Java나 Maven의 경우 JAVA_HOME과 MAVEN_HOME은 Java나 Maven이 설치된 디렉토리를 가르켜야 하지만 Vagrant의 경우는 그렇지가 않다(실제로 나는 Vagrant를 D:\Vagrant에 설치했다) 이 이미지를 받는 디렉토리가 C 드라이브에 있을 경우 C 드라이브 용량이 작아지는 상황이 벌어질수 있어서 위치를 바꾸었다. 위치르 바꿀때는 환경변수로 VAGRANT_HOME에 지정하면 된다(나는 VAGRANT_HOME을 D:\Vagrant_VMS\.vagrant.d 로 지정했다) 이때 주의점이 있다. VAGRANT_HOME에 매핑되는 디렉토리를 Vagrant가 설치된 디렉토리(나의 경우로 예를 들면 D:\Vagrant 가 된다)의 하위 디렉토리로 설정하면 안된다. Vagrant를 설치하면 Vagrant가 설치된 디렉토리는 일반 계정으로는 접근이 안되기 때문에 읽거나 쓰지 못하는 상황이 벌어져서 이미지를 다운로드 받지 못하게 된다. 그래서 위에서 언급한 설정으로 Vagrant 설치 디렉토리가 아닌 D:\Vagrant_VMS\.vagrant.d로 지정했다.


트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

프로그래밍/기타 카테고리의 포스트 목록을 보여줍니다

집에서 사용하는 도어락 제품인 게이트맨 SR(사용한지 무려 10년은 더 된 제품이다..)에 같이 달려나온 리모콘이 고장나는 바람에 게이트맨을 제조화는 회사인 아이레보에서 나온 통합 리모콘을 구매하였다. 그러나 리모콘을 도어락과 연동하는 과정이 쉽지가 않아서 기록 차원에서 남겨둔다. 구형 도어락과 이 리모콘을 연동할때 애로사항을 겪는 분들이 많을것 같아서 이런 분들이 이 글을 검색했을때 차후에 도움이 되길 바란다.


내가 구매한 리모콘은 아래의 것이다.



사진을 찍을때 책상위에 올려놓고 찍느라 빛이 가려져서 잘 안보일수도 있는데 동그란 버튼 2개중 큰 버튼은 문을 열어주는 열림 버튼이고 작은 버튼은 문을 잠가주는 닫힘 버튼이며 위의 그림에서는 안보이지만 SET이라는 글씨 왼쪽에 조그만 홈 형태로 된 버튼이 있는데 이 버튼이 등록 버튼이다. 이 리모콘은 설명서에도 설명되어 있지만 게이트맨 제품군을 A,B,C 이렇게 3가지의 타입으로 나누어서 지원한다고 되어 있는데 우리집 도어락인 게이트맨 SR의 경우는 A 타입에 속한다. 이 리모콘을 구매할 의사가 있는 사람은 인터넷에서 검색을 해보면 통신팩 이라는 일종의 모듈을 같이 사야 하는걸로 설명되어 있는데 내가 사용중인 게이트맨 SR의 경우는 원래 리모콘 기능이 포함되어 있는 기능이기 때문에 제품안에 통신 기능이 내장되어 있다. 그래서 이 통신팩을 살 필요가 없다(어디까지나 게이트맨 SR에만 해당되는 경우이며 다른 제품을 사용중이라면 카카오 플러스 친구로 게이트맨 고객센터를 등록한뒤 상담하면 구매해야 하는지의 여부를 알 수 있다)


리모콘에 대한 대략적인 설명은 마치고 이제 힘들었던 부분에 대해 설명하겠다. 카카오톡 플러스 친구로 게이트맨 고객센터를 등록한 뒤 상담을 해보니까 리모콘을 산 뒤에 해줘야 할 작업이 있었다. 바로 주파수 변경 이란 작업이다. 리모콘 설명서에서 보면 아래의 내용에 해당하는 것이다.



리모콘의 주파수는 위의 그림에서 B & C Type 제품군과 연결되는 상태인 푸른 램프가 켜지는 상태로 출시가 되어 나온다. 그래서 A Type 제품군을 사용할 경우엔 위의 과정을 거쳐서 적색 램프가 점등이 되게끔 설정을 해주어야 한다. 근데 문제는 설명서대로 해도 이게 되지를 않았다. 이것땜에 고객센터에 직접 전화를 걸어 메뉴얼대로 했는데도 안되었다고 얘길하니 고객센터에서는 내가 사는 지역의 대리점과 연결해주었지만 대리점에서는 이 제품이 자신이 대리점을 차리기도 전에 나온 제품이라 모르겠다며 오히려 본사 제품관리부에 연락을 하라고 했다. 그래서 다시 고객센터에 전화를 걸어 설명을 하니 기사를 보내겠다고 하길래 우리 지역 담당 기사도 다룰수가 없는 제품을 누가 다루겠냐고 하자 다른 지역 기사에게 상황을 설명한뒤 보내겠다고 한다. 그러나 이럴 경우 출장비가 나올수도 있다고 했다. 리모콘이 불량이어서 도어락과 연결이 안되면 출장비를 받지 않지만 그렇지가 않은 경우엔 출장비가 나온다고 한다. 그래서 출장수리는 일단 보류하고 가족 구성원들 의견을 물은뒤에 출장수리 받는 것으로 결정나서 다시 고객센터에 전화를 거니 이번 상담원은 이제껏 나랑 얘기했던 상담원 2명과는 연결하는 방법에 대해 다른 얘기를 해서 그 방법대로 해서 성공을 했다. 썰이 약간 길었는데 이제 그 방법에 대해 설명하겠다.


나는 주파수 변경 작업을 할때 왼손에 리모콘을 들고 오른손에 SET 버튼을 누르기 위한 이쑤시개를 들고서 했다. 그런뒤 리모콘을 들고 있는 왼손 엄지손가락으로 닫힘 버튼을 누르고 이때 동시에 오른손으로 들은 이쑤시개로 SET 버튼을 눌러서 주파수 변경 작업을 했다. 이때 나타나는 반응은 파란색 램프만 계속 깜박깜박하다가 꺼지는 그런 상황이었다. 몇번을 해도 빨간색 램프가 나오지를 않았다. 근데 이번 상담원의 경우 이런 방법으로 설명했다.


  1. 리모콘을 손으로 들지 말고 책상이나 방바닥 같은 평평한 곳에 둔다.
  2. 1번과 같은 상태에서 손으로 잡고 있는 이쑤시개로 리모콘의 SET 버튼 구멍에 넣기만 하고 아직 버튼을 누르지는 않은 상태로 있는다(이쑤시개로 SET 버튼을 언제는 누를수 있게끔 이쑤시개를 구멍에 넣은 상태로 이쑤시개 놓지 말고 손에 붙잡은 상태로 대기)
  3. 2번 상태에서 닫힘 버튼을 누르면서 손으로 붙잡고 있던 이쑤시개를 눌러 SET 버튼을 동시에 누른다.
  4. 파란색 램프가 깜빡이고 있는동안에는 누르고 있는 SET 버튼와 닫힘버튼을 떼지 말고 계속 누르고 있다가 깜빡이는게 꺼지면 그때 SET 버튼과 닫힘버튼에서 손을 뗀다
  5. 다시 2번과 3번 과정을 순서대로 진행한다.


이렇게 하니까 5번을 진행할때 빨간색 램프가 한번 깜빡이다가 꺼지는게 보였다. 이렇게 해서 주파수 변경을 할 수 있었다. 이 과정을 진행할때는 도어락과 가까이 있는데서 진행하는게 좋을듯하다. 실제로 이 작업을 진행했던 내 방의 경우 도어락이 있는 출입문의 옆에 있는 방이어서 가까운 위치에 있었다. 주파수를 변경한 뒤에는 리모콘 등록하는 것은 리모콘 설명서에 있는 A 타입에 있는 설명대로 진행해서 리모콘을 등록했다(이 부분도 게이트맨 SR의 경우 차이가 있는데 리모콘 메뉴얼의 경우엔 키등록버튼이라고 되어 있지만 게이트맨 SR의 경우 카드등록 버튼이 그 버튼이었다. 도어락 실내부를 열어보면 건전지를 넣는 곳 아래에 버튼이 2개 있는데 왼쪽 버튼이 리모콘 등록 버튼이라고 생각하면 될 듯 하다)


왜 이리 힘들었나 지금 생각해보면 좀 엉뚱한 결론일수는 있겠지만 손으로 리모콘을 잡고 한것이 리모콘의 주파수 변경에 무언가 영향을 준것이 아닌가 싶다. 적어도 리모콘 설명서에 손으로 리모콘을 잡지 말고 평평한 바닥에 놓고 하라고 했으면 덜 헤맸을텐데 이것땜에 몇시간을 소비하며 하마터면 엉뚱한 출장비까정 물뻔 했다. 나와 같은 사람에게 도움이 되기를 바란다.

트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

사는 얘기/나의 흔적 카테고리의 포스트 목록을 보여줍니다

Eclipse에서 Darkest Dark Theme 적용 후 Git과 연동하면서 색상이 보기 흉하게 바뀌는 상황이 있었다. 이유는 Git으로 파일 관리를 하면서 파일의 상태가 바뀌었을때 이에 대해 표현하는 방법때문이었다. 예를 들면 파일을 수정할 경우 Commit이 아직은 안되어 있는 상태이기 때문에 Uncommited 인데 이때 이 자원을 나타내는 background 색상이 흰색으로 설정되어 있어서 전체적으로 검은색 테마에서 배경색을 흰색으로 주다보니 어울리지 않아 보기 싫은 상황이 생겼다. 암튼 Darkest Dark Theme를 사용하면서 배경색이 흰 색으로 되어 있는 부분은 튀어 보이는 상황이 벌어지는 것이 있는데 일단 예를 들은 경우를 수정할려면..(차후에 이런 상황들이 또 일어나면 여기에 정리할 예정이다)


1. Window -> Preference -> General -> Appearance -> Color And Fonts 에 간 뒤 Git 항목의 하위 항목으로 Uncommited Change(Background)를 찾아보면 현재 색상이 흰 색으로 되어 있는데 이것을 검정으로 바꿔준다.


2. Git의 ignored 파일에 속한 파일들도 그 배경색이 흰 색이기 때문에 Window -> Preference -> General -> Appearance -> Color And Fonts 에 간 뒤 Git 항목의 하위 항목으로 Ignored Resource (Background) 를 찾아서 이 색상을 검정으로 바꿔주면 된다.

트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

프로그래밍/Java 카테고리의 포스트 목록을 보여줍니다

지난 글에서는 Eclipse와 git을 사용해서 github에 자신이 만든 프로젝트를 올리는 방법에 대해 설명했다. 이번엔 그 반대의 상황으로 github에 올라와 있는 프로젝트를 자신의 eclipse workspace로 받는 방법에 대해 설명하고자 한다. 환경은 지난글과 동일한 환경이어서 환경에 대한 얘기는 생략하기로 하겠다. 대신 지난번 글을 보고 그대로 따라한 상황에서 이번 글을 보고 그대로 따라하고 싶으시다면 지난번 글에 올라간 자신의 프로젝트를 eclipse workspace에서 삭제해주길 바란다. 이번 글로 설명할때 프로젝트가 자신의 workspace에는 없다는 가정에서 할 것이기 때문에 eclipse workspace에 등록되어 있는 github 에 등록된 자신의 프로젝트를 삭제하고 진행하길 바란다(이때 프로젝트에서 마우스 우클릭하여 나오는 context menu에서 Team -> disconnect 를 선택하여 git과의 연동을 끊은 뒤에 프로젝트가 있는 worksppace 디렉토리에서 해당 프로젝트 디렉토리가 삭제가 된 상태로 삭제 처리를 해주어야 한다)


먼저 해야 할 것은 지난 글을 통해 자신의 프로젝트 소스가 올라간 github repository에 가서 주소를 얻어와야 하는 일이다. 아래의 그림은 github repository를 브라우저로 방문했을때 나타나는 화면이다.



여기서 빨간 박스로 표시된 Clone or download 버튼을 클릭하면 위의 그림과 같이 Clone with HTTPS 타이틀을 가진 조그만 레이어 화면이 나오는데 이때 파란색 박스로 표시된 버튼을 클릭하여 현재 방문한 repository의 URL을 복사하여 문서편집기에 일단 붙여넣자. 그리고 탐색기를 통해 eclipse에서 현재 사용중인 workspace 디렉토리로 이동한 뒤 마우스 우클릭하여 나오는 context menu에서 Git Bash Here 메뉴를 선택한다.



여기서 중요한 점은 이 작업을 하게 되는 디렉토리다. 이 부분은 이전 글과는 차이점이 있다. 이전 글에서는 Git Bash 화면을 띄우는 위치가 해당 프로젝트의 디렉토리였다. 그러나 이번글은 프로젝트가 없는 상태에서 github에 등록된 자신의 프로젝트를 받는 것이기 때문에 이전 글과 같이 해당 프로젝트의 디렉토리로 이동할 수 없는 상황이다. 그렇기 때문에 이 작업을 할때는 이 프로젝트를 받게되는 eclipse workspace 디렉토리에서 해야 한다. 이 작업을 하게 되면 해당 디렉토리에서 Git Bash Prompt 화면을 띄워주게 된다. 이 상태에서 다음의 명령어를 입력해주면 된다. 


git clone remote repository 주소


여기서 remote repository 주소 란 것은 아까 위에서 github에서 복사하여 문서편집기에 붙여넣은 주소이다. 아래의 그림은 다음의 명령어를 실행한 화면이다.



위의 화면을 보면 명령어를 remote repository에 접속하여 해당 remote repository에 올라와 있는 것을 받게 된다. 이때 remote repository 이름(여기서는 samplemvn이 된다)으로 디렉토리를 만들어 받게 된다. 현재 이 명령어를 실행할때 eclipse의 workspace 디렉토리에서 실행했기 때문에 workspace 디렉토리에 remote repository 이름으로 디렉토리를 만들어서 받게 된다. 이때 git local repository도 같이 생성해주기 때문에 이전 글에서 했던 git init 명령을 하지 않는다. 아래의 화면은 이 작업을 진행한 뒤의 workspace 디렉토리를 탐색기로 본 화면이다. samplemvn이란 디렉토리가 만들어져있다. 그래서 git으로 할 작업은 모두 다 끝났다.(벌써? 이걸로?)



그러면 이걸로 진정 끝난걸까? 아니다. 끝난것은 git으로 할 작업뿐이다. eclipse의 workspace 디렉토리에 해당 repository를 다운로드 받으면 eclipse에서 바로 사용할 수 있을까? 전혀 아니다. 왜냐면 workspace 디렉토리에 다운로드만 받은것 뿐이지 이것이 eclipse의 프로젝트로 등록되어진 상태는 아니기 때문이다. 그래서 지금부터는 이렇게 다운로드 받은 프로젝트를 eclipse에 등록하는 작업을 진행하고자 한다. 먼저 eclipse에서 다음과 같이 Package Explorer에서 마우스 우클릭하여 나오는 메뉴에서 import 메뉴를 실행한다.



Import 메뉴를 실행하면 아래의 화면과 같이 Import 화면이 나오는데 여기서 Git의 Projects from Git 선택한뒤 Next 버튼을 클릭한다.



Projects from Git을 선택하면 아래와 같은 화면이 나오는 데 여기서 Existing local repository를 선택한 뒤 Next 버튼을 클릭한다.



Next 버튼을 클릭하면 아래와 같은 화면이 나오는데 여기서 빨간 박스로 표시된 Add 버튼을 클릭한다.



Add 버튼을 클릭하면 아래의 화면과 같이 나타난다. 여기서 빨간 박스로 표시된 Browse... 버튼을 클릭하면 폴더 선택 화면이 나오는데 여기서 local repository 디렉토리를 선택한다. 그러면 이 디렉토리가 어떤것인가? 이전 글에서는 git init 명령을 실행하면 만들어지는 .git 디렉토리가 local repository 디렉토리였지만 지금 상황에서는 맞지 않는다. 그러면 이 디렉토리는 어디인가? 아까 git clone 명령을 실행해서 받은 디렉토리(remote repository 이름으로 된 디렉토리)의 하위 디렉토리를 보면 .git 디렉토리가 있다. 그 디렉토리를 선택해준다.



.git 디렉토리를 선택하면 아래 화면과 같이 선택한 .git 디렉토리가 화면에 보이게 되는데 이때 아래 화면과 같이 해당 .git 디렉토리를 체크 설정을 해준다. 그러면 화면이 나타날 당시엔 비활성화 되어 있는 Finish 버튼이 활성화가 된다. 아래 화면과 같이 설정해준뒤 Finish 버튼을 클릭한다.



Finish 버튼을 클릭하면 아래의 화면과 같이 선택한 local repository가 추가된다. 이때 아래 화면과 같이 추가된 local repository를 선택한 상태에서 Next 버튼을 클릭한다.



Next 버튼을 클릭하면 아래와 같은 화면이 나오는데 여기서 Import as general project를 선택한뒤 Next 버튼을 클릭한다.



Next 버튼을 클릭하면 이 진행과정의 마지막 단계로 프로젝트 이름을 설정하는 화면이 나온다. 프로젝트 이름을 입력한뒤 Finish 버튼을 클릭하면 eclipse에 프로젝트를 등록하는 모든 과정을 마치게 된다.



여기까지 진행해서 github을 통해 받은 프로젝트를 eclipse에 등록하는 과정을 마쳤다. 그러나 이것으로 끝난 것일까? 아니다. 아직 한가지 작업이 더 남았다. 아래의 화면을 보자.



위의 화면은 방금 등록한 프로젝트의 하위 구조를 열어보인 것이다. 이걸로 작업할 수 있을까? 불가능하진 않지만 불편하다. 이전 글을 통해 우리가 프로젝트를 github에 올렸을 때 Maven 기반의 프로젝트를 올렸는데 위의 화면은 Maven 프로젝트의 형태로 보이지 않는다. 이유는 우리가 이 프로젝트를 일반적인 Java 프로젝트로 등록했기 때문이다. 그래서 이 프로젝트를 Maven 기반 프로젝트로 변환해줘야 한다. 위의 그림과 같이 프로젝트에서 마우스 우클릭하여 나오는 context menu에서 configure 메뉴의 Convert to Maven Project 메뉴를 선택해준다. 그러면 프로젝트 구조를 Maven Project 구조로 바꿔주면서 아래의 화면과 같은 형태로 보여주게 된다.



이상으로 모든 과정이 끝났다. git 관련 명령을 실행하는 것도 이전 글에서와 같이 마찬가지로 Eclipse의 Team 메뉴를 통해 git 관련 명령을 실행할 수 있기 때문에 Git Bash 화면을 띄워서 작업하지 않아도 된다. 


이전 글에서와 마찬가지로 이것도 연동하는 과정에서 로그인 아이디와 비밀번호를 물어보는 상황이 나올수 있다. 이때는 github의 로그인 아이디와 비밀번호를 입력하면 된다.


트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

프로그래밍/기타 카테고리의 포스트 목록을 보여줍니다

개인적으로 eclipse와 github을 연동하면서 싫어하는 상황이 하나 있다. 그것은 Eclipse에서 git을 사용하려면 local repository 디렉토리를 설정해야 하는데 연동을 하게 되면 연동된 프로젝트들이 모두 local repository 디렉토리 밑으로 들어가게 되어서 실제로는 프로젝트 소스가 eclipse의 workspace에 존재하지 않게 된다. 이렇게 될 경우 동일한 workspace에 존재하는 여러 프로젝트들 중 git으로 공유되지 않은 프로젝트는 workspace 디렉토리에 있지만 디스크에 2군데에 존재하는 상황이 벌어진다. 이점에 있어서는 IntelliJ 가 잘되어 있는게 IntelliJ의 경우는 local repository를 특정 디렉토리로 설정하는 것이 아니라 공유 대상이 되는 Module 밑에 이 local repository를 두게 된다. 그래서 이클립스와는 달리 같은 소스가 2군데에 존재하는 상황은 벌어지지 않는다(git 연결을 더이상 안할려고 할 경우엔 IntelliJ에서 git과의 연동을 끊고 .git 디렉토리를 지워주면 끝이다) 그래서 이 글에서는 IntelliJ 처럼 Eclipse 프로젝트 디렉토리 밑에 git local repository를 두어서 연동하는 방법에 대해 써보고자 한다. 이 글에서 사용하는 프로그램은 Eclipse는 아니고 Eclipse 기반의 Spring Tool Suite 4(이하 STS로 하겠다)이지만 git을 연동하는것은 Eclipse나 STS 모두 EGit을 사용하기 때문에 같은 방법으로 사용할 수 있다.


이 방법으로 할 경우 먼저 git의 공식 사이트인 git-scm.com에서 자신의 운영체제에 맞는 git client를 설치해야 한다. git client를 설치하는 방법은 다른 블로그들에 이미 많이 소개되어 있어서 여기서는 소개하지는 않고 이것이 설치가 되어 있다는 상태에서 설명을 시작하도록 하겠다. 먼저 git의 remote repository를 만들어준다. github에서 자신이 만든 remote repository를 들어가면 이런 형태의 화면을 보게 될 것이다.



이 화면에서 빨간색 박스가 쳐져 있는 버튼을 클릭해서 현재 자신이 만든 remote repository의 주소를 복사한 뒤에 메모장 같은 문서 편집기에 붙여넣는다. 이 주소는 나중에 쓸 것이라서 일단은 다른데에 보관하는 차원에서 붙여넣어둔 것이다.


그 다음으로 remote repository에 올릴 프로젝트의 디렉토리로 이동한다. 여기서는 설명을 하기 위해 D:\workspaces\samplemvn 디렉토리가 Eclipse의 프로젝트 디렉토리라고 하겠다. 여기서 마우스 우클릭을 하면 다음과 같은 화면이 나타난다(이 프로젝트는 STS에서 Spring Starter Project 메뉴를 이용해서 만든 Maven 기반의 Spring Boot 프로젝트이다. 그래서 .gitignore 파일이 있다)



위에서 언급했던 Git Client를 설치했다면 마우스 우클릭시 다음과 같이 Git GUI Here란 메뉴와 Git Bash Here 란 메뉴가 나타날것이다. 여기서 Git Bash Here 메뉴를 선택한다. 그러면 이 폴더에 위치한 상태로 Git Bash 화면이 나타난다. 이 화면에서 다음의 순서대로 명령어를 입력해서 실행시켜 준다. 그러면 아래의 그림과 같이 나타난다.


  1. git init
  2. git add .
  3. git commit -m "commit message"
  4. git remote add origin 문서편집기에 붙여 두었던 github remote repository 주소
  5. git push origin master

 


위에서 나열한 명령어가 하는 작업에 대해 간략하게 설명하자면 git init이란 명령을 해서 현재 디렉토리를 기준으로 local repository를 만들게 된다. 이 명령을 하면 .git 폴더가 숨김 폴더 형태로 만들어지게 된다. git add . 을 실행해서 local repository에 보관되어 있는 것과 변경점이 있는 파일들을 index에 추가한다. 여기서는 local repository가 금방 만들어져 있는 상태여서 아무것도 없기 때문에 현재 디렉토리에 있는 모든 디렉토리와 파일이 추가된다. 그리고 git commit -m "commit message" 를 통해 index에 추가된 디렉토리와 파일을 commit 하게 된다. 위의 그림을 보면 Init Project 로 commit message를 설정해서 명령을 실행했다. 그리고 git remote origin remote repository 주소를 통해 remote repository를 추가한다. 여기서 사용하는 remote repository 주소는 아까 문서편집기에 붙여넣은 remote repository 주소를 사용한다. 그리고 이렇게 사용되는 remote repository 주소를 origin 이란 이름으로 remote repository에 추가한다. 그리고 마지막으로 git push -u origin master 를 통해 local repository에 있는 디렉토리와 파일들을 remote repository에 추가한다. 이렇게 자신의 프로젝트가 github에 방금 만들어놓은 remote repository에 들어가게 된다. 이 과정을 거친뒤에 github에 들어가면 다음과 같이 자신의 프로젝트 소스들이 들어가 있는 repository를 보게 된다. 



지금까지 한 과정은 github과의 연동을 전체 과정중 절반까지 한 것이다. 우리가 github 연동할 때 위에서 사용했던 Git Bash 화면으로만 할 것이면 전부 다 한것이지만 그렇게 할 경우엔 git 명령을 일일이 프롬프트 화면에서 명령어 입력하는 형태로 진행해야 하기 때문에 불편하다. Git Bash  화면으로 하는 것은 연동에 대한 초기화 작업만 진행하는 것이고 그 다음부터 commit, push, pull 등의 git 관련 명령을 실행하는 것은 eclipse에서 하는 것이 편하다. 실제 현재 상황을 설명하자면 git 과의 연동은 Git Bash 화면에서는 모두 끝이 났지만 eclipse에서는 아무런 연동이 되어 있지 않은 상황이다. 그래서 지금부터 하는 설명은 eclipse에서 git 명령을 할 수 있게 연동하는 과정을 설명하겠다. eclipse에서 Git Bash 화면을 통해 github과 연동되어 있는 프로젝트에서 마우스 우클릭을 하면 아래와 같은 context menu가 나오는데 이 메뉴에서 아래 그림과 같이 Team -> Share Project... 를 선택한다.



Share Project... 메뉴를 선택하면 아래의 그림과 같이 나타난다. 흔히 eclipse와 git 연동 관련 글을 보게 되면 이 과정에서 나오는 화면과는 다른 모습이 보일 것이다. 왜냐면 기존 글은 git을 연동하지 않은 상태에서 메뉴를 선택했기 때문에 local repository를 만드는 과정을 거치지만 우리는 이미 Git Bash 화면을 통해 local repository를 만들어놓은 상태이기 때문에 local repository 디렉토리(여기서는 .git 디렉토리)를 자동으로 인지하게 되어서 아래의 그림과 같이 나타난다. 아래와 같이 화면이 나온 상태에서 Finish 버튼을 클릭하면 Eclipse에서 Git을 연동한 과정이 모두 끝나게 된다.



이렇게 모든 과정을 진행한뒤 다시 eclipse 프로젝트에서 마우스 우클릭을 해서 Team 메뉴를 들어가보면 아래의 그림과 같이 Git 관련 명령을 사용할 수 있는 메뉴들을 볼 수 있게 된다. 이후부터 git 관련 작업은 Git Bash 화면이 아닌 eclipse의 Team 메뉴를 통해서 작업하면 된다.



이렇게 자신이 만든 프로젝트를 github과 같은 remote repository에 올리는 방법에 대해 설명했다. 지금까지 설명한 내용을 살펴보면 eclipse에서 local repository를 만든것이 아니라 Git Bash 화면을 통해 현재 프로젝트 디렉토리 하위에 만들었기 때문에 프로젝트 소스가 workspace에 존재하지 않는 그런 상황이 발생되지 않는다. 이 글에서는 자신이 만든 프로젝트를 remote repository에 올리는 방법에 대해 설명했고 다음 글에서는 remote repostory에 올라와 있는 소스를 자신의 eclipse workspace 디렉토리에 가져오는 방법에 대해 설명하겠다.


이 글에서는 언급하지 않았지만 연동하는 과정에서 로그인 아이디와 비밀번호를 물어보는 상황이 나오게 된다. 이때는 github의 로그인 아이디와 비밀번호를 입력하면 된다.


트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

프로그래밍/기타 카테고리의 포스트 목록을 보여줍니다