Recently, I’ve encountered a challenge with my aging CircleCI pipeline used for deploying our legacy application. The issue arises whenever I make modifications to a pipeline step: the cache invalidates, forcing the entire process to start from scratch. This has led to complications, particularly with the use of an outdated image that has surfaced during builds.

The repository ‘http://dl.google.com/linux/chrome/deb stable InRelease’ is not signed.

How to Fix

Just add the step `Linux Package Signing Keys` as mentioned in https://www.google.com/linuxrepositories/ before apt update or apt-get update

Since I’m using new debian version then I can use the following command (copy from instruction in the link above)

wget -q -O — https://dl.google.com/linux/linux_signing_key.pub | sudo tee /etc/apt/trusted.gpg.d/google.asc >/dev/null`

Done.

References

1. https://support.google.com/chromebook/thread/257688390/the-repository-http-dl-google-com-linux-chrome-deb-stable-inrelease-is-not-signed
2. https://www.google.com/linuxrepositories/

The repository ‘http://dl.google.com/linux/chrome/deb stable InRelease’ is not signed. was originally published in GiVeR on Medium, where people are continuing the conversation by highlighting and responding to this story.

What’s Locking Your GPG Signature? A Simple Fix

Use ps aux | grep gpg to find the process locking GPG. If no process is found, a dangling .lockfile is often the culprit. Simply find and delete the lock file to resolve the issue.

$ gpg --list-secret-keys --keyid-format LONG
gpg: Note: database_open 134217901 waiting for lock (held by 30991) ...
gpg: Note: database_open 134217901 waiting for lock (held by 30991) ...
gpg: Note: database_open 134217901 waiting for lock (held by 30991) ...
gpg: Note: database_open 134217901 waiting for lock (held by 30991) ...
gpg: Note: database_open 134217901 waiting for lock (held by 30991) ...
gpg: keydb_search_first failed: Operation timed out

$ cd ~/.gnupg/public-keys.d
$ ls -al

.rw-------@ 82k tanin 19 Aug 17:23 pubring.db
.rw-r--r--@  38 tanin 12 Sep 16:09 pubring.db.lock

$ rm pubring.db.lock

gpg: Note: database_open 134217901 waiting for lock (held by 30991) … was originally published in GiVeR on Medium, where people are continuing the conversation by highlighting and responding to this story.

คำสั่งไหนที่ควรใช้? คำสั่งไหนที่เลิกใช้แล้ว? บทความนี้มีคำตอบพร้อมตารางเปรียบเทียบชัดๆ สำหรับนักพัฒนาทุกคน

สำหรับนักพัฒนาที่ใช้ Git เป็นประจำ คำสั่ง git stash ถือเป็นเครื่องมือช่วยชีวิตในยามที่ต้องสลับ Branch กะทันหัน แต่ยังไม่พร้อมที่จะ commit โค้ดที่ทำค้างไว้ แต่คุณเคยสงสัยไหมว่าระหว่าง git stash save กับ git stash push ที่หน้าตาคล้ายกัน มันต่างกันอย่างไร และเราควรจะเลือกใช้อันไหนกันแน่?

บทความนี้จะไขข้อข้องใจทั้งหมด เปรียบเทียบให้เห็นภาพชัดๆ และฟันธงไปเลยว่าคำสั่งไหนคือตัวเลือกที่ดีที่สุดสำหรับคุณในปัจจุบัน

git stash save: คำสั่งดั้งเดิมที่ถึงเวลาต้องปล่อยวาง

git stash save คือคำสั่งดั้งเดิมที่หลายคนอาจจะคุ้นเคยกันดี มันทำหน้าที่ของมันได้ตรงไปตรงมา นั่นคือการบันทึกการเปลี่ยนแปลงทั้งหมดใน Working Directory ของคุณเข้าไปเก็บไว้ใน Stash

# ตัวอย่างการใช้งานแบบดั้งเดิมพร้อมข้อความ
git stash save "WIP: กำลังทำฟีเจอร์หน้าแรก"

แม้จะยังใช้งานได้ แต่ใน Git เวอร์ชันใหม่ๆ คำสั่งนี้ถูกจัดว่าเป็น Deprecated หรือ “ไม่แนะนำให้ใช้งานแล้ว”

ข้อจำกัดสำคัญของ save คือ: มันขาดความยืดหยุ่น คุณไม่สามารถเลือกได้ว่าจะ stash เฉพาะบางไฟล์หรือบางโฟลเดอร์ เมื่อสั่ง save มันจะกวาดทุกการเปลี่ยนแปลงที่คุณยังไม่ได้ commit ไปเก็บไว้ทั้งหมด ซึ่งบางครั้งก็ไม่ใช่สิ่งที่เราต้องการ

git stash push: คำสั่งใหม่ที่ทรงพลังและยืดหยุ่นกว่า

git stash push คือคำสั่งที่ถูกพัฒนาขึ้นมาใหม่เพื่อแทนที่ save และเป็นคำสั่งที่ แนะนำให้ใช้เป็นมาตรฐานในปัจจุบัน มันไม่ได้แค่ทำทุกอย่างที่ save ทำได้ แต่ยังมาพร้อมความสามารถที่สำคัญอย่างยิ่ง

ความสามารถเด่นที่สุดของ git stash push คือการรองรับ Pathspec ซึ่งทำให้เราสามารถระบุได้ว่าจะ stash เฉพาะไฟล์หรือโฟลเดอร์ที่ต้องการเท่านั้น

ลองดูตัวอย่างการใช้งาน:

# Stash เฉพาะการเปลี่ยนแปลงในไฟล์ main.js และโฟลเดอร์ components/
git stash push -m "Update main logic and components" -- src/main.js src/components/# Stash เฉพาะการเปลี่ยนแปลงในไฟล์ main.js และโฟลเดอร์ components/  

