반응형
작성일: 2024년 5월 8일

 

Go 언어를 2015~2020년 사이에 사용하고, 그 뒤로 거의 쓰지 않다가 오늘 go-pktgen 소스 코드를 보다가

몇년 사이 golang에 많은 변화가 있다는 것을 알았다.

내가 2015년에 책으로 배운 Go 언어에 대한 지식만으로 프로그래밍하면 큰코 다치겠다 ㅋㅋ

(회사 동료들이 같이 Go 언어를 사용하면, 같이 성장할텐데... 회사 동료들은 C, C++ 찬양론자들이라서... ㅠㅠ)

 

새로운 Golang Feature도 파악하고, 다시 기억도 좀 살리기 위해 Golang 학습 문서를 봐야겠다

오늘 기준으로 볼만한 온라인 문서를 찾아보니... 아래와 같다.

 

 

Tucker의 Go 언어 프로그래밍 (2021년, 공봉식)

2024년 5월 8일 기준으로 이 책을 eBook으로 구입해서 보고 있는데...

내가 9년 전에 구입해서 봤던 책보다는 3배 정도 설명이 자세하고 친절하다.

9년 전에 구입한 Go 언어 책이 미울 정도이다. (그 책을 읽은 시간이 아깝다 ㅠㅠ)

종이 책(또는 eBook) 중에서는 이 책이 가장 괜찮은 것 같다. (나의 주관적 느낌)

 

Tucker의 Go 언어 프로그래밍 (책 표지)

 

 

아래 화면은 내가 구입한 eBook이고 macOS용 Crema 앱으로 보고 있는 중이다.

컴퓨터학(Compute Science) 전공하고 있는 대학생, 또는 컴퓨터학을 수료한 졸업생이라면 쉽게 읽힐 수 있는 책이다.

왜냐고? 책 중간 중간에 Memory 구조와 Go source code를 설명하는 부분이 자주 등장하는데,

약간이라도 CPU, Memory 구조 및 동작 방식을 알고 보는 것이 재미있다.

예를 들어, 아래 빨간 동그라미로 표시한 부분과 같은 표현이 익숙하고 잘 이해가 되는 분이라면 이 책을 재미있게 읽을 수 있다.

 

Tucker의 Go 언어 프로그래밍 (eBook으로 구입해서 macOS용 Crema로 보고 있음)

참고: 저작권 침해가 될 것 같아서 위와 같이 책 내용을 가렸습니다.

 

Tucker의 Go 언어 프로그래밍 (eBook으로 구입해서 macOS용 Crema로 보고 있음)

 

아무튼 이 책은 적극 추천~~~
(이 책의 저자, 출판사로부터 받은 거 없음. 그냥 개인적 소신임)

 

 

Tucker의 Go 언어 프로그래밍 / 동영상 강의

YouTube 채널, Playlist: https://www.youtube.com/playlist?list=PLy-g2fnSzUTBHwuXkWQ834QHDZwLx6v6j

 

 

 

Effective Go (Go Official Site)

영어 문서: https://go.dev/doc/effective_go 

한국어 문서: https://gosudaweb.gitbooks.io/effective-go-in-korean/content/

 

 

 

 

Facebook 그룹

가끔 Facebook을 통해서 공식 행사를 알려준다. (예를 들어, GopherCon Korea 2024 같은 이벤트)

https://www.facebook.com/groups/golangko

 

 

 

 


 

반응형
작성일: 2024년 4월 19일

 

 

Rust Programming 책을 구입해서 읽기 어려운 상황이라면, 아래의 온라인 문서를 추천.

 

https://doc.rust-kr.org/

 

The Rust Programming Language - The Rust Programming Language

Steve Klabnik, Carol Nichols 지음. 기여해주신 러스트 커뮤니티 여러분과 한국어 번역에 참여해주신 분들께 감사드립니다. 이 텍스트 버전은 여러분이 (2023년 2월 9일에 출시된) 러스트 1.67.1 혹은 이후

doc.rust-kr.org

 

 

 


 

반응형
작성일: 2024년 4월 18일

 

 

example.com에 대해서 새로 변경된 DNS Record 정보를 가져오게 하려면

기존에 내 Local Host의 DNS Cache에 저장된 DNS Record를 삭제해야 한다.

 

macOS를 사용하는 경우라면, 아래와 같이 명령을 수행하면 DNS Cache를 삭제할 수 있다. (또는 DNS 초기화, Flush, Reset)

 

$ sudo dscacheutil -flushcache

$ sudo killall -HUP mDNSResponder

 

 

