다운 타임을 최소화하면서 Java 웹 응용 프로그램을 배포하는 모범 사례?


Answers

최신 정보:

이 답변이 처음 작성된 이후로 중단 시간이없는 tomcat에 war 파일을 배포하는 더 좋은 방법이 등장했습니다. 최근 버전의 Tomcat에서는 war 파일 이름에 버전 번호를 포함 할 수 있습니다. 예를 들어 ROOT##001.warROOT##002.war 파일을 동일한 컨텍스트에 동시에 배포 할 수 있습니다. ## 이후의 모든 것은 Tomcat에 의해 버전 번호로 해석되며 컨텍스트 경로의 일부가 아닙니다. Tomcat은 앱의 모든 버전을 실행 상태로 유지하고 새로운 요청 및 세션을 최신 버전으로 제공합니다. 이전 버전의 요청 및 세션은 시작한 버전에서 정상적으로 완료됩니다. 버전 번호 지정은 Tomcat 관리자와 Catalina Ant 작업을 통해 수행 할 수도 있습니다. 더 많은 정보는 here .

원문 답변 :

Rsync는 델타 전송 알고리즘이 파일의 변경 사항을 찾고 작은 압축이 압축되지 않은 파일이므로 결과 압축 된 버전을 크게 변경시킬 수 있으므로 압축 된 파일에 비효율적 인 경향이 있습니다. 이러한 이유 때문에 네트워크 대역폭이 병목 현상이있는 것으로 판명되면 압축 된 버전이 아닌 압축되지 않은 war 파일을 rsync하는 것이 좋습니다.

Tomcat 관리자 응용 프로그램을 사용하여 배포를 수행하는 것이 잘못된 이유는 무엇입니까? 전체 전쟁 파일을 원격 위치에서 Tomcat 관리자 앱에 직접 업로드하지 않으려면 위에서 설명한 이유 때문에 압축을 풀고 프로덕션 상자의 자리 표시 자 위치로 rsync하고 전쟁에 다시 패키지하고 그것을 관리자에게 국지적으로 전달하십시오. Tomcat과 함께 제공되는 멋진 개미 작업이 있습니다. Tomcat 관리자 앱을 사용하여 배포 스크립트를 작성할 수 있습니다.

접근법에 언급되지 않은 또 다른 결함이 있습니다 : 응용 프로그램이 부분적으로 배포되는 동안 (rsync 작업 중에) 응용 프로그램이 변경된 인터페이스가 동기화되지 않은 일관성없는 상태에있을 수 있으며 새롭거나 업데이트 된 종속성이 또한 rsync 작업의 소요 시간에 따라 응용 프로그램이 실제로 여러 번 다시 시작될 수 있습니다. Tomcat에서 변경된 파일 듣기와 다시 시작하기 동작을 끌 수 있고 꺼야한다는 것을 알고 있습니까? 실제로 프로덕션 시스템에는 권장되지 않습니다. Tomcat 관리자 앱을 사용하여 언제든지 수동 또는 개미 스크립팅 된 응용 프로그램 재시작을 할 수 있습니다.

물론, 재시작 중에는 사용자가 응용 프로그램을 사용할 수 없습니다. 그러나 가용성에 대해 우려한다면로드 밸런서 뒤에 여분의 웹 서버가 있어야합니다. 업데이트 된 war 파일을 배포 할 때 배포가 끝날 ​​때까지로드 밸런서가 일시적으로 다른 웹 서버에 모든 요청을 보내도록 할 수 있습니다. 다른 웹 서버에서 린스하고 반복하십시오.

Question

대형 Java 웹 응용 프로그램 (> 100 MB. war)을 배포 할 때 현재 다음 배포 프로세스를 사용하고 있습니다.

  • 응용 프로그램 .war 파일은 개발 컴퓨터에서 로컬로 확장됩니다.
  • 확장 된 응용 프로그램은 개발 컴퓨터에서 실제 환경으로 rsync : ed입니다.
  • 라이브 환경의 app 서버는 rsync 후에 다시 시작됩니다. 이 단계는 꼭 필요한 것은 아니지만 배포시 응용 프로그램 서버를 다시 시작하면 빈번한 클래스 로딩으로 인해 "java.lang.OutOfMemoryError : PermGen space"를 피할 수 있습니다.

이 접근법에 대한 좋은 점 :

  • rsync는 개발 컴퓨터에서 실제 환경으로 보내는 데이터의 양을 최소화합니다. 전체 .war 파일을 업로드하는 데는 10 분이 걸리지 만 rsync에는 몇 초가 걸립니다.

이 접근법에 대한 나쁜 점 :

  • rsync가 실행되는 동안 파일이 업데이트되기 때문에 응용 프로그램 컨텍스트가 다시 시작됩니다. 이상적으로 rsync가 완료된 후에 다시 시작해야하며, 아직 실행 중이 아닌 경우 다시 시작해야합니다.
  • 앱 서버를 다시 시작하면 약 2 분의 가동 중지 시간이 발생합니다.

다음 속성을 사용하여 배포 프로세스를 찾고 싶습니다.

  • 배포 프로세스 중 중단 시간 최소화.
  • 데이터 업로드에 소요 된 최소 시간.
  • 배포 프로세스가 응용 프로그램 서버마다 다르면 응용 프로그램 서버는 오픈 소스 여야합니다.

문제:

  • 명시된 요구 사항이 주어지면 최적의 배포 프로세스는 무엇입니까?



몇 가지 매개 변수를 사용하고 서버간에 파일을 rsync하는 bash 스크립트를 작성했습니다. 대규모 아카이브의 경우 rsync 전송 속도가 빨라집니다.

