BoB 11기 3주차에 접어 들었습니다.

코로나에 걸렸습니다.

아픕니다.

하…….정신이 없네요

attend 리팩토링을 해야 하는데 자꾸 미루네요. 저번주 주말은 캠핑을 다녀왔습니다. 너무 힘들어요.

여튼 이번주는 월요일~화요일 공부한 스프링 게이트웨이와 유레카에 대해 간단히 소개 드리겠습니다.

gateway 는 말그대로 게이트웨이입니다. 사용자가 요청하면 요청을 받고 url 을 분석해서 적절한 서버로 전달해주는 역할을 합니다.
eureka 는 마이크로 서비스 명단을 관리 해주는 역할을 합니다. 서비스 각각을 제어하지 않고 누가 살았는지 명단만 잘 관리해줍니다.

그림을 보면 이해가 쉬우실 겁니다.

순서대로 한번 보겠습니다. 일단 eureka 가 떠 있다고 가정하겠습니다.

1. (노란색 화살표) 스프링 클라우드가 뜨면서 eureka 에 등록을 합니다.
2. (노란색 화살표) 마이크로서비스도 뜨면서 eureka 에 다 등록이 됩니다.
3. 현재 살아있는 서버는 api, user, file, gateway 가 되겠죠. eureka 가 정기적으로 heartbeat 를 수신 받으면서 살아있는지 체크를 합니다. 만약 heartbeat 가 안오면 죽었다고 판단을 하는 것 입니다.
4. (빨간색 화살표) 사용자가 /api/blah/blah 로 요청을 보냅니다. spring cloud 는 url 을 읽고 api 서버로 보내야 함을 압니다.
5. (검은색 화살표) 그리고 게이트웨이에서 살아있는 api 서버 목록을 받습니다. 살아있는 서버 중 하나로 유저의 요청을 보냅니다.

현재 조사가 안된게 “게이트웨이에서 살아있는 api 서버 목록을 받습니다” 이 부분입니다. 목록을 받는건지 살아있는 서버 중 한곳을 리턴하는건지 더 조사해야 합니다.

이런 구조의 장점은 micro service 의 scale-out이 간편하다는 것 입니다.

더 알아 보아야 할것은 로드 밸런싱 종류입니다. 기본적으로 설정되는 로드 밸런싱 방법은 round robin 입니다. 서버 사양이 다를 경우 한 서버에 부하가 심해질 수 있으므로 다른 방법을 찾아야 할 것 같습니다.

BoB 11기 2주차에 접어 들었습니다.

저번주 너무 짧게 적은거 같아 이번주 후기는 고민을 많이 해보았습니다.

“아 잠온다”

고민은 했는데 너무 잠와서 3주차 후기에 많이 쓸께요. ㅃ

핵심 코드는 다음과 같습니다

Generic 타입의 Pass를 생성하였고 26~31까지는 패스의 색상과 이름을 정해주었습니다

backFields에 들어있는거는 패스 뒷면에 보이는것들인데 아래 사진처럼 Pass 뒷면에 보이는 값들입니다.

그리고 아래에 locations에 경산캠퍼스와 대명캠퍼스 도서관 좌표를 딱 넣어놨습니다 그래서 도서관 근처가면 잠금화면에 떠서 바로 눌러서 들어가기 SSAP ABLE

그리고 패스에 바코드는 전자출결에서 띄워주는게 QR이라서 QR타입으로 해줬습니다

이렇게 포맷을 지정해주면 돼요

그리고 뜨는 정보는 이름이랑 학번 그리고 학과 3개만 해놨어요

그래서 이케 뜹니다

다음 시간에는 건우형이 다 해준 서버 만든거 올릴게요 뿅뿅

BoB 11기 1주차가 지나고 후기를 써보겠습니다.

“아 잼있었다”

2주차 후기로 찾아올께요. ㅃ

MiscThings 동앙리 활동을 하면서 다양한 서비스를 만들고 배포하고 있는데요

이번에는 대구대학교 새내기 혹은 예비 신입생을 위한 대구대학교 퀴즈를 제작하였습니다.

기본적으로 자바스크립트를 이용하여 제작하였으며 퀴즈 결과 공유를 위한 카카오톡 API를 이용하여 기능적으로 추가하였습니다.

제작 완료한 퀴즈가 정적인 상태로 구동이 가능함으로 Github Page 기능을 활용하여 배포 하였습니다.

퀴즈는 https://quiz.miscthings.net 에서 만나보실 수 있으며 퀴즈 결과를 카카오톡으로 많은 공유 부탁드립니다.

도움주신 아이슬란드 동아리 회장님 및 MiscThigns 브레인 님께 감사인사 드립니다.

리팩토링 전에 갖고 있는 가상서버들을 정리해 보겠습니다.

최종 목표는 이겁니다. 가상 서버가 사양에 비해 금액이 적지 않다고 판단하였고 더 높은 사양을 원하기에 물리 서버를 두대 둬야한다고 생각 했습니다. 클라우드에 비해 물리서버가 죽을 확률은 높아서 프록시 서버는 클라우드에 한대 뒀습니다. 리버스 프록시에서 로드 밸런싱과 서버 health check 를 담당할 예정입니다.

우선은 북구에 놓을 서버가 없기에 Linode 60달러짜리 서버를 한대 빌렸습니다. 지금은 데탑 서버(평사)와 리노드(일본) 두대가 있습니다.

이제 자동 배포를 구축할 겁니다.
기존에는 리눅스 서비스를 만들어두고 관리하는 방식으로 했는데 코드를 변경할 때 마다 재시작 명령어를 입력해줘야 해서 배포하기가 매우 귀찮았습니다. 이걸 젠킨스를 통해 자동화 할 계획입니다.

게다가 서비스마다 각각 다른 부분이 있어 신경써야 할 부분이 많습니다. 이걸 도커로 만들어두면 서비스를 올릴 때 같은 명령으로 전부 처리할 수 있고 어느 환경에서나 동일하게 동작하기 때문에 배포할 때 뇌를 덜 사용해도 됩니다.
그리고 docker-compose를 사용할 겁니다. docker run 뒤에 오는 수많은 옵션을 관리하는 것도 상당히 귀찮은 일 입니다. docker-compose 는 이런 옵션들을 파일로 만들어뒀다고 생각하시면 됩니다. 옵션을 미리 파일로 저장해 두고 docker-compose up -d 만 입력하면 서비스가 올라갑니다.

빌드 촉발은 깃허브 푸시로 진행할 겁니다. 지금 생각하고 있는 배포 방식은 두가지 입니다.

도커 허브를 잘 활용하기 위해 깃허브에서 푸시가 들어오면 도커 빌드 → 도커 푸시 과정을 거치는것은 똑같습니다. 다만 깃허브 액션으로 빌드와 푸시를 할것인지, 도커 허브를 통해 빌드를 할것인지는 선택해야 합니다.

깃허브 액션으로 하면 다음과 같은 특징이 있습니다

• ＋ 빌드, 배포를 한 곳에서 관리 가능함.
• － CI Minute 을 보고 비용 신경써야 함.
• △ 배포 명령 전달시 젠킨스를 사용해도 됨

도커 허브와 젠킨스를 사용하면 다음과 같은 특징이 있습니다

• ＋ 젠킨스 사용으로 자동화 자유도가 넓어짐
• － 과정이 좀 복잡함. (깃허브 푸시 → 도커 허브 → 젠킨스 순)
• △ 어짜피 도커 허브 프로를 샀는데 활용하자는 마인드

지금은 dockerhub 를 통해 빌드하고 있습니다. 이제 젠킨스 세팅을 알아보겠습니다.

처음 젠킨스를 설치하고 할 일은 다음과 같습니다.

1. 웹훅 플러그인 설치, 배포(over ssh 로 검색) 플러그인 설치
2. 대상 서버에서 ssh-keygen 을 하고 이 키를 깃허브에 등록합니다. (docker-compose 파일을 받기 위함)
3. 배포 플러그인(Publish over SSH) 에서 ssh 서버 추가 (관리 → 시스템 설정 에 있음)
4. 대상 서버에서 레포지토리 받기(또는 docker-compose 파일만 있어도 됨)

빌드 유발은 웹훅 입니다. 젠킨스에서 웹훅 플러그인을 깔고 토큰을 설정해 주면 됩니다.

빌드 환경 설정은 다음과 같습니다. 말이 빌드 환경일 뿐이지 사실은 서버에 접속해서 도커 재시작 해주는 명령이 전부 입니다.

cd /root/srtbot
git pull
docker-compose pull
docker-compose up -d --remove-orphans
yes | docker image prune

위 명령어를 젠킨스가 웹훅이 들어오면 실행해 줍니다.

이로써 자동 빌드 환경이 구성되었습니다. git commit 과 push 를 하게 되면 dockerhub → jenkins → 서버에서 docker-pull 과정을 거쳐서 서비스가 최신 상태로 올라오게 됩니다.

다음은 attend 프로젝트의 도커화와 cockroach 데이터베이스 연결, sqlite3 에서 cockroach 데이터베이스로 데이터 이동을 할 것 같습니다.