Dahoon06 Store

시간이 날 때 하자 해서 미루고 미루었던 파일 업로드 api를 만들고 deploy 브랜치에 코드를 올렸다. 근데 서버가 죽었다.. 처음에는 콘솔에 cors가 찍혀있길래 어??? 갑자기 왜??? 그래서 다시 배포를 해보았는데 맙소사... 서버가 켜지질 않는다.. 와 진짜... 어떻게 해놓은건데 서버가 그래버리나.. 부랴부랴 새벽에 찾아보면서 일단 대충 도커를 새로 빌드해보고, ec2도 껏다켜보고... 했는데 세상에 이제는 github actions 도 안되는것... 먼저 어디서 에러가 났는지 알고싶어 로그를 확인해보려고 EC2에 접속하였다. 로그 확인전에 컨테이너가 돌아가는지 확인을 하려고 했더니.. 권한 문제의 경우는 블로그를 찾아다니면서 쉽게 해결할 수 있었다. # 1. 보통은 docker group이..

EC2에 도커를 띄우고 이제 그 관리를 script를 만들어서 하려고 했으나, 동갑내기 사원님이 테스트 프로젝트로 github actions에 성공했다고 해서 부랴부랴 지금 프로젝트에 세팅을 하였다. (액션을 세팅하는 부분은 추후에 정리하여 포스팅할 예정...!) 💡 CI/CD (Continuous Integration/Continuous Delivery) CI: 빌드 / 테스트 자동화 과정 (지속적인 통합) CD: 배포 자동화 과정(지속적인 배포) 세팅까지 끝내고, back-deploy test push 를 해보는데 초록불 두둥!!! 모야 간단하네!!!! 라고 생각하고 사이트를 접속해 보는데 정상적으로 작동!! 그래서 한번 더 테스트 해 볼겸 스웨거를 업데이트 하고 다시 돌려보는데 스웨거가 업데이트가 ..

이번 프로젝트를 진행하면서 인프라 관련해서 4가지 정도의 목표를 잡았었다. 첫번째. backend Docker에 올린 후 EC2에서 실행시키기. 두번째. docker 관련 script 만들어서 명령어 하나로 관리되도록 하기 세번째. github Actions 를 사용하여 자동 배포 시스템 만들기. 네번째. EC2가 버텨준다면.. 프론트도 EC2로 옮겨서 하나의 EC2에서 프론트, 백 관리 (여기서 Nginx 다뤄보기) 세번째, 네번째의 경우 여유가 된다면이라는 조건을 두고 첫번째, 두번째는 무조건 하기로 했다. 조건을 둔 이유는 각자의 회사 업무도 있고, 이 프로젝트의 기간의 경우 정말 길어봐야 한달을 잡았기 때문에 시간적 여유가 되면하기로 했다. 회사에서 도커 컨테이너 기반으로 빌드, 배포를 하고 있는..

현재 내가 작성하는 Vue 3 코드를 보며 의문점이 들었다. 새롭게 변화된 부분을 알고 싶어서 Vue 3를 사용해보는데 작성된 코드를 보면 Vue 2랑 완전히 똑같다... Vue 3 Doc를 보면 setup 에 관련해서 계속 나오는데 나는 이를 전혀 사용하지 않았다. 다른 점이라고는 Vue 2 에서 @Components({}) 로 컴포넌트를 불러왔다면 @Options({}) 로 불러와야한다는 점, store 를 사용하기 위해서 useStore() 훅을 사용한 점 말고는 완전히 똑같은 코드가 되었다. store를 사용한 시점부터 콘솔을 열어보면 아래 이미지의 경고문이 계속 나온다. 기존 사용 방식인 class 형태의 컴포넌트에서 this.store로 접근했던 방식이 아닌 store = useStore() ..

도메인이 no1recipe.com 으로 결정되었다. recipe 와 관련하여 둘 이 생각을 하고 또 해보는데 도저히 도메인이 생각나지 않았다.. 도메인 후보로는 - recipenote - appfanatic - cook4me - cookcoo - no1recipe 이정도가 있었는데 일단 저걸로 하기로 (도메인 정하기 진짜 어려웠다...) 이번 사이드 프로젝트는 기준을 정해놓고 시작하였다. 첫째. 최대한 짧게 진행할 수 있도록 최소한의 기능만 만든다.! 두번째. 사용해보지 않았지만 해보고싶다 라고 생각이 드는게 있으면 해보는 것.!! 그리고 역할 분담 프론트, 백 각자 역할을 나눠서 개발을 진행한다. 원래 이렇게 하는거 아닌가 생각할 수 있지만 지금의 회사는 프론트와 백을 나누지 않는다. 각자 맡은 기능이..

