Jenkins 플러스 Shell 은 가장 간단 한 지속 적 인 배 치 를 실현 합 니 다.

더 읽 기
참조 점프 링크:
http://ju.outofmemory.cn/entry/29263
 
 
 
 
대량의 지속 적 인 통합 과 관련 된 서적 과 문서 에서 대체적으로 지속 적 인 배치 라 는 절 차 를 언급 했다.그러나 구체 적 으로 어떻게 실현 하 는 지 통행 하 는 방법 이 없다.전형 적 인 자바 웹 응용 에 있어 대체적으로 두 가지 방향 이 있다.하 나 는 웹 용기(예 를 들 어 Tomcat,JBoss)를 통 해 제공 하 는 인터페이스 배치 이다.이 분야 의 대 표 는 바로 Cargo 이다.그러나그 단점 은 설정 이 복잡 하고 불안정 하 다 는 것 입 니 다.제 경험 은 여러 번 배치 한 후에 용기 의 JVM 이 메모리 가 넘 칩 니 다.물론 이것 은 구체 적 인 용기 와 관련 이 있 습 니 다.몇 번 배치 한 후에 야 넘 치고 웹 응용 프로그램의 크기 도 봐 야 합 니 다.
두 번 째 는 처음에 더 복잡 해 보 이 는 방법 은 용기 업 데 이 트 를 중단 하고 웹 애플 리 케 이 션 을 업데이트 한 다음 에 용 기 를 시작 하 는 것 입 니 다.사실 셸 을 조금 알 면 이런 방법 은 매우 간단 하고 안정 적 입 니 다.매번 JVM 프로 세 스 를 직접 죽 일 때마다 메모리 가 넘 치 는 문 제 를 피 할 수 있 기 때 문 입 니 다.다음은 구체 적 인 절차 입 니 다.Jenkins 와 Tomcat 를 예 로 들 면:
1.Jenkins 의 Build Job 을 설정 한 후 Archive war 파일 을 준비 합 니 다.
이렇게 빌 드 가 끝 날 때마다 해당 하 는 Job 으로 갑 니 다.예 를 들 어:http://10.12.136.115:8080/job/fileserver/lastSuccessfulBuild/artifact/my-app/target/my-app.war。
또 다른 방법 은 Jenkins Build 가 끝 난 후에 바로 deploy 를 Nexus 로 보 낸 다음 에 Nexus 에서 직접 얻 을 수 있 습 니 다.자세 한 내용 은 설명 하지 않 겠 습 니 다.
2.배포 스 크 립 트 작성 및 테스트
스 크 립 트 의 기본 적 인 사 고 는 용기 가 실행 되 고 있 는 지,있 으 면 kill 을 제거 한 다음 에 Jenkins/Nexus 에서 최신 war 파일 을 다운로드 하여 오래된 것 을 교체 하고 용 기 를 시작 하 는 것 입 니 다.예 를 들 어:

#!/bin/bashexport JAVA_HOME=/usr/java

tomcat_pid=`/usr/sbin/lsof -n -P -t -i :9009`[-n "$tomcat_pid"]&& kill -9 $tomcat_pid

cd /home/admin/
mv myapp.war myapp.war.bak
wget http://10.12.136.115:8080/job/fileserver/lastSuccessfulBuild/artifact/my-app/target/my-app.war
rm /home/admin/apache-tomcat-7.0.40/webapps/myapp.war
rm -fr /home/admin/apache-tomcat-7.0.40/webapps/myapp
cp myapp.war /home/admin/apache-tomcat-7.0.40/webapps/myapp.war

cd /home/admin/apache-tomcat-7.0.40/bin/./startup.sh

왜 export JAVAHOME 환경 변 수 는 나중에 설명 합 니 다.이 곳 의 lsof 명령 은 tomcat 가 감청 한 포트 에 따라 프로 세 스 ID 를 가 져 와 죽 이 고 다른 명령 은 기본적으로 한눈 에 알 수 있 습 니 다.배치 기계 에서 이 스 크 립 트 를 실행 하여 작업 할 수 있 도록 한 다음 원본 창고 에 제출 합 니 다.
3.Jenkins Job 을 만들어 배 치 를 전문 으로 한다.
freestyle Job 을 만 들 고 scm 등 설정 도 그대로 입 니 다.물론 스 크 립 트 는 scm 창고 에 배치 해 야 합 니 다.그리고 Jenkins 의 Build 설정 은 다음 과 같 습 니 다.
이 명령 은 ssh 를 통 해 배치 기기 에 원 격 으로 로그 인하 여 배치 스 크 립 트 deploy.sh 를 실행 하 는 것 입 니 다.-x 매개 변 수 는 셸 이 모든 줄 에서 실행 할 명령 을 인쇄 하도록 합 니 다.-s 는 표준 입력 에서 실행 할 스 크 립 트 를 읽 는 것 을 표시 합 니 다.여기 서 deploy.sh 로 방향 을 바 꾸 었 습 니 다.(어떻게 ssh key 를 설정 하여 비밀번호 로그 인 을 면제 합 니까?
주의해 야 할 것 은 이러한 원 격 으로 스 크 립 트 를 실행 하 는 방식 은 비 상호작용 셸 에 속 하 며~/.bash 와 같은 트리거 가 발생 하지 않 습 니 다.profile 같은 파일 을 불 러 옵 니 다.이것 도 제 가 왜 Shell 스 크 립 트 에서 export JAVAHOME,이 환경 변 수 는 원래~/.bashprofile 의,물론,당신 도 직접 source 전체~/.bashprofile。
마지막 으로 Jenkins 의 Pipeline 을 통 해 my-app Build 가 성공 하면 deploy 라 는 작업 을 자동 으로 실행 하여 자동 으로 지속 할 수 있 습 니 다.
여러 개의 애플 리 케 이 션 이 있다 면 비슷 한 방법 으로 여러 개의 Jenkins Job 을 만 들 면 됩 니 다.Shell 스 크 립 트 는 자신 이 쓴 것 이기 때문에 어떤 용기 든 OK 입 니 다.포기 한 것 은 용 기 를 다시 시작 해 야 하기 때문에 용기 인 터 페 이 스 를 통 해 직접 배치 하 는 것 보다 시간 이 조금 걸 리 지만 안정성 이 크게 향상 되 고 배치 가 간소화 되 는 것 을 고려 하면 가치 가 있다 고 생각 합 니 다.
칭찬 하 다
지속 집적
  jenkins
  shell
  ssh