인프라

어찌하다 보니 Gitlab repository에서 약 30여 개 프로젝트를 Github 리파지토리로 마이그레이션 하는 경우가 생겼습니다. 일단은 기존 저장소를 복제합니다. git clone --bare {복제할 저장소주소} 그 후 복제한 저장소의 폴더로 접근해 cd {복제할 저장소주소} 새로 옮길 저장소로 이동시킵니다. git push --mirror {옮길 저장소주소} 이렇게 여러 개의 리파지토리를 옮기는 쉘 스크립트를 작성한 후 실행 시킬 수 있습니다. * 한 번 clone 하여 push 하면 그 이후에 재실행하면 변경된 부분만 push 할 수 있습니다. 이렇게 옮기는 와중에 특정 몇몇 리파지토리가 push 할 때 다음과 같은 오류메시지와 함께 push 가 되지 않았습니다. [remote reject..

AWS의 로드밸런서인 ALB를 사용하던 중 문득 궁금함이 들어 정리해 봅니다. 왜 꼭 ALB를 썼어야 했을까? 차이점은 L4, L7 에 있었습니다. NLB가 L4, ALB가 L7 입니다. 각각 로드밸런서를 이해하기 위해서는 일단 OSI 7 계층에 대한 간략한(?) 이해가 필요합니다. 각 계층 별 사용되는 프로토콜이 존재하고, L4(Layer 4)에서 사용하는 프로토콜은 TCP, UDP, ARP L7(Layer7)에서 사용하는 프로토콜은 HTTP, FTP, DNS 등이 있습니다. 상위 레벨의 Layer는 하위 레벨 Layer를 이해할 수 있어야 합니다. 즉, L7 로드밸런서는 L4 로드밸런서의 TCP로 할 수 있는 IP, 포트로 로드밸런싱 도 가능해야 합니다. 제가 사용했던 ALB는 L7에서 동작하는 로드..

0. git init - local에 git 저장소 생성 1. git log - git commit log를 보여준다. - git log --oneline 으로 간결하게 확인가능 2. git reset (이력남기지 않고 되돌리기) HEAD^ 위치에는 git log를 통해 확인한 commit key값을 넣을 수 있다. - git reset --soft HEAD^ head commit 취소 후 staged 상태로 워킹 디렉토리에 보존 - git reset HEAD^, git reset --mixed HEAD^ head commit 취소 후 unstaged 상태로 워킹 디렉토리에 보존 - git reset HEAD~2 마지막 2개의 commit 취소 - git reset --hard HEAD^ head com..

AWS 인프라를 담당하고 있는 서비스에서 개발서버 테스트 중 메모리와 CPU를 프리티어 급 (cpu 0.25, 메모리 512mb)으로 잡아놨더니 사용률이 90프로가 넘어갔다. ECS의 작업정의 -> 새 개정 생성으로 컨테이너 성능을 스케일 업 한 후 서비스 업데이트 처리하여 스케일 업하여 정상 범위로 돌아올 수 있었고, 다시 테스트를 진행할 수 있었다.

mac/linux 기준으로 ~/.aws/credentials windows 기준으로 %USERPROFILE%\.aws\credentials 파일을 수정하여 아래와 같이 프로필을 추가한다. [default] aws_access_key_id=AKIAIOSFODNN7EXAMPLE aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY [user1] aws_access_key_id=AKIAI44QH8DHBEXAMPLE aws_secret_access_key=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY mac&Linux 기준으로 ~/.aws/config windows 기준으로 %USERPROFILE%\.aws\config 파일을..

ACM에서 생성한 인증서는 각 LB에서 등록할 수 있다. AWS 검색창 > 로드 밸런서 > 로드 밸런서 선택 > 리스너 체크 > 편집 > 443에 대한 인증서 교체 로 인증서를 변경할 수 있음

AWS Client VPN 이용 시 AWS에서 제공하는 VPN Client로 접속하려 하면, Driver 문제인지 정상동작하지 않음. 맥에서는 AWS VPN Client를 이용하고, 윈도우 환경에서는 OpenVPN을 이용하면 정상 동작된다.

AWS에 개발환경 구축 시 작업자 간 동일한 개발 DB를 이용해 개발하고 싶으나, AWS RDS의 권장사항은 퍼블릭엑세스를 허용하지 않는다. 따라서 작업자 간 동일한 DB를 이용해 개발하려면 AWS Client VPN을 사용하여 VPC 내부에서 개발 및 테스트할 수 있다. ( 다만, 비용이 발생함. ) Client VPN 엔드포인트를 설정하고 보안그룹 및 권한부여 규칙 추가 등 모든 설정을 했음에도 불구하고 VPN 연결 후 RDS에 접근할 수 없었다. 신기하게도 REDIS는 접근이 가능하여, RDS 쪽 설정을 확인하다가 퍼블릭 엑세스가 "예"로 되어있는 것을 확인 해당 옵션을 "아니오"로 바꿔주니 정상적으로 접근할 수 있었다. 정확한 원인은 모르지만, AWS Client VPN 의 분할 터널을 사용하고,..

배포 스펙 소스관리 : github (기왕이면 AWS에서 제공하는 CodeCommit을 쓰는게 나을 것 같다) 빌드 : buildspec.yml 파일 (빌드하는 과정을 정할 수 있다.) 배포 : aws code deploy에서 ecs 서비스로 배포 배포 시나리오 1. AWS CodeBuild를 통해 github repository에서 소스를 가져오고 buildspec.yml에 작성된 빌드 순서에 따라 이미지로 빌드 (spring boot 2.3 이후 부터 추가 된 gradle의 bootBuildImage task를 이용하여 Dockerfile 없이 Dockerizing 2. 빌드 된 이미지의 태그에 빌드 번호를 붙여준다. 3. 이미지를 ECR에 푸시 및 ECS 배포를 위한 컨테이너 이름 및 이미지 저장소..

api.dev.example.com 의 경우 *.example.com 와일드카드 도메인이 적용되지 않음 *.dev.example.com으로 인증서를 신청하면 개발서버도 와일드카드 도메인을 사용할 수 있다.