mkdir testdir
touch testdir/a.txt
chmod 600 testdir/a.txt
su test
cat testdir/a.txt

이 상태로 접근해보려고 하면 당연히 이렇게 permission denied가 뜬다.

문제1. testdir 디렉토리에 대한 other 접근 권한이 부여되지 않음 문제2. a.txt에 대한 other 접근 권한이 부여되지 않음

그래서 chmod 605 testdir(읽기권한r+실행권한x)로 바꿔주면

읽기권한과 실행권한을 추가해주어 ls로 접근이 잘 되는것을 확인할 수 있다.

이제 chmod 704 testdir/a.txt로 a.txt파일을 읽을 수 있는 읽기 권한 까지 주면

(a.txt는 빈 파일이다) 문제없이 접근이 잘 된다.

2️⃣사용자(user)는 계정의 정체성! 리눅스의 user는 로그인 계정 = windows의 사용자 계정

root
ubuntu
test

이 사용자별로 홈 디렉토리가 있음
/home/root
/home/ubuntu
/home/test

3️⃣(중요)세션(session): 누가, 어떤 계정으로, 어떤 터미널에서 접속했는가. 하나의 터미널에는 한 명의 사용자가 로그인 상태로 존재. ssh, su, sudo 같은 명령은 이 “세션의 사용자 신분”을 바꾸는 것

한 컴퓨터에서 터미널 3개를 열면 이렇게 3개의 세션이 생김.

4️⃣ssh와 su의 차이

예시

# 현재 로컬 PC의 gut 계정에서,

ssh test@172.23.28.7
→ "다른 컴퓨터의 test 계정"으로 들어감 (IP 필요)

su test
→ "같은 컴퓨터" 안에서 test 계정으로 임시 전환

5️⃣ “현재 디렉토리”는 사용자와 독립적인 상태 현재 디렉토리는 “지금 작업 중인 폴더 위치”를 말하고, 사용자와는 별개!

• pwd로 확인
• cd로 이동

예시

cd /home/gut
su test

이렇게 하면 여전히 /home/gut에 머무른 채 test 사용자로 바뀝니다.

반면에 su - test

이렇게 하면 로그인 셸로 바뀌며 자동으로 /home/test로 이동합니다.

6️⃣ 여러 터미널을 열었을 때의 관계

터미널이 여러 개일 때는 각 터미널 = 각각 독립된 세션. 즉, 서로 영향을 주지 않는다.

예를 들어 두 창을 열어서:

창 1: ssh gut@172.24.48.1

창 2: ssh test@172.24.48.1

→ 둘 다 같은 서버(같은 WSL)에 접속하지만, 서로 다른 로그인 세션이라 각자의 환경(whoami, pwd, ps)이 다르다.

심지어 같은 사용자로 접속해도 세션은 분리되어 있습니다:

ssh gut@172.24.48.1    # 첫 번째 창
ssh gut@172.24.48.1    # 두 번째 창

→ 같은 계정이지만 프로세스·PID·환경변수·셸 인스턴스가 전부 다름.

7️⃣ 요약

(중요) 파일에 접근하기 위해서는, 그 파일이 위치한 모든 상위 디렉토리에 대한 ‘x(실행)’ 권한이 필요하다.

💡 추가 팁: 시각적으로 확인하기

아래 명령으로 세션 상태를 명확히 볼 수 있습니다:

whoami      # 현재 사용자
pwd         # 현재 디렉토리
hostname    # 접속한 시스템 이름 (WSL 이름 or 서버 이름)
echo $USER  # 환경변수에 저장된 사용자 이름

이 네 가지를 항상 같이 쳐보세요. 그럼 “아, 지금은 누구로 어디 접속했고 어디 디렉토리에 있구나”가 한눈에 정리됩니다.

👌목표: flask를 사용한 flaskApp.py를 Dockerfile을 이용해 이미지화해서 컨테이너로 띄우기

1. flask 기본 코드

from flask import Flask
from urllib.parse import quote as url_quote

app = Flask(__name__)

@app.route('/')
def hello():
    return 'hello flask world'

if __name__ == '__main__':
    app.run(host="0.0.0.0", port=3000)

2. Dockerfile 작성

FROM python:3.9

COPY requirements.txt requirements.txt
RUN pip install -r requirements.txt

COPY . /app

WORKDIR /app

CMD [ "python","flaskApp.py"]

이때 다른 dockerfile과는 다르게 requirements.txt라는걸 넣는데, requirements.txt에는 이렇게 입력하자.

Flask==2.0.3
Werkzeug==2.0.3

이렇게 입력하는게 생각보다 중요하다(이유는 밑에서)

3. docker 이미지만들고 컨테이너로 띄우기

docker build -t flask-app . 도커 이미지를 빌드한다.

docker run -d -p 3000:3000 flask-app 도커 컨테이너를 실행한다. -d : 백그라운드에서 -p : 포트포워딩 3000:3000 호스트포트:컨테이너포트 잘 뜨는걸 확인할 수 있다.

트러블슈팅

error1. ImportError: cannot import name 'url_quote' from 'werkzeug.urls'

진심 이거 때문에 1시간 정도 썼다. Flask와 Werkzeug의 버전 차이 문제로 인식하고 스택오버플로우랑 레딧 참고해서 링크 했는데도 계속 같은 오류가 나길래 gpt한테 물어봤더니 pip install flask==2.0.3 werkzeug==2.0.3로 다운그레이드 필요 라고 알려줬다. 근데? 이렇게 해도 안됬다. 그리고 docker ps -a해보니 세상에

docker run으로 생성된 컨테이너가 exited된채 한가득! 무한 제공 이벤트!^^

그래서 docker container prune으로 exited된 컨테이너 다 지워줬다.

다시 docker run해서 띄워보니 문제 해결!

error2. ERR_EMPTY_RESPONSE

근데? 두번째 문제 발생. 페이지가 로드가 안됬다. (뭐에요)

이유를 찾아보니

Flask를 기본 설정으로 실행하면 127.0.0.1(로컬 루프백) 에서만 바인딩돼서 도커 컨테이너 밖에서는 접근할 수 없다.

app.run(host="0.0.0.0", port=3000) 이렇게 수정해줬더니 잘 됬다.

마무리

다음에 계속~

첫번째는 달력 만들기.

정말 nice 하게도 이미 module이 있어서 그걸 import해서 사용하기만 하면 되는게 좋았다.

1. code

a = input("input Year:")

a = int(a)
print(calendar.calendar(a))

2. Trouble Shooting (not supported between instances of 'int' and 'str')

비교하려는 객체의 type이 맞지 않아 발생한 error라고 한다.

그래서 type()으로 변수 a의 타입을 확인하니 string이었다. input()함수로 받는 값의 type은 기본적으로 string. type casting을 해주면 되는데 정말 간단했다. a= int(a)이렇게만 해주면 문제 없이 type casting(형 변환)이 된다.

3. 결과 사진

(중간에 Jul, Aug랑 Sep안보이는데 width가 좁아서 그런거다:)

4. A bit more advanced(조금 더 발전된)

[A bit more advanced, 주로 기술이나 기능이 발전된 대에 쓴다고 한다]

심화에 특정 달만 출력 하는게 있어서 이걸 if문을 이용해 적용했다.

# 연도 전체 or 특정 달 출력
import calendar

choose = input("'entire year' or 'specific month': ")
year = int(input("input Year: "))

if (choose == 'entire year'):
    print(calendar.calendar(year))
elif(choose == 'specific month'):
    month = int(input("input month: "))
    print(calendar.prmonth(year,month))
else:
    print("error")

5. finish(마무리)

예전에 배운걸 간단한 것 부터 복습하니 재밌었다. 띄어쓰기 잘 지켜야하는건 약간 shell script를 닮은거같기도 하고.. 나는 처음부터 이론 먼저 보고 공부하는 스타일보단 냅다 실습하면서 필요한 부분만 알아가는 스타일이 더 맞는 것 같기도 하다. 다음 미니 프로젝트는 [숫자 맞추기 게임]! 조만간 돌아옵니다 :)

참고 블로그

• Python : calendar - 달력 관련 라이브러리
• [python] 파이썬 타입 변환, 형변환 (float, int, str, chr, bool)

Dockerfile에서 WORKDIR은 어떤 역할을 할까?

Dockerfile?

docker image를 생성하기 위해 작성해야하는 파일이다.

문법은 어떻게 되요?

기본적으로 이렇게 쓴다. (node.js 기준)

FROM node:20

WORKDIR /app/start

COPY package*.json ./

RUN npm install
COPY . .
EXPOSE 3000
CMD ["node","app.js"]

각 명령어에 대한 설명은 이 블로그를 참고하자.

• Docker로 Node.js 서버 컨테이너 만들기

1. 그래서 WORKDIR이 왜요?

구글링으로 WORKDIR을 검색했을때 리눅스 명령어 cd와 비슷한 명령어래서 "아 그럼 실행하면 실제로 현재 위치가 바뀌거나 이동되나?" 싶었다. 그래서 docker run으로 실행해봤는데도 바뀌는게 없었다. 뭐지? 싶어서 GPT에게 물어봤다.

📌 알아둬야 할 핵심 개념 3가지 1. 컨테이너 내부 디렉토리 경로 설정

• Dockerfile 내 이후의 명령어(RUN, CMD, COPY, ADD)들이 어느 디렉토리 기준으로 실행될지를 정함.
  예시:

  WORKDIR /app/start
  COPY . .  # => 컨테이너 내부의 /app/start 기준으로 현재 폴더가 복사됨

