Django

[Django] GitHub Actions CD기능 살펴보기

Y0un9Ki 2024. 4. 24. 02:40

필자가 전 블로그에 GitHub의 기본적인 Actions과 CI기능에 대해서 살펴보았다.

하지만 아직까지 test코드를 만들어서 push나 pull_reqeust를 할때에 test를 돌려보고 test 코드를 통과하면 push나 pull_request가 되는 CI에 대해서 익숙하지 않아서 솔직히 크게 CI의 기능이 필요하지는 않았다.

 

하지만 CD기능은 자동으로 서버에 배포를 해야했기에 필자한테는 꼭 필요한 기능이다.

 

그렇기에 요번에는 CD의 기능을 한번 알아보려고 한다.

일단 개요를 보자면 필자가 local에서 개발을 진행을 한 후 push를 할때마다 서버에서 pull을 받아야 하는 번거로움이 존재했다.

그렇기에 GitHub Actions를 통해서 CD(지속적인 배포)를 자동화 할것이다.

 

그래서 workflows가 어떻게 되냐면 Events는 main 브랜치에서 push나 pull_request가 발생을 했을 때 SSH 서버를 연결하고 자동으로 서버에 pull을 진행하는 방식의 CD자동화를 진행을 할 예정이다. 또한 runners는 Ubuntu환경에서 진행을 할 예정이다.

 

일단 GCP서버를 열고 그에 해당하는 git repo를 살펴보자.

 

앞에서 블로그를 쓰면서 실습을 했던 것처럼 필자는 이미 만들어진 repo에 대해서 사용을 할 것이다.

 

일단 git에 들어와서 Actions를 보자.

필자는 django로 웹개발을 했기에 Django의 템플릿을 사용을 할 것이다. 

Django의 Configure를 눌러주자.

 

 

이러한 창이 나오게 되는데 필자가 위에서 개요에서 말한 것 처럼 workflows를 바꿔보겠다.

 

 

이 workflow의 이름은 Django CD이며 Event는 push와 pull_reqeust가 작동을 했을 때 workflows가 실행이 되며 runners는 Ubuntu의 최신버전 그리고 appleboy라는 action을 통해서 ssh의 키를 가지고 와서 EC2서버를 연결해준다. 

Jobs의 이름은 build이며 이것은 git에서 CD가 돌아갈때 나오는 이름이다. 다른걸로 바꿔도 상관없다. ##

그 다음에 우리가 pull을 받아야 하는 경로로 이동을 하고 git pull origin main으로 pull을 받아주고 SSH Shell을 restart시켜주는 CD자동화를 구현해 놓은 것이다.

 

django.yml 파일을 커밋을 진행하고 서버와 로컬에서 각각 pull을 받아준다.

 

이제 필자가 with구문으로 host와 username, key를 지정해두었듯이 git에서 이것의 값들을 각각 셋팅을 해보자.

 

해당 repo의 settings에 들어와서 Secrets and variables를 클릭하고 Actions를 눌러보면 위와 같은 화면이 나온다.

거기서 Repository secrets에 해당하는 부분에서 New를 클릭해주자.

그리고 위에 자동화 코드에서 설정을 했던것 처럼 HOST, USERNAME, KEY를 등록해주면 된다.

  • HOST : VM인스턴스의 외부 IP
  • USERNAME : GCP의 ID
  • KEY : SSH키를 생성하고 cat ~/.ssh/id_rsa를 눌러서 나오는 private키를 전부 복사해서 넣어준다.

 

이것으로 모든 설정은 마쳤다.

 

이제 CD가 잘되나 확인을 해보자.

 

엥 근데 계속 해서 안되는 것이었다.

 

처음에는 .github/workflows/django.yml의 위치가 프로젝트를 진행한 경로보다 상위에 있어서 안되는 줄 알았다.

이것이 무슨 말이냐면은 보통은 바탕화면에 폴더를 만들고 그안에 바로 django 프로젝트를 시작하지만 이것을 진행할 때에는  폴더안에 또 폴더를 만들어서 django 프로젝트를 실행했기 때문에 django-todolist/.github/workflows/django.yml의 경로가 manage.py가 존재하는 경로보다 상위에 있었다. (manage.py 경로 : django-todolist/ToDoList/manage.py)

 

그런데 나중에 에러를 해결하고 보니까 이것은 문제가 없었고 결국에는 자동화하는 파일의 경로는 밑에 경로만 잘 만족시키면 된다는 것을 알게 되었다.

.github/workflows/{자동화파일이름}.yml

이것은 전에 블로그를 작성할 때도 굉장히 강조했다. 위와 같은 경로로 안하면 에러가 뜬다.

 

결국 에러메세지를 읽어 보다가 마지막에 써놨던 코드가 err가 발생하는 것이었다. (에러메세지를 잘 읽자)

 

유튜브에 강의를 들으면서 저 코드가 SSH Shell을 다시 시작해주는 코드인줄 알았는데 그게 아닌 NGINIX, uWSGI를 연동해서 뭘 하는 코드였다. 그래서 CD자동화가 안되고 있었던 것이다.

그렇기에 그 코드 부분을 지우고 실행을 하니까 자동으로 배포가 되는 것을 볼 수 있었다.

  • sudo systemctl restart uwsgi 코드 부분을 지워주니까 잘 되는 것을 확인 할 수 있었다.

 

<수정>

열심히 찾아본 결과 ssh shell을 다시 시작하기 위해서는 아래와 같은 방식으로 script안에 Action을 작성해야된다.

sudo systemctl <action> <service-name>

 

그렇기에 위에 코드를 필자의 자동화에 맞게 사용한다면 아래코드와 같이 된다.

sudo systemctl restart ssh

 

자동화 코드를 위에 코드로 수정을 진행을 했고 잘 돌아가는 것을 확인을 했다.

근데 딱히 변화가 보이지는 않았다. 뭔가 저 자동화 코드를 넣어주면 배포된 웹을 새로고침하지 않아도 알아서 바뀔줄 알았는데 그것은 아니었다.

 

##

 

그러면 이제 서버를 켜서 확인을 해보자.

 

필자가 만들어 놓은 To-do-List이다. 이제 로컬에서 To-do-List with Django를 To-do-List로 바꾸고 git push만을 했을 때에 서버에서도 잘 바뀌는지 확인을 해보자.

 

 

로컬에서 h1태그안에 To-do-List로 바꾼 후에 git에 push를 한것을 볼 수 있다.

과연 서버는 알아서 바뀌었을 것인가? 서버를 새로고침 해주자!!!

 

서버를 새로고침 해주니까 로컬에서 변경한대로 서버에서 pull을 안했는데도 변경된게 적용된 것을 볼 수 있다.

 

이로써 GitHub-Actions을 통한 CD를 진행해보았다.

아직까지 workflows를 작성하는데 있어서 모르는게 많지만 점차 알아가면서 더욱더 많은 Action과 Job을 통해 더 많은 자동화 기능을 실현해 보고 싶다.

 

다음에는 이제 배포와 자동화가 진행되면서 라이브러리를 다운받을 때마다 서버에서도 라이브러리를 다운받아야 되는 번거로움이 있었다.

그렇기에 이를 Docker를 통해서 해결을 해볼려고 한다. 다음 블로그는 Docker에 대해서 공부를 진행한 후 블로그에 작성을 해야겠다.

 

####