Redddy's Devlog

[AWS] AWS에서 248달러 플렉스하기 - 1와 이어지는 글이다. 본론이제 NAT 게이트웨이 비용을 줄일 수 있는 방법을 찾아야 했다. 구글링해보고 친구한테도 물어보니까 NAT 인스턴스가  NAT 게이트웨이의 역할을 대신 해줄 수 있다는 것을 알았다.  둘의 주요 차이점은 NAT 게이트웨이는 AWS에서 자동 관리 해주지만, NAT 인스턴스는 사용자가 직접 관리해야한다. 그리고 NAT 게이트웨이는 NAT 트래픽 처리에 최적화된 소프트웨어를 사용하지만, NAT 인스턴스는 단순히 NAT으로 설정된 일반 AMI를 사용한다. 때문에 NAT 게이트웨이가 NAT 인스턴스 보다 고성능 및 확장성을 제공해준다.   AWS에서는 NAT 게이트웨이가 더 나은 가용성과 대역폭을 제공하고 관리에 소요되는 작업이 줄어들기 때..

서론우테코의 인프라 비용 지원이 끝나고 맞이하게 된 첫번째 달이었다. 그동안 한달에 많아봐야 70달러를 넘기지 않고 사용해왔기에, 이전하면서도 그정도 예상을 했었다. 하지만 우습게도 일주일 만에 50달러를 초과하였다. 🤑 그렇게 12월 한달간 총 248달러 사용하였다. 본론왜 이렇게 많이 나왔느냐?!! 인프라 이전 회의를 하면서 테스트 환경과 운영 환경을 동일하게 가져가기로 결론을 내렸다. 운영과 테스트의 환경이 달라 테스트에서 잡지 못했던 예외 상황들이 운영에 배포되고 나서 확인이 됐던 꽤 있었기에 이를 방지하고자 내린 결론이였다. 예를 들면, 테스트는 단일 서버라 세션 공유 문제를 겪지 않았는데, 운영은 다중 서버 환경이여서 로그인 과정에서 세션 공유 문제를 겪었다. 그리고 운영에서만 nginx를..

들어가며깃허브 organizations에서 여러 레포지토리를 만들어 작업을 하더라도 issue 나 pr 템플릿은 동일하게 가져가고 싶을 수 있다. 각 레포지토리마다 .github/ISSUE_TEMPLATE 디렉토리 만들고 그 하위에 이슈 템플릿 만들거나, pull_request_template.md 사용해서 pr 템플릿을 만들 수도 있다. 하지만 이렇게 만들면 중복된다는 문제가 발생한다!  해결예를 들어 한 organizations에 있는 backend 레포지토리와 frondend 레포지토리에서 동일한 issue 및 pr 템플릿을 사용하고 싶다면 .github 라는 이름의 레포지토리를 만들고 그 레포지토리 안에서 issue 및 pr 템플릿을 만들면 된다!    courgette 레포지토리와 aubergi..

문제우테코에서 프로젝트를 진행할 때 각 팀당 주어지는 레포지토리는 하나이다. 코딩해듀오는 백엔드와 프론트엔드 브랜치 prefix를 BE와 FE로 정하여 여기에서 작업을 하고 백엔드 코드와 프론트코드 모두 있는 브랜치는 production으로 정하였다. 다시 말해 prefix가 BE면 백엔드 코드만, FE면 프론트엔드 코드만 존재하고 production 브랜치에는 백엔드, 프론트엔드 코드 모두 존재한다.  백엔드 코드와 프론트엔드 코드 각자도생하다가 런칭 페스티벌 즈음에 production 브랜치에서 만났다. 이 브랜치에서 만나는 과정도 CI/CD 파일들이 컨플릭트 나긴 하였지만 어찌저찌 잘 해결하였다.  하지만 문제는 BE/test 브랜치에서 production 코드를 pull 땡겨와 머지하는 실수를 하..

로컬 환경에서 코드를 수정하고, add와 commit이란 작업을 하는데 commit message를 남길 때 규칙이 있다. Commit message 7가지 규칙 제목과 본문을 빈 행으로 구문한다 제목을 50글자 내로 제한 제목 첫 글자는 대문자로 작성 제목 끝에 마침표 넣지 않기 제목은 명령문으로 사용하며 과거형을 사용하지 않는다 본문의 각 행은 72글자 내로 제한 어떻게 보다는 무엇과 왜를 설명한다 Commit message 구조 다음과 같은 구조가 commit message 에서 사용되고 있다. : Type feat: 새로운 기능 추가, 기존의 기능을 요구 사항에 맞추어 수정 fix: 기능에 대한 버그 수정 build: 빌드 관련 수정 chore: 패키지 매니저 수정, 그 외 기타 수정 ex) .g..