• 2. 디렉토리가 없다면 자동 생성됨*
• /app/start가 존재하지 않아도 자동으로 만들어짐. 단, 이건 컨테이너 이미지 안에서만 보임.
• 호스트(EC2, PC) 파일시스템에는 아무 변화도 없음. 그래서 밖에서 보면 아무것도 안 생긴 것처럼 보임.

• 3. 호스트랑 컨테이너는 다른 세계*
• Dockerfile이나 컨테이너 내부에서 설정한 디렉토리는 호스트에 영향을 주지 않음.
• Docker는 격리된 가상 환경을 만들기 때문이야. 외부에 /app/start가 생기지 않는 게 맞는 동작이야.

첫번째 요약

그럼 직접 컨테이너 내부로 들어가볼까?

좋은 생각이다. 들어가보자.

docker run -it --rm your-image-name sh혹은 docker run -it --rm your-container-name sh로 컨테이너 내부에 들어갔다.

ls를 해보면? 뭔가 뜨는거같긴 하고?

2. 근데 왜 /app/start가 안뜨죠?

이때 가장 먼저 해야할 것은 pwd로 현재 위치 확인하기다.

pwd로 확인했더니 현재 경로가 /app/start임을 확인할 수 있었다.

3. 왜 프롬포트에 경로 명시가 안되지?

이건 docker container 내부로 sh로 들어가면 이렇게 나온다고 한다.

sh는 PS1(프롬프트 표시 형식)이 단순해서 경로를 표시하지 않음. 예: 그냥 # 만 나옴

흔히 우분투에서 보는 cli처럼 경로가 보이게 하려면 bash를 설치해주고 bash로 들어가면 된다.

apt update && apt install -y bash
bash

경로가 잘 보이는 걸 확인할 수 있다!

4. 그냥 cd 치고 ls -al해도 아무것도 안나와요..

왜이럴까 싶었다. 이유는 단순했다. 아무것도 안 넣어서요.

마무리

dockerfile쓰면서 이해가 안됬던 부분이라 실습하면서 이해되서 재밌었다.

쿠버네티스: 컨테이너화 된 애플리케이션을 효율적으로 배포하고 운영하기 위해 설계된 오픈소스 플랫폼

컨테이너를 쓰는 이유1: 애플리케이션 실행에 필요한 라이브러리나 운영체제 패키지등을 모두 담아서 불변의 실행환경을 만듬. 이렇게 하면 개발자든간, 테스트와 운영 환경 간의 차이를 없앨 수 있음.

컨테이너를 쓰는 이유2

1. 인프라의 사용률 향상
2. 빠른 기동 시간
3. 불변 실행 환경

쿠버네티스는 크게 4가지의 기능 제공

• 배포 계획에 맞춰 애플리케이션 신속 배포 가능
• 가동 중인 애플리케이션을 스케일 업/다운 할수 있음
• 새로운 버전의 애플리케이션을 무정지 업그레이드 가능
• 하드웨어 가동률을 높여 자원 낭비를 줄임

쿠버네티스의 아키텍처: 클러스터 관리를 담당하는 마스터와 컨테이너화된 애플리케이션을 실제로 실행하는 노드 단 두 종류의 서버로 구성

가상 서버(ex VMWare)와 비교했을때 컨테이너는 경량, 빠른 기동, 이식성의 장점을 가진다.

도커는 도커 데몬 서버와 클라이언트인 도커 커맨드, 그리고 이미지의 보관소인 레지스트리로 구성된다.

• (1) 도커 데몬: 클라이언트인 도커 커맨드의 명령을 받아들여서 도커 오브젝트인 이미지, 컨테이너, 볼륨, 네트워크등을 관리

• (2) 도커 클라이언트: 컨테이너를 조작하는 커맨드라인유저 인터페이스로 도커 데몬의 클라이언트다. 도커 api를 사용하여 도커 데몬의 요청을 보낸다.

• (3) 이미지: 읽기 전용인 컨테이너의 템플릿, 컨테이너를 기동하기 위한 실행 파일과 설정 파일의 묶음,컨테이너를 실행하면 이미지에 담긴 미들웨어나 애플리케이션이 설정에 따라 기동.

• (4) 컨테이너: 하나의 프로세스, 정확히는 '실행 가능한 이미지의 인스턴스'

• (5) 도커 레지스트리: 컨테이너의 이미지가 보관되는 곳

레지스트리와 리포지터리의 차이 레지스티리: 리포지터리를 여러개 가지는 보관 서비스 리포지터리: 하나의 이미지에 대해 태그를 사요하여 다양한 출시 버전을 함께 보관

퍼블릭 레지스트리: 누구나 이용할 수 있도록 공개된 레지스트리 클라우드 레지스트리: 퍼블릭 클라우드가 제공하는 레지스트리 서비스 비공개 레지스트리: 회사나 팀 전용으로 레지스트리를 구축하여 운영하는 경우에 해당

쿠버네티스에서 컨테이너가 동작할 때까지의 흐름을 설명하면 다음과 같음

1. docker build로 이미지를 빌드한다.
2. docker push로 이미지를 레지스트리에 등록한다.
3. kubectl커맨드로 매니페스트에 기재한 오브젝트들의 생성을 요청한다
4. 매니페스트에 기재된 리포지터리로 부터 컨테이너의 이미지를 다운로드한다.
5. 컨테이너를 파드 위에서 기동한다.

쿠버네티스는 도커를 컨테이너의 런타임 환경으로 사용함, 그래서 쿠버네티스를 설치할때 제일 먼저 도커를 설치해야함

• 오브젝트: k8s클러스터 내부의 엔티티로서, 파드, 컨트롤러, 서비스등의 인스턴스를 의미, 지정된 상태가 유지되도록 쿠버네티스에 의해 제어

• 워크로드: 오브젝트의 카테고리를 나타내는 용어로 컨테이너와 파드, 그리고 컨트롤러의 그룹을 의미

• 컨테이너: 쿠버네티스에서는 컨테이너를 독자적으로 실행하는 것이 불가능, 반드시 파드 내에서 실행해야한다.

• 파드(pod): 컨테이너를 실행하기 위한 오브젝트. 한개 혹은 여러개의 컨테이너를 담을 수있다.

컨트롤러: 파드의 실행을 제어하는 오브젝트
설정: 컨테이너 내 애플리케이션의 설정값이나 비밀번호 등의 정보된 배포된 네임스페이스로부터 취득하는 것이 좋음
서비스: 파드와 클라이언트를 연결하는 역할 수행
스토리지: 파드나 컨테이너는 실행 시에만 존재하는 일시적인 존재이기 때문에 중요한 데이터를 컨테이너의 파일 시스템에 저장해서는 안된다. 
데이터를 잃지 않기 위해서는 퍼시스턴트 볼륨을 사용하여 전원이 꺼져도 데이터가 유지되는 스토리지 시스템에 데이터를 저장해야한다. 

파드(Pod)는 하나의 목적을 위해 만들어진 컨테이너를 부품처럼 조합할 수 있도록 설계됨

1. 파드 내부의 컨테이너들은 파드의 ip주소와 포트번호를 공유
2. 파드의 내부 컨테이너들은 localhost로 서로 통신 가능
3. 파드의 내부 컨테이너들은 system V 프로세스 통신이나 POSIX 공유 메모리를 사용하여 서로 통신 가능
4. 파드의 내부 컨테이너들은 파드의 볼륨을 마운트하여 파일 시스템을 공유할 수 있다. 파드의 IP주소는 기동 시 부여(고정X),종료시 회수되어 다른 파드가 기동할때 사용됨. 파드에 요청을 보내고 싶은 경우에는 반드시 서비스를 사용해야함

서비스는 클라이언트로부터 요청을 지정한 파드의 그룹에 부하분산하며 전송하는 역할을 담당

EC2에 Nginx 설정 /etc/nginx/sites-available 설정법 프록시 설정: 80 → 3000번 포트(예시)

참고사항 오늘 실습 전체의 흐름은 참고 첫번째 링크에 다 나와있다! 원래 nginx랑 certbot으로 https 적용을 한 포스트 안에 다하려고 했는데 아차차! nginx 설정만 해도 오류가 많아 나누게 되었다

실습을 진행하며 생긴 오류 순서대로 번호를 부여했고, 내용이 다 이어져있어 뒤에 내용까지 보면 이해가 될거라 생각한다.

이번 포스트는 약 2시간 넘게 오류만 고친 사람의 기록이다 (정신 찵이고 포스트 찵여.)

이번 실습은 GPT를 쓰지 않고 진행했다.(그래서 마지막 부분이 안풀리고 있다)

1. Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 884 (unattended-upgr)

sudo apt-get install nginx를 시도하던 중 발생한 오류

구글링 → process 884에 lock이 걸려있다. 이걸 지우면 해결. → ps -ef로 확인 → ? 884번 프로세스는 없었음. 차분히 다시 sudo apt-get install nginx를 입력하니 다른 오류가 떴다.

2. You don't have enough free space in /var/cache/apt/archives/.

공간이 부족하다!

구글링 → df -h로 상태를 확인해보니 /dev/root의 용량을 100% 전부 다 썼음을 확인 할 수 있었다.

EC2 인스턴스 볼륨의 용량 부족문제 임을 확인 하고 볼륨 수정하여 8 GiB → 32GiB로 늘려줬다. (내 요금 ^_ㅜ) 볼륨만 수정했다고 끝이 아니다. 사용하던 파티션을 늘린 용량만큼 확장 해줘야한다. lsblk로 디스크 상태를 확인해보면, 밑에 있는 xvda1이 변경해줘야할 파티션이다. → xvda1 파티션을 확장해보자

