-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bugfix/Inhabas#286] github actions 개선 및 버그 수정 #304
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
안녕하세요 :) 1기 팀장으로 있었던 양태영입니다.
이전에는 장고로 개발했었는데, 요즘은 스프링으로 개발하나보네요 :)
주제넘지만, 감회가 새로워서 코드도 볼 겸 현업자 입장에서 리뷰 몇 개 남겨볼테니 한번 고민해보시는 것도 성장에 있어 도움이 많이 될 것 같습니다.
if [ -d "$REPO_PATH" ]; then | ||
cd $REPO_PATH | ||
git checkout dev | ||
git pull | ||
else | ||
echo "Error: Directory $REPO_PATH does not exist." | ||
exit 1 | ||
fi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
먼저 짧게 배포 시퀀스를 보니 git checkout -> 도커 빌드 -> 컨테이너 실행 순 인 것 같습니다.
현업에서도 일부 이렇게 하는 회사가 있겠지만, 표준은 아닌 편입니다.
버전 관리도 어렵고, 롤백 시 특정 브런치에 의존하기 때문에 버그 발생시 대응이 조금 어려울 수 있습니다.
SSH로 배포시퀀스를 구성하신다면 일반적으로 CI툴에 빌드에 대한 책임을 넘기고, SCP 액션을 통해 빌드된 파일만 넘겨서 해당 서버를 실행시키는 것이 좀 더 표준적일 것 같네요 :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
docker를 빌드하기 위한 액션들도 오픈소스로 꽤 많은 편입니다.
이런 액션을 쓰지 않고도 물론 명령어를 직접할 수도 있으니 어디까지나 참고용도로 봐주세요 :)
안녕하세요~ 전혀 주제 넘지 않습니다... 안그래도 현재 코드가 어느 부분이 부족한지 알기 쉽지 않아서 고민중이었습니다. 처음 spring으로 개편할때는 태영님이 만드신 장고서버보다 나은 서버를 만들려고 했는데 권한부분이 하도 복잡해서 구현하다가 오히려 삭제한 기능도 꽤 있었고 솔직히 속도나 유지보수 측면에서도 나아졌는지도 잘 모르겠습니다. spring 코드나 아키텍쳐나 데브옵스 부분(아주 적지만) 어느 부분이든 리뷰 남겨주시면 적극 반영하려 노력하겠습니다. |
- name: Notify Discord on Success | ||
if: success() | ||
run: | | ||
curl -H "Content-Type: application/json" \ | ||
-d '{"content": "Production deployment completed successfully!"}' \ | ||
${{ secrets.DISCORD_WEBHOOK_URL }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
직접 API를 찔러보는 것도 좋지만, 찾아보니 이런 툴을 써보는 것도 재밌겠네요 :)
https://github.com/marketplace/actions/discord-message
다만 배포가 완료되었다고, 컨테이너가 실행되었다고 바로 서버가 구동가능한 상태가 아닐 수 있기 때문에 중간 과정에 API를 통해 헬스체크하는 과정을 추가하고, 해당 과정이 통과 한 후에 보내는 것도 방법이지 않을까 싶습니다.
docker rmi $IMAGE_NAME | ||
fi | ||
|
||
docker build -t $IMAGE_NAME . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
도커 빌드를 로컬 머신에서 계속하게되면 배포할 때마다 빌드한 이미지 스냅샷이 쌓이기 때문에 용량 관리에 좋지 않습니다. (참고 https://cloud-allstudy.tistory.com/1942) 비용도 많이 나오겠죠?
배포 후에 이미지 스냅샷을 비우는 스탭을 추후에 추가한다거나, 관리하는 머신이 있다면 cron 등의 과정을 통해 주기적으로 삭제해주는 편이 좋습니다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
아마 EC2로 관리하고 계셔서 SSH를 사용하고 계시지 않을까 생각이 듭니다.
도커를 좀 더 제대로 컨테이너 기반으로 배포하고 관리하실 거면 AWS ECS(Elastic Container Service)를 Fargate기반으로 사용해보시는 것도 도움이 될 것 같습니다. (inhabas 정도의 트레픽이면 제일 낮은 스펙으로 배포해도 문제 없습니다.)
이전에 프로젝트 할 때 유사한 조건으로 실제 회사에서 배포하는 시퀀스에 맞게 ECS에 배포 시퀀스를 구축한 경험이 있는데, 만약 ECS통해서 배포하신다면 글 보시고 도움이 되셨으면 좋을 것같네요 :) (더 좋은 글들도 많으니 찾아보셔도 됩니다.)
프론트 쪽도 AWS Amplify 통해서 배포하면 엄청 쉽게 배포가 가능할텐데, 그건 예진이와 상의해보세요 :) (CSR이 아니라 좀 어려울 수도 있겠네요 허허허)
사실 신입 기준에서도 쉘 스크립트를 이렇게 써서 배포한 것도 매우 잘한 것이니 자부심을 가지셔도 됩니다.
항상 힘내세요 :)
네 질문 주셔도 됩니다. 사실 저도 되는 시간에만 답변하니까요 ㅎㅎ 편하게 질문 주시면 저도 편하게 답변 드리도록 하겠습니다. 🤣 꼭 코드 관련 질문 아니더라도 취준이나 이런걸로 어려움 있으시면 연락주세요 :) public 레포라 연락처를 이곳에 남기긴 좀 그래서 예진이 통해서 전달받으셔서 저에게 연락해주세요 :) (카톡 문자 다 됩니다~) |
안녕하세요! 태영님. 조언 해주신대로 ECS, ECR을 사용해보려고 하였으나 몇몇 걱정되는 문제가 있어서 질문 남깁니다!
링크로 주신 글도 읽어봤는데 저와 서버 구조가 조금 달라서 갈피를 좀 못잡고 있는 상황입니다. 비용, 깔끔한 CI/CD, 컨테이너화 모두 챙기고 싶은데 쉽지 않네요... 질문도 막연하고 상황 설명도 부족하지만 지금 상황에선 어떻게 하는게 최선일지 약간의 의견이라도 주실수 있을까요? |
@whitem4rk 먼저 질문 주신 부분에 대한 답변은 아래와 같습니다.
Cloud Config Server 의 경우 필요하다면 말씀 주신대로 컨테이너를 분리해서 띄우긴 해야하는데요. 질문 드리고 싶은 부분은 왜 도입하려고 하시는 걸까요? 일반적으로 회사에서는 MSA 환경에서 서버를 관리를 좀 더 용이하게 하려고 사용하긴 한데, 사연 주신 부분에서는 기능적으로는 API 서버가 모놀리식인 것 같아서, 굳이 컨피그를 위한 서버를 두어야 할지 의문이긴 합니다. (물론 제가 구성 및 의도를 몰라서 그런걸 수도 있으니 해당 부분은 질문이라고 보시면 될 것 같습니다.) 제가 구성한다면, 2개의 컨테이너(ecs fargate || ecs ec2) 정도는 필수적으로 띄우고 grafana는 AWS 에 등록해서 사용하는 방식으로, 컨피그 서버는 별도로 두지 않고 프로파일만 분리해서 빌드 시 환경변수만 주입하는 방법으로, k6는(제가 아는 k6가 맞나요? 성능 테스트 용도인)로컬에서 테스트 보는 용도로만 사용 할 것 같습니다. Github Action 등으로 배포 시 자동화 할 계획이라면 다른 얘기일 것 같긴 한데, IBAS 구조 상 비용적으로 어렵진 않을 지 우려가 되네요. 사실 현 상태를 이렇게 읽는 것으로는 어떤 부분에서 정확히 문제가 있으신 지 파악은 안돼서, 시간이 되시면 한번 연락주시고 서비스를 한번 설명해주시고, 구성을 함께 고민해봐요. 😄
|
applicaiton.yml
dump data로 수정기존 문제 - PR시 헤드브랜치가 아닌 베이스브랜치 코드를 기반으로 실행되는 문제
main
에 병합 시dev
서버 배포 후 webhook 발생release-*
형태로 생성된 branch는production
서버 배포 후 webhook 발생