## DNS Cache를 flush하기 전에는 CURL 같은 Application이 
## 예전에 조회해서 얻었던 Old IP address를 사용한다.
$ curl -v my-example.kr:8080
  Trying 12.15.20.38:8080...
  ... 중간 생략 ...


## DNS Cache를 flush
$ sudo dscacheutil -flushcache

$ sudo killall -HUP mDNSResponder

## DNS Cache를 flush한 후에는 CURL 같은 Application이
## 새 DNS Record를 조회하고, 새로 얻은 IP Address를 사용한다.
$ curl -v my-example.kr:8080
  Trying 19.12.25.113:8080...
  ... 중간 생략 ...

 

 

 

 

 

 

 


 

반응형
작성일: 2024년 4월 16일

 

 

Network(특히 ONOS, VPN), Linux OS, Kubernetes, GNS3, Raspberry Pi 등 관련 내용을 구글링하다보면, 자주 '톨티의 공작소'가 검색 결과로 뜬다.

그래서 의도하지 않게 '톨티의 공작소' 블로그를 보게 된다.

 

인터넷 문서(블로그)에 이렇게 정성과 공을 들여서 컨텐츠를 만들어주니, 나 같은 열람자(Reader) 입장에서는 고맙다.

문서 중간에 그림, 표 등이 많이 있어서 바쁠 때는 쓱 훑어보기에도 좋다.

 

https://m.blog.naver.com/love_tolty

 

톨티의 공작소 : 네이버 블로그

Tolty의 하드웨어 소프트웨어 공작소 입니다.^^

m.blog.naver.com

 

 

 

 

 

 

반응형
작성일: 2024년 4월 12일

 

Jinja2를 사용해서 리스트(목록)이 있는 문서를 만들다보면 리스트의 각 컬럼의 폭을 맞춰야 할 때가 있다.

 

예를 들어, 아래와 같은 경우.

## 컬럼이 들쑥 날쑥한 리스트
redmine  IN  A  10.1.1.8
git  IN  A  10.1.1.7
jenkins  IN  A  10.1.1.11
chat-server  IN  A  10.1.1.12

 

 

Jinja2 파일(즉, example.j2 파일)에 아래와 같이 기술하면, 왼쪽 또는 오른쪽으로 정렬할 수 있다.

 

## 문자열의 오른쪽으로 공백 문자를 채우기 (Right-side Whitespace Padding)
{{ "{:<17}".format("test string") }}

## 문자열의 왼쪽으로 공백 문자를 채우기 (Left-side Whitespace Padding)
{{ "{:>17}".format("test string") }}

 

 

아래 출력 예시는 가장 왼쪽 컬럼(예: redmine, git, jenkins, ...)에 대해서 오른쪽 공백 문자를 채운 것이다.

## 컬럼 폭(너비)를 맞춘 리스트
redmine      IN  A  10.1.1.8
git          IN  A  10.1.1.7
jenkins      IN  A  10.1.1.11
chat-server  IN  A  10.1.1.12

 

 


 

반응형
작성일: 2024년 4월 12일

 

 

Jinja 파일(*.j2)과 YAML 파일(*.yml *.yaml)을 VIM으로 편집할 때

문서 내용이 적절한 Syntax Color로 보여지지 않는다면, 아래 절차를 따라서 VIM 편집기를 설정해보자.

 

 

Pathogen 설치하기

## 관련 폴더를 미리 만든다.
$ mkdir -p ~/.vim/autoload ~/.vim/bundle 

## pathogen.vim 파일을 다운로드한다.
$ curl -LSso ~/.vim/autoload/pathogen.vim https://tpo.pe/pathogen.vim

## ~/.vimrc 파일에 아래의 내용을 추가한다.
$ cat ~/.vimrc
... 중간 생략 ...
execute pathogen#infect()
syntax on
filetype plugin indent on
... 중간 생략 ...

 

 

VIM Bundle 추가하기

$ cd ~/.vim/bundle

## Ansible, YAML 관련 번들 파일을 다운로드
$ git clone https://github.com/chase/vim-ansible-yaml.git

## Jinja 관련 번들 파일을 다운로드
$ git clone https://github.com/lepture/vim-jinja.git

 

 

테스트하기

$ vim test.j2

 

Jinja 파일 하이라이트 기능

 

 


 

반응형

 

작성일: 2024년 4월 9일

 

Amazon AWS, Microsoft Azure, Google GCP, Oracle Cloud Infra 등 CSP에서 Compute resource를 생성하려고 보면,

