스프링 부트 기능정의

단독실행가능한 스프링 애플리케이션 생성 내장 컨테이너로 톰캣, 제티, 혹은 언더토우 중에서 선택가능 스타터(starter)를 통해 간결한 의존성 구성지원 스프링에 대한 자동구성(Auto-Configuration) 제공 더이상 XML 구성 필요없음 (pom.xml 정도만 작업 후 순수한 자바만 가지고 적용가능. 제품 출시(release) 후 운영에 필요한 다양한 기능(상태점검, 모니터링 등) 제공 (healthcheck?)

스프링부트 구성요소

빌드도구(그레이들 vs 메이븐) : 요근대는 그레이들을 많이씀. (아직 maven 사용) 스프링 프레임워크(4.x vs 5.x) 스프링 부트(v1.5 vs v2.0) 스프링 부트 스타터(spring-boot-starter)

프랑스 철학자 ‘장 풀 샤르트르’가 인생은 BCD 라고 했다고 합니다. 태어나고(Bitch)- 죽는(Death) 사이에 수많은 선택을 한다고,

스트링 부트 또한 BCD입니다.

Build - Code - Deploy

• Build
• Code.
  • spring-boot-starter
  • Auto-configuration
  • programming in spring enviroment
• Deploy

Build(빌드)

Java va Kotilin vs Groovy

스프링 부트는 자바, 코틀린, 그루비를 지원합니다.

빌드도구로는 그레이들과 메이븐이 있는데, 의존성과 빌드동작들을 실행하는 스크립트가 존재합니다. 그래들은 build.gradle 에 선언하고 maven의 경우 pom.xml 에 선언하게 됩니다.

Executable Jar or war

실행학능한(Executable) JAR (or WAR) : App 과 tocmat 이 공존 고전적인 WAR : 톰캣과 APP이 분리되어있는 형태

스프링부트는 2.0부터!!

1.5 는 스프링 4 지원 2.0은 스프링 5 지원이며 주가되는 것은 스프링부트 2.0을 주가 됩니다.

스프링부트는 애너테이션 기반으로 작동(컴포넌트를 탐색하여 동작함.)

@SpringBoodtApplication(with SpringApplication) @ComponentScan @EnableAutoConfiguration @configuration @ConditonalOn~~ @SpringBoodtConfigration(= @Configuration) @EnableConfigurationProperties @ConfigurationProperties

Auto-Configuration

• spring-starter 를 github에서 검색가능합니다.
• 스프링부트가 기술흐름에 따라 제공하는 관례(Convention)적인 구성
• 봐야할 모듈 : spring-boot-autoconfigure
• 동작선언
  • @EnableAtuoConfigurazion(with @SpringBootApplication)
  • @Configuration
• tkdyd dosjxpdltus
  • @Configuration
  • @ConditonalOn

외부구성(External Configuration)

1. 실행인자
2. spring_application_json
   • 서버안에 json 으로 선언한 구성파일의 위치 지정
3. 환경변수(운영체제)
4. 기타등등
5. application.yml or application.properties
6. application-{defaultprofiles}.yml

1이 우선순위가 가장높습니다.

Programming in Spring Environment

• @ComponentScan 을 통해 ApplicationContext 적재
  • @Repository
  • @Component
  • @Service
  • @Controller & @RestController
  • @Configuratioin
    • @Bean
    • @ConfiguraitonProperties
  • DI, IoC, @Autowired
  • @Value Vs @ConfigurationProperties
  • AOP 프로그래밍

완료 – 업무 구현(비즈니스 로직)

alias 란 ?

일종의 별명으로, 서버에서 작업하거나 모니터링을 할 때,
너무 길거나 복잡해서 매번 입력하기 귀찮거나 기억하기 어려운 명령들이 있을 수 있으며,
이러한 명령을 자주 사용하지 않는다면 큰 무리가 없겠으나,
개개인의 업무 스타일에 따라 자주 사용하게 된다면 그때마다 매번 명령들을 어렵게 입력해야 하는 고통을 감내해야 합니다.
alias 기능을 이용하면 어떤 명령이든지 명령의 길이가 얼마이든지 상관없이 내가 사용하기 편하게 바꾸어서 사용할 수 있습니다.

다만, 그렇게 되면 alias 명령어를 외우게 되어 실제 명령어를 까먹을 수 있으니, alias 설정했다는 것을 잊지 말아야합니다.

사용자별 alias 가 있고, 모든 사용자에 대한 alias 가 존재합니다.

/home/계정명/.bashrc
/etc/bashrc

보통은 root 에서 작업을 한다고 할 경우에,

/home/root/.bashrc

에 alias 를 등록하여 처리하게 됩니다. 작업이 완료되면,

source ~/.bashrc

를 사용하여 바로 적용하면됩니다.

서버내부에서 helthcheck 서버를 구성할 때 처리할 때, 특정폴더에 올라간 jar 파일을 가지고, 서버를 실행시키거나, 중지시키는 용도의 shell script 입니다.

#!/bin/sh
SERVICE_NAME=healthcheck
PATH_TO_JAR=/home/users/deploy/healthcheck.jar
PID_PATH_NAME=/tmp/healthcheck-pid
case $1 in
    start)
        echo "Starting $SERVICE_NAME ..."
        if [ ! -f $PID_PATH_NAME ]; then
            nohup java -jar $PATH_TO_JAR /tmp 2>> /dev/null >> /dev/null & echo $! > $PID_PATH_NAME
            echo "$SERVICE_NAME started ..."
        else
            echo "$SERVICE_NAME is already running ..."
        fi
    ;;
    stop)
        if [ -f $PID_PATH_NAME ]; then
            PID=$(cat $PID_PATH_NAME);
            echo "$SERVICE_NAME stoping ..."
            kill $PID;
            echo "$SERVICE_NAME stopped ..."
            rm $PID_PATH_NAME
        else
            echo "$SERVICE_NAME is not running ..."
        fi
    ;;
esac

start 할 때, pid 를 특정 파일에 저장하며, stop 할때 해당 pid를 kill 합니다. 자주 사용하는 기능으로, pid를 저장함으로써 다시 실행하거나 중지할때 해당 파일을 kill 합니다.

이 스크립트의 문제는 별도의 서비스를 통해, 프로세스가 kill 되었을 때, 혹은 pid 파일이 삭제되면, stop을 하더라도 프로세스가 종료가 안될 수 있습니다.

참조