코끼리 개발 일지
1.[FE][https] 인증서 관련 문제 - ERR_CERT_COMMON_NAME_INVALID
프론트엔드에서 백엔드에게 요청을 보냈더니 아래와 같은 오류가 발생했다GET https://api.co-kkiri.com/my-page/info net::ERR_CERT_COMMON_NAME_INVALID기존에 백엔드와, 프론트엔드 서버 자체를 인스턴스를 분리하
2.[FE][https] SSL/TLS와 http - SNI를 설정하자
단일 IP주소에서 수신을 대기하는 두 개 이상의 https 서버를 구성할 때는 몇가지 문제가 발생할 수 있다.nginx 공식 문서우리는 이전글에서 서술한 것처럼 백엔드와 프론트엔드 서버를 하나의 인스턴스 내에 합치는 중이다.이전에 각 인스턴스에 하나의 서버를 사용할 때
3.[GitHub] Squash and Merge를 선택한 이유
기존 프로젝트에는 three-way 나 fast-forward 상관 없이 git flow를 따르며 merge하는 행위 자체에 의의를 뒀었다.하지만 이슈가 쌓이고, 그래프들이 많이 merge될 수록 git graph가 몹시 지저분해져 보기 싫었다.git flow를 지키
4.[FCM] 알림을 만들어보자 - 1. 어떤 기술을 사용할까?
우리 사이트는 이미 개발 중이고, 실제 오픈을 앞두고 있다.거의 다 개발이 완료된 상황에서, 백엔드분들이 손을 떼게 되어 프론트엔드 인원만 남은 상황에 중요한 한가지를 빼먹었음을 깨달았다.단순히 어떠한 이벤트가 발생하면 메세지함에 표시되는 것은 물론이고, 브라우저 PU
5.[Github] [Action] 조직 전체에서 같은 Action을 사용하기 - .github 레포지토리
프로젝트를 진행하면서, 점점 여러 프로젝트가 생기기 시작했다.모노 레포로 사용하지 않고, 조직 내에 각 프레임워크마다 하나의 레포지토리를 만들어서 관리하다보니 새로운 레포지토리를 만들 때마다, Action을 옮겨야하는 귀찮은 상황이 발생하였다. 2개뿐이긴 하지만이러한
6.SSL 인증서 재발급은 제 때 하자 - net::ERR_CERT_DATE_INVALID
4월 중순에 프로젝트를 일부 마무리하고, co-kkiri 사이트를 배포했다.이 때, https 통신을 위해 ssl 인증서를 'certbot'을 통해 발급받고 nginx config에 연결하였다.무료로 ssl인증서를 받게 도와주는 라이브러리Let's Encrypt 인증서
7.[Github] 레포를 복사해보자 - Import Repository
새로운 프로젝트를 시작하게 되었다.새 조직을 파면서, 기존 프로젝트에서 사용하고있는 액션이나, 컨벤션들을 옮길 상황이 발생하였다.기존 프로젝트에서는 .github라는 특수한 목적의 레포지토리에서 action이나 template를 관리하고 있었다.이 레포지토리를 다시 만