본문 바로가기
IT/SpringBoot

스프링 부트 #6.애플리케이션 배포

blogood 2020. 6. 19. 21:54
반응형

6. 스프링 부트 애플리케이션 배포

Spring Boot의 유연한 패키징 옵션은 응용 프로그램 배포와 관련하여 다양한 선택을 제공합니다. Spring Boot 애플리케이션을 다양한 클라우드 플랫폼, 컨테이너 이미지 (Docker 등) 또는 가상 / 실제 머신에 배치 할 수 있습니다.

이 섹션에서는보다 일반적인 배포 시나리오에 대해 설명합니다.

6.1. 컨테이너에 배포

컨테이너에서 응용 프로그램을 실행하는 경우 실행 가능한 jar을 사용할 수 있지만,이를 확장하여 다른 방식으로 실행하는 것이 종종 유리합니다. 특정 PaaS 구현은 아카이브가 실행되기 전에 압축을 풀도록 선택할 수도 있습니다. 예를 들어 Cloud Foundry는 이러한 방식으로 작동합니다. 압축을 푼 아카이브를 실행하는 가장 간단한 방법은 다음과 같이 적절한 실행기를 시작하는 것입니다.

$ jar -xf myapp.jar
$ java org.springframework.boot.loader.JarLauncher

이는 실제로 확장되지 않은 아카이브에서 실행하는 것보다 시작시 (jar의 크기에 따라) 약간 빠릅니다. 런타임에 차이점을 기 대해서는 안됩니다.

jar 파일의 압축을 풀고 나면 "대신"기본 방법으로 앱을 실행하여 시작 시간을 추가로 늘릴 수 있습니다 JarLauncher. 예를 들면 다음과 같습니다.

$ jar -xf myapp.jar
$ java -cp BOOT-INF / classes : BOOT-INF / lib / * com.example.MyApplication
  를 사용하여 JarLauncher응용 프로그램의 주 방법보다 것은 예측 가능한 클래스 경로 순서의 추가 혜택을했다. jar에는 클래스 경로를 구성 할 때 classpath.idx사용되는 파일이 포함되어 있습니다 JarLauncher.

종속성과 응용 프로그램 클래스 및 리소스 (일반적으로 더 자주 변경됨)에 대해 별도의 레이어 를 만들어보다 효율적인 컨테이너 이미지를 만들 수도 있습니다 .

6.2. 클라우드에 배포

Spring Boot의 실행 가능한 jar는 가장 인기있는 클라우드 PaaS (Platform-as-a-Service) 제공 업체를 위해 기성품입니다. 이 제공자들은 귀하에게“자신의 용기를 가져와”요구하는 경향이 있습니다. 그들이 적응 중간 계층이 필요 그래서 그들은 응용 프로그램 프로세스 (안 특히 Java 응용 프로그램)을 관리 하여 받는 응용 프로그램 클라우드의 실행중인 프로세스의 개념을.

인기있는 클라우드 공급 업체 인 Heroku와 Cloud Foundry는 "빌드 팩"접근 방식을 사용합니다. 빌드 팩은 배포 된 코드를 응용 프로그램 을 시작하는 데 필요한 모든 것으로 포장합니다 . JDK 및에 대한 호출 java, 내장 웹 서버 또는 본격적인 응용 프로그램 서버 일 수 있습니다. 빌드 팩은 플러그 가능하지만 가능한 한 적은 수의 사용자 정의로 얻을 수 있어야합니다. 이렇게하면 제어 할 수없는 기능의 풋 프린트가 줄어 듭니다. 개발 환경과 프로덕션 환경 간의 차이를 최소화합니다.

이상적으로 Spring Boot 실행 파일 jar과 같은 응용 프로그램에는 패키지 실행에 필요한 모든 것이 있습니다.

이 섹션에서는 "시작하기"섹션에서 개발 한 간단한 애플리케이션을 클라우드에서 실행 하는 데 필요한 사항을 살펴 봅니다 .

6.2.1. 클라우드 파운드리

Cloud Foundry는 다른 빌드 팩이 지정되지 않은 경우 기본 빌드 팩을 제공합니다. Cloud Foundry Java 빌드 팩 은 Spring Boot를 포함하여 Spring 애플리케이션을 완벽하게 지원합니다. 기존 .war패키지 응용 프로그램 뿐만 아니라 독립 실행 형 실행 가능 jar 응용 프로그램을 배포 할 수 있습니다 .

당신이 (예를 들어, 사용하여 응용 프로그램을 구축 한 후 mvn clean package) 및 한 설치된 cf명령 줄 도구를 의 사용하여 응용 프로그램을 배포 cf push, 명령을 컴파일 경로를 대체 .jar. 응용 프로그램을 푸시하기 전에 명령 행 클라이언트로 로그인cf 했는지 확인하십시오 . 다음 행은 cf push명령을 사용하여 응용 프로그램을 배포하는 것을 보여줍니다 .

$ cf push acloudyspringtime -p target / demo-0.0.1-SNAPSHOT.jar
  앞의 예에서, 우리 는 당신이 당신의 응용 프로그램의 이름으로 acloudyspringtime제공 cf한 값을 대신 합니다.

추가 옵션에 대해서는 cf push설명서 를 참조하십시오 . manifest.yml동일한 디렉토리에 Cloud Foundry 파일이 있으면 해당 파일이 고려됩니다.