การใช้ flag -m เพื่อใส่ข้อความก็เป็นรูปแบบที่สอดคล้องกับคำสั่งยอดนิยมอย่าง git commit -m "..." ทำให้ไวยากรณ์ของ Git มีความสอดคล้องกันมากขึ้น

ตารางเปรียบเทียบชัดๆ: save vs push

บทสรุป: ฟันธงให้เลยว่าควรใช้อะไร

คำตอบนั้นชัดเจนมากครับ: คุณควรใช้ git stash push เสมอ

ในเมื่อ git stash push สามารถทำทุกอย่างที่ save ทำได้ แถมยังมอบความยืดหยุ่นที่เหนือกว่าด้วยฟีเจอร์ Pathspec จึงไม่มีเหตุผลที่จะย้อนกลับไปใช้คำสั่งที่เก่ากว่าและมีความสามารถน้อยกว่าอีกต่อไป

การเปลี่ยนนิสัยมาใช้ git stash push ตั้งแต่วันนี้ จะช่วยให้คุณจัดการกับโค้ดที่พักไว้ได้อย่างมีประสิทธิภาพและแม่นยำมากขึ้นแน่นอนครับ

หากคุณชอบบทความนี้ อย่าลืมกด “Clap” 👏 และกดติดตามเพื่อไม่พลาดเนื้อหาดีๆ เกี่ยวกับการพัฒนาซอฟต์แวร์นะครับ!

Git Stash: push vs save — เลิกสับสน แล้วเลือกใช้ให้ถูกในปี 2025 was originally published in GiVeR on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR

git rebase -i HEAD~<number-of-commits>

# Mark the commit you want to edit by changing pick to edit in the list of commits that appears.

git commit --amend --author="Your Name <email@domain.com>"

Long Story

Lately, I realized that I have multiple credentials on my computer, requiring me to alternate between personal and company projects. I noticed that my personal email was unintentionally used in my pushed commits when opening the PR. Subsequently, I had to investigate the issue. Upon inspection, I discovered the necessity of configuring my git to local settings instead of global settings.

It also have several ways to do like below

1. Using git local config

ref: https://stackoverflow.com/a/73658922/1890430

git config --local credential.helper ""
git push origin master
# It asks for username and password for current repo.

Or specific user/e-mail on the local repo manually

# Using text editor to put user and e-mail
git config --local -e

# OR 

git config user.name "Your Name"
git config user.email your@domain.com

2. Using git specific configuration

[includeIf "gitdir:~/Documents/projects/my-company-repo"]
  path = ~/.gitconfig-work

# The contents of this file are included only for GitLab.com URLs
[includeIf "hasconfig:remote.*.url:https://gitlab.com/**"]
  path = ~/.gitconfig-work

# .gitconfig-work
[user]
name = Your Name
email = name@domain.com

In case you missed to commit already

Using the follow method in the link

Git change name or email in commit history

git config alias.change-commits '!'"f() { VAR=\$1; OLD=\$2; NEW=\$3; shift 3; git filter-branch --env-filter \"if  \\\"\$\`echo \$VAR\`\\\" = '\$OLD' ; then export \$VAR='\$NEW'; fi\" \$@; }; f "
git change-commits GIT_AUTHOR_NAME "<Old Name>" "<New Name>" -f
git change-commits GIT_AUTHOR_EMAIL <old@email.com> <new@email.com> -f
git change-commits GIT_COMMITTER_NAME "<Old Name>" "<New Name>" -f
git change-commits GIT_COMMITTER_EMAIL <old@email.com> <new@email.com> -f

Update the author name and email for a previously pushed Git commit was originally published in GiVeR on Medium, where people are continuing the conversation by highlighting and responding to this story.

วันนี้เราจะมาอยู่กับ Basic Container และ Docker กันต่อเนื่องจากสัปดาห์ที่แล้วนะครับ ส่วนตอนก่อนหน้า อ่านตาม Link ข้างล่างได้เลยครับ

• [สรุป] The Cloud Camp 2024 — Audition Round 2 (Day 2/ 3)
• [สรุป] The Cloud Camp 2024 — Audition Round 2 (Day 1/ 3)

Container Origin

• Concept มันก็มาจาก Container จริงๆ นั่นแหละอย่างที่เราเห็นตามรูปเรือที่มีตู้ Container วางอยู่แบบนั้นเลย
• ของที่เราจัด (Pack) อยู่ในตู้ Container มันจะเพิ่ม เปลี่ยน หรือเอาของข้างในตู้ออกไม่ง่าย เพราะว่ามันถูกจัดให้พอดีสุดๆ ให้ขนสินค้าไปได้มากที่สุด โดยหลักการแล้ว การเอา Container มาอีกอัน แล้วย้ายเอาของข้างในไปใส่อีกตู้ดูท่าจะเหมาะสมและเร็วกว่า ก็เลยเป็นที่มาว่าการสร้าง Container ใหม่ทุกครั้งที่มีการเปลี่ยนแปลงย่อมสะดวกและง่ายกว่าแก้ไขของเดิม ซึ่งก็ตรงกับที่ว่า ถ้าเรามีการปรับเปลี่ยนอะไรใน Container Image เดิมก็จะเกิด Container Image ID ใหม่ทุกครั้ง

Application Deployment Process (Recap.)

Containerize and Application

หลักการคือ การเอา Application ที่พร้อมรัน เอาไปใช้บน Server พร้อมใช้ ตามรูปนี้เลย

ทบทวนความเข้าใจกับ Docker กันหน่อย

• Docker คือ Platform ที่ทำให้เราใช้งาน Application ในลักษณะของ Conainer ได้ สรุปได้ว่า Docker = Container Platform
• Docker ประกอบด้วย containerd กับ runc
• Docker != Container Runtime แต่ใช้ containerd ในการรัน Container
• containerd ใช้ runc ในการรัน Container จริงๆ

