나의 개발 족보

어느 날 회사에서 시스템을 하나 더 운영하게 되었다!

인수인계도 없이... 

그러던 어느 날 서비스에 접속이 안된다는 연락을 받고 확인해 보니 서버가 죽진 않았는데 멈췄다.. 뭐지..

서버에 들어가 보자 윈도우 CMD 창으로 띄어진 서버..

일단 Tomcat 재실행으로 문제 해결 후 에러 로그를 확인하려는 찰나.. 로그가 없다.. 

산출물 확인해 보자! CMD 창이 선택 tomcat으로 되어 있다면 서버가 멈추니 CMD 창 클릭 후 엔터를 치라고 되어있다...

이 문제라면 CMD 창이 아니라 서버 구동 방식으로 윈도우 서비스 구동방식으로 변경해야겠다.

조치 1. 윈도우 서비스 구동방식 변경 순서

1. 서비스 이름 수정

  - 경로 : Tomcat > bin > service.bat

  - SERVICE_NAME, DISPLAYNAME 수정

2. service.bat install

3. 생성된 서비스에서 시작 유형 자동으로 수정 후 시작

그리고 한 달 뒤.. 같은 문제 재발생..

서비스 구동방식으로 변경 후 tomcat log가 추가적으로 더 생성되었다.

로그 파일에 increasing the maximum size of the cache 로그 확인

조치 2. Tomcat 설정 수정

Tomcat 캐시 메모리 설정 변경

1. tomcat 서버 > conf > context.xml 파일에 아래 문구 추가

<WatchedResource>WEB-INF/web.xml</WatchedResource>
<WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
<Resources cacheMaxSize="100000" cachingAllowed="true"/>

이후 멈춤 현상은 발생하지 않고 있습니다!

같은 증상 발생할 경우 다시 찾아오도록 하겠습니다.

다시 안 돌아오길..

아키텍처 흐름

1. 어느 부분에서 Authentication이 저장되는가? 
2. AuthenticationManager를 통해서 인증된다.(Authentication)
3. 결과로 나온 Authentication을 다시 SecurityContextHolder에 저장은 어디서?
4. Authentication은 UsernamePasswordAuthenticationFilter, SecurityContextPersisenceFilter 에서 저장되는데 그러면 이 필터들은 어디에서 등록되는가?
5. WebSecurityConfigurerAdapter를 상속받은 SecurityConfig에 설정한 정보가 Filter에 등록되는데 어떻게 url로 요청하면 FilterChainProxy 들어왔는가?
6. DelegatingFilterProxy를 통해서 FilterChainProxy에 들어온다.
7. 권한 확인(인가)은 어디서 이루어지는가? AccessDecisionManager
8. AccessDecisionManager는 어디서 사용하고 있는가? FilterSecurityInterceptor
9. 인증과 인가처리에 발생한 에러가 어떻게 처리되는지? ExceptionTranslationFilter

SecurityContextHolder와 Authentication

SecurityContextHolder

• SecurityContext 제공, 기본적으로 ThreadLocal를 사용
• 한 Thread에 특화되어 있는 정보
• application 어디에서나 꺼내서 사용할 수 있다.
• SampleService.findSercurityContextHolder() 참고

SecurityContext

• Authentication 제공.

Authentication

• Principal과 GrantAuthority 제공.

Principal

• "누구"에 해당하는 정보
• UserDetailsService에서 리턴한 그 객체(AccountService.class 참고)
• 객체는 Userdetails 타입

GrantAuthority

• "ROLE_USER", "ROLE_ADMIN"등 Principal이 가지고 있는 "권한"을 나타낸다.
• 인증 이후, 인가 및 권한 확인할때 이 정보를 참조한다.

UserDetails

• 어플리케이션이 가지고 있는 유저 정보와 스프링 시큐리티가 사용하는 Authentication 객체 사이의 어댑처

UserDetailsService

• 유저 정보를 UserDetails 타입으로 가져오는 DAO 인터페이스
• 구현은 마음대로

