배포 수업

Jung·2021년 5월 6일

수업

목록 보기

19/20

aws 비용관리 - cost explorer로 비용 볼 수 있다.

EC2 만들기

단계6: 보안그룹 구성에서
사용자 지정 TCP - 8080 열기
::/0 any address의 ipv6 표기법이다.

git branch
./gradlew build #jar build되나? fail한다.
javac -version # 15버전이다.

update 내부망을 사용하고 패키지를 가져올수있다.

brew install sdkman

oracle java 깔면 복잡하므로 openjdk 깔기.
sudo apt install openjdk-8 식으로 깔면된다.
javac -version #으로 버전확인하기. 원랜 --version이 컨벤션
git clone https://github.com~
ls로 목록확인하고
./gradlw run #으로 레포를 가져와 실행한다.
그런데 ec2는 작은 인스턴스라 여기서 빌드해서 실행하면 서버가 죽을 때가 있다는 단점이 있다. 실제 회사는 빌드 서버가 따로 있어서 빌드 결과인 artifact를 서버에 보내는 방식으로 배포한다. 빌드서버와 배포 도구가 따로있기 떄문에 aws에 개발자 도구 - code artifact, codeBuild, codeDeploy등을 자동으로 할 수 있다. 빌드 서버에서 단위 테스트 다 한다. jenkins를 많이 쓴다.
이번 경우에는 로컬에서 빌드해서 결과물인 jar파일을 서버로 보내 서버에서 실행해주면 된다.

./gradlew run이 실패했다.
./gradlew bootrun 으로 해본다. 스프링부트 플젝인게 문제원인일수도있다.

우리가 t시리즈 인스턴스를 사용하고 있다. 인스턴스유형이 t4g nano를 하는데, 메모리가 500메가라 빌드될리가 없다. java는 메모리가 큰게좋아서 2기가가 적당하다. 그리고 다른 문제는 빌드를 자꾸하면 됐다 안됐다한다. 모니터링탭을 보면 클라우드워치라는 모니터링 도구이다. cpu사용률이 높은데, cpu크레딧이 있는데 다른 인스턴스엔 없는데 인스턴스 중 t로 시작하는 애들만 있다. 인스턴스 안 사용할 때 크레딧이 쌓인다. 쌓인 크레딧 개수만큼 1분당 cpu를 100%사용할 수 있다. t2.nano는 누적 가능한 최대 크레딧이 72라서 하루에 72분만 풀파워로 쓸수있고, 그 이후에는 5%로 돌아간다.(사실상 ssh접속도 제대로 안되는 수준) 시간당 지급되는 cpu 크레딧이 3이기 때문에 5%로 돌아가는 것이다. 싼 인스턴스유형들은 한대의 서버를 여러 명이 사용하기 때문에 이렇다.
특히 테스트는 복잡하기 때문에 gradle build -x test로 테스트 없이 빌드할 수도있다. 빌드할 때 원래 테스트 해주는 것이 맞는데 메모리 부족 문제 때문에 이렇게한다.
빌드 작업은 cpu를 100%쓴다. 빌드는 전부 cpu bound job이다. 평소 잘 돌아가다 빌드 몇번으로 서버 죽는 것이 이러한 이유이다. 따라서 로컬에서 빌드해서 jar파일만 보내줘서 실행하면, 싸구려 인스턴스로도 버틸수있다.

아무튼 t4g.nano에서 좀 큰 서버로 바꾼 후에 다시 실습 진행한다.
바뀐 public ipv4주소 복사해서 ssh -i 비번파일 ip주소로 접속한다. 플젝 파일로 들어간다.
./gradlw bootrun

또는
./gradlw build jar 로 할 수 있다.
./gradlw build 하면 build/libs에 snapshot이 생긴다.
java -jar build/libs/스냅샷파일

아무튼 이런 과정을 스크립트로 짤수있다.
vi build.sh
which bash
which bash >> build.sh
로 배시를 이용해서 스크립트를 짜겠다는 말이다. \
tmux는 가상 터미널이다. 창 두개를 왔다갔다할 수 있다. 가상 터미널에서 프로젝트 디렉토리 등을 확인하며 0번 원본 터미널에서 위에서 했던 배포 작업 명령어들을 다 써준다.

배포 브랜치 0505를 만든다.
gloga로 브랜치 그림 확인하기
git reflog를 보면 로컬 커밋이 확인할수있다.
git branch -f 브랜치이름 커밋주소 면 강제로 브랜치를 커밋으로 옮겨준다.
우리가 커밋하면 무조건 로컬에 남겨져있다. reflog명령어로 살릴 수 있다.