growpart라는 파티션을 확장해 주는 명령어를 사용한다.

#sudo growpart /dev/파티션명 파티션번호
sudo growpart /dev/xvda 1

3-1. cannot create directory ‘/tmp/growpart.908’: No space left on deviceFAILED: failed to make temp dir

얘도 뭔가 저장공간의 문제.

블록 디바이스에 남은 공간 없음 오류를 방지하려면 임시 파일 시스템 tmpfs를 /tmp 탑재 지점에 탑재합니다. 그러면 /tmp에 탑재된 10M tmpfs가 생성됩니다.

sudo mount -o size=10M,rw,nodev,nosuid -t tmpfs tmpfs /tmp 이렇게 입력 후 다시 sudo growpart /dev/xvda1 해주면 되는 줄 알았다.

3-2. GPT PMBR size mismatch (16777215 != 67108863) will be corrected by write. The backup GPT table is not on the end of the device.

sudo sfdisk --list /dev/xvda로 파티션 테이블을 확인하려 했는데 발생한 오류.

root로 전환 후 parted라는 명령어를 사용하여 GPT 정보를 수정하여 오류를 해결했다.

이렇게 입력해준 후 다시 fdisk를 해보면 에러메시지가 사라져있다.

(중간에 도커 이미지/컨테이너 크기땜에 부족한 줄 알고 지우려다가 도커 데몬 이 실행이 안되서 헤맨건 안비밀.. 여전히 모르겠다)

→ 이제 파일 시스템에 변경된 파티션 크기를 적용하자 sudo resize2fs /dev/xvda1 입력 후 다시 df -h로 확인해보면 짠 사용공간이 늘어났음을 확인했다!

이제 다시 nginx 설치로 돌아가서,

sudo apt-get install nginx 실행 근데 실행 중 failed가 자꾸 뜨고 안되길래 apt-get update해줬는데도 계속 오류가 떴다.

4. Some index files failed to download. They have been ignored, or old ones used instead.

DNS 서버 확인 후 수정하라길래 그대로 했다. vi /etc/resolv.conf에 nameserver 8.8.8.8을 추가하여 저장.

다시 apt-get update시도하니 업데이트가 잘 됬다.

5. sudo: unable to resolve host ip주소: Name or service not known

뭔가를 알 수 없다..?

/etc/hostname과 /etc/hosts 두 파일의 내용이 달라서 그렇다고 한다. 나는 /etc/hostname에 있는 ip주소를 /etc/hosts에 그대로 넣어줬다.

여기까지하면 그제야 sudo apt-get install nginx을 할 수 있다.

service nginx start로 nginx 실행 후 http://localhost:80으로 접속(http가 80번 포트를 의미하기에 생략 가능)

/etc/nginx안에서 주요하게 봐야할 것

• site-available/: nginx에서 관리되는 호스트 정보

• site-enabled/: site-abailable/에서 만든 사이트를 site-enabled/에 추가해야 활성화 됨. site-available/에 추가한 사이트를 site-enabled/에 심볼릭 링크하여 사이트를 활성화 할 수 있습니다.

nginx 설치시 기본으로 설치된 설정 파일 제거 → 1. 서버 생성(참고 첫번째 링크에 있음) → 2. site-available 사이트 추가

vim /etc/nginx/site-available/server1에 아래 코드 입력 후 저장

server {
        listen 80 ;
        listen [::]:80;

        root /home/server1;
        server_name server1 www.server1.com;

        access_log /var/log/nginx/server1.access.log;
        error_log /var/log/nginx/server1.error.log;

        location /server1/ {
                proxy_pass http://127.0.0.1:3000/;
        }
}

3. site-enabled 사이트 활성화

마지막으로 site-available에 추가한 사이트를 site-enabled에 심볼릭 링크로 연결

ln -s /etc/nginx/sites-available/server1 /etc/nginx/sites-enabled/server1

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

nginx -s reload하면 curl http://localhost:3000시 응답이 잘 오는 것 처럼 웹사이트에도 응답이 떠야하는데 난 계속 404 NOT FOUND만 떴다.

6. Command 'nvm' not found

shell 에서 nvm을 실행시킬 때 필요한 환경변수가 제대로 세팅이 되어있지 않아서 생긴 문제라고 한다.

자신이 쓰는 쉘에 따라 방법이 조금 다르다. 난 bash를 쓴다.

bash 인 경우: vi ~/.bashrc zsh 인 경우: vi ~/.zshrc

키보드 i 를 누르고 아래 코드를 입력하고 ESC 키를 누르고 :wq! 입력

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

그리고 터미널을 재로그인하거나, source 명령어로 스크립트 실행

source ~/.bashrc or source ~/.zshrc

7. had too many unstable restarts (16). Stopped. "errored"

pm2 log 찍으면 계속 나오는 에러메시지

뭘 하지도 않았는데 reload가 저렇게 많이 된다고? (당황)

찾아보니 오래된 버전의 라이브러리가 있다면 이럴 수도 있대서 지우고 다시 설치했다.

pm2 kill
rm -rf node_modules
npm i
authbind --deep pm2 start app.js

여전히 해결이 안된 부분

• localhost/server1로 접속한 웹사이트에 응답이 뜨지 않고 계속 404 NOT FOUND로 뜬다. 아무리 검색해도 안나와서 이건 GPT한테 후에 물어보고 고친 후 다시 포스트 업로드 해야겠음.

• 여전히 도커 데몬이 실행되지 않는다... 으악!

• 그리고 pm2 상태가 계속 바뀐다. 건들지 않아도 어쩔땐 online이다가 어쩔땐 errored였다가..

쓰다보니 /etc/nginx/sites-available 보단 그냥 오류 나열에 가까워지게 된거같다.. 정리해서 쓰는게 너무 어렵다 일단 쓰고 봐야한다.

궁금한 점

• 분명 npm init으로 초기화를 했는데 왜 ./bin/www가 안생겼지?
• 내가 재접속을 안했는데 왜 reload 수가 늘어나지?
• 파티션과 디스크 쪽의 정확한 개념들과 자세한 설명 필요

이어서 해야할 것

• certbot으로 https 적용
• docker demon 안돌아가는 거 고치기
• 도커/쿠버네티스 책 첫파트 블로그 업로드
• 개인 도메인 복구
• python 공부 → 블로그 업로드

참고

• [nginx] nginx 시작하기 1/3 - 기초편
• [ubuntu] Could not get lock /var/lib/apt/lists/lock. Error
• EC2 'No space left on device' 파일 시스템에 남은 공간 없을 때 EBS 볼륨 크기 늘리기
• 리눅스 디스크 에러 복구
• EC2 용량 늘리기
• [EC2][Server][Docker] EC2 용량 꽉 찼을 때 해결 / No space left on device 해결
• [Ubuntu ] Some index files failed to download. 에러 해결
• unable to resolve host 에러 해결 방법
• bash: nvm: command not found 에러 해결
• (에러핸들링) (AWS EC2) had too many unstable restarts
• [ERROR] command not found: nvm
• Node.js PM2 간단 정리

EC2에서 docker-compose down && docker-compose up -d 를 자동으로 돌리는 bash script 만들기(crontab 이용)

실습 전 궁금했던 것

전 포스트들을 보면 알 수 있듯 난 이미 deploy.yml에 docker-compose를 재시작하도록 코드를 작성해두었는데, 왜 EC2안에서 한번 더 해야할까? 라는 궁금증이 생겨 GPT에게 물어봤더니,

GPT 답변: 그 deploy.yml이 GitHub Actions Workflow 파일이라면, 그건 "내가 GitHub에 push할 때 EC2에 git pull하고, docker-compose 재시작하는 것"을 자동화한 거지. 근데 그건 "코드가 바뀌었을 때만" 실행되잖아. 예를 들면: 코드 변경 → push → GitHub Actions → EC2에서 재시작 그런데 만약: 코드 변경 없이, EC2에서 컨테이너가 죽었다거나, 서버가 오래 켜져 있어서 리소스가 부족하다거나, 컨테이너가 이유 없이 멈췄다거나 이런 경우에도 주기적으로 EC2를 재시작하거나, docker-compose를 재시작하게 하면 서버의 안정성이 높아지는 거야.

요약하면 서버의 리소스 회수, 메모리 누수 방지, 컨테이너 안정화를 위해 자동화 스크립트를 작성해주는 게 좋다고 한다.

난 내 EC2를 항상 켜두진 않기 때문에(요금이 ^_ㅜ) 굳이 필요할까? 싶었지만 알아두면 좋을 것 같아 실습 해봤다.

1. docker-compose 재시작 스크립트 작성하기

간단하다 스크립트 파일을 하나 만들어 docker-compose down과 docker-compose up -d를 적어주면 된다

#!/bin/bash

echo "[$(date)] Restarting Docker containers..." >> /home/ubuntu/restart.log

docker-compose down
docker-compose up -d

echo "[$(date)] Restart complete." >> /home/ubuntu/restart.log

GPT가 로그 파일도 남겨두는게 좋다고 추천해줘서 로그파일을 남길 수 있도록 코드를 추가했다.

2. crontab 작성 후 실행되는 지 확인하기

여기서 잠깐, crontab이 뭘까?

윈도우의 스케쥴러와 비슷, "특정 시간에 특정 작업"을 해야할 때 crontab으로 작업을 설정해줄 수 있다.

• crontab -e를 입력 하면 텍스트 에디터를 고르는 창이 뜰텐데 nano로 선택하는게 편하다 :)
• 참고로 crontab -l을 하면 crontab에 어떤 내용이 들어있는지 알 수 있다.
• 주기 결정 다섯개의 을 모두 입력하면 *매 분**마다 실행한다.

  #매주 금요일 오전 5시 45분에 test.sh 를 실행
  45 5 * * 5 /home/script/test.sh
  