สรุปได้ว่าในการทำงาน Docker จะใช้ containerd เป็น backend ในการจัดการคอนเทนเนอร์ และ containerd จะใช้ runc เพื่อรันคอนเทนเนอร์แต่ละตัว

คำถามจากทางบ้าน

🙋 Portrainer คืออะไร

เป็น Container Management Software โดยจากคำนิยมจากตัว Software Portainer เอง เขาบอกว่า “Portainer is your container management software to deploy, troubleshoot, and secure applications across cloud, datacenter, and Industrial IoT use cases.”

🙋Kubernetes (K8s) ใช้ทำอะไร จำเป็นต้องใช้ Docker หรือเปล่า

K8s ไม่จำเป็นต้องใช้คู่กับ Docker เสมอไป แต่เนื่องจากแต่ก่อน Docker เคยถูกใช้เป็น Container Runtime (containerd + runc) คู่กับ K8s มาอย่างช้านาน แต่สุดท้ายทาง K8s ก็เข้าร่วมมาตรฐาน CRI (Container Runtime Interface) และเลือกใช้ containerd เป็นตัวเริ่มต้น โดยไม่ได้พึ่งพา Docker Ecosystem อีกต่อไป โดยเริ่มตั้งแต่ K8s v1.2.0

🙋Helm คืออะไร

Helm เป็นเครื่องมือจัดการแพ็กเกจ (package manager) สำหรับ K8s ซึ่งมีบทบาทสำคัญในการทำให้การจัดการแอปพลิเคชันบน K8s ง่ายและมีประสิทธิภาพมากขึ้น โดย Helm ช่วยในการติดตั้ง, อัปเดต, และจัดการ lifecycle ของแอปพลิเคชันที่ทำงานบน k8s มองง่ายๆ ก็เหมือนคนใช้ NodeJS แล้วมี npm หรือ yarn ให้ใช้ประมาณนั้นเลย

Helm is a tool for managing Charts. Charts are packages of pre-configured Kubernetes resources. — Helm

จากรูปบน เราทำการ Build ทั้ง Software Package ให้อยู่ในรูปแบบของ Container Image เพื่อเป็นแม่แบบให้ Container Runtime ไป Deploy ในรูปแบบของ Container Instance

Container Deployment

จากที่กล่าวข้างต้นคือ หลังจากที่เราได้ Container Image แล้ว เราก็จะนำส่งเจ้าตัว Container Image (เรียกสั้นๆ ว่า “Image”) ไปยัง Server ที่มีเจ้าตัว Container Runtimes อยู่ เพื่อนำไปปรับแต่งต่อเพื่อทำการรันเจ้าตัว Image ของเราที่เป็นแม่แบบ ออกไปอยู่ในรูปแบบ Instance

Check Point #1

1. เข้าใจที่มา ที่ไปของตู้ Container และ Container Technology
2. เข้าใจว่า Container เข้ามาแก้ปัญหาอะไร
3. รู้จักกระบวนการ Containerization
4. เข้าใจและสามารถอธิบายพื้นฐานของ Container ได้
4.1 เข้าใจและสามารถอธิบาย Container Runtime ได้
4.2 เข้าใจและสามารถอธิบาย Container Image ได้
4.3 เข้าใจและสามารถอธิบาย Container Instance ได้

Containerization Characteristic

1. Isolation — ตัว Container จะทำการแยกตัว environment ออกจากตัว Application เพื่อให้แน่ใจว่าแต่ละ Container ทำงานได้อย่างอิสระ
2. Portability — ทำงานได้ทุกที่ที่มี Container Runtime มาตรฐาน Container R
3. Consistency — รันทุกที่ได้ผลแบบเดียวกันภายใต้เงื่อนไขตัว Container ตัวเดียวกัน
4. Efficiency — ตัว Container จะเบากว่าการใช้ VM แบบดั้งเดิมมาก เพราะว่าใช้แค่ระดับ Kernel แทนที่จะใช้แบบ Full OS
5. Scalability — เพราะว่าเล็กและ Portable ดังนั้นมันจะสามารถ Scale up/down ได้งานและรวดเร็วบน Cloud Native Application

Docker Components

Docker Host

คือระบบหรือเครื่องที่รัน Docker Engine และจัดการทุกอย่างที่เกี่ยวข้องกับคอนเทนเนอร์ ตั้งแต่การสร้าง การจัดการ จนถึงการรันคอนเทนเนอร์ทั้งหมด เป็นสภาพแวดล้อมที่ Docker components อื่น ๆ ทำงานอยู่ โดย Docker Engine และ Docker Containers ถูกติดตั้งและดำเนินการภายใน Docker Host

Docker Daemon (dockerd)

Docker Daemon หรือ dockerd เป็นส่วนประกอบสำคัญของ Docker Engine ที่ทำงานอยู่บน Docker Host มีหน้าที่รับคำสั่งจาก Docker Client และ API เพื่อจัดการการสร้าง, การรัน, การหยุด และการลบคอนเทนเนอร์ รวมถึงการจัดการ Docker images, networks และ volumes.

Docker Registries

คือสถานที่ใช้เก็บ แชร์ และดาวน์โหลดเจ้าตัว docker image ซึ่งสามารถเป็นได้ทั้ง public หรือ private (ใช้ username/password)โดย default จะชี้ไปยัง hub.docker.com

Check Point #2

1. เข้าใจส่วนประกอบต่างๆ ของ docker architecture ได้เป็นอย่างดี
1.1 Docker Client / Docker CLI ทำหน้าที่อย่างไร
1.2 เข้าใจความหมายของคำว่า Host
1.3. Docker image ทำหน้าที่อย่างไร
2. รู้จัก Container Registry
2.1 Local Registry
2.2 Cloud Registry -> Public / Private
3. Docker Daemon / Docker Server ทำหน้าที่อย่างไร

