포함 된 컨테이너가있는 실행 가능한 jar와 전쟁 파일 배포에 대한 조언


89

자바 웹 애플리케이션을 war 파일 (또는 ear 파일)의 형태로 자바 서블릿 컨테이너 (또는 애플리케이션 서버)에 배포하는 것에서 벗어나 대신 애플리케이션을 실행 가능한 jar로 패키징하는 자바 공간의 현재 추세가있는 것 같습니다. jetty와 같은 임베디드 서블릿 / HTTP 서버. 그리고 이것은 애플리케이션이 최종 사용자에게 전달되는 방식보다 새로운 프레임 워크가 새로운 애플리케이션을 개발하고 배포하는 방식에 영향을 미치는 방식에 더 가깝다는 것을 의미합니다 (예를 들어 Jenkins가 임베디드 컨테이너를 사용하는 이유를 알 수 있습니다. ). 실행 가능한 jar 옵션을 채택한 프레임 워크의 예 : Dropwizard , Spring BootPlay (서블릿 컨테이너에서 실행되지 않지만 HTTP 서버가 포함되어 있음).

제 질문은 (지금까지 대부분 Struts2) 애플리케이션을 단일 tomcat 애플리케이션 서버에 배포 한 환경에서 온 것입니다. 임베디드 컨테이너 접근 방식을 사용할 계획이라면 어떤 변경, 모범 사례 또는 고려 사항이 필요합니까? ? 현재 우리는 단일 tomcat 서버에서 약 10 개의 자체 개발 한 애플리케이션을 실행하고 있으며 이러한 작은 애플리케이션의 경우 리소스를 공유하고 하나의 서버에서 관리 할 수있는 기능이 좋습니다. 당사의 응용 프로그램은 최종 사용자에게 배포되어 환경 내에서 실행되도록 설계되지 않았습니다. 그러나 새로운 Java 프레임 워크를 활용하기로 결정한 경우이 접근 방식이 변경되어야합니까? 클라우드 배포 (예 : Heroku)의 사용이 증가하면서 실행 가능한 jar 로의 전환이 촉진 되었습니까?

단일 애플리케이션 서버에서 기존의 war 파일 배포와 비교하여 Play 스타일의 배포로 여러 애플리케이션을 관리 한 경험이 있다면 통찰력을 공유하십시오.

답변:


81

흥미로운 질문입니다. 이것은 주제에 대한 나의 견해이므로 모든 것을 소금으로 가져 가십시오. 서블릿 컨테이너와 임베디드 서버를 모두 사용하여 때때로 애플리케이션을 배포하고 관리했습니다. 서블릿 컨테이너를 사용하는 데에는 여전히 많은 좋은 이유가 있다고 확신하지만 오늘날 왜 덜 인기가 있는지에 초점을 맞추려고합니다.

짧은 버전 : 서블릿 컨테이너는 단일 호스트에서 여러 애플리케이션을 관리하는 데 유용하지만 하나의 단일 애플리케이션 만 관리하는 데는 그리 유용하지 않은 것 같습니다. 클라우드 환경에서는 가상 머신 당 단일 애플리케이션이 선호되고 더 일반적으로 보입니다. 최신 프레임 워크는 클라우드와 호환되기를 원하므로 임베디드 서버로 전환합니다.


그래서 클라우드 서비스가 서블릿 컨테이너를 버리는 주된 이유라고 생각합니다. 서블릿 컨테이너를 사용하여 애플리케이션을 관리하는 것처럼 클라우드 서비스를 사용하면 가상 머신, 인스턴스, 데이터 스토리지 등을 관리 할 수 ​​있습니다. 이것은 더 복잡해 보이지만 클라우드 환경에서는 단일 앱 시스템으로 전환되었습니다. 이것은처럼 자주 전체 시스템을 치료할 수 있다는 것을 의미 응용 프로그램입니다. 각 응용 프로그램은 적절한 크기의 컴퓨터에서 실행됩니다. 클라우드 인스턴스는 언제든지 팝업되고 사라질 수 있으므로 확장에 적합합니다. 애플리케이션에 더 많은 리소스가 필요한 경우 더 많은 인스턴스를 만듭니다.

