Racoon's IT Devlog

8월 최근 일상 - 입사 5개월차

코딩하는너굴맨 — Sat, 3 Aug 2024 19:16:55 +0900

근황

더워 죽겠는 8월입니다.

현재는 입사 5개월정도 꽉채운 현재입니다.

원래 하던 프로젝트 외에 새로운 프로젝트에도 투입되고, 출장도 3번이나 갔다왔습니다.

솔직히 아직도 전체적인 구조도 이해 안가는 곳이 많고, 겨우겨우 따라가는 느낌입니다. 언젠간 익숙해지겠지 하고 버티고 있는 요즘입니다. 열심히 하다보면 어떻게 되겠죠?

아마도 9월말에는 외국으로 출장을 갈 수도 있을 것같습니다.

유럽도 처음가보고, 좀 기대가 되는 부분이 없지않습니다. 푸하하

요즘은 취미로 맛집을 구글맵에 정리하고 있습니다.

어떻게든 chatgpt나 구글 api를 활용해서 자동화해보려고 했는데, 가게마다 기준도 다르고 뭔가 엄청 귀찮아져서 2주만에 포기하고, 그냥 수동으로 적는 중입니다. 뭔가 지도가 채워지는 느낌이 재밌네요.

자취한지 6개월 정도가 되어가는데, 외로움이 없는사람이지만, 외로움이 조금씩 생기는 기분입니다.

본가에서 아예 먼 곳으로 오다보니 친구들도 주변에 없고, 특히 주말에 좀 심심한 기분입니다.

이 또한 지나가겠죠.

요즘 결혼하는 친구들이 하나둘 늘어나고 있습니다.

이제 신입으로 들어와 정신도 없는데 일찍 일해서 일찍 결혼하는 친구들을 보니 새삼 대단하다고 느낍니다.

요즘 출산율이 안좋다, 결혼을 안한다 뭐니 하는데, 제 주변에는 해당하지 않는 것 같군요?!

7월 최근 일상 - 입사 4개월 차

코딩하는너굴맨 — Mon, 1 Jul 2024 04:47:25 +0900

1. 근황

짜잔

최근 근 거의 4개월간 포스팅을 하지 못했습니다.

제가 쭉 백엔드 과정으로 올해 2월까지 준비를 했었는데요.

제가 이때까지 대학시절 파이썬이나 OpenCV같은 카메라 인식, 인공지능 같은 분야에 관심이 많았습니다.

하지만 취업 쪽으로는 백엔드 개발자를 목표로 공부를 계속 하고 있었어요.

하지만, 이번에 3월에 Vision 쪽, 즉 카메라, 인식 관련 개발자로 일하게 되었습니다.

그래서 자취를 위해 이사하랴 부랴부랴 준비하고, 신입으로 4개월동안 일하느라 정신이 없었네요.

현재 하고있는 일은 하나부터 열까지 처음부터 알아가는 과정중이라 적응하는게 어려운거지,

제가 관심있는 분야에서 일하는 것이라 현재까지는 너무 즐겁게 일하고 있습니다.

그래서 앞으로는 백엔드 보다는, 폭넓은 컴퓨터 포스팅이나, Vision 쪽 포스팅을 하게될 것 같습니다.

오늘은 새벽 4시에 일어나서 글을 작성하고 있네요.

일주일에 한번 정도는 일상 글을 적어볼까도 생각중입니다. 생각을 정리하는데 좋을 것 같아요.

그럼 이만~

AWS - AWS 꼭 확인하자! 요금폭탄 피하기

코딩하는너굴맨 — Sat, 3 Feb 2024 19:49:24 +0900

0. 개요

가난한 취준생 생활을 이어가는 중에, 갑자기 AWS에서 16,000원 가량의 해외결제를 제 계좌로 계속 시도하고 있었던 것을 확인했습니다. 결제가 되지않은 것은 해당 해외결제 카드를 사용하지 않아서 돈이 없어서 그런 것 이었는데요. 나는 AWS 프리티어만 사용했고, 돈이 나갈일이 없는데 뭐지? 해킹이라도 당한건가? 라는 불안함이 엄습했습니다.

1. 청구서 확인하기

청구서를 확인해보니 Lightsail과 Elastic Compute Cloud에서 사용요금이 나가고 있었습니다.... 이게뭐야??

확인해보니, 한두달전에 유튜브에서 본 AWS강의를 보고 Lightsail을 사용했던 적이 있었던 것 같습니다. 그래서 Lightsail 인스턴스와 고정IP가 할당되어 있었습니다.

또한 Elastic Compute Cloud의 경우에도 이게 뭔가하고 보았더니 IPv4 adress에 대해서 요금이 할당되고 있었습니다. EC2를 사용하더라도, 고정 IP를 사용하는 경우에는 요금이 조금씩 부과되는 것으로 보입니다...

배포나 직접 사용하지만 않으면 요금이 부과되지 않을거라 생각했던 제가 안일했던 거죠..

궁금해서 알아보니 AWS에 대해서 관리나 설정을 잘못하거나, key를 해킹당해서 요금폭탄을 맞는 경우가 꽤나 있는 편 인 것 같습니다. 다행이 고객센터에서 직접 사용하지 않는 사례에 대해서는 해결을 해준다고는 하지만, 관리를 잘 해야하는 것 같습니다.

2. 요금폭탄 피하기 - 수시로 확인하고, 삭제하자

수시로 확인하기

좌측 상단에 자신의 계정을 클릭하면 "결제 및 비용관리" 라는 메뉴가 있습니다. 여기서 청구서를 들어가서 위에 제가 올린 것처럼 어디서 어떤 비용이 발생되었는지를 확인할 수 있습니다. 비용은 매월 초 (3일)에 카드로 요금이 요청됩니다. 꼭 확인합시다.

예를들어, EC2를 사용하더라고 여러개의 인스턴스를 생성해서 프리티어의 사용량을 넘을 수도 있고, 고정 IP를 사용하고 방치를 했다던가, 등등의 이유가 있을 수 있습니다.

지우고, 삭제하라

사용할 때마다 생성하고, 평소에는 삭제해 놓는 것이 좋습니다. 1년 365일 매일매일 AWS에 들어와서 체크하기는 힘들 것 입니다. ㅠㅠ

청구서에서서 확인한 서비스로 들어가서 삭제해주도록 합니다.

인스턴스 중지, 인스턴스 삭제, 고정Ip를 삭제합니다.
DB를 생성했다면, RDS에서 DB를 삭제해줍니다. 스냅숏도 삭제합니다.
S3, VPC를 사용했다면 삭제해줍니다.
이미지 복사본 AMI를 만들었다면, EC2-AMI에서 삭제합니다.