Docker Client และ Docker CLI

เป็นคำที่บางครั้งใช้แทนกันได้ แต่ในบริบท (Context) ของ Docker นั้นมีหน้าที่ที่ค่อนข้างเหมือนกันและมักจะถูกใช้ร่วมกันเพื่ออธิบายการสื่อสารระหว่างผู้ใช้งานกับ Docker Daemon โดยส่วนใหญ่คนมักเข้าใจว่า Docker Client คือ GUI และ Docker CLI ก็คือ CLI Command-line ตรงตัว

Docker Daemon กับ Docker Server ทำหน้าที่อย่างไร

ต้องบอกก่อนว่า บางคนก็เรียก Docker Daemon ว่า Docker Server ซึ่งก็คือสิ่งเดียวกันนั่นแหละ ไปอ่านได้ในหัวข้อด้านบน “Docker Daemon (dockerd)”

Docker Management

หัวข้อนี้ไม่มีอะไรมาก ลองเล่นดูแล้วจะรู้

Container Instance Managements

• docker run
• docker start
• docker stop
• docker kill

Monitoring & Troubleshooting

• docker ps, docker exec, docker logs
• docker pull, docker images

Container Images Managements

• docker rm, docker rmi, docker system prune
• docker login, docker build, docker push

Basic CI/CD

Continuous Integration (CI)

CI is all about verifying your code!

• Continuous + Integration
• รวมความเปลี่ยนแปลงบ่อยๆ
• เราต้องมีการตรวจสอบ (verify) ว่าโค้ดอันนั้นทำงานได้อย่างถูกต้อง

Continuous Delivery (CD)

• เป็นการนำกระบวนการ (process) หลายๆ ตัวเข้ามาใช้เพื่อ “ทำให้ Software Engineer” หลายๆ คนพัฒนา Software ได้มีคุณภาพมากขึ้น และได้สร้างสรรค์ผลงานได้อย่างที่ต้องการ
• เพื่อทำให้ทีมสามารถ release การเปลี่ยนแปลงได้อย่างปลอดภัย (Safely) รวดเร็ว (Quickly) และยั่งยืน (Systainably)
• เพื่อพิสูจน์ว่าการเปลี่ยนแปลงนั้นสามารถถูก Deploy ได้หลายครั้ง
• เพื่อทำการให้เกิดกระบวนการอัตโนมัติในการนำส่ง Software ออกไปใช้งาน (Automating Release Processes)

ส่วนประกอบของ CD มีอะไรบ้าง

Lining (ได้ Verifed Source Code)

• Source Code → Check / Lint → Source Code (verified)

Testing (Quality Gate) (ได้ Tested Source Code)

• Source Code → Check / Lint → Source Code (verified) → Test → Source Code (tested)

Building (ได้ Executable File)

• Source Code → Check / Lint → Source Code (verified) → Test → Source Code (tested) → Compile / Interpret → Executable File

Publishing (ได้ Container Image)

• Source Code → Check / Lint → Source Code (verified) → Test → Source Code (tested) → Compile / Interpret → Executable File → Build → Container Image

Deploying (ได้ Container Instance)

• Source Code → Check / Lint → Source Code (verified) → Test → Source Code (tested) → Compile / Interpret → Executable File → Build → Container Image → Run → Container Instance

Checkpoint #1

1. เข้าใจกระบวนการของ CD
2. เข้าใจกระบวนการของ CI

Checkpoint #2

1. เห็นภาพรวมทั้งหมดของ CD
2. สามารถ Mapping แต่ละขั้นตอนในการสร้าง Apllication ออกมาเป็น Pipeline ได้
3. เข้าใจความแตกต่างระหว่าง CI/CD

จบแล้วจร้ากับ Basic Concept ที่เรียนมาตลอด 3 วัน

[สรุป] The Cloud Camp 2024 — Audition Round 2 (Day 3/ 3) was originally published in GiVeR on Medium, where people are continuing the conversation by highlighting and responding to this story.

กลับมาต่อกันในวันที่ 2 นะครับ

ขอเกริ่นก่อนนะครับ พวก Basic Linux Command Fundamental และ VI Editor วันนี้ก็มีสอนเหมือนกัน แต่ผมขออนุญาตข้ามนะครับ เพื่อความกระชับของเนื้อหา

พวก Linux Command พื้นฐานก็ไปหาได้เยอะแยะ ตัวอย่างเช่น https://www.hostinger.com/tutorials/linux-commands

Vi Cheatsheet
https://vim.rtorr.com/

สำหรับคนที่พื้นฐาน Linux ไม่แน่น นอกจากที่เรียนใน Class แล้ว แนะนำลองหาจากที่อื่นดู และทบทวนมากขึ้นตามเทคนิค “Spaced Repetition” หรือ การทบทวนแบบเว้นระยะ ซึ่งก็คือ การอ่านหรือและเว้นช่วงพักอย่างสม่ำเสมอ แล้วค่อยกลับมาทบทวนใหม่ ช่วงพักเว้นนี้อาจหมายถึง จากครั้งแรกที่อ่าน เว้นหนึ่งวันกลับมาทบทวนใหม่ ไล่เป็นเว้นสองวัน เว้นสามวัน การทำแบบนี้ค้นพบว่าการเว้นระยะในการทบทวนช่วยลด “โค้งการลืม” ได้ ถ้ายกตัวอย่างก็

สมมติว่าเด็กคนหนึ่งเรียนรู้คำว่า “แอปเปิ้ล” ในวันนี้

