Redddy's Devlog

들어가며깃허브 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 등, 쌓인 레이어 등등 이미지가 어떻게 구성되어 있는지 확인할 수 있다.

docker ps -a 하면 많은 컨테이너가 뜰 것이다. 이제 이것들이 나타자니 않게 깔끔히 지워보자. docker images 를 통해 설치된 이미지를 확인하고 docker rmi [IMAGE ID] 를 통해 삭제한다. 실행되고 있는 이미지는 삭제할 수 없다. 만약 실행되고 있지 않은 이미지를 전부 지우고 싶다면 docker image prune 을 사용하면 된다. 공백으로 여러 아이디를 동시에 입력하여 지울 수 있다. 추가로 --rm을 사용하여 컨테이너가 중지되면 자동으로 제거할 수도 있다. 매우 유용하니 자주 사용하길 docker run -p 3000:80 -d --rm [IMAGE ID]

도커와 파이썬을 연결해보는 실습을 하였다. 그동안 노드로만 하다가 파이썬을 보니 매일 중국어 듣다가 한국어 들은 것처럼 매우 기뻤다...ㅎ from random import randint min_ = int(input('please enter min ')) max_ = int(input('please enter max ')) if (max_ < min_): print('Invalind input - shuttind down') else: rnd_num = randint(min_, max_) print(rnd_num) 이제 파이썬을 도커화해보자. FROM python WORKDIR /app COPY . /app CMD ["python", "rng.py"] 도커 터미널에서 이미지 빌드하고 컨테이너를 실행시킨..