[TIL][makefile] 一些常用的 Makefile 指令整理

摘要

花了一點時間玩了一下 makefile ,有一些字串對應方式與使用方式在不使用 sed 的前提下其實也很方便. 順手整理一下一些常用的案例.

並且也列出一些使用 makefile 在編譯 Dockerfile 的時候經常會用到的範例.

基礎常見語法:

wildcard

透過 wildcard 可以擴展找出所有匹配的項目.

找出所有具有 Dockerfile 的目錄(並且依序排列)

DOCKERFILE_PATHS := $(sort $(wildcard */Dockerfile))

patsubst 替換字串

常用再換掉路徑,去除路徑.以下紀錄幾個常用的.

取得 Parent Path (ex: a/b/c/d –> a/b/c)

PARENT_PATHS := $(patsubst %/,%,$(dir $(CURRENT_PATHS)))

nodir 去除所有目錄

這個可以幫你去除所有目錄,剩下檔名. ex: a/b/c/d –> d

取得上一層目錄列表

PARENT_PATH_LIST := $(notdir $(dir $(CURRENT_PATHS)))

這裡也要解釋一下, dir 會取得目錄而已.跟 nodir 剛好相反.

另外, basenamedir 也不同.

$(basename a/b/c/d.a) —> d

進階用法 *, %$*$<

這邊講解起來會有點難懂,就用一個案例來講解.

  • $* 會找出所有結果
  • % 會將前方變數帶給之後用
  • $< 列出前面的結果

以下用個例子

範例(1) : 找出 Dockerfile 並且編譯

build-image-%: %/Dockerfile $(shell find $* -type f)
	time docker build  \
		--tag docker.io/$(YOUR_PROJECT)/%:master \
		--file $< \
		$(dir $<)

這個會去編譯某個你輸入底下的 Dockerfile .

舉例而言: 你有個目錄 tensorflow/Dockerfile 你就要輸入 make build-image-tensorflow ,他就會自動找出這個 Dockerfile 並且編譯名稱為 $(YOUR_PROJECT)/tensorflow:master 以下透過這個案例解釋每個用法:

  • % 會將前面輸入的,帶到後面.在這裡也就是 tensorflow 帶到第二個與第三個出現%的地方
  • $< 會列出 shell find $* -type f 結果,也就是列出所有檔案,並且符合 %/Dockerfile 也就是如果你有其他檔案舉例為 tensorflow/README.md 也不會列出.

似乎這樣好像很麻煩? 其實透過前面介紹的基礎常見語法,可以更方便編譯.

範例(2) : 找出所有符合目錄直接帶到以上編譯

#find all docker files
DOCKERFILES := $(sort $(wildcard */Dockerfile))

#extract dir name
DIRS := $(patsubst %/Dockerfile,%,$(basename $(DOCKERFILES)))

#remain only dir name list
NAMES := $(notdir $(DIRS))

#add prefix combine to function strings
TARGETS := $(addprefix build-image-,$(NAMES))

#get all functions and run it.
all: $(TARGETS)

舉例而言,你有以下目錄結構

  • a/README.md
  • b/Dockerfile
  • b/README.md
  • c/Dockerfile
  • d/test.c

你現在只要輸入 make all 就會自動把 b/Dockerfile 與 c/Dockerfile 找出來,並且組成字串 build-image-b build-image-c 然後呼叫到範例(1)來呼叫兩個 docker build

Reference

[TIL][vgo] 對於 Version and Go 相關詳解(part1)

目錄:

摘要

vgo 是 Golang 將在 1.11 提出的新功能.提供著套件的管理與版本的控制.

本篇文章會解釋 vgo (versioning go) 與 dep 在 sub-package的挑選上有什麼不同. 並且解釋出 vgo 如何解決掉大家的問題. 並且在 Go versioning 的準則 (principles) 上, Russ Cox 有列出以下的準則:

  • Compatibility
  • Repeatability
  • Cooperation

接下來,我會整理一下近期學習的經驗.試著讓各位能在這篇文章中了解.

Compatibility

這邊講的是套件在開發上的”兼容性”,他也很強調所謂的 “Semantic Import Versioning” . 也就是如同上圖所顯示的部分一樣,任何的產品與套件都應該遵循以上的版本法則.

  • Major version: 具有向後不相容的變動,就要變更.
  • Minor version: 當有新的功能加入,就要變更.
  • Patch version: 只是問題的修復.

在這裡,只要是 Major version 是一樣的話,就不應該產生有任何向後不相容的變動.也建議不要有 API 的版本變動.

Repeatability

為了讓每個使用軟體(或是套件)上能夠讓每個人在任何時間都能夠透過相同的程式碼與相同的套件版本來使用.