반면에 전용 서버는 일반적으로 강력하지만 크기가 고정되어 있으므로 단일 시스템에서 여러 응용 프로그램을 실행하여 리소스 사용을 극대화 할 수 있습니다. 각각 고유 한 구성, 웹 서버, 경로 및 연결 등을 사용하여 수십 개의 애플리케이션을 관리하는 것은 재미 있지 않으므로 서블릿 컨테이너를 사용하면 모든 것을 관리 할 수 ​​있고 제정신이 유지하는 데 도움이됩니다. 하지만 확장하기가 더 어렵습니다. 클라우드의 서블릿 컨테이너는 그다지 유용하지 않은 것 같습니다. 단일 애플리케이션 만 관리하므로 많은 가치를 제공하지 않고 각각의 작은 인스턴스에 대해 설정해야합니다.

또한 구름은 멋지고 비 구름은 지루합니다 (여전히 과대 광고를 믿는 경우). 많은 프레임 워크는 기본적으로 확장 가능하므로 클라우드에 쉽게 배포 할 수 있습니다. 임베디드 서버는 배포 및 실행이 빠르기 때문에 합리적인 솔루션처럼 보입니다. 서블릿 컨테이너는 일반적으로 여전히 지원되지만 더 복잡한 설정이 필요합니다.

기타 사항 :

  • 임베디드 서버 는 프레임 워크에 최적화되거나 프레임 워크 도구 (예 : 플레이 콘솔)와 더 잘 통합 될 있습니다.
  • 모든 클라우드 환경에 사용자 정의 가능한 머신 이미지가 제공되는 것은 아닙니다. 서블릿 컨테이너를 다운로드하고 설정하기 위해 초기화 스크립트를 작성하는 대신 클라우드 애플리케이션 배포를위한 전용 소프트웨어를 사용하는 것이 훨씬 간단합니다.
  • 앱을 몇 번 재배포 할 때마다 perm gen 공간 오류가 발생 하지 않는 Tomcat 설정을 아직 ​​찾지 못했습니다 . 다운 타임없이 스테이징 인스턴스와 프로덕션 인스턴스 사이를 거의 즉시 전환 할 수 있다면 임베디드 서버를 (다시) 시작하는 데 시간이 조금 더 걸리는 것은 문제가되지 않습니다.
  • 질문에서 이미 언급했듯이 최종 사용자가 응용 프로그램을 실행하는 것이 매우 편리합니다.
  • 임베디드 서버는 이식 가능하고 개발에 편리합니다. 오늘날 모든 것이 빠르며 프로토 타입과 MVP를 최대한 빨리 만들고 제공해야합니다. 어느 누구도 모든 개발자를 위해 환경을 설정하는 데 너무 많은 시간을 소비하고 싶지 않습니다.

1
답변 해주셔서 감사합니다. 좋은 점수를 받았습니다. 클라우드가 원동력입니다! 우리 상황에서는 애플리케이션을 Google App Engine (Platform as a Service)으로 배포하는 것보다 Amazon Web Services 모델 (Infrastructure as a Service)에 따라 클라우드 서버를 소유하는 것이 더 편하다고 생각합니다. 생각의 오래된 학교. 요점 : 서비스 방식의 플랫폼에서 클라우드를 활용할 계획이 없다면 전쟁 배포는 단일 서버에서 여러 독립형 자바 웹 애플리케이션을 관리하는 것보다 갈 길입니다. 입력 해 주셔서 다시 한 번 감사드립니다.
Brice Roncace 2014 년

3
단 2cc : 프록시로 가벼운 HTTP 서버를 사용하여 단일 머신에서 여러 jar-apps 를 실행할 수 있습니다. 대규모 트래픽을 계획 할 때 사용합니다 (성능이 더 우수하고 기본 앱을 통한 정적 리소스의 경우에도 모든 단일 요청 처리).
biesior 2014 년
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.