AuthenticationManager(인증할 때 사용)와 Authentication

• 스프링 시큐리티에서 인증(Authentication)은 AuthenticationManager가 한다.

Authentication과 SecurityContextHolder

• UsernamePasswordAuthenticationFilter
  • 폼 인증을 처리하는 시큐리티 필터
  • 인증된 Authentication 객체를 SecurityContextHolder에 넣어주는 필터
  • SecurityContextHolder.getContext().setAuthentication(authentication)
• SecurityContextPersisenceFilter
  • SecurityContext를 HTTP session에 캐시(기본 전략)하여 여러 요청에서 Authentication을 공유할 수 있는 공유 필터
  • SecurityContextRepository를 교체하여 세션을 HTTP session이 아닌 다른 곳에 저장하는 것도 가능하다.
  • 같은 session에서만 공유된다.

스프링 시큐리티 Filter와 FilterChainProxy

• 스프링 시큐리티 필터는 FilterChainProxy가 호출한다.
• 여기에 등록되는 필터들은 SecurityConfig에서 설정한 정보가 SecurityFilterChain을 만드는데 사용된다.(FilterChainProxy.getFilters에 SecurityFilterChain)
• SecurityConfig 설정에 따라서 등록되는 Filter에 개수가 달라진다.

DelegatingFilterProxy와 FilterChainProxy

DelegatingFilterProxy

• 일반적인 서블릿 필터(위에서 살펴본 다른 필터들과 같은 서블릿 필터지만 서블릿에 직접 등록되는 필터)
• 서블릿 필터 처리를 스프링에 들어있는 빈으로 위이함고 싶을 때 사용하는 서블릿 필터
• 타겟 빈 이름을 설정한다.
• 스프링 부트 없이 스프링 시큐리티 설정할 때는 AbstractSecurityWebApplicationInitializer를 사용해서 등록
• 스프링 부트를 사용할 때는 자동으로 등록된다. (SecurityFilterAutoConfiguration)

FilterChainProxy

• 보통 "springSecurityFilterChain" 이라는 이름의 빈으로 등록된다.
• DelegatingFilterProxy

AccessDecisionManager

Access Control 결정을 내리는 인터페이스로, 구현체 3가지를 기본적으로 제공

• AffirmativeBased : 여러 Voter중에 한명이라도 허용하면 허용, 기본 전략
• ConsensusBased : 다수결
• UnanimousBased : 만장일치

AccessDecisionVoter

• 해당 Authentication이 특정한 Object에 접근할 때 필요한 ConfigAttributes를 만족하는지 확인한다.
• WebExpressionVoter : 웹 시큐리티에서 사용하는 기본 구현체, ROLE_Xxxx가 매치하는지 확인
• RoleHierarchyVoter : 계층형 ROLE 지원, ADMIN > MANAGER > USER

FilterSecurityInterceptor

• AccessDecisionManager를 사용하여 Access Control또는 예외 처리하는 필터.
• 대부분의 경우 FilterChainProxy에 제일 마지막 필터로 들어있다.

ExceptionTranslationFilter

AuthenticationException

• AuthenticationEntryPoint 실행
• AbstractSecurityInterceptor 하위 클래스(예, FilterSecurityInterceptor)에서 발생하는 예외만 처리
• 그렇다면 UsernamePasswordAuthenticationFilter에서 발생한 인증 에러는? UsernamePasswordAuthenticationFilter 자체에서 처리한다.

AccessDeniedException

• 익명 사용자라면 AuthenticationEntryPoint 실행
• 익명 사용자가 아니라면 AccessDeniedHandler에게 위임

정리

DeligatingFilterProxy -> FilterChaninProxy -> 시큐리티 필터 목록들(체인들은 어떻게 만들어지는가? WebSecurity, HttpSecurity를 이용해서 만들어진다. 참고 - WebSecurity 주석) -> 인증 관련된 객체(AuthenticationManager) -> 인가 관련된 객체(AccessDecisionManager) -> SecurityContextHolder -> SecurityContext -> Authentication -> Pricipal, GrantAuthority