• วันนี้ทบทวนคำว่า “แอปเปิ้ล” สองสามครั้ง
• วันพรุ่งนี้หรืออีกสองวัน ทบทวนคำว่า “แอปเปิ้ล” อีกครั้ง
• อีกหนึ่งสัปดาห์ ทบทวนคำว่า “แอปเปิ้ล” อีกครั้ง

การทบทวนแบบนี้ช่วยให้เด็กจำคำว่า “แอปเปิ้ล” ได้ดีกว่าและนานกว่า

Linux in General

Linux Kernel 4 Majors Task

1. Memory Management
2. Process Management
3. Device Drivers
4. System Calls and Security — คุยกับ Hardware ยังไง หรือมีสิทธิ์ในการใช้งานยังไง

Tips

เราสามารถใช้ strace -c ls เพื่อใช้ดูว่า คำสั่ง “ls” มี system call เป็น trace อะไรบ้าง

Kernel Space and User Space

Working with Hardware

ขอ note เฉพาะคำสั่งที่ปกติ user ทั่วไปไม่ค่อยได้ใช้ แล้วพูดถึงใน class เรียนเน้อ

• ใช้คำสั่ง lscpu ดู CPU spec
• ใช้คำสั่ง lsmem ดู Memory spec

Linux Boot Sequence

1. BIOS POST (Basic Input/Output System Power-On Self Test)
   - เมื่อคอมพิวเตอร์เปิดขึ้น BIOS จะทำการตรวจสอบฮาร์ดแวร์พื้นฐาน เช่น RAM Harddisk และอุปกรณ์อื่นๆ
   - หลังจากตรวจสอบแล้ว BIOS จะค้นหาอุปกรณ์บูต (เช่น ฮาร์ดดิสก์, USB, CD/DVD) เพื่อโหลด Boot Loader
2. Boot Loader (GRUB2 — GRand Unified Bootloader 2)
   จะทำการโหลดและแสดงเมนูบูตให้ผู้ใช้เลือกว่าต้องการบูตเข้าสู่ระบบปฏิบัติการใด (ถ้ามีหลายระบบปฏิบัติการ)
3. Kernel Initialization
   - หลังจาก Kernel ถูกโหลดเข้าสู่หน่วยความจำ Kernel จะทำการตรวจสอบและติดตั้งไดรเวอร์ฮาร์ดแวร์ทั้งหมด
   - Kernel จะตั้งค่าระบบไฟล์ root (root filesystem) และเปิดใช้งานกระบวนการแรกของระบบ (initial process) ซึ่งมักจะเป็น init หรือ systemd
4. INIT Process (Systemd)
   - ระบบ systemd จะทำการจัดการกระบวนการบูตที่เหลือทั้งหมด
   - systemd จะเริ่มการทำงานของบริการพื้นฐาน (services) ต่างๆ เช่น การตั้งค่าเครือข่าย การติดตั้งระบบไฟล์เพิ่มเติม และการเริ่มต้นการบริการระบบ (system services)
   - หลังจากนั้น systemd จะเริ่มโปรแกรมการเข้าสู่ระบบ (login prompt) ทำให้ผู้ใช้สามารถเข้าสู่ระบบและเริ่มการใช้งานเครื่องคอมพิวเตอร์ได้

File Types in Linux

⚠️ ข้อควรระวัง ⚠️

Hard Links เวลาลบร่างโคลน ตัว original หรือต้นทางก็หายด้วยนะ เพราะว่าชี้ไปที่ inode เดียวกัน (อันนี้ low-level หน่อยนะ คนที่เรียนวิชา Operating System น่าจะเข้าใจ)

Package Manager

• APT (Advanced Package Tool) — พัฒนาโดย Debian Project สำหรับจัดการแพ็คเกจในระบบปฏิบัติการ Debian และ Ubuntu ตัวอย่าง
  👉 apt search
  👉 apt-cache search
  👉 apt install search
  👉 apt list — upgradable เพื่อให้ดู package ไหนสามารถ upgrade ได้บ้าง
• YUM (Yellowdog Updater, Modified) — พัฒนาโดย Yellowdog Linux (YDL) และใช้เป็นหลักใน Red Hat-based distributions เช่น Red Hat Enterprise Linux (RHEL), CentOS, และ Fedora
• DNF (Dandified YUM) — ถูกพัฒนาขึ้นมาเป็นการปรับปรุง YUM โดย Red Hat
• APK (Alpine Package Keeper) — พัฒนาโดย Alpine Linux

Basic Observability

Application Characteristic

• Program Process
• Application Building
• Application Output
• Application Package Manager

Program Process

• Programming = Coding + Problem Solving
• Application Building — Source Code เขียนให้มนุษย์เข้าใจ ก่อนที่จะถูกแปลงไปเป็นภาษา computer และกลายเป็น executable file หรือ application
• Program = Collection of Instructions — ชุดหรือกลุ่มของคำสั่ง
• แบ่งออกเป็น 2 รูปแบบ
  1) Batch Program — ทำงานให้เสร็จโดยไม่ต้องการ User Interaction หรือรอ External Event และทำงานเป็นลำดับขึ้นจนเสร็จ
  2) Event-Driven or Interactive Program — รอรับการทำงานตลอดเวลาเมื่อมีเหตุการณ์ (Event) เกิดขึ้น เช่น API call, กดปุ่ม และจะหยุดการทำงานเมื่อได้รับทำสั่งให้หยุด

Program vs Application

• (Computer) Program = ชุดคำสั่งที่ถูกนำไปทำงานโดยคอมพิวเตอร์
• Application = ตัวโปรแกรม (Computer Program) ที่ถูกออกแบบมาให้สำหรับผู้ใช้ (End Users)

Application Building

JIT = Just in Time
AOT = Ahead of Time

Executable file

กลุ่ม OS Executable

