목록인프라 (15)
코딩기록

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..

1. 도커 작동 원리 2. 도커 컨테이너란? image: 세팅된 컨테이너 도커 컨테이너 : image가 실행된 상태

깃/깃허브를 통해 3~4인 소규모 팀에서 협업하는 시나리오를 정리하여 기록합니다. 다음 인터넷 강의 참고 : https://www.youtube.com/watch?v=2mNxZEr1m-M&list=PL93mKxaRDidFtXtXrRtAAL2hpp9TH6AWF&index=27 실행 전 : 깃허브 리포지토리 Setting -> Notifications에 메일주소 남겨놓는게 좋음 1. : 환경설정 셋팅 깃허브 리포지토리 새로 만들고 클론해서 자신 컴퓨터에서 환경설정 만듬 커밋 후 dev 브런치 만듬 다시 푸시 : git push --all (모든 브런치가 다 푸시됨) 깃허브 리포지토리 설정 settings -> Branchs -> Require a pull request before merging 체크: 보호..

git init : 이 프로젝트를 git이 관리하겠다. git remote add origin https://github.com/billups1/photogram.git 깃 커밋하는 법 git add . git commit –m “메세지” git push git reflog : 커밋내역 확인가능 git reset --hard ~~~~ : 복구 가능 (soft, mixed, hard) git branch ~~~ 브런치 생성 git checkout ~~~ 브런치 변경 git checkout –b ~~~ 브런치 생성하면서 체크아웃 git merge ~~~ ~~~브런치와 합체함 - fast forward merge 형상이 똑같을때 - 3-way merge 형상이 다를 때 git merge --no-ff [joi..
재배포 절차는 다음의 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 요청..