#매일 매시간 0분, 20분, 40분에 test.sh 를 실행 0,20,40 * * * * /home/script/test.sh

#매주 수요일 오전 11시에 restart.sh를 실행 0 11 * * 3 /home/ubuntu/restart.sh

원하는 주기 대로 시간을 입력해주고 저장하면 정해둔 시간마다 작업이 실행된다.

### UTC -> KST로 바꾸기
crontab 실행 전 bash restart.sh로 실행 시켰을때 찍힌 로고의 date가 UTC 기준으로 떠서 정확한 시간이 맞는지 확인하기 쉽지 않았다.

바로 구글 검색을 해 ```tzdata``` 패키지를 알아냈고 설치했다.

sudo apt -y install tzdata sudo timedatectl set-timezone Asia/Seoul timedatectl date

date를 찍어보면 _Wed Jul 23 12:23:27 KST 2025_ 라는 결과가 잘 나온다.

### [한번에 되는 건 없어요] 문제 해결
실습할 때 한번에 제대로 진행된 적이 없듯 오늘도 그랬다.
미리 설정해두지 않은 여러 절차가 있었다.

1. restart.sh를 실행 파일로 바꾸기: 정말 당연하고 간단한건데 까먹었었다.
```chmod +x restart.sh``` 해줘야한다.
2. PATH 명시하기:
bash로 실행시켰을땐 잘 됬었는데 crontab에선 실행이 안됬다. crontab은 기본 쉘과 기본 경로가 제한적 이어서 PATH를 명시해줘야 한다고 한다.
```PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin``` 첫 줄 밑에 적어주었다.
3. 스크립트 안에서 쓰는 명령어의 절대경로 필요: 2번까지 했음에도 안됬었다. 추가 방법이 명령어의 절대경로를 적어주는 거였는데,
```which docker-compose``` 이렇게 적어 docker-compose 명령어의 절대 경로를 확인 후 스크립트에 절대경로로 명령어를 적어주는 것이다.

수정코드

#!/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

LOGFILE="/home/ubuntu/restart.log" echo "[$(date)] Restart script start" >> $LOGFILE

sudo /usr/local/bin/docker-compose -f /home/ubuntu/Devops/docker-compose.yml down >> $LOGFILE 2>&1 sudo /usr/local/bin/docker-compose -f /home/ubuntu/Devops/docker-compose.yml up -d >> $LOGFILE 2>&1

echo "[$(date)] Restart script complete" >> $LOGFILE

_참고: 2>&1은 에러도 같은 파일로 리다이렉트_

근데 docker의 절대경로는 ```usr/bin/docker```던데
왜 docker-compose는 ```usr/local/bin/docker-compose```일까? 신기하네..


작성 중에 vi 에디터를 써서 편집도 했는데,
단어 치환이 필요해서 검색으로 찾아내어 적었다.
%s/[원본단어]/[바꿀단어]/옵션 ex) ```%s/myapp/Devops/g```
g는 전역을 의미.

