DevOps 배포

오늘 배운 대략적인 내용은
소프트웨어 프로젝트를 수동으로 배포하는 과정이였습니다.

준비연습과정

처음에는 아마존 웹서비스에 접속하여 EC2를 만들어 클라우드 세팅을하고 해당 인스턴스로 접속하였습니다.

ec2에 접속하는 방법은 다양했지만 실습때 실행한 방법으로는
1. 웹에서 직접 접속하는 방법
2. MobaXterm툴을 사용하여 SSH접속하는 방법
이 있었습니다.

MobaXterm툴을 사용한이유는 로컬 pc에서 빌드한 .jar파일을 EC2 인스턴스로 전송하기 위해서였습니다.
스프링부트에서 build한 .jar파일을 ec2 인스턴스로 전송후 실행시킨다음
ip주소:8080으로 웹서버에 접속해보니 제대로 작동하는것을 확인하였습니다.

수동배포

수동으로 .jar 파일을 배포하는 실습을 github를 통해 진행 하였습니다.
깃 레파지토리를 하나만들어 로컬pc와 연동하였습니다.
해당 레파지토리는 향후 실습때 보안성을 높이기위하여 private로 설정하여 생성 하였습니다.

그리고 ec2인스턴스에서 ssh연결을통해 깃 레파지토리를 ec2인스턴스에 추가하였습니다.
이 과정속에서 해결해야할 문제가 있었습니다. 바로 이전에 레파지토리를 private으로 만들었기 때문에 https주소만으로 git clone이 불가능하여 해당 ec2에서 ssh키를 만들어 github에 해당 ssh키를 등록한후 ssh를 활용하여 레파지토리를 불러왔습니다.

이렇게 깃 레파지토리를 local-pc , ec2인스턴스에 연결을 하였습니다.
local-pc에서 해당 스프링부트 프로젝트를 인텔리제이편집기를 활용하여 내용을 수정한다음 깃에 push 하고
ec2에서 pull하여 받아온다음 다시 ./build하여 .jar파일을 만들어 실행시켜 해당서버에 접속하여 수정된 내용을 확인할 수 있었습니다.

이런식으로 수동배포를 해보니 굉장히 많이 손을 봐야해 불편하다는 것을 알게 되었습니다.

앞으로 배울내용

CI/CD deployment는 자동화 처리가 핵심입니다. 앞으로 gitaction을 통하여 레파지토리가 업데이트가되면 해당 업데이트내용을 자동으로 배포하는 부분을 실습할 예정입니다.

특이 사항

1. 아마존 웹서비스는 이용한만큼 서비스 비용이 나가니 항상 결제 및 비용관리를 체크해야 합니다.

2. nohup & 명령어로 .jar 파일을 실행시키면 백그라운드에서 실행되기 때문에 kill명령으로 프로세스를 종료 시켜줘야 .jar파일이 사용하던 포트번호를 다시 사용할 수 있습니다.

3. aws에서는 VPC를 활용하여 네트워크 환경을 커스터마이징할 수 있습니다. 리전별로 vpc에서 구성할 수 있는 로직이 조금씩 차이가 있습니다.