이 시점에서, cf다음 예와 비슷한 출력을 생성, 응용 프로그램을 업로드 시작합니다

acloudyspringtime 업로드 중 ... 확인 acloudyspringtime 
시작 준비 중 ... 확인 
-----> 다운로드 한 앱 패키지 ( 8.9M )
-----> Java Buildpack 버전 : v3.12 (오프라인) | https://github.com/cloudfoundry/java-buildpack.git#6f25b7e
-----> https://java-buildpack.cloudfoundry.org/openjdk/trusty/x86_64/openjdk-1.8.0_121.tar.gz에서 Open Jdk JRE 1.8.0_121 다운로드 (캐시에 있음)
       Open Jdk JRE를 .java-buildpack / open_jdk_jre (1.6 초)로 확장
-----> https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/memory-calculator-2.0.2_RELEASE.tar.gz에서 Open JDK Like Memory Calculator 2.0.2_RELEASE 다운로드 은닉처)
       메모리 설정 : -Xss349K -Xmx681574K -XX : MaxMetaspaceSize = 104857K -Xms681574K -XX : MetaspaceSize = 104857K
https://java-buildpack.cloudfoundry.org/container-certificate-trust-store/container-certificate-trust-store-1.0.0_RELEASE.jar에서 컨테이너 인증서 신뢰 저장소 1.0.0_RELEASE 다운로드 -----> 캐시에)
       .java-buildpack / container_certificate_trust_store / truststore.jks (0.6s)에 인증서 추가
-----> https://java-buildpack.cloudfoundry.org/auto-reconfiguration/auto-reconfiguration-1.10.0_RELEASE.jar에서 Spring Auto Reconfiguration 1.10.0_RELEASE 다운로드 (캐시에 있음)
앱 'acloudyspringtime'의 상태 확인 중 ...
  인스턴스 1 개 중 0 개 (시작 1 개)
  ...
  인스턴스 1 개 중 0 개 (시작 1 개)
  ...
  인스턴스 1 개 중 0 개 (시작 1 개)
  ...
  1 개 인스턴스 중 1 개 (실행 중 1 개)

앱 시작

축하합니다! 응용 프로그램은 이제 라이브입니다!

응용 프로그램이 활성화되면 cf apps다음 예와 같이 명령 을 사용하여 배포 된 응용 프로그램의 상태를 확인할 수 있습니다 .

$ cf 앱
응용 프로그램 가져 오기 ...
확인

요청 된 상태 인스턴스 메모리 디스크 URL 이름
...
acloudyspringtime 시작 1/1 512M 1G acloudyspringtime.cfapps.io
...

Cloud Foundry가 애플리케이션이 배포되었음을 확인하면 제공된 URI에서 애플리케이션을 찾을 수 있어야합니다. 앞의 예에서는에서 찾을 수 있습니다 https://acloudyspringtime.cfapps.io/.

서비스에 바인딩

기본적으로 실행중인 응용 프로그램 및 서비스 연결 정보에 대한 메타 데이터는 응용 프로그램에 환경 변수 (예 :)로 노출됩니다 $VCAP_SERVICES. 이 아키텍처 결정은 Cloud Foundry의 폴리 글롯 (모든 언어 및 플랫폼이 빌드 팩으로 지원 될 수 있음) 특성에 기인합니다. 프로세스 범위 환경 변수는 언어에 구애받지 않습니다.

환경 변수가 항상 가장 쉬운 API를 만드는 것은 아니므로 Spring Boot는 자동으로 변수를 추출 Environment하여 다음 예제와 같이 Spring의 추상화를 통해 액세스 할 수있는 속성으로 데이터를 플랫 화합니다 .

@Component
class MyBean implements EnvironmentAware {

    private String instanceId;

    @Override
    public void setEnvironment(Environment environment) {
        this.instanceId = environment.getProperty("vcap.application.instance_id");
    }

    // ...

}

모든 Cloud Foundry 속성에는 접두사가 붙습니다 vcap. vcap속성을 사용 하여 응용 프로그램 정보 (예 : 응용 프로그램의 공용 URL) 및 서비스 정보 (예 : 데이터베이스 자격 증명)에 액세스 할 수 있습니다 . 자세한 내용은 'CloudFoundryVcapEnvironmentPostProcessor'Javadoc을 참조 하십시오.

  자바 CFEnv의 프로젝트는 데이터 소스를 구성하는 등의 작업을위한 더 나은 적합합니다.

6.2.2. 쿠 버네 티스

Spring Boot는 환경 "*_SERVICE_HOST"및 "*_SERVICE_PORT"변수 를 확인하여 Kubernetes 배포 환경을 자동 감지 합니다. spring.main.cloud-platform구성 속성 으로이 탐지를 무시할 수 있습니다 .

Kubernetes 컨테이너 수명주기

Kubernetes가 응용 프로그램 인스턴스를 삭제하면 종료 프로세스에는 여러 개의 하위 시스템이 동시에 포함됩니다. 종료 후크, 서비스 등록 해제,로드 밸런서에서 인스턴스 제거 ...이 종료 처리는 병렬로 수행되며 (분산 시스템의 특성으로 인해) 종료 처리를 시작한 포드로 트래픽을 라우팅 할 수있는 창이 있습니다.