• เกิดจากกลุ่ม System Programming Language
• พวก binary file ทั้งหลาย เช่น .exe บน Windows และไม่มีนามสกุลบน *nix เป็นต้น

กลุ่ม Application Package

• เกิดจากกลุ่ม High-level Programming Language
• ต้องการตัว Runtime เช่น .jar, .war ของ Java ที่ต้องการ JDK (JRE and JVM) ในการใช้งาน หรือฝั่ง Javascript (.js) ที่ต้องการ NodeJS (V8) ในการรันคำสั่ง

Trend Application Programming with OS Executable

Pros

• ไม่ต้องการตัว Runtime
• เบาสบาย
• ประสิทธิภาพสูงเพราะว่า มันเป็นภาษาเครื่องเลยไม่ต้องผ่านตัวแปลภาษา

Cons

• ต้อง compile ไปให้ใช้งานกับทุก platform และ architecture ทั้งหมดที่ใช้ทีละตัว

ตัวอย่างของการพยายามแปลงพวก Runtime เป็น Executable file ก็

• NodeJS มี Node Single Executable
• Java มี GraalVM

Application Output

• Logs เช่น Grafana loki, Elasticsearch
• Traces เช่น Grafana Tempo, Elastic APM
• Metrics เช่น Grafana Mimir, Prometheus

Application Package Manager

• Source Code
• Code Translation
• Executable file

Observability

• Telemetry = Tele (ไกล) + Metron (การวัด) = กระบวนการส่งข้อมูลจากการวัดจากที่ห่างไกล

สุดท้ายก่อนจบวัน มีการพูดถึงเรื่องที่มาของ Container Technology แต่ผมว่าจะเอาไปรวมกับสัปดาห์แทนละกันจะได้ไม่ครึ่งๆ กลางๆ

[สรุป] The Cloud Camp 2024 — Audition Round 2 (Day 2/ 3) was originally published in GiVeR on Medium, where people are continuing the conversation by highlighting and responding to this story.

เกริ่นนำ

เป้าหมายแรกเริ่มที่อยากเรียนคือ อยาก upskill และ reskill ของที่รู้เมื่อนานชาติมาแล้ว แต่ก็พอไม่ได้ใช้ทุกวัน มันก็ลืมไปแล้ว โดยเริ่มจากพื้นฐานก่อน ก็ได้มาคอส free ปูพื้นฐานของ CNPF โดย Jumpbox ซึ่งก็ได้ลงเรียน มีเวลา 3 วันแหล่ะ ก็พยายาม force ตัวเองให้มาจดโน้ตเนอะ input = output ได้รับเท่าไร ก็จดเท่านั้นแหละ รวมถึงหาข้อมูลเพิ่มเติมด้วย

ยุคนี้คือยุคของ Cloud Native Era

วันแรกที่เรียนต้องปรับ Mindset ในการเรียนรู้ก่อน

1. ต้องให้กำลังใจตัวเอง อย่าใช้ประโยคแนว “อยาก” “จะ” “ต้อง” “ไม่” เพื่อเป็นการปลุกใจตัวเอง อย่าโทษตัวเอง มันไม่มีประโยชน์
2. อย่าไปว่าคนอื่นโง่หรือโทษว่าตัวเองโง่ มีแต่รู้กับไม่รู้ในการเรียนรู้
3. อย่างน้อยถ้าเราได้รู้อะไร ถึงรู้ไม่เท่าคนอื่น อย่างน้อยตัวเราเองก็รู้มากกว่าก่อนที่เราเรียนนั่นแหละ

“พร้อมยอมรับความอ่อนแอ และ เชื่อในตัวเองหรือยัง” กล่าวคือ รู้ยังว่าตัวเองไม่รู้อะไรหรือมีจุดอ่อนอะไร แค่นั้นก็เพียงพอแล้ว

เราเชื่อว่าการเรียนรู้ทำให้ชีวิตคุณดีขึ้น — Jumpbox Team

เข้าเนื้อหา Cloud Native Practitioner Foundamental (CNPF) ต้องรู้อะไรบ้าง

1. Cloud Computing
2. Linux Foundamental
3. Observability
4. Container Foudnamental
5. CI & CD
6. Problem Solving

Cloud Computing

Cloud คืออะไร ทำไมต้องใช้ Cloud

• Cloud คือ Computer ที่อยู่บนโลกนี้สักที่หนึ่งบนโลก
• มือถือเราเครื่อง powerful กว่าเครื่องบางเครื่องบน cloud เสียอีก
• ถ้าพูดถึง Cloud มันต้องหมายถึงการใช้งานทรัพยากรคอมพิวเตอร์ผ่านทาง Internet
• Cloud ทำให้เราไม่จำเป็นต้องมี server หรือ hardware ที่เราต้องดูแลเอง ปล่อยให้ผู้ให้บริการ cloud (Cloud Provider) เป็นคนจัดการแทน
• ถ้าเราใช้เครื่องแล้วทรัพยากรไม่พอ เราก็ Upgrade hardware จากการไปซื้อ hardware โน้นนั่นนี่ แล้วใช้คน upgrade แต่เรามายุคที่อยู่ที่เรียกว่า Cloud (Digital) Transformation ที่สามารถทำระบบ automation หรือ bot เพื่อให้ upgrade เครื่องผ่าน internet ได้
• Cloud Computing — Pay as you go ใช้เท่าไร จ่ายเท่านั้น

Cloud is the on-demand delivery of infrastructure (handware/servers), storage, databases,, and all kinds of application services via the internet

Cloud Characteristics

• Reduce Cost — Pay as you go ใช้เท่าไรจ่ายเท่านั้น
• Unlimited Storage — ในชีวิตอาจจะจำกัดแหละ แต่มันมากพอที่เราไม่ต้องสนใจ
• Scalable — ขยายได้ไม่จำกัด ตราบเท่าที่เรายอมจ่ายเพื่อให้ขยาย
• Security — มีความปลอดภัยตราบเท่าที่ผู้ให้บริการจะทำได้