또한, 당분간 사용하지 않을 계힉이라면, 계정 자체를 지워두는 것이 마음이 편할 수 있습니다. 이렇게 하는 것도 좋습니다. 여기서도 주의할 점이 사용하고 있던 리소스들을 삭제하지 않고 계정탈퇴를 하면, 그대로 요금이 부과될 수도 있습니다. 계정 복구를 해서 다시 리소스들을 삭제한 후에 계정 탈퇴를 하도록 합니다.

예방하는법

https://brunch.co.kr/@topasvga/96

22.AWS 예상 비용 알람 받기

AWS는 사용한 만큼 비용을 낸다. 테스트로 몇 개 만들어 놓고 지우지 않으면 비용이 계속 발생한다. 서버 자동생성 코딩을 잘못해서 고비용이 발생할 수 있다 이를 모니터링하기 위해 기본적으로

brunch.co.kr

일정 금액이상의 노티가 나오면 예상 금액을 알람을 받도록 설정할 수 있습니다. 위의 포스팅을 참고해주세요.

혹은 구글 OTP를 사용해서 해킹당했을 시 통장에서 돈이 빠져나가는 것을 예방하는 것이 좋습니다.

혹은 결제 및 비용관리에서 비용 분석 및 보고서탭에서 비용모니터로 사용량을 관찰할 수 도 있습니다. 모니터를 생성해주고 수시로 확인해봅시다.

Docker - 1. Docker의 개념과 설치 및 사용법

코딩하는너굴맨 — Fri, 2 Feb 2024 22:30:46 +0900

0. 개요

이번에는 Docker에 대해서 제가 공부한 내용을 정리하는 시간을 가져보고자 합니다. docker가 무엇이길래, 이걸로 프로젝트 배포를 관리하고, 꼭 배워야 한다고 하는 것일까?

1. Docker를 알기위한 Container

Docker의 마크를 보면, 배위에 컨테이너가 쌓여있는 듯한 그림이 존재합니다. 왜 이렇게 Docker를 비유했을까??

말콤 맥린(Malcolm McLean)이라는 20세기 초반, 자동차 운수업으로 매우 성공한 사람이 있었습니다. 자동차를 팔면서, 에로사항이 발생했습니다. 항구가 존재하면, 항구의 입구를 통해서 자동차를 담은 트럭이 들어오고, 배앞으로 와서 노동자들이 자동차를 내려서 배에 싣고... 이 작업을 하는동안 다른 트럭들은 대기를 하고... 이렇게 엄청난 트래픽이 몰리면서 구조적으로 비효율적이었습니다.

여기서 container라는 개념이 생겨났습니다. 노동자들이 트럭이 자동차를 내릴 필요가 있었던 이전방식과 달리 외부에서 항구로 차를 싣을 컨테이너를 가져와서 대형 기계가 컨테이너를 들어서 항구에 적재하고, 트럭은 할일을 다했으니 그냥 가면 됩니다. 컨테이너채로 싣어버리니까 노동자의 일도줄고, 시간도 빠르고, 트래픽도 줄어들게 되었습니다.

받는 쪽에서도 배가 들어오면, 컨테이너를 기계로 싣어버리고, 트럭에 컨테이너에 그대로 싣어서 내보내는 간편함이 있었습니다. 이것이 컨테이너의 발명입니다. 그리고 Docker는 프로그래밍적으로 컨테이너를 관리하는 프로그램입니다.

2. Docker??

아까 배위에 컨테이너를 올리듯이, Docker는 나의 컴퓨터 위에 OS를 올립니다. OS에는 JDK, Git, Python ...등등의 많은 프로그램이 설치되어 있습니다. 통째로 한번에 설치해서 올릴 수 있는 것 입니다. 또 이렇게 만들어진 컨테이너를 다른 컨테이너와 상호작용을 해서 한번에 올리거나 한번에 내릴 수도 있습니다. 이것을 Docker-compose라고 합니다. 이렇게 Docker container는 여러 프로그램을 한방에 옮길 수 있으므로, 잘 만들어놓은 컨테이너가 있으면 다른 컴퓨터에서도 동일하게 환경세팅을 쉽게 할 수 있습니다.

3. Docker, Docker-compose, Docker-hub

Docker는 컨테이너를 만들고 실행을 하고, 컨테이너를 구성할 수 있게 도와주는 기능을 제공합니다. 예를들어 떡볶이라는 컨테이너를 만들어서 떡, 파, 오뎅 등을 싣을 수 있습니다.

Docker-compose는 다른 컨테이너와 상호작용할 수 있게 해줍니다. 예를들어 불고기라는 컨테이너를 떡볶이가 실행되면 같이 실행되도록 할 수 있습니다. 최소 두 개이상의 컨테이너를 실행하는 방법입니다.

