복세편살 개발라이프

Prometheus KubeControllerManagerDown & kubeSchedulerDown (EKS,GKE)

LeafCat — Fri, 29 Apr 2022 12:35:35 +0900

EKS나 GKE와 같은 managed kubernetes 서비스에서 Promethues를 통해 모니터링을 할 때 KubeControllerManagerDown와 kubeSchedulerDown이 Firing되어 있는 것을 볼 수 있을 것이다.

이는 EKS나 GKE의 경우 control plane을 서비스로 제공하는 클라우드로서(control plane as a service) 클러스터를 받아 kubernetes를 사용하는 것이기 때문에 kube controller manager나 kube scheduler와 같은 control plane 구성 요소들이 제공받은 worker node들에서 숨겨져 있다. 따라서 해당 구성 요소들에 대한 metric 수집을 꺼두는 것이 좋다.

아래는 EKS를 사용할 때, kube-prometheus-stack의 values.yaml 설정의 예시이다.

defaultRules:
  create: true
  rules:
    alertmanager: true
    etcd: false
    configReloaders: true
    general: true
    k8s: true
    kubeApiserver: true
    kubeApiserverAvailability: true
    kubeApiserverSlos: true
    kubelet: true
    kubeProxy: true
    kubePrometheusGeneral: true
    kubePrometheusNodeRecording: true
    kubernetesApps: true
    kubernetesResources: true
    kubernetesStorage: true
    kubernetesSystem: true
    kubeScheduler: false
    kubeStateMetrics: true
    network: true
    node: true
    nodeExporterAlerting: true
    nodeExporterRecording: true
    prometheus: true
    prometheusOperator: true

kubeControllerManager:
  enabled: false

kubeEtcd:
  enabled: false

kubeScheduler:
  enabled: false

EKS에서 Prometheus가 kube-proxy metric을 수집 못하는 문제

LeafCat — Fri, 29 Apr 2022 12:23:28 +0900

EKS 최신버전 클러스터는 kube-proxy metric bind address가 변경되어서 정상 기동중임에도 Prometheus상에 Target Down으로 표시된다. (connect: connection refused)

이를 해결하기 위해 cm에 있는 metricsBindAddress값을 변경해줘야한다.

kubectl edit cm kube-proxy-config -n kube-system
metricsBindAddress: 127.0.0.1:10249 > metricsBindAddress: 0.0.0.0:10249

kube-proxy를 한번씩 재시작 해주면 metric이 정상적으로 수집되는 것을 확인할 수 있을 것이다.

kubernetes pv RECLAIMPOLICY 변경하기

LeafCat — Thu, 28 Apr 2022 20:17:26 +0900

pv를 이미 생성한 뒤에 reclaimpolicy를 변경해야 할 필요가 있을 경우가 생각보다 자주 발생한다. 특히 Delete -> Retain으로 변경해야 할 필요가 있을 때가 많은데, kubernetes에서는 kubectl patch 명령어를 통해 이미 만들어져 사용되고 있는 pv의 reclaimpolicy를 변경할 수 있게끔 기능을 제공한다.

kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

AWS EKS 클러스터에 접근하기

LeafCat — Tue, 19 Apr 2022 15:55:16 +0900

1. AWS api key 생성

https://us-east-1.console.aws.amazon.com/iam/home#/security_credentials

us-east-1.console.aws.amazon.com

엑세스 키 만들기를 통해 key를 생성하고 .csv 파일을 잘 보관해두자.

2. AWS cli에 api key를 등록

aws configure

3. aws eks 명령어를 통해 kubeconfig에 eks 클러스터 정보를 등록하고 해당 클러스터를 사용하도록 설정할 수 있다. (kubeconfig 파일을 직접 수정해도 됨..)

등록된 api key의 계정이 해당 클러스터에 권한이 있어야 한다.

aws eks update-kubeconfig --region [region-code] --name [my-cluster]

4. 확인하기

kubectl cluster-info

kubectl 다중 클러스터 사용(kubectl cluster switch)

LeafCat — Tue, 19 Apr 2022 15:47:45 +0900

※참고 : https://kubernetes.io/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/

다중 클러스터 접근 구성

이 페이지에서는 구성 파일을 사용하여 다수의 클러스터에 접근할 수 있도록 설정하는 방식을 보여준다. 클러스터, 사용자, 컨텍스트가 하나 이상의 구성 파일에 정의된 다음 kubectl config use-conte

kubernetes.io

하나의 jumphost에서 여러 kubernetes 클러스터를 관리하는 경우, 클러스터를 바꿔가면서 kubectl 명령어를 사용해야 할 필요가 있다.

혹은 namespace에 따라 사용자를 바꿔가며 접근해야 할 경우가 있을 수 있다. 이럴 경우 kubectl config를 통해 접근하려는 클러스터와 사용자를 관리할 수 있다.

1. kubeconfig 파일 작성 혹은 수정.

(기본적으로 kubeconfig 파일은 ~/.kube/config 이며, 추가적인 config 파일을 자유롭게 작성할 수 있다.)

Sample

apiVersion: v1
clusters:
- cluster:
    certificate-authority: fake-ca-file
    server: https://1.2.3.4
  name: development
- cluster:
    insecure-skip-tls-verify: true
    server: https://5.6.7.8
  name: scratch
contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
- context:
    cluster: development
    namespace: storage
    user: developer
  name: dev-storage
- context:
    cluster: scratch
    namespace: default
    user: experimenter
  name: exp-scratch
current-context: ""
kind: Config
preferences: {}
users:
- name: developer
  user:
    client-certificate: fake-cert-file
    client-key: fake-key-file
- name: experimenter
  user:
    password: some-password
    username: exp

2. 사용하려는 컨텍스트로 변경하기

kubectl config (--kubeconfig=[kubeconfig]) use-context [context name]

에러 failed to start container "prometheus-node-exporter": Error response from daemon: path / is mounted on / but it is not a shared or slave mount

LeafCat — Thu, 14 Apr 2022 14:40:30 +0900

임시 해결법 :

nodeExporter:
 ## If true, node-exporter pods mounts host / at /host/root
  ##
  hostRootfs: false

nodeExporter.hostRootfs 를 false로 설정한다.

prometheus 설치 (Helm chart 사용)

LeafCat — Thu, 14 Apr 2022 14:37:23 +0900

prometheus를 설치하기 위한 방법은 다양하다. binary로 설치하거나, 단일 docker container로 구동하거나, yaml파일을 작성하여 kubernetes 클러스터에서 실행하거나... 이 글에서는 helm chart를 사용하여 kubernetes 클러스터에 prometheus를 구동하는 방법을 공유하겠다.

