yanghyeondong/dev-room

K8S 기반 학교 수업용 컨테이너 관리 서비스

📌 DevRoom: 교육용 개인 개발 컨테이너 관리 시스템

📁 팀 다큐멘테이션 (Notion)

🎯 1. 프로젝트 소개

1.1. Overview

DevRoom은 수업에 필요한 환경과 자료를 효율적으로 관리합니다.

DevRoom에서는 교육자가 웹 서비스에서 한 번의 클릭으로 수십개의 컨테이너 환경을 구축합니다.

DevRoom에서는 수강생이 웹 IDE, SSH 등으로 손쉽게 컨테이너 환경에 접속합니다.

교육자도, 수강생도, 모두가 수업과 교육에 집중할수 있는 환경을 만들어 주는것이 'DevRoom'의 목적입니다.

1.2 프로젝트 구조도

1.3 DB ERD

👥 2. 팀 정보

사진	이름	역할	GitHub	E-Mail
	조재현	DB 설계 Spring 서버 개발
	양현동	K8S 서버 구축 및 관리 백엔드 API 관리
	김태건	프론트엔드 개발 및 관리

dev-room's Issues

✨ k3s 서버 (GCP) 도메인 연결

구현 목표 기능

• K3s 서버 IP를 AWS route53에 등록합니다

가능한 구현 방법 소개

• AWS route53 콘솔에서 단순 라우팅 추가
  

현재 잘 연결 되었습니다.

🐛 k3s 쉘 스크립트 파일 /r 개행 문자 오류 (윈도우 환경에서 개발시 발생)

구현 목표 기능

• Spring이 적용된 람다에서 k3s 서버 쪽으로 configmap을 위한 스크립트 파일을 텍스트로 전달

발생한 문제점 및 버그

• k3s 리눅스 서버에서 사용하기 위한 파일을 윈도우 개발 환경에서 윈도우 확장 CRLF로 바꿔버리는 바람에 문제가 생깁니다.
• 원래는 없어야 할 /r이 생겨나고, 이를 k3s에서 읽게 되면서 문제가 발생합니다.

해결 방안

우선 간단한 해결 방안은 윈도우 환경 ex. InteliJ 등에서 스크립트 파일을 다룰때 CRLF가 아닌 LF로 다뤄야 합니다.
하지만 이는 번거롭고 임시 방편이라, Spring 내에서 자동으로 변환하게 하는 방법을 고려해 보는 것이 좋을 듯 합니다.

✨ 파드마다 Port를 자동 결정 및 할당하는 모듈

구현 목표 기능

• 파드마다 Port를 자동 결정 및 할당하는 모듈

가능한 구현 방법 소개

• (공통) k8s API와 통신하여 현재 점유중인 SVC 포트를 제공받아 가용 Port 목록 작성
• 가용 목록 중 순차선택
• 가용 목록 중 랜덤선택

구현 방법 건의 및 사유

개발 도중에서는 편리성을 위해 순차선택이 좋을 것 같지만, 추후에는 보안등의 이유로 랜덤선택이 좋을듯 합니다.

K8S 호스트 환경 관련 문제점 논의사항

단일 노드에서 사용할 수 있는 파드의 한계치가 존재 110개

• 서비스 환경에 맟춰 노드수를 조절

AKS, EKS등의 퍼블릭 SCP 클러스터 서비스들은 로드밸런서를 구현시 IP 리소스를 너무 많이 사용함. (개별 학생마다 IP 할당)

• 직접 k8s, k3s로 클러스터를 구성하고, IP대신 port로 로드밸런서 구분하기

✨ Exception handling 관련 논의

구현 목표 기능

만일 exception이 발생했을 때 이를 handling 할 수 있는 에러 객체가 정의되어 있지 않은 것 같은데, 이에 대한 논의가 필요할 것 같습니다.

가능한 구현 방법 소개

• Record, Class를 활용한 에러 객체 정의 및 통일화

구현 방법 건의 및 사유

• Security나 controller에서 exception 발생시 이를 handling 할 수 있는 에러 객체 정의

✨ Gabia 도메인 AWS API Gateway 연결

구현 목표 기능

• 가비아에서 구매한 devroom.online 도메인을 api 게이트 웨이에 연결합니다.
• *.devroom.online 에 대하여 ACM TLS 인증서 발급
• API Gateway 커스텀 도메인 연결
• 가비아 DNS 수정 및 CNAME 설정

가능한 구현 방법 소개

• https://velog.io/@kikiki0611/AWS-api-gateway-third-party-custom-domain-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0

현재 연결 확인하였습니다

🐛 JWTAuthenticationFilter에서 successfulAuthentication 동작 관련 문제

구현 목표 기능

• 사용자가 인증을 성공한 후, JWT token을 발급하여 response의 헤더에 넣은 후 클라이언트에 보내는 동작을 구현하고자 했음.