참조 - 스프링 시큐리티(inflearn 백기선님 강의)

이번 시간에는 github의 webhook을 이용해서 소스코드를 push를 하면 자동적으로 소스코드가 배포될 수 있도록 해보겠습니다.

참고로 이번 과정에서는 jenkins pipeline이 구축되어 있는 상태에서 시작합니다.

jenkins 파이프라인이 처음이시라면 저의 블로그에 "토이 프로젝트_STEP 04"를 보고 한 번 따라 해보시길 추천드립니다.

Github

github Repotisory > Settings > Webhooks > Add webhook

webhook

• Payload URL - 젠킨스 서버 주소에 /generic-webhook-trigger 경로를 추가하고 token를 입력합니다.
  • http://locahost:8080를 입력하시면 정상적으로 동작하지 않습니다. (외부에서 접근할 수 있도록 젠킨스 서버를 Forwarding)
  • ngrok 어플리케이션을 이용하면 서버를 쉽게 Forwarding 할 수 있습니다.
• Content type - application/json 타입을 사용합니다.
• Add webhook 버튼을 누릅니다.

github에서 하는 webhook 설정은 모두 끝났습니다.

이제 전에 구축한 jenkins 파이프라인에 webhook 설정을 추가하도록 하겠습니다.

Jenkins

jenkins pipeline Configuration

Post content parameters

  - push한 사용자 이름으로 빌드를 유발시키도록 하겠습니다.

Token

   - 위에서 작성한 토큰 정보를 작성합니다.

Optional filter

  - Post content parameters에 매핑될 사용자 아이디를 작성합니다. 

이것으로 webhook 설정은 끝났습니다.

이제 한 번 webhook을 이용해서 빌드를 유발하도록 하겠습니다.

소스코드를 push 하면 아래와 같이 webhooks > Recent Deliveries에서 webhook에 대한 정보를 확인하실 수 있습니다.

초록색으로 체크가 되었다면 정상적으로 jenkins에게 이벤트를 전달했다고 생각하시면 될 것 같습니다.

토이 프로젝트로 혼자서 클라우드 서비스를 이용하여 웹 개발부터 배포까지 온 과정을 경험해 보았습니다.

이 과정을 단계별로 나누어서 정리해 보려고 합니다.!

많은 피드백은 감사합니다!

목차 

STEP 01) NCP 서버 

STEP 02) AWS RDS, S3

STEP 03) Web Application 개발

STEP 04) Jenkins pipeline 배포

STEP 05) Domain 등록

이번에는 AWS Route53 서비스를 이용해서 도메인을 등록해보겠습니다.

가비아에서 구매 한 도메인을 AWS Route53에 등록해보겠습니다.

Route53에서도 도메인 구매가 가능합니다

1. 호스팅 영역 > 호스팅 영역 생성

2. 도메인 정보 입력

  - 도메인 이름 : 구매한 도메인

  - EC2 퍼블릭 IP

  - 퍼블릭 호스팅 영역 : 인터넷에서 트래픽을 라우팅하고자 하는 방법을 지정하는 레코드를 포함합니다.

3. NameServer 등록

  - NS : 네임서버 레코드로 도메인에 대한 네임서버의 권한을 가지고 있는지 알려주는 레코드

  - SOA : 도메인의 정보를 가지고 있는 레코드

4. 가비아에 AWS 네임서버 등록

  - 호스팅업체의 네임서버를 사용해도 무방합니다.

5. 도메인과 EC2 인스턴스 IP 연결

  - 레코드 생성 클릭

레코드 이름 : 라우팅할 이름을 설정합니다.

레코드 유형 : ec2로 라우팅할 경우 ipv4로 라우팅합니다.

값 : ec2 인스턴스 퍼블릭 IP

TTL : DNS에 ip 주소를 저장하는 시간

레코드를 생성하면 시간이 조금 지나서 등록한 도메인으로 접속이 가능합니다!