Cloud Native

“ใช้ความสามารถของ cloud ให้เกิดประโยชน์สูงสุด” — Use cloud in optimized way

• Cloud Native is not only for Application
• Cloud Native มันคือ ERA หรือยุคสมัย
• Cloud Native != Cloud ตัวของมันเองก็ไม่ใช่ cloud นะ
• Cloud Native is more than a toolset
• สามารถใช้เทคโนโลยีที่ใช้จำลองเสมือน Virtualization Technology (Hypervisor) เพื่อทำงานเป็น cloud ได้

ตัวอย่างสุดขำ ถ้าเอาตุ่ม (Jar) มาร่วมกับ Cloud Native มันก็จะออกมาแบบใน clip นี้เลย มีคุณสมบัติ unlimited storage และกันปอบลง (แบบไม่ตั้งใจ ฮ่าๆ)

Cloud Native for XYZ

It is a complete architecture, a philosophical approach for XYZ that take full advantage of cloud computing

ถ้าใครอยากอ่านเพิ่มแนะนำหนังสือ Cloud Native Transformation by Pini Reznik, Jamie Dobson, Michelle Gienow หรือไปอ่านบนเวบ https://www.cnpatterns.org/

Cloud Native Transformation

Cloud Fundamental

• Cloud Characteristics
• Cloud Delivery Models => SaaS, PaaS, IaaS
• Cloud Deployment Models

Cloud Characteristics

1. On Demand Usage — ใช้ตามที่ควรใช้ใจ
2. Ubiquitous Access — คนที่เข้ามา จะไม่เห็น resource คนอื่นในเครื่องเดียวกัน แต่ทุกอย่างใช้พื้นที่เดียวกันแบบไม่รู้ตัว
3. Multi-Tenant — ทุกคนใช้เครื่องร่วมกันทั้งหมด แล้ว Hypervisor จะมาแบ่ง resource ให้เอง
4. Elasticity — การขยายเครื่องแบบ “Pre-Determined” ตัวอย่างเช่น สมมติว่าพรุ่งนี้จะมีขายตั๋วคอนสักรายการนึง แล้วเราประเมินว่าคนจะเข้ามาอย่างล้นหลามตอน 9:00 น. เราก็อาจจะ scale เครื่องรอตั้งแต่ 8 โมงนิดๆ เลยก็ได้สัก 100 เครื่อง แต่ถ้าเกิดแบบเป็น “Runtime” ก็คือเราจะตัดสินใจ scale เครื่องถ้ามันตรงเงื่อนไขที่เรากำหนด เช่น ถ้าสมมติเครื่อง server เรามี CPU Load 50% แล้วก็ค่อยให้เพิ่มเครื่องเข้ามาอีก 1 ตัวเรื่อยๆ จนกว่า CPU เฉลี่ยของเครื่องทั้งหมดต่ำกว่า 50% แบบนี้ ซึ่งเราจะทำได้ ก็ต้องมีตัววัด metrics ของบริการของเรา
5. Measured Usage — เรามีที่ๆ ให้ monitor ปริมาณการใช้งานของระบบเรา ไม่ว่าจะ CPU, Memory ต่างๆ นานา ที่สำคัญควรมีระบบ automation แล้วก็การออก report ด้วย
6. Resiliency — Multi Availabililty Zone (Across Physical Locations), Multi Cloud (ใช้ Cloud Service Provider คนละเจ้าเลย)

Checkpoint #1

• Cloud Characteristic มีอะไรบ้าง แต่ละตัวมีความสามารถอย่างไร
• ลักษณะแบบใดที่ทำให้เกิด Cost Optimization ได้
• ลักษณะแบบใดที่ทำให้สามารถ track สิ่งต่างๆ ที่เกิดขึ้นได้
• ลักษณะแบบใดที่ทำให้เกิด High Availability
• ลักษณะแบบใดที่ทำให้เกิด Scalability

Shared Responsibility Model

จากภาพเราจะดูง่ายเลยว่า ส่วนไหนที่ลูกค้ารับผิดชอบ และส่วนใหญ่ผู้ให้บริการ cloud (Cloud Service Provider) รับผิดชอบ

Cloud Delivery Models

• Infrastructure-as-a-Service (IaaS) — คิดว่าเป็น Digital Ocean ละกัน
• Platform-as-a-Service (PaaS) — เรามี Application + Data แล้วใช้งานได้เลย
• Software-as-a-Service (SaaS) — ไปแต่ตัว ทุกอย่างมีให้ใช้
• Sub Models — พวก ABC-as-a-service ทั้งหลาย เช่น Database as a service, Storage as a service ซึ่ง พวกนี้จะให้บริการเป็นเรื่องๆ ไป
• Combining Models — คือ พวกที่ให้บริการ IaaS, PaaS หรือ SaaS แต่ผู้ใช้ที่ต้องการความ Advance สามารถไปปรับแต่งระดับล่างได้

จาก model ที่กล่าวมาด้านบน ปัจจุบันหลายบริการสามารถทำอะไรได้มากกว่า Single Models โดดๆ และมักจะมาในรูปแบบรวมหรือผสมกันมากกว่า 1 ตัวอย่างเช่น

ตัวอย่างที่ 1: IaaS + PaaS

ปล่อยให้ deploy app ของเราได้โดยไม่ต้องยุ่งกับ server เลย แต่สามารถปรับแต่ server config ได้นิดหน่อย

ตัวอย่างที่ 2: Saas + PaaS + IaaS