이 Compute instance(또는 VM instance)를 생성한 것 때문에 비용이 얼마나 되는지 감을 잡기가 어렵다.

 

마침, Oracle Cloud의 연간 Credit 구입한 것이 많이 남아 있고, 5일 후에 Expire되기 때문에 남는 Credit을 소진해볼겸

VM instnace를 Scale-up, Scale-down하면서 비용 증가/감소 정도를 체크해봤다.

 

1개 VM instance를 대상으로 CPU/Memory Scale-up 수행 후 비용 증감을 체크

초기 VM instance의 Spec Scale-up 이후의 Spec 비용 증가분(Delta)
CPU: 1 core (2 thread)
MEM: 2GB
Storage: 50 GB (Boot volume)
CPU: 8 core (16 thread)
MEM: 128 GB
Storage: 50 GB (Boot volume)
11,479 원   (Daily Cost)

 

참고:
  CPU 종류: AMD EPYC 7J13
  CPU Caches: 
      L1d:  512 KiB (8 instances)
      L1i:   512 KiB (8 instances)
      L2:   4 MiB (8 instances)
      L3:   32 MiB (2 instances)

 

 

 

위에 내가 실제로 VM instance를 Scale-up한 이후의 비용 증가분을 계산한 것은
클라우드 테넌트 계약 조건과 현재 원/달러 환율 따라 30% 정도 차이가 날 것이다.
특히 클라우드 테넌트 계약시, 3년 이상 장기 계약한 경우 많은 할인율이 적용되서  Scale-up에 대한 증가분이 크지 않을 수 있다.
1년 단위로 단기 계약한 테넌트라면, CPU/Memory를 Scale-up할 때 비용 증가분이 위의 계산 결과보다 클 수 있다.

 

 

반응형
작성일: 2024년 4월 9일

 

Microsoft Azure, AWS(Amazon), GCP(Google Cloud Platform), Oracle Cloud Infra 등 Cloud Infra 서비스를 사용하다보면

예상한 것보다 비용이 더 지출되는 경우가 있다.

내 경우, Cloud Infra를 1년간 사용하는 중에 Storage(Block Volume)과 VCN(Virtual Cloud Network) 리소스 사용 비용이 계속 증가만 하길래 이 비용 증가 원인을 찾는 작업을 했다.

 


 

나는 회사 업무 때문에 CSP(Cloud Service Provider)가 제공하는 Managed Kubernetes를 종종 이용하는데, 

이 Managed Kubernetes의 cluster를 생성하고 삭제하는 과정에서 찌꺼기 리소스가 계속 발생하고 있었다.

찌꺼기 리소스가 발생하게 된 이유에 대해 좀더 자세히 설명하면 아래와 같다.

 

  1. Managed Kubernetes 서비스를 이용하여 Cluster-A를 생성한다.
  2. Cluster-A에 Pod, LoadBalancer Type의 Service 리소스 등을 생성한다.
  3. 몇달 동안 사용 후 Cluster-A를 삭제한다.    <-- 이 순간부터 찌꺼기 리소스에 대한 과금이 시작된다 (일명, 숨겨진 비용 발생)

 

위와 같은 순서로 Managed Kubernetes Cluster를 사용하면,

Pod가 사용했던 Storage(즉, PV)와 Public IP Address를 사용했던 LoadBalancer 리소스가 찌꺼기로 남게 된다.

즉, 실제로는 K8s Cluster가 없지만 Storage와 Public IP address는 내 테넌트 내의 자원으로 할당된 상태로 남게 된다.

이 찌꺼기 자원이 계속 비용을 유발하므로, 발견한 즉시 삭제해야 한다.

내 경우, 1년 동안 사용하면서 Pod, PVC, PV, Service Resoruce(LB Type) 등을 먼저 삭제하지 않은 상태에서

K8s cluster를 삭제한 경우가 2번 있었는데... 이것들을 정리하고 나니까 Cloud 사용 요금이 50% 수준으로 떨어졌다. ㅠㅠ

그 동안 쓰지 않아도 될 돈을 지출하고 있었던 것이다.

 

Cloud 서비스를 사용할 때는 Kubernetes cluster를 삭제하는 순서에 대해서 꼭 주의하자!

 

  1. Kubernetes cluster 내부에서 사용했던 Pod, PVC, PV, Service Resoruce를 모두 삭제한다.
  2. PV, Service Resource가 삭제되었는지 여부를 반드시 확인한 후,
  3. Kubernetes cluster를 삭제한다.

 


 

+ Recent posts