MSFL :: 모리스 소프트웨어 공작소

How to use KUDO CLI Commands KUDO 및 Package 관리를 위한 KUDO CLI를 정리한다. Global Flags Global Flags : 전체 명령들에 사용할 수 있는 전역 옵션들 --home <path> : Kudo 설정이 있는 Home Directory 지정 (Default: "~/.kudo") --kubeconfig <path> : Kubernetes 설정이 있는 Home Directory 지정 (Default: "~/.kube/config") -n, --namespace <namespace> : 객체를 처리할 대상 Namespace (Default: "Default") --request-timeout <seconds> : 요청 시간 제한을 초단위로 지정 (Default: 0 - 무제한) -v <line count>, --v : 상세 로그 수준을 라인단위로 지정 --validate-install : 명령을 실행하기 전에 KUDO 설치 여부 검증 (Default: true) Semi-Global Flags : 전체 명령들은 아니지만 많은 명령들에 사용할 수 있는 옵션들 --help : 모든 명령에 지정 가능하며, 해당 명령의 상세 정보 출력 -o, --output : 많은 명령들이 지원하며, "Yaml" 또는 "Json" 방식으로 출력 가능 --dry-run : 실제 실행하지는 않고, 점검과 준비만 처리하며, --output 옵션으로 대상 리소스에 대한 출력물 생성 init KUDO Server와 Client 컴포넌트의 초기화 및 업그레이드 처리 kubectl kudo init [options] 옵션들은 설치 및 업그레이드에 대한 변경을 위한 것으로 주로 Server를 대상으로 하며 저장되지 않기 때문에 매번 제공해야

Multi-Container Design Patterns 정리 지난 몇 년동안 컨테이너 기술은 코드를 패키징하고 배포하는 대중적인 기술로 발전했다. 여기서도 컨테이너를 통해 분산 응용 프로그램을 구축 하는 방법의 변화에 대해 주목할 필요가 있다. 이번에는 마아크로 서비스 아키텍처에서 컨테이너늘 다루는데 사용할 수 있는 디자인 패턴 3가지에 대해서 정리해 본다. Sidecar Pattern 하나의 컨테이너는 하나의 책임만 가지고 있어야 한다. 예를 들면 웹 서버와 로그 수집기가 같이 존재하는 컨테이너가 있다고 가정했을 때 다음과 같은 고민을 하게 된다. 웹 서버를 수정할 때 로그 수집기의 종속성을 고려해야 한다. 직접적인 관련은 없더라도 오류가 발생했을 때 어디서 문제가 발생했는지 빠르게 파악하지 못할 수도 있다. 위의 같이 상관이 없음에도 고려할 부분이 생길 수 있기 때문에 서로 다른 역할을 하는 서비스는 각각의 컨테이너로 분리해 주는 것이 좋으며, 이런 상황에서 활용할 수 있는 패턴이 Sidecar Pattern 이다. Pod 내의 메인 컨테이너 (위의 그림에서는 Web Server Container)를 확장하고 향상 및 개선하는 역할을 컨테이너를 Sidecar Container 라고 하고, 이렇게 적용하는 패턴을 Sidecar Pattern 이라고 한다. 서로 다른 컨테이너이며 단지 Pod내에 묶여 있는 것이기 때문에 서로 간에 종속성이나 간섭의 문제가 생기지 않는다. 당연히 Web Server를 교체하더라도 로그 수집기 컨테이너는 변경이 없고 특정 기능을 활용하도록 재 사용성이 증가하는 효과를 가져오게 된다. Ambassador Pattern 메인 컨테이너의 네트워크 연결을 전담하는 프록시 컨테이너를 두는 패턴이다. Sidecar Pattern 이 이미 완성되고 동작하는 애플리케이션에 기능 추가를 위한 변경이 없이 보조 기능으로 추가해서 활용하는 측면을 강조한 것이라면 Ambassador Pattern은 개별 기능만을 중점

