2024.06. 개발 궁금증 링크 일기

 

 

 

 

마리아디비 예약어 목록

Reserved Words - MariaDB Knowledge Base

 

git error 111

Missing or invalid credentials 에러 처리하기 (tistory.com)

git pull이 안되는 게 이상해서 검색했더니 해결법은 황당하게도 간단했다.

 

읽어본, 읽어볼 아티클

• 6/10
  • 노션은 왜 지금 캘린더를 출시했을까? | 요즘IT (wishket.com)
• 6/12
  • 백엔드 인프라 #1 소개 및 테스트 서버만들기 (tistory.com)
• 6/13
  • 백엔드 인프라 #1 소개 및 테스트 서버만들기 (tistory.com)
  • “지금 테스트서버 쓰시는 분?” (GitOps로 브랜치별 배포 시스템 구축하기) (1/2) | by 김희철 | 레몬베이스 팀블로그 (lemonbase.team)
  • Linux/기본명령어/at - 인코덤, 생물정보 전문위키 (incodom.kr)
  • 도커 이미지 생성해보기 1편 (feat. Dockerfile) (velog.io)
  • [Docker] 도커 python 이미지 빌드 | 도커로 개발하기 :: Haonly's Blog (tistory.com)
• 6/21
  • "poetry install --no-root"의 사용 사례는 무엇입니까? - 스택 오버플로 (stackoverflow.com)

 

gpt와의 대화

• 6/13
  • 도커 컨테이너를 임시로 만들고 지울 수가 있구나???
    
    • 도커 이미지의 내용을 확인하는 방법은 몇 가지가 있습니다. 이미지를 실제로 실행하지 않고도 이미지 내부의 파일 시스템을 확인할 수 있는 몇 가지 명령어를 소개하겠습니다.
      
      1. **`docker image inspect` 명령어를 사용하여 메타데이터 확인하기**
         ```bash
         docker image inspect <이미지 이름 또는 이미지 ID>
         ```
         이 명령어는 이미지의 메타데이터를 JSON 형식으로 출력합니다. 이미지의 레이어, 환경 변수, 명령어 등 다양한 정보를 포함합니다.
      
      2. **`docker run` 명령어를 사용하여 임시 컨테이너로 내용 확인하기**
         ```bash
         docker run --rm -it --entrypoint sh <이미지 이름 또는 이미지 ID>
         ```
         이 명령어는 이미지를 기반으로 임시 컨테이너를 실행합니다. `--rm` 옵션은 컨테이너가 종료될 때 자동으로 삭제되도록 하며, `-it` 옵션은 상호작용 모드로 셸에 접근할 수 있게 합니다.
      
      3. **`docker export`와 `tar` 명령어를 사용하여 이미지 파일 시스템 추출하기**
         ```bash
         docker create --name temp-container <이미지 이름 또는 이미지 ID>
         docker export temp-container -o image.tar
         tar -xf image.tar -C /path/to/extract
         docker rm temp-container
         ```
         이 명령어들은 이미지를 기반으로 임시 컨테이너를 생성하고, 그 컨테이너의 파일 시스템을 `image.tar` 파일로 추출한 후, 해당 파일을 원하는 경로에 압축 해제합니다. 마지막으로 임시 컨테이너를 삭제합니다.
      
      이 명령어들을 사용하면 도커 이미지의 내부를 확인하고 필요한 정보를 얻을 수 있습니다. 
      
      추가적인 설명이나 도움이 필요하시면 말씀해 주세요!
