일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- gitlab 잔디옮기기
- Ngrinder Docker
- AWS S3 계정이동
- 캐시백챌린지
- Avast Security
- putty Inactive
- aws
- RedisJSON
- 패캠챌린지
- 환급챌린지
- ERR unknown command 'JSON.SET'
- Redis
- AWS S3 버킷 삭제
- 한 번에 끝내는 AWS 인프라 구축과 DevOps 운영 초격차 패키지 Online
- elastic cache
- 직장인자기계발
- aws s3
- 잔디이전
- Window redis-cli
- 직장인인강
- redis-cli
- Avast 구독취소
- nodemailer
- ERR unknown command 'JSON.GET'
- AWS S3 migration
- 패스트캠퍼스
- 캐시백
- 패스트캠퍼스후기
- redis cli
- vscode
- Today
- Total
Developing
패스트캠퍼스 캐시백 챌린지 29일차 본문
Nginx에 관한 클립을 수강하는식으로 챌린지를 진행하였다. Nginx는 한번쯤 꼭 개인적으로도 다루어보고 싶었던 내용인데 실습까지 할 수 있어서 좋았던 것 같다. 다만 처음 사용해보는거라 "sudo service nginx restart"가 한방에 안먹었을때 살짝 긴장했었는데, 구글링도해보고 메세지대로도 쳐보면서 잘 해결하였다.ㅎㅎ;; 그리고 config 파일 수정할때도 문제가 살짝있어서 해당 내용을 찾아서 진행해주었다. 다음 포스팅은 AWS Autoscaling Group과 AMI에 관한 포스팅을 할 예정이다.
만약에 EC2 100개가 있을것이라고 가정해본다면, 기존처럼 python manage.py ...해서 서버구동해주는 작업을 각각의 EC2마다 해야한다. 그렇게 일일이 작업을 하지 않아도 쉽게 이미지를 생성해서 실행만하면 같은 환경으로 자동적으로 서버가 구동되도록 해주려고 한다.
Nginx
- 웹서버
- 한 이미지를 EC2를 따서 100개를 따있는 상태더라도 배포가 되어있는 상태라고 생각하면 된다.(가령 각각에 대해서 python manage.py 를 따로 안해주어도 된다.)
- 아파치를 역전한 이유
⇒ 요즘 시대에 맞지 않는 코드들이 많음
⇒ 더 작은 자원으로 빠르게 제공해준다.
Nginx 적용해보기(django project)
ubuntu EC2를 하나 생성해서 nginx-server로 명명하고 다음과 같은 절차들을 진행해준다.
sudo apt update
sudo apt-get install python3-pip
sudo pip3 install gunicorn
sudo apt-get install supervisor
sudo apt-get install nginx
sudo pip3 install django
django-admin startproject django_nginx
cd django_nginx
vi django-nginx/settings.py
settings.py의 allowd_host를 [“ * ”] 로 수정해준다.
cd /etc/supervisor/conf.d
sudo touch django.conf
[program:gunicorn]
directory=/home/ubuntu/django_nginx
command=/usr/local/bin/gunicorn --workers 3 --bind unix:/home/ubuntu/django_nginx/app.sock django_nginx.wsgi:application
autostart=true
autorestart=true
stderr_logfile =/logs/gunicorn.err.log
stdout_logfile=/logs/gunicorn.out.log
위와같이 django config를 입력해준다.
- 소켓 웹서버를 진행하게 되는데 wsgi application 안의 소켓을 사용하겠다
- autostart : 자동으로 재시작하겠다
- 로그파일들이 어디 저장되는지에 대한 설정
sudo mkdir /logs
sudo supervisorctl reread
이때 gunicorn: available 이라고 뜨면 정상적으로 지금까지 진행된 것이다.
sudo supervisorctl update
업데이트까지 진행해준다.
cd /etc/nginx/
cd sites-available
sudo touch django.conf
sudo vi django.conf
server{
listen 80;
server_name *.compute.amazonaws.com;
location / {
include proxy_params;
proxy_pass <http://unix>:/home/ubuntu/django_nginx/app.sock;
}
}
이번에도 django config를 위와같이 작성해준다.
sudo ln django.conf /etc/nginx/sites-enabled/
sudo service nginx restart
이제 확인해보면 nginx가 잘 구동되고 있는 것이다!
putty를 종료하여도 서버가 구동되고, 이미지를 생성하여 EC2를 생성하여도 마찬가지로 구동되게 된다.
sudo service nginx restart 했을때에 에러가 발생했었다. 저 두가지의 메세지 중에서 "journal -xeu nginx.service"를 보고 가늠을 할 수 있었다.
prox_pass 라고 되어있는 것을 proxy_pass로 수정해주어 문제를 해결할 수 있었다.
그런데 이번에는 config file 수정할때 이때 wq!가 안먹는 것이 아니겠는가..?
이 문제는 위의 방식으로 해결할 수 있다.
패스트캠퍼스 [직장인 실무교육]
프로그래밍, 영상편집, UX/UI, 마케팅, 데이터 분석, 엑셀강의, The RED, 국비지원, 기업교육, 서비스 제공.
fastcampus.co.kr
*본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.
'Devops > Fastcampus 캐시백 챌린지' 카테고리의 다른 글
패스트캠퍼스 캐시백 챌린지 31일차 (0) | 2022.05.18 |
---|---|
패스트캠퍼스 캐시백 챌린지 30일차 (0) | 2022.05.17 |
패스트캠퍼스 캐시백 챌린지 28일차 (0) | 2022.05.15 |
패스트캠퍼스 캐시백 챌린지 27일차 (0) | 2022.05.14 |
패스트캠퍼스 캐시백 챌린지 26일차 (0) | 2022.05.13 |