How to use MongoDB with Golang 이 문서에서는 아주 간단하게 Docker-compose를 이용해서 MongoDB를 구동하고 Golang을 통해서 연결하는 부분에 대해서 정리하고 있습니다. 환경은 맥북, VSCode, Golang, Docker 등이 이미 설치되어 있는 것을 기준으로 합니다. 간단한 MongoDB 정리 RDBMS와의 비교 RDBMS MongoDB Database Database Table Collection Tuple/Row Document Column Key/Field Table Join Embedded Documents Primary Key Primary Key (_id) 특징과 장/단점 주요 특징 들은 다음과 같다. Document-Oriented Storage : Database > Collections > Documents 구조로 Document는 key-value 형태의 BSON (Binary JSON) 으로 되어 있다. Full Index Support : 다양한 인덱싱을 제공한다. Single Field Indexes : 기본적인 인덱스 타입 Compound Indexes : RDBMS의 복합 인덱스 타입 Multikey Indexes : Array에 매칭되는 값이 하나라도 있으면 인덱스에 추가하는 인덱스 타입 Geospatial Indexes and Queries : 위치기반 인덱스와 쿼리 지원 Text Indexes : String에 대한 인덱스 지원 Hashed Indexes : Btree 인덱스가 아닌 Hash 타입의 인덱스도 지원 Replication & High Availablity : 간단한 설정을 통해서 데이터 복제를 지원하므로 가용성이 향상된다. Auto-Sharding : 자동으로 데이터를 분산해서 저장하며, 하나의 컬랙션처럼 사용할 수 있도록 수평

Yarn vs NPM 비교 node + npm이 기본이었는데, 몇 가지 npm의 문제점을 해결하기 위해 yarn 이 발표되었다. 기존 NPM은 배포가 쉽고, 종속성을 쉽게 해결할 수 있지만 패키지가 중복으로 설치 될 수 있고, 파일이 많은 경우에 문제가 될 수 있다. 페이스북에서는 이런 문제점들을 해결하기 위해서 yarn을 발표했다. npm3 보다 패키지 설치 속도가 빠르다. json 포맷을 사용하지 않는다. offline 모드가 가능하다. YARN 설치 설치페이지 를 통해서 직접 설치가 가능하다. 맥북이라면 brew를 이용해서 설치가 가능하다. npm을 통해서도 설치가 가능하다. 터미널에서의 설치는 다음의 명령으로 처리하면 된다. $ npm install -g yarn # npm 사용 $ brew install yarn # 맥북 명령 비교 npm 명령 yarn 명령 설명 npm init yarn init 프로젝트 초기화 npm install yarn or yarn install package.json 의 패키지 설치 npm install --save [package name] yarn add [package name ] 패키지를 프로젝트 의존성 수준으로 추가 (dependencies) npm install --save-dev [package name] yarn add -D[or --dev] [package name] 패키지를 프로젝트 개발 의존성 수준으로 추가 (Devdependencies) npm install --global [package name] yarn global add [package name] 패키지를 전역 수준으로 추가 npm update --save yarn upgrade 프로젝트의 패키지 업데이트 npm run [script name] yarn [script name] package.json의 scripts에 지정된 명령

Opencensus를 이용한 gRPC Global Tracing Overview Opencensus를 사용해서 시스템의 추적 및 매트릭을 수집하고 선택한 백엔드로 내보내 분산 시스템에 대한 관찰성을 제공할 수 있다. 간단하게 gRPC 상에서 추적을 검증하기 위한 용도이므로 단순히 바이트를 포함하는 페이로드를 받아서 대문자 처리를 하는 서비스를 대상으로 검토해 보도록 한다. Requirements go : Download and install - The Go Programming Language 를 통해 설치 gRPC $ go get -u google.golang.org/grpc Protocol Buffer v3 : Quick start – gRPC 문서의 내용에 따라서 Releases · protocolbuffers/protobuf · GitHub 에서 바이너리를 받을 수 있다. # linux apt or apt-get $ apt install -y protobuf-compiler $ protoc --verion # 버전 3+ 확인 # Mac Homebrew $ brew install protobuf $ protoc --version # 버전 3+ 확인 Go 용 protoc 플러그인 $ go get -u github.com/golang/protobuf/protoc-gen-go Creating our gRPC Service 추적을 활성화하기 위해서는 다음과 같은 패키지가 필요하다. Opencensus gRPC 지원 : go.opencensus.io/plugin/ocgrpc Opencensus Trace 지원 : go.opencensus.io/trace 매트릭을 활성화하기 위해서는 다음과 같은 패키지가 필요하다. 서버 핸들러 : go.opencensus.io/plugin/ocgrpc.SserverHandler 클라이언트 핸들러 : go.opencensus.io/plugin/ocgrpc.ClientHandler 서