### 최종 확인
![](https://velog.velcdn.com/images/park-rgb125/post/4b2c491a-0fe2-40da-8713-e6a6d808b1d5/image.png)
restart.log를 cat했을때 로그가 잘 남아있는 걸 확인 할 수 있었다.
UTC -> KST로 바뀐거 보니까 마음이 편안하다.

다음은 Nginx + HTTPS 복습을 할 것 이다.

> 학습 참고 링크 출처:
- [리눅스 크론탭(Linux Crontab) 사용법](https://jdm.kr/blog/2)
- [[Linux] 리눅스 timezone 설정 UTC에서 KST로 변경하기](https://bosungtea9416.tistory.com/entry/Linux-%EB%A6%AC%EB%88%85%EC%8A%A4-timezone-%EC%84%A4%EC%A0%95-UTC%EC%97%90%EC%84%9C-KST%EB%A1%9C-%EB%B3%80%EA%B2%BD%ED%95%98%EA%B8%B0#:~:text=%ED%99%98%EA%B2%BD%EC%9D%80%20EC2%EC%9D%98%20Amazon%20Linux2%EC%9D%B4%EB%A9%B0%2C%20%EA%B8%B0%EB%B3%B8%EC%A0%81%EC%9C%BC%EB%A1%9C%20%EC%84%A4%EC%A0%95%EB%90%98%EC%96%B4%20%EC%9E%88%EB%8A%94,%EA%B0%99%EC%9D%B4%20%EC%88%98%EC%A0%95%20ZONE=%22UTC%22%20UTC=true%20%23%20/etc/localtime%20%ED%8C%8C%EC%9D%BC%EC%9D%84)
- [vi editor 텍스트 치환(변경)하기](https://cchhoo407.tistory.com/3)
- Chat GPT

GitHub에 Push하면 EC2 서버에서 자동으로 git pull + Docker Compose 재시작되는 흐름을 만든다.

🧩 실습

1. EC2에서 SSH 키 발급

aws EC2 인스턴스가 이미 있다는 가정하에 진행한다. 인스턴스로 접속하여 해당 코드를 입력해 SSH 키를 발급한다.

ssh-keygen -t rsa -b 4096

2. 공개키를 GitHub에 등록 (Settings > Deploy Keys)

SSH 키를 발급받으면 공개키와 비밀키를 함께 받을 수 있다.

공개키 확인방법

cat ~/.ssh/id_rsa.pub

여기로 들어가면

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA7... (생략) ...==

요런 긴 문자열이 있다. 이 전체 문자열을 복사하자.

3. GitHub 레포지토리로 이동

• GitHub에서 너의 프로젝트 레포로 이동
• Settings > Deploy keys로 이동
• Add deploy key 클릭
• Title: EC2 Deploy Key
• Key: 복사한 공개키 붙여넣기
• Allow write access 체크 (git pull이니 읽기만 필요하지만, push도 할거면 체크)

4. 추가 완료

이러면 EC2에서 git pull 할 때 비밀번호 없이 SSH 키로 인증할 수 있다.

5. GitHub Actions 워크플로우 만들기

내가 GitHub에 푸시하면 → EC2가 자동으로 코드를 pull하고 → docker-compose를 재시작하게 만든다. (이 부분이 제일 어려웠고 오래걸렸다..)

• 로컬 프로젝트에 아래 경로에 디렉토리 만들기: .github/workflows/deploy.yml

• 그리고 deploy.yml에 다음 코드 넣기:

  name: Deploy to EC2
  

on: push: branches: [ main ]

jobs: deploy: runs-on: ubuntu-latest steps: - name: SSH and deploy uses: appleboy/ssh-action@master with: host: ${{ secrets.EC2_HOST }} username: ${{ secrets.EC2_USER }} key: ${{ secrets.EC2_SSH_KEY }} script: | cd /path/to/your/project git pull origin main sudo docker-compose down sudo docker-compose up --build -d

/path/to/your/project → EC2에서 내 프로젝트 경로로 바꿔준다.
- EC2에서 내 프로젝트 경로 확인하는 방법: EC2 접속 -> git clone 해당 레포지토리 -> 클론한 프로젝트로 cd 한후 pwd입력하면 내 프로젝트 경로가 나온다. 실습할 때 나는 ```cd /home/ubuntu/Devops```라고 썼다.

#### **6. GitHub Secrets 설정**
위에서 ${{ secrets.XXX }} 부분에 값이 있어야 실행된다.
- GitHub 레포 Settings > Secrets and variables > Actions
- New repository secret 클릭

아래 세가지를 등록

EC2_HOST: EC2의 퍼블릭 IP EC2_USER: ec2-user (Amazon Linux) or ubuntu (Ubuntu) EC2_SSH_KEY: EC2의 private key (id_rsa의 내용)

참고: EC2의 퍼블릭IP는 인스턴스를 중지하고 실행할때마다 **매번 바뀐다.**
그래서 탄력적IP를 설정하여 IP를 고정하는 것도 편한 방법 중 하나다.
_물론 요금이 나온다 :).._

**그리고 이때!! 중요한게 있다.**
EC2_SSH_KEY에 EC2의 private key (id_rsa의 내용)을 등록할 때,
id_rsa의 내용은 대략 이렇다.

-----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEA0V2Lt... (중간 내용 수백 줄) ...QIDAQAB -----END RSA PRIVATE KEY-----

여기서  저 **BEGIN RSA~~랑 END RSA까지** 전부 복사해서 붙여넣어야한다. 안에 있는 중간 내용만 맞는 줄 알고 넣어서 deploy했다가 오류났었다 :(

아, 그리고 여기에서 말하지만, 난 배포 후 내가 EC2에 docker-compose를 설치하지 않음을 깨달았다. 여러분은 꼭 미리 EC2에 ```docker와 docker-compose```를 설치하기 바란다^^
#### _간단한 EC2에 docker 설치 방법_

1. docker 설치

sudo apt update sudo apt install docker.io -y

sudo systemctl start docker sudo systemctl enable docker

2. docker-compose 설치, 실행권한 부여

#docker-compose 설치 sudo curl -L "https://github.com/docker/compose/releases/download/v2.24.6/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

#실행권한 부여 sudo chmod +x /usr/local/bin/docker-compose

3. 설치확인

docker-compose --version

``` 정상설치되면 Docker Compose version v2.24.6 이렇게 버전이 나와야한다!

이렇게 설치한 후 다시 로컬 코드 수정 + git push 하면 GitHub Actions가 EC2에 접속해서 docker-compose up을 제대로 실행할 수 있다!.. 그치만 미리 추가 작업을 해줘야 오류 없이 잘 deploy할 수 있다.

추가로 미리 해둬야할 작업(에러 해결)

1. EC2내부에서만 .env파일을 만들자 겪은 에러: env file /home/****/Devops/.env not found 이유는?

• 프로젝트의 docker-compose.yml 안에 환경변수 참조 (.env 파일)가 있거나, Node.js 앱 내에서 dotenv 패키지를 써서 .env 로드를 시도하고 있었다.
• 그런데 GitHub에는 .gitignore 때문에 .env가 없음. 그래서 EC2의 git pull 이후에도 .env 파일이 없다! 해결방법: EC2내부에서만 .env파일을 만들어서 필요한 키들을 적어주고 저장한다(보안이슈 때문에 github엔 가급적 push하지 않는다!)

2. EC2 보안 그룹 확인 AWS 콘솔 → EC2 → 인스턴스 → 보안 → 보안그룹 → 인바운드 규칙에서 3000번 포트 (TCP)가 열려 있어야 한다. 없으면 추가하기

• 포트 범위: 3000
• 프로토콜: TCP
• 소스: 0.0.0.0/0 (전부 허용, 테스트용) 또는 본인 IP

마무리, 전체적인 흐름

• 로컬 VSCode에서 코드 수정
• git add, commit, push
• GitHub → Actions 자동 실행
• EC2 SSH 접속 → git pull, docker-compose down, build, up -d
• 변경사항 반영된 서비스가 EC2에서 자동 재실행
• http://퍼블릭IP:3000 접속 → 변경 확인 이렇게 구현을 완료했다.

배포는 되는데 EC2에서 자동으로 git pull, docker-compose down, build, up -d 가 안되서 오류를 해결하느라 시간이 좀 소요되었다.

배포 흔적을 보여주고 싶었는데 사진이 자꾸 깨져서.. 여길 누르세요 이 링크를 누르면 확인할 수 있다. 예전에 했을땐(compose-todo-api 였나?) 배포까지만 하고 변경사항 반영되서 재실행 하게 하는건 안했다. 이번엔 다 해서 뿌듯하다.

이제 여기에 프론트를 추가해도 재밌겠고.. 다른 데브옵스 공부를 해서 추가해도 재밌겠다. 2학기에 수업으로도 배워서 실습은 일단 여기까지 해볼까.

프론트 요청을 Nginx → Node → Mongo로 전달하는 구조 완성 민감한 정보를 코드가 아닌 .env 파일에서 관리할 수 있다

🧩 실습 세부내용

1. nginx 폴더 만들고, default.conf 생성:

   server {
   listen 80;
   
   location / {
    proxy_pass http://backend:3000;
   }
   }
   

2. ```docker-compose.yml```에 nginx 추가:

nginx: image: nginx:stable ports: - "8080:80" volumes: - ./nginx/default.conf:/etc/nginx/conf.d/default.conf depends_on: - backend

3. 전체 실행: ```docker-compose up --build```
4. 접속 확인: http://localhost:8080 → “Hello with Mongo!”
근데 난 hello with mongo라고 안뜨더라.. 
connected는 됬는데 db error로 undefined라고 나온다.

5. ```.env``` 파일 생성:

MONGO_URL=mongodb://mongo:27017/test

6. ```docker-compose.yml``` 수정:

backend: ... env_file: - .env

7. app.js 최상단에 dotenv 추가:

require('dotenv').config();

주의: dotenv 가 설치되어 있어야 오류없이 작동한다 없다면npm install dotenv```로 다운받기

8. 다시 실행: docker-compose down && docker-compose up --build

여전히 컨테이너가 쉽지 않다..

조만간 중급자용 책을 살 예정이다. 컨테이너 개념을 잘 이해하면 다른 사람들에게도 쉽게 설명해줄 수 있을 것이다.

하나의 명령어로 Node.js + MongoDB 컨테이너를 동시에 실행할 수 있다

🧩 실습 세부내용

1. 루트에 docker-compose.yml 파일 만들기:

   version: '3'
   services:
   backend:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - mongo
    environment:
      - MONGO_URL=mongodb://mongo:27017/test
   
   mongo:
    image: mongo:6
    ports:
      - "27017:27017"
   

참고로 yml 파일은 띄어쓰기가 중요한 것 같다.
이 docker-compose.yml을 보고 직접 따라쳤는데 띄어쓰기 문제 때문에
_services.ports must be a mapping_
이런 오류가 발생했었다.
GPT 가 알려준 코드 그대로 복붙해서 다시 docker-compose up하니 잘 실행된다.

2. app.js 수정 (Mongo 연결 포함):

const express = require('express'); const mongoose = require('mongoose'); const app = express(); const PORT = 3000;

mongoose.connect(process.env.MONGO_URL) .then(() => console.log('MongoDB connected')) .catch(err => console.error('DB error:', err));

app.get('/', (req, res) => res.send('Hello with Mongo!')); app.listen(PORT, () => console.log(Server on ${PORT}));

3. ```npm install mongoose```

4. ```docker-compose up --build```

5. localhost:3000 접속 → 서버 정상 작동 확인

### 잘 모르고 했던 실수 하나

docker run으로 3000번 포트를 점유한 컨테이너를 실행 중에서
docker-compose up --build를 했더니
_port is already allocated_
라는 오류가 났었다.

```docker run으로 만든 컨테이너와
docker-compose up으로 만든 컨테이너는
다른 컨테이너지만, 서버(호스트)의 동일한 포트(예: 3000번)를 공유하기 때문에 충돌이 나.

그렇다고 한다.

그리고 추가로

docker-compose는 여러 컨테이너를 하나의 그룹처럼 실행하고 연결하는 도구라서,
가능하면 실습할 땐 docker run은 잠깐 테스트용,
docker-compose로 전체를 구성하는 게 더 깔끔하고 관리도 쉬워.

이것도 알려주었다.

참고1

🔧 Dockerfile vs docker-compose.yml

📌 Dockerfile
하나의 이미지(예: Node.js 앱 이미지)를 만드는 “레시피”

보통 FROM, COPY, RUN, CMD 같은 명령이 들어감

📌 docker-compose.yml
여러 개의 컨테이너를 정의하고 한 번에 띄움

예를 들어 Node.js 서버, MongoDB, Nginx가 각각 컨테이너 하나씩 필요할 때

docker-compose는 여러개의 컨테이너를 한번에 정의한다. 컨테이너 한개 = 이미지 한개 컨테이너 한개에 여러개의 이미지 X

참고 2

한번 실습할때 컨테이너를 생성하고 끝난 후 중지하고 삭제하지 않으면 어느새 이렇게 컨테이너가 많아져있다.

특히 나는 docker run으로 컨테이너 실행 후 내 터미널에서 ctrl+c를 해서 종료했었는데, 사진을 보면 2일 지난 컨테이너도 여전히 살아있는걸 볼 수 있다. 쟤내들을 다 지우고 나니 그제서야 docker-compose up build가 제대로 실행됬다.

docker run에 -d 옵션을 붙이면 ex) docker run -d -p 3000:3000 node-test

백그라운드에서 실행되기 때문에, Ctrl + C는 단순히 내 터미널에서 연결을 끊는 것일 뿐, 컨테이너는 백그라운드에서 계속 running 상태이다.

1. docker run으로 실행한 컨테이너는 docker stop으로 꼭 중지, docker kill(rm도 가능)로 삭제해주자
2. docker-compose up 으로 실행한 컨테이너는 docker-compose down으로 꼭 컨테이너를 말끔히 종료해주자

앞으로 docker-compose down을 습관처럼 써야겠다..

Dockerfile을 이해하고 직접 만들 수 있다 docker build, docker run을 실행해 서버를 띄울 수 있다

🧩 실습 세부내용

1. node-docker-test라는 폴더 생성

2. 아래 구조로 파일 구성:

node-docker-test/ ├── app.js ├── package.json ├── Dockerfile

3. app.js 내용

   const express = require('express');
   const app = express();
   const PORT = 3000;
   app.get('/', (req, res) => res.send('Hello Docker!'));
   app.listen(PORT, () => console.log(`Server on ${PORT}`));

4. package.json 만들기(터미널에서)

   npm init -y
   npm install express

5. Dockerfile 내용

   FROM node:18
   WORKDIR /app
   COPY package*.json ./
   RUN npm install
   COPY . .
   EXPOSE 3000
   CMD ["node", "app.js"]

   여기서 Dockerfile의 각 명령어들을 간단 정리하자면 FROM: 생성할 이미지의 베이스가 될 이미지를 결정하는 명령어, 이 명령어를 시작으로 Dockerfile을 작성한다.

WORKDIR: 명령어를 실행할 디렉토리를 지정하는 명령어(= linux cd명령어)

EXPOSE: Dockerfile의 빌드로 생성된 이미지에서 노출할 포트를 지정하는 명령어, 그러나 EXPOSE를 설정한 이미지를 기반으로 컨테이너를 생성한다고해서 이 포트가 호스트의 포트와 바인딩하는 것은 아니며, 단지 해당 이미지를 사용하는 사용자에게 해당 포트를 사용한다고 문서화하는 목적을 가지는 것 뿐이다.

Q.만약 publish하고 싶으면? docker run 명령어에 -p 옵션으로 포트를 지정

COPY: 현재 디렉토리 경로의 모든 파일과 디렉토리를 해당 디렉토리의 디렉토리에다가 모두 복사하는 명령어, COPY <src> <dest> src는 호스트 운영체제 경로, dest는 이미지 상에서 경로

RUN: 이미지를 만들기 위해 컨테이너 내부에서 명령어를 실행한다.

6. 이미지 빌드

   docker build -t node-test .

7. 실행

   docker run -p 3000:3000 node-test

-p옵션으로 포트바인딩한다 3000:3000 [호스트의 포트] : [컨테이너의 포트]

8. 브라우저 접속: http://localhost:3000 → “Hello Docker!” 나오면 성공

분명 도커가 잘 설치 되어있고 docker -v하면 버전도 잘 뜨는데 docker ps를 하려 할때마다

The command 'docker-compose' could not be found in this WSL 2 distro 이런 비슷한 오류가 떠서 또 구글링했다.

https://whdgus928.tistory.com/176 이 블로그를 보고 해결할 수 있었다.(구글링 짱) 캡쳐화면을 보여주고 싶은데 docker desktop이 실행이 안되서 아쉽 :(

실습 ing (docker run )

docker 실습을 위해선 image가 필요하다. 이는 도커 명령어로 내려받을 수 있으므로 별도로 설치할 필요는 없다.

🤔 image가 뭐에요? 가상머신을 생성할 때 사용하는 iso파일과 비슷하다. 컨테이너를 생성하고 실행할 때 읽기 전용으로 사용된다.

난 요리조리 검색하다가 archlinux라는걸 알게되어서 이걸 설치해주었다. 설치는 간단하다! https://hub.docker.com/_/archlinux/ 여기로 가서 copy한 후 wsl2에 붙여넣기 혹은 직접

docker pull archlinux

라고 써줘도 좋다. 후자가 더 편하니 후자를 추천:)

이렇게 docker pull을 한 후

docker images

를 입력하면 추가한 archlinux 이미지가 보인다.

(잠시만 컨테이너 설명을 빼먹었어)

🤔 container가 뭐에요? 프로세스 단위의 격리환경, 위에서 말한 image로 컨테이너를 생성하면 해당 이미지의 목적에 맞는 파일이 들어있는 파일 시스템과 격리된 시스템 자원 및 네트워크를 사용할 수 있는 독립된 공간이 생성됨<-- 컨테이너

이제 컨테이너를 생성하면서 동시에 실행을 시켜주자. docker run 명령어를 이용하면 쉽다.

docker run -i -t archlinux

실행했을때 무슨 프롬프트가 뜨긴해서 어 된건가..? 했는데 혹시 몰라 다른 창일 수 있잖아 해서

ls /etc 해보니 arch-relaese가 뜨길래 오케이~~ 했다.

docker create, attach

지금 시작하세요!도커/쿠버네티스 라는 책을 참고하고 있어서 여기서 나온 docker create, attach라는 개념도 살짝 실습해봤다.

docker create -i -t --name myarchlinux archlinux

이렇게 "myarchlinux"라는 archlinux 이미지를 생성했다.

여기서 바로 docker run을 하려고 했더니 permission관련 오류가 떴다! 엥?

확인해보니 create명령어는 컨테이너를 생성만 할뿐 컨테이너로 들어가지 않는다고 한다. 들어가려면 docker start와 docker attach를 해주어야한다.

docker start myarchlinux

docker attach myarchlinux

역시 실행이 잘된 것을 확인할 수 있었다.

그다음은? 책의 내용을 따라 2.2.4 컨테이너를 외부에 노출 ~ 2.2.9 컨테이너 자원 할당 제한

까지 실습할 예정이다.

난 지금껏 visual studio code 터미널 안에서만 docker를 썼었는데 (node.js + Dockerfile) 이렇게 wsl2에서 해보니까 약간 다른 느낌..

배워갈수록 더 다를 거같다.

TypeError: The comparison function must be either a function or undefined: #<Object>
    at Array.sort (<anonymous>)
    at C:\Users\user\Desktop\dev\CRUD-1\app.js:16:42
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)  

인터넷에서도 명확하게 잘 안나오길래 GPT한테 물어봤다.

문제였던 코드

app.get('/diaries',async (req, res) => {
   const diaries = await Diary.find().sort({date: -1});
    res.render('diaries',{diaries}); //ejs 템플릿으로 넘김
})

.sort({date: -1}); 이부분이 문제인가? 했는데

🔍 왜 틀렸던 걸까? (await Diary.find()) → 이건 배열이 됨 .sort({ date: -1 }) → 자바스크립트 배열 .sort()는 비교 함수를 요구함 { date: -1 }는 MongoDB 쿼리 형식이지 비교 함수가 아니야! 그래서 TypeError가 뜬 거야 😅

🔁 정리 한 줄 요약 Diary.find().sort({ ... })는 MongoDB에서 정렬 (await Diary.find()).sort(...)는 JS 배열 정렬이므로 비교 함수가 필요함

고쳐주니 잘 떴다 :]

docker-compose를 사용하는이유

docker-compose : 단일 서버에서 여러개의 컨테이너를 하나의 서비스로 정의해 컨테이너의 묶음으로 관리할 수 있는 작업 환경을 제공하는 관리 도구

여러개의 컨테이너로 구성된 어플리케이션을 구축하기 위해 run 명령어를 여러번 사용할 수 있지만 각 컨테이너가 제대로 동작하는지 확인하는 테스트 단계에서는 이런식으로 일일이 여러개의 컨테이너를 실행하기는 번거롭다. 매번 run 명령어에 옵션을 설정해 cli로 컨테이너를 생성하기 보다는 여러개의 컨테이너를 하나의 서비스로 정리해 컨테이너 묶음으로 관리할 수 있다면 좀 더 편리할것. 도커 컴포즈는 컨테이너를 이용한 서비스의 개발과 CI를 위해 여러 개의 컨테이너를 하나의 프로젝트로서 다룰 수 있는 작업환경을 제공한다. (출처: https://seosh817.tistory.com/387)

docker-compose실습을 위해 다른 프로젝트 한개가 더 필요했는데, 그건 mongoDB프로제그로 해결하기로 했다.

근데 mongoDB를 어떻게 쓰는지부터 익혀야해서, 가볍게 데이터베이스를 추가하는 것부터 시작했다. mongoDB 설치부터!

npm install express mongoose

mongoDB와 mongoose의 차이는 이 링크를 참조하면 잘 알 수 있다.

실습

전에 했던 compose-todo-app의 코드를 참고해 index.js에 app.get을 추가했다.

app.get('/items', async (req, res) => {
  const items = await Item.find(); 
  res.json(items);
});

app.get('/debug', async (req, res) => {
  try {
    const items = await Item.find();
    if (items.length === 0) {
      return res.send('⚠️ 데이터 없음1');
    }
    res.json(items);
  } catch (err) {
    res.status(500).send('❌ 에러 발생: ' + err.message);
  }

});

compose-todo-app프로젝트를 실습했을땐 별다른 프로그램 설치 없이 진행했어서 이번에도 그렇게 하려했는데 구글에 검색해보니 mongoDB를 다운받아야하고 mongosh를 다운받아야하고... 그래서 다 다운 받았다.

docker-compose.yml을 작성하고 프로젝트 구조에 문제가 있어서 조금 변경하고 등등

docker-compose.yml

version: "3.8"

services:
  backend:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - mongo
    environment:
      - PORT=3000
      - MONGO_URL=mongodb://mongo:27017/testDB

  mongo:
    image: mongo
    ports:
      - "27017:27017"
    volumes:
      - mongo-data:/data/db 

volumes:
  mongo-data: {}      

맨 밑에 volumes은 gpt가 알려준 데이터 영구저장에 관련됬다. 터미널에서 mongosh로 접속해

db.컬렉션명.insert();
db.item.insert([{"name":"소현","age":24},{"name":"신위","age":24}]);

데이터를 삽입해준 후 mongoDB compass에서 connection을 지웠다가 다시 켜봤는데 데이터가 매번 지워져있었다. 그래서 저 volumes을 추가로 설정해줬다. yml 파일이라 그런지 띄어쓰기가 너무 엄격하다.

문제1(컨테이너 꺼짐)

중간에 컨테이너 두개 중 한개가 자꾸 꺼지는 일이 발생했는데 캐시문제 때문에 그랬었다.

docker-compose down

docker-compose build --no-cache

docker-compose up -d

이렇게 순서대로 실행해주니 정상적으로 컨테이너가 실행되었다.

문제2(json데이터 화면에 안보임)

mongoDB에 저장되어있는 데이터를 불러와서 화면에 띄우기 까지 완성하는게 목표였다. localhost:3000/items 을 찍어보면 분명히 [] 은 나오는데 계속 데이터가 안나와서 미치는 줄 알았다.

models/Item.js

const mongoose = require('mongoose');

const itemSchema = new mongoose.Schema({
  name: String,
  age: Number,
});

module.exports = mongoose.model('Item', itemSchema, 'item'); // 컬렉션 이름 고정

여기서 컬렉션 이름 때문에 또 몇십분 썼다. 이 문제도 있었고, 위에서 언급한 mongoDB 데이터가 계속 지워지는 현상때문에 [] 이렇게 나오기도 했다.

결과물 JSON데이터가 화면에 잘 뜬것을 볼 수 있다.

컨테이너들 또한 잘 실행되었다.

이 실습에만 3시간 넘게 썼는데.. 다른 실습들은 과연 어떨까. 다음은 gitAction이나 다른 걸 실습해볼 계획이다.

모든 코드는 https://github.com/kgms217068/docker-rebuild 여기에 업로드 되어있으니 참고바랍니다

데브옵스 엔지니어로써 일하기 위해~

2. express generator로 프로젝트 생성 (express docker-rebuild)

(이때 SET DEBUG=docker-rebuild:* & npm start를 실행하지 못하는 오류가 발생했는데, 이건 그냥 window powershell의 문제로 두개를 따로 실행해주면 된다.)

3. 첫번째 문제 발생,(Error: Cannot find module 'http-errors')

npm install http-errors를 입력해 http-errors를 설치해준다

4. npm install로 각종 의존성 패키지들을 설치해준다

5. Dockerfile만들기

FROM node:18
#기본 이미지를 node 18버전을 사용한다

WORKDIR /app
#컨테이너의 작업공간을 /app을 기준으로 한다. 
#작업 공간이란 해당 컨테이너로 파일을 넣거나 진입했을 때 기준이 되는 경로

COPY package*.json ./
#호스트 계정에 있는 package로 시작하는 파일명.json 파일을 컨테이너의 ./경로로 복사한다.

RUN npm install
#컨테이너 안에서 npm install 명령어를 수행한다.

COPY . ./
EXPOSE 3000
CMD [ "npm","run","start" ]
#호스트 계정에서 도커파일이 있는 경로의 모든 파일/디렉터리를 컨테이너의
#./경로로 복사.호스트 계정에서 도커파일이 있는 경로의 모든 파일/디렉터리를 컨테이너의 ./ 경로로 복사한다.

#마지막으로 3000번 포트를 노출하고 컨테이너가 실행될 때 npm run start명령어를 수행

"여기서 한가지 중요한 점은 Dockerfile을 이용하여 빌드하기 전에 반드시 node_modules를 삭제해주세요"

이건 참고한 링크에서 이렇게 하랬는데 왠진 잘모르겠다.

6. 도커이미지 빌드: 빌드란 Dockerfile의 내용을 기반으로 도커 이미지를 만드는 것을 의미합니다. 이렇게 만들어진 이미지를 이용하여 컨테이너를 생성하면 됩니다.

docker build -t [이미지 이름:이미지 버전] [Dockerfile의 경로]
docker build -t Dockerfile .

이렇게 했을때 The system cannot find the file specified. 오류가 나서 검색해보니 docker desktop을 안켜서 그렇다고.. 해서 키고 다시 해봤더니 ERROR: invalid tag "Dockerfile": repository name must be lowercase이런 오류가 나길래 아 소문자로 써야하나?하고 docker build -t dockerfile .로했더니 잘되는것 같다가

ERROR: failed to solve: failed to read dockerfile: open Dockerfile: no such file or directory 이런오류가 발생했다. 몇분 삽질하다가 그냥 docker build -t dockerfile . 이렇게 했더니 바로 됨 이미지 명이랑 dockerfile의 이름을 무조건 같게는 안해도되는구나를 깨달았다.

이러고 이제 docker images로 확인해보면 이름이 잘 뜬다. docker run을 하려는데

docker run -d -p 3000:3000 docker-rebuild

이렇게 하니 Unable to find image 'docker-rebuild:latest' locally docker: Error response from daemon: pull access denied for docker-rebuild, repository does not exist or may require 'docker login' 이런 오류가 떴다.

그래서 docker hub에서 로그인하고 터미널 내에서도 docker login을 해줬는데 또 같은 오류가 발생했다. 보니까 이름을 잘못적은거같아서 dockerfile로 바꿔주니 됬다. 근데 포트를 3000번으로 했더니 포트 할당 오류가 발생해 8080:80으로 바꿔주니 해시값이 나오면서 성공했다.

8080포트로 접근하려고했는데 오류가 나고 80포트로 접근하려니 예전에 설정해둔 nginx 페이지가 떠서 당황했다.

개념 정리

dockerfile 내 expose EXPOSE 3000 : 이 컨테이너 내부에서 3000번 포트를 서비스로 열거야. 이건 단순한 정보 표기이고, 실제 포트를 열고 연결하려면 docker run -p 명령이 필요

docker run -p 8080:80

의미: 내 컴퓨터의 8080포트와 컨테이너 내부의 80포트를 연결해줘 localhost:8080 → 컨테이너 내부 80번 포트로 들어감 localhost:80 → 로컬 PC 자체에 이미 떠 있는 서비스(Nginx 등)가 응답

이렇게 뜨길래 기존에 실행중이던 컨테이너를 지우고 다시 빌드한 후 궁금한게 있어 gpt에게 물어봤다. "포트를 npm start할때 얘를 3000번대로 이미 사용중이라서 안되는건가? 그럼 nodejs 실행 포트를 바꿔야해?" 로컬 PC에서 3000번 포트가 이미 점유 중인데 Docker 컨테이너도 -p 3000:3000 하려고 하면 → 충돌 나거나 접속이 안 돼 → 그래서 Node.js 앱의 포트를 바꾸거나, → 또는 Docker가 바인딩하는 호스트 포트를 다른 걸로 정해야 해

난 docker가 바인딩하는 호스트 포트를 바꾸는 방법을 선택했다. docker run -p 8080:3000 dockerfile 그래서 이렇게 한 후 localhost:8080으로 들어가니 접속이 잘됬다. (컨테이너 내부:3000번에서 앱실행됨, 로컬 pc:localhost:8080으로 접속가능)

전에 실습했을때 docker-compose.yml도 했던거같아서.. 뭔 차이인지 궁금했다. 검색해보니 Dockerfile은 사용자가 이미지를 어셈블하기 위해 호출할 수 있는 명령이 포함된 간단한 텍스트 파일인 반면 Docker Compose는 다중 컨테이너 Docker 애플리케이션을 정의하고 실행하기 위한 도구입니다.

Docker Compose는 앱을 구성하는 서비스를 docker-compose.yml에 정의하여 격리된 환경에서 함께 실행할 수 있습니다. docker-compose up을 실행하여 하나의 명령으로 앱을 실행합니다. 프로젝트의 docker-compose.yml에 빌드 명령을 추가하면 Docker compose는 Dockerfile을 사용합니다. Docker 워크플로는 생성하려는 각 이미지에 적합한 Dockerfile을 빌드한 다음 compose를 사용하여 build 명령을 사용하여 이미지를 조합하는 것이어야 합니다.

이렇다고 한다 Dockerfile : 이미지 빌드 docker-compose.yml : 앱이 실행되는 동안 컨테이너 관리

docker-compose.yml을 사용하여 하는 것도 곧 도전해봐야지

수포자인 내가 봤을땐 정말 하나도 이해되지 않았다. 점화식을 뭘 어떻게 해서 등비수열..뭐? 정말 모르겠어서 chat gpt에게 쉽게 설명해달라고 했다. 그리고 내가 과제를 풀기 위해 이해한 것만 적어본다

원래의 그 증명이야 당연히 이해가 안되고 그냥 푸는것도 어렵..

주의) 일부문제에만 적용될 수도 있다.

우린 여기서 a,b,d 값을 구해 case 1, 2, 3 중 어디에 해당하는지 알아내면 된다.

단, f(n)이 nlogn인 경우는 d로 직접 표현할 수 없다.

예시 문제 2개를 보며 풀어보자.

여기서 a = 2, b = 2, log_b(a)= 1, 그럼 d는 뭘까? f(n)의 형태가 n의 몇 제곱인가를 찾는게 핵심이다.

f(n) = 2 , 2는 상수이므로 O(n^0) 즉 d = 0 (b^d = 1) case에 비교해보면, a > b^d <=> log_b(a) > d 인 case 3에 맞다. 확인) 2 > 1 <=> 1 > 0 만족.

따라서 형태가 O(n^log_b*a)형태가 되는데 여기서 log_b(a) = 1 이었으니 O(n^1) = O(n)이 된다.

따라서 문제 1의 시간 복잡도는 O(n)이다.

2.

여기서 a = 3, b = 2 , log_b(a) = 1.548, d는? 엥 이번엔 f(n)이 n^2이다. 상수의 형태가 아닌데 어떻게 구하지? 이때 d는 그냥 이 지수 값을 의미한다. 즉, f(n) = n^2 -> d = 2 (b^d = 4)

case 1에 만족한다는 것을 알 수 있다. 확인) 3 < 4 <=> 1.548 < 2

따라서 형태가 T(n^d)가 되는데 d = 2이니 O(n^2)가 된다.

문제 2의 시간 복잡도는 O(n^2)이다.

(이 글은 개인 기록용으로 작성되었습니다)

정말 쉽게 푼 만큼 이렇게 간단하지 않은 문제엔 적용이 안될 수도 있다. 그리고 이게 틀린 걸 수도 있다. 다른 분들이 설명한 것과 같이 보면서 이해해보시기 바랍니다.

목표: Node.js + MongoDB 프로젝트를 GitHub Actions + DockerHub + Docker Compose + AWS EC2를 활용해 완전 자동화 + 실전 배포까지 해보기

github 레포지토리 2개에 push 되어있다. devops-node-todo-api / compose-todo-api

devops-node-todo-api compose-todo-api 코드를 깃허브에 올려뒀으니 참고해서 보면 좋을 것 같다.

전체 실습 흐름 요약

1. Node.js + MongoDB Todo API 만들기

• express와 mongoose로 간단한 /todos API 구현
• GET, POST, PUT, DELETE 라우트로 CRUD 구성
• MongoDB는 로컬이 아닌 도커 내부의 mongo 서비스로 연결

  mongoose.connect('mongodb://mongo:27017/todos')

2. Docker로 백엔드 컨테이너화

• backend/Dockerfile 작성
• Node.js 앱을 도커 이미지로 빌드 가능하게 구성 Dockerfile

  FROM node:18
  WORKDIR /app
  COPY package*.json ./
  RUN npm install
  COPY . .
  EXPOSE 3000
  CMD ["node", "index.js"]

  이후

  docker build -t devops-node-todo-api

  를 이용해 도커 이미지를 빌드해주고

docker run -p 3000:3000 devops-node-todo-api

를 써서 도커 컨테이너를 실행해준다. -p 3000:3000 -> 내 컴퓨터의 3000번 포트를 컨테이너 안의 3000번 포트와 연결

3. Docker Compose로 전체 서비스 관리

• docker-compose.yml로 백엔드 + MongoDB구성 docker-compose.yml

  services:
  backend:
    build: ./backend
    ports:
      - "3000:3000"
    depends_on:
      - mongo
  mongo:
    image: mongo
    ports:
      - "27017:27017"

• docker-compose up 으로 컨테이너 2개를 한번에 실행 이때 중간에 gpt가 알려준 index.js 코드 중 일부를 일부러 안썼었다. 아예 안쓰는게 또 다른 문제기도 했던..

  mongoose.connect('mongodb://mongo:27017/todos', {
  useNewUrlParser: true,
  useUnifiedTopology: true,
  });

  useNewUrlParser랑 useUnifiedTopology는 MongoDB 최신 버전에서는 필요없는 옵션. 그러나 mongoose.connect() 자체는 필수다. Node.js 서버가 MongoDB에 데이터를 저장/읽기 하려면 Mongoose가 MongoDB 서버와 "연결"되어 있어야하기 때문.

수정 코드

// MongoDB 연결
mongoose.connect('mongodb://mongo:27017/todos')
  .then(() => console.log('✅ MongoDB 연결 성공!'))
  .catch(err => console.error('❌ MongoDB 연결 실패:', err));

이후 docker-compose up --build를 다시 하고 localhost:3000/todos에 접속하니 [] 이 떴다(정상출력)

그다음 VS Code REST Client 확장으로 POST /todos 요청도 보내봤다.

• requests.http(REST Client가 읽을 요청 스크립트 파일)을 따로 만들어서 진행

여기에서의 문제는

PUT과 DELETE가 되지 않음 하나의 .http 파일에 GET, POST, PUT , DELETE등 여러 요청을 연습용으로 다 넣을 수 있다.

1. index.js에 PUT과 DELETE요청을 처리하는 코드를 넣지 않았기 때문이다.

그래서 index.js에 PUT, DELETE 코드를 추가했다.

// ✅ 할 일 수정 (PUT)
app.put('/todos/:id', async (req, res) => {
  const { id } = req.params;
  const updated = await Todo.findByIdAndUpdate(id, { text: req.body.text }, { new: true });
  if (updated) {
    res.json(updated);
  } else {
    res.status(404).json({ error: "할 일을 찾을 수 없어요!" });
  }
});

// ✅ 할 일 삭제 (DELETE)
app.delete('/todos/:id', async (req, res) => {
  const { id } = req.params;
  const deleted = await Todo.findByIdAndDelete(id);
  if (deleted) {
    res.json({ message: "삭제 완료!" });
  } else {
    res.status(404).json({ error: "삭제할 항목을 찾을 수 없어요!" });
  }
});

수정한 전체 .http 코드

### 전체 할 일 목록 조회
GET http://localhost:3000/todos
Accept: application/json

###

### 새로운 할 일 추가 (POST 요청)
POST http://localhost:3000/todos
Content-Type: application/json

{
  "text": "Docker Compose 실습 최고!"
}

###

### 할 일 수정 (PUT 요청)
PUT http://localhost:3000/todos/여기에_실제_ID_입력
Content-Type: application/json

{
  "text": "수정된 내용입니다!"
}

###

### 할 일 삭제 (DELETE 요청)
DELETE http://localhost:3000/todos/여기에_실제_ID_입력

2. requests.http에 실제ID를 틀리게 입력함 너무 간단한 오류.. 당연히 ID가 맞아야 넣든 지우든 할것이다.

4. Github Actions + DockerHub 자동화 구축 (CI/CD)

• .github/workflows/docker.yml 작성
• GitHub에 push → Docker 이미지 자동 빌드 → DockerHub에 업로드
• GitHub Secrets에 DOCKER_USERNAME / DOCKER_PASSWORD 등록

yml 코드 중 일부

run: docker build -t ${{ secrets.DOCKER_USERNAME }}/compose-todo-api ./backend
run: docker push ${{ secrets.DOCKER_USERNAME }}/compose-todo-api

난 DockerHub 로그인에서 조금 막혔었다. 실수: GitHub Secrets에 DOCKER_NAME이라고 쓰고 yml엔 DOCKER_USERNAME이라고 쓰기(불일치) 여러번의 push 끝에 성공

여기까지하면

GitHub에 코드 푸시 → 자동으로 최신 Docker 이미지가 빌드됨 DockerHub에 latest 태그로 업로드됨 이제 누구나 docker pull로 받아서 실행 가능함!

이 가능하다

5. .env로 환경변수 분리 (.env 적용 실습)

• MongoDB 주소와 포트를 .env 파일로 분리
• process.env를 통해 코드에서 참조 .env 코드

  PORT=3000
  MONGO_URL=mongodb://mongo:27017/todos

6. AWS EC2 서버에 배포

• EC2 Ubuntu 인스턴스 생성 & SSH 접속
• Docker + Docker Compose 설치
• GitHub에서 프로젝트 클론
• .env 작성 후 docker-compose up으로 컨테이너 실행
• 외부 IP + 3000 포트로 API 확인

EC2 인스턴스 만들기

1. https://aws.amazon.com 접속
2. EC2 > 인스턴스 시작 운영체제: Ubuntu 22.04 LTS 인스턴스 유형: t2.micro (프리 티어) 키페어 생성 → .pem 파일 저장
3. 인스턴스 생성 후, 보안 그룹 설정에서 포트 열기 22번: SSH 3000번: Node.js 접속용 (커스텀 TCP) 27017번: MongoDB 접속용 (선택)

chmod 400 이름.pem
ssh -i 이름.pem ubuntu@퍼블릭IP주소

wsl에서 EC2로 접속할때 이런 문구가 떠서 좀 당황했는데, 리눅스나 맥에나 SSH접근시 항상 물어보는 질문이라고 한다.

[Linux / Mac] SSH 접근시 "Are you sure you want to continue connecting (yes/no)?" 없이

이 링크를 참고하여 해결했다.

접속성공

그다음 다운받은 .pem 파일을 wsl로 옮겨줘야하는데,

explorer.exe .

이 명령어를 wsl에 입력해서 할 수 있었다. 신기하게 윈도우에 파일 복사하듯이 ctrl+c ctrl+v가 가능했다.

배포 완료 뭔가 이렇게 뜨더니

curl http://localhost:3000/todos

을 입력하니 [] 이 잘 나왔다.

소감: 이번 실습을 통해 단순한 API 서버를 넘어서 도커화 → 자동화 → 배포까지 한 번에 경험할 수 있어 좋았다. 아직도 잘 모르겠지만 계속 하다보면 조금이라도 알게되지 않을까.

fcitx설치 방법

sudo apt install fcitx5 fcitx5-hangul

설치 후 Settings > Region & Language > Manage Installed Languages > Language Support 창 하단의 Keyboard input method system을 Fcitx 5로 선택

그다음

위에 키보드 모양이 뜰거다. 누르고 configure을 누른다.

available input method 검색창에 hangul 입력 하면 뜬다. (language support에서 hangul을 설치했다면) < 모양 눌러서 왼쪽으로 옮겨준다

trigger input method 클릭하고 한영키 누르면 이렇게 hangul이라고 뜬다. apply 누른 후 입력해보면 뭔 이상한 작은창이 위에 함께 뜰텐데 그게 좀 거슬리고 자동으로 한자변환도 되서 별로니 없애주도록 하자.

Show Input Method Information when switch input method를 체크 해제하면 된다.

난 한자 쓸일이 없을거같아서 hangul hanja도 hanja mode toggle key에서 빼긴 했다.

와... ibus진짜 ㅡㅡ

fcitx5의 문제점은 문제가 생기면 알아보도록 하자.

출처 한글 입력을 위한 fcitx5 설치 Ubuntu 24.04 한글입력기 fcitx5 설치 및 설정 방법

전에도 본 적 있어서 침착하게 서치 했더니

git pull origin main

하고 다시 push하면 된다길래 했는데 또 안됨

그리고 내가 깃 푸시 과정 중 제일 싫어하는 상황 "staging 중인 커밋 사라짐"

이렇게 git log엔 보이지만 status에 안보이면 멘붕이 온다.

다른 블로그들을 또 찾아서

git reset --hard HEAD^

를 했더니 뭔가 되긴 한거같은데 엥 제 파일도 함께 사라졌어요

"git reset --hard는 현재 작업 중인 내용(unstaged)이나 되돌아가고 싶은 커밋 이후의 작업 내용을 전부 날린다."

그렇군...

계속 찾아보다가 branch name 문제인가 싶어서 검색

master -> main으로 변경방법

git branch -m master main

내 브랜치는 master였고, 위 명령어로 수정하니 push가 됬다. 야호!

그나저나 우분투 한영키 자주 에러 나는게 좀 거슬린다. 조만간 고쳐서 또 업로드 해야지

참고 출처들 [Git] git 커밋 한거 롤백 하는 방법 [Git, Github] error: src refspec main does not match any 완벽 해결 [Git] 원하는 지점의 커밋으로 되돌아가는 방법 (git reset --hard) 출처: https://systorage.tistory.com/entry/Git-원하는-지점의-커밋으로-되돌아가는-방법-git-reset-hard