Route53은 Free tier 사용하더라도 월별 호스팅 가격 및 쿼리(도메인을 통해서 AWS에 접속하는 횟수) 비용이 발생합니다.

  - Rout53 요금제

토이 프로젝트로 혼자서 클라우드 서비스를 이용하여 웹 개발부터 배포까지 온 과정을 경험해 보았습니다.

이 과정을 단계별로 나누어서 정리해 보려고 합니다.!

많은 피드백은 감사합니다!

목차 

STEP 01) NCP 서버 

STEP 02) AWS RDS, S3

STEP 03) Web Application 개발

STEP 04) Jenkins pipeline 배포

STEP 05) Domain 등록

이번에는 젠킨스 파이프라인을 구축해보도록 하겠습니다.

젠킨스 파이프라인 구성 순서

1. pipeline 구조 생성

2. github clone

3. gradle build

4. ssh를 이용해서 파일 전송 후 applicaton 기동

1. pipeline 구조 생성

젠킨스 파이프라인 구성에 앞서 구조부터 생성해보도록 하겠습니다.

1.1) pipeline 생성

Dashboard > 새로운 Item > name 작성하고 OK

1.2) 샘플을 실행 시켜봅시다. (Advanced Project Options 탭에서 우측상단의 Hello Wold 선택하고 저장)

1.3) 파이프라인 실행

  - 파이프라인 구조를 생성하고 샘플 Script를 실행해보았습니다. 이제 본격으로 파이프라인 구성을 해보도록 하겠습니다.

2. github clone

jenkins pipeline은 Pipeline Syntax를 이용해서 Script를 생성해서 구성합니다.

2.1) Pipeline Syntax > Sample Step(git: Git 선택 혹시 안보이신다면 jenkins관리에서 github plugin을 설치하시기 바랍니다.)

2.2) github repository url을 작성하시고 배포할 Branch를 선택합니다.

2.3) 첫 Jenkins 세팅이라면 Credentials 없으실텐데요. 아래 Add > Jenkins 클릭하시면 아래와 같은 창이 나옵니다.

    - Kind를 Username with password를 선택 후 Password에는 github token을 넣어줍니다. github token 발급은 바로 아래에서 설명드리겠습니다.

    - ID는 중복되지 않도록 작성하시면 됩니다.

2.4) github token 발급

github > Settings > 오르쪽 카테고리에서 Developer settings 선택

Note - token을 구분할 수 있도록 작성하고 Expiration으로 토큰의 기간을 정한다.

Select scopes - 필요한 권한을 체크한다.(저는 repo, admin:repo_hook 체크)

repo : repository 권한

admin:repo_hook : webhook에 필요한 hook 권한

Generate token을 클릭하면 token이 발급됩니다.

아래와같이 발급된 토큰을 복사해서 사용하면됩니다. 토큰 기간만료 또는 분실시 같은 방법으로 토큰을 발급받으면 됩니다.

다시 jenkins로 위에서 추가한 Credentials를 선택하고 Generate Pipeline Script 클릭하면 Script가 생성됩니다.

Syntax에서 생성한 Script를 pipeline으로 가져와서 그대로 붙여줍니다.

github clone에 성공하였습니다!

3. gradle build

build stage를 추가하도록 하겠습니다.

  - build는 clone으로 가져온 소스에 포함되어 있는 gradle wrapper를 이용합니다. 자신의 소스코드에 맞게 위치를 지정해서 gradle          build를 해주시면 됩니다.

build까지 성공하였습니다! 애플리케이션이 배포되기까지 거의 다 왔습니다!

4. ssh를 이용해서 파일 전송 후 applicaton 기동

빌드된 파일을 전달하기위해서는 jenkins에 publish over ssh plugin이 설치되어있어야 합니다.

플러그인이 설치되면 Dashboard > Jenkins 관리 > Configure System으로 이동해서 Publish over SSH에 서버 정보를 입력하면 됩니다.