요청이 이미 종료되기 시작한 포드로 라우팅되지 않도록 preStop 처리기에서 절전 실행을 구성 할 수 있습니다. 이 대기 시간은 새 요청이 포드로 라우팅되는 것을 중지하기에 충분히 길어야하며 지속 기간은 배포마다 다릅니다. 사전 중지 처리기는 다음과 같이 포드 구성 파일의 PodSpec을 통해 구성 할 수 있습니다.

spec:
  containers:
  - name: example-container
    image: example-image
    lifecycle:
      preStop:
        exec:
          command: ["sh", "-c", "sleep 10"]

사전 정지 후크가 완료되면 SIGTERM이 컨테이너로 전송되고 정상 종료 가 시작되어 나머지 기내 요청이 완료 될 수 있습니다.

6.2.3. 헤 로쿠

Heroku는 또 다른 인기있는 PaaS 플랫폼입니다. Heroku 빌드를 사용자 정의하려면을 제공 Procfile하여 애플리케이션을 배포하는 데 필요한 주문을 제공합니다. Heroku port는 Java 응용 프로그램에 사용할 a 를 할당 한 다음 외부 URI 로의 라우팅이 작동하도록합니다.

올바른 포트에서 청취하도록 애플리케이션을 구성해야합니다. 다음 예제는 Procfile스타터 REST 애플리케이션 의 를 보여줍니다 .

웹 : java -Dserver.port = $ PORT -jar 대상 /demo-0.0.1-SNAPSHOT.jar

Spring Boot는 -DSpring Environment인스턴스 에서 접근 가능한 속성 으로 인수를 사용할 수 있게 합니다. server.port구성 속성이 시작할 때 그 포트를 사용하여 매립 톰캣 부두 또는 역류 인스턴스에 공급된다. $PORT환경 변수는 Heroku가 PaaS를 우리에게 할당됩니다.

이것은 당신이 필요로하는 모든 것이어야합니다. Heroku 배포를위한 가장 일반적인 배포 워크 플로 git push는 다음 예제와 같이 프로덕션 코드입니다.

$ git push heroku master

리포지토리 초기화가 완료되었습니다 .
개체 수 : 95, 완료 .
최대 8 개의 스레드를 사용한 델타 압축.
객체를 압축 : 100 % (78분의 78)를 수행 .
객체 쓰기 : 100 % (95/95), 8.66 MiB | 606.00 KiB / s 완료 .
총 95 (델타 31), 재사용 된 0 (델타 0)

-----> Java 앱이 감지되었습니다
-----> OpenJDK 1.8 설치 ... 완료 
-----> Maven 3.3.1 설치 ... 완료 
-----> settings.xml 설치 ... 완료
-----> 실행 : mvn -B -DskipTests = true 새로 설치

       [정보] 프로젝트 스캔 중 ...
       다운로드 중 : https : //repo.spring.io / ...
       다운로드 : https : //repo.spring.io / ... (1.8 KB / 초에 818 B)
        ....
       다운로드 : https : //s3pository.heroku.com/jvm / ... (595.3 KB / sec에서 152KB)
       [정보] / tmp / build_0c35a5d2-a067-4abc-a232-14b1fb7a8229 / target / ... 설치
       [정보] /tmp/build_0c35a5d2-a067-4abc-a232-14b1fb7a8229/pom.xml 설치 ...
       [정보] ----------------------------------------------- -------------------------
       [정보] 빌드 성공
       [정보] ----------------------------------------------- -------------------------
       [정보] 총 시간 : 59.358s
       [정보] 마감일 : 금 3 월 07 일 07:28:25 UTC 2014
       [정보] 최종 메모리 : 20M / 493M
       [정보] ----------------------------------------------- -------------------------

-----> 프로세스 유형 발견
       Procfile은 타입을 선언합니다-> 웹

-----> 압축 ... 완료 , 70.4MB
-----> 시작 ... 완료 , v6
       https://agile-sierra-1405.herokuapp.com/ Heroku에 배포

에 git@heroku.com 민첩 - 시에라 - 1405.git :
 * [신규 지점] 마스터-> 마스터

이제 응용 프로그램이 Heroku에서 작동하고 실행 중이어야합니다. 자세한 내용은 Heroku에 Spring Boot 응용 프로그램 배포를 참조하십시오 .

6.2.4. OpenShift

OpenShift 에는 다음을 포함하여 Spring Boot 응용 프로그램을 배포하는 방법을 설명하는 많은 리소스가 있습니다.

6.2.5. 아마존 웹 서비스 (AWS)

Amazon Web Services는 전통적인 웹 애플리케이션 (전쟁) 또는 내장 웹 서버가있는 실행 가능한 jar 파일로 Spring Boot 기반 애플리케이션을 설치하는 여러 가지 방법을 제공합니다. 옵션은 다음과 같습니다.

  • AWS Elastic Beanstalk
  • AWS 코드 배포
  • AWS OPS 작동
  • AWS 클라우드 형성
  • AWS 컨테이너 레지스트리

각각 다른 기능과 가격 모델이 있습니다. 이 문서에서는 가장 간단한 옵션 인 AWS Elastic Beanstalk 만 설명합니다.

AWS Elastic Beanstalk

