나름 개발자의 IT블로그

지난시간 nginx설정한 도메인으로 들어가보면 http연결이라고 뜨면서 주의요함이라는 메시지를 받는다. https연결을 사용하지 않았기 때문이다. 그리고 mixed content문제라고 해서 프론트 접속할 때 https를 쓰고 백엔드 접속할 때 http를 사용하면 불러오지 못하는 문제가 생긴다. 특히 기본 https를 제공하는 gh-pages랑 http로 설정한 백엔드로 접속하려고 할 때 의문도 모른채 생기는 오류를 접할 수 있다. 그래서 요즘은 모두 https를 사용하는게 좋다. nginx에서 https를 적용하는 법을 알아보자. nginx 파일 # /etc/nginx/sites-available/aaa.riroan.com server { listen 80; server_name aaa.riroan.c..

최근 진행하는 프로젝트가 꽤 많아져서 배포를 위해 인스턴스 한대를 혹사시키고 있다. Oracle Cloud에 있는 인스턴스 한 대에 백엔드서버 3개와 프론트엔드 페이지를 2개 배포중이다. 그러다보니 서로 다른 프로젝트의 도메인들이 같은 서버를 가리키고 있다. 현재, aaa.riroan.com, bbb.riroan.com이 하나의 서버 ip를 가리키고 있는 상태이다. 이를 위한 nginx 설정이 필요했다. riroan1.com, riroan2.com같이 도메인이 통채로 다른 경우도 가능하고 aaa.riroan.com, bbb.riroan.com처럼 접두어(prefix)만 다른 경우도 가능하다. (어떻게 생각해보면 당연하다.) 파일 작성 기본적으로 nginx설정을 하기 위해 /etc/nginx/sites-a..

배포도 잘되고 페이지도 잘 보이는데 불편한게 하나 있다. 바로 도메인이다. 현재 기본으로 사용하는 도메인은 github에서 제공하는 도메인이라 살짝 길고 불편할 수 있다. 여기에 커스텀 도메인을 사용해보자. 커스텀 도메인 일단 package.json에서 사용할 도메인으로 변경하고 push한다. // package.json { "homepage": "https://page.riroan.com", // 생략 ... 그 후 도메인을 구매한 페이지에서 CNAME으로 사용할 도메인을 riroan.github.io를 가리키게 설정한다. 나의 도메인이 깃허브를 찾을 수 있도록 레코드도 추가해야 한다. 그리고 깃허브 Repository에서 Settings -> Pages 밑으로 가면 custom domain이 나온다...

프로젝트 수정 프로젝트를 수정하고 다시 배포하려면 어떻게 해야할까? // App.js function App() { return 안녕하세요 } export default App 굉장히 간단한 수정을 하고 배포 명령을 다시 실행해봤다. npm run deploy deploy명령을 실행하면 github actions가 자동으로 동작하며 배포를 수행한다. 완료되면 ctrl+shift+r을 눌러 강제 새로고침을 하고 수정한 내용을 확인할 수 있다. Github Actions 우리는 위에서 한 과정을 Github Actions를 통해 push하면 자동으로 배포하게 할 수 있다. # .github/workflows/deploy.yml name: Deploy on: [push] jobs: deploy: name: D..

나는 지금까지 프론트엔드 페이지를 서버에 올려서 nginx로 가리키는 형식으로 배포해왔다. 최근에 깃허브 액션을 공부하며 gh-pages라는 편리하고 서버 없이 배포할 수 있는 방법을 알게돼서 신세계를 경험했다. 잊어버리기 전에 기록해두자. 프로젝트 준비 나에게 가장 익숙한 리액트를 사용할 것이지만 어떤 프레임워크를 사용해도 상관 없다. npx create-react-app my-page code my-page 프로젝트 생성 후 깃허브 repository도 만들어서 올려놓자. gh-pages 패키지 설치 이제 배포하기 위한 npm 패키지를 설치해야 한다. npm install gh-pages --save-dev yarn add gh-pages --save-dev 둘중 사용하는 것으로 설치하자. 그 후 배..