Opening keynote: Go with Versions - GopherConSG 2018 演講的時候 , Russ Cox 曾經提到一個很重要的概念.

What is software engineering?

Software engineering is what happens to programming when you add time and other programmers.

也就是說 Software Engineering 是經過一段時間的開發,並且是跟其他人一起開發. 所以來說”版本的可重複性”(Repeatability) 就格外的重要.

  • 你必須要在半年後接手開發的人,能夠拿到跟你目前一樣狀態的品質與原始碼.
  • 你也必須要讓其他人不論本地端是否有預裝哪些套件,也要能夠拿到相同的代碼

在提到其他的部分之前,我們得提一下跟 Repeatability 相反的部分. Low-Fidelity Builds

Low-Fidelity Builds

這裡解釋一下,何謂 “Low-Fidelity Builds” .並且解釋為何 vgo 能夠達成 High-Fidlity Build.

Low-Fidelity Builds (低忠誠度的版本),也就是表示你的版本控管並不嚴謹.使得你的套件在版本變更的時候,會讓你的產品穩定度低下.

假設我們開發套件 A ,裡面使用到 B 與 C 套件.假設 A 必須要使用到 B1.2 與 C1.2 才能正常運作.

範例 1: 使用 go get

當你使用 go get 他會檢查目前 GOPATH 資料夾內是否有相關套件, 條件如下:

  • 當套件存在的時候,他會直接使用該套件(不論版本是否新舊)
  • 當套件不存在的時候,會抓下最新的套件.

問題:

當你 GOPATH 裡面有 B1.1 這時候跑 go get 就不會更新套件,而造成你在跑的時候可能會造就 build fail 的狀態.

範例 2: 使用 go get -u

使用 go get -u 會無條件將所有使用的套件更新到最新版本,這並不是代表沒有問題的.

問題:

如同以上的圖示,如果執行到 go get -u 就會抓下最新的套件 B 與 套件 C .也就是說會抓下 B1.2C1.3 .由於套件 A 在開發的時候,並沒有測試過 C1.3 這個版本的套件,這時候可能會造成錯誤的產生.

結論

所以可以看得出來,不論是原生的 go get -d 或是更新套件 go get -u 的方式.透過這些方式所產生的套件管理都是具有低忠誠度的版本控管.

接下來會來解釋,透過 vgo 能夠如何來管理套件的版本並且解決原始 go get 所帶來的問題.

接下來會帶到 vgo 如何透過 Minimal Version Selection 來解決這樣的問題.

下次文章會開始解釋 MVS (Minimal Version Selection)

Reference

[TIL][GIT] How to correctly separate subdirectories from git repo

Problem

If you have big repo, you want to separate it into several small repos.

There are two approach you might google it, here is different

Subtree

git subtree split -P feature_a -b "branchA"

It will separate your code, but it will include whole git history. It will slow-down your CI/CD flow if your original repo history is very huge.

Filter-Branch

which rewrites the repo history picking up only those commits that actually affect the content of a specific subdirectory. (refer to refer 2)

git filter-branch --prune-empty --subdirectory-filter SUBDIR -- --all

Reference

[Slides] Consistent Hashing: Algorithmic Tradoffs

這幾天閱讀 Damian Gryski 的 blog post “Consistent Hashing: Algorithmic Tradeoffs” 整理出來的投影片 (第一版)

應該會找時間寫寫中文 blog

Consistent hashing algorithmic tradeoffs from Evan Lin

[GTG30] Introduce vgo

放上這次再 GTG (Golang Taipei Gathering 30)聚會的投影片,主要是介紹可能會放入 go 1.11 的新功能 vgo

GTG30: Introduction vgo from Evan Lin

[Kubernetes] GPU resource names in Kubernetes between Accelerators and DevicePlugin

Two ways to enable GPU in Kubernetes:

If you want to enable GPU resource in Kubernetes and want Kubelet to allocate it. You need config it as following ways:

  • Kubernetes 1.7: Using NVidia container and enable Kuberlet config feature-gates=Accelerators=true
  • Kubernetes 1.9: Using Device Plugin with Kuberlet specific config feature-gates=DevicePlugins=true

Check node if it has GPU resource:

Using kubectl command kubectl get node YOUR_NODE_NAME -o json to export all node info as json format. You should see something like:

## If you use Kubernetes Accelerator after 1.7
  "allocatable": {
        "cpu": "32",
        "memory": "263933300Ki",
        "alpha.kubernetes.io/nvidia-gpu": "4",
        "pods": "110"
    },

Detail defined in k8s.io/api/core/v1/types.go

## If you use Kubernetes Device Plugin after 1.9
  "allocatable": {
        "cpu": "32",
        "memory": "263933300Ki",
        "nvidia.com/gpu": "4",
        "pods": "110"
    }, ## Reference: