AWS Lightsail 인스턴스 설정서버 업데이트 및 필수 패키지 설치Django 프로젝트 코드 클론- Python 가상환경 설정 및 의존성 설치
- Django 프로젝트 설정
- Gunicorn 설정
- Systemd 서비스 파일 생성
- Nginx 설정
- 방화벽 설정
- Django 정적 파일 수집
3번까지 진행이 된 상황이다. 계속 가보자.
일단, python 가상환경 설정 및 의존성 설치를 해야 하는 이유를 공부하고 넘어가자.
가상환경을 설정하는 이유는 프로젝트마다 독립적인 환경을 제공하기 위해서입니다. 가상환경은 Python 패키지들이 시스템 전체와 충돌 없이 각 프로젝트에만 필요한 패키지들을 설치하고 관리할 수 있도록 돕습니다.
가상환경 설정의 주요 이유:
- 프로젝트 간 독립성 유지:
- 각 프로젝트는 필요한 라이브러리와 버전이 다를 수 있습니다. 가상환경을 사용하면 프로젝트마다 다른 버전의 패키지를 설치할 수 있어, 서로 다른 프로젝트에서 사용하는 라이브러리가 충돌하지 않습니다.
- 의존성 관리:
- 가상환경 내에서만 필요한 패키지를 설치할 수 있으며, 프로젝트마다 필요한 패키지를 관리하기 용이합니다. 예를 들어, 하나의 프로젝트는 Django 3.x 버전을, 다른 프로젝트는 Django 4.x 버전을 사용해야 할 수 있습니다.
- 배포 및 이동성:
- 개발 환경을 서버나 다른 개발 환경으로 이동할 때, 가상환경을 이용하면 필요한 라이브러리들이 모두 관리된 상태로 전달되어 일관된 환경을 유지할 수 있습니다. 또한, requirements.txt 파일을 통해 의존성을 쉽게 관리할 수 있습니다.
- 시스템 Python과의 격리:
- 시스템에 기본적으로 설치된 Python 라이브러리와 충돌을 피할 수 있습니다. 예를 들어, 시스템 Python에 설치된 라이브러리와 프로젝트에서 사용하는 라이브러리 버전이 다르면 충돌할 수 있기 때문에 이를 방지하기 위해 가상환경을 사용합니다.
요약:
가상환경을 사용하면 각 프로젝트에 필요한 패키지와 버전만 독립적으로 설치하고 관리할 수 있어 시스템의 안정성을 높이고, 프로젝트 간의 의존성 충돌을 방지할 수 있습니다.
가상환경을 설정하고 활성화한 후 필요한 패키지를 설치!
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
마지막 줄에 보면, (venv - virtual environment) 라고 되는데, 이제부터 설치하는 패키지는 해당 디렉토리에만 적용된다는 뜻으로 생각하면 되겠다.
지금까지 설치된 패키지들을 보여주는 requirements.txt 가 필요하다.
그런데 지금까지 만든적이 없으니 만들어야 한다. GPT한테 물어보니,
로컬 컴퓨터에서 pip freeze > requirements.txt 를 하라고 한다.
이렇게 각각의 패키지랑 그것들의 버전 정보가 담겨있는 txt 파일이 만들어졌다.
저장하고 커밋푸쉬를 해서 github 서버에 올려야 한다. 그래야 AWS 에서 github에서 해당 파일에 손댈 수 있다.
git pull 이라고 하니까 AWS에 당겨와졌다.
ubunto를 껐다가키면, 가상환경 활성화는 다시 해주면 된다.
requirements.txt 설치까지 끝났다... 이 한 마디를 하기 위해서 지금 시간이 얼마나 지난건지..
다음은
Django project에서 settings.py 에 손을 봐야 한다.
* 참고로, 리눅스, 우분투에서는 파일을 열때
vim 파일이름
이런 식으로 연다.
* 커서는 방향키로 움직일 수 있다.
* i 키를 눌러서 입력 모드로 들어갈 수 있다. 화면 하단에 --INSERT-- 라고 표시되어 있을 것.
* 저장하고 나가기 :wq 입력하고 enter를 치는건데, 그거랑 똑같은 의미로,
Shift 를 누른채로 z를 두번 누르면, 저장하고 vim 을 종료하는 것.
그래서 vim settings.py 들어와서,
1. SECRET_KEY 는 default로 생성되는거라서 몇가지 문자를 더 추가해줘서 보강
2. DEBUG = True 를, False 로 변경해줘야 한다.
3. ALLOWED_HOSTS = ["domain 주소를 입력"]
4. DB - 설정을 로컬 컴퓨터의 PostgreSQL에서, AWS의 RDS로 만든 PostgreSQL의 endpoint 값을, "HOST": "endpoint 입력" 으로 해서 설정해준다.
5. DB의 PASSWORD, USER, NAME 도 설정해주고 (Password는 lightsail에서 확인, User도 lightsail, name은 pgadmin4에서 만들었던 db의 이름을 가지고 와야함)
여기는 이미지를 보여주기가 좀 그렇다. 보여주면 안 되는 정보들이 있으니 각자 주의.
이제 AWS 리눅스 서버에 PostgreSQL DB를 연결을 했다.
새로운 DB가 연결이 된 것이니까, Migration을 해야 한다.
Migration이 기억이 가물가물한 나는, 내가 기록했던 걸 내가 다시 읽어보기로 한다.
https://wy-family.tistory.com/6
Django Model 작성 / Migration과 결과 확인 / DB 확인 (PostgreSQL의 pgAdmin 4, Django Admin 기능)
Model을 작성하려면,관계형 DB에 대한 이해가 필요하다Model 에는 data type을 정의해야 하고, 그들의 관계를 정의해야 한다.지금 만들어보려고 하는 건, AI Chatbot.메시지를 주고 받는 것이 기본이니,메
wy-family.tistory.com
python manage.py migrate 라고 해서,
postgreSQL에 Django 내용들이 반영이 되는 것.
이제 5단계까지 왔다.
이제 Gunicorn 설정을 할 것이다. - Gunicorn 설치 (install) / 설정 (configuration) 을 만지작할 것이다.
ssh에서 가상환경으로 가자
먼저, Gunicorn의 역할은
python과 Nginx 사이에서 WSGI의 역할을 하는 것이다.
gunicorn을 install 할 때는 가상환경(source venv/bin/activate)에서 해야 한다.
그리고,
제대로 작동하는지 확인을 해볼건데,
gunicorn mysite.wsgi:application --bind 0.0.0.0:8000이라고 입력을 해야 한다. 그런데, 이걸 입력할 때, 한 가지 기억해야 하는 건, manage.py가 존재하는 디렉토리에서 gunicorn을 실행해야 한다는 점. 안 그러면 Error가 뜰 것이다.
실행해보니 잘 작동한다는 걸 확인했고, ctrl + c 를 누르면 작동 해지가 된다고 한다.
자 이제 여기까지 6단계 마무리!
AWS Lightsail 인스턴스 설정서버 업데이트 및 필수 패키지 설치Django 프로젝트 코드 클론Python 가상환경 설정 및 의존성 설치Django 프로젝트 설정Gunicorn 설정- Systemd 서비스 파일 생성
- Nginx 설정
- 방화벽 설정
- Django 정적 파일 수집
7단계의 경우에는, Systemd 서비스 파일 생성이라고 되어 있는데, configure Gunicorn as a Systemd Service라고 단계를 영어로 표현하면 그렇다. 그래서 7단계는 gunicorn과 관련된 것이다.
GPT의 설명은 이렇다.
서비스 파일을 설정하여 Gunicorn이 자동으로 시작되고 백그라운드에서 실행되도록 만드는 것이 목표!
Systemd 서비스 파일 생성:Systemd를 이용해 Gunicorn을 서비스로 등록하여 서버가 자동으로 시작되고, 시스템 재부팅 시에도 자동 실행되도록 설정할 것입니다.
이제 다음 단계인 Systemd 서비스 파일 생성으로 넘어가 서버를 관리하는 설정을 해 주세요.
라고 말하고 있다.
솔직히 말해서, 프로젝트의 끝을 향해 갈수록 이해되는 퍼센티지가 점점 줄어들고 있다.
그래서 더욱 더 GPT에게 단계적으로 차근차근, 구체적으로 설명해달라고 말하고 있다.
7단계의 경우에도 추가 질문을 해서 구체적으로 공부하고 행동으로 옮기겠다.
Systemd 서비스 파일을 생성하여 Gunicorn을 백그라운드 서비스로 실행할 수 있도록 설정하는 단계를 자세히 안내해 드리겠습니다.
1. Systemd 서비스 파일 생성
- 먼저 Systemd 서비스 파일을 만들어서 Gunicorn을 관리하도록 설정합니다.
- 아래 명령을 입력하여 mysite_gunicorn.service 파일을 생성하고 편집합니다.
sudo nano /etc/systemd/system/mysite_gunicorn.service2. 서비스 파일 구성
- mysite_gunicorn.service 파일에 다음 내용을 입력합니다. 이 내용은 Gunicorn이 백그라운드에서 Django 앱을 실행할 수 있도록 설정합니다.
- 파일에서 <your-project-directory>와 <your-project-name>을 실제 경로와 이름으로 바꾸세요.
[Unit]
Description=gunicorn daemon
After=network.target
[Service]
User=ubuntu
Group=www-data
WorkingDirectory=/home/ubuntu/src/CodingProject/mysite # <your-project-directory> 위치에 맞게 수정
ExecStart=/home/ubuntu/src/CodingProject/venv/bin/gunicorn --workers 3 --bind unix:/home/ubuntu/src/CodingProject/mysite/mysite.sock mysite.wsgi:application # <your-project-name> 위치에 맞게 수정
[Install]
WantedBy=multi-user.target- 설명:
- User=ubuntu : Gunicorn을 ubuntu 사용자로 실행합니다.
- Group=www-data : www-data 그룹을 설정하여 Nginx와의 호환성을 높입니다.
- WorkingDirectory : Django 프로젝트 최상위 디렉토리를 지정합니다.
- 이 부분의 경우에는, 이 gunicorn은 manage.py가 있는 곳에서 진행되어야 하는데, 해당 디렉토리에 가서, pwd 라는 입력어를 치면 절대 경로라는 걸 알려주는데, 그게 저 /home/ubuntu/src/CodingProject/mysite 라고 나온다. pwd 는 print working directory
- ExecStart : Gunicorn이 실행되는 경로와 명령어를 입력합니다. --bind 옵션을 통해 mysite.sock 파일 경로를 지정합니다.
- 소켓파일, .sock 은 리눅스 안에 있는 프로세스들끼리 통신을 할 수 있게 도와주는 파일이다. 이번에 생성된 소켓파일은 나중에 Nginx에서 이 소켓파일을 연결을 해줄 것이다. Nginx 로 사용자들이 들어와서 gunicorn 통해서 django로 가는데, Nginx가 gunicorn을 쓰기 위해서는 이 소켓파일에 대해 플러깅을 해야 한다.
- 여기도 마찬가지다. gunicorn이 설치 되어 있는 곳을 찾아서 절대 경로 (pwd 를 쳐서 나오는 경로) 를 찾아서 입력해야 한다. gunicorn은 가상환경 (venv) 에서 bin 이라는 폴더내에 설치가 되어 있으니 cd 를 해서 찾아가보자. (source venv/bin/activate 라고 하는 것도 경로에 대한 이해를 하고 보면 좀 더 잘 이해가 된다)
- 파일 저장 후 닫기
- 편집이 끝났으면, Ctrl + X를 누른 후 Y 키를 눌러 저장하고 Enter 키로 닫습니다.
4. Systemd 데몬 리로드
- 새로 생성한 서비스 파일을 반영하기 위해 Systemd 데몬을 리로드합니다.
sudo systemctl daemon-reload* 여기서 systemctl 에서 ctl 은 control 의 준말이다.
5. Gunicorn 서비스 시작 및 자동 실행 설정
- 이제 Gunicorn 서비스를 시작하고, 서버 재부팅 시 자동으로 시작되도록 설정합니다.
sudo systemctl start mysite_gunicorn
sudo systemctl enable mysite_gunicorn6. Gunicorn 서비스 상태 확인
- Gunicorn 서비스가 정상적으로 실행되고 있는지 확인합니다.
sudo systemctl status mysite_gunicorn- 이 명령을 통해 서비스 상태가 **"active (running)"**으로 표시되면 성공적으로 설정된 것입니다.
이제 Gunicorn이 백그라운드에서 실행되며, 서버를 재시작해도 자동으로 실행됩니다. 다음 단계로 Nginx 설정을 진행하시면 됩니다.
추가 질문으로,
1. sudo 가 무슨 뜻일까?
2. nano 라는 건?
3. systemd 에서 d는 뭘까?
4. gunicorn이 백그라운드에서 django 앱을 실행할 수 있도록 설정한다고 하는데, 그 백그라운드가 무슨 뜻이지?
5. 데몬이 뭔지? 데몬 리로드는 뭔지?
1. sudo란?
- **sudo**는 “superuser do”의 약자로, 관리자 권한(루트 권한)으로 명령어를 실행하는 역할을 합니다.
- 일반 사용자 계정은 보안 때문에 시스템 파일이나 중요한 설정을 변경할 수 없는데, sudo를 사용하면 일시적으로 관리자 권한을 획득하여 필요한 작업을 수행할 수 있습니다.
2. nano란?
- **nano**는 리눅스에서 사용하는 텍스트 편집기입니다. 간단하면서도 기본적인 텍스트 파일 편집 기능을 제공하며, 서버에서 설정 파일이나 소스 코드 파일을 수정할 때 많이 사용됩니다.
- 예를 들어 nano /etc/systemd/system/gunicorn.service 명령을 통해 gunicorn.service 파일을 열어서 수정할 수 있습니다.
3. systemd의 ‘d’는 무엇일까?
- **systemd**에서 ‘d’는 **데몬(demon)**의 약자입니다. systemd는 리눅스의 서비스와 프로세스를 관리하는 시스템 관리자입니다.
- 서비스 실행, 자동 시작 설정, 상태 확인 등 다양한 시스템 관리 작업을 수행하며, 리눅스 시스템의 전반적인 운영을 지원합니다.
4. 백그라운드란?
- 백그라운드는 프로그램이 사용자 화면에 표시되지 않고, 백그라운드에서 조용히 실행되는 상태를 말합니다.
- Gunicorn이 백그라운드에서 Django 앱을 실행하면, 사용자 인터페이스에 표시되지 않고 서버 뒤에서 계속 작동하여 웹 요청을 처리합니다.
- 백그라운드에서 실행되는 경우, 서버에서 다른 작업을 할 때도 Django 앱은 계속 작동합니다.
5. 데몬(demon)이란? 데몬 리로드는 무엇일까?
- **데몬(demon)**은 백그라운드에서 계속 실행되면서 특정 작업을 수행하는 프로세스입니다. 서버의 다양한 기능, 예를 들어 웹 서버(Nginx)나 데이터베이스(MySQL)가 데몬으로 작동합니다.
- 데몬 리로드는 새로운 서비스 파일이나 설정을 적용할 때, Systemd가 기존 설정을 새로고침하는 작업입니다. Systemd가 데몬을 리로드하면, 새로 생성한 서비스 파일들이 반영됩니다.
질문하신 내용들이 기본이면서도 중요한 개념들이니, 이해해 두시면 앞으로 서버 관리나 리눅스를 사용할 때 큰 도움이 되실 거예요!
대략적인 이해를 했고, systemd가 무엇인지, 그리고 목적이 무엇인지 파악을 했다.
gunicorn.service 파일을 생성할것이다. 파일이니까, gunicorn은 service 파일의 이름이고, service는 txt, pdf 처럼 파일의 형식인걸로 이해된다. 그래서 질문을 해봤다. 생성할 파일 이름에 프로젝트 이름을 함께 넣는것도 괜찮은지.
mysite_gunicorn.service처럼 원하는 이름으로 생성해도 괜찮습니다. 다만, Systemd 파일 이름은 나중에 유지보수할 때 알기 쉽게 짓는 것이 중요합니다.
권장 사항
- 프로젝트와 관련된 이름을 포함하기: mysite_gunicorn.service처럼 프로젝트 이름을 포함하면 여러 프로젝트를 관리할 때 구분하기가 더 쉽습니다.
- 이름 선택에 대한 고려: gunicorn.service로 설정하면 Gunicorn과 관련된 서비스임을 바로 알 수 있지만, 프로젝트 이름이 포함된 mysite_gunicorn.service도 좋습니다. 특히 여러 개의 Django 앱을 관리하거나 배포할 계획이 있다면, 구분하기 쉬운 mysite_gunicorn.service를 추천합니다.
결론: mysite_gunicorn.service처럼 원하는 이름을 사용해도 시스템 관리에는 전혀 문제가 없으며, 프로젝트 구분에도 유리합니다.
자, 하나씩 진행하고 오겠다.
1번 Systemd 서비스 파일 생성, 4번 Systemd 데몬 리로드, 5번 Gunicorn 서비스 시작 및 자동 실행 설정, 6번 Gunicorn 서비스 상태 확인, 이 명령어 입력들은 어느 디렉토리에서 입력해도 상관이 없다고 한다.
이 명령어들은 Systemd 서비스와 관련된 작업이기 때문에, 현재 작업 중인 위치와는 무관하게 동작합니다.
구체적으로 설명드리면:
- 1번 서비스 파일은 항상 /etc/systemd/system/ 경로에 생성되기 때문에, 다른 디렉토리에서 명령을 실행해도 지정된 위치에 파일이 생성됩니다. 즉, sudo nano /etc/systemd/system/gunicorn.service 명령어는 현재 디렉토리 위치와 무관하게 /etc/systemd/system/에 gunicorn.service 파일을 생성합니다.
- 4번 sudo systemctl daemon-reload: 시스템 전체에서 Systemd 설정을 리로드하는 명령이기 때문에, 위치와 상관없이 실행할 수 있습니다.
- 5번 sudo systemctl start 및 sudo systemctl enable: 특정 서비스(Gunicorn)를 시작하고 자동 실행되도록 설정하는 명령어이므로, 현재 위치와 관계없이 실행 가능합니다.
- 6번 sudo systemctl status: Gunicorn 서비스의 상태를 확인하는 명령어로, 역시 위치와 관계없이 사용할 수 있습니다.
따라서, 디렉토리 위치에 구애받지 않고 실행하시면 됩니다.
하아... 드디어....
저 active 표시를 보기 위해서 여러 과정이 있었다. 에러가 계속 떴다. 디렉토리에서 찾을 수 없다느니..
근데 내 생각에는, 백그라운드에서 실행하기 위해서 약간의 시간이 필요했던게 아닐까 싶다. 왜냐면 뭔가를 계속 수정해주다가 결국 처음과 코드로는 달라진게 하나도 없었는데 처음에는 안 되더니 시간이 지났을 때에는 active 로 정상 작동되고 있는걸로 봐서는 그렇다.
mysite_gunicorn 서비스가 정상적으로 실행되고 있습니다. 상태가 active (running)으로 표시되며, 여러 워커 프로세스들이 정상적으로 실행 중인 것을 확인할 수 있습니다. 이는 Gunicorn이 성공적으로 Django 앱을 백그라운드에서 실행하고 있다는 의미입니다.
다음 단계
이제 Nginx 설정을 통해 Gunicorn과 연결하고, Django 앱에 외부에서 접근할 수 있도록 준비를 마무리하면 됩니다. Nginx 설정을 진행하면서 mysite.sock 파일을 사용하여 Gunicorn과 연결합니다.