https://gist.github.com/3985742







나의 조언은 rsync를 분해 된 버전으로 사용하지만 war 파일을 배포하는 것이다.

  1. 라이브 환경에 임시 폴더를 생성하여 웹 응용 프로그램의 버전을 압축하십시오.
  2. Rsync 버전이 폭발했습니다.
  3. 성공적인 rsync 후에 라이브 환경 컴퓨터의 임시 폴더에 war 파일을 생성하십시오.
  4. 서버 배포 디렉토리의 오래된 전쟁을 임시 폴더의 새로운 전쟁으로 교체하십시오.

Tomcat을 기반으로하는 JBoss 컨테이너에서는 이전 작업을 새로운 것으로 대체하는 것이 좋습니다. 이는 원자력과 빠른 작업이기 때문에 배포자가 전체 응용 프로그램을 시작할 때 배포 된 상태로 유지됩니다.




이 질문에 대한 답변이 맞는지 잘 모르겠습니다 만, 제가 한 몇 가지 프로젝트에서 사용하거나 만나는 배포 프로세스를 공유 할 것입니다.

너와 비슷하게, 나는 전전 재배치 또는 업데이트를 상기 한 적이 없다. 대부분의 경우, 업데이트는 몇 개의 JSP 파일, 어쩌면 라이브러리, 일부 클래스 파일로 제한됩니다. 영향을받는 아티팩트는 무엇인지 관리하고 결정할 수 있으며 대개 업데이트 스크립트와 함께 zip 파일로 패키지를 패키징했습니다. 업데이트 스크립트를 실행합니다. 스크립트는 다음을 수행합니다.

  • 덮어 쓸 파일을 오늘의 날짜와 시간이 표시된 폴더로 백업하십시오.
  • 내 파일 패키지 풀기
  • 응용 프로그램 서버 중지
  • 파일 이동
  • 응용 프로그램 서버 시작

가동 중단 시간이 염려되는 경우 대개 내 프로젝트는 상태를 공유하지 않고 고정 세션 라우팅을 제공하는 라우터를 사용하는 경우에도 대개 HA입니다.

내가 궁금해하는 또 다른 사항은 rsync가 필요한 이유 일 것입니다. 라이브와 함께 델타 검사를 수행하지 않고 스테이징 / 개발 환경에서 필요한 변경 사항을 파악하여 필요한 변경 사항을 파악할 수 있어야합니다. 대부분의 경우 데이터베이스 연결, smtp 서버 등과 같이 프로덕션 서버에서 사용하는 리소스를 정의하는 특정 속성 파일과 같이 파일을 무시하도록 rsync를 조정해야합니다.

이것이 도움이되기를 바랍니다.




초기 컨텍스트가 다시 시작됩니다. 모든 컨테이너에는 클래스 파일 또는 정적 자원 변경시 자동 재배치를 비활성화하는 구성 옵션이 있습니다. web.xml 변경시 자동 재배치를 비활성화 할 수 없으므로이 파일이 마지막으로 업데이트됩니다. 자동 배포를 사용하지 않도록 설정하고 마지막으로 web.xml을 업데이트하면 전체 업데이트 후에 컨텍스트가 다시 시작됩니다.







Tomcat 7에는이 사용 사례를 위해 설계된 " 병렬 배포 "라는 멋진 기능이 있습니다.

요점은 .war 파일을 webapps / 또는 symlinked 디렉토리 바로 아래에있는 디렉토리로 확장한다는 것입니다. 응용 프로그램의 후속 버전은 app##version 이라는 디렉토리에 있습니다 (예 : myapp##001myapp##002 . Tomcat은 기존 버전의 기존 세션과 새 버전의 새 세션을 처리합니다.

이 잡기는 PermGen 유출에 매우 조심해야한다는 것입니다. PermGen을 많이 사용하는 Grails의 경우 특히 그렇습니다. VisualVM은 당신의 친구입니다.




rsync에 대한 추출 된 전쟁에 대한 접근 방식은 꽤 좋으며 프로덕션 서버에서 핫 전개를 사용해서는 안되기 때문에 다시 시작해야합니다. 따라서 유일한 단점은 서버를 다시 시작해야하는 다운 타임입니다.

나는 당신의 애플리케이션의 모든 상태가 데이터베이스에 있다고 가정하므로 다른 사용자가 다른 애플리케이션 서버 인스턴스에있는 동안 한 애플리케이션 서버 인스턴스에서 작업하는 일부 사용자에게는 아무런 문제가 없다고 가정합니다. 그렇다면,

두 개의 응용 프로그램 서버 실행 : 번째 응용 프로그램 서버 (다른 TCP 포트에서 수신 대기)를 시작하고 거기에 응용 프로그램을 배포하십시오. 배포 후 두 번째 응용 프로그램 서버를 가리 키도록 Apache httpd의 구성 (mod_jk 또는 mod_proxy)을 업데이트합니다. 정상적으로 Apache httpd 프로세스를 다시 시작합니다. 이렇게하면 다운 타임이 발생하지 않고 새로운 사용자 및 요청이 자동으로 새 앱 서버로 리디렉션됩니다.

앱 서버의 클러스터링 및 세션 복제 지원을 사용할 수 있다면 두 번째 앱 서버가 시작하자 마자 즉시 다시 동기화되므로 현재 로그인 한 사용자는 원활하게 진행됩니다. 그런 다음 첫 번째 서버에 대한 액세스가 없으면 종료하십시오.




Related