❉ Helm 3 설치가 선행되어야 한다. ( https://www.leafcats.com/338 )

1. Git repo info

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

2. value.yaml 수정을 수월하게 하기 위해 git repo를 clone받자.

git clone https://github.com/prometheus-community/helm-charts.git

3. 환경에 맞게 value.yaml을 수정하자.

config를 위한 prometheus.yml 수정도 value.yaml을 통해 할 수 있다.

본 예제를 위해서는 prometheus server와 alertmanager를 node port로 노출하기 위해 다음과 같이 수정했다.

alertmanager:
    loadBalancerIP: ""
    loadBalancerSourceRanges: []
    servicePort: 80
    nodePort: 30005
    sessionAffinity: None
    type: NodePort
    
    
server:
    loadBalancerIP: ""
    loadBalancerSourceRanges: []
    servicePort: 80
    sessionAffinity: None
    type: NodePort
    nodePort: 30006

4. helm install

helm install [RELEASE_NAME] prometheus-community/prometheus -f values.yaml

6. 확인

kubectl get po

prometheus 관련 pod들이 잘 실행되었는지 확인한다.

혹, node-exporter 실행에서 error가 발생한다면 다음 글 참고 (https://www.leafcats.com/340 )

7. 접속

web에 접속하여 정상적으로 조회 되는지 확인해보자

http://localhost:30006/graph

Helm 설치하기

LeafCat — Wed, 13 Apr 2022 17:47:46 +0900

Helm은 Kubernetes에서 패키지 관리를 도와주는 오픈소스 tool이다. Helm을 사용하면 kubernetes상의 다양한 application들을 보다 쉽게 설치할 수 있으며, 자신의 프로젝트 application에 대한 배포 절차를 helm을 통해 간소화하고 재사용을 용이하게 한다.

1. helm 3 설치

바이너리를 다운로드 받아서 설치할 수 있지만, 스크립트를 통해 설치하는 것이 더 보편적이다.

스크립트를 다운로드 받을 디랙토리에서 아래 명령어를 통해 스크립트를 받고 실행시키자.

curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 > get_helm.sh
sudo chmod 700 get_helm.sh

./get_helm.sh

2. 다운로드 확인

helm version

위 명령어를 통해 helm 3가 잘 설치된 것을 확인할 수 있다.

3. Helm chart repo 추가

Helm chart repo를 추가하고 ~~git에서 stable chart들을 받아보자~~

helm repo add stable https://charts.helm.sh/stable
git clone https://github.com/helm/charts
helm repo update

❉ https://github.com/helm/charts Repository 자체를 kubernetes 및 helm측에서 더이상 support 하지 않는다. k8s 버전이 점점 올라감에 따라 api version 등의 문제로 최신 버전의 k8s를 사용한다면 작동하지 않는 차트들이 많을 것이다.

https://artifacthub.io/ 에서 직접 검색하여 repo를 추가하는 것을 권장한다.

4. Helm search

helm search repo stable

m1 mac에서 node.js canvas 설치 문제

LeafCat — Mon, 14 Mar 2022 13:43:36 +0900

애플의 M1칩을 사용하는 최신 맥 PC에서는 걱정했던 것보다 더 많은 호환성 문제가 발생한다.

Node.js에서 Canvas 라이브러리를 사용해야 했지만, 역시나 순조롭게 진행되지 않았다.

다행히도 최신 버전(2.9.0 이상)의 canvas에서는 m1칩을 지원해주지만, 별도의 설치를 해 주어야 정상적으로 사용이 가능했다.

brew install libtiff gdk-pixbuf librsvg

위 명령어를 통해 별도의 디팬던시를 수동으로 설치해 주어야 m1 mac에서도 canvas 설치가 정상적으로 진행된다.

mac solidity 설치 (solc)

LeafCat — Wed, 23 Feb 2022 00:40:45 +0900

brew를 통해 설치하자.

brew update
brew upgrade
brew tap ethereum/ethereum
brew install solidity

아래 명령어를 통해 잘 설치 되었는지 확인할 수 있다.

 solc --version

windows 실행중인 포트 확인, 종료

LeafCat — Fri, 31 Dec 2021 16:17:25 +0900

1. 아래 명령어로 점유중인 포트와 PID를 확인

netstat -a -o

2. PID로 프로세스 kill (Linux의 kill -9 와 유사한 명령어)

taskkill /f /pid 1234

wsl2 kubernetes volume hostpath 못잡는 문제 해결방법

LeafCat — Fri, 18 Jun 2021 11:21:11 +0900

로컬환경 Windows10에서 wsl2 + docker desktop 사용하여 k8s 구성하는 경우, kubernetes에서 hostpath로 volume (pv 포함)을 못잡는 문제가 있다.

일반 docker에서는 문제가 없는데 k8s에서는 잘 동작하지 않는다.

한참 구글링해서 찾아낸 방법으로는,

/run/desktop/mnt/host/wsl/{temp-dir} 경로로 hostpath volume 경로를 지정하는 것이다.

위 경로에서 실제로 리눅스 환경에 존재하는 위치는 /mnt/wsl/{temp-dir} 이다.

따라서..

1. mkdir /mnt/wsl/{temp-dir}

2. sudo mount --bind /{real-path} /mnt/wsl/{temp-dir}

3. /run/desktop/mnt/host/wsl/{temp-dir} 를 kubernetes volume hostpath로 마운트

[발뮤다 더 스피커] 발뮤다 블루투스 스피커 후기

LeafCat — Fri, 14 May 2021 14:53:45 +0900

기존에 사용하던 "보스 사운드링크 미니" 라는 블루투스 스피커가 있었습니다. 거의 사용하지 않고 먼지만 쌓여가다 3달 전 쯤 지인에게 중고로 팔았죠. 그러다 어느날 문득 '블루투스 스피커가 있으면 좋겠다' 라는 생각이 들었습니다. 몇 달을 전원 한번 켜지 않아서 팔아버렸는데 없으니까 또 그 쓰임이 생각이 나더라고요. 음향을 전문으로 취급하는 기업들의 좋은 스피커들이 많이 있었지만, 무언가 '듣는것' 말고 또다른 가치를 가져다 줄 수 있는 스피커 하나가 눈에 밟혀 구입하게 되었습니다.

바로 발뮤다의 더 스피커 입니다.

개봉

택배상자 뚜껑을 열자마자 BALMUDA 로고가 보이는 것이 개봉을 시작하자 마자 무언가 기분 좋은 감성을 가져다 줍니다.

발뮤다 답게 가타부타 다른 설명이나 그림 없이 심플하지만 그 자체로 이 회사가 추구하고자 하는 감성을 잘 보여주는 포장으로 박싱 되어 있습니다.

스피커는 천 재질의 파우치에 담겨 있으며 USB-C 타입의 충전기가 포함되어 있습니다.

혹시나 마이크로5핀이면 어쩌지 하는 우려를 했으나 C타입의 충전 타입이라 안심했습니다.

사용

전원을 켜니 고급스러운 On 사운드와 함께 불이 들어옵니다.

태블릿에 블루투스 페어링을 시키고 음악을 재생해보니 멜로디와 악기에 따라 불빛이 춤을 추는듯한 인상을 줍니다.

(단순히 LED불빛이라 생각했는데 촛불과도 같은 느낌을 강하게 주는 LED 캔들입니다.)

사진이나 영상으로 보이는 모습보다 실제 모습이 몇배는 더 아련하고 아름답습니다.

감상

유선 연결이 아닌 블루투스 스피커이고, 음향보다는 다른 감성에 더 집중한 스피커인지라 고가의 가격을 뛰어넘는 음향을 들려주지는 않습니다. 사실 음향만 놓고 보면 절반정도 가격인 지난번에 사용하던 보스 사운드링크 미니2가 더 뛰어난 것 같습니다.

그렇다고는 해도 고가의 스피커이기 때문에 기본 이상의 좋은 소리를 들려주기는 합니다. 그리고 시각적으로 보여주는 감성적인 자극이 워낙에 훌륭하기에 충분히 만족스러웠습니다. 실제로도 일반 블루투스 스피커는 거의 사용하지 않았던 저도 집에 오자마자 가장 먼저 하는 일이 발뮤다 더 스피커의 전원을 켜는 일입니다.

잔잔한 음악과 그 음악소리에 맞춰 춤추듯 잔잔하게 일렁이는 불빛을 잠시 바라보고 있는 것 만으로도 일상속에서 힘들었던 마음에 위로를 가져다 줍니다.

극강의 가성비를 추구하시는 분들은 다소 실망할 수 있습니다. 하지만 나 자신을 위한 작은 감성적 사치를 선물하고자 할 때 아주 좋은 선택이 될 것 같습니다.

현대카드 M포인트몰에서 50%포인트를 사용해 자비로 구입했으며, 이 글을 쓰는 지금도 책상 한쪽에서 음악과 함께 따듯한 불빛을 일렁이고 있습니다.

vue와 express 연동하기

LeafCat — Tue, 4 May 2021 20:58:03 +0900

nodejs의 가장 많이 사용되는 web 프레임워크인 Express js와 vuejs를 연동하여 프로젝트를 시작하는 방법에 대한 글이다. 각각의 프로젝트를 별도로 설치하고 둘을 연동시키는 방법으로 진행한다.

아래 글을 참고해서 Vue와 Express를 각각의 프로젝트로 우선 설치하는 것으로 시작한다.

1. vue 설치 : www.leafcats.com/326

vue cli로 vue.js 스켈레톤 프레임워크 설치

1. 통합 프로젝트 디렉토리 생성 $ mkdir node-test $ cd node-test 2. vue-cli 설치 $ sudo npm install vue-cli -g 3. webpack을 사용해 vue project 생성 $ sudo vue init webpack front 필요한 것들을 선택해..

www.leafcats.com

2. Express 설치 : www.leafcats.com/327

Node Express 스켈레톤 웹 프레임워크 생성

1. express-generator 설치 $ sudo npm i express-generator -g 2. express 프로젝트 설치 $ cd ~/node-test $ express backend --view=pug 3. express 서버 실행 $ cd backend $ npm install $ DEBUG=backend:* n..

www.leafcats.com

3. front/config/index.js의 bulid 항목의 경로를 다음과 같이 수정한다.

4. npm build를 통해 front 프로젝트를 빌드한다.

$ npm run build

5. 빌드가 완료되면 backend(express) 프로젝트의 public/index.html 파일과 pulbic/static 하위에 css, js파일들이 추가되어있다.

5. backend/routes/index.js파일에 path 모듈을 추가하고 res.sendfile을 아래와같이 추가한다. (res.render는 주석처리한다.)

6. backend 서버를 실행한다.

$  DEBUG=backend:* npm start

localhost:3000 (express 서버)로 접속하면 vue 화면이 보이는 것을 확인할 수 있다.

Node Express 스켈레톤 웹 프레임워크 생성

LeafCat — Tue, 4 May 2021 20:47:38 +0900

1. express-generator 설치

$ sudo npm i express-generator -g

2. express 프로젝트 설치

$ cd ~/node-test
$ express backend --view=pug

3. express 서버 실행

$ cd backend
$ npm install
$ DEBUG=backend:* npm start

브라우저에서 localhost:3000 접속하면 Express 초기 화면이 나타난다.

vue cli로 vue.js 스켈레톤 프레임워크 설치

LeafCat — Tue, 4 May 2021 20:45:12 +0900

1. 통합 프로젝트 디렉토리 생성

$ mkdir node-test
$ cd node-test

2. vue-cli 설치

$ sudo npm install vue-cli -g

3. webpack을 사용해 vue project 생성

$ sudo vue init webpack front

필요한 것들을 선택해서 진행한다. 잘 모르겠으면 그냥 쭉 엔터키

4. front 디렉터리로 이동해서 vue 프로젝트 실행해보기

$ cd front
$ npm run dev

브라우저에서 localhost:8080에 접속하면 vue 초기 화면을 확인할 수 있다.

wsl2 설치 - windows에서 리눅스 사용하기

LeafCat — Sun, 2 May 2021 00:16:43 +0900

리눅스를 철저하게 무시해오던 마이크로소프트가 어느순간부터인가 극단적일 정도로 친 리눅스 성향으로 방향을 전환한 것 같다.

엄청나게 향상된 wsl2 (Windows Subsystem Linux 2)의 도입으로 사실상 windows 환경에서 별도의 복잡한 가상화 설정 없이도 완벽하게 리눅스 환경을 동시에! 사용할 수 있게 되었다. 심지어 여러 리눅스 배포판을 한번에 말이다. windows의 디스크 드라이브들아 모두 마운트 되어 있으며 docker와 같은 툴을 windows 및 설치한 리눅스들이 완벽하게 공유한다.

"개발자는 맥북을 써야한다" 라는 미신이 반쯤 맞는 말이었던 것이 맥이 유닉스 계열이라는 점 때문이었는데 이제는 오히려 windows OS를 사용하는 것이 훨씬 더 나은 리눅스 개발환경을 제공한다.

0. Windows Terminal 다운로드

우선 wsl만큼이나 혁신적인 도구인 windows terminal을 다운로드받자. wsl을 제대로 활용하려면 선택이 아닌 필수이다.

Windows Terminal은 Microsoft Store에서 받을 수 있다.

1. 사전조건 확인

wsl2는 다음과 같은 조건의 windows 버전 이상에서만 사용 가능하다.

x64 시스템의 경우: 버전 1903 이상, 빌드 18362 이상
ARM64 시스템의 경우: 버전 2004 이상, 빌드 19041 이상

cmd를 열어 winver을 입력해 현재 PC에 설치된 windows OS 버전을 확인해서 해당 버전 아래라면 업데이트를 하자.

2. WSL2활성화 및 VM기능 설정

우선, PowerShell을 관리자 권한으로 실행한 뒤, 다음 명령어를 실행한다.

- WSL2 Enable

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

- Virtual Machine Platform 사용 설정

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

(실제로 사용성에 있어서는 마치 windows 위에 리눅스를 프로세스처럼 설치해서 사용하는 것 같지만 엄연히 두 OS는 커널이 다르기에 공존이 불가능하다. WSL 역시 가상화를 통해 리눅스를 사용하는 것이기 때문에 Virtual Machine Platform 옵션을 사용하도록 설정해 줘야한다.)

3. 재부팅

WSL2를 설치한 뒤에는 재부팅을 해야 사용이 가능합니다.

4. Linux 커널 업데이트 패키지 다운로드 및 설치

wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi

5. WSL2를 기본 사용으로 설정

wsl --set-default-version 2

6. 원하는 Linux 배포판 설치

Microsoft Store에서 원하는 Linux 배포판을 설치한다. (여러개 설치도 가능)

7. 정상 설치 확인

$ wsl -l -v

혹시나 5번 단계를 건너뛰어 wsl1 버전을 사용중이라면 다음과 같이 변경해준다.

$ wsl --set-version Ubuntu-18.04 2

Ubuntu 리눅스 최신버전 node.js 설치

LeafCat — Sat, 1 May 2021 23:00:27 +0900

일반적으로 ubuntu에서 패키지를 설치하는 가장 쉬운 방법은 apt를 사용하는 것이다. 하지만 그냥 apt install을 통해 설치할 경우, 원하는 버전을 설치할 수 없으며 일반적으로 구버전이 설치된다.

다음과 같은 방법으로 최신버전(혹은 희망하는 버전)의 nodejs를 설치해줄 수 있다.

1. PPA 등록

$ curl -sL https://deb.nodesource.com/setup_14.x | sudo -E bash -

(14.x가 아닌 다른 버전을 선택하고 싶으면 14를 원하는 버전으로 바꿔주자)

2. apt install로 nodejs 설치

$ sudo apt install nodejs

3. 여러 빌드 툴이 포함된 build-essential 설치

$ sudo apt install build-essential

Ubuntu user root 권한 부여

LeafCat — Tue, 27 Apr 2021 17:18:45 +0900

1. /etc/sudoers 수정

$ vi /etc/sudoers
아래와 같이 root 아래에 root로 부여할 일반 계정을 추가해준다.

※ readolny파일이라 수정이 안 될 경우 다음 글 참고

www.leafcats.com/322

/etc/sudoers 파일 수정(readonly 파일 수정 권한)

linux에서 특정 user를 root로 설정하는 과정에서 sudoers 파일을 수정할 일이 생겼다. /etc/sudoers파일은 최초에 440으로 설정되어 있어서 readonly 상태이다. 다음과 같이 수정 권한을 부여하면 수정이 가

www.leafcats.com

2. /etc/passwd 수정

$ vi /etc/passwd

user 권한을 부여할 사용자를 찾아서 {계정}:x:0:0 으로 변경해준다.

3. /etc/group 수정

$ vi /etc/passwd

root group에 사용자 계정을 추가한다.

/etc/sudoers 파일 수정(readonly 파일 수정 권한)

LeafCat — Tue, 27 Apr 2021 17:08:44 +0900

linux에서 특정 user를 root로 설정하는 과정에서 sudoers 파일을 수정할 일이 생겼다.

/etc/sudoers파일은 최초에 440으로 설정되어 있어서 readonly 상태이다. 다음과 같이 수정 권한을 부여하면 수정이 가능해진다.

$ sudo bash
$ chattr -i /etc/sudoers
$ chmod u+w /etc/sudoers

디파이 비영구적 손실 개념

LeafCat — Mon, 26 Apr 2021 12:57:31 +0900

우선, 디파이에 대한 전반적인 개념에대해 먼저 다음 글을 참고 바랍니다. (디파이 개념과 이자농사 수익 구조에 대해 : www.leafcats.com/311)

사실 디파이가 풀에 유동성을 공급하고 이에 따른 이자를 받는 '이자 농사'만을 의미하는 것은 아니다. 하지만 일반적인 개인 투자자들이 가장 관심 있는 디파이는 이자농사를 기반으로 하는 유동성 공급일 것이다. 수십~수만 퍼센트의 연이율을 앞세워 투자자들을 유혹하지만, 유동성 풀 공급에서 절대 간과해서는 안되는 부분이 바로 '비영구적 손실(Impermanent loss) 이다. '비영구적'이라는 단어 때문에 별거 아니라고 생각했다가 영구적으로 모든 자산을 날려버릴 수 있는 위험한 요소이기에, 실제로 디파이에 유동성을 공급해서 수익을 보고자 하는 투자자라면 반드시 개념을 완벽하게 이해 하고 있어야 한다.

디파이 풀에 유동성을 공급할 때 일반적으로 코인의 쌍(pair)을 1:1로 공급하게 된다.

이더리움과 달러를 유동성으로 공급하는 것을 예로 들 때,

현재 1이더리움이 100달러(테더) 라고 가정하고 초기에 10 이더리움과 1000테더를 풀에 예치 하는 상황을 생각해 보자.

이더리움의 가치가 상승하거나 하락할 경우 두 코인 페어의 비율이 변동되게 된다.

풀에서는 이 비율이 스왑을 통해 자연스럽게 조정이 된다. 즉, 이더리움이 오르면 타 거래소들과의 재정 거래를 위해 사람들은 테더를 풀에 넣고 이더리움을 가져간다.

자연스럽게 풀에서 테더 대비 이더리움의 가치가 많이 상승해 이제 1이더리움의 가치가 400 달러가 된다.

초기에 나는 10 이더리움과 1000 테더를 풀에 가지고 있었지만, 이제는 5ETH와 2000테더를 가지고 있게 된다.

당연히 ETH가 상승 했기 때문에 처음보다 전체 자산의 가치는 올랐다. 하지만 만약 풀에 넣지 않았을 상황을 가정해 본다면 어떨까?

- 유동성 공급을 하지 않고 10ETH와 1000테더를 홀딩할 경우 현재 자산가치는 10*400 + 1000 = 5000달러

- 유동성 공급으로 IL이 발생한 경우 현재 자산 가치는 5*400 + 2000 = 4000달러

즉, 유동성을 제공하지 않았을 경우에 비해 1000달러에 해당하는 손실이 발생하게 된다.

이것이 바로 비영구적 손실(Impermanent loss)이다.

'비영구적'이라 함은 다시 이더리움 가격이 떨어져 초기의 비율로 돌아오면 사라지는 손실이기 때문에 '비영구적'이라고 하는 것이다. 코인 가격이 다시 떨어지지 않고 계속 오르거나, 반대로 하락시에 생기는 비영구적 손실도 다시 상승하지 않고 계속 하락한다면 이는 '영구적'이 될 수도 있는 것이다.

코인의 가치가 상승했을 경우는 홀딩 대비 덜 버는 것이기 때문에 조금 아쉽지만 그러려니 할 수 있다.

하지만 비영구적 손실의 진정한 위험은 코인 가치가 하락하는 것에서 온다. (이는 코인+스테이블 에서도 마찬가지다)

정말로 많은 사람들이(심지어 디파이에 대해 잘 안다고 자부하는 사람들조차) 하락 할때는 덜 손해본다고 알고 있다. 이것이 정말로 위험한 생각이다. 결론부터 말하면 유동성 공급 중 한쪽 코인 가치가 하락할 경우 비영구적손실만큼 손해를 추가로 입는다. 스캠 코인들을 이율 높다고 테더나 dai같은 스테이블과 페어로 유동성 공급하면 내 테더나 dai까지 모두 싹 잃어버릴 수 있다는 소리다.

출처 : binance academy (https://academy.binance.com/ko/articles/impermanent-loss-explained)

블록체인과 크립토 생태계에서 가장 먼저 현실화 되고 사업화 되는 부분이 NFT라고 많이들 이야기 한다. 하지만, 디파이야말로 블록체인과 크립토로 엄청난 유동성과 경제적인 효과를 가장 먼저 실현해 내고 있는 산업이라고 생각한다.

디파이를 단순히 이자농사 돈넣고 돈먹기로만 생각해서는 안된다. 물론 Dex와 유동성 풀, 스왑 등도 디파이의 한 축을 담당하는 중요한 부분이다. 다음번에는 내 코인을 담보로 다른 코인 혹은 스테이블코인을 대출을 받아 레버리지 효과를 발생시킬 수 있는 디파이의 또다른 분야에 대해 글을 작성하려 한다.

디파이 DeFi 3부작

1부 : 디파이 개념과 이자농사 수익 구조에 대해 : www.leafcats.com/311

2부 : 디파이 비영구적 손실 개념 : www.leafcats.com/321

3부 : 디파이로 하는 코인 담보대출

Ubuntu linux nslookup 설치

LeafCat — Tue, 20 Apr 2021 14:21:37 +0900

dns 등에서 특정 도메인에 맵핑된 ip를 확인하기 위해 nslookup 패키지를 주로 사용한다.

하지만 아래와 같이 환경에 따라 nslookup이 기본적으로 설치되어 있지 않은 경우가 많다.

apt를 활용해 ubuntu 리눅스에 nslookup을 설치하기위해 우선 apt update를 해주자

$ apt update

업데이트가 완료되면 nslookup을 설치하기 위해 apt install nslookup을 하면, 해당 모듈이 존재하지 않는것으로 나온다.

nslookup은 apt를 통해 별도로 설치가 안되는 것으로 보인다. nslookup 모듈은 dnsutils 라는 패키지에 포함되어 있다. 따라서 dnsutils를 설치해주자.

$ apt install dnsutils

설치가 완료된 뒤 정상적으로 nslookup을 사용할 수 있는것을 확인할 수 있다.

WSL2 프로세스 외부 접속을 위한 포트포워딩

LeafCat — Mon, 19 Apr 2021 11:23:54 +0900

MS의 업데이트로 WSL2 내부에서 실행한 프로세스를 Host windows에서 localhost로 접속이 가능하게끔 되었다.

하지만 해당 프로세스를 아예 외부에서 접속하고자 할 때에는 Host의 ip로 접속이 불가능하다.

이를 위해 포트 포워딩 작업을 해 줘야 하는데, 이를 수행해주는 스크립트를 구글링 속 해외 한 귀인으로부터 얻을 수 있었다. (https://dev.to/vishnumohanrk/wsl-port-forwarding-2e22)

1. 아래 스크립트를 작성해서 OOO.ps1 이름으로 저장한다.

ex) C:\ports_wsl.ps1

If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) {   
  $arguments = "& '" + $myinvocation.mycommand.definition + "'"
  Start-Process powershell -Verb runAs -ArgumentList $arguments
  Break
}

$remoteport = bash.exe -c "ifconfig eth0 | grep 'inet '"
$found = $remoteport -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}';

if ( $found ) {
  $remoteport = $matches[0];
}
else {
  Write-Output "The Script Exited, the ip address of WSL 2 cannot be found";
  exit;
}

$ports = @(3000, 3001, 5000, 5500, 19000, 19002, 19006);

Invoke-Expression "netsh interface portproxy reset";

for ( $i = 0; $i -lt $ports.length; $i++ ) {
  $port = $ports[$i];
  Invoke-Expression "netsh interface portproxy add v4tov4 listenport=$port connectport=$port connectaddress=$remoteport";
}

Invoke-Expression "netsh interface portproxy show v4tov4";

2. $ports = @(3000, 3001, 5000, 5500, 19000, 19002, 19006); 부분을 수정해 포워딩을 원하는 포트를 추가 혹은 제거한다.

3. Windows PowerShell을 관리자 권한으로 실행한다.

4. 해당 스크립트를 실행한다.

※ 이 시스템에서 스크립트를 실행할 수 없으므로 C:\ports_wsl.ps1 파일을 로드할 수 없습니다. 자세한 내용은 about_Executio n_Policies(https://go.microsoft.com/fwlink/?LinkID=135170)를 참조하십시오. 와 같은 오류 발생시 다음 게시글 참고 : (www.leafcats.com/317)

PowerShell 스크립트 실행 오류 - 이 시스템에서 스크립트를 실행할 수 없으므로..

LeafCat — Mon, 19 Apr 2021 11:14:49 +0900

Windows PowerShell 스크립트를 작성하여 실행하려 할 때 다음과 같은 에러가 발생했다.

.\wsl_port.ps1 : 이 시스템에서 스크립트를 실행할 수 없으므로 C:\wsl_port.ps1 파일을 로드할 수 없습니다. 자세한 내용은 about_Executio
n_Policies(https://go.microsoft.com/fwlink/?LinkID=135170)를 참조하십시오.

구글링 결과 window에서 스크립트 실행에 대한 권한이 막혀있기 때문이라 한다.

해결 방법은 다음과 같다.

1. PowerShell을 관리자 권한으로 실행

2. ExecutionPolicy를 다음과 같이 변경

$ Set-ExecutionPolicy RemoteSigned

3. 다시 ps1 스크립트를 실행해보면 정상적으로 실행 되는 것을 확인할 수 있다.

linux docker 명령어 자동완성 (docker bash autocompletion)

LeafCat — Thu, 15 Apr 2021 11:54:03 +0900

새로 생성한 리눅스 환경에서 docker를 설치하고 사용하려 할 때 자동완성이 되어있지 않아 불편함을 느꼈던 적이 많다.

docker 명령어에 자동완성을 적용하기 위한 절차는 다음과 같다. (ubuntu 기준)

1. bash-completion 설치

$ apt install bash-completion

2. docker 명령어 적용

$ curl https://raw.githubusercontent.com/docker/docker-ce/master/components/cli/contrib/completion/bash/docker -o /etc/bash_completion.d/docker.sh

3. /etc/.bash.bashrc 파일 주석해제

$ vim /etc/bash.bashrc

#아래 스크립트가 주석처리 되어있다면 주석을 해제해준다.
if ! shopt -oq posix; then
    if [ -f /usr/share/bash-completion/bash_completion ]; then
        . /usr/share/bash-completion/bash_completion
    elif [ -f /etc/bash_completion ]; then
        . /etc/bash_completion
    fi
fi

4. ~/.bashrc 주석해제

$ vim ~/.bashrc

if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
    . /etc/bash_completion
fi

5. source 명령어로 적용

$ source /etc/bash.bashrc
$ source ~/.bashrc

[gin] go web framework gin 시작하기

LeafCat — Tue, 13 Apr 2021 16:04:57 +0900

golang web프레임워크로는 gin gonic, Martini, beego 등 여러 프레임워크가 있다. MVC기반의 Full stack web framwork는 beego가 가장 활발한듯 하고 빠른 속도의 micro web framwork는 gin이 가장 활발한 커뮤니티가 있다. (gi이 모든 go framwork project 중 github의 star가 가장 많다.)

gin quickstart는 매우 간단하다.

1. Go 설치

2. Gin 설치

$ go get -u github.com/gin-gonic/gin

3. quickstart (main.go작성)

package main

import "github.com/gin-gonic/gin"

func main() {
	r := gin.Default()
	r.GET("/ping", func(c *gin.Context) {
		c.JSON(200, gin.H{
			"message": "pong",
		})
	})
	r.Run() // listen and serve on 0.0.0.0:8080 (for windows "localhost:8080")
}

4. 실행

$ go run example.go

5. localhost 8080으로 접속하면 잘 실행된 것을 확인할 수 있다.

MinIO 설치 docker registry object storage 연계

LeafCat — Thu, 25 Mar 2021 00:43:48 +0900

Private docker registry를 구축하려 할 때 AWS S3등 Object storage를 사용하게 되는 경우가 많을것이다.

MinIO는 실제 운영 환경에서 Object Storage를 사용하기 이전에 테스트 용도로 사용하기 위한 가볍고 훌륭한 오픈소스 오브젝트 스토리지이다.

1. MinIO설치

MinIO는 binary, docker, window, kubernetes(helm) 등 다양한 방식으로 매우 손쉽게 설치할 수 있다.

(min.io/download#/docker)

간단한 테스트를 위해 docker로 설치를 해보자

$  docker run -d -p 80:9000 --name minio minio/minio server /export

(기본적으로 minio는 9000번 포트를 사용한다. 이번 테스트에서는 80으로 포워딩했다.)

설치 후 웹브라우저로 접속해서 UI를 통해 확인해 볼 수 있다. (초기 계정/pw : minioadmin/minioadmin)

2. bucket 생성

registry로 사용할 bucket을 생성하자. minio cli를 별도로 설치해서 생성해도 되지만, 간단하기 UI로 생성/관리 할 수 있다. 화면 우측 하단 플러스 버튼을 클릭해 생성한다.

3. registry config 파일 작성

config.yml

version: 0.1
log:
  level: debug
  formatter: text
  fields:
    service: registry
    environment: staging
loglevel: debug
storage:
  s3:
    accesskey: "minioadmin"
    secretkey: "minioadmin"
    region: us-east-1
    regionendpoint: http://{endpoint ip or domain}
    # Make sure you've created the following bucket.
    bucket: docker
    encrypt: false
    secure: false
    chunksize: 5242880
    rootdirectory: /
  delete:
    enabled: true
  maintenance:
    uploadpurging:
      enabled: true
      age: 168h
      interval: 24h
      dryrun: false
    readonly:
      enabled: false
http:
  addr: :5000

3. 만든 config 파일을 사용해 registry continer 실행

$ docker run -d -p 5000:5000 -v $(pwd)/config.yml:/etc/docker/registry/config.yml  --name=registry registry

4. 확인

이미지가 잘 들어간다.

MinIO 웹에서도 bucket 내부에 레이어 정보들이 업로드 된것을 확인해 볼 수 있다.

Ubuntu 리눅스 apt-get 명령어

LeafCat — Fri, 19 Feb 2021 13:43:18 +0900

apt-get은 우분투 리눅스에서 패키지를 설치하기 위해 사용하는 명령어이다.

CentOS 계열의 yum과 유사한 기능을 수행한다.(www.leafcats.com/172 -리눅스 yum 명령어)

apt-get이 나오기 전에는 dkpg(Debian package)를 사용해서 필요한 패키지를 설치 했는데, dkpg는 단순히 필요한 패키지를 설치해 줄 뿐 '의존성' 문제를 해결할 수 없다.

예를 들어 A라는 패키지를 설치하기 위해 B라는 패키지가 필수라면 B를 수동으로 먼저 설치해 줘야 하고, B를 설치하는데 또 C에 의존성이 있다면 C를 또 설치해 줘야 한다.

apt-get은 이를 개선하여 설치하려는 패키지가 의존하고 있는 모든 패키지를 한번에 설치해 준다. 우분투 리눅스에 패키지 설치를 위해서는 대부분 apt-get 하나면 충분하다.

apt-get이 제공하는 기능들을 살펴보기 위해 help 옵션을 주면 다음과 같은 하위 명령어를 볼 수 있을 것이다.

$ apt-get --help

apt-get 의 자주 사용하는 명령어들

다음은 주로 사용하는 기본 명령어들에 대한 설명이다.

패키지 설치

$ apt-get -y install 패키지명

-y옵션을 주지 않으면 의존성이 있는 패키지 설치 등 과정에서 직접 yes를 입력해 줘야 한다.

패키지 목록 업데이트

$ apt-get update

apt-get은 /etc/apt/sources.list 파일을 읽어서 다운로드할 패키지 목록을 관리한다. 해당 파일을 수정하거나 리모트 소스에서 리스트가 업데이트 되었다면 위 명령어를 통해 패키지 목록을 업데이트 해 줘야 한다.

패키지 삭제

$ apt-get remove 패키지명

설치된 패키지를 삭제한다. remove로 삭제한 경우 설정 파일이 남아있을 수 있어 다시 설치할 경우 이전의 설정이 적용될 수 있다.

$ apt-get purge 패키지명

설치된 패키지를 설정파일까지 완전히 삭제한다.

$ apt-get autoremove

사용하지 않는 패키지를 삭제한다.

Clean

$ apt-get clean
$ apt-get autoclean

설치 과정에서 받은 임시 파일이나 오래된 파일들을 제거한다.

디파이 개념과 이자농사 수익 구조에 대해

LeafCat — Thu, 18 Feb 2021 22:21:13 +0900

디파이(DeFi, Decentralized finance)는 아는 사람들만의 전유물이었다. 하지만 최근 일부 디파이 토큰들의 급등, 국내 거래소 상장 등을 통해 대부분의 암호화폐 투자자들에게 '일단 들어는 본' 것이 되었다.

수십조원의 자금이 디파이에 몰리고 있다. 사실 개인적으로 암호화폐를 투자하는 사람들은 이제 '디파이를 하는 사람'과 '하지 않는 사람'으로 나눌 수 있을 만큼 디파이는 암호화폐 역사상 비트코인과 이더리움에 버금가는 위대한 발명이라고 생각한다. 하지만 아직도 90% 이상의 암호화폐 투자자는 그들의 코인을 거래소에서 개인 지갑으로 꺼내본 적도 없기에 아직도 국내에서 디파이가 대중적으로 유행하기에는 갈 길이 멀어 보인다.

정말 혹시나 디파이에 관심이 생겨 참여해 봐야 겠다는 마음을 먹은 사람들을 위해 디파이에 관련된 글들을 적어보려 한다. 디파이는 생각보다 더 어렵다. 블록체인과 크립토에 익숙하지 않다면 (심지어 개인 지갑에 대한 개념도 없다면)실수 한 번으로 모든 코인을 모두 잃을 수 있으며, 사기와 스캠이 넘쳐나고 제대로 된 개념 정립이 되어있지 않는다면 사소한 잘못으로도 큰 손해를 입을 수도 있다.

우선 디파이를 시작하려는 사람들을 위해, 혹은 시작해서 하고 있으나 헷갈리는 개념들에 대해 먼저 정리해 보았다.

디파이란?

디파이(DeFi, Decentralized finance)는 영문 그대로 '탈 중앙화된 금융'이다. 기존 은행, 거래소 등 중앙화된 기관의 전유물이었던 금융업을 블록체인의 특성을 이용해 모두가 은행/거래소가 될 수 있도록 해준다. 은행에 참여해 자산을 남에게 빌려주고 이자를 받을 수도 있고, 누구나 거래소가 되어 거래에 대한 수수료 수익을 가져갈 수도 있으며, 은행/거래소의 운영에 투표를 통해 상장될 토큰을 직접 결정하거나 이율 등에 대한 결정에 참여할 수도 있다.

디파이 스왑(Swap)이란?

이더리움진영 등 디파이의 역사가 나름 오래 된 플랫폼의 경우 정말 많은 종류의 디파이 플랫폼들이 존재하지만, 일반적으로 스왑(Swap) 거래소가 그 중심이 된다. 스왑 거래소는 일반적인 중앙화 거래소(업비트, 바이낸스 등)과 달리 거래에 호가가 존재하지 않는다. 간단하게 A코인을 주면 B코인으로 바꿔준다.

예를 들어 테더(USDT)로 이더리움(ETH)를 사고자 한다면, 개인 지갑에서 직접 일정 양의 테더를 스왑에 넣으면 그 금액에 해당하는 이더리움을 개인 지갑으로 바로 보내준다. 거래소에 돈을 예치하거나 입출금 프로세스, KYC등 아무것도 필요 없이 디파이에 내 지갑을 연결하고 코인을 보내면 원하는 코인을 비율에 맞춰 지갑으로 보내주는 것이다.

그렇다면 대체 그 비율은 누가 결정하며 무슨 기준으로 가격이 결정되는 것인가?

바로 이자를 받기 원하는 사람들이 넣은 LP(Liquidity Pool)의 비율에 따라 모든 것이 결정된다.

지금 가격이 1이더=1,000테더 라고 가정하자. 사람들은 LP에 코인을 넣기 위해서는 이더리움과 테더를 1:1 가격 비율로 넣어야 한다. 즉, 이자를 받고자 1이더를 LP에 넣기 위해서는 1000테더를 같이 넣어야만 한다. 그렇게 많은 사람들이 LP에 참여해 풀에 1000이더와 1,000,000테더가 들어와 있다.

여기서 이더의 가치가 올라 사람들이 스왑을 통해 이더리움을 사고자 테더를 스왑해 이더리움을 가져가서 전체 풀에 500이더와 3,000,000테더가 되었다고 치자. 처음에 1이더를 스왑으로 거래하기 위해서는 1,000테더를 스왑하면 됐지만 이제는 1이더를 얻기 위해서는 6,000테더를 스왑해야 한다. (LP에 추가로 투입하기 위해서도 1이더 당 6,000테더를 넣어야 한다)

즉, LP에 들어와 있는 두 토큰의 비율에 따라 가격이 결정되는 것이다. 이는 재정 거래를 하는 봇들을 통해 수많은 중앙화 거래소의 가격에 자연스럽게 연동된다.

이자농사의 수익 구조

사실상 블록체인상에서 이루어지는 모든 대다수의 금융 활동을 디파이라 할 수 있다. 하지만 일반적으로 가장 많은 일반 투자자들이 참여하고 있는 디파이인 '이자 농사'의 수익 구조에 대해 설명하겠다.

이자농사를 통해 얻을 수 있는 수익은 크게 3가지이다.

1. 스왑 거래 수수료

2. 디파이 거버넌스 토큰 채굴

3. LP토큰을 활용한 파생

1. 스왑 거래 수수료 / 2. 디파이 거버넌스 토큰 채굴

위에서 설명했듯 스왑 거래소가 존재하기 위해서는 사람들이 LP 풀에 코인을 넣어야 한다. LP에 많은 코인이 들어와 있을수록 그 디파이는 안정적이 되고 리스크가 줄어든다. 그렇다면 LP에 넣는 사람들은 왜 코인을 넣는 것일까? 그 이유가 스왑 거래 수수료 수익과 거버넌스 토큰 채굴 목적이다.

스왑에서 거래할 경우 일반적인 중앙화 거래소와 마찬가지로 거래 수수료가 발생한다. 이 수수료는 해당 코인 쌍의 LP에 코인을 공급한 사람들이 N분할로 가져가게 된다. 내가 이더리움과 테더 풀에 참여했다면 누군가가 스왑 거래소에서 이더리움-테더를 거래 할 때마다 수수료를 내 풀 비중 만큼 받게 되는 것이다.

이와 동시에 LP에 토큰을 예치하면 그 금액과 비중에 따라 해당 디파이의 거버넌스 토큰이 매 초 내 몫으로 쌓이며, 언제든 이를 클레임 할 수 있다. 이 거버넌스 토큰은 해당 스왑 거래소의 운영에 참여할 권한을 갖게 된다. 자유롭게 상장이 불가능한 스왑 거래소의 경우, 상장 심사에 투표하거나 수수료의 비율, 파트너쉽 등 디파이 스왑의 대부분의 운영에 투표를 통해 참여할 수 있다. 해당 디파이 스왑의 LP풀에 많은 자금이 잠길수록 이 거버넌스 토큰의 가치는 올라간다.

3. LP 토큰을 이용한 파생

LP에 참여하면 내 토큰을 해당 디파이에 예치 하게 되는 대신 그 권리에 대한 증표로 LP토큰이라는 것을 받는다. 이 토큰을 또 다른 곳에 예치하거나 그저 가지고 있는 것 만으로도 파생 디파이 업체들의 토큰을 얻을 수도 있다. 그렇기에 이더리움의 유니스왑과 같은 대형 디파이 거래소의 이더-테더 풀과 같은 메인 LP풀의 권리는 때로는 그 자체로도 많은 수익이 되기도 한다.

그렇다면 무조건 디파이에 참여 하는 것이 이득인가?

사실 그렇다! 라고 말 하고 싶다. 하지만 LP풀 참여는 코인을 그냥 홀딩하고 있는 것보다 손해를 볼 가능성도 크다. 이를 비영구적 손실(Impermanent Loss) 이라 한다. 비영구적 손실은 디파이를 참여하는 사람들이 가장 머리아프고 명확히 이해가 잘 가지 않는 개념이다. 이 비영구적 손실에 대해서는 다음 글에서 자세히 설명하려 한다.

( 디파이(DeFi) 유동성 공급에 따른 비영구적 손실 개념 - www.leafcats.com/321 )

디파이(DeFi) 유동성 공급에 따른 비영구적 손실 개념

우선, 디파이에 대한 전반적인 개념에대해 먼저 다음 글을 참고 바랍니다. (디파이 개념과 이자농사 수익 구조에 대해 : www.leafcats.com/311) 사실 디파이가 풀에 유동성을 공급하고 이에 따른 이자

www.leafcats.com

디파이 DeFi 3부작

1부 : 디파이 개념과 이자농사 수익 구조에 대해 : www.leafcats.com/311

2부 : 디파이(DeFi) 유동성 공급에 따른 비영구적 손실 개념 : www.leafcats.com/321

3부 : 디파이로 하는 코인 담보대출

Java JWT 토큰 생성 및 검증 예제 (jjwt 예제)

LeafCat — Tue, 26 Jan 2021 16:10:03 +0900

Jwt에 대한 기본 개념과 구조 설명은 다음 게시글 참조.

(JWT (Json web token) : JWT 토큰의 소개와 구조 : www.leafcats.com/309)

Java에서 JWT 토큰을 발급하고 사용하기 위한 방법에 대한 간단한 예제 코드를 공유한다.

(기준환경 : Spring boot 2.1.2)

1. Dependency 추가

maven 혹은 gradle에 jjwt dependency 추가

<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt</artifactId>
    <version>0.9.1</version>
</dependency>

2. JWT 토큰 생성 및 검증 util

아래 예제에서는 서비스에 사용할 VO와 permission 정보, error정보 등을 private claim으로 token payload에 포함시켰다.

public class JwtTokenUtil {
	
    private static final String SECRET_KEY = "PRIVATE_KEY";  //TODO Key는 하드코딩 하지말고 외부에서 가져오는것을 권장
    
    public static String createToken(String subject, AccessVO accessVO, Boolean hasPermission, Errors errors) {
    	
    	long ttlMillis = (10 * 1000 * 60);
    	
        if (ttlMillis <= 0) {
            throw new RuntimeException("Expiry time must be greater than Zero : ["+ttlMillis+"] ");
        }
        SignatureAlgorithm  signatureAlgorithm= SignatureAlgorithm.HS256;
 
        byte[] secretKeyBytes = DatatypeConverter.parseBase64Binary(SECRET_KEY);
        Key signingKey = new SecretKeySpec(secretKeyBytes, signatureAlgorithm.getJcaName());
        JwtBuilder builder = Jwts.builder()
                .setSubject(subject)
                .setIssuer("leafcats.com")
                .setHeaderParam("typ", "JWT")
                .claim("hasPermission", hasPermission)
                .signWith(signatureAlgorithm, signingKey);
        
        Map<String, Object> map = new HashMap<String, Object>();
        
        //private claim으로 VO객체를 추가할 수 있음
        if(accessVO != null) {
        	builder.claim("access", accessVO);
        }
        
        if(errors != null) {
        	builder.claim("errors", errors);
        }
        
        long nowMillis = System.currentTimeMillis();
        builder.setExpiration(new Date(nowMillis + ttlMillis));
        return builder.compact();
    }
 
    public static String getSubject(String token) {
        Claims claims = Jwts.parser()
                .setSigningKey(DatatypeConverter.parseBase64Binary(SECRET_KEY))
                .parseClaimsJws(token).getBody();
        return claims.getSubject();
    }
    
    public static Claims getTokenData(String token) {
    	Claims claims = Jwts.parser()
    			.setSigningKey(DatatypeConverter.parseBase64Binary(SECRET_KEY))
    			.parseClaimsJws(token).getBody();
    	return claims;
    }
    
    public static Map<String, Object> getSubjectMap(String token) {
    	
        String subject = getSubject(token);
        Map<String, Object> map = new LinkedHashMap<String, Object>();
        map.put("result", subject);
        return map;
    }

}

3. 사용

3.1. 토큰 생성

String token = JwtTokenUtil.createToken(RequestParam.getUsername(), accessVO, hasPermission, response.getData().getErrors());

3.2. 클라이언트에서 들어온 토큰 검증

String token = registryRequestParam.getToken();

//토큰이 있으면 토큰으로 인증
if(token != null && !"".equals(token)) {
	Claims tokenData = JwtTokenUtil.getTokenData(token);
	String tmp = objectMapper.writeValueAsString(tokenData.get("access"));
	AccessVO accessVO = objectMapper.readValue(tmp, AccessVO.class);
	
	if((Boolean)tokenData.get("hasPermission")) {
		if(accessVO.getActions().contains("pull")) {
			hasPermission = true;
		}else {
...
..
		}
		
	}
}else{ //토큰 없으면 ERROR
...
...
}

JWT (Json web token) : JWT 토큰의 소개와 구조

LeafCat — Tue, 26 Jan 2021 13:49:37 +0900

1. 토큰기반 인증의 필요성

최근 토큰기반 인증을 지원하고 권장하는 모듈들이 늘어나고 있다. 토큰기반 인증이 활발하게 사용되기 이전에는(물론 지금도 수많은 곳에서 사용중이다) 세션을 사용한 인증을 사용했다. 세션은 최근 부각되고 있는 마이크로 서비스 측면에서 치명적인 단점을 가지고 있다.

"스케일 인 / 스케일 아웃 등 확장성이 중요한 마이크로서비스 환경에서 세션 유지에 대한 불편함이 있다."

이를 획기적으로 개선할 수 있는 대안이 바로 토큰기반 인증이다.

인증 정보와 기본적인 일부 데이터들을 정해진 시간동안 유효한 토큰으로 만들어 인증에 사용하게 되는데, 이는 서버측 부하를 줄여줄 뿐 아니라 스케일 인 / 스케일 아웃 상황에서 어떤 노드로 커넥션이 옮겨 가더라도 현재의 인증 상태를 유지할 수 있게 된다.

다만 토큰은 서버가 클라이언트의 상태를 확인하고 이를 가지고 있어야 하는 stateful 서비스에는 적합하지 않다.

2. JWT (Json Web Token)

JWT(Json Web Token)은 json string 형태로 되어있는 토큰이다.

JWT이외로 많이 사용되고 있는 Oauth 토큰과의 가장 큰 차이점은 토큰 자체에 정보를 담고있는지에 대한 여부이다. Oauth 토큰의 경우 인증의 유효성 여부만 판단할 수 있기에 만약 서버가 해당 토큰에 담겨있는 인증 사용자의 다른 정보를 확인하기 위해서는 추가적인 서버 작업이 필요하다.

이와는 다르게 JWT의 경우 JSON형식의 토큰 자체에 필요한 정보들이 담겨있기 때문에 인증 외로 필요한 작업들이 있을 때 서버에서 추가 작업이 필요 없다는 장점이 있다.

3. JWT 구성

JWT는 xxx.yyy.zzz 와 같이 . 을 구분자로 3가지 구역으로 나누어져 있다.

3.1. Header

JWT의 가장 앞 구역은 header이다. Header에는 typ(토큰의 타입), alg(해시 알고리즘)을 담고있다.

3.2. Payload

JWT의 중간 부분을 구성하는 Payload(내용)이다.

토큰이 담고있는 정보가 들어있으며 key/value 쌍으로 이루어진 정보 하나 하나를 claim이라고 부른다.

클레임의 종류는 다음과 같이 세가지로 나누어진다.

3.2.1. registered claim

토큰 자체에 대한 정보들을 담고있는 클레임들이다. 미리 정해진 이름들을 사용해야 하지만 필수적으로 필요한 클레임은 없다.

iss : 토큰 발급자
sub : 토큰의 제목
aud : 토큰의 대상
exp : 토큰 만료일시
nbf : Not Before의 약자이며 지정된 날자가 도달하기 전까지는 토큰이 처리되지 않는다.
iat : 토큰이 발행된(issued) 시간을 의미한다.

3.2.2. public claim

public claim은 collision-resistant해야 하며 주로 URL 형식으로 만들어진다.

ex) {"https://leafcats.com/has_role" : true}

3.2.3. private claim

서비스에 필요한 정보들이 저장된다. 해당 사용자의 role, 이름 등 서비스에 사용될 정보들이 저장되어 있다.

3.3. Signature

JWT 마지막 영역은 서명 정보로 이루어져 있다. 서명은 Header의 인코딩된 값과 Payload의 인코딩값을 합친 다음 private key로 해싱 하여 생성된다. 서버는 이를 통해 해당 토큰의 위변조 여부를 판단할 수 있다.

즉, 해커가 header와 payload에 있는 정보를 변조했다 하더라도 서버에서 이를 다시 해싱했을 때 signature 영역과 다르다면 유효한 토큰이 아니라고 판단할 수 있는 것이다.

JWT 토큰 발급 및 사용 Java 예제 : www.leafcats.com/310

private docker registry 이중화

LeafCat — Tue, 7 Jul 2020 15:09:52 +0900

Docker hub 등의 Public registry를 사용하지 않고, 별도 private registry를 구축해 실제 운영 환경에 사용하는 경우가 있다. 대규모의 클러스터 운영 환경일수록 registry는 컨테이너로 기동되는 서비스의 빌드 및 배포에 매우 중요한 역할을 하기에 가용성 및 안정성에 압박을 받게 될 것이다.

Registry를 이중화 하는 것은 일반적인 DB이중화에 비해 간단하다. docker docs에서 기술하고 있는 다음 3가지만 지켜주면 된다.

The most important aspect is that a load balanced cluster of registries must share the same resources. For the current version of the registry, this means the following must be the same:
- Storage Driver
- HTTP Secret
- Redis Cache (if configured)

Registry 인스턴스를 2개 올리고 이를 load balanc한다고 할때, 각 Registry 인스턴스는 다음 3가지를 동일하게 유지해야 한다.

1. Storage driver (file system이던 S3건..)를 같은 곳을 바라보게 한다.
2중화를 하건 3중화를 하건 실제 물리 데이터가 저장될 장소는 동일해야 한다. 이게 일반적인 RDB와 다른 점인데, DB의 경우에는 애초에 하나의 스토리지는 하나의 인스턴스밖에 바라보지 못한다. 이미 하나의 DB인스턴스가 물고 있는 스토리지를 다른 인스턴스가 물고 뜰 수가 없다.

반면, Docker registry의 경우 몇 개의 인스턴스라도 하나의 스토리지를 바라보고 실행될 수 있으며, 이중화를 위해서는 이렇게 구성 해야한다.

2. 동일한 HTTP Secret을 준다.
이부분을 놓치는 바람에 고생을 많이 했는데.. registry의 config.yaml파일이나 환경변수에 REGISTRY_HTTP_SECRET 값으로 secret을 줄 수 있다. 만약 시크릿을 별도로 설정하지 않는다면, Registry 인스턴스가 처음 시작될 때 임의의 값을 생성해서 실행한다. 이 경우에 이중화된 각각의 Registry 인스턴스는 secret 값이 다르기 때문에 docker는 이 두 인스턴스가 유효한 하나의 서비스가 아니라고 판단해서 pull / push 등의 작업이 정상적으로 되지 않는다.

따라서 config.yaml의 http.secret에 문자열로 된 시크릿을 설정해 주거나, REGISTRY_HTTP_SECRET 환경변수로 시크릿 값을 모든 인스턴스에 동일하게 설정해야 한다.

3. Redis cache

docker registry는 registry에 저장된 이미지의 layer metadata 캐시를 위해 inmemory와 redis를 지원한다. inmemory로 설정할 경우 해당 registry 인스턴스의 로컬 inmemory를 캐시 저장소로 사용하고, redis로 설정할 경우 별도의 redis 서버를 캐시 서버로 연결해 줘야 한다.

registry를 이중화 하는 경우에 캐시를 inmemory로 하게되면 각 인스턴스가 캐싱하고 있는 정보가 다르기 때문에 정상적으로 사용이 불가능하다. 반드시 별도의 redis 서버를 두고 모든 registry 인스턴스가 동일한 redis에 연결되어야 한다.

리눅스 tar 압축 / 압축풀기 (tar, gz)

LeafCat — Thu, 25 Jun 2020 15:58:03 +0900

리눅스는 파일 '압축'과 '묶기' 가 별개로 이루어진다. 단순히 tar로 묶인 파일이라고 해도 gz 등으로 압축하지 않는다면 용량이 줄지 않는다.

자주 쓰이는 tar 압축 관련 명령어는 다음과 같다.

1. tar로 묶기
tar -cvf [파일명.tar] [대상1] [대상2] [대상3]...

2. tar 묶음 풀기
tar -xvf [파일명.tar]

3. tar.gz 로 묶고 압축하기
tar -zcvf [파일명.tar.gz] [대상1] [대상2] [대상3]...

4. tar.gz 압축 풀기
tar -zxvf [파일명.tar.gz]

아래는 리눅스 tar 명령어의 동작과 옵션에 대한 부가 설명이다.

tar 동작

소문자 c : 새로운 묶음을 만든다.

대문자 C : tar 묶음을 풀 때 지정한 디렉터리 하위에 풀어준다. 지정하지 않으면 해당 tar 파일과 동일한 디렉터리에 풀린다.

x : 묶인 파일을 풀어준다.

t : 풀기 전에 경로를 보여준다.

tar 옵션

f(필수) : tar 파일의 이름을 지정한다.

v : 파일이 묶이고 풀리는 과정을 터미널상에 보여준다.

대문자 J : tar로 묶고 xz로 압축한다.

소문자 j : tar로 묶고 bzip2로 압축한다.

호문자 z : tar로 묶고 gzip으로 압축한다.

쿠버네티스(Kubernetes) 사용에 따른 장점

LeafCat — Thu, 25 Jun 2020 00:26:39 +0900

1. 애플리케이션 배포의 단순화

개발자가 운영자의 도움이나 서버에 대한 별도의 지식 없이 자체적으로 애플리케이션을 배포할 수 있게 된다. 쿠버네티스 클러스터의 노드는 수많은 베어메탈 서버 혹은 VM으로 구성되어 있을지라도 배포를 기다리는 애플리케이션 입장에서는 하나의 거대한 서버이다.

개발자는 컨테이너화 된 애플리케이션을 인프라 구성에 대한 정보 없이도 손쉽게 배포할 수 있다. 또한 쿠버네티스 환경에서는 rolling upgrade, blue-green 배포 등을 간단하게 실행할 수 있다.

2. 애플리케이션 개발의 단순화

개발 환경과 운영 환경이 동일한 환경(컨테이너)에서 애플리케이션이 구동된다는 보장을 갖게 된다. 개발자는 환경 차이에 따른 추가적인 고민을 할 필요가 없게 된다. java로 동작하는 애플리케이션을 배포하기 위해서 클러스터의 어떤 node에도 java가 설치되어 있을 필요가 없다(추가적인 수많은 환경 설정들도 신경쓸 필요가 없다). 어떤 노드에 애플리케이션이 배포되더라도 애플리케이션은 빌드한 컨테이너의 java와 환경 설정을 동일하게 가져간다.

또한 개발자가 고려해야 하는 복잡한 기능들(피어 검색, 리소스 락을 위한 인스턴스 리더 선정 등)을 구현할 필요 없이 쿠버네티스를 활용할 수 있다.

3. 컴퓨팅 리소스 활용

쿠버네티스는 배포할 애플리케이션이 요구하는 리소스 등을 고려해 배포될 노드를 자동으로 선택해 준다. 쿠버네티스는 빠르고 효율적으로 수백, 수천개의 노드의 자원 상황에 따라 애플리케이션을 적재 적소에 배포할 수 있게 된다. 이를 통해 낭비되는 자원을 최소화 할 수 있으며 개발자, 인프라 운영자의 수고도 최소화 할 수 있다.

4. 지속적인 상태 확인과 셀프 힐링

쿠버네티스는 배포된 애플리케이션의 구성 요소들과 노드를 지속적으로 모니터링 한다. 컨테이너에 문제가 발생하거나 노드에 장애가 발생할 경우 자동으로 해당 애플리케이션 컨테이너를 문제가 없는 다른 적당한 노드로 스케쥴링해 다시 구동시켜준다. 컨테이너 특성상 재구동이 매우 빠르게 이루어지며 운영자의 모니터링 없이도 장애에 자동으로 대응할 수 있게 된다.

5. 오토스케일링

특정 컨테이너에 부하가 급격하게 발생할 경우, 쿠버네티스는 이를 모니터링 하고 있다가 정해진 수준 이상으로 부하 발생시 자동으로 스케일 아웃하여 컨테이너를 늘려서 부하를 분산시켜준다. 사용이 줄어 부하가 감소하면 쿠버네티스는 다시 이전 수준으로 감소시켜 준다.

이를 통해 급격한 부하 증가에 따른 장애를 방지할 수 있으며, 스케일 아웃을 위해 미리 거대한 자원을 확보해 둘 필요가 없기 때문에 비용적인 측면 역시 많은 효과를 볼 수 있다.

쿠버네티스(kubernetes) 클러스터 구성요소

LeafCat — Wed, 24 Jun 2020 23:48:59 +0900

쿠버네티스(Kubernetes) 클러스터가 어떤식으로 구성되어 있는지 간략하게 알아보자.

쿠버네티스는 수많은 노드로 구성될 수 있으나, 노드는 크게 두가지 유형으로 나뉜다.

1. 마스터 노드
쿠버네티스 컨트롤 플레인을 실행하는 노드이다. 컨트롤 플레인은 쿠버네티스 클러스터 전체를 제어하고 관리하는 역할을 하는 구성 요소들로 이루어져 있다.

2. 워커 노드
실제 컨테이너들이 배포되는 노드이다. 워커 노드에 애플리케이션 컨테이너들이 구동된다. 마스터 노드도 컨트롤 플레인을 제외하면 하나의 워커 노드로서 기능할 수 있다.

다음은 마스터/워커 노드를 구성하는 요소들에 대한 간략한 설명이다.

컨트롤 플레인의 구성 요소

- API 서버 : 워커노드, 컨트롤 플레인의 구성 요소들과 통신한다.
- 스케쥴러 : 애플리케이션 컨테이너들의 배포를 스케쥴링한다. 컨테이너들을 워커 노드에 할당하고 이들의 구동을 관리한다.
- ETCD : 현재 클러스터가 구성된 정보들을 저장하고 있는 데이터 저장소 역할을 한다.
- 컨트롤러 매니저 : 구성 요소들의 복제본, 워커노드에 대한 추적, 노드 장애 처리 등과 같은 클러스터단에 필요한 기능들을 담당한다.

노드 구성요소

- 컨테이너 런타임 : docker, rkt 등 컨테이너를 실행하는 런타임 (k8s 클러스터의 구성 요소라고 볼 수는 없다.)
- Kubelet : 컨트롤 플레인의 API 서버와 통신하며 각 노드의 컨테이너를 관리한다.
- Kube proxy : 애플리케이션 구성 요소들의 네트워크를 로드밸런싱 해주는 쿠버네티스 서비스 프록시이다.

Docker container의 프로세스 격리(cgroup, namespace)

LeafCat — Tue, 23 Jun 2020 00:06:56 +0900

컨테이너는 Host OS의 커널을 공유하며 하나의 프로세스로서 격리된다.

Docker container가 기존의 VM(가상머신)과 비교하여 가상화 측면에서 어떻게 다른지는 (https://www.leafcats.com/301) 를 참조 바란다.

그렇다면 리눅스 OS 환경에서 어떻게 하나의 프로세스가 커널을 공유하면서 가상화 될 수 있는걸까?

컨테이너는 다음 두가지를 사용해 컨테이너 프로세스를 격리한다.

첫 번째로는 리눅스 네임스페이스(namespace)로 각각 컨테이너에서 실행된 프로세스가 시스템(user, 파일, 네트워크, 호스트명, 프로세스 등)에 대해서 독립되어 볼 수 있도록 구현해 준다.

그 다음으로는 리눅스의 cgroups를 사용해 각각의 컨테이너(프로세스)가 사용할 수 있는 시스템 리소스(CPU, 메모리, network bandwidth)를 제한해 준다. cgroups으로 리소스 사용이 제한된 각 컨테이너는 다른 컨테이너에게 예약된 리소스를 사용할 수 없다. 이는 해당 프로세스가 별도의 OS에서 실행될 때와 비슷한 효과를 줄 수 있다.

namespace와 cgroups. 이 두 가지로 각 컨테이너는 Host, 그리고 다른 컨테이너들과 OS 커널을 공유하면서도 격리된 것처럼 사용할 수 있게 된다.

VM(가상머신) 과 컨테이너 가상화

LeafCat — Mon, 22 Jun 2020 23:17:18 +0900

하나의 물리적인 베어메탈 머신을 여러 머신으로 가상화 하여 분리하는 방식은 크게 VM(가상 머신)과 컨테이너 가상화로 구분된다.

VM은 베어메탈 서버에 설치된 호스트 OS와 커널의 공유하지 않으며 구성 요소 프로세스 뿐만 아니라 시스템 프로세스 전체를 실행하게 된다. 때문에 가상화된 환경 위에 애플리케이션을 구동하기 위해서는 애플리케이션 구동에 필요한 리로스 뿐 아니라 VM을 생성하고 실행하기 위해 많은 추가적인 컴퓨팅 리소스가 필요하다.

또한 VM을 새롭게 구동할 때 시스템 서비스를 새롭게 구성하는 부팅 과정이 필요하며 이는 일반적으로 시간을 소요한다.

컨테이너는 반면에 호스트 OS의 커널을 공유하며 단순히 호스트OS에서 실행되는 하나의 격리되어있는 프로세스로서 동작한다. 즉, 구동하는 애플리케이션이 사용하는 컴퓨팅 리소스 외에 추가로 들어가는 부하가 거의 없다고 볼 수 있다.

커널을 호스트와 공유하기 때문에 시스템 부팅 과정이 필요하지 않으며 컨테이너에서 실행되는 프로세스는 즉시 시작된다.

일반적으로 VM은 자체적으로 오버헤드가 발생하기 때문에 하나의 애플리케이션 모듈 당 하나의 VM을 사용하기 보다는 각 VM마다 연관에 의한 그룹으로 애플리케이션 모듈들을 묶어서 배포하게 된다. 컨테이너의 경우에는 보통 하나의 애플리케이션 모듈마다 하나의 가상화된 컨테이너를 갖게 된다.

위에서 설명한 것처럼 컨테이너 가상화에는 추가적인 리소스 부하가 없기 때문에 동일한 하나의 물리적 베이메탈 머신에서 더 많은 에플리케이션을 가상화하여 구동할 수 있게 된다.

그렇다면 컨테이너 가상화가 무조건 더 유리한 것일까? 그렇지는 않다. VM의 경우 각각의 가상 머신이 독립된 리눅스 커널을 사용한다. 즉, OS가 완전히 격리되어 있다고 볼 수 있다. 반면에 컨테이너의 경우 모든 컨테이너가 Host OS의 동일한 커널을 사용하기 때문에 보안 위험이 발생할 수 있다. 심한 경우, 가상화된 컨테이너가 Host OS까지 간섭할 수 있게 된다.

실제 업무 운영 환경에서는 거대한 베어메탈 서버를 VM으로 일부 가상화 하고, 각각의 VM 위에 보안 관계에 따라 컨테이너를 배포한다. 간단하게 예를 들면, 클라우드 서비스를 제공하는 업체가 있고 이를 사용하는 회사가 A, B, C가 있다고 가정해 보자. 클라우드 업체는 거대한 베어메탈 서버를 3개의 VM으로 가상화 시키고 각 회사의 애플리케이션을 각 VM에 컨테이너로 배포하는 식이다.

Scale up (수직 확장) 과 Scale out (수평 확장)

LeafCat — Mon, 22 Jun 2020 22:15:37 +0900

시스템이 작동하는 서버에 부하가 생겼을 때, 이를 해결하기 위해 서버를 확장한다.

서버 확장을 위한 방법에는 Scale up (수직 확장)과 Scale Out (수평 확장) 두가지 방법이 존재한다.

Scale up : 늘어나는 부하를 처리하기 위해 부족한 자원(CPU, 메모리 등)을 늘려 서버를 수직으로 확장하는 방법.

대부분의 경우, 확장을 위해 동작하고 있는 애플리케이션를 변경할 필요가 없으나 서버의 자원을 확장하는 것에 물리적인 한계가 존재한다.

Scale out : 서버의 수를 늘리고 동작하는 애플리케이션의 복제본을 실행해 이중화, 삼중하를 하는 방식으로 부하를 분산시켜주는 방식.

하나의 서버에 거대한 시스템이 하나로 존재하는 모놀리스 방식의 경우 수평 확장을 위해 애플리케이션 코드의 변경이 필요하며 부하가 발생하는 일부분만 확장하기 어렵기에, 불필요하고 전체 시스템을 통으로 확장해야 하는 경우가 많다. 다만 마이크로서비스로 모듈화 되어있는 시스템의 경우, 컨테이너 기술 및 오케스트레이션 툴 등을 사용해 간단하게 수평 확장할 수 있다.

[CKEditor] 강력한 Javascript Editor 플러그인

LeafCat — Thu, 14 Mar 2019 19:19:32 +0900

기본적인 정보를 보여주기만 하는 웹 사이트가 아니라면 웹 개발에서 에디터를 적용해야 하는 경우가 매우 많다. 특히 블로그나 매거진, 커뮤니티 형식의 흔히 웹앱의 경우 에디터는 필수라고 해도 무방하다.

그렇다면 어떤 에디터를 사용해야 할까? 오픈소스로 제공되는 javascript editor 플러그인은 적지 않다. 그 중에서, 실제 글로벌 대기업들이 사용하고 있고 Use case가 많은 프로젝트가 가장 믿을 수 있고, 자료도 많아서 개발하기에도 수월하다.

오늘은 다양한 자바스크립트 에디터 플러그인 중, 가장 많이 사용되는 에디터 중 하나인 CKEditor에 대해 소개하려 한다.

- 홈페이지 : https://ckeditor.com/

- Document : https://ckeditor.com/docs/

- github : https://github.com/ckeditor/

CKEditor는 Vue, React등 프론트앤드 프레임워크에서도 쉽게 사용할 수 있고, jQuery, Bootstrap 등을 활용한 일반적인 HTML환경에서도 손쉽게 적용할 수 있다.

CKEditor의 가장 강력한 부분은 이미 다양한 글로벌 기업들에서 꾸준히 사용되며 검증되었다는 것에 있다. 그러기에 구글링을 통해서 자료를 구하기도 쉽고, 디버깅에도 한결 수월하다.

현재 지원하는 버전은 CKEditor4와 CKEditor5 버전이 있다.

몇 년 전부터 꾸준히 업데이트가 되고 있는 CKEditor4와 보다 깔끔하고 풍부한 UI를 제공하는 CKEditor5는 각각의 장단점이 있는데, 기능적인 측면에서는 오히려 CKEditor4가 더 많은 것으로 보인다.

CKEditor4로 개발 되어진 소스를 CKEditor5로 전환 해본 경험이 있는데, 플러그인을 적용하기 위한 변수 명이나 속성, 함수가 완전 다르기 때문에 전환에는 어느정도의 공수가 들어간다.

에디터를 적용하기 위한 방법은 https://ckeditor.com/docs/ckeditor5/latest/builds/guides/quick-start.html 각 버전의 다큐먼트를 따라하기만 해도 쉽게 사용할 수 있다.

[Fing] 공유기에 연결된 장치들 IP 확인하기

LeafCat — Sun, 17 Feb 2019 23:24:37 +0900

지금 내가 사용하고 있는 무선 공유기에 연결되어 있는 장치들(휴대폰, 노트북, 데스크탑, TV 등 모든 장치)의 IP 정보를 한번에 쉽게 확인할 수 있는 안드로이드 어플이 있다.

바로 fing라는 안드로이드 어플리케이션이다. 아이폰에도 동일한 App이 있는지는 모르겠지만, 비슷한 기능을 하는 어플리케이션들이 있을 것이다.

별다른 설정 없이 그냥 앱을 설치한 뒤 와이파이로 해당 공유기에 연결하고 앱을 실행하면, 바로 해당 공유기에 연결된 장치들의 IP와 MAC어드레스까지 확인이 가능하다.

노트북이나 데스크탑처럼 직접 커맨드로 손쉽게 IP를 확인하기 쉬운 장치들은 굳이 필요 없더라도 간혹 라즈베리파이나 IP 확인이 필요한 장비들의 IP를 확인하기 매우 쉽고 유용한 어플리케이션이다.

Ubuntu 리눅스에 MongoDB설치와 부팅시 자동실행

LeafCat — Tue, 26 Jun 2018 03:07:22 +0900

최근에는 Docker Container를 통해 리눅스 배포판을 가리지 않고 각종 어플리케이션을 설치하는 것이 가능해 졌다. 그럼에도 간혹 No container로 설치해야 하는 상황들이 있는데, 그 중 가장 많은 경우가 DB이다.

역시나 ubuntu 환경에서 VM Process로 MongoDB를 설치해야 하는 상황이 생겼다.

우선 설치를 위해 아래 커멘드를 실행한다.
(ubuntu 14.04 맞춤형 스크립트이다. 다른 버전의 경우 정상 동작하지 않는다면 mongodb 공식 홈페이지를 참고하자)

1
2
3
4
5
6
7
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 0C49F3730359A14518585931BC711F9BA15703C6
 
echo "deb [ arch=amd64,arm64 ] http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list
 
sudo apt update
 
sudo apt install -y mongodb-org
Colored by Color Scripter
cs

설치가 완료되면, MongoDB를 실행하기 위한 설정을 위해 /etc/mongod.conf 파일을 수정한다. 기본적으로 yaml 문법으로 구성되어 있다.

$ sudo vi /etc/mongod.conf

config 정보를 수정했으면, mongodb를 실행하자.

$ sudo service mongodb start

config 등을 수정하여 재시작이 필요할 경우, 아래 명령어로 재시작 할 수 있다.

$ sudo service mongod restart

mongo 명령어를 통해 MongoDB에 접속할 수 있다.

$ mongo

위와 같이 service 명령어로 시작, 재시작, 중지 등 서비스의 동작에 대한 커맨드를 할 수 있지만, systemctl 명령어를 사용하는 것이 일반적이다.
systemd를 사용하여 부팅과 함께 MongoDB를 실행시키려면 /etc/systemd/system/mongodb.service 파일을 작성한다.

$ sudo vi /etc/systemd/system/mongodb.service

1
2
3
4
5
6
7
8
9
10
[Unit]
Description=High-performance, schema-free document-oriented database 
After=network.target
 
[Service]
User=mongodb
ExecStart=/usr/bin/mongod --quiet --config /etc/mongod.conf
 
[Install]
WantedBy=multi-user.target
Colored by Color Scripter
cs

이제 부팅과 동시에 MongoDB가 실행되며, systemctl 명령어로 구동, 상태확인, 정지, 부팅시 실행 설정 등을 할 수 있다.

구동 : sudo systemctl start mongodb
정지 : sudo systemctl stop mongodb
부팅시 실행여부 설정 : sudo systemctl enable(disable) mongodb
상태 확인 : sudo systemctl status mongodb

파이참(PyCharm) 한줄씩 실행 단축키 및 키맵 설정

LeafCat — Thu, 21 Jun 2018 00:26:27 +0900

파이참을 활용해 파이썬 공부를 하던 도중 위에서부터, 혹은 중간부터 한 줄씩 실행할 수 있는 방법은 없을지 찾아보게 되었다.

물론 디버깅 모드로 실행하는 방법으로도 가능 하겠지만 조금 더 편한 방법이 있었다.

기본적으로 셋팅된 단축키는 다음과 같다.

Alt + Shift + E

실행하고자 하는 라인에서 해당 단축키를 입력하면 그 라인이 실행된다.

범위를 지정해 실행할 수도 있고, 중간의 라인을 건너 뛰고 다른 라인부터 실행할 수도 있다.

위 캡쳐에서 보면 1번, 2번라인을 먼저 실행하고 바로 5번라인을 실행한 뒤 7번라인을 실행했다.

3번라인을 실행하지 않았기 때문에 변수 c가 할당되지 않았고, 7번라인에서는 에러가 발생한 것을 볼 수 있다.

이렇게 한줄씩 원하는 곳을 차례로 실행하다 보면 디버깅이 수월하고 우측 하단의 Special Variables에서 변수가 할당되는 과정도 눈에 잘 들어온다.

키맵 설정

Alt + Shift + E 단축키를 자주 사용하다 보면 이 단축키의 쌍이 매우 불편하게 느껴진다.

파이참에서 키맵을 변경하는 방법은 간단하다. File -> Settings -> Keymap에서 단축키를 변경할 수 있다.

Execute selection in console에 해당하는 키맵을 쉬운 키쌍으로 변경해 주면 되겠다.

[EOS] 이오스 메인넷 출시와 진행 단계 정리

LeafCat — Thu, 31 May 2018 15:47:30 +0900

EOS의 1년간의 길었던 ICO가 종료되고, 메인넷이 출시되는 시점이 다가왔습니다.

이오스 메인넷은 EOS 소프트웨어를 개발하고 ICO를 진행한 Block.one에서 담보하거나 진행하지 않습니다. 때문에 수많은 EOS BP들이 EOS 메인넷 런치 그룹(EMLG)를 결성하여 메인넷의 성공적인 출발을 위해 준비하고 노력해 왔습니다.

시기가 다가올수록 메인넷에 대한 많은 의심과 FUD들이 쏟아지고, 불확실한 정보들이 계속해서 공유되고 있습니다.

FUD를 방지하고, 메인넷 런칭에 대한 확실한 정보를 공유하고자 글을 옮겨왔습니다.

※ 한국어 지원에 대한 부분은 한국 EOS BP 후보인 EOSYS, EOS NodeOne, AcroEOS와 한국 최대 EOS 커뮤니티인 KOREOS.io 의 도움으로 번역 되었으며, 해당 글은 EOS NodeOne의 steemit에서 옮겨 왔습니다.
( https://steemit.com/kr/@eosnodeone/eos-eos )

EOS라 불리는 하나의 메인넷

5월 25일, 2018 EOS 메인넷 런치 그룹(이하 EMLG)은 EOS라고 불릴 하나의 메인넷을 런칭하자는 일념 하에 결성되었습니다. 커뮤니티에 가능한 한 투명하게 모든 것을 진행하고자 런치 계획을 공개합니다.

토큰 동결

ERC-20 EOS 토큰 분배는 6월 1일 22:59:59 UTC에 끝납니다. 이로부터 23시간 후 (EOS ICO를 통해 분배된) ERC-20 토큰은 동결되어 거래가 불가능해집니다.
EMLG는 토큰 동결이 성공적으로 완료된 것을 확인한 후, 메인넷 시동 프로세스를 밟아 나가고자 합니다.
[여러분이 아직 가지고 계신 EOS ERC-20 토큰을 EOS 키페어로 매핑해 두지 않으셨다면, 아래 글을 참조하여 준비하시기 바랍니다.]

http://koreos.io/News/754

EOS 홀더 주의사항

메인넷이 런칭되는 시점을 전후해 많은 스캠이 횡행할 것으로 예상됩니다.
본인이 신뢰하는 블록 프로듀서들 최소 5팀이 모여 공동 성명을 통해 확인해 주기 전까지는 함부로 본인의 프라이빗 키를 노출하지 마세요.
이 경고를 무시한다면 토큰을 잃게 될 수 있습니다. http://koreos.io 에 방문하여 블록 프로듀서 후보들에 대해 알 수 있습니다.

메인넷 가동의 4단계

EOS 메인넷 가동은 아래와 같은 4단계를 거치게 됩니다. 각 단계별로 시간이 정해져 있지는 않습니다. 각 단계가 성공적으로 마무리되는 것이 빠르게 끝나는 것보다 중요하기 때문입니다.
모든 과정이 성공적으로 완수되는 데에는 며칠이 소요될 수 있습니다.

스냅샷 검증 및 부팅(Verify Snapshot & Boot) : EMLG와 기타 객관성을 담보할 수 있는 제3자가 동결된 토큰에 대한 스냅샷을 제작하고 검증합니다. 이 과정이 완료되면 부팅 프로세스가 시작됩니다.
테스팅(Testing) : EMLG와 다른 제3자 그룹이 스냅샷에 있는 토큰 수량이 오류 없이 매핑되었는지 확인합니다. 모든 소프트웨어가 제대로 작동하는지에 대한 테스트도 이 단계에서 이루어집니다.
가동(Enable) : 1, 2단계의 내용이 확인되면 세계 블록프로듀서 커뮤니티가 사용자들이 프라이빗 키를 가져와 투표를 개시해도 안전하다는 합동 성명서를 냅니다. 일반 EOS 토큰 홀더의 투표는 이 합동성명서가 공개된 시점으로부터 본격 개시됩니다.
활성화(Activation) : EOS 메인넷 성공적 가동과 활성화 공표합니다.

이상 스냅샷 확인-검증단계에서부터 활성화 단계까지 모두 완수되면 최종적인 EOS 메인넷이 가동된 것으로 볼 수 있습니다. 그 전까지는 1-3단계의 과정이 성공할때까지 지속적으로 반복됩니다.
이상 모든 단계에는 한치의 기술적 오류가 없도록 치밀한 확인과 검증, 테스팅이 수반될 예정입니다. 이에 따라 모든 과정이 최종 완료되기까지는 수일이 소요될 수 있습니다.

메인넷 가동 4단계 상세 설명

스냅샷 검증 및 부팅(Verify Snapshot & Boot)

EMLG는 공식적인 스냅샷 툴을 이용하여 최종적으로 동결된 ERC-20 EOS 토큰 스냅샷을 생성합니다. 커뮤니티 멤버 분들은 EMLG의 스냅샷에 오류가 없는지, 동일한 툴을 활용해서 스냅샷을 만들어 본 후 그것이 EMLG가 만든 스냅샷과 정확히 일치하는지 제 3자로서 검증해 주시길 부탁드립니다. EMGL가 만든 스냅샷에 오류가 없음이 확인되면, 일시적으로 임명된 블록 프로듀서(ABP; Appointed Block Producer) 그룹이 런치 그룹 내에서 발족됩니다. 이 ABP들은 임시 조직으로, 네트워크의 성공적인 부팅과 부팅된 네트워크가 투표와 유효성 검증이 이루어지는 동안 안정적으로 가동되는지 검증하는 역할을 맡습니다. 이때에는 블록 보상이 주어지지 않습니다.

테스팅(testing)

일시 임명된 프로듀서(ABP)들이 부팅 과정을 완료하고 각 지갑에 매핑된 토큰 액수에 오류가 없음을 확인하면, 네트워크는 제3자 그룹의 검증을 위해 일반 대중에 공개됩니다. 이때부터는 원하는 사람이면 누구든 네트워크에 오류나 결함이 없는지 직접 테스트해보고 검증해 볼 수 있습니다. 커뮤니티의 여러 주체들이 검증에 필요한 툴을 배포하기 시작할 것입니다.
EMLG는 이 단계에서 네트워크를 복제(clone)하여, 최종적으로 승인돼도 괜찮을지를 검증하기 위해 초고강도 자체 테스팅을 진행합니다. 48시간이라는 데드라인을 정해, 커뮤니티가 적극적으로 기술적 하자와 취약점을 찾아내도록 합니다. 만일 이 48시간 내에 코드 변경이 필요한 중대 결함이나 하자가 발견된다면, EMLG는 이 48시간 데드라인을 리셋하여 커뮤니티가 추가적인 테스트를 진행할 수 있도록 여유시간을 줍니다. 이 48시간 프레임은 메인넷 런칭을 주도하는 EMGL의 판단에 따라 변경될 수 있습니다.

가동(enable)

이 단계에서는 EMLG가 일반 토큰 홀더들이 투표해 참여해도 좋다는 공동 성명서를 발표합니다. 이 시점부터 네트워크가 일반 토큰홀더 커뮤니티에게 본격적으로 공개됩니다. EOSIO 체인이 본격적으로 가동되기(enabled) 위해서는, 전체 토큰 홀더의 15%가 자신의 프라이빗 키를 사용하여 토큰을 스테이킹(락업)하고 최소한 하나의 블록 프로듀서에 투표를 해야 합니다. 이 단계에서는 15%의 토큰이 투표에 참여해야 하기에, 커뮤니티의 참여도에 따라 얼마든지 시간이 늘어나거나 줄어들 수 있습니다. 그래서 여러분의 참여와 투표가 중요합니다. 커뮤니티에 투표 방법에 대한 설명이 이미 많이 소개되어 있으니 참고해 보셔도 좋습니다. 현재 커뮤니티에서도 자발적으로 투표 포털사이트를 제작 중에 있으며, 이에 대한 업데이트는 @eosportal 에서 찾아볼 수 있습니다. 위에서 언급했듯, 최소 본인이 신뢰하는 5개의 블록 프로듀서들이 공동 성명을 확인해 주기 전까지는 본인의 프라이빗 키를 절대 노출하지 마십시오. 이 경고를 무시한다면 토큰을 잃게 될 수 있습니다.

활성화(Activation)

메인넷은 스테이크 되고 투표에 쓰인 토큰 수량이 15%에 도달해야 비로소 그 유효성이 인정됩니다. 체인의 다른 일반적인 기능들이 활성화되는 것 역시 이때부터입니다. 모든 일시 임명된 블록 프로듀서(Appointed Block Producer)들은 커뮤니티의 투표로 선출된 블록 프로듀서(Elected Block Producer)로 즉각 대체됩니다.

앞으로 이어질 일들

EMLG는 다음 공동성명을 통해 “검증(Verify)” 기간의 상세 내용을 배포하고, 제3자 그룹이 소프트웨어와 토큰 잔고를 검증하는 데 사용할 수 있는 툴(tool)을 배포할 예정입니다.

메인넷 런칭을 위한 전진

EOS는 인간이 서로 상호작용하는 방식을 근본부터 바꿀 새로운 세대의 블록체인 기술입니다. EOS 커뮤니티가 앞둔 메인넷 시동은 그 시작을 알리는 첫걸음입니다. 메인넷 시동 그룹으로서 우리는 이 경험을 토큰 홀더 여러분과 함께하고 싶습니다. 응원해 주셔서 감사합니다.

EOS 메인넷 런치 그룹 #EOSLaunch

한국어 지원은 EOSYS, EOS NodeOne, AcroEOS 그리고 KOREOS의 도움으로 번역되었습니다.

[ENG]

EOS Mainnet Launch: The Order of Events

The Token Freeze

The ERC-20 EOS token distribution will end on June 1st at 22:59:59 UTC. Per the EOS crowdsale Ethereum smart contract, the ERC-20 tokens will be frozen 23 hours after the end of the token distribution. Once the freeze is completed we will begin the Phases of Launch process. If you have not done so, please be sure to generate your EOS keypair and map them to the ETH address which holds your EOS ERC-20 tokens.

Be Smart. Be Vigilant

The ecosystem will be wrought with scams during this time. Do not import your private key until you have seen a joint statement released from at least five Block Producers that you trust that it is safe to do so. Ignoring this warning could result in tokens lost. Please visit [KOREOS] to learn more about block producer candidates.

Overview: Phases of Launch

There are no times associated with each phase because ensuring each phase is completed successfully is more important than each being completed quickly. The launch process may take days to complete.

Verify Snapshot & Boot: Snapshot taken and verified by EMLG and third parties. Boot process initiated.

Testing: Allow time for EMLG and third parties to verify that the tokens have been loaded according to the snapshot file, and that the software performs well.

Enable: Release joint statement from Block Producer community that it is safe to import private keys and vote. Voting beings.

Activation - Declare the EOS Mainnet active.

Only after all 4 phases are complete do we have an irreversible blockchain. Until then rollback and restart of the chain is possible. This essential technical due diligence, including validation testing, could take days rather than hours to complete.

Phases in Detail

Verify Snapshot & Boot

The EMLG will use the official snapshot tool to produce a final snapshot of the frozen ERC-20 EOS tokens. The community is encouraged to use the same tools to produce their own copies of the snapshot and verify that it matches the EMLG’s copy exactly. Once the snapshot has been verified, Appointed Block Producers will be established within the launch group. These Appointed Block Producers are temporary and only exist to ensure that the network is booted correctly and stable throughout the verification and voting process. No block rewards are awarded at this time.

Testing

Once Appointed Block Producers have completed the boot process and ensured that the token balances are correct the network will be opened for third party verification. Anyone who wishes to verify the network at this stage may do so, and tools will be released by the community to help facilitate this verification.

The EMLG will clone the network at this stage and conduct their own in-depth acceptance testing as well. This stage will continue for a 48-hour period to allow for the completion of these tests. If a major bug is found which requires code changes then the 48-hour window will be reset to allow for ample time to test these new changes. The decision to reset the 48-hour window will be at the sole discretion of the EMLG.

*Transactions or votes staked during this period are not safe and can be undone or lost.

Enable

At this stage a statement will be released by the EMLG and the network will be opened to the general token-holder community. For an EOSIO chain to be considered enabled, 15% of all tokens-holders must use their private keys and stake votes for at least one Block Producer. The length of this phase will be as long as it takes for the token-holder community to act. So get out there and vote! Many block producers have developed tutorials on how to vote. A community voting portal has been developed and you can follow updates on its construction on Twitter @eosportal. As state above, Do not import your private key until you have seen a joint statement released from at least five Block Producers that you trust that it is safe to do so.

Activation

Once 15% of tokens are staked and used to vote the chain is considered valid and normal functions are activated. All Appointed Block Producers will be immediately replaced by the Elected Block Producers that have been voted in by the community.

Next Steps

In the next joint statement we will release the details of the “Verify” period and the tools used to facilitate third party verification of both the software and the token balances.

Onward to Launch

The EOS mainnet is the first step toward a new generation of blockchain technology that will fundamentally affect how we interact with one another. We look forward to sharing this experience with you, the token holder. Thank you for your support.

The EOS Mainnet Launch Group #EOSLaunch

Java Spring websocket client 구현

LeafCat — Fri, 25 May 2018 02:23:28 +0900

Spring에서 Websocket은 Spring 4부터 지원한다고 한다. 거기다 Java는 서버단의 언어로 사용되기 때문에 Websocket Clinet를 Java로 구현하는 것에 대한 예제가 많지 않다.

암호화폐 trading bot을 만들기 위해 spring boot로 websocket 요청을 할 필요가 있어서 이번 기회에 코드를 정리해 보았다.

사용한 라이브러리

Github에 올라와 있는 neovisionaries 라는 websocket 라이브러리를 사용하였다.

( https://github.com/TakahikoKawasaki/nv-websocket-client )

pom.xml

maven을 사용했기 때문에, pom.xml에 아래와 같은 dependency를 추가해 주었다. Gradle을 사용한다면 gradle에 추가해 주면 되겠다.

1
2
3
4
5
<dependency>
    <groupId>com.neovisionaries</groupId>
    <artifactId>nv-websocket-client</artifactId>
    <version>2.4</version>
</dependency>
Colored by Color Scripter
cs

Source

간단하게 text를 입력받아 동일한 text를 return 해주는 테스트용 websocket 서버로 연결하는 소스 예제이다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
 
import com.neovisionaries.ws.client.WebSocket;
import com.neovisionaries.ws.client.WebSocketAdapter;
import com.neovisionaries.ws.client.WebSocketException;
import com.neovisionaries.ws.client.WebSocketExtension;
import com.neovisionaries.ws.client.WebSocketFactory;
 
 
public class EchoClient
{
    /**
     * The echo server on websocket.org.
     */
    private static final String SERVER = "ws://echo.websocket.org";
 
    /**
     * The timeout value in milliseconds for socket connection.
     */
    private static final int TIMEOUT = 5000;
 
 
    /**
     * The entry point of this command line application.
     */
    public static void main(String[] args) throws Exception
    {
        // Connect to the echo server.
        WebSocket ws = connect();
 
        // The standard input via BufferedReader.
        BufferedReader in = getInput();
 
        // A text read from the standard input.
        String text;
 
        // Read lines until "exit" is entered.
        while ((text = in.readLine()) != null)
        {
            // If the input string is "exit".
            if (text.equals("exit"))
            {
                // Finish this application.
                break;
            }
 
            // Send the text to the server.
            ws.sendText(text);
        }
 
        // Close the WebSocket.
        ws.disconnect();
    }
 
 
    /**
     * Connect to the server.
     */
    private static WebSocket connect() throws IOException, WebSocketException
    {
        System.out.println("Start get data from upbit");
        return new WebSocketFactory()
            .setConnectionTimeout(TIMEOUT)
            .createSocket(SERVER)
            .addListener(new WebSocketAdapter() {
                
                // binary message arrived from the server
                public void onBinaryMessage(WebSocket websocket, byte[] binary) {
                    String str = new String(binary);
                    System.out.println(str);
                }
                // A text message arrived from the server.
                public void onTextMessage(WebSocket websocket, String message) {
                    System.out.println(message);
                }
            })
            .addExtension(WebSocketExtension.PERMESSAGE_DEFLATE)
            .connect();
    }
 
 
    /**
     * Wrap the standard input with BufferedReader.
     */
    private static BufferedReader getInput() throws IOException
    {
        return new BufferedReader(new InputStreamReader(System.in));
    }
}
Colored by Color Scripter
cs

Lessoned learn

웹소캣 서버에서 응답을 주는 형식을 잘 파악해야 onTextMessage만 connect method에 선언할 경우, 바이너리 배열 형식으로 리턴 오는 데이터는 수신 자체가 안 된다. 잘 모르겠으면 onTextMessage와 onBinaryMessage 양쪽을 다 열어서 확인해 보자.

[EOS] 이오스 크롬 익스텐션 EOS KIT 소개

LeafCat — Sat, 5 May 2018 17:17:19 +0900

EOS ICO가 종료되는 6/2일이 다가오고 있습니다. 그와 함께 BP(Block Producer) 선거가 시작되는 순간도 가까워 지고 있죠.

지금까지 활성화된 EOS BP 후보의 수는 2018-05-02 EOS GO 발표 기준102팀 입니다.

이 BP 후보들 중 이오스 메인넷이 다가옴에 따라 점점 눈에 보이는 결과물을 보여주는 팀들이 하나씩 생겨나고 있습니다.

비교적 초창기부터 이오스 중국의 BP 후보인 MEET.ONE에서 크롬 익스텐션 어플리케이션으로 EOS KIT을 선보였습니다.

크롬 확장 플러그인으로 설치하여 이오스의 가격과 차트, 고래들 홀더들의 현황, ICO 현황, 각종 SNS에서의 EOS 소식들을 확인할 수 있는 매우 유용한 어플리케이션입니다.

메타마스크와 같은 크롬 익스텐션 프로그램이기에 크롬 웹스토어에서 설치할 수 있습니다.

1. 크롬 웹스토어에 접속합니다.

https://chrome.google.com/webstore/

2. EOS KIT를 검색하고, MEET.ONE에서 제작한 EOS KIT를 CHROME에 추가합니다.

3. 아래와 같이 설치를 계속 진행합니다.

4. 설치가 완료되면 크롬 우측 상단에 MEET.ONE의 EOS KIT 플러그인을 실행할 수 있는 아이콘이 생성됩니다.

5. 아이콘을 클릭해 EOS KIT를 실행합니다.

EOS 토큰의 현재 차트와 가격, Market CAP, ICO현황을 메인화면에서 확인할 수 있습니다.

고래 지갑에 대한 정보를 시각화 해서 보여주는것도 재미있네요.

좌측에 마우스를 가져가면 전체 메뉴가 나타납니다. EOS와 관련된 각종 뉴스들과 SNS 정보, EOS Daap에 대한 정보들을 쉽게 확인할 수 있도록 정리가 되어 있습니다.

이오스 BP 후보들 중 이렇게 생태계를 위해 가시적인 결과물을 보여줄 수록 선거에서 많은 표를 받기 유리해질 듯 합니다. MEET.ONE팀 뿐만 아니라 많은 BP 후보들에서 강력하고 유용한 어플리케인션들을 준비하고 있는 것으로 알려져 있습니다. EOS 메인넷이 다가올 수록 하나씩 실체가 보여지게 되고, 전체 생태계에서 좋은 시너지를 낼 것이라 생각합니다.

Java JDK 이미지와 Docker Container Memory, Cpu limit 문제

LeafCat — Wed, 18 Apr 2018 19:35:59 +0900

아래 설명할 이슈는 Java SE 8u131 , JDK 9 버전 이후 버전에서는 해결된 문제이다.

그 하위 버전에서는 Java Application을 Docker Container를 사용해서 구동하는 경우, CPU와 Memory와 관련된 문제가 있을 수 있다.

Docker의 Resource 제한(CPU / Memeory) 기능과 함께 사용하는 경우이다. Kubernetes의 경우도 결국 Docker의 기능을 사용하게 되기 때문에 마찬가지의 현상이 발생한다.

Docker는 리눅스 cgroup을 사용해 CPU, Memory 할당을 컨테이너별로 격리한다.

하지만 Java SE 8u121 이전 버전의 Java를 사용하는 경우 이 리소스 제한에 대해 문제가 발생한다.

Java 어플리케이션이 Docker 컨테이너에서 실행될 때 JVM은 컨테이너의 리소스 제한이 아닌, Host 환경의 리소스 설정을 사용하게 된다.

즉, 별도로 -Xmx 설정을 주지 않고 Java 컨테이너를 사용하게 되면 JVM은 사용할 수 있는 최대 힙 사이즈를 Host 설정으로 구동되는 것이다.

만약 8GB 메모리 Host OS에 Docker 컨테이너로 4GB 메모리 제한을 걸어 Java 이미지를 실행한다고 가정해 보자.

JDK는 Host 메모리인 8GB를 자신이 사용할 수 있는 최대 힙 사이즈라고 생각하고 GC를 이에 맞춰서 천천히 수행한다.

하지만 실제로 해당 컨테이너에게 할당된 메모리 자원은 4GB가 한계이기 때문에 OOM이 발생하고 컨테이너가 죽는 상황이 생긴다.

이는 CPU의 경우도 마찬가지인데, -XX : ParalllelGCThreads 와 -XX : CICompilerCount 옵션을 JDK 설정에 추가하지 않은 경우 JVM은 Docker CPU 제한을 Host에서 보이는 CPU 코어 수로 적용한다.

결론 :

Java SE 8u131 및 JDK 9 버전 미만의 Java 어플리케이션을 Docker 리소스 제한 기능과 함께 적용하는 경우, JDK 리소스 제한 설정을 반드시 Docker 설정에 맞게 적용해서 구동해야 한다.

Kubernetes pod node Assign 기준(scheduler algorithm)

LeafCat — Tue, 17 Apr 2018 16:59:49 +0900

Kubernetes Scheduler가 node를 선택하는 기준은 1. 노드 필터링을 거치고, 2. 노드 랭킹 점수에 따라 할당된다.

1. 노드 필터링(노드 제약 체크)

- PodFitsHostPorts: 컨테이너가 사용하는 Port 중복 체크

- PodFitsResources: Request 사용 가능한 Node

- NoDiskConflict: AWS EBS, GCE PD, ISCSI 및 Ceph 가 지원되는지

- NoVolumeZoneConflict: Volume path 등 노드에서 제한이 있는지

- MatchNodeSelector: Node selector 제약조건 만족 (특정노드만 배포)

- HostName: PodSpec의 NodeName 필드에 지정된 노드를 제외한 모든 노드

2. 노드 랭킹(priorities)

SUM(weight(k) * priorityFunc(k)) k = LeastRequestedPriority, BalancedResourceAllocation, ServiceSpreadingPriority, EqualPriority)

- LeastRequestedPriority: 새 노드가 노드에 스케줄 된 경우, (Node 전체 capacity - 이미 노드에 있는 모든 pod requests sum - 현재 pod request) / Node 전체 capacity). CPU와 Memory 동일한 가중치 적용

- BalancedResourceAllocation: 현재 pod이 배치 된 후, CPU와 Memory 사용률이 균형을 검사

- SelectorSpreadPriority: 같은 Node에있는 service, replication controller, or replica set에 속하는 Pod 수를 최소화

- CalculateAntiAffinityPriority: 특정 label에 대해 동일한 값을 갖는 노드에서 동일한 서비스에 속하는 포드의 수를 최소화

Reference: https://github.com/kubernetes/community/blob/master/contributors/devel/scheduler_algorithm.md

EOS 이오스 에어드랍 일정 정리

LeafCat — Tue, 17 Apr 2018 16:51:19 +0900

EOS.io 오픈소스 소프트웨어와 그 생태계는 기술적인 부분 외에도 철학적, 경제적으로 매우 정교하게 모델링 되어있죠.

이오스 생태계의 긍정적인 발전이 곧 이오스 투자자 들에게도 큰 수익을 안겨 줄 것입니다. 아는만큼 보이는 법이고, 남들보다 더 보는 만큼 더 많은 경제적 이익도 따라 올거에요.

이오스 관련 프로젝트가 점점 무섭게 증가하고, 그에 따라 에어드랍을 발표한 프로젝트들도 많아지고 있습니다. 이제는 따로 기록하지 않으면 안될 정도가 되어버린듯 하네요. 현재 예정되어 있는 EOS 에어드랍에 대해 정리해 보았습니다.

실체가 전혀 없는 스캠성의 에어드랍은 제외 하였으며, 잘못된 점이 있거나 추가/변경 되는 사항이 있으면 지속적으로 업데이트 할 예정입니다.

※ 좋은 정보는 널리 공유하자는 취지에서 복사해 가시는건 환영이지만, 출처는 꼭 남겨주시면 좋겠습니다 :)

EOS Air-Drops

최초 작성일 : 2018/04/17

최종 수정일 : 2018/05/05

메인넷 이전

■ EOSDac

- 스냅샷 및 에어드랍 : 4/15 한국시간 10시 스냅샷.

- 비율 : 1:1

- 총 발행량 : 12억 개 (미지원 거래소 물량 약 3억개 소각 예정)

- 상세 : 이오스 BP 후보중 한 팀인 EOSDac에서 발행. EOSDac 토큰 소지자가 BP로서의 지분을 보유하게 됨. EOSDAC BP 팀의 운영방향 등에 대한 의결권 행사 가능, BP보상으로 얻은 EOS 중 일부를 EOSDAC토큰 소유자에게 분배할 수 있음. ERC20 토큰으로 선발행 후 이오스 메인넷 이후 스왑 예정 (완료)

- 공식사이트 : http://eosdac.io/

■ EOS Hedging(HNT) 1:1 (5/15일 스냅샷, 5/17부터 에어드랍 시작):

~~홍콩 EOS BP. 암호화폐 파생상품(헷지) 거래 플랫폼.~~ (해당일까지 공지 없음. 스냅샷 진행 여부 불투명)

■ Evolution

- 스냅샷 및 에어드랍 : 5/10 Initial Airdrop 스냅샷 + 6월 스케일 에어드랍

- 비율 1:1 + @

- 총 발행량 : 50억개

- 상세 : 이오스의 문제점이라 생각하는 부분들을(거래소 및 BP지분 등) 자체 개선하여 런칭하는 독립 체인. 별도의 ICO는 없으며, 이오오스 메인넷 토큰 보유자 대상으로 에어드랍한 코인으로 운영할 예정. 총 50억개.

이니셜 에어드랍으로 등록된 지갑 기준 균등분배 + 6월 제네시스 스냅샷 기준으로 이오스 1:1비율 즉, 두번에 걸쳐 에어드랍.

최소 25개 이상의 EOS + 0.025개 이상의 이더리움을 보유한 eos.io에 등록된 개인지갑이면 별도의 작업 필요 없음.

(5월4일 이전에 등록을 완료한 지갑이면 0.025 이더리움 필요 없음) (이니셜 에어드랍 완료)

- 공식사이트 : https://www.evolutionos.com/

■ Lab Ledger

- 스냅샷 및 에어드랍 : 2018 5/21 스냅샷, 2018/6/21 erc20으로 에어드랍, 2019/6/21 EOS 토큰으로 스왑

- 비율 : 1:1

- 총 발행량 : 12억개 (Lab Ledger 팀에서 2억개 보유)

- 상세 : 과학자들을 위한 블록체인 생태계. Scientist들이 자신의 연구를 공유하고, 서로의 연구를 평가함. 고품질 연구의 경우 upvote를 통해 보상을 받을 수 있음. 자신의 연구에 대한 크라우드 펀딩을 받아 자금을 조달 할 수 있는 환경 구축. 이러한 경제 시스템이 EOS를 기반으로 수수료 없이 P2P로 이루어질 예정.

scientist들이 자신의 연구를 블록체인 위에서 공유하고 펀딩을 받을 수 있는 환경을 마련한다는 점에서 굉장히 매력적이라고 생각됨. 우선 ERC20 토큰으로 발행한 후, 2019년 6월 21일이 되어야 최종 EOS 메인체인 토큰으로 다시 스왑해 주는 점이 특이사항.

- 공식 사이트 : https://labledger.net/

■ KEOS

- 스냅샷 및 에어드랍 : 2018/5/31 01:00 UTC, 한국시간 오전 10시 스냅샷.

- 비율 : 1:1

- 총 발행량 : 15억개

- 상세 : 한국 블록체인 스타트업인 KChain의 EOS BP 후보. KEOS토큰을 사용해 탈중앙화 자율 조직(DAC)을 구축하겠다는 목표. EOSDAC과 거의 동일한 사상이라고 생각됨. 토큰을 에어드랍 하는 것도 비슷한 전략인듯함. 100개 이상의 EOS토큰을 보유한 홀더 대상으로 5/31스냅샷. 몇일 나지 않는데 왜 EOS genesis를 참조하지 않는지 알 수 없음.

- 공식 사이트 : https://www.keos.kr/

■ DEOS(DEO)

스냅샷 및 에어드랍 : 2018/5/25 13:00UTC, 한국시간 22:00 스냅샷 / 메인넷 런칭 후 6월3일~7일 사이 에어드랍
비율 : 1:1
총 발행량 : 15억개
상세 : 이오스 기반의 카지노 플랫폼 토큰. 현실의 카지노나 비트코인 기반 게임의 경우에 들어가는 수수료를 이오스 기반으로 조작이 불가능하고 수수료 없는 블록체인 카지노 Dapp
공식 사이트 : https://deosgames.com/

메인넷 스냅샷 Genesis.json 기준 (6월)

■ Everypedia(IQ)

- 스냅샷 및 에어드랍 : 6월 2일 제네시스 스냅샷(제네시스 스냅샷이 늦어질 경우 6월 15일 자체 스냅샷)

- 비율 : 1:1 이상

- 총 발행량 : 10억개 + @

- 상세 : EOS VC에서 3천만달러(약 320억)를 공식 투자받은 Dapp. 위키피디아 공동 창업자중 한명인 래리 생어의 프로젝트. 탈중앙화 인터넷 백과사전. 스팀잇 위키피디아 버전. 이오스 에어드랍 중 유일한 블록원(이오스 개발사) 공식 에어드랍.

- 공식 사이트 : https://everipedia.org/

■ Chaince(CET)

- 스냅샷 및 에어드랍 : 6월 2일 제네시스 스냅샷 기준.

- 비율 : 1:1

- 총 발행량 : 20억개

- 상세 : EOS 기축 거래소. 총 20억개 중 10억개를 EOS 제네시스 스냅샷 기준 1:1 에어드랍. EOS 기축 거래의 수수료를 Chaince 재단에 보관하고, CET토큰 소지자가 보유한 CET를 락업 한 뒤 EOS로 교환할 수 있음. Chaince 거래소는 우수한 이오스 에어드랍 토큰을 선별해 상장할 예정.

- 공식 사이트 : http://chaince.com

■ horuspay

- 스냅샷 및 에어드랍 : 6월 2일 제네시스 스냅샷 / 6월 30일 EOS 메인체인 토큰으로 에어드랍

- 비율 : 1:1

- 총 발행량 : 12억개

- 상세 : 블록체인을 활용한 분산 Global Payroll portal. 페이롤 서비스를 블록체인화하여 페이롤 산업 전반을 블록체인으로 가져오는 것이 목표. 블록체인을 활용해 급여 정보(wages, salaries, 보너스 등)을 투명하게 처리하고, 수수료를 대폭 절감할 수 있게끔 하는 솔루션. 5월 중순 에어드랍 예정이었으나, 메인넷 후 스왑 등의 문제로 스냅샷 일자를 6월2일 제네시스 시점으로 변경함. 백서 공개 예정. 6월 30일에 이오스 지갑으로 에어드랍할 예정

- 공식 사이트 : https://horuspay.io

- 한국 공식 텔레그램 : https://t.me/HorusPayKorea

■ Hirevibes(HVT)

- 스냅샷 및 에어드랍 : 6월 2일 제네시스 스냅샷

- 비율 : 4:1 예정(이오스 4개 당 HVT 1개)

- 상세 : EOS BP 후보, EOSVibes의 구인 플랫폼 Dapp

■ Polalis 총 발행량의 10% :

체인파트너스 런칭 독립 체인 (이오스판 EEA 지향). 기업 대상으로 이오스 메인넷 대비 최대 1/150 가격 수준으로 스테이킹 부담을 줄여줄 예정. 현재 접촉중인 국내 기업 있음

메인넷 이후

■ EOS ASIA(EOS Gems) :

EOS BP 후보, 아시아지역 블록체인 개발인력들이 모인 BP후보이다. 게임 Dapp인 EOS Gems와 디지털 광고(ex. 에드센스) Dapp 개발중에 있다. 이오스 메인넷 런칭 이후 EOS Gems 에어드랍 예정

■ EOS BET (BET)

EOS기반 주사위 게임. 현재 EOS Dapp 최상위권에서 일 트랜잭션 150,000건 이상을 기록하고 있다.

- EOSBet 소개 ( http://www.leafcats.com/290 )

- 게임 플레이 : https://dice.eosbet.io/?ref=eoskywallets

기타

- Scatter : 이오스 지갑 Dapp

- Iryo : 의료 정보 플랫폼

- Carmel : 코딩 교육 플랫폼

꾸준히 업데이트 예정입니다. 잘못된 점이나 추가/변경점이 있는 경우 댓글 부탁드립니다 :)

※ EOS의 검증된 소식과 상세한 정보는 코리오스( http://koreos.io ) 를 잠조 바랍니다.

MySQL function 관련 에러 log_bin_trust_function_creators

LeafCat — Tue, 17 Apr 2018 13:21:04 +0900

어플리케이션에서 다른 쿼리들의 실행에는 문제가 없으나, function이 실행이 안되는 에러가 발생했다.

현상

This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)

위와 같은 에러와 함께 function을 포함한 쿼리의 실행이 되지 않는 현상이다.

원인

구글링 해보니 MySQL 특정 버전대에서 Super 권한이 없는 user에게서 발생할 수 있는 문제이다.

원인은 mysql global variable 중 log_bin_trust_function_creators 옵션이었다.

설명

log_bin_trust_function_creators 옵션은 MySQL이 function, trigger 생성에 대한 제약을 강제할 수 있는 기능이다.

해당 옵션의 default는 OFF이며, OFF상태의 경우 권한이 있더라도 trigger를 생성할 수 없고, function을 생성할 수 없다.

결론적으로 해당 옵션이 OFF 상태일 경우, root 권한이 없는 user가 생성한 function을 일반 user가 실행할 수 없게된다.

해결방법

1. 안정성 검증이 완료된 function을 super유저가 다시 생성하던가

2. log_bin_trust_function_creators 옵션을 ON 시키는 방법으로 해결한다.

확인 ) show global variables like 'log_bin_trust_function_creators';

조회결과 OFF일 경우 SET GLOBAL log_bin_trust_function_creators=ON;

Docker로 EOS Node 쉽게 실행하기

LeafCat — Tue, 17 Apr 2018 01:40:14 +0900

국내에서는 아직도 익숙하지 않은 기술이지만.. docker 기반의 컨테이너는 이미 전 세계적으로 거의 모든 개발사에서 쓰이고 있다. 특히나 오픈소스 소프트웨어에 있어 github에 올라온 소스코드와 docker hub에 Push한 이미지는 기본 중에 기본이다.

이오스는 block one에서 개발하는 오픈소스이다. 역시나 Docker 컨테이너 기반으로 동장할 수 있도록 잘 구성 되어 있으며, 별도로 깃헙에 Run in docker 가이드도 제공한다.

eos.io git hub는 eos.io nodeos와 지갑인 keosd 컨테이너를 docker-compose로 묶어 함께 실행할 수 있도록 가이드 하고 있다.

우선 nodeos만 떼어서 별도로 구동해 보았다. docker를 사용하면 누구나 손쉽게 이오스를 가상화 컨테이너로 구동할 수 있다.

※ 참고

Docker 개념과 Architecture 정리 : http://www.leafcats.com/146

가상머신과 도커 : http://www.leafcats.com/152

1. 준비물

- 최소 8GB 이상의 RAM

- Docker 17.05 version 이상

( 리눅스에 docker 설치 : http://www.leafcats.com/153 )

window에서도 다양한 방법으로 docker를 사용할 수 있다. 가장 쉽게는 window용 docker를 설치해서 사용해도 될것 같지만, VMware를 사용해 8GB RAM Ubuntu VM을 구동해서 사용했다.

2. git에서 eos 소스 받아오기

$ git clone https://github.com/EOSIO/eos.git --recursive

3. Dockerfile이 있는 경로로 이동해 docker build 실행

$ cd eos/Docker

$ docker build . -t eosio/eos

4. Volume 디렉토리 생성

기본적으로 docker container는 컨테이너가 내려가면 데이터가 사라진다. 노드 데이터의 보존을 위해 Host 경로에 디렉토리 하나를 생성하고 이를 Volume으로 물고 컨테이너를 기동할 것이다.

$ mkdir /nodeos-data

5. config.ini 수정

$ vi config.ini

config.ini 파일을 수정해 eos node 구성에 필요한 각종 설정들을 변경할 수 있다.

config.ini 파일을 수정했으면, volume을 물릴 디렉토리 경로에 해당 config.ini 파일을 복사해 놓자.

우선은 별도 수정 없이 디폴트 설정대로 기동하자.

6. container 실행

$ docker run --name nodeos -v /nodeos-data:/opt/eosio/bin/data-dir -p 8888:8888 -p 9876:9876 -t eosio/eos nodeosd.sh arg1 arg2

최초 New Chain 기동에 별도의 genesis.json 파일을 지정하지 않았기 때문에 구동하면서 default genesis file을 생성한다.

실제 EOS 메인넷의 genesis 순간에 쓰일 genesis.json에 포함된다는게 얼마나 큰 의미인지 세삼 느낀다.

새로운 나만의 EOS New Chain이 구동 완료되었고 내 스스로가 BP가 되어 블록을 생성하기 시작했다.

리눅스 환경에서 curl http://127.0.0.1:8888/v1/chain/get_info 명령어를 통해 chain 정보를 얻어올 수 있다.

docker 컨테이너를 통해 node를 기동하고, swarm이나 kubernetes와 같은 도구를 사용해 오케스트레이션 환경을 구성하면, 기본적으로 손쉬운 scale in/out이 가능하다. 더해서 서버 환경과 부하 상황에 따라 유동적으로 자원을 관리할 수 있을 뿐더러 장애 상황에도 여유로운 대응이 가능할 것이다.

다음번에는 docker-compose를 사용해 eos node와 지갑을 연결해 함께 구동하는 것을 해보고, cleos 커맨드를 활용하는 것을 테스트 해 보겠다.