Docker-hub(https://hub.docker.com/)는 Github와 같다고 생각하면 편합니다. 클라우드 서버에 개인이나 회사가 완성한 컨테이너를 올려서 공유하고, 통째로 다운받을 수 있습니다. repository와 같은 느낌의 컨테이너 관리 저장소입니다.

4. Docker-Desktop, Docker-compose 설치

Docker-Desktop

https://www.docker.com/products/docker-desktop/

Docker Desktop: The #1 Containerization Tool for Developers | Docker

Docker Desktop is collaborative containerization software for developers. Get started and download Docker Desktop today on Mac, Windows, or Linux.

www.docker.com

Docker-Desktop을 설치해줍니다.

여기서 중요한 점은 제어판 > 프로그램 및 기능 > Windows 기능에서 Linux용 Windwos 하위 시스템이 깔려있어야 합니다. Docker는 리눅스 시스템으로 돌아가므로, Docker Desktop을 설치하면 해당 옵션이 생성될 것 입니다. 체크해서 활성화 되어 있는지 확인해줍니다.

docker --version

도커가 정상적으로 설치되어 있는지 cmd창에서 확인할 수 있습니다.

docker run -d -p 80:80 docker/getting-started

예시로 한번 컨테이너를 받아서 실행시켜봅니다.

나중에 다시 설명하긴 할텐데, 위의 명령어는 docker/getting-started라는 컨테이너를 run(실행)합니다. 만약 해당 컨테이너(이미지)가 내 컴퓨터에 없으면 다운받아서 실행합니다. 80:80으로 포트포위딩을해서 -d옵션으로 백그라운드 실행을 합니다.

그럼 이렇게 Docker-Desktop에 새로운 컨테이너가 활성화 됩니다.

80포트로 실행중이니 localhost:80으로 진입하면 정상적으로 잘 실행되는 것을 확인할 수 있습니다.

Docker-compose

https://docs.docker.com/compose/install/standalone/

Install Compose standalone

How to install Docker Compose - Other Scenarios

docs.docker.com

해당 문서에서 docker-compose를 설치하는 방법을 알려주고 있습니다.

 Start-BitsTransfer -Source "https://github.com/docker/compose/releases/download/v2.24.5/docker-compose-windows-x86_64.exe" -Destination $Env:ProgramFiles\Docker\docker-compose.exe

해당 명령어를 파워쉘의 관리자모드에서 실행해줍니다.

docker-compose --version

해당 명령어가 잘 실행되면 잘 설치가 된 것입니다.

이번에는 Docker에 관해서, 설치에 대해서 얘기했습니다. 다음에는 Docker의 작동원리, 컨테이너에 대해서 알아보는 시간을 가져보려고 합니다.

AWS - 3-3. 베이직 하게 배포해보기 - cron으로 주기적 실행

코딩하는너굴맨 — Wed, 31 Jan 2024 20:44:32 +0900

0.개요

이전에는 스크립트 파일로 불필요한 명령어를 치는 과정을 하나의 스크립트 파일로 압축해서 실행하도록 했습니다. 하지만 아직은 스크립트 파일을 일일히 수동으로 실행해주어야합니다. 하지만 웹사이트는 어떠한 문제로 인해서 프로세스가 종료될 수 도 있습니다. 이를 감지해서 알아서 자동으로 켜주게 하는 것이 좋을 것입니다. cron이라는 명령어를 통해서 주기적으로 프로세스를 감지,실행하도록 해보겠습니다.

1. cron명령어

cron은 주기적으로 어떤 작업을 실행할 수 있는 명령어입니다.

crontab -e

* * * * * ls -l >>cron.log

crontab -e를 통해서 crontab을 생성해줍니다. 이후에 어떤 에디터로 작성할지를 묻는데, 저는 vi에디터가 편해서 2번을 선택하겠습니다.

안에는 위와같은 텍스트를 적어줍니다. * 은 처음부터 분,시간,일,월,요일을 의미합니다. ">"와 ">>"의 차이는 한개일 때는 결과값을 넘기고 덮어씌웁니다. 두개일 때는 지속적으로 추가합니다.

정리하자면, 해당 명령어는 매분 "ls -l"이라는 명령어를 실행해서 cron.log라는 파일을 생성해서 안에 지속적으로 추가하라는 의미입니다. 해당 명령어로 crontab이 잘돌아가는지 실험해 보도록합니다.

그럼 루트경로에가서 확인해보면 cron.log라는 파일이 생성된 것을 확인해볼 수 있습니다. cat으로 확인해보면 "ls-l" 이라는 명령어가 매분마다 실행되고 있음을 확인할 수 있습니다.

2. cron 스크립트화

이런 cron 명령어 또한 스크립트화 해주도록 합니다.

vi myscript.sh

crontab -l 1>crontab_new

스크립트 파일을 하나 만들고, 안에 위의 명령어를 적어줍니다.

crontab의 내용을 그대로 가져와서 crontab_new라는 파일에 덮어씌워준다는 의미입니다.

./myscript.sh
cat crontab_new

실행하고 확인해보면 crontab의 내용이 그대로 담겨진 crontab_new라는 파일이 생성되었습니다.

crontab -l 1>crontab_new

echo "* * * * * /home/ubuntu/job.sh" 1>>crontab_new

crontab crontab_new

방금 만든 스크립트 파일의 내용을 위처럼 추가해줍니다.

매분 /home/ubuntu/job.sh 라는 파일을 실행해서 contab_new에 넣고, 이후 crontab_new의 내용을 crontab명령어로 실행하도록 합니다.

vi job.sh

ls -l>/home/ubuntu/cron.log

job.sh파일에서는 "ls -l"이라는 명령어를 cron.log에 담는 작업을 하도록 해줍니다.

그럼 crontab -e를 통해서 crontab을 확인해보면 crontab_new에서 Job.sh를 실행하라는 명령이 반영되어 있는 것을 확인해볼 수 있습니다. 이제 crontab에서는 주기적으로 job.sh안에 있는 ls -l를 cron.log에 저장하도록 할 겁니다.

cron.log을 살펴보면 분마다 "ls -l"을 실행해서 저장하고 있는 것을 확인해볼 수 있습니다.

정리

정리하자면,

crontab -e를 통해 crontab이라는 주기적으로 명령들이 실행되는 공간을 만든다.
crontab_new라는 파일을 만들어서 crontab의 내용을 가져와서 복사합니다.
crontab_new에 원하는 명령어나 스크립트 실행하는 명령어를 추가한 다음 crontab_new에 내용이 crontab에 적용되도록 합니다.
crontab_new에 추가된 내용이 crontab에 적용되면서 주기적으로 해당 명령어들이 실행됩니다.

3. cron을 이용해 스프링 서버를 재시작하기

mkdir cron-restart
cd cron-restart
vi spring_stop.sh

"cron-restart" 라는 디렉토리를 만들어서 프로젝트를 종료,시작하는 스크립트 파일을 모아두겠습니다. 해당 디렉토리로 들어가서 "spring_stop"이라는 스크립트 파일을 만들어줍니다.

echo "SPRINGBOOT STOP..."
SPRING_PID=$(pgrep -f v1.0.0.1-SNAPSHOT.jar)
kill -9 $SPRING_PID

이전에 했던 내용 그대로 우리가 실행하는 포르젝트의 jar파일을 종료하도록 하는 스크립트를 작성해줍니다.

vi spring-restart.sh

SPRING_PID=$(pgrep -f v1-0.0.1-SNAPSHOT.jar)
SPRING_PATH="/home/ubuntu/aws-v1/build/libs/v1-0.0.1-SNAPSHOT.jar"

echo $SPRING_PID
echo $SPRING_PATH

if [ -z "$SPRING_PID" ]; then
        echo "스프링 종료된 상태..."
        echo "스프링 재시작 - $(date)" 1>>/home/ubuntu/cron-restart/spring-restart.log
        nohup java -jar $SPRING_PATH 1>log.out 2>err.out &
else
        echo "스프링이 시작된 상태..."
fi

이번에는 "spring-restart"라는 프로젝트를 재실행하는 스크립트도 짜두도록 합니다.

해당 스크립트는 프로젝트의 jar파일의 PID를 추적해서, -z 옵션으로 해당 PID의 길이가 0이면 참이라고 판단하게 합니다.

현재 프로젝트가 실행중이라면, PID가 존재한다.> PID가 존재하면 길이가 0일 수가 없다.

반대로, PID가 존재하지 않는다 > 길이가 0이다 > 현재 프로세스가 실행되고 있지 않다. 라는걸 의미합니다. 해당 조건으로 if문을 통해서 현재 프로젝트가 실행중인지 아닌지 판단할 수 있습니다.

이러한 판단을 통해서 현재 프로세스가 종료된 상태라면, date, 즉 현재시간을 함께 담아서 언제 프로젝트가 재실행 되었는지를 확인할 수 있도록 spring-restart.log라는 로그에 담도록 하고, nohup명령어로 다시 프로젝트를 실행하도록 합니다.

이렇게 하면 모종의 이유로 종료된 프로젝트를 감지해서 알아서 재시작 해주는 로직이 완성되었습니다.

vi deploy.sh

# 2. 스프링 서버 종료시 재시작
echo "crontab 등록 - spring restart..."
crontab -l > crontab_new
echo "* * * * * /home/ubuntu/cron-restart/spring-restart.sh" 1>>crontab_new
crontab crontab_new
rm crontab_new

deploy.sh라는 스크립트 파일을 만들어서 해당 내용을 넣어줍니다. crontab_new를 만들어서, 프로젝트 재실행 동작을 추가하고, crontab에 적용하고, crontab_new파일을 필요 없어졌으니 삭제해줍니다.

deploy.sh에는 자동으로 github에서 프로젝트를 가져와서...JDK깔고....빌드해서..배포하는 과정도 추가해야 하지만 일단은 재실행 동작만 테스트 해보겠습니다.

sudo chmod u+x spring-restart.sh
sudo chmod u+x deploy.sh
./deploy.sh

해당 스크립트를 실행시킵니다.

crontab -e 로 확인해보면 crontab에 재실행 프로세스가 추가되어 있습니다. 이제 프로젝트가 종료된 것을 매분 감지해서 자동으로 실행을 해줄 것입니다.

위처럼 프로젝트가 종료되어 있는 상태에서 1분이 지나면, spring-restart.log가 생성되고, 8080포트가 자동으로 실행됩니다.

재시작 로그 또한 확인할 수 있습니다.

4. 개선해야할 점

지금까지 EC2 서버를 통해서 스크립트로 베이직하게 배포하는 방법을 해보았습니다. 하지만 역시 개선해야할 점이 많습니다.

프로젝트가 업데이트 되어서 재배포를 해야할 때는 어떻게 할 것인가?
재배포 할 시 서버가 꺼져있으면 안되는데 이것을 어떻게 해결할 것인가?
테스트를 안하고 배포중인데, 테스트를 어떻게 처리할 것인가?
사용자가 늘어나서 서버가 불안정해지면 어떻게할 것인가?
github에 코드를 새로 push하면 이를 감지해서 자동으로 재배포를 할 수 있도록 할 수는 없을까?

앞으로 이런점들을 고려해서 배포하는 방법들을 알아보겠습니다.

AWS - 3-2. 베이직 하게 배포해보기 - 타임존 변경, 스크립트 작성

코딩하는너굴맨 — Wed, 31 Jan 2024 19:36:22 +0900

0. 개요

이번에도 역시 저번 포스팅에 이어서, 프로젝트를 배포하는데 고려해야할 문제들에 대해서 조금씩 고쳐보는 시간을 가져보고자 합니다.

추가적인 고려했던 문제입니다.

현재 우분투의 시간설정이 US로 되어 있어서 +9시간이 된 채로 로그들이 남는다. 변경해야 한다.
일일히 배포를 하거나, PID를 알아내서 배포를 종료하는 작업을 스크립트로 해결하도록 하는 것이 좋다.

1. 타임존 변경

timedatectl
timedatectl list-timezones | grep Seoul
sudo timedatectl set-timezone Asia/Seoul

timedatectl이라는 명령어로 타임존을 변경할 수 있습니다. timedatectl을 옵션없이 실행하면 현재의 타임존을 알 수 있는데 UTC로 잡혀있습니다. 이를 대한민국으로 바꾸어 주어야합니다.

timedatectl list-timezones로 사용할 수 있는 타임존을 검색할 수 있는데 전세계에 서비스 중이다 보니 엄청많이 나올겁니다. Seoul을 옵션으로 검색하도록 합니다. 이를통해 Asia/Seoul로 타임존을 변경해주도록 합니다.

2. 스크립트 작성

프로젝트 프로세스를 키거나 꺼야하는 상황이 있을겁니다. 이전까지는 java -jar로 실행하고, 끌 때는 PID를 찾아서 확인하고 해당 PID를 kill해주었습니다. 이러한 불필요한 과정은 해야하는 일을 증가시킵니다. 이를 위해서 스크립트 파일을 작성해서 명령어들을 자동으로 실행해주는 것이 좋습니다.

ps -ef | grep *.jar | grep -v grep | awk '{print $2}'

이전에는 실행중인 프로세스를 확인하기 위해 "ps-ef" 라는 명령어를 사용했습니다. 여기서 우리가 실행하는 프로젝트의 PID만을 뽑아오기 위해서 위의 조건을 달아줍니다.

jar파일이어야 하고, 현재 ps-ef로 검색하는 것도 프로세스에 남으니 현재 프로세스는 빼고 가져오도록 하고, 두번째 칸에 있는 정보만 가져오도록 합니다. 그러면 위처럼 현재 실행중인 jar파일의 프로세스 PID를 가져올 수 있습니다.

pgrep -f *.jar

하지만 위처럼 많은 옵션을 달지않아도, pgrep이라는 명령어로 쉽게 실행중인 jar파일 프로세스의 PID를 가져올 수 있습니다.

vi spring-stop.sh

echo "Springboot Stop....."

SPRING_PID=$(pgrep -f *.jar)

echo $SPRING_PID

kill -9 $SPRING_PID

이제 이를 활용해 스크립트를 짜줍니다. spring-stop이라는 sh파일을 만들어줍니다.

SPRING_PID에는 pgrep으로 가져온 PID값을 넣어줍니다. (&로 감싸줘야 명령어로 인식합니다.) 이후 해당 PID를 kill 해주도록 합니다. 중간중간에 echo로 현재 실행중인 작업을 터미널로 인식할 수 있도록 합니다.

chmod u+x spring-stop.sh
./spring-stop.sh

이제 해당 스크립트 파일을 실행가능하도록 실행권한을 주고 현재 폴더에서 실행해 주도록 합니다. "./" 옵션을 줘서 현재 폴더에서 실행해도록 해야합니다. 안그러면 환경변수에서 설정된 파일을 실행할겁니다. 위처럼 정상적으로 현재 실행중인 프로젝트의 프로세스를 정상적으로 멈추게 해주었습니다.

AWS - 3-1. 베이직 하게 배포해보기 - 백그라운드 실행, 로그파일 분리

코딩하는너굴맨 — Wed, 31 Jan 2024 19:02:12 +0900

0. 개요

이번에는 저번 포스팅에 이어서, 프로젝트를 배포하는데 고려해야할 문제들에 대해서 조금씩 고쳐보는 시간을 가져보고자 합니다.

고려했던 문제가 몇개 있었습니다.

원격 터미널 창을 끄더라고 계속 실행이 되도록 백그라운드 실행이 되어야한다.
프로젝트의 로그 파일을 보기 좋게 분리해야 한다.

1. nohup로 백그라운드 실행

nohup이라는 명령어를 통해서 백그라운드 실행을 하도록 합니다. nohup는 리눅스에서 프로세스를 실행한 터미널의 세션연결이 끊어지더라도 지속적으로 동작할 수 있게 해주는 명령어입니다.

jar {
	enabled = false
}

저번 포스팅에 언급을 안했는데, spring boot 프로젝트의 경우, build.gradle에 해당 옵션을 추가해줘야합니다.

원래는 build를 실행하면 jar파일이 두 개가 생기게 됩니다. 모든 라이브러리와 소스코드가 포함된 jar파일, plain.jar라는 모든 의존성을 포함하지 않고 소스코드의 클래스파일과 리소스 파일만 존재하는 파일이 생성됩니다. plain.jar는 모든 의존성이 존재하지 않기 때문에 java -jar로 빌드시 오류가 발생합니다.

위 옵션으로 plain.jar가 생성되지 않도록 합니다.

nohup java -jar *.jar* &

이제 nohup을 통해서 jar파일을 빌드해주록 합니다. 여기서 "&"이라는 옵션을 통해서 백그라운드 실행을 하게 됩니다.

이제 터미널을 꺼도 사이트에 접근이 계속해서 가능한 상태가 되었습니다.

sudo apt install net-tools
netstat -nlpt

netstat이라는 명령어로 현재 실행중인 프로세스를 확인하기위해 net-tools를 다운받아서 netstat명령어를 사용해봅니다.

이렇게 프로세스가 돌아가고 있는 것을 확인할 수 있습니다.

2. 로그파일 변경 및 분리

이제 로그파일을 분리해보도록 합니다. 몇백줄이나 되는 기존의 프로젝트 로그를 보고 판단하는 것 보다, 에러가 있는지, 어떤 사용자가 접근하는지 등등의 로그파일을 분리해서 목적에 따라 확인하게 하는 것이 좋습니다. 로그파일을 변경하는 방법 이후에 로그파일을 분리해보도록 하겠습니다.

로그파일 확인 및 변경

ls
cat nohup.out

nohup으로 백그라운드 실행을 하게되면, nohup.out이라는 파일이 생성됩니다. 해당 파일을 cat으로 들어가보면, 내 프로젝트의 로그들이 모두 모여있습니다.

tail -f nohup.out

하지만, 계속 들어오는 로그들을 위해서 tail 이라는 명령어로 로그의 변화를 계속 관찰할 수 있습니다. 사이트에 접근하면 실시간으로 로그가 들어오는 것을 확인할 수 있습니다.

ps -ef
kill -9 "프로젝트 jar파일 프로세스 PID 번호"

그럼 위처럼 실행중인 프로세스를 확인해서 PID를 알아내고 kill 명령어로 일단 실행중인 프로세스를 죽여주도록 합니다. netstat으로 종료된 것을 확인할 수 있습니다.

nohup java -jar *.jar > mylog.out &

이제 nohup으로 프로젝트를 배포할 때, 옵션을 줘서 mylog.out이라는 파일로 로그가 모이도록 해줍니다. 이제 로그가 내가 원하는 이름의 파일로 모이게 됩니다.

로그파일 분리

nohup java -jar asasdq23adsd213da.jar &

만약 위처럼 이상한 파일명으로 아무렇게나 nohup을 실행하더라도 실행되지는 않지만, nohup.out이라는 로그파일은 생성됩니다. 여기에 실패한 내용에 대한 에러 로그가 남습니다. 그럼 정상적인 로그와 에러로그를 따로따로 파일로 분리해서 저장하도록 해봅시다.

nohup java -jar v1-0.0.1-SNAPSHOT.jar 1>log.out 2>err.out

위처럼 명령어로 1 의 경우 정상적인 로그, 2의 경우 에러로그를 의미합니다 .이렇게 따로따로 원하는 파일의 이름으로 저장이 가능합니다.

위처럼 프로젝트.jarr 처럼 잘못된 이름으로 배포를 시도하면, 위처럼 err.out에 에러 로그가 남게 됩니다. 반대로 정상적이라면 log.out에 남게 됩니다. 이제, 나중에 프로젝트를 배포했는데, 실행이 안되었다? err.out이라는 로그 파일만 확인하면 됩니다.

AWS - 3. 베이직 하게 배포해보기 - EC2 서버에 프로젝트 배포하기

코딩하는너굴맨 — Wed, 31 Jan 2024 17:51:41 +0900

0. 개요

원래는 배포를 하면서 nginx를 사용해서 프록시 서버를 거치게 하거나, CI/CD 도구로써 Jenkins를 사용하거나, 혹은 docker를 사용해서 배포를 하게됩니다. 하지만 이번에는 AWS EC2서버만을 이용해서 베이직하게 배포를 하는 방법을 실습한 것을 정리해보는 시간을 가져보겠습니다.

1. EC2 환경 세팅

배포를 하기전에 사용하기위해 EC2 서버의 환경 세팅을 한 후, EC2 서버로 원격접속을 해서 우리가 Github에 올린 프로젝트를 다운받아 보는 것을 해보겠습니다.

EC2 서버 고정 IP 설정

이전의 포스팅(https://chick-it.tistory.com/89)에서 한 내용처럼 인스턴스를 EC2에서 생성해줍니다.

이전과 다른점이라면, 네트워크 설정에서 편집 버튼을 누르고 하단의 인바운드 보안 그룹 규칙에 들어가서 현재는 22포트 밖에 없지만 인바운드 보안그룹 규칙을 추가 버튼을 눌러서 8080포트를 추가해줍니다. 모든 사용자가 접근할 수 있도록 위치무관으로 유형을 정해주도록 합니다.

그럼 위처럼 인스턴스가 생성될 텐데, 현재는 퍼블릭 IPv4포트 번호만 존재합니다. 우리는 AWS에서는 엘라스틱 ip(탄력적 ip)라고 부르는 고정 ip를 설정해주어야 합니다.

보통 가정집의 IP는 유동적으로 사용합니다.

예를들어 위처럼 공유기에 여러집이 물려있고, 통신사에는 연결된 집들에게 인터넷을 사용하도록 IP주소를 할당해줍니다. 하지만 예를들어 연결된집이 3개라고 해서 3개의 IP주소를 할당해주지 않습니다. 개인적으로 인터넷을 사용하는 사람들은 사용하는 시간이 있고, 나머지 시간에는 사용하지 않습니다.

세 사람이 자동차를 각자 아침,점심,저녁에만 사용한다면 한개의 자동차로 3명이 공유해서 사용할 수 있습니다. 이처럼 개인적으로 사용하는 인터넷은 일정 갯수의 IP를 유동적으로 공유해서 사용합니다.

하지만, 우리가 만들어서 배포할 웹서비스는 여러 사람이 하나의 IP로 사이트에 접속해서 서비스를 사용하게 됩니다. 이 주소가 계속 유동적으로 바뀐다면 서비스를 할 수 없습니다. 이를 위해서 비용은 조금 더 들지만, 고정 IP를 사용해서 서비스를 운영해야합니다.

EC2에서 탄력적 IP 탭으로 가서, 탄력적 IP 주소 할당을 눌러서 주소를 할당 받습니다.

이후 탄력적 IP 주소 연결을 통해, 방금 만든 인스턴스를 연결해줍니다.

그러면 우리가 만든 EC2 서버에 고정 IP가 할당됩니다. 이제 고정 IP를 통해서 MobaXterm으로 원격 접속을 하면 됩니다.

잘 접속됩니다.

2. JDK, Git clone, 빌드, 배포

Git

git --version
git clone "내 프로젝트 깃허브 링크"

git이 깔려져 있는지 버전을 확인합니다. 보통은 기본적으로 깔려있습니다.

이후 내 프로젝트를 가져와주도록 합니다.

ls명령어로 확인해보니 프로젝트가 잘 들어왔음을 확인할 수 있습니다.

Build

이제 빌드를 해서 다운받은 프로젝트 파일을 실행가능한 jar파일로 만들어 주겠습니다. 프로젝트 안으로 들어와서 ls로 내부를 확인해보면, gradlew이라는 파일이 있는 것을 확인할 수 있습니다. 이 실행파일로 프로젝트를 jar로 변환할 수 있습니다. 하지만 현재 권한이 -rw 로 x, 즉 실행권한이 없는 것을 확인할 수 있습니다.

chmod u+x gradlew

chmod로 gradlew에 실행권한을 주도록 합니다. 초록색 글자가 되어있는 걸 보니 실행할 수 있는 상태가 되었습니다. 이대로 빌드를 해야하지만, 제가 가져온 프로젝트의 경우 spring boot 프로젝트 입니다. 이를 위해서 java를 설치해야합니다.

sudo apt update
sudo apt-cache search jdk | grep openjdk-11
sudo apt install openjdk-11-jdk

한번 우분투 내의 라이브러리를 업데이트 해주고, java11로 만든 프로젝트 이므로 jdk 11을 다운받겠습니다. apt-cache search로 다운로드 가능한 jdk를 검색하는데 심각하게 많을 정도로 많은 파일이 검색될 것이므로 openjdk-11로 좁혀서 검색해서 원하는 jdk를 다운받아 줍니다.

빌드

./gradlew build

이제 빌드를 해줍니다.

cd build
cd libs
ls
java -jar v1-0.0.1-SNAPSHOT.jar

빌드에 성공하면 build라는 디렉터리가 생기는데, 여기에 들어가면 libs라는 디렉터리가 있습니다. 여기에 빌드로 만들어진 jar파일이 존재합니다. 이 파일을 실행하면 프로젝트가 실행됩니다.

와우! 인텔리제이 에서나 보던 spring boot 프로젝트가 원격 컴퓨터에서 실행되고 있습니다.

이제 고정IP:8080에 접근하면, 우리가 만든 프로젝트가 배포되어 있습니다.

해당 페이지에 접근하면 로그를 띄우게 했는데, 위처럼 로그가 잘 뜨는 것을 확인할 수 있습니다.

2. 현재 배포의 문제

하지만 지금은 날것 그 자체로 프로젝트를 배포한 것 뿐입니다. 현재 배포한 환경에는 문제가 많습니다.

1. 현재 MobaXterm에 열려있는 원격접속 창을 끄면, 서비스 또한 연결이 끊어집니다. 터미널 창이 꺼지더라도 계속 백그라운드로 실행이 되어야 합니다.

2. 현재 배포를 하면, Spring boot 프로젝트가 돌아가고 있습니다. 하지만, 돌아가면서 여기에서 발생하는 로그나 다른 에러 메세지들을 따로 빼서 보는 것이 가시성에 훨씬 좋습니다. 로그파일을 분리해주어야 합니다.

3. 현재 임대 컴퓨터는 US로 시간대가 정해져 있어서 시간대 역시 한국으로 변경해야 하며, 프로젝트를 시작하거나, 프로젝트를 종료하는 것을 일일히 하지말고, 스크립트 코드를 작성해서 손쉽게 해주는 것이 좋습니다.

4. 빌드, 배포 자동화 : 현재 github에서 프로젝트를 가져오고 > JDK 설치 > 빌드 > 배포 프로세스를 진행중인데, 그러면 프로젝트를 새 기능을 추가해서 재 배포를 하려고 하면, 이 모든 과정을 다시 일일히 수동으로 해야하는가? 이 프로세스를 자동화 해주어야 합니다.

다음 포스팅부터 이런 문제들을 해결하는 방법을 알아보고자 합니다.

AWS - 2. 키페어와 RSA

코딩하는너굴맨 — Tue, 30 Jan 2024 21:55:49 +0900

0. 개요

이전의 포스팅에서 인스턴스를 생성할 때, 키페어라는 것을 생성했습니다. 그리고 키페어를 통해서 MobaXterm으로 임대 컴퓨터에 접속할 수 있었습니다. "어떤 과정이 존재하는 것일까?" 대해서 설명을 하려면 AWS의 EC2 서버의 방화벽에 대해서 알아볼 필요가 있습니다.

1. AWS EC2 서버의 방화벽

이전 포스팅의 과정을 정리하자면, 인스턴스를 생성해서 22번 포트로 MobaXterm으로 접속했습니다. 22번 포트는 ssh로 접속합니다. 접속해서 shell명령으로 통해 우분투라는 OS가 받아서 번역해서 하드웨어를 컨트롤 할수 있게 됩니다. 우리는 AWS에서 인스턴스라는 하나의 컴퓨터를 받았으므로 여기에 shell명령으로 Java, 톰캣 등등을 설치해서 사용할겁니다.

하지만 AWS의 방화벽은 기본적으로 모든 포트를 차단합니다. 그러므로 인바운드 규칙 설정을 통해 원하는 포트를 개방해서 접속을 허용해야합니다.

ssh는 secure shell의 약자로,

shell : 사람이 하드웨어를 컨트롤 하기위해 OS에게 명령을 하는데 shell언어를 쓴다.
secure : 민감한 정보를 보낼 때 노출 시를 대비해 데이터를 암호화한다,

정리하자면, SSH는 네트워크 상에서 안전하게 인터넷을 통해 다른 컴퓨터에 로그인하거나 원격시스템 명령을 실행하기위한 프로토콜 및 해당 프로토콜을 구현한 프로그램입니다. SSH로 원격 컴퓨터에 접속해서 원격으로 Shell명령이 가능해집니다.(CLI환경)

2. RSA인증 방식

이전 포스팅에서 인스턴스를 생성할 때, RSA라는 유형으로 키 페어를 생성했습니다. RSA가 뭔지 알아보겠습니다.

동식이와 춘배가 데이터를 주고받습니다. 하지만 여기서 중간에 해커가 데이터를 탈취할 수 있습니다. 그러므로 비밀번호 같은 예민한 정보를 주고받게 되면 치명적일 수 있습니다. 그래서 비밀번호 데이터를 암호화하고, 동식이와 춘배는 k라는 공통된 키를 공유해서 암호를 풀게됩니다. 이렇게 공통된 키를 사용하는 방식을 대칭 키라고 합니다. 단점은 k라는 키를 주고 받는 과정이 번거롭습니다.

RSA방식은 키를 두개를 사용합니다. A키로 잠긴 데이터를 B키를 통해 열 수 있고, B키로 잠긴 데이터는 A키로 열 수 있습니다. 이러한 방식을 공개 키 방식이라고 합니다.

공개 키 방식을 이용해 RSA에서는 상대방의 공개키로 데이터를 잠금니다. 동식이는 "춘배의 공개 키"로 암호화해서 춘배에게 비밀번호를 보내줍니다. 그럼 춘배는 자기가 가지고 있는 "춘배 비밀 키"로 데이터를 해석해서 사용하고, 춘배가 동식이에게 보내줄 때는 데이터를 "동식이 공개 키"로 암호화를 해서 보내주고, 동식이는 자신의 비밀키로 데이터를 확인합니다. 해커는 공개 키밖에 모르니 데이터를 탈취해도 사용할 수 없습니다.

추가적으로, 중간에 해커가 데이터를 탈취해서 자신만의 방식으로 다시 암호화해서 상대방에게 계속 보내준다면, 상대방은 잘못된 방식으로 암호화된 데이터가 계속 들어오는 경우가 발생할 수있습니다 .

이를 위해서 송신자의 비밀키로 한번더 잠금니다. 이러면 춘배 입장에서는 데이터가 잠겨있는걸 확인하고 공개키로 열어보는데, 만약 동식이의 공개키로 열리는 것을 확인하면, 송신자가 동식이라는 것을 알 수 있습니다. 이렇게 송신자를 알 수있도록 한번더 잠그면, 해커가 중간에 탈취한후 자신만의 암호화 방식으로 춘배에게 보내도 춘배 입장에서는 동식이의 공개키로 안열리는 것을 확인하고 송신자가 동식이가 아닌 것을 판단해서 막히게 됩니다. 이렇게 송신자가 누군지를 알기 위해 잠가서 전자서명으로 사용합니다.

RSA방식을 정리하자면,

공개키, 비밀키 두 개의 키를 이용해서 데이터를 교환한다.
송신자는 수신자의 공개키로 암호화를 하고, 자신의 비밀키로 전자서명을 통해 보안적으로 사용한다.
수신자는 송신자의 비밀키로 잠긴 전자 서명을 송신자의 공개키로 열고, 수신자의 비밀키로 연다.

이러한 RSA방식을 AWS에서는 키 페어로 생성합니다. 위의 그림에서는 춘배가 받은 키페어를 춘배의 비밀 키라고 하겠습니다. 춘배가 AWS의 22번 포트로 비밀 키를 통해서 연결을 시도합니다. AWS 컴퓨터 내부에는 .ssh 폴더안에 Authorized-key라는 키가 존재하는데, 이 키는 접속하려는 클라이언트, 즉 춘배의 공개 키입니다. 해당 키로 접속으로 들어온 비밀 키에 대입해서 해제에 성공하면, 전자서명 인증완료로 세션이 생성됩니다. 이제 마음대로 원격 컴퓨터에 데이터든, 명령이든 할 수 있는 상태가 되었습니다.

참고 - 메타코딩 유튜브

https://www.youtube.com/@metacoding

AWS - 1. AWS에 대해서

코딩하는너굴맨 — Tue, 30 Jan 2024 19:35:28 +0900

0. 개요

배포라는 말이 나오면 무조건 AWS에 대한 내용이 나오기 마련입니다. AWS가 도대체 뭐길래 이렇게 주목되고 있는 것일까? 이번에는 AWS에 대해서 제가 알아본 내용을 정리하고, 간단하게 컴퓨터를 임대하고, 접속해보는 시간을 가져보고자 합니다.

1. AWS??

AWS(Amazon Web Service)는 2006년에 아마존닷컴(Amazon.com)에서 시작되었습니다. 아마존은 당시 자사의 IT 인프라를 효과적으로 활용하고자 하였고, 이를 다른 기업들과 공유함으로써 서버, 스토리지, 데이터베이스, 네트워크, 컴퓨팅 파워 등 다양한 IT 서비스를 제공하게 되었습니다.

간단하게 배경을 설명하자면, 2000년 초반, pc를 사용하는 사람이 점점 늘어나기 시작했습니다. 그러면서 점점 감당이 안되기 시작하면서 이를 위한 컴퓨터 시스템을 만들기로 합니다. 미리 여러대의 컴퓨터를 구축해놓기로 합니다. 하지만 이렇게 되면, 사용자가 급증하는 기간에는 좋지만, 사용자의 사용이 감소하는 시기에는 사용하지 않는 컴퓨터가 늘어납니다. 이 컴퓨터들을 외부에 빌려주는 서비스를 하기 시작한 것이 클라우드 컴퓨팅의 시작입니다.

개인이 이렇게 누군가가 구축해 놓은 컴퓨터를 입대해서 사용할 수 있게됩니다. 이러한 인프라를 제공하는 것을 IaaS(Infrastructure as a Service)라고 하며, 이런식으로 본인의 컴퓨터아닌 외부에서 제공하는 리소스를 사용하는 것을 "Off-premise"라고 합니다. 이에 상반되는 개념으로 "On-premise"가 있는데, 조직이 자체적으로 소유하는 하드웨어나 소프트웨어 인프라를 이용하는 것을 의미합니다. 이러한 인프라를 제공하는 서비스를 전세계에서 하는 것이 현재의 AWS입니다.

AWS의 탄생은 기업들이 자사의 IT 인프라를 보다 효과적으로 운영하고 비용을 절감하고자 하는 요구에 부응하기 위한 것이었습니다. 클라우드 컴퓨팅 서비스는 기업들이 필요한 만큼의 컴퓨팅 리소스를 유연하게 이용할 수 있도록 하는 등의 혁신적인 개념을 도입하여 새로운 비즈니스 모델을 형성하게 되었습니다.

2. 인스턴스 접속

이번에는 간단하게 AWS를 직접 사용해보면서 임대한 인스턴스에 접속을 해보는 실습을 해보겠습니다. 사용할 서비스는 EC2를 사용하겠습니다.

1. 인스턴스 생성

구글에 AWS를 검색해서 AWS 사이트로 들어와서 가입을 해줍니다. 요구조건이라면, 해외 결제가 가능한 카드가 존재해야합니다. 그러므로 꼭 준비해주도록 합니다. 저도 처음 가입할 때는 기존의 카드가 안되서 토스카드를 부랴부랴 발급받았던 기억이 있습니다.

로그인을 한 후 홈에서 리전을 서울로 바꿔줍니다.

AWS는 전세계 적으로 서비스중인데, 아시아,미국,유럽 등등에 분포 되어 있습니다. 분포되어있는 곳을 리전이라고 합니다. 그래서 우리의 서비스가 원활하게 돌아가려면 한국에서 가장 가까운 리전을 선택해야합니다. 아시아 태평양(서울)을 선택해주도록합니다.

이후 검색을 통해 EC2를 선택해주도록 합니다. EC2(Elastic Compute Cloud)는 아마존에서 제공하는 클라우드 컴퓨팅 서비스로, 가상의 컴퓨터를 임대할 수 있습니다. 피시방 후불제 처럼 사용한 만큼 지불하기 때문에 탄력적이라는 의미인 Elastic이 붙었습니다. 원하는 만큼의 스펙은 커스텀할 수 있어 지불하는 비용이 달라집니다.

EC2를 들어와서 인스턴스로 들어옵니다. 그리고 인스턴스를 생성해주겠습니다.

AWS EC2 인스턴스를 생성한다는 것은 AMI를 토대로 운영체제, CPU, RAM 혹은 런타임 등이 구성된 컴퓨터를 빌리는 것을 의미합니다. AMI는 Amazon Machine Image의 약자로, EC2 인스턴스를 생성하는데 사용되는 가상머신 이미지 입니다.

인스턴스의 이름은 대충 AWS-v1 이라고 지어주었습니다. 그리고 OS를 선택해주어야 하는데, Ubuntu를 선택하고, 최신버전인 22.04를 선택해주었습니다.

인스턴스 유형은 프리티어가 사용가능한 t2.micro를 선택해줍니다. 여기서 프리티어는 가입한지 1년내의 고객을 의미하며, AWS는 사용할때마다 요금이 나가는데, 프리티어유저는 어느 정도의 서비스를 무료로 이용할 수 있습니다. 이를 위해서 프리 티어용 옵션들을 선택해주겠습니다.

특정 키를 이용해서 임대 컴퓨터에 접속이 가능합니다. 처음으로 AWS 서비스를 이용하면 없을테니 만들어줍니다. RSA유형, .pem의 형식으로 만들어줍니다. ".pem"형식으로 만든 이유는 이후에 임대 컴퓨터에 연결할 때 MobaXterm이라는 프로그램을 사용할건데 이 때, pem형식의 키가 필요합니다. 키페어에 대해서는 다음 포스팅에서 다루겠습니다.

네트워크 설정은 기본설정대로 사용하고, 스토리지 구성의 경우 하단의 경고창에서 나온 것 처럼 30GB 가지는 무료로 제공해줍니다. 그러므로 30GB로 설정해줍니다. 이후 인스턴스 시작을 눌러서 인스턴스를 생성해주면 됩니다.

그럼 이제 인스턴스가 생성된 것을 확인할 수 있습니다. 이제 해당 인스턴스, 즉 임대한 컴퓨터에 접속하기 위해서 mobaXterm을 사용하겠습니다.

2. 인스턴스에 접속하기

https://mobaxterm.mobatek.net/

MobaXterm free Xserver and tabbed SSH client for Windows

The ultimate toolbox for remote computing - includes X server, enhanced SSH client and much more!

mobaxterm.mobatek.net

MobaXterm을 설치해줍니다.

설치 후 MobaXterm을 실행하면 위와같은 창이 뜹니다.

Session 클릭
SSH 클릭
Remote host에는 AWS에서 생성한 인스턴스의 IP를 적어줍니다. 그리고 ubuntu로 OS를 정했으므로 name은 ubuntu로 해주었습니다.
Advanced SSH settings 클릭 한 후 User private key에서 방금 인스턴스를 생성하면서 발급받은 키를 넣어줍니다.
OK를 눌러 연결해줍니다.

그러면 이렇게 임대한 EC2 인스턴스에 접속을 할 수 있게 되었습니다. 여기서 프로젝트 파일을 jar파일로 빌드해서 배포를 진행하면 되겠습니다. 하지만 현재는 아무것도 설정하지 않았으므로 문제점이 많습니다. 이후의 실제 배포에 대한 내용은 이후에 포스팅 하도록 하겠습니다.