Trace 정리 Tracing (이하 트레이싱) 추적은 응용 프로그램을 구성하는 다른 서비스에 의해 처리되는 단일 사용자 요청의 진행과정을 추적하는 것이다. 진행 과정의 각 작업은 Span 으로 부르며, 각 스팬에는 단계에 소요된 시간 (대기 시간), 상태, 시간 이벤트, 속성, 링크를 포함하여 작업을 나타낼 수 있는 메타 데이터가 포함된다. 이 추적 정보를 활용해서 애플리케이션의 오류 및 대기 시간 문제를 디버깅 할 수 있다. Trace (이하 추적) 추적은 스팬 트리로 구성된다. 즉, 작업의 흐름 경로를 보여주는 관찰 가능한 신호의 집합이다. 추적 자체는 고유한 16바이트 시퀀스로 표현되는 TraceID 로 식별된다. 트레이싱을 통해서 수집된 추적 정보는 다음과 같이 표현된다. 위의 그림에서와 같이 여러 단계의 작업(스팬)이 호출된 것을 확인할 수 있다. auth: 사용자 인증 여부 검사 cache.Get: 캐시 검증 mysql.Query: 캐시에 존재하지 않아 DB 조회 cache.Put: DB 조회결과 캐시 처리 Exporting (이하 내보내기) 수집된 추적 정보를 다양한 분석을 위해서 여러 가지 백엔드들에 대한 내보내기를 구성해서 처리할 수 있다. 다양한 내보내기 목록등은 Opencensus 를 참고하면 된다. Span (이하 스팬) 스팬은 추적의 단일 작업을 나타낸다. 주로 HTTP 요청, RPC (원격 프로시저 호출: Remote Procedure Call), 데이터베이스 쿼리 또는 코드가 사용자 코드에서 사용하는 경로 등을 나타낸다. 스팬은 트리 구조를 이루기 때문에 상위 스팬의 존재여부에 따라서 상위 스팬과 하위 스팬으로 나뉜다. 각 스팬은 SpanID 로 식별된다. SpanID 와 옵션 바이트들을 합쳐서 Span Context 라고 한다. 동일 프로세스 내에서 스팬 컨텍스트는 컨텍스트 객체로 전달된다. 프로세스 경계를 넘어서면 프로토콜 헤더로 직렬화 된다. 따라서 수신 측은 스팬 컨텍스트를 읽고 하

Access to remote server using ssh key with iterm2 환경 Mac OS ssh-keygen (SSH에 사용할 키 발급) ssh-copy-id (발급된 공개키를 서버에 전송) 원격 서버 (Ubuntu 16.04) 및 사용자 서버에 사용자가 추가되어 있다고 가정한다. 사용자 추가에 대한 부분은 많은 자료들이 존재하므로 참고하도록 한다. ssh-copy-id 설치 ssh-copy-id 는 로컬에서 발급된 공개키를 서버로 전송할 때 사용하는 패키지다. $ brew install ssh-copy-id SSH Key 발급 ~/.ssh 폴더를 기준으로 한다. # ssh-keygen [-t] [rsa] [-b] [2048] # -t : dsa, ecdsa, ed25519, rsa, rsa1 중에 어떤 암호화 알고리즘을 선택할지 지정 (기본 값, rsa) # -b : key를 생성할 때 bit 수 지정 (기본 값, 2048) $ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/Users/<현재 사용자>/.ssh/id_rsa): <<< 여기에 저장될 파일 경로 또는 파일명 입력 Enter passphrase (empty for no passphrase): <<< 비밀번호로 사용할 값 Enter same passphrase again: <<< 다시 입력 Your identification has been saved in <파일명> Your public key has been saved in <파일명>.pub. 키 파일에 대한 권한 문제 ssh-key을 통해서 처리한 경우는 문제가 되지 않을 수 있지만 수동으로 처리한 경우는 다음과 같이 파일 권한을 설정해 줘야 한다. 공개 키 : 0644 (-rw-r--r--) 개인 키