저는 AWS EC2 서버를 사용하고있습니다.

EC2 접속에 필요한 pem 키를 Key에 붙여넣어줍니다.

Name : syntax에서 참조될 이름

Hostname : private ip

Username : ec2에서 사용되는 username

Remote Dircetory : 베이스 디렉토리(참고, 이 디렉터리 기준으로 파일이 전송되고, 스크립트가 실행된다.)

모두 작성하시고 Test Configuration를 클릭하시면 문제 없으면 Success가 표시됩니다.

Pipeline Syntax로 돌아가서 Step : sshPublisher: Send build artifacts over SSH 선택

Souce files : 빌드된 파일 위치입니다.

Remove prefix : 소스파일에서 원본 파일의 디렉토리를 어디까지 포함할 것인지 설정입니다.(여기서는 jar 파일 하나만 선택되도록 설정)

Remote directory : 위에서 선택된 jar 파일을 해당 디렉터리 아래에 위치시킵니다.

Exec command : 파일을 전송한 다음 실행할 shell

마지막으로 Pipeline에 stage를 추가해서 위 script를 붙여줍니다.

최종 pipeline script

pipeline {
    agent any

    stages {
        stage('github clone') {
            steps {
                git credentialsId: 'tutorial-jenkins-token', url: 'https://github.com/kgc0120/daily_special.git'
            }
        }
        
        stage('build'){
            steps{
                sh'''
                    echo build start
                    ./gradlew clean bootJar
                '''
            }
        }
        
        stage('publish over ssh'){
            steps{
                sshPublisher(publishers: [sshPublisherDesc(configName: 'aws-daily-special'
                , transfers: [sshTransfer(cleanRemote: false
                , excludes: ''
                , execCommand: 'sh /dailySpecial/app/nonstop/deploy.sh'
                , execTimeout: 120000, flatten: false, makeEmptyDirs: false
                , noDefaultExcludes: false
                , patternSeparator: '[, ]+'
                , remoteDirectory: '/app/nonstop/springboot-webservice/build/libs'
                , remoteDirectorySDF: false
                , removePrefix: 'build/libs', sourceFiles: 'build/libs/*.jar')]
                , usePromotionTimestamp: false
                , useWorkspaceInPromotion: false
                , verbose: false
                )])
            }
        }
    }
}

pipeline을 실행시켜보면 서버 배포까지 정상적으로 성공하였습니다!!

정말 시행착오도 많았고 길었던 Jenkins pipeline 구축이었습니다... ㅜ

다음번에는 github webhooke을 이용해서 소스코드를 push 하면 젠킨시가 자동으로 배포되도록 해보겠습니다.

Spring에서 @Value 애노테이션은 설정 파일(yml, properties)에 있는 정보를 가져오는데 주로 사용됩니다.

@Value로 설정 파일 값을 가져오는 변수가 null인 경우 점검해보아야 하는 부분을 정리하였습니다. 

1. 어느 @Value 애노테이션을 사용했는지 import 확인

lombok이 아닌 spring 애노테이션을 사용하자

import org.springframework.beans.factory.annotation.Value;

2. static 변수에는 값을 넣을 수 없다.

예시는 application.properties 파일에서 active.root 값을 Config class에서 path 변수에 저장해서 사용하고 있습니다.

path 변수를 클래스 변수(static 변수)로 지정해서 테스트 해보도록 하겠습니다.

Config.java

@Component
public class Config {

    @Value("${active.root}")
    private static String path;

    public String getPath() {
        return path;
    }
}

application.properties

active.root=home

Test Code

@SpringBootTest
class ConfigServiceTest {

    @Autowired
    Config config;

    @Test
    void findActiveRootTest() {
        String root = "home";
        Assertions.assertEquals(config.getPath(), root);
    }

}

Test Code 결과

org.opentest4j.AssertionFailedError: 
Expected :null
Actual   :home

null 이 출력되는 것을 확인할 수 있습니다.