간단한 빌드 스크립트이다.
git branch git fetch하고 git checkout0505로 원하는 브랜치를 체크아웃한다. 한번이렇게 체크아웃하면 유지되기에 스크립트에 브랜치 체크아웃하는 내용을 포함할 필요는 없다.

chmod해주고 ..
./build.sh 실행해준다.

문제점들

스크립트 상으로, 이미 돌아가고 있는 Spring 앱을 kill 하는 것도 추가하면 좋을 것 같아요. 포트 충돌 대비해서.

우리 자바 프로세스는 터미널의 ssh의 하위 프로세스이다. 터미널 닫으면 프로세스 종료된다. 터미널이 종료될때 sighup같은 시그널이 발생한다. 이거하면 아까처럼 죽어야하는데 우리의 경우엔 tmux로 터미널을 두개 열어놔서 안죽는다.
tmux ls로 가상 터미널이 보인다. tmux a 하면 접속 전 상태로 돌아간다.

아무튼 일반

honux77/practice/wiki

&붙이면 백그라운드 프로세스가 된다. 백그라운드란 것은 일을 뒤쪽에서, 음지에서 일하는 것이다.
백그라운드 프로세스
터미널을 끄면 sighup이 발생한다. sigh란 것은 프로세스끼리의 통신이다. 눈치를 줬다고 해서 행동을 강요하진 않느다. 저 터미널인데 먼저 죽어요~ 하면 다른 프로세스들이 무엇을 할지 정의되어있지 않지만 시그널을 받으면 디폴트 액션이 죽는 것이라, 자녀 프로ㅔㅅ스들이 다 죽는다. 그런데 사용자 정의 액션, 무시하도록 프로세스 액션을 정의할 수 있다. 백그라운드 프로세스는 기본저긍로 sighup을 무시하도록 되어있다.

ps 로 돌아가는 프로세스를 볼 수 있다.
ps -aux | grep java

터미널을 끄면 원래 자동으로 죽는데 백그라운드 프로세스로 고치면 안 죽는다. 스탠다드 아웃풋 출력을 해주는데 리다이렉션을 해주고 있다. 어디다 출력을 할지 모르니까.

표준 출력만 리다이렉트 해준다. 기존 로그에 추가해준다. 로그도 쓰기 위해 2>&1와 같은 것을 해준다.

프로세스 죽이려면 ps -ef | grep java로 확인한 후에
kill로 프로세스에 시그널을 보내야한다.
kill 1417 하면 시그텀이라고 하는 시그널이 된다. 시그텀은 정중히 죄송한데 죽어달라는 것이다. 그런데 kill -9 1417 과 같이 -9로 하면 그냥 죽어! 하는 것이다. -9없이 하면 유연을 남기고 죽을 수 있는데, -9를 붙이면 바로 죽어버린다.
그런데 프로세스 번호를 어떻게 찾을 것인가, ps -ef | grep qna로 1417번 프로세스를 찾아야한다.
jps 명령어를 이용하면
jps | grep qna java 프로세스를 보는 명령이다. qna가 들어가는? 자바프로젝트만 담긴다.

jps | grep qna | cut -d " " -f1 위에서 걸러낸 qna 자바 프로세스 중에서도, 첫번째 아규먼트를 받을 수 있다. 1417 얘를 받아서 kill할 수 있다. 아규먼트를 받아서 KK= jps | grep qna | cut -d " " -f1
kill $KK

BOOT뒤에 공백없애야한다. 만약에 돌아가고 있는 프로세스가 없다면 kill $BOOT가 kill 만되어버려서 문제 발생 가능하다.

tmp
git stash pop해서 현재 브랜치로 체크아웃할 때 stash한 것 가져올 수 있다.

로컬에서 변경한 후 커밋, 푸시한다. 인스턴스에서 빌드하면 된다.
브랜치에서 vi 파일이름으로 수정가능하다.

나쁜 점은 변경사항이 없어도 계속 build.sh가 실행된다는 것이다. 변경사항이 있는지 확인하는 방법은? local과 origin의 (0505) 브랜치가 다르면 변경사항이 존재한다.
git rev-parse HEAD 로컬의 HEAD가 보인다.
git rev-parse origin/HEAD하면 오리진의 HEAD가 보인다.
둘이 동일하면 빌드할 필요가 없을 것이다.

vi build.sh로 수정하기