Github Action 을 적용하기 위해서는 우선 Github 에 Action을 적용할 저장소가 필요하다.

우선 Github Action을 적용하기 위한 프로세스를 간략하게 나열하겠다.

1. 프로젝트를 Github 원격저장소에 올린다.
2. 프로젝트 가장 바깥에 .github/workflows 폴더를 만들어 그 안에 작업 yaml 확장자로 코드를 작성한다.
3. 배포할 서버에 원격저장소 프로젝트를 받는다. -> git clone "주소" (굳이 안해도 된다)
4. Github 원격저장소에 Settings 에 들어가 Actions 탭을 클릭 후, Runner 를 클릭한다.
5. new self-hosted runner 버튼을 클릭한다.
6. 자신에 맞는 OS 를 선택 후, 배포할 서버에 아래쪽 코드를 전부 작성한다.

위의 프로세스로 작업을 해 보겠다.

1. 프로젝트를 Github 원격저장소에 올린다

필자는 이미 올렸다.

2. 프로젝트 가장 바깥에 .github/workflows 폴더를 만들어 그 안에 작업 yaml 확장자로 코드를 작성한다.

우선 프로젝트 폴더 Root 위치에 .github/workflows 폴더를 만들었다.

그 후, 필자는 blank.yml 이라는 파일을 생성했다.

blank.yaml

name: CI/CD

on:
  push:
    branches: [ master ]

jobs:
  build:
    runs-on: self-hosted

    steps:
    - name: Pull Master Branch
      run: |
        cd /var/www/roadmap/ && sudo git pull origin master
        
    - name: Deploy with React Build
      run: |
        sudo sh /var/www/roadmap/deploy.sh

필자는 master 브랜치에 push 를 할 경우 action 을 잡았다.

jobs 에 runs-on 은 따로 Linux 서버를 이용하기 때문에 self-hosted 로 적용했다.

그리고 steps 에는 sudo sh /var/www/roadmap/deploy.sh 했는데, 해당 코드는 React 프로젝트를 빌드하고 Django 가 Build 된 정보를 추적할 수 있도록 설정하고, collectstatic 하고, nginx 및 uwsgi 를 재부팅 하는 코드를 작성했다.

그래서 Action 으로 는 이 .sh 파일을 실행하도록 명령한 것이다.

3. 배포할 서버에 원격저장소 프로젝트를 받는다.

필자는 이미 git clone 으로 해당 프로젝트를 다운로드 받았다.

4. Github 원격저장소에 Settings 에 들어가 Actions 탭을 클릭 후, Runner 를 클릭한다.

5. new self-hosted runner 버튼을 클릭한다.

6. 자신에 맞는 OS 를 선택 후, 배포할 서버에 아래쪽 코드를 전부 작성한다.

필자는 Linux 인데 sudo 로 ./config.sh --url ... 를 작성하면 sudo 로는 못한다는 에러가 난다... 이때 앞에 RUNNER_ALLOW_RUNASROOT="1" ./config.sh --url... 같이 하면 된다.

해당 작업을 전부 하고, service 로 올리기 위해 sudo ./svc.sh install 작업을 한다.

그 후, 서비스를 실행한다. sudo ./svc.sh start

서비스를 종료하고 싶으면 sudo ./svc.sh uninstall 한다.

완료

이제 모든 작업이 완료 되었다!!!

프로젝트를 수정해서 master 에 push 하면 이제 자동으로 배포 작업을 할 것이다!!

아주 편리해졌다!!

아래 사진은 Action 을 수행한 모습이다.

CI/CD 로 엄청 많은 프로세스를 생략시켜 삶의 질이 향상 되었다!!

SQS 란?

'SQS'는 아마존 웹 서비스(AWS)에서 제공하는 메시지 큐 서비스입니다. SQS는 분산 애플리케이션, 마이크로서비스 및 서버리스 애플리케이션에서 메시지를 보내고 받는 데 사용됩니다.

메시지 큐는 송신자와 수신자 간의 비동기적인 통신을 위해 사용되며, 메시지를 보내고 받는 방식으로 작동합니다.

송신자는 메시지를 큐에 보내고, 수신자는 해당 큐에서 메시지를 가져와 처리합니다.