Config class에서 static 변수를 일반 전역 변수로 수정하면 문제를 해결됩니다.

3. Spring Bean으로 생성된 객체가 아닌 경우

Spring은 애플리케이션 로딩 시점에 스프링 컨테이너 내부에서 모든 빈들을 등록하면서 @Value 애노테이션 안의 값들을 설정 파일에서 읽어들여 변수에 저장합니다.

그 결과 Spring에서 싱글톤으로 관리되는 빈이 아닌 새로운 객체로 생성하게 되면 @Value 애노테이션으로 설정 파일을 읽어들이는 변수는 null로 값이 저장되지 않습니다.

Test Code

  - @Autowired를 제거하고 new를 이용해서 Config 인스턴스를 생성하였습니다.

@SpringBootTest
class ConfigServiceTest {

    @Test
    void findActiveRootTest() {

        Config config = new Config();

        String root = "home";
        Assertions.assertEquals(config.getPath(), root);
    }

}

Test Code 결과

org.opentest4j.AssertionFailedError: 
Expected :null
Actual   :home

Test Code

 - 정상으로 값이 저장되는 경우

 - new 연산자를 이용해서 인스턴스를 생성해서 사용하고 있는 것은 아닌지 확인해 보자!

@SpringBootTest
class ConfigServiceTest {

    @Autowired
    Config config;

    @Test
    void findActiveRootTest() {
        String root = "home";
        Assertions.assertEquals(config.getPath(), root);
    }

}

1. Jar 파일 생성하기

1. File > Project Structure

2. Artifacts > + 버튼 클릭 > JAR > From modules with dependencies...

3. Main Class - Jar 실행 파일을 생성할 경우 Main Class 선택 / 외부 추가용 Jar 파일 생성할 경우 생략

4. 위 2번 순서에 Output directory 위치에 Jar 파일 생성

2. 외부 Jar 파일 추가해서 사용하기

Spring Boot 프로젝트에 위에서 생성한 printjar 파일을 외부 jar 파일로 추가해서 사용해 보도록 하겠습니다.

위에서 생성한 printjar 파일 내부 클래스

package lib;

public class PrintJarMain {

    public static void print() {
        System.out.println("PrintJar Call!!");
    }

    public void test() {
        System.out.println("test");
    }


}

1. File > Project Structure

2. Modules > main > + 버튼 클릭 > JARs or Directories... > 위에서 생성한 printjar 파일 선택

3. Main 함수

  - 외부 jar로 추가한 printjar 내부 클래스의 메소드 호출

@SpringBootApplication
public class AopApplication {

    public static void main(String[] args) {

        PrintJarMain printJarMain = new PrintJarMain();
        System.out.println("<<<<<===============>>>>>>>>>");
        printJarMain.print();
        System.out.println("<<<<<===============>>>>>>>>>");
        printJarMain.test();
        System.out.println("<<<<<===============>>>>>>>>>");
        SpringApplication.run(AopApplication.class, args);
    }

}

4. 결과

<<<<<===============>>>>>>>>>
PrintJar Call!!
<<<<<===============>>>>>>>>>
test
<<<<<===============>>>>>>>>>

git 캐시를 삭제 후 다시 프로젝트를 PUSH 해줍니다.

git rm -r --cached .
git add .
git commit -m "DELETE git cached"

추가적으로 .gitignore에 파일이 등록되어 앞으로 파일이 repository에 안 올라가도 히스토리를 통해서 기존 파일 확인이 가능합니다.

중요한 정보가 노출되는 불상사를 막기 위해서는 히스토리도 삭제를 해줘야 합니다.

설정 파일인 yml 파일의 히스토리를 삭제해 보도록 하겠습니다. 

--ignore-unmatch 파일 경로( git repository 기준의 경로값)

git filter-branch --force --index-filter "git rm --cached --ignore-unmatch *.yml" --prune-empty --tag-name-filter cat -- --all

git push origin master --force

이상으로 git 캐시 삭제와 히스토리 삭제를 알아보았습니다!