• 6/14
  • 임시로 지우는 건 그냥 명령어를 바로 이용할 때만 가능
  • 명령어를 스크립트로 작성해서 sh 명령어로 구동한다면 백그라운드로 구동되기 때문에, 특정 케이스만 확인하고 바로 지울 수 있는 식의 상황이 아니라면 의미 없음
  • WORKDIR 설정의 효과
    • # 8. 작업 디렉토리 설정 WORKDIR /usr/src/app 도커파일 만들 때 이 설정을 넣어줬기 때문에 컨테이너 bash로 접근하면 저기부터 뜨는 거지? 만약 작업 디렉토리를 설정해주지 않으면 그냥 /부터 뜨나? 설정 안해도 무관하고?
      
      
      네, 맞습니다. `Dockerfile`에서 `WORKDIR` 명령을 사용하면, 컨테이너가 시작될 때 기본 작업 디렉토리를 설정할 수 있습니다. 이 설정을 사용하면, 컨테이너 내부에서 기본적으로 이동할 디렉토리가 지정됩니다.
      
      ### `WORKDIR` 설정의 효과
      
      1. **기본 작업 디렉토리 지정**:
         `WORKDIR /usr/src/app`으로 설정하면, 컨테이너가 시작될 때 기본 작업 디렉토리가 `/usr/src/app`로 설정됩니다. 컨테이너에 `bash`로 접근할 때 자동으로 이 디렉토리로 이동합니다.
         ```bash
         docker run -it my-ubuntu-python /bin/bash
         # 이제 /usr/src/app 디렉토리에서 셸이 열립니다.
         ```
      
      2. **`WORKDIR` 없이 실행 시**:
         만약 `WORKDIR`을 설정하지 않으면, 기본 작업 디렉토리는 `/` (루트 디렉토리)입니다. 즉, 컨테이너에 접근할 때 기본적으로 루트 디렉토리로 이동합니다.
         ```bash
         docker run -it ubuntu /bin/bash
         # 기본적으로 / 디렉토리에서 셸이 열립니다.
         ```
      
      3. **작업 디렉토리 설정의 유용성**:
         `WORKDIR`을 설정하면, 코드 파일이나 애플리케이션이 위치할 디렉토리를 지정하고, 컨테이너가 시작될 때 이 디렉토리에서 명령을 실행하게 할 수 있어 편리합니다. 이는 특히 여러 명령이 특정 디렉토리에서 실행되어야 할 때 유용합니다.
      
      ### 요약
      
      - **`WORKDIR` 사용**: 컨테이너가 시작될 때 기본 디렉토리를 지정합니다.
      - **설정하지 않으면**: 기본적으로 `/` (루트 디렉토리)에서 시작합니다.
      - **설정은 선택사항**: 필요에 따라 설정할 수 있으며, 설정하지 않아도 기본 동작에는 문제가 없습니다.
      
      이렇게 하면, `WORKDIR` 명령어의 역할과 설정되지 않았을 때의 동작 방식을 이해할 수 있습니다. 필요에 따라 `WORKDIR`을 설정하여 작업 환경을 더 효율적으로 관리할 수 있습니다.
  • 도커 이미지 빌드 시점 설정법과 도커 컨테이너 생성 시점 설정법이 다름
    • https://sl.bing.net/kjzkCjJKBgW
• 6/16
  • 도커파일 작성 시 RUN 명령어로 작성하는지 아니면 CMD 명령어로 작성하는지에 따라 실행 시점이 다름
    • RUN 명령어로 작성하면 이미지 빌드 시점에
    • CMD 명령어로 작성하면 컨테이너 생성 시점에
  • 도커 이미지로 컨테이너 실행하는 명령어를 스크립트로 작성할 때 --rm 옵션을 추가했다면,
    docker stop [컨테이너명]을 했을 때 동시에 삭제도 진행된다.
    결과적으로, docker ps -a 했을 때 stop 상태로 남아있는 컨테이너가 없이 지워진다.
    따로 rm을 해주지 않아도 된다.

 

 

 

최근 두 달을 보내면서 든 생각 (6/5)

내가 백엔드가 아니라면

• 프론트는 화면으로 바로 확인되니까 의문사항이 제대로 구현됐는지 바로 확인할 수 있음
• 백엔드는 실제 발생되어야 확인되는 상황들이 있어서 어떻게 되는지 발생 전에 확인 어려움

• 의문 사항이 제대로 구현됐는지 궁금할 거임

• 기능이 정확히 어떻게 만들어졌는지 궁금할 거임
• 어떻게 굴러가는 건지 궁금할 거임
• 에러 날 일은 없을지 궁금할 거임

• 예상되는 문제점이 있는 상태에서 만들었는지, 아니면 예상 못하고 만들었는지 궁금할 거임

• 예상을 했다면

• 이에 대해 나중에 어떻게 수정하는 게 좋을지 고민하고 있는지

• 고민하고 있는 방법을 공유해준다면
• 괜찮은 방법이라고 긍정을 해주거나
• 더 좋은 다른 대안을 제시하거나
• 고려해야할 점을 피드백 주거나
• 다른 대안을 고민해보는 게 좋겠다고 하거나를 해줄 수 있음

• 예상은 되는데 아직 대안이 떠오르지 않았는지

• 동일 직군은 아니지만 같이 고민해줄 수 있는지
• 동일 직군만 고민해줄 수 있는 문제일지

• 예상하지 못했다면

• 대안을 고민하도록 제시해줄 수 있음
• 에러 케이스를 미리 대비할 수 있음

생각해보니까 내가 얼마나 답답한 사람이었을지가 더 확연하게 보인다.

입장 바꿔 생각해보자를 이제서야 하다니. 어떤 이유로 생각이 닫혀 있던 걸까. 뭔가 상당히 지쳐있었던 것 같긴 하다.

그래도 왜 내가 이랬는지.. 참.. 그렇다.

 

다음 고민 대상

- 내가 팀장이라면

- 내가 대표라면

어떤 게 궁금할까, 어떤 걸 내가 물어보기 전에 팀원이 말해주길 기다릴까, 어떤 것들을 먼저 말해주면 굉장히 고마울까