발생한 문제점 및 버그

• 인증은 정상적으로 되는 듯 하나, 계속해서 "/"에 대한 404 Not Found 에러를 발생시킴

문제 코드

해당 코드 부분에 response.addHeader 등의 동작과 securitycontext 세팅 작업을 하고자 했었음.

해결 방안

successfulAuthentication을 implement하는 대신, Security Configuration에서 authenticationSuccessHandler를 구현하는 방식을 선택하였음.

해결 코드

원인은 알 수 없음. 내부적으로 두 코드의 동작이 다르기 때문으로 추정됨. 인터넷 검색해도 두 코드는 취향차이라는 말 밖에는 없음... 알아볼 필요 있음

🐛 SecretKey 파싱 오류 (JWT validity cannot be asserted and should not be trusted)

구현 목표 기능

• application.properties에 정의된 JWT 토큰 키로 HTTP 헤더로 주고받는 jwt token string을 암호화, 복호화 하고자 하는 기능을 구현하고자 했음.

발생한 문제점 및 버그

• 같은 secretKey로 암호화 및 복호화를 진행했음에도 JWT 무결성이 인증되지 않는 문제점이 발생했음.

문제가 된 코드 부분 및 해결 코드

(해당 코드는 해결된 코드임)

원인 및 해결 방안

JWTS 라이브러리에서 사용되는 해싱 알고리즘은 바이트 배열을 기준으로 동작한다. String은 인코딩 방식(e.g. UTF-8, ISO-8859-1)에 따라 각자 다른 바이트 배열로 변환되는데, 만일 클라이언트와 서버에서 String 인코딩이 동일하지 않을 시 변환되는 바이트 배열도 다르게 되어 인증 오류가 발생한다.

(해당 오류도 자바에서 내부적으로 string을 인코딩하는 utf-16형식과 postman 자체적으로 string을 처리하는 인코딩 방식으로 추정되는 utf-8형식과 맞지 않았기 때문에 그렇지 않은가라고 추정됨.)

따라서 인코딩, 디코딩을 할 때는 꼭 인코딩 형식을 맞춰서, 바이트 배열로 변환 후 사용하자

🐛 동일한 PV 클레임에서 복수개의 볼륨을 생성하여 마운트할 시 문제 발생

문제가 발생한 기능

• PV에서 교육자용 public 폴더는 readonly로, 학생용 private 폴더는 readwrite 권한으로 학생 컨테이너 마운트

발생한 문제점 및 버그

• 동일한 Claim에 대해 여러개의 볼륨을 정의하고 마운트 할시, ContinerCreating 단계에서 무한 대기에 진입
  kubectl describe로도 정확한 정보는 알 수 없기 때문에 자세한 이유는 모르지만, 해당 부분이 문제라는 것은 확인

문제 코드

    volumes:
      - name: config
        configMap:
          name: student-{{ $student.id }}-{{ $class.name | lower }}-config
      - name: data1
        persistentVolumeClaim:
          claimName: {{ $.Values.pv_name }}-claim
      - name: data2
        persistentVolumeClaim:
          claimName: {{ $.Values.pv_name }}-claim

해결 방안

PV와 PV-Claim을 2개로 분리했습니다. Helm 배포시에는 반복문을 사용하여 yaml을 작성하도록 하였습니다.
이때, PV도 분리한 이유는 PV와 PV-Claim 이 서로 1:1 대응이기 때문입니다.

🐛 AWS Lambda에서 AWS Integration 관련 오류 해결

구현 목표 기능

• API Gateway에서 Lambda로 HTTP Request를 보내고자 함.

발생한 문제점 및 버그

CloudWatch 로그 확인 결과, AWSProxyRequest 객체가 정상적으로 생성이 되었음에도 Request 정보가 모두 null로써 제대로 lambda에 전달되지 않는 모습을 확인할 수 있었음.

문제 코드

API Gateway와 Lambda의 연결 방식에는 두가지 방식이 있는데,

기본적으로 API Gateway와 Lambda의 연결은 비프록시 방식으로서, API Gateway에 보내는 request와 response의 매핑을 전부 API Gateway가 관리함.

이때 API Gateway에 매핑 관련 동작을 하나도 적용해 두지 않고 request를 보냈기에 매핑된 정보가 없어 null이 발생하였음.

해결 방안

그러나 현재 우리의 프로젝트는 이미 spring boot 프로젝트에서 모든 request와 response를 파싱하여 전달하고 있기 때문에, API Gateway에서 파싱할 이유가 없음.

따라서 Lambda에서 모든 파싱을 진행할 수 있도록, API Gateway - Lambda 연결 방식을 프록시 연결로 설정하여 request를 있는 그대로 API Gateway에서 Lambda로 넘겨 줄 수 있도록 설정하였음.

해결 코드

API Gateway - 통합 요청 설정 - Lambda 프록시 통합 True 설정