공식 Elastic Beanstalk Java 안내서에 설명 된대로 Java 애플리케이션을 배포하는 두 가지 기본 옵션이 있습니다. "Tomcat 플랫폼"또는 "Java SE 플랫폼"을 사용할 수 있습니다.

Tomcat 플랫폼 사용

이 옵션은 war 파일을 생성하는 Spring Boot 프로젝트에 적용됩니다. 특별한 구성이 필요하지 않습니다. 공식 가이드 만 따라하면됩니다.

Java SE 플랫폼 사용

이 옵션은 jar 파일을 생성하고 내장 웹 컨테이너를 실행하는 Spring Boot 프로젝트에 적용됩니다. Elastic Beanstalk 환경은 포트 80에서 nginx 인스턴스를 실행하여 포트 5000에서 실행되는 실제 애플리케이션을 프록시합니다.이를 구성하려면 application.properties파일에 다음 행을 추가 하십시오.

server.port = 5000
 
소스 대신 바이너리 업로드

기본적으로 Elastic Beanstalk는 소스를 업로드하고 AWS에서 컴파일합니다. 그러나 바이너리를 대신 업로드하는 것이 가장 좋습니다. 이렇게하려면 .elasticbeanstalk/config.yml파일에 다음과 유사한 줄을 추가 하십시오.

deploy:
    artifact: target/demo-0.0.1-SNAPSHOT.jar
 
환경 유형을 설정하여 비용 절감

기본적으로 Elastic Beanstalk 환경은로드 밸런싱됩니다. 로드 밸런서는 비용이 많이 듭니다. 이러한 비용을 피하려면 Amazon 설명서에 설명 된대로 환경 유형을 "단일 인스턴스"로 설정하십시오 . CLI 및 다음 명령을 사용하여 단일 인스턴스 환경을 작성할 수도 있습니다.

eb create -s
요약

이는 AWS에 접근하는 가장 쉬운 방법 중 하나이지만 Elastic Beanstalk를 CI / CD 도구에 통합하고 CLI 대신 Elastic Beanstalk Maven 플러그인을 사용하는 방법과 같이 더 많은 내용을 다루어야합니다. 이 블로그 게시물 더 자세히 이러한 주제를 다루는는.

6.2.6. Boxfuse 및 Amazon Web Services

Boxfuse 는 Spring Boot 실행 파일 jar 또는 war를 VirtualBox 또는 AWS에서 변경없이 배포 할 수있는 최소 VM 이미지로 전환하여 작동합니다. Boxfuse는 Spring Boot와 긴밀하게 통합되어 있으며 Spring Boot 구성 파일의 정보를 사용하여 포트 및 상태 확인 URL을 자동으로 구성합니다. Boxfuse는이 정보를 생성 한 이미지와 프로비저닝하는 모든 리소스 (인스턴스, 보안 그룹, 탄력적로드 밸런서 등)에 모두 활용합니다.

Boxfuse 계정 을 생성하고 이를 AWS 계정에 연결하고 최신 버전의 Boxfuse 클라이언트를 설치 한 후 애플리케이션을 Maven 또는 Gradle (예 :을 사용하여)로 빌드했는지 확인 mvn clean package하면 Spring을 배포 할 수 있습니다 다음과 유사한 명령을 사용하여 애플리케이션을 AWS로 부트하십시오.

$ boxfuse myapp-1.0.jar 실행 -env = prod

추가 옵션에 대해서는 boxfuse run설명서 를 참조하십시오 . 가있는 경우 boxfuse.conf현재 디렉토리에있는 파일 존재, 그것은 간주됩니다.

  기본적으로 Boxfuse boxfuse는 시작시 이름이 지정된 스프링 프로파일을 활성화합니다 . 실행 가능한 jar 또는 war에 application-boxfuse.properties파일 이 포함 된 경우 Boxfuse 는 파일에 포함 된 속성을 기반으로 구성합니다.

이 시점에서 boxfuse애플리케이션의 이미지를 생성하고 업로드 한 다음 AWS에서 필요한 리소스를 구성 및 시작하여 다음 예제와 유사한 결과를 얻습니다.

myapp-1.0.jar의 이미지 융합 ...
00 : 06.838s (53937 K)에 융합 된 이미지-> axelfontaine / myapp : 1.0
axelfontaine / myapp 생성 ...
axelfontaine / myapp : 1.0 푸시하기 ...
axelfontaine / myapp : 1.0 확인 중 ...
탄력적 IP 생성 ...
myapp-axelfontaine.boxfuse.io를 52.28.233.167로 매핑 ...
eu-central-1에서 AWS가 axelfontaine / myapp : 1.0 용 AMI를 생성하기를 기다리는 중 (최대 50 초 소요) ...
00 : 23.557s에서 생성 된 AMI-> ami-d23f38cf
보안 그룹 boxfuse-sg_axelfontaine / myapp : 1.0 생성 중 ...
EU-Central-1에서 axelfontaine / myapp : 1.0 (ami-d23f38cf)의 t2.micro 인스턴스 출시 ...
00 : 30.306에서 시작된 인스턴스-> i-92ef9f53
https://52.28.235.61/에서 AWS가 인스턴스 i-92ef9f53 및 페이로드가 부트되기를 기다리는 중 ...
페이로드는 00 : 29.266s에서 시작되었습니다-> https://52.28.235.61/
Elastic IP 52.28.233.167을 i-92ef9f53로 다시 매핑 ...
AWS가 Elastic IP Zero Downtime 전환을 완료 할 때까지 15 초 동안 대기 ...
배포가 성공적으로 완료되었습니다. axelfontaine / myapp : 1.0이 https://myapp-axelfontaine.boxfuse.io/에서 실행 중입니다.