How to install and access Kubernetes Dashboard 대시보드는 웹 기반 Kubernetes 사용자 인터페이스로 컨테이너화된 애플리케이션을 배포하고 문제를 해결하고, 클러스터 리소스들을 관리한다. 또한 클러스터의 쿠버네티스 리소스 상태 및 발생했을 수 있는 오류에 대한 정보도 확인할 수 있다. Deployments StatefulSets DaemonSets Jobs Services Ingress Deployments Scaling Rolling Update Pod Management Persistent Volume / Claim 배포 및 액세스 기본적으로 쿠버네티스에 포함되어있지 않기 때문에 별도 배포해 줘야 한다. kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml namespace/kubernetes-dashboard created serviceaccount/kubernetes-dashboard created service/kubernetes-dashboard created secret/kubernetes-dashboard-certs created secret/kubernetes-dashboard-csrf created secret/kubernetes-dashboard-key-holder created configmap/kubernetes-dashboard-settings created role.rbac.authorization.k8s.io/kubernetes-dashboard created clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created clusterrolebinding

Set up Item2 terminal with oh-my-zsh on Mac 별다른 수정이 없었다면 기본 터미널 쉘은 `bash(Bourne Again Shell) 일 것이다. $ echo $0 -bash 아마 맥북 최신 OS 상태라면 zsh 로 나올 것이다. (macOS 10.15 Catalina 부터 GPL v3 라이센스 제한) 필수 준비 항목들 Homebrew 설치 : Mac OS 용 패키지 관리자 $ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" 또는 $ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" 설치 후에는 다음과 같이 패키지 명을 지정해서 다른 패키지들을 설치할 수 있다. $ brew install [package-name] zsh : bash를 확장한 쉘로 Mac은 bash 기반으로 zsh도 같이 설치되어 있다. $ brew install zsh $ which zsh /usr/local/bin/zsh $ chsh -s $(which zsh) Item2 : Mac OS의 Terminal emulator, 다운로드해서 설치 Oh-my-zsh 설치 및 설정 터미널을 쉽게 사용할 수 있도록 ZSH 를 확장하는 오프소스 프로그램으로 커뮤니티가 활발하게 형성되어 있다. # curl을 이용한 설치 $ sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" # wget을 이용한 설치 $ brew install wget $ sh -c "$(wget -O- https://raw.gith

[Golang] How to add static files (for Web serving) to the golang binary without dependencies 참고 go.rice go-bindata packr esc 과연 이런 작업이 필요한 것일까? 특히 고객에게 전달되어야 하는 최종 산출물일 경우라면 이런 접근 방법에 대한 명확한 이유를 설명할 수 있어야 한다. 장점 "안정성" : 바이너리에 추가된 파일은 다시 추출하기 어렵기 때문에 안정성이 있다. "편리" : 배포 또는 소스를 전달할 떄 웹 서비스를 위한 추가적인 폴더들을 제공할 필요가 없다. 단점 "크기" : 추가된 만큼 바이너리 자체의 크기가 증가한다. "성능" : 그다지 큰 이슈가 될 것 같지는 않지만, Admin Web과 같이 정적 파일을 운영할 경우는 별도로 웹을 구성해서 서비스하는 것보다는 바이너리내의 파일을 서비스하는 개념이기 때문에 아주 약간의 성능 상 이슈가 있을 수 있다. 틱 단위의 서비스가 중요한 서비스가 아니라 내부 관리자 용이라면 이런 걱정은 하지 않아도 될만한 차이다. 가능한 원리는 무엇일까? 프로그램으로 프로그램 코드를 작성하는 "제너레이터"를 이용 하는 것이다. (이전에는 "golang.org/x/tools/cmd/goyacc"를 이용했었다) golang 1.4 부터는 이런 작업을 편하게 처리할 수 있도록 "go generate" 명령이 추가 되었다. 이를 통하면 소스 상에 특수한 주석으로 명기된 명령을 검색해서 처리해주는 방식으로 운영할 수 있다. 구현해 보자. 이제 아주 간단한 실제 동작하는 샘플을 통해서 검증을 해 보자. 모듈 구성 go module을 사용하는 프로젝트 구성 # go mod init <project module path> $ go mod init g