도커 이미지가 생성될 때, 이들 폴더의 스냅샷만 복사하기 때문에 생성된 후 html 파일을 변경하여도 이미지나 컨테이너에 변경사항이 반영이 되지 않는다. 이는 개발에 있어 치명적이다. 새로운 변경사항이 생겼을 때 항상 모든 것을 다시 시작해야하기 때문이다. 이런 문제점을 해결해주는 것이 바로 바인드 마운트이다. 소스 코드를 바인드 마운트에 넣으면 컨테이너는 이를 인식하여소스 코드를 실제로 스냅샷에서 복사하는 것이 아니라 바인딩 마운트에 복사한다. 그래서 컨테이너는 항상 최신 코드를 엑세스 할 수 있게 된다. 바인드 마운트는 영구적이고 편집 가능한 데이터에 적합하다. 볼륨은 영구적이긴 하지만 호스트 머신에서의 저장 위치를 모르기에 편집은 불가능하다. 바인드 마운트 실행은 터미널에서 가능하다. 이렇게 절대 ..

도커에는 볼륨이라는 내장 기능이 있는데 이는 데이터를 유지하도록 돕는다. 볼륨은 컨테이너가 종료된 경우에도 지속되며 계속 존재하는데, 만약 컨테이너에 볼륨을 추가하면 컨테이너가 종료되어도 볼륨에 데이터가 남는다. 볼륨은 호스트머신의 폴더인데 도커 컨테이너 내부의 폴더에 매핑된다. 도커의 COPY는 복사시킬 경로와 파일의 스냅샷을 갖고 이것들을 이미지에 복사하는게 전부이며 일회성 스냅샷일 뿐이다. 컨테이너 내부의 폴더를 호스트 머신 상의 컨테이너 외부 폴더와 연결시킬 수 있다. 그렇다면 이 두폴더의 변경사항은 다른 폴더에 반영되는데, 만약 호스트 머신에 파일을 추가한다면 컨테이너 내부에서 액세스할 수 있고 컨테이너가 매핑된 경로에 파일을 추가하면 컨테이너 외부, 즉 호스트 머신에서도 사용할 수 있다. 볼륨..

Data?!! 데이터의 종류는 크게 세가지로 나눌 수 있다. Application Temporary App Data Permanent App Data 1번째 Application은 코드나 환경을 의미한다. 개발자가 작성한 코드, 이미지, 빌드한 컨테이너가 여기에 포함되고 이것들은 Read-Only 상태로 이미지에 저장된다. 2번은 임시적인 데이터인데 인풋 박스에 사용자가 입력중인 데이터가 여기에 포함된다. 이 데이터는 읽고 쓰기가 가능하다. 컨테이너에 저장된다. 마지막 3번째는 영구적인 데이터인데 사용자의 계정같은 데이터가 여기에 속한다. 읽고 쓰기가 가능하고 영구적이며 컨테이너와 볼륨에 저장된다. 위와 같은 도커 파일을 생성하고 (도커 파일 제외한 소스코드는 강의에서 제공되었음) 터미널에 다음과 같이 ..

도커로 파일을 복사하려면 다음과 같은 명령어를 입력한다. docker ps docker cp [폴더명]/. [name]:/[파일명] 파일명은 ps 를 통해 얻을 수 있다. 그리고 카피할 파일은 로컬 파일 안에 있어야만 한다. 컨테이너를 실행시키면 자동으로 이름이 할당되는데 (like 직박구리) 이 이름을 지정하려면 다음과 같은 명령어를 사용하면 된다. docker run -p 3000:80 -d --rm --name [NAME] [ID] 이제 실행시키고 중지시킬 때 조금 수월해졌다. 도커 파일은 name:tag 형식으로 되어있는데 tag 부분에 버전등을 지정할 수 있다. FROM node:12 # node 버전 12 docker build -t [NAME]:[TAG] 이런식으로 태그를 지정할 수도 있다.

생성한 이미지를 이제 확인해보자 docker images 해당 명령어 입력시 이미지ID, 사이즈 등등 이미지에 대한 정보가 출력된다. 이제 이런 이미지들의 정보를 파악하고 싶다면 아래의 명령어를 사용해주면 된다. docker image inspect [IMAGE ID] 도커의 버전, 사용중인 운영체제, 풀ID 등, 쌓인 레이어 등등 이미지가 어떻게 구성되어 있는지 확인할 수 있다.