이제 애플리케이션이 AWS에서 작동하고 실행 중이어야합니다.

에 블로그 게시물을 참조하십시오 EC2에 봄 부트 응용 프로그램을 배포 아니라 한 Boxfuse 봄 부트 통합 문서 응용 프로그램을 실행하는 메이븐 빌드를 시작하기를.

6.2.7. 구글 클라우드

Google Cloud에는 Spring Boot 애플리케이션을 시작하는 데 사용할 수있는 몇 가지 옵션이 있습니다. 시작하기 가장 쉬운 방법은 아마도 App Engine이지만 컨테이너 엔진이있는 컨테이너 또는 Compute Engine이있는 가상 머신에서 Spring Boot를 실행하는 방법을 찾을 수도 있습니다.

App Engine에서 실행하려면 먼저 UI에서 프로젝트를 생성하면 고유 식별자를 설정하고 HTTP 경로도 설정할 수 있습니다. 프로젝트에 Java 앱을 추가하고 비워 둔 후 Google Cloud SDK 를 사용 하여 명령 행 또는 CI 빌드에서 Spring Boot 앱을 해당 슬롯으로 푸시하십시오.

App Engine Standard에서는 WAR 패키징을 사용해야합니다. 다음 단계 에 따라 App Engine Standard 애플리케이션을 Google Cloud에 배포 하십시오 .

또는 App Engine Flex에서는 app.yaml앱에 필요한 리소스를 설명 하는 파일을 만들어야 합니다. 일반적으로이 파일을에 넣고 src/main/appengine다음 파일과 비슷해야합니다.

service: default

runtime: java
env: flex

runtime_config:
  jdk: openjdk8

handlers:
- url: /.*
  script: this field is required, but ignored

manual_scaling:
  instances: 1

health_check:
  enable_health_check: False

env_variables:
  ENCRYPT_KEY: your_encryption_key_here

다음 예제와 같이 프로젝트 ID를 빌드 구성에 추가하여 앱 (예 : Maven 플러그인 사용)을 배포 할 수 있습니다.

<plugin>
    <groupId>com.google.cloud.tools</groupId>
    <artifactId>appengine-maven-plugin</artifactId>
    <version>1.3.0</version>
    <configuration>
        <project>myproject</project>
    </configuration>
</plugin>

그런 다음로 배포하십시오 mvn appengine:deploy(먼저 인증해야하는 경우 빌드가 실패 함).

6.3. 스프링 부트 애플리케이션 설치

를 사용하여 Spring Boot 응용 프로그램을 실행하는 것 외에도 java -jarUnix 시스템 용으로 완전히 실행 가능한 응용 프로그램을 만들 수도 있습니다. 완전히 실행 항아리는 다른 실행 가능한 바이너리처럼 수행 할 수 있거나 할 수 있습니다 에 등록 init.d하거나systemd . 따라서 일반적인 프로덕션 환경에서 Spring Boot 응용 프로그램을 매우 쉽게 설치하고 관리 할 수 ​​있습니다.

  완전히 실행 가능한 jar는 파일 앞에 추가 스크립트를 포함시켜 작동합니다. 현재 일부 도구는이 형식을 허용하지 않으므로 항상이 기술을 사용하지 못할 수도 있습니다. 예를 들어, jar -xf완전히 실행 가능한 jar 또는 전쟁을 자동 추출하지 못할 수 있습니다. jar 또는 war java -jar을 서블릿 컨테이너 와 함께 실행 하거나 서블릿 컨테이너에 배포 하지 않고 직접 실행하려는 경우에만 jar 또는 war을 완전히 실행 가능하게 만드는 것이 좋습니다 .
  zip64 형식 jar 파일은 완전히 실행 가능하게 만들 수 없습니다. 이렇게하면 jar 파일이 직접 또는로 실행될 때 손상된 것으로보고됩니다 java -jar. 하나 이상의 zip64 형식 중첩 jar을 포함하는 표준 형식 jar 파일은 완전히 실행 가능할 수 있습니다.

Maven으로 '완전히 실행 가능한'jar을 만들려면 다음 플러그인 구성을 사용하십시오.

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <executable>true</executable>
    </configuration>
</plugin>

다음 예제는 동등한 Gradle 구성을 보여줍니다.

bootJar {
    launchScript()
}

그런 다음 입력하여 응용 프로그램을 실행할 수 있습니다 ./my-application.jar( my-application귀하의 유물의 이름입니다). jar을 포함하는 디렉토리는 응용 프로그램의 작업 디렉토리로 사용됩니다.

6.3.1. 지원되는 운영 체제

기본 스크립트는 대부분의 Linux 배포를 지원하며 CentOS 및 Ubuntu에서 테스트되었습니다. OS X 및 FreeBSD와 같은 다른 플랫폼에서는 custom을 사용해야합니다 embeddedLaunchScript.

6.3.2. 유닉스 / 리눅스 서비스

봄 부트 응용 프로그램은 쉽게 중 하나를 사용하여 유닉스 / 리눅스 서비스로 시작할 수 있습니다 init.d또는 systemd.