들어가기 전에 지난시간 test를 실패하게 만들어서 정상적으로 작동하지 않을 것이다. 이를 성공하도록 만들자. # test.py def test1(): assert 1+1 == 2 def test2(): assert 1+2 == 3 브랜치와 폴더 지금까지 작성한 워크플로우는 아무데나 push만 하면 작동하도록 만들었다. 이번에는 브랜치별로 나눠보고, 폴더별로 나누는 옵션을 적용해보자. 일단 temp 브랜치를 위한 워크플로우를 만들건데 이 브랜치를 위한 워크플로우를 main 브랜치에 만든다. # ./github/workflows/temp.yml name: temp branch on: push: branches: - temp jobs: job: runs-on: ubuntu-latest steps: - nam..

테스트코드 우리는 개발을 하면서 이 코드가 올바르게 작동하는지 테스트코드를 작성하곤 한다. 심지어 TDD를 사용한다면 개발을 안한상태에서 테스트코드부터 작성한다. 이렇게 테스트코드를 작성하면 배포하기 전에 한번 돌려본 후 모든 테스트를 성공해야 배포를 할 수 있다. 그럼 테스트하는 workflow를 추가해보자. pip install -U pytest 우선 pytest로 테스트를 하기 위해 의존성을 설치한다. 그리고 테스트코드를 작성한다. # test.py (local) def test1(): assert 1+1 == 2 파일 이름은 pytest특성상 test가 포함되어야 하고 함수명도 마찬가지이다. 실행은 pytest test.py를 쓰면 된다. 일단 yml 파일을 작성하기 전에 테스트 작업은 꼭 ssh..

main.yml 우선 지난시간에 작성한 yml파일부터 살펴보자. name: auto pull github actions에서 보일 이름을 정하는 부분이다. 원하는대로 지으면 된다. on: [push] 언제 이 워크플로우를 작동할지 정하는 코드이다. 어느 브랜치든 어떤 폴더든 푸시만하면 작동하게 설정했다. 옵션으로 push, pull request, issue를 정할 수 있고 브랜치별, 폴더별로도 정할 수 있다. jobs: build: name: Build runs-on: ubuntu-latest 이제 push가 되면 무슨 행동을 할 지 정해야한다. build: 라고 쓰여진 부분도 별칭이니 바꿔도 된다. 일단 이름을 Build라고 정했다. (실제 빌드하는 작업은 아니다) 그리고 그 작업을 수행할 서버를 gi..

CI/CD은 빠르고 편리한 빌드/테스트/배포를 위한 과정을 의미한다. 이미 배포한 서비스를 업데이트하기 위해 git push를 하고 모든 테스트가 통과된다면 자동으로 배포가 되는 편리한 기능이다. 이를 위한 소프트웨어로 유명한 Jenkins, Bamboo등이 있다. 이러한 소프트웨어는 개인 서버에 설치가 되어 관리가 돼야 한다. 하지만 그 서버가 고장나거나 Jenkins가 다운된다면 난처한 상황이 생길것이다. 이를 위해 Github나 Gitlab에서 클라우드같이 컴퓨터를 대여해주는 식으로 CI/CD서비스를 제공해준다. 그 중 Github Action을 이용한 CI/CD를 알아볼 것이다. CI/CD가 없다면 1. 개발을 한다. 2. 테스트를 돌린다. 3. 테스트가 모두 통과된 것을 확인하고 원격 저장소에 ..

요즘 Chat-GPT가 핫하다. 이 대화형 인공지능이 알고리즘 문제도 해결한다고 하는데 어디까지 해결할 수 있는지 궁금해서 백준 문제로 실험을 해봤다. 문제가 될까봐 실제 제출은 하지 않았고 정답이 맞는지는 내가 판단했다. 문제는 브론즈 5부터 한단계씩 올라가면서 내가 푼 문제들 중 한국어 문제 기준으로 테스트했다. B5 16394 홍익대학교 B4 16204 카드뽑기 주석까지 적는 여유가 보인다. B3 15917 노솔브 방지문제야!! B2 2954 창영이의 일기장 B1 5533 유니크 입력형식이 올바르지 않아 런타임에러가 났는데 풀이만 놓고 보면 정답이다. 입력형식이 복잡해서 그럴 수 있으니 좀 단순한 문제로 다시 시도했다. B1 1110 더하기 사이클 틀렸다. 표본이 적고 solved 난이도가 개인차에..