먼저 정상적으로 배포 서버에 jenkins 서버가 파일을 보내준 경우 아래처럼 확인할 수 있다.
포스팅 순서대로 따라왔다면 아마 빌드가 잘 수행되지 않았을 텐데, 해당 내용에 대해서는 아래에서 설명함
수행한 빌드를 클릭해서 상세 Console Output을 볼 수 있다.
하필 오래된 빌드 삭제 옵션으로 최근 빌드 3개만 저장하도록 설정해놔서 많은 오류메세지들이 사라졌지만, 잘 모르는 사람이 보더라도 대충 오류나는 곳을 파악할 수 있다.
오류메세지를 하나 예로 들어 설명함
위의 오류메세지는 ssh agent가 배포서버에 접속은 했으나, scp 명령중 젠킨스가 구동되는 vm에서 내가 지정한 파일을 못찾는다는 오류이다. 디렉토리를 잘 적었는지 확인해 볼 필요가 있다.
아까 포스팅 순서대로 진행했을 경우의 발생된 오류는 배포 서버에 해당 디렉토리가 없다는 오류가 발생했을 것이다.
그럴 만 한게 배포서버의 ec2 instance를 생성만했지 어떤 디렉토리를 만들어주거나 하지 않았기 때문이다.
아래 사진처럼 본인의 배포서버 ec2 instance내에 pipeline에서 복사될 디렉토리로 지정한 디렉토리가 존재해야하므로, 디렉토리를 생성한다.
나의 경우는 hh/backend 디렉토리를 생성해야한다.
이렇게 배포 서버에 jar 파일과 함께 전송된 두 개의 파일을 살펴보자
run-server.service
# /etc/systemd/system/your-service-name.service
[Unit]
Description=hanghaero service
After=syslog.target
[Service]
Environment="SPRING_PROFILES_ACTIVE=deploy"
ExecStart=/usr/bin/java -jar /home/ubuntu/hh/backend/hanghaero-0.0.1-SNAPSHOT.jar
SuccessExitStatus=143
[Install]
WantedBy=multi-user.target
리눅스를 조금이라도 만져봤다면, systemctl 명령어로 방화벽을 켜고 끄거나 하는 등의 작업을 해봤을 텐데, 이렇게 리눅스 환경의 공식 시스템처럼 우리 스프링부트 jar 파일을 실행시킬것이다.
코드를 살펴보면, 환경변수로 deploy 프로필로 스프링부트를 실행한다고 하고있다.
수동으로 위 서비스를 동작시키려면
- /etc/systemd/system/ 디렉토리에 저 파일을 이동시키고,
- 데몬을 재시작하고,
- 서비스를 활성화하고,
- 시작해야한다.
이과정을 직접 수행하기 보단, shell 파일을 만들어서 자동화하는 게 편하다.
따라서 run-server.service 파일과 같은 디렉토리에 존재할 run-server.sh 파일을 생성하고 아래와같이 작성했다.
#!/bin/bash
SERVICE_NAME="run-server.service"
# 1. 서비스 파일을 /etc/systemd/system 경로로 복사
sudo cp run-server.service /etc/systemd/system/
# 2. systemd 데몬 재시작, enable, start 명령 실행
sudo systemctl daemon-reload
# 3. 서비스 상태 확인
if sudo systemctl is-active --quiet $SERVICE_NAME; then
echo "Stopping the running $SERVICE_NAME..."
sudo systemctl stop $SERVICE_NAME
fi
# 4. 서비스 시작
echo "Starting $SERVICE_NAME..."
sudo systemctl enable $SERVICE_NAME
sudo systemctl start $SERVICE_NAME
이제 run-server.sh, run-server.service, jar파일 3개가 있으면 jenkins에서 ssh접속으로 run-server.sh를 실행시키기만 하면 된다
먼저 정상적으로 배포 서버에 jenkins 서버가 파일을 보내준 경우 아래처럼 확인할 수 있다.
포스팅 순서대로 따라왔다면 아마 빌드가 잘 수행되지 않았을 텐데, 해당 내용에 대해서는 아래에서 설명함
수행한 빌드를 클릭해서 상세 Console Output을 볼 수 있다.
하필 오래된 빌드 삭제 옵션으로 최근 빌드 3개만 저장하도록 설정해놔서 많은 오류메세지들이 사라졌지만, 잘 모르는 사람이 보더라도 대충 오류나는 곳을 파악할 수 있다.
오류메세지를 하나 예로 들어 설명함
위의 오류메세지는 ssh agent가 배포서버에 접속은 했으나, scp 명령중 젠킨스가 구동되는 vm에서 내가 지정한 파일을 못찾는다는 오류이다. 디렉토리를 잘 적었는지 확인해 볼 필요가 있다.
아까 포스팅 순서대로 진행했을 경우의 발생된 오류는 배포 서버에 해당 디렉토리가 없다는 오류가 발생했을 것이다.
그럴 만 한게 배포서버의 ec2 instance를 생성만했지 어떤 디렉토리를 만들어주거나 하지 않았기 때문이다.
아래 사진처럼 본인의 배포서버 ec2 instance내에 pipeline에서 복사될 디렉토리로 지정한 디렉토리가 존재해야하므로, 디렉토리를 생성한다.
나의 경우는 hh/backend 디렉토리를 생성해야한다.
이렇게 배포 서버에 jar 파일과 함께 전송된 두 개의 파일을 살펴보자
run-server.service
# /etc/systemd/system/your-service-name.service
[Unit]
Description=hanghaero service
After=syslog.target
[Service]
Environment="SPRING_PROFILES_ACTIVE=deploy"
ExecStart=/usr/bin/java -jar /home/ubuntu/hh/backend/hanghaero-0.0.1-SNAPSHOT.jar
SuccessExitStatus=143
[Install]
WantedBy=multi-user.target
리눅스를 조금이라도 만져봤다면, systemctl 명령어로 방화벽을 켜고 끄거나 하는 등의 작업을 해봤을 텐데, 이렇게 리눅스 환경의 공식 시스템처럼 우리 스프링부트 jar 파일을 실행시킬것이다.
코드를 살펴보면, 환경변수로 deploy 프로필로 스프링부트를 실행한다고 하고있다.
수동으로 위 서비스를 동작시키려면
- /etc/systemd/system/ 디렉토리에 저 파일을 이동시키고,
- 데몬을 재시작하고,
- 서비스를 활성화하고,
- 시작해야한다.
이과정을 직접 수행하기 보단, shell 파일을 만들어서 자동화하는 게 편하다.
따라서 run-server.service 파일과 같은 디렉토리에 존재할 run-server.sh 파일을 생성하고 아래와같이 작성했다.
#!/bin/bash
SERVICE_NAME="run-server.service"
# 1. 서비스 파일을 /etc/systemd/system 경로로 복사
sudo cp run-server.service /etc/systemd/system/
# 2. systemd 데몬 재시작, enable, start 명령 실행
sudo systemctl daemon-reload
# 3. 서비스 상태 확인
if sudo systemctl is-active --quiet $SERVICE_NAME; then
echo "Stopping the running $SERVICE_NAME..."
sudo systemctl stop $SERVICE_NAME
fi
# 4. 서비스 시작
echo "Starting $SERVICE_NAME..."
sudo systemctl enable $SERVICE_NAME
sudo systemctl start $SERVICE_NAME
이제 run-server.sh, run-server.service, jar파일 3개가 있으면 jenkins에서 ssh접속으로 run-server.sh를 실행시키기만 하면 된다
