목록인프라/리눅스, AWS (12)
코딩기록

1. RDS 퍼블릭 엑세스 해제AWS 프리티어를 사용하고 있는데 다음과 같은 항목으로 비용이 조금씩 발생했다. 원인을 살펴보니, RDS를 퍼블릭 엑세스로 사용하면 외부에서 접속 가능한 v4 IP를 발급하게 되고, 이 IP는 프리티어 대상이 아니라 비용이 청구되는 것이었다. RDS의 퍼블릭 엑세스를 불가능으로 바꾸면 비용이 발생하지 않는다. 2. SSH Tunneling 접속이렇게 RDS의 퍼블릭 엑세스를 사용하지 않는다면, 당연히 기존 TCP 방식으로 RDS에 직접 접속했던 Connection이 작동하지 않는다. 현재 농구장 위치 공유 백엔드 서버가 깔려있는 EC2를 통해 RDS에 접속해야 하는 것이다.(같은 보안그룹 안에 있기 때문에 이곳에서 접속 가능) = "SSH Tunneling" MySQL W..

직장인 커뮤니티 팀프로젝트에서. 구글 SMTP를 이용한 메일전송 시스템 구현을 위한 AWS QSQ를 구현하고 있다. 현재 프로젝트에서 spring-cloud-aws의 2.4.4버전 을 사용하고 있는데 이 버전에 맞추어 개발하려고 하였다. @SqsListener가 작동이 안되는 문제가 있었다. 2일 동안 모든 블로그 글들을 확인하며 설정들을 바꾸었지만 결국 작동하지 않았다. @SqsListener(value="MailSQS" , deletionPolicy = SqsMessageDeletionPolicy.NEVER) public void receive(String payload) { System.out.println("payload = " + payload); } 현재 환경에서 작동하지 않는 것이였다. Sp..
재배포 절차는 다음의 9가지 단계로 진행된다. 해당 절차의 코드 내용을 정리하였다. 1. 환경변수 등록 -> 2. 실행 중인 크론 종료 -> 3. 현재 구동중인 서버 체크(구동 중이면 종료 / 구동되지 않고 있으면 최초 배포 준비(jdk 설치, timezone 설치)) -> 4. 기존 프로젝트 폴더 삭제 -> 5. git clone -> 6. 실행파일 권한 부여 -> 7. 빌드 -> 8. 실행 -> 9. 지속적 배포 크론 재실행 cf) 환경변수 설정하는 방법 export LOVE="i love you" 환경변수 저장 echo $LOVE = i love you ./.bashrc 에 적용하면 환경변수 영구히 사용 가능 1 aws 재부팅하면 적용되고 또는 2 source ./.bashrc 로 강제적용 할수도 ..
지난번 단계에서 RDS, 엘라스틱빈스톡 환경을 구축했다. 이번에 Github Action을 통한 최종 배포를 진행한다. Github Action은 테스트, 배포, 필요한 스크립트 실행 등을 진행하여 ci/cd를 자동화 해주는 Github의 서비스이다. Github Action에게 일을 시키기 위해, Spring 프로젝트에 deploy.yml / 00-makeFiles.config / Procfile 3개의 파일을 적절한 경로에 만들어 주어야 한다. deploy.yml .github/workflows/*.yml 파일에 배포에 필요한 액션이 작성되는 스크립트이다. 제공되는 라이브러리 활용이 가능하다. name: lessonReserve on: push: branches: - prod jobs: build: ..

지난 포스트에 작성된 과정에서 CI/CD의 개념을 이해하였으며, 이제부터 본격적으로 GithubAction, 로드밸런서를 통한 최종 배포를 진행해볼 예정이다. 이를 위한 환경설정을 진행하며, 해당 내용을 기록했다. 깃허브 포크하기: 남의 레포지토리에서 프로젝트 복제해오기 1. 보안그룹 생성 보안그룹 (1)security-group-aws-v5 80. 22 3306(내 IP, 같은 시큐리티 그룹이면 다 들어올 수 있게) (RDS 포함) (2)sg-078a86f18b5522c06(ec2가 가지고 있는 시큐리티 그룹) vpc vpc-0efdde57da278439d (RDS 포함) rds aws-v5-mariadb.cza8ywk6w952.ap-northeast-2.rds.amazonaws.com rds 타임존 ..

CI/ CD : 완성된 또는 새로운 코드가 나오면 이것을 자동으로 통합, 테스트, 배포하는 것 기존 방식은 윈도우에서 테스트 및 빌드 후, EC2를 통해 수동 배포하였기 때문에, 테스트 실행 환경이 달랐다.(배포 전 window 테스트 후 -> 배포 후 리눅스 테스트) CI/ CD는 로컬에서 깃허브 배포 -> CI(지속적 통합) 서버(AWS환경과 동일해야 함)에서 테스트, 빌드, 실행파일 생성함 : CI(countinuous integration) 서버는 AWS 서버의 실행을 보장시켜 줌 : CD(countinuous delivery 지속적 배포) 폴링: 10초에 한번씩 요청하는 것 훅: 이벤트 전달 젠킨스: 훅 방식, 트래비스: 폴링 방식 Github Action를 통해서도 무중단 배포 가능 AWS I..

전 포스트에서 배포 장소였던 EC2는 Issa로서, 해당 인스턴스에 직접 OS 및 스프링 프로젝트를 설치하여야 했다. 한편 엘라스틱 빈스톡은 PaaS로서, OS, jdk 등이 미리 설치된 소프트웨어로 편하게 사용이 가능하다. 이번에는 엘라스틱 빈스톡을 이용하여 스프링 프로젝트 배포를 진행해 보았다. 엘라스틱 빈스톡 OS 설치가 필요없음 jdk 설치가 필요없음 오토스케일링, 각종 소프트웨어 구성, 로드밸런서, 모니터링, 업데이트 버전관리 최앞단에서 클라이언트 요청 받음, 외부오픈, 80포트 (기존 ec2는 ec2가 다이렉트로 클라이언트에게 요청을 받는 구조) ↓ 요청:80 nginx 서버(프록시) 80포트 ↓ 내부적으로 호출:5000 jdk(샘플코드 동작) 5000포트 NGinx 서버 -> 외부 IP 요청..
리눅스 if 문 조건 정리. 항 목 true 반환 조건 -eq 두 값의 같이 경우 -ne 두 값이 다른 경우 -lt 오른쪽 값보다 왼쪽 값이 작은 경우 -le 오른쪽 값보다 왼쪽 값이 작거나 같은 경우 -gt 오른쪽 값보다 왼쪽 값이 큰 경우 -ge 오른쪽 값보다 왼쪽 값이 크거나 같은 경우 -z 문자열의 길이가 0인 경우 (-z $VALUE와 같이 씀) -n 문자열의 길이가 0이 아닌 경우 (-n $VALUE와 같이 씀) == 두 개의 문자열이 동일한 경우 != 두 개의 문자열이 서로 다른 경우 오른쪽의 문자열이 왼쪽의 문자열보다 정렬 시 선행되는 경우
cron을 통해 매 분마다 스프링 프로세스 종료 여부를 확인하고, 종료되었다면 해당 서버를 재시작 하는 스크립트를 제작한다. 향후 AWS 엘라스틱빈스톡/도커를 사용하면 아래 코드를 작성할 일은 거의 없다고 하나, 직접 코드를 작성함으로써 절차를 이해하였다. $변수 -> 변수의 값을 출력 혹은 실행 $(명령어) -> 명령어의 결과를 리턴 cron crontab -e 추가 * * * * * ls -l 1>>cron.log * * * * * = 분 시간 일 월 요일 = 매 시간에 실행을 하겠다는 이야기 꺽쇄 1개는 덮어쓰기 2개는 더하기 (append) /home/ubuntu에 생김 cron.log crontab -l : 크론탭에 있는 글자를 그대로 화면으로 출력 crontab -l 1>crontab_new ..
스프링 프로젝트 최초 배포 시에 필요한 깃허브 클론 및 설정 세팅 절차를 정리했다. git --version 깃허브 다운받기 gradlew 실행권한 주기 chmod u+x gradlew 자바 설치 jdk, jre sudo apt install openjdk-11-jdk gradlew 프로젝트를 jar 파일로 바꾸기 ./gradlew build 꼭 ./ 붙이기(현재 폴더라는 의미) -> build 라는 폴더가 생김 시간설정 jar 파일 실행 java -jar v1-0.0.1-SNAPSHOT.jar java -jar *.jar nohup 실행 nohup java -jar v1-0.0.1-SNAPSHOT.jar 1>log.out 2>err.out & log.out 에만 로그 남음 / 에러 발생 시 err.ou..