init.d 서비스로 설치 (시스템 V)

Spring Boot의 Maven 또는 Gradle 플러그인을 구성하여 완전히 실행 가능한 jar 을 생성 하고 custom을 사용하지 않으면 embeddedLaunchScript응용 프로그램을 init.d서비스 로 사용할 수 있습니다 . 이렇게하려면에 항아리를 심볼릭 링크 init.d표준 지원 start, stop, restart, 및 status명령.

이 스크립트는 다음 기능을 지원합니다.

  • jar 파일을 소유 한 사용자로서 서비스를 시작합니다
  • 다음을 사용하여 응용 프로그램의 PID를 추적합니다. /var/run/<appname>/<appname>.pid
  • 콘솔 로그를 /var/log/<appname>.log

에 스프링 부트 애플리케이션이 설치되어 있다고 가정하면 /var/myapp스프링 부트 애플리케이션을 init.d서비스 로 설치하려면 다음과 같이 심볼릭 링크를 만듭니다.

$ sudo ln -s /var/myapp/myapp.jar /etc/init.d/myapp

일단 설치되면 일반적인 방법으로 서비스를 시작하고 중지 할 수 있습니다. 예를 들어, 데비안 기반 시스템에서 다음 명령으로 시스템을 시작할 수 있습니다.

$ 서비스 myapp 시작
  응용 프로그램이 시작되지 않으면 기록 된 로그 파일 /var/log/<appname>.log에서 오류 를 확인하십시오 .

표준 운영 체제 도구를 사용하여 응용 프로그램이 자동으로 시작되도록 플래그를 지정할 수도 있습니다. 예를 들어, 데비안에서는 다음 명령을 사용할 수 있습니다.

$ update-rc.d myapp 기본값은 <priority>
init.d 서비스 보안
  다음은 init.d 서비스로 실행되는 Spring Boot 애플리케이션을 보호하는 방법에 대한 일련의 지침입니다. 응용 프로그램과 응용 프로그램이 실행되는 환경을 강화하기 위해 수행해야하는 모든 항목의 전체 목록이 아닙니다.

root가 init.d 서비스를 시작하는 데 사용되는 경우와 같이 root로 실행될 때 기본 실행 스크립트는 RUN_AS_USER환경 변수에 지정된 사용자로 응용 프로그램을 실행합니다 . 환경 변수를 설정하지 않으면 jar 파일을 소유 한 사용자가 대신 사용됩니다. 당신은 스프링 부트 응용 프로그램을 실행해서는 안됩니다 root때문에, RUN_AS_USER루트 및 응용 프로그램의 jar 파일이 루트가 소유해서는 안됩니다 않을 것입니다. 대신 다음 예제와 같이 특정 사용자를 작성하여 애플리케이션을 실행하고 RUN_AS_USER환경 변수를 설정 하거나 chownjar 파일의 소유자로 사용하십시오.

$ chown bootapp : bootapp your-app.jar

이 경우 기본 실행 스크립트는 응용 프로그램을 bootapp사용자 로 실행합니다 .

  응용 프로그램의 사용자 계정이 손상 될 가능성을 줄이려면 로그인 셸을 사용하지 못하도록 고려해야합니다. 예를 들어 계정 셸을로 설정할 수 있습니다 /usr/sbin/nologin.

또한 응용 프로그램의 jar 파일이 수정되지 않도록 조치를 취해야합니다. 먼저 다음 예제와 같이 권한을 쓸 수없고 소유자 만 읽거나 실행할 수 있도록 권한을 구성하십시오.

$ chmod 500 your-app.jar

둘째, 응용 프로그램 또는 실행중인 계정이 손상된 경우 피해를 제한하기위한 조치를 취해야합니다. 공격자가 액세스 권한을 얻는 경우 jar 파일을 쓰기 가능하게 만들고 내용을 변경할 수 있습니다. 이를 방지하는 한 가지 방법 chattr은 다음 예제와 같이을 사용하여 변경할 수 없도록하는 것입니다 .

$ sudo chattr + i your-app.jar

이렇게하면 루트를 포함한 모든 사용자가 jar을 수정하지 못하게됩니다.

root가 응용 프로그램 서비스를 제어하는 ​​데 사용되고 파일 을 사용하여.conf 시작을 사용자 정의 .conf하는 경우 루트 사용자가 파일을 읽고 평가합니다. 그에 따라 고정되어야합니다. 사용하여 chmod파일이 소유자 만 사용하여 읽을 수 있도록 chown다음 예에서와 같이, 메이크업 루트 소유자에게 :

$ chmod 400 your-app.conf
$ sudo chown root : 루트 your-app.conf
체계적인 서비스로 설치

systemdSystem V init 시스템의 후속 제품이며 현재 많은 최신 Linux 배포판에서 사용되고 있습니다. 로 init.d스크립트를 계속 사용할 수 있지만 'service'스크립트를 systemd사용하여 Spring Boot 응용 프로그램을 시작할 수도 있습니다 systemd.

에 스프링 부트 애플리케이션이 설치되어 있다고 가정하면 /var/myapp스프링 부트 애플리케이션을 systemd서비스 로 설치하려면 이름이 지정된 스크립트를 작성하여 디렉토리에 myapp.service배치하십시오 /etc/systemd/system. 다음 스크립트는 예제를 제공합니다.