ตัวอย่างจากรูปข้างล่าง Software Dashboard ที่เราใช้งาน ต่อเข้ากับ PaaS ที่เป็น EKS (Elastic Kubernetes Service) โดยมี Virtual Server อยู่หลังบ้าน ซึ่ง อย่างที่เราทราบกันอยู่แล้ว ใน AWS เวลาเราจะใช้สัก service ที่มันต้อง depend กับ service อื่น เราสามารถหาได้ว่ามันไป setup ตัว service ข้างใต้ที่ไหน และเราสามารถปรับแต่งตัวข้างใต้ได้ด้วย

Checkpoint #2

• Cloud Delivery Models ประกอบไปด้วยอะไรบ้าง
• IaaS คืออะไร
• PaaS คืออะไร
• SaaS คืออะไร
• Sub Models คืออะไร มีความเกี่ยวข้องกับ IaaS, PaaS, SaaS อย่างไร
• ให้คิด Product และทำการวาดภาพให้ออกมาในรูปแบบ Combining Cloud Delivery Models: IaaS, PaaS, SaaS

Cloud Deployment Models

• Public Cloud — ผู้ในบริการ Cloud สาธารณะ เช่น AWS, Azure, Google Cloud, AKUITY (ให้บริการ ARGO CD), Atlas (ให้บริการ MongoDB) หรือ Redis เป็นต้น
• Private Cloud — On-Premise (ที่ไม่เรียก cloud เพราะว่าบางอย่างอาจจะไม่ได้คุณสมบัติของ cloud) or owned by a single organization
• Multi-Cloud — คือ User เจ้าเดียว ไปใช้ cloud provider หลายเจ้าพร้อมๆ กัน เช่น ใช้ AWS (Amazon Web Service) + GCP (Google Cloud Platform)
• Hybrid Cloud — ใช้ Private + Public Cloud พร้อมๆ กันเพื่อทำงานเฉพาะ เช่น ข้อมูลเก็บในรัฐบาลที่ข้อมูลบางส่วนเก็บต้องในประเทศเท่านั้นใน Private Cloud แต่ตัว application ไปใช้ Public Cloud อย่างนี้

จริงๆ ครึ่งหลังมีเรื่อง Basic Linux Foundamental แต่เนื่องจากเป็นเรื่องที่ผมรู้อยู่แล้ว และอยากให้บทความไม่ยืดยาวเกินไป เลยของโฟกัสในเรื่อง Cloud Native Concept ก็พอ

[สรุป] The Cloud Camp 2024 — Audition Round 2 (Day 1/ 3) was originally published in GiVeR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Step by Step

• On Cloudflare, make sure you configure your Cloudflare DNS to point to the right domain, as shown in the picture

• On Medium.com, please follow the support page to get the correct IP addresses (as shown in the picture below)

If custom domain in Medium.com had already linked then we need to unlink and link it again after we done Cloudflare step properly

• Done. Happy writer :)

TL;DR

Actually, this solution is not originally mine, but I searched around the internet and saw people asking the same question again and again then I can conclude on the exact step to make it work on the custom domain in medium.com (paid user) specially for me.

[Solved] DNS-Error 1000 on connecting `medium.com` custom domain with Cloudflare was originally published in GiVeR on Medium, where people are continuing the conversation by highlighting and responding to this story.

When we work on Typescript, especially when we work with React. Most of the time, it’s easy to get confused about which one to use to cover all the needed properties.

In my use case, I want to extend my custom link components from <a> attributes.

interface ComponentProps1 extends React.DetailedHTMLProps<React.HTMLAttributes<HTMLAnchorElement>, HTMLAnchorElement> {}

interface ComponentProps2 extends React.HTMLAttributes<HTMLAnchorElement> {}

type Dif = Omit<ComponentProps1, keyof ComponentProps2>;
type Dif2 = Omit<React.ComponentPropsWithRef<'a'>, keyof React.AnchorHTMLAttributes<HTMLAnchorElement>>;

If we mouse over the Dif or Dif2 in IDE (e.g. VSCode), we might see the difference between both props.

Ref: Try it on Typescript Playground

TL; DR

• ❌ NOT SAFE for non-geek user
• ❌ NOT ALWAYS WORKING
• Make sure you’re logged in to your ✅ same iCloud account on every single device that needs to use the Universal Clipboard feature
• Go to Terminal, and type the following command
• (Optional) To delete existing.

defaults delete ~/Library/Preferences/com.apple.coreservices.useractivityd.plist ClipboardSharingEnabled

• ✅ To enable clipboard sharing features

defaults write ~/Library/Preferences/com.apple.coreservices.useractivityd.plist ClipboardSharingEnabled 1

5. Done. Enjoy

Long story that I have to spend a lot of time investigating the problem by doing the several user troubleshooting ways to solve this problem

Option #1

• Using the same iCloud account on every device
• Restart Macs
• Restart iOS devices
• Turn on/off Bluetooth
• Turn on/off Wifi
• Disable and Enable the handoff feature on both macOS and iOS devices
• etc.

Above item, I did it already but never thrived. So I’m trying to figure out the most geek way to enable this feature.

Thx to one of the community contributions from the following thread

https://discussions.apple.com/thread/253274114

😘 Thanks, msimpson81 that giving the geek way to solve this issue.

Final Output of com.apple.coreservices.useractivityd.plist file.

Option #2

Most of the case I do not really need this to make it works

Ref: https://forums.macrumors.com/threads/universal-clipboard-not-working-mac-iphone-iphone-mac.2231304/?post=28871143#post-28871143

1. Disable Handoff in System Prefs
2. Terminal:
   rm ~/Library/Preferences/com.apple.coreservices.useractivityd.plist
3. Keychain Access -> delete “handoff-own-encryption-key” (this is the local device’s handoff key)
4. Restart in Safe Mode
5. System Prefs -> Enable Handoff.
6. Reboot.
7. Universal Clipboard working correctly!