전체 글

3. Type | Built with Notion개요dongbin-note.notion.site

2. 클래스 | Built with Notion개요dongbin-note.notion.site

1. 기본 문법 | Built with Notion목차dongbin-note.notion.site

개요 코틀린 공식 홈페이지를 보면 코틀린에 대한 세부 설명 중 멀티 플랫폼 항목이 가장 상단에 위치하는 것을 볼 수 있다. 그만큼 jetbrains 사에서도 코틀린이 가지는 가치 중 멀티 플랫폼을 중요하게 생각함을 알 수 있다. 이번 글에서는 코틀린이 가지는 특징 중 멀티 플랫폼에 대한 내용을 다룬다. 코틀린 멀티 플랫폼? “The Kotlin Multiplatform technology is designed to simplify the development of cross-platform projects.” ”It reduces time spent writing and maintaining the same code for different platforms while retaining the flexi..

개요Exposed ORM은 Kotlin으로 작성된 ORM(Object-Relational Mapping) 라이브러리로, SQL Query를 작성하는 대신 Kotlin 코드로 데이터베이스를 조작할 수 있게 해줍니다. 이 글에서는 Exposed ORM을 사용하여 One-to-Many 관계의 엔티티를 생성하고 CRUD를 구현하는 방법, 그리고 Join read를 구현하는 방법에 대해 알아보겠습니다. One-to-Many 관계의 엔티티 생성 방법One-to-Many 관계란, 한 엔티티가 다른 엔티티를 여러 개 가지는 관계입니다. 예를 들어, 한 사용자(User)가 여러 개의 주소(Address)를 가지는 경우, 사용자(User)와 주소(Address)는 One-to-Many 관계를 가집니다. 다음 예시를 통해..

개요도커 이미지 크기를 줄일 수 있는 방법에 대해 찾아본다.skaffold dev 명령어로 이미지 초기 생성시 필요한 패키지를 설치하는 과정이 빌드 과정의 많은 시간을 차지하는 문제가 있어 이를 줄일 수 있는 방법에 대해 찾아본다.기술 스택Docker Multi stage buildDocker Buildkit in SkaffoldPython Wheel 구현 방법Multi stage build 및 buildKit 사용도커 이미지를 빌드 할 때 소스 코드만 변경해도 필요한 패키지들을 모두 설치하는 과정이 포함되어 빌드 시간이 길게는 15초까지 소모됐다. 이를 해결하기 위해 Docker에서 지원하는 Multi stage build 및 buildKit을 사용한다. Multi stage build란 하나의 Do..

개요Skaffold의 JIB를 사용해 Java spring 프로젝트를 빌드하고 배포JIB Sync 기능을 활용해 변경된 파일만 sync하여 재빌드 및 배포, pod 재시작 단계 생략 필요 조건Skaffold는 build 옵션으로 JIB를 지원하고 있다. 이때 File Sync 기능을 활용하면 변경된 파일을 copy 해주기 때문에 파일이 변경 되더라도 재빌드 및 배포, pod 재시작 단계 없이 구동되고 있는 pod에 변경사항을 적용시킬 수 있다.JIB Sync 기능을 auto로 사용하기 위해서는 몇가지 필요 요건이 존재한다. Sync 기능은 구동하는 컨테이너 내부에 tar가 존재해야 함. 즉, JIB가 build하는 base image에 tar가 포함되어야 함. spring dependency로 sprin..

개요 아래 그림은 istio 공식 페이지에서 제공하고 있는 bookinfo 데모 프로젝트 중 reviews.default.svc.cluster.local로 요청을 보낼 때 내부 사이드카 프록시가 트래픽을 인터셉트하고 라우팅하는 흐름, ratings로 향하는 아웃바운드 트래픽의 흐름을 보여준다. 이 글에서는 envoy 프록시가 사이드카로 포함되어 있는 pod에 대해 인바운드 트래픽과 아웃바운드 트래픽이 어떻게 인터셉트 되고 처리 되는지 알아본다. Iptable 분석 # minikube login for root $ minikube ssh docker@minikube:~$ sudo -i # productpage pod의 프로세스 확인 root@minikube:~# docker top `docker ps|gr..

개요 Service mesh가 클러스터 내부 서비스간 트래픽 관리 (”east-west” traffic)를 담당한다면 API Gateway는 client와 backend간 트래픽 관리 (”north-south” traffic)를 담당한다. istio는 0.8 버전 이전 버전에서 쿠버네티스의 ingress를 트래픽 포털로 사용했으나, 0.8 버전부터 gateway 리소스를 베타로 지원한다. (둘 다 ingress controller로 envoy 프록시 사용) gateway 리소스가 추가되면서 mesh 서비스에서 어떤 api gateway를 사용해야 할 지, api gateway (e.g., zuul, kong)를 istio ingress gateway가 대체할 수 있을지에 대한 궁금증이 생기기 시작했다. ..

Istio의 트래픽 라우팅 규칙을 사용하면 서비스 간 트래픽 흐름과 API 호출을 쉽게 제어할 수 있다. Traffic Management를 통해 제공하는 기능은 다음과 같다. Circuit breaker Timeout & Retry A/B 테스트 Canary 테스트 백분율 기반 트래픽 분할 Istio의 트래픽 관리는 사용자가 서비스를 배포 하면서 함께 배포되는 Envoy 프록시에 의해 가능해진다. 모든 트래픽은 envoy 프록시를 거쳐 들어오고 나가게 되어 별도로 서비스의 변경 없이 트래픽 관리를 쉽게 할 수 있다. 더 많은 내용은 다음 페이지에서 참고 가능 architecture overview 개요 Istio는 트래픽 관리를 위해 각 서비스가 어떤 endpoint를 가지고 있는지 알아야 한다. 이 ..