[단위]
설명 = myapp
이후 = syslog.target

[서비스]
사용자 = myapp
ExecStart = / var / myapp / myapp.jar
SuccessExitStatus = 143

[설치]
WantedBy = 다중 사용자. 대상
  변화에 기억 Description, User및 ExecStart응용 프로그램에 대한 필드.
  이 ExecStart필드는 스크립트 작업 명령을 선언하지 않으므로 run명령이 기본적으로 사용됩니다.

init.d서비스 로 실행할 때와 달리 응용 프로그램, PID 파일 및 콘솔 로그 파일을 실행하는 사용자는 systemd자체적 으로 관리 되므로 'service'스크립트에서 적절한 필드를 사용하여 구성해야합니다. 자세한 내용은 서비스 유닛 구성 매뉴얼 페이지 를 참조하십시오.

시스템 부트시 응용 프로그램이 자동으로 시작되도록 플래그를 지정하려면 다음 명령을 사용하십시오.

$ systemctl enable myapp.service

자세한 man systemctl내용은 참조하십시오.

시작 스크립트 사용자 정의

Maven 또는 Gradle 플러그인으로 작성된 기본 내장 시작 스크립트는 여러 가지 방법으로 사용자 정의 할 수 있습니다. 대부분의 사람들은 기본 스크립트를 몇 가지 사용자 정의와 함께 사용하면 충분합니다. 필요한 것을 사용자 정의 할 수없는 경우 embeddedLaunchScript옵션을 사용 하여 자신의 파일을 완전히 작성하십시오.

작성 될 때 시작 스크립트 사용자 정의

jar 파일에 기록 될 때 시작 스크립트의 요소를 사용자 정의하는 것이 종종 의미가 있습니다. 예를 들어, init.d 스크립트는 "설명"을 제공 할 수 있습니다. 설명을 미리 알고 있으므로 변경할 필요가 없으므로 jar이 생성 될 때 제공 할 수도 있습니다.

작성된 요소를 사용자 정의하려면 embeddedLaunchScriptPropertiesSpring Boot Maven 플러그인 옵션 또는 propertiesSpring Boot Gradle 플러그인의 특성을 사용하십시오launchScript .

기본 스크립트에서는 다음과 같은 속성 대체가 지원됩니다.

이름 기술 Gradle 기본값 메이븐 기본

mode

스크립트 모드.

auto

auto

initInfoProvides

Provides"INIT 정보"섹션

${task.baseName}

${project.artifactId}

initInfoRequiredStart

Required-Start “INIT INFO”섹션.

$remote_fs $syslog $network

$remote_fs $syslog $network

initInfoRequiredStop

Required-Stop “INIT INFO”섹션.

$remote_fs $syslog $network

$remote_fs $syslog $network

initInfoDefaultStart

Default-Start “INIT INFO”섹션.

2 3 4 5

2 3 4 5

initInfoDefaultStop

Default-Stop “INIT INFO”섹션.

0 1 6

0 1 6

initInfoShortDescription

Short-Description “INIT INFO”섹션.

한 줄짜리 버전 ${project.description}(으로 폴백 ${task.baseName})

${project.name}

initInfoDescription

Description “INIT INFO”섹션.

${project.description}(로 돌아 가기 ${task.baseName})

${project.description}(로 돌아 가기 ${project.name})

initInfoChkconfig

chkconfig “INIT INFO”섹션

2345 99 01

2345 99 01

confFolder

의 기본값 CONF_FOLDER

항아리를 포함하는 폴더

항아리를 포함하는 폴더

inlinedConfScript

기본 실행 스크립트에 인라인되어야하는 파일 스크립트에 대한 참조입니다. JAVA_OPTS외부 구성 파일을로드하기 전과 같은 환경 변수를 설정하는 데 사용할 수 있습니다.

    

logFolder

의 기본값입니다 LOG_FOLDER. init.d서비스 에만 유효

    

logFilename

의 기본값입니다 LOG_FILENAME. init.d서비스 에만 유효

    

pidFolder

의 기본값입니다 PID_FOLDER. init.d서비스 에만 유효

    

pidFilename

의 PID 파일 이름에 대한 기본값입니다 PID_FOLDER. init.d서비스 에만 유효

    

useStartStopDaemon

start-stop-daemon명령을 사용할 수있을 때 프로세스를 제어하는 ​​데 사용해야하는지 여부

true

true

stopWaitTime

STOP_WAIT_TIME초 단위의 기본값 입니다. init.d서비스 에만 유효

60

60
스크립트가 실행될 때 사용자 정의

jar가 작성된 후 사용자 정의해야하는 스크립트 항목의 경우 환경 변수 또는 구성 파일을 사용할 수 있습니다 .

기본 스크립트에서 다음 환경 특성이 지원됩니다.

변하기 쉬운 기술

MODE

"작동 모드". 기본값은 jar의 빌드 방법에 따라 다르지만 일반적으로 auto( 초기 디렉토리라는 디렉토리의 심볼릭 링크인지 확인하여 init 스크립트인지 추측하려고 함 init.d)입니다. 명시 적으로 설정할 수 있습니다 service너무 것을 stop|start|status|restart명령이 작동거나 run당신이 전경에서 스크립트를 실행하려면.

RUN_AS_USER

애플리케이션을 실행하는 데 사용될 사용자입니다. 설정하지 않으면 jar 파일을 소유 한 사용자가 사용됩니다.

USE_START_STOP_DAEMON

start-stop-daemon명령을 사용할 수있을 때 프로세스를 제어하는 ​​데 사용해야하는지 여부 기본값은 true입니다.

PID_FOLDER

pid 폴더의 루트 이름입니다 ( /var/run기본적으로).

LOG_FOLDER

로그 파일을 넣을 폴더의 이름입니다 ( /var/log기본값).

CONF_FOLDER

.conf 파일을 읽을 폴더의 이름입니다 (기본적으로 jar 파일과 동일한 폴더).

LOG_FILENAME

에서 로그 파일의 이름 LOG_FOLDER( <appname>.log기본적으로).

APP_NAME

앱의 이름입니다. jar이 심볼릭 링크에서 실행되면 스크립트는 앱 이름을 추측합니다. 심볼릭 링크가 아니거나 앱 이름을 명시 적으로 설정하려는 경우 유용 할 수 있습니다.

RUN_ARGS

프로그램에 전달할 인수 (Spring Boot 앱)

JAVA_HOME

java실행 파일 의 위치는 PATH기본적 으로를 사용하여 검색 되지만에 실행 파일이있는 경우 명시 적으로 설정할 수 있습니다 $JAVA_HOME/bin/java.

JAVA_OPTS

JVM이 시작될 때 JVM에 전달되는 옵션.

JARFILE

스크립트가 실제로 포함되지 않은 jar을 시작하는 데 사용되는 경우 jar 파일의 명시 적 위치입니다.

DEBUG

비어 있지 않으면 -x쉘 프로세스 에서 플래그를 설정 하여 스크립트에서 논리를 쉽게 볼 수 있습니다.

STOP_WAIT_TIME

종료를 강제 실행하기 전에 응용 프로그램을 중지 할 때까지 대기하는 시간 (초 60)입니다 ( 기본).
  PID_FOLDER, LOG_FOLDER그리고 LOG_FILENAME변수는에만 유효 init.d서비스를 제공합니다. 의 경우 systemd'service'스크립트를 사용하여 동등한 사용자 정의를 수행합니다. 자세한 내용은 서비스 유닛 구성 매뉴얼 페이지 를 참조하십시오.

를 제외 JARFILE하고 APP_NAME, 이전 섹션에서 열거 된 설정은 사용하여 구성 할 수있는 .conf파일. 이 파일은 jar 파일 옆에 있어야하고 이름은 같지만 접미사가 .conf아닌 접미사입니다 .jar. 예를 들어, 이름 지정된 jar 은 다음 예제와 같이 /var/myapp/myapp.jar이름이 지정된 구성 파일을 사용합니다 /var/myapp/myapp.conf.

myapp.conf
JAVA_OPTS = -Xmx1024M
LOG_FOLDER = / custom / log / 폴더
  jar 파일 옆에 구성 파일을 갖고 싶지 않은 경우 CONF_FOLDER환경 변수를 설정하여 구성 파일의 위치를 ​​사용자 정의 할 수 있습니다 .

이 파일을 적절히 보호하는 방법을 배우려면 init.d 서비스 보안을위한 지침을 참조하십시오 .

6.3.3. Microsoft Windows 서비스

를 사용하여 Spring Boot 애플리케이션을 Windows 서비스로 시작할 수 있습니다 winsw.

( 별도로 유지 관리되는 샘플 )에는 Spring Boot 애플리케이션을위한 Windows 서비스를 작성하는 방법이 단계별로 설명되어 있습니다.

6.4. 다음 읽을 거리

아웃 확인 클라우드 파운드리 , Heroku가 , OpenShift 및 Boxfuse의 PaaS를 제공 할 수있는 기능의 종류에 대한 자세한 내용은 웹 사이트를. 이들은 가장 인기있는 Java PaaS 제공 업체 중 4 개에 불과합니다. Spring Boot는 클라우드 기반 배포에 매우 적합하므로 다른 공급자도 자유롭게 고려할 수 있습니다.

다음 섹션에서는 Spring Boot CLI 를 다루거나 계속해서 빌드 도구 플러그인 에 대해 읽을 수있다 .

 

 

Spring Boot Reference Documentation

Phillip Webb, Dave Syer, Josh Long, Stéphane Nicoll, Rob Winch, Andy Wilkinson, Marcel Overdijk, Christian Dupuis, Sébastien Deleuze, Michael Simons, Vedran Pavić, Jay Bryant, Madhura Bhave, Eddú Meléndez, Scott Frederick

2.3.1.RELEASE

Copyright © 2012-2020

Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically.

출처 : https://docs.spring.io/spring-boot/docs/2.3.1.RELEASE/reference/htmlsingle/#deployment

반응형

'IT > SpringBoot' 카테고리의 다른 글

스프링 부트 #8. 빌드 도구  (0) 2020.06.19
스프링 부트 #7. 스프링부트 CLI  (0) 2020.06.19
스프링 부트 #5.7. Auditing  (0) 2020.06.19
스프링 부트 #5.6. 측정 항목  (0) 2020.06.19
스프링 부트 #5.3. 모니터링 및 관리  (0) 2020.06.19

'IT/SpringBoot' Related Articles

티스토리툴바