www.no1recipe.com Recipe 빠르게 찾고 빨리 해먹자. No.1 Recipe www.no1recipe.com 동갑내기 사원 한 분이 있는데 학원에서 했던 결과물이 아쉽다고 비슷한 주제로 같이 만들어보자고 제안을 해주셔서 같이 해보기로 했다. 주제는 음식 레시피 관련된 반응형 웹 사이트 이다. 초기 버전의 경우 정말 간단한 CRUD 의 기능만 있는 게시판 형태의 사이트이다. 각자 맡은 업무도 있기도 하고, 처음부터 크게 잡으면 흐지부지될걸 알기에 빨리 할 수 있는 정도의 양으로만 정했다. 프론트 개발은 Vue cli 3, 백엔드 개발은 NestJs, DB는 MongoDB 를 사용한다. 스택은 현재의 회사 기술 스택에 맞춰서 진행하되 각자 추가하고 싶은게 있다면 언제든지 추가하는 방향으로 잡..

백엔드를 맡고 있는 형과 같이 발급받은 ssh key 를 등록을 하려는데 아무래도 가장 걱정됐던 부분은 요금 문제였다. 혹여나 요금 폭탄을 맞지 않을까하는 마음에 등록하기전에 ACM 에 붙어 있는 여러 서비스 링크를 따라가면서 인증서를 등록하고 난 다음에 어떤 구조로 흘러가는지 따라가봤다. 근데 뭔가 이건 상당히 잘못됐다라는 느낌을 많이 받았다. ( 배보다 배꼽이 더 큰 느낌... ) 사실 그냥 이런 서비스도 있으니까 한번 사용해봐라~~ 이런 글이였는데 둘 다 처음이다 보니...무조건 써야하는줄 알았다. "아니 이게 맞아...? 저거 다 써야한다고?????" 딱 이런 느낌...ㅎㅎ 그래서 다시 각자 알아보기로 하고 저날 인증서 등록은 포기하고 일단 프론트를 다시 넷리파이로 옮겨놨다. 몇일 지나고 회사에서..

이전 포스팅에 이어 SSL 인증서 발급 받았던 방법이다. SSL 인증을 받으려고 했던 이유는 처음에 HTTPS 통신을 하기 위해서는 프론트와 백엔드가 동일한 인증서로 사용해야만 서로 호출이 가능한줄로 알았다. 그래서 발급 받은 인증서로 프론트는 넷리파이에 인증서를 올리고, 백엔드도 ACM에 인증서를 올리는 방법으로 방향을 잡았다. 참고한 블로그에 발급받는 정리가 잘 되어있어 많은 도움이 되었다. 일단 발급받는데 까지는 성공했는데 문제는 EC2에 접근해서 인증서를 가져오는 것.. (하나 성공하면 또 다른 하나가 문제...) EC2에 접근해서 파일을 가져오려면 FTP 를 사용해야해서 파일질라를 써보기로 했다. 파일질라도 회사에서 메뉴얼 작업 때문에 다뤄본적은 있지만 개인적으로 파일을 다운받기 위해서 사용해 ..

프론트는 넷리파이를 통하여 정적 웹 호스팅을 하였고, 백엔드의 경우 aws 에 배포하여 운영하고 있다. 문제는 프론트는 HTTPS, 백엔드는 HTTP 이기 때문에 프론트에서 백엔드로 API 호출 시 Mixed Contents 에러가 발생하게 된다. 도메인 구입부터 해서 배포까지 모든게 처음이다 보니까 문제를 해결하는데 있어서 두달 가까이 걸렸다... 가비아에서 도메인을 구입 후 처음했던 부분은 넷리파이의 DNS 정보를 가비아에 등록하였고, 구입한 도메인으로 사이트가 잘 들어가져 괜찮을 줄 알았지만 백엔드가 문제였다. 프론트는 HTTPS 로 올라가져있고, 백엔드는 HTTP 인데 Route53에 도메인이 등록되어있지 않기 때문에 ACM을 사용하지 못하였다. 그래서 생각했던 건 ssh 키를 발급받아서 ACM에..