이러한 방식으로 메시지 큐를 사용하면, 다양한 애플리케이션 간에 안정적이고 확장 가능한 통신을 구축할 수 있습니다.

SQS는 서버리스 환경에서 사용하기 적합하며, 다양한 AWS 서비스와 통합할 수 있습니다.

SQS를 사용하면 메시지 큐 관리 및 처리를 간편하게 수행할 수 있습니다.

SQS는 여러 사용자가 동시에 큐를 사용할 수 있으므로, 고성능 및 확장성이 보장됩니다.

SQS 사용하기 위한 준비 작업

1. 아마존 웹서비스에 가입을 합니다.

2. https://ap-northeast-2.console.aws.amazon.com/sqs/v2/home?region=ap-northeast-2#/ 에 들어가서 SQS 페이지로 갑니다.

3. 대기열을 생성합니다.

4. iam 에서 sqs 권한을 생성합니다.

full 권한이 있습니다.

sqs 액세스 정책도 해당 iam 으로 변경합니다.

(iam 정보는 iam 쪽에 있습니다.)

오랜만에 글을 올리네요.

요즘 너무 바빠서 블로그에 손을 대지 못했는데 기존에 프로젝트를 하면서 새로운 지식을 얻게 되어, 이렇게 기록을 합니다!

프로젝트를 하면서 알림을 보내야하는 경우가 있습니다.

이때, 이메일로 보낼 수도 있지만 이메일로 보내는 경우 비용(개발자 리소스)이 많이들기 때문에 슬랙으로 모니터링 할 수 있는 방법을 기록하려고 합니다.

1. 슬랙 웹훅 설정

슬랙에 스페이스를 만들고 더보기를 클릭합니다.

앱을 클릭합니다.

검색창에 in 으로 검색을 한 후, 수신 웹후크의 추가 버튼을 클릭합니다.

그러면 아래와 같은 화면 웹 브라우저가 켜집니다. 이때 Slack에 추가를 클릭합니다.

원하는 채널을 선택합니다.

설정을 완료하면 아래와 같은 웹후크 url 이 나옵니다.

이 웹후크 URL 를 기록합시다.

추가로 아래 쪽으로 스크롤 하다보면 이 웹후크 설정 내용을 확인할 수 있습니다.

웹후크 시, 웹후크에서 보내는 아이콘의 이미지를 수정한다던지 그렇습니다.

2. 웹후크 실행

웹후크를 실행하는 방법은 http 통신으로 가능합니다.

예제를 보면 curl 로 이용할 수도 있죠.

아래와 같이 사용할 수 있죠!

하지만 저는 python 프로젝트에서 이를 사용하려고 합니다.

그러면 python 코드로 이것을 간단하게 모듈화 하여 사용합시다.

def notify_slack(channel_url: str, text: str):
    payload = json.dumps({
        'text': text,
    })
    requests.post(
        url=channel_url,
        data=payload,
    )

(requests 모듈을 설치했습니다. pip install requests)

위 코드에서 channel_url 을 복사했던 링크입니다.

text 는 전달할 메시지입니다.

이제 함수를 실행하면 정상적으로 텍스트가 전달됩니다.

동글이/네모니

동글이: 안녕하세요~! 저는 동글이에요!

네모니: 안녕하세요~! 저는 네모니에요!

글을 작성할 때, 도와줄 캐릭터를 만들어 보았다.

Django 와 React 프로젝트를 진행하면서 배포를 하기 위해서는 Git 레포지토리에 push 하고 서버 컴퓨터에 pull 을 받은 상태에서, 매번 React 프로젝트를 Build 한 다음 Build 된 폴더를 Django 가 가리키는 static 폴더로 옮기고 collectstatic 해야한다.

그 후, 웹서버와 웹서버게이트웨이 인터페이스를 재실행 해줘야 하는 불변함을 매번 겪어야 한다.

간단하게 이 순서를 나열하면

1. 로컬 컴퓨터에 수정한 코드를 Github 원격 저장소에 Push 한다.
2. 서비스를 하고 있는 서버 컴퓨터에 원격 접속하여 Github 원격 저장소에 올라온 수정된 코드를 Pull 받는다.
3. React 같은 경우, 수정을 반영하기 위해 Build 를 한다.
4. Build 한 폴더를 Django 가 추적할 수 있도록 static 폴더에 배치한다. (index.html 또한 따로 templates 쪽에 배치)
5. Django 에서 collectstatic 을 한다.
6. 웹서버와 wsgi 를 재실행 시켜준다.

벌써 재배포를 하기 위해서 여러 작업이 필요하다.

더 간단하게 하기 위해 CI/CD 툴을 이용했다.

CI/CD 를 도와주는 것 중에 필자가 자주 이용하는 Github 자체에 이 역할을 수행해 주는 Github Action 이라는 것이 있다고 했다.

Github Action 은 간단하게 설명하면 로컬에서 Github 원격저장소에 하는 일련의 행위 중 (예: push 등) 무언가를 하면 해당 Github 원격 저장소를 Github Action 으로 연결된 특정 서버에서 어떤 역할(명령어 실행) 을 할 수 있도록 도와주는 것이다.

더욱 간단하게 설명하면 아래 사진과 같다.

다음 장에서 직접 구현해서 프로젝트에 적용해 보자!

예전에 "달고나" 라고 하는 큰 동아리?? 말로는 이제 더이상 동아리가 아니고 연합? 이다??? 라고 하는 조직이있다.

이곳에서 Django 이용하여 백엔드 서버를 구축한 적이있다.

그런데, 2021년 11월 정도에 이제 만든 프로젝트를 사용하지 않고 "그누보드" 를 이용하여 한다는 말과 함께 AWS 에 올려놓은 EC2, S3, RDS 전부 사라지게 생겨서 어떻게 할까 고민을 했다.

그래도 나름 열심히 노력해서 만든 프로젝트여서 그래도 '남길 수 있으면 남기자!' 라는 마인드로 Oracle Cloud 를 이용하여 공짜 인스턴스를 이용해 백엔드 서버와 프론트엔드 서버를 구축하기로 마음 먹었다.

이 작업을 하기 위해 무엇을 해야하는지 순서대로 생각해보았다.

1. Django 백엔드 서버 만들기
2. 데이터베이스 복사하기
3. S3 이미지, 파일 로컬서버로 옮기기
4. 데이터베이스에 저장되어있는 이미지 url 주소 S3 가리키고 있는 것 로컬로 Update 시키기
5. React Build 후, 프론트엔드 서버 만들기 (새로운 백엔드 바라보기)

정도가 있었다.

1. Django 백엔드 서버 만들기

이 작업을 하기 위해 우선 Oracle Cloud 를 가입했다.

Oracle Cloud 같은 경우, 총 2개의 인스턴스를 무료로 계속 사용할 수 있었다.

그렇기 때문에 인스턴스 1개는 백엔드 서버용, 다른 1개는 프론트엔드 서버용으로 이용하려고 인스턴스를 생성했다.

인스턴스 생성 후, VPC 에 Subnet 규칙 중에 포트 80(HTTP), 443(HTTPS), 3306(MySQL) 가 제한되어 있어 규칙을 추가했다.

그런데, ssh 로 접속하려고 하는데 안되던 것이다...

분명 22 포트는 열려져있는데.. '왜 이러지??' 생각을 하면서 다시 인스턴스를 껏다 켰다...

이 과정에 인스턴스 재부팅 시간이 너무 오래 걸려 '일단 다른 인스턴스에 접속해보자...' 라는 생각으로 다른 인스턴스에 접속했을 때는 잘 되었다...

ssh 원격 접속 후, 내 github 주소에 Private 로 올려놓았던 프로젝트를 clone 받았다.

그리고, WAS Django 배포를 위한 Nginx, uWSGI, MySQL 등을 설치하고, 구성을 완료했다.

HTTPS 도 적용했다.

2. 데이터베이스 복사하기

기존 데이터베이스는 AWS 서비스 중, RDS로 이용하고 있었다.

어떻게 데이터를 가져올까... 라는 생각에 MySQL WorkBench 를 이용해 데이터베이스 스키마랑 데이터 전부 Dump 떠서 가져오는 결정을 했다.

그래서 RDS 주소로 WorkBench 를 연결 후, 데이터를 Export 하려고 했는데... 뜬금 없이...

mysqldump.exe: unknown variable 'column-statistics=0'

에러가 나오는 것이다...

문제를 찾아보니, 현재 내가 사용하고 있는 WorkBench의 Dump 역할을 수행해주는 mysqldump Tool 버전이 맞지 않아 문제가 되는 것이었다.

아래 사진과 같이 해결 방법을 찾아 아래 사진에 보이는 링크에 들어가 다운로드 받았다.

그리고 Edit -> Preference -> Administration 에 Path to mysqldump Tool 경로를 다운로드 받은 압축파일을 풀고, bin 폴더에 있는 mysqldump.exe 을 새로 연결시켜주었다.

이제 잘 데이터를 Dump 할 수 있었다.

이제는 WorkBench 를 이용해 새로운 백엔드 서버에 설치한 MySQL 서버에 연결하여 이 Dump 뜬 데이터를 집어넣어야 했다.

이 또한 WorkBench 기능 Import 로 쉽게 해결될 줄 알았지만... 어림도 없이 에러가 발생했다.

Access denied; you need (at least one of) the SUPER privilege(s) for this operation

이런 에러가 나왔다....

이 해결 방안은 dump 뜬 파일 안에 몇 줄만 주석처리 했으면 됐다.

위에 사진과 같이 저 부분만 주석처리하면 문제가 해결 되었다.

3. S3 이미지, 파일 로컬서버로 옮기기

기존 백엔드 서버는 media 파일을 전부 S3 에 업로드 하여 관리했다.

그렇지만 S3 조차 돈을 낭비하기 싫기 때문에 Oracle Cloud 에서 생성한 인스턴스로 제어하고 싶었다.

그래서 모든 S3 이미지를 로컬서버로 옮기는 작업을 해야 했다.

S3 에 들어가보니 폴더로 파일들을 다운로드할 수 없었다.

그래서 찾아보니 AWS CLI 를 이용하여 폴더 기준으로 다운로드 하는 방법을 찾았다.

sudo apt install awscli

우선 AWS CLI 를 백엔드 서버에 설치하고, aws configure 명령어로 기본 AWS 설정을 잡아줬다.

aws configure

설정을 마치고 aws s3 명령어로 모든 파일을 원하는 위치에 다운로드 했다.

aws s3 cp s3://{버켓이름}/media ./media --recursive

그러고 Django 설정에 S3 설정을 기존 로컬 static 과 media 설정으로 바꾸었다.

4. 데이터베이스에 저장되어있는 이미지 url 주소 S3 가리키고 있는 것 로컬로 Update 시키기

게시글에 이미지를 삽입할 수 있었는데, 이때 url 경로를 이용해서 이미지를 띄우고 있었다.

하지만 기존 이미지는 S3 url 을 가지고 있어서 변경이 필요했다.

그래서 데이터베이스에 전에 사용하고 있는 S3 url 을 전부 현재 로컬서버 url 주소로 변환이 필요했다.

SELECT REPLACE(body, '이전주소', '현재주소') AS body
FROM dalgona.board_board_post 
WHERE body LIKE '%이전주소%';

UPDATE 데이터베이스.board_board_post  SET body = REPLACE(body, '이전주소', 'https://dalgonabackend.shop') WHERE body LIKE '%이전주소%';

위에는 잘 됐는지 테스트 SQL 문이고, 아래가 UPDATE 하는 문이다.

당연히 될 줄 알았지만!! 어림도 없이 WorkBench 에서 "너 정말로 UPDATE 다 칠꺼야?" 라는 에러와 함께 나를 힘들게 했다....

이 작업을 수행하기 위해서 Edit 에 있는 Preference 를 건들어야 했다.

위에 사진에 보이는 SQL Editor 부분을 클릭하고, Safe Updates (rejects UPDATEs and DELETEs with no restrictions) 체크를 해제한 후, 다시 데이터베이스를 들어와야 했다.

그러고 다시 SQL 문을 실행하면 잘 작동했다.

5. React Build 후, 프론트엔드 서버 만들기 (새로운 백엔드 바라보기)

이 부분은 프론트엔더 개발자가 따로 있는데, 그분에게 요청을 했다!!

나중에 프론트엔드 서버도 구축은 내가 하겠지만 일단 React 코드를 받아서 Build 작업이 남았기 때문에 기다리고 있다.