Quantcast
Channel: cc :: somkiat
Viewing all 2000 articles
Browse latest View live

คำถามที่น่าสนใจ เราควรลบ feature ไหนออกจากระบบงานดี ?

$
0
0

วันนี้มีการพูดคุยสรุปเรื่องของการเพิ่ม feature ใหม่ ๆ เข้ามาในระบบงาน
ซึ่งทุก ๆ อย่างดูดี ทดสอบดี ส่งมอบดี คนใช้งานดี
แต่สิ่งหนึ่งที่น่าสนใจต่อจากนี้คือ
เราควรที่จะเอา feature ไหนออกไปจากระบบงานดี ?

ที่ต้องมีคำถามนี้เพราะว่า

  • ระบบงานเริ่มมี feature เยอะ
  • การดูแลรักษาและพัฒนาเริ่มยากและใช้เวลานานขึ้น
  • เมื่อไปดูจากสถิติการใช้งาน พบว่ามีหลาย ๆ feature ไม่ถูกใช้เลย หรือใช้น้อยมาก

คำตอบที่ได้คืออะไร ?

ชัด ๆ เลยคือ ไม่ !!

มันเป็นสิ่งที่น่าแปลกใจไหมนะ
ที่เราจะใช้เวลาจำนวนมาก ในการคิดและสร้าง feature ใหม่ ๆ
แต่กลับไม่จัดการ feature ที่ถูกสร้างมาแล้ว !!
ทั้ง ๆ ที่ไม่ถูกใช้งานเลย หรือ อาจจะไม่สร้างผลประโยชน์ใด ๆ เลย
หรือมันกลายเป็นความปกติไปแล้วนะ ?

เคยมีไหม ที่เราได้รับ feature ว่า ต้องการลบ feature X ออกไป ?



สรุปแนวทางการป้องกันปัญหา Log4Shell สำหรับ Docker container

$
0
0

ใน blog ของ Docker
เรื่อง 10 tips for keeping your Docker containers safe from Log4Shell
ได้สรุป 10 ข้อ สำหรับการป้องกันปัญหา Log4Shell
ที่อาจจะเกิดขึ้นได้ใน Docker container
โดยมี Cheat Sheet :: Docker + Snyk log4shell remediation ออกมาให้
จึงทำการสรุปสั้น ๆ ไว้หน่อย

  • อย่าลืม scan image ด้วย $docker scan
  • ใช้ official image และ image ที่แก้ไขล่าสุดด้วยเสมอ
  • Update version ของ JDK ไม่เพียงพอ ต้องไป config com.sun.jndi.ldap.object.trustURLCodebase=false ด้วย
  • ตรวจสอบผลการ scan image ในDocker Hub ด้วยว่า รอดไหม
  • ใช้งาน Docker desktop 4.3.1 ขึ้นไป
  • ห้าม run container ด้วย user root เด็ดขาด
  • ให้ใช้งาน root filesystem แบบ read only เท่านั้น
  • ทำการ upgrade log4j เป็น version ล่าสุด
  • ห้าม run container ใน privileged mode
  • อะไรที่ไม่ได้ใช้งาน ก็ไม่ต้องมีใน container เช่น curl, wget เป็นต้น

มาลองใช้งาน Test runner ใน Node.js 18

$
0
0

ใน Node.js 18 ที่ปล่อยออกมานั้น
มีการเพิ่ม Test runner module ออกมาด้วย (ยังเป็น experiment เท่านั้น)
ทำให้เราสามารถเขียนและ run test โดยไม่ต้องใช้ extenal library อื่น ๆ อีกต่อไป
ซึ่งสนับสนุนทั้งการทำงานแบบ synchronous และ asynchronous
ดังนั้นมาลองใช้งานกันนิดหน่อย

เริ่มต้นจากการเขียน test case ต่าง ๆ

ซึ่งทดสอบได้ทั้ง sync และ async function
โดยทำการ import node:test และ assert module มาใช้งาน

รูปแบบจะคล้ายกับ jest เลย
รวมทั้งเขียน subtest ได้
ถือว่าเป็นการเริ่มต้นที่ดีมาก ๆ

[gist id="e90c9999dab7df5d08047aeacd032bae" file="hello_test.js"]

จากนั้นทำการ run test ด้วย node

โดยผลที่ออกมายังไม่สวย แต่ก็ run และได้ผลการทดสอบออกมา
ดังนี้

[gist id="e90c9999dab7df5d08047aeacd032bae" file="1.txt"]

โดยที่ option ในการ run test จะประกอบไปด้วย

  • concurrency สำหรับการ run test พร้อม ๆ กัน ค่า default = 1
  • only ทำการ run เฉพาะ test นั้น ๆ
  • skip ทำการข้าม test ที่เขียนให้ skip และแสดงเหตุผลของการ skip
  • todo แสดงเหตุผลของ test ที่เขียน TODO

ลองใช้กันดูครับ

วันนี้เขียน test แล้วหรือยัง ?

Reference Websites

รูปอธิบายเรื่อง Program vs Process vs Thread

$
0
0

เจอรูปอธิบายเรื่อง Program vs Process vs Thread ใน Twitter
ซึ่งเข้าใจง่ายดี
โดยที่

  • ในแต่ละ program ประกอบด้วยชุดคำสั่งต่าง ๆ และทำการจัดเก็บลงใน disk
  • ในแต่ละ program นั้นสามารถมีมากกว่า 1 process ทำงานอยู่
  • ในแต่ละ process นั้นจะถูก load ลงไปใน memory
  • ในแต่ละ process จะมีหลาย ๆ thread ทำงานอยู่ ดังนั้นโดยปกติ ถ้า process ตาย thread ก็ตายตามไปด้วย
  • ในแต่ละ thread สามารถติดต่อสื่อสารกันได้
  • การ switch context ไปมาระหว่าง process จะเปลืองทรัพยากรมาก ๆ

แนะนำ KubeOrbit สำหรับการทดสอบระบบบน Kubernetes

$
0
0

ก่อนหน้านี้ในการพัฒนาและทดสอบระบบงานที่ deploy บน Kubernetes นั้น
มักจะใช้งาน Telepresence เป็นหลัก
ช่วยทำให้พัฒนาและทดสอบได้ง่ายและรวดเร็วมากยิ่งขึ้น
มาวันนี้เห็นมี KubeOrbit อีกตัว ที่สร้างออกมา
เน้นเรื่องของการทดสอบและ debug เป็นหลัก
และทดสอบแบบอัตโนมัติอีกด้วย

เป้าหมายของ KubeOrbit คือ

  • ลดปัญหาต่าง ๆ ที่เกิดจาก integration testing
  • ลดปัญหาในเรื่องของ resource และ environment ที่มีอยู่อย่างจำกัด
  • การพัฒนาและทดสอบมักจะขัดแย้งกัน โดยรวมทำให้การส่งมอบระบบช้าลงอย่างมาก
  • ปัญหาของการทดสอบที่ไม่น่าเชื่อถือ ส่งผลให้ปัญหาเกิดขึ้นบ่อย และกระทบต้อลูกค้าอีกด้วย

โครงสร้างเป็นดังรูป

  • โดยที่ KubeOrbit จะมี cli ให้ใช้งาน เพื่อทำการ forward traffic จาก kubernetes cluster มายัง local development ได้

ดังนั้นเป็นอีกเครื่องมือที่น่าสนใจ น่าลองมาก ๆ => Getting Start ...

แนะนำหนังสือ Software Engineering at Google (SWE Book)

$
0
0

เพิ่งเห็นว่าหนังสือ Software Engineering at Google
นั้นเปิดให้ download PDF มาอ่านแบบฟรี ๆ

โดยในหนังสือเล่มนี้มีหลายหัวข้อที่น่าสนใจ

ประกอบไปด้วย

  • ความแตกต่างระหว่าง Software Engineering และ Programming
  • การสร้างความสัมพันธ์ที่ดีกับกลุ่มคนต่าง ๆ ที่ทำงานร่วมกัน
  • ใช้เครื่องมือและแนวทางในการทำงานร่วมกันที่ดี เช่นพวก style guide และรูปแบบของการเขียน test รวมถึงแนวทางในการจัดการ dependency ต่าง ๆ
  • ให้พื้นที่หรือโอกาสกับ junior เพื่อความก้าวหน้าและเติบโต

ลอง Download มาอ่านกันเลย

บันทึกการ run Selenium IDE ผ่าน command line

$
0
0

วันนี้ทำการแนะนำเกี่ยวกับการทดสอบระบบแบบอัตโนมัติ
หนึ่งในเครื่องมือที่แนะนำสำหรับมือใหม่ไป
คือ Selenium IDE
ใช้สำหรับการทดสอบระบบที่ทำงานบน web browser
โดยไม่จำเป็นต้องเขียน code มากนัก
เพราะว่าเป็นเครื่องมือแบบ record and playback นั่นเอง

โดยเราสามารถบันทึกชุดการทดสอบที่ได้จากการ record ลงไฟล์
ซึ่งไฟล์จะมีนามสกุล .side
ที่มันสนุกกว่านั้นคือ สามารถนำไฟล์นี้
มา run ผ่าน command line ได้
ผ่านเครื่องมือที่ชื่อว่า Command-line Runner

ส่งผลให้เราสามารถนำชุดการทดสอบนี้
ไป run ใน pipeline ของระบบ Continuous Integration ได้เลย
โดยสามารถ run ชุดการทดสอบผ่าน browser ต่าง ๆ
หรือจะผ่าน Selenium grid ก็ได้อีกด้วย

เป็นอีกเครื่องมือที่น่ารู้จักและลงใช้งานไว้บ้าง
รู้ดีกว่าไม่รู้นะ
จะใช้หรือไม่ นั่นเป็นอีกเรื่อง

Node 18.1.0 เพิ่ม test runner cli มาให้แล้ว

$
0
0

ก่อนหน้านี้ Node 18.0 นั้น ได้เพิ่ม Test runner module เข้ามา
ช่วยให้เราสามารถเขียน test case และ run ผ่าน node command ได้เลย
แต่สิ่งที่ขาดไปคือ cli option สำหรับการ run test แบบเฉพาะไปเลย
ดังนั้นใน Node 18.1.0 นั้น ได้เพิ่มเข้ามาให้
นั่นคือ เพิ่ม --test flag เข้ามานั่นเอง

การใช้งานเป็นดังนี้

[code] $node --test $node --test *.js tests/ [/code]

การ run test แบบปกติ จะทำการค้นหาไฟล์ .js, .cjs และ .mjs เพื่อทดสอบ
หรือถ้ามี test directory ก็จะหาไฟล์ .js, .cjs และ .mjs เพื่อ run ต่อไป
ส่วน node_modules directory จะถูก ignore ไป

โดยรูปแบบของไฟล์จะต้องเป็นดังนี้

  • ^test$
  • ^test-.+
  • .+[\.\-\_]test$

ลองใช้งานกันดูครับ เริ่มมีการปรับปรุงในทางที่ดีขึ้นเรื่อย ๆ


รูปแบบของ test case ที่ไม่น่าจะดี !!

$
0
0

วันนี้ทำการ review test case ของระบบ
มีทั้ง unit, integration, component และ end-to-end test
แล้วก็เจอ test case แปลก ๆ ที่คิดว่าไม่น่าจะดี
จึงสรุปไว้นิดหน่อย

ปัญหาแรก Test ผ่าน เมื่อมีการเปลี่ยนแปลงขึ้นมา !!

เมื่อมีการเปลี่ยนแปลง requirement และ code แล้ว
ผลที่ได้คือ test case ดันทำงานผ่านซะงั้น
นั่นหมายความว่า test case ที่เรามีนั้น
มันไม่ครอบคลุมเพียงพอ หรือ ไม่น่าเชื่อถือหรือไม่ ?

ปัญหาที่สอง ทำการ Fake dependency สำหรับ integration และ end-to-end test

เป็นผลมาจากปัญหาแรกด้วย
เพราะว่า มีการทำ fake พวก dependency ไว้เพียบ
ทำให้แทนที่จะติดต่อไปยังระบบปลายทางจริง ๆ กลับผ่าน fake ต่าง ๆ
มันช่วยให้ผ่านก็จริง แต่ใช้ผิดที่มันก็เป็นภัย

ปัญหาที่สาม แต่ละ test case เชื่อมต่อกันเป็นลูกโซ่มากเกินไป

แต่ละ test case ทำงานไม่จบในตัวเอง
แต่มีความสัมพันธ์กับ test case อื่น ๆ
ก็ให้เกิดปัญหาของการ run test ผ่านบ้างไม่ผ่านบ้าง
มันคือ flaky test ไหมนะ

เมื่อเกิดปัญหาขึ้นมา ก็ใช้การ retry test แทน
หรือมันช้ามาก ๆ ก็ตั้ง timeout นาน ๆ
แบบนี้มันดีไหมนะ ?

ปัญหาที่สี่ test case ไม่อธิบายว่า ทำอะไร ทดสอบอะไร เพื่ออะไร

ตรงนี้เป็นปัญหาสำคัญมาก ๆ
เพราะว่า ทำให้เกิดปัญหาเช่นทดสอบไม่ผ่านแล้ว
ไม่รู้ว่าคืออะไร ทดสอบอะไร
หนักกว่านั้น ก็ reference ให้ไปอ่านที่ระบบอื่น ๆ อีก
สร้างความซับซ้อนโดยใช่เหตุ
แต่มีก็ดีกว่าไม่มีนะ

ชุดการทดสอบ ควรช่วยบอกเราได้ว่า
มีปัญหาอะไรเกิดขึ้น อย่างทันท่วงที หรือแต่เนิ่น ๆ
รวมทั้งมีความน่าเชื่อถือด้วยเสมอ
ไม่ใช่มีเพียงเพื่อให้มีเท่านั้นนะ !!

ถ้ามีหนังสือเล่มนี้จริง ๆ อยากให้มีหัวข้ออะไรบ้าง ?

$
0
0

ไปเจอปกหนังสือขำ ๆ มา คิดว่า ถ้ามีคนเขียนออกมาเป็นหนังสือจริง ๆ
น่าจะดีไม่ใช่น้อย
เพื่อน ๆ คิดว่า ในหนังสือเล่มนี้ควรมีหัวข้ออะไรบ้าง
ช่วย share มากันหน่อยครับ
ผมคิดว่า น่าสนุกมาก ๆ

ว่าด้วยเรื่องของ Complexity ของ software

$
0
0

วันนี้อ่านเจอเรื่อง complexity ของ software
จะประกอบไปด้วย 2 ชนิดหลัก ๆ คือ

  • Essential complexity
  • Accidental complexity

เป็นเรื่องที่น่าสนใจ จึงทำการสรุปไว้นิดหน่อย

Essential complexity

เป็นความซับซ้อนที่เกิดขึ้นกับ software เป็นปกติ
ที่ไม่สามารถหลีกเลี่ยง หรือ เอาออกไปได้
เพราะว่า เกิดมาจากการแก้ไขปัญหานั้น ๆ
จะมากหรือน้อยเท่านั้นเอง

Accidental complexity

เป็นความซับซ้อนที่เกิดขึ้นจากการออกแบบ วางแผน พัฒนาและ deploy
จาก delivery team ของ software นั้น ๆ เอง
ซึ่งมักจะไม่ได้เกี่ยวกับการแก้ไขปัญหานั้น ๆ โดยตรงเหมือน
เป็นการปะผุ หรือ แก้ไขอะไรบางอย่าง เพื่อให้ทำอีกอย่างได้
แต่ไม่ได้แก้ไขที่ต้นเหตุ

เป็นรูปแบบของความซับซ้อนที่ควรหลีกเลี่ยงหรือระมัดระวังให้มาก
เพราะว่าผลที่ตามมามันเกินความคาดเดาและยากต่อการหาปัญหาและแก้ไขอีกด้วย

ยกตัวอย่างเช่น
มีต้นไม้ขวางทางสิ่งที่เราทำคือ
สร้างกำแพงรอบต้นไม้
จากนั้นทำทางอ้อมไป หรือว่า เป็นสะพาน หรือ ขุดอุโมงค์ลอดไป

ดังนั้นจึงควรให้ความสำคัญ
ตั้งแต่การออกแบบ การแบ่งหน้าที่รับผิดชอบให้ชัดเจน
รวมทั้งการเริ่มแบบ simple หรือ เรียบง่ายก่อน
อย่าไปท่าเยอะ หรือ pattern เยอะมากมาย
มิฉะนั้นก็จะก่อให้เกิด accidental complexity ขึ้นมาอีก

ชอบรูปนี้ อธิบายได้ชัดเจนมาก ๆ

กลับมาในโลกของการพัฒนา software

เราจะเจอความซับซ้อนใน 2 แบบหลัก ๆ คือ

  • ความสามารถในการทำความเข้าใจ การดูแลรักษาแต่ละส่วนของ code/module/component ของระบบ หลังจากที่สร้างมันขึ้นมาแล้ว
  • Big-O complexity เป็นความซับซ้อนจาก algorithm ที่ใช้เพื่อแก้ไขปัญหา ว่าเป็นอย่างไร ทั้งความซับซ้อนและความเร็ว

โดยถ้ามองในแง่ของนักพัฒนาแล้ว

ปัญหาที่มักก่อให่เกิดความซับซ้อนโดยเปล่าประโยชน์ ประกอบไปด้วย

  • ขาดความรู้ความเข้าใจ ในสิ่งที่ทำ หรือ ในสิ่งที่นำมาใช้ ทั้งเครื่องมือ framework รวมถึงภาษาโปรแกรมที่ใช้
  • ขาดการวางแผนที่ดี รวมถึงความเข้าใจในงานที่ทำ ว่าควรจะออกแบบ วางแผน พัฒนา และทดสอบอย่างไร เรื่องของการแบ่งงานก็สำคัญ
  • อะไรที่ไม่เข้าใจก็ยังลงมือทำ ยิ่งทำยิ่งซับซ้อน ถึงแม้จะแก้ไขปัญหาได้ก็ตาม บ่อยครั้งนักพัฒนายังตกใจ ว่ามันทำงานได้อย่างไร !!
  • บ่อยครั้งพบว่า ถ้าส่วนไหนที่มันทำงานได้ เราจะไม่ไปแก้ไขให้มันดีขึ้น ทั้ง ๆ ที่รู้ว่ามันไม่ดี หรือ มีความซับซ้อน หรือ มีสิ่งที่ไม่รู้อีกเพียบ

เมื่อเวลาผ่านไปเรื่อย ๆ ก็จะเป็นไปตามรูปด้านบนนั่นเอง

ลองดูสิว่า ในระบบงานของเรามีความซับซ้อนแบบไหนบ้าง ?

ว่าง ๆ มาดู benchmark ของ Generic ใน Go กันหน่อย

$
0
0

ระหว่างนั่งรอขึ้นรถกลับ เลยนำ code ที่เขียนด้วยภาษา Go
กับการเปลี่ยนมาใช้งาน Generic กันนิดหน่อย
จากนั้นทำการวัด benchmark กันหน่อย
ว่าจะเพิ่มหรือลดลงอย่างไรบ้าง ?

ตัวอย่างของ code เป็นการตรวจสอบข้อมูลใน array ว่ามีหรือไม่ ?

โดย code เป็นดังนี้

[gist id="24f359c12fe98ddde485253d9600d809" file="demo.go"]

จากนั้นเขียน test เพื่อวัด benchmark กัน

[gist id="24f359c12fe98ddde485253d9600d809" file="demo_test.go"]

ผลที่ได้เป็นดังนี้

[gist id="24f359c12fe98ddde485253d9600d809" file="1.txt"]

จะพบว่าความเร็วไม่ได้ต่างกันมาก

มาดู Docker Desktop 4.8.1 กันหน่อย

$
0
0

หลังจากไม่ได้ update Docker Desktop เลย
ซึ่งตัวมันเองก็แจ้งตลอด วันนี้ฤกษ์ดีเลยทำการ upgrade เป็น version 4.8.1 กันหน่อย
โดยใน version นี้มี feature ที่น่าสนใจคือ

  • Docker Desktop for Linux
  • Docker extension ซึ่งเปิดให้ใช้งานแบบ beta version ช่วยให้สามารถเพิ่มความสามารถของ Docker Desktop ได้ และมี marketplace ให้ใช้งานด้วย
  • เอา dockershim ออกไปแล้ว
  • Docker compose V2 เป็นตัว GA แล้ว ซึ่งใช้ BuildKit เป็นค่า default
  • โดย V1 จะถูกแจ้งเป็น deprecated แล้ว และ V1 จะถูกแก้ไขเฉพาะเรื่องของ security issue และ critical bug เท่านั้น นั่นคือหยุดพัฒนาแล้ว โดย timeline ของ V1 น่าจะหยุดทุกอย่างช่วงปีหน้า

Update กันได้แล้วครับ

การแก้ไขปัญหา Dashboard UI ใน kubernetes 1.24

$
0
0

วันนี้ทำการติดตั้ง Kubernetes 1.24 กับ Dashboard UI
แต่ก็เจอปัญหาเรื่องของ token ที่ใช้ในการเข้าใช้งาน UI
เนื่องจากทำตามเอกสาร Creating sample user แล้วไม่ได้

ก็เลยไปลองดูปัญหาเรื่องนี้ใน GitHub issue ของ project
ก็พบว่ามีคนที่เจอปัญหานี้เช่นกัน
แถม issue นั้น close ไปด้วย !!

คำอธิบายใน issue ง่าย ๆ คือ
ตอนนี้ Dashboard UI ยังไม่ได้ support หรือ update ตาม Kubernetes 1.24 นั่นเอง
จึงทำให้เกิดปัญหาเรื่องของการสร้าง token

ดังนั้นการแก้ไขไม่ยาก ให้ทำการใช้คำสั่ง create token เองดังนี้

[code] $kubectl -n kubernetes-dashboard create token admin-user [/code]

เพียงเท่านี้ก็จะได้ token ไปใช้แล้ว

กับอีกปัญหาที่ Kubernetes 1.24 มีปัญหากับ containerd
ซึ่งเป็นตาม issue นี้

[gist id="5c399bc3e48e96d8f23c6f36c9db4742" file="1.txt"]


แก้ด้วยการลบ config และ restart containerd นั่นเอง

สวัสดี Ballerina

$
0
0

จากหนังสือ Data-oriented programming
ก็ได้ตามมาถึงภาษา Ballerina
ซึ่งมีความแปลกและน่าสนใจดี
อีกอย่างมันคือ JVM language ตัวหนึ่ง
ว่าแล้วก็ลองเขียนเล่นดูหน่อย
ด้วยการเขียน REST API แบบ hello world กันหน่อย

มาเริ่มกันเลย

เริ่มจากการติดตั้ง

[gist id="da1659403dc6cb67361605ee9ce6ce41" file="1.txt"]

สร้าง project กันต่อเลย

[gist id="da1659403dc6cb67361605ee9ce6ce41" file="2.txt"]

ทำการ run ใน mode development

[gist id="da1659403dc6cb67361605ee9ce6ce41" file="3.txt"]

ถ้าต้องใช้งานบน production จะต้อง build เป็น JAR file

[gist id="da1659403dc6cb67361605ee9ce6ce41" file="4.txt"]

เพื่อให้ดูมีอะไรขึ้นมาหน่อย ทำการสร้าง REST API กันหน่อย

โดยใช้งาน http package ท่ีมากับตัวภาษานั่นเอง

[gist id="da1659403dc6cb67361605ee9ce6ce41" file="main.bal"]

จากนั้นทำการ run และทดสอบดังนี้

[gist id="da1659403dc6cb67361605ee9ce6ce41" file="5.txt"]

อีกอย่างใน VS Code มี extension ในการแสดง REST API แบบภาพสวย ๆ ให้อีก
ตัวนี้ชอบมาก ๆ

ไม่พอยังสามารถ generate OpenAPI specification ได้อีก

ดูแล้วน่าสนใจดี สำหรับภาษานี้
ไปศึกษากันดู Learn Ballerina

Reference Websites

  • https://www.infoq.com/articles/ballerina-fullstack-rest-api/

มาลองสร้าง Docker Extension เล่นกันหน่อย

$
0
0

จาก Docker Desktop 4.8 ใหม่นั้น
ได้เพิ่มเรื่องของ Docker Extension ออกมาให้ใช้งาน
ช่วยให้เราสามารถขยายความสามารถ Docker ตามที่ต้องการได้มากขึ้น
โดยทาง Docker ได้ปล่อย SDK มาให้ใช้งานด้วยเช่นกัน
แต่ยังอยู่ใน beta version เท่านั้น
ดังนั้นความสามารถต่าง ๆ อาจจะเปลี่ยนแปลงได้เสมอ
เพื่อความสนุกสนานก็มาลองสร้าง Docker Extension เล่นกันหน่อย

เริ่มด้วยติดตั้ง extension ดังนี้

[gist id="d163ad4637ab6b1dcc31a68d82986fbf" file="1.txt"]

จากนั้นทำการสร้าง extension ขึ้นมา

สร้างด้วยภาษา Go สำหรับฝั่ง backend หรือ REST API
ที่ติดต่อกับทาง Docker engine ซึ่งใช้ library ต่าง ๆ ดังนี้

  • Echo สำหรับพัฒนา REST API
  • Logrus สำหรับการจัดการ logging
  • Testify สำหรับการทดสอบ

ส่วนฝั่ง UI ใช้ ReactJS

[gist id="d163ad4637ab6b1dcc31a68d82986fbf" file="2.txt"]

สามารถดู code ที่ generate มาให้ได้ทั้ง

ในฝั่ง backend ที่เขียนด้วยภาษา Go

[gist id="d163ad4637ab6b1dcc31a68d82986fbf" file="main.go"]

และฝั่ง UI ที่พัฒนาด้วย ReactJS

[gist id="d163ad4637ab6b1dcc31a68d82986fbf" file="App.js"]

ในการ build ใช้ makefile หรือ Docker

ทำการ build extension ผ่าน makefile หรือ docker build ได้เลย

[gist id="d163ad4637ab6b1dcc31a68d82986fbf" file="3.txt"]

เมื่อผ่านแล้ว ทำการ install extension ที่สร้างมาไปยัง Docker engine ที่เครื่องของเรา

[gist id="d163ad4637ab6b1dcc31a68d82986fbf" file="4.txt"]

ลองดูผลการติดตั้งใน Docker Desktop ได้ดังรูป

หลังจากที่ทดสอบเรียบร้อยแล้ว สามารถ push ขึ้นไปยัง Extensions Marketplace

เป็นการ push ขึ้นไปที่ Docker Hub
ซึ่งใช้เวลานานมาก ๆ ทนหน่อย

[gist id="d163ad4637ab6b1dcc31a68d82986fbf" file="5.txt"]

เพียงเท่านี้ก็สามารถสร้าง Docker extension แบบง่าย ๆได้แล้ว
เป็นอีกความสามารถที่น่าสนใจของ Docker

สวัสดี Rancher Desktop

$
0
0

จากการ share เรื่องของ Docker และ Kubernetes
มีคำถามว่า จะใช้อะไรแทน Docker Desktop
และใช้งาน Kubernetes แบบ local ได้
จึงทำให้คิดถึง Rancher Desktop
เลยเขียนการใช้งานแบบคนเริ่มต้นไว้นิดหน่อย

โดยความสามารถพื้นฐานคือ

  • Container management
  • Kubernetes cluster บน local machine
  • ติดตั้งเครื่องมอืต่าง ๆ ให้เพียบ ทั้ง moby, containerd, k3sและ kubectl เป็นต้น รวมทั้ง rancher desktop command-line และ nerdcli ด้วย

สามารถติดตั้งได้ทั้งบน Windows, Mac และ Linux

เมื่อติดตั้งแล้ว สามารถเลือกได้ว่า จะใช้ Kubernetes version อะไร
รวมทั้ง container runtime อีกด้วย

จากนั้นก็เริ่มใช้งาน จะสังเกตได้ว่ากำลังทำการ download Kubernetes นั่นเอง

ถ้าไปดูใน task manager หรือ Activity monitor แล้ว

จะพบว่ามีการสร้าง VM ขึ้นมา ซึ่งใช้งาน memory เยอะเช่นกัน
บนเครื่อง Mac ที่ผมใช้นั้น ใช้ memory ไป 4.8 GB ส่วน CPU ก็กินไปเยอะเช่นกัน
ถ้าเครื่องไม่แรง และ resource น้อย ไม่น่ารอดนะครับ

มาเริ่มใช้งานกัน เรื่องของการจัดการ image และ container

ใช้งานผ่าน nerdctl ดังนี้

[gist id="286ffa1ceb9ee4d28cf562c602771655" file="1.txt"]

แล้วมาลอง deploy บน Kubernetes cluster ด้วย kubectl

โดยทำตามตัวอย่างเรื่องของ Deployment เล่นดู
ได้ผลดังนี้

[gist id="286ffa1ceb9ee4d28cf562c602771655" file="2.txt"]

เพียงเท่านี้ก็สามารถจัดการพวก container
และใช้งาน Kubernetes cluster บน local machine ได้แล้ว
ลองใช้งานกันดูครับ เป็นอีกทางเลือกที่น่าสนใจ

น่าสนใจกับ CloudNativePG

$
0
0

ตั้งแต่เดือนเมษายนที่ผ่านมา ทาง EnterpriseDB หรือ EDB
ได้ปล่อย CloudNativePG เป็น open source ออกมา
ซึ่งเป็น Kubernetes operator สำหรับ
ติดตั้งและจัดการ PostgreSQL cluster บน Kubernetes นั่นเอง

โดย CloudNativePG มีความสามารถดังนี้

  • Autopilot สำหรับการ deploy และจัดการ PostgreSQL
  • Data persistence โดยจะจัดการผ่าน PVC (Persistence Volume Claim)
  • ทำงานผ่าน Kubernetes API server โดยตรง นั่นคือจัดการสิ่งต่าง ๆ ตาม Kubernetes เลย ทั้ง Self-healing, rolling update และ scale ได้เลย
  • สนับสนุนเรื่องSecurity by default อยู่แล้ว รวมทั้งทำการ audit ผ่าน PGAudit อีกด้วย
  • Monitoring จะมี Prometheus exporter มาให้เลย รวมทั้ง customize ได้อีก
  • Architecture default คือ primary/standby architecture แต่ก็สามารถเพิ่มสิ่งต่าง ๆ เข้าไปได้ เช่น PgBouncer สำหรับจัดการ connection pool และการ replica ข้าม region เป็นต้น

จะ Mock หรือ ไม่ Mock ดี ?

$
0
0

คำถามที่น่าสนใจ สำหรับการพัฒนาและทดสอบระบบงาน
หนึ่งในนั้นคือ เราควรจะ Mock หรือ ไม่ Mock พวก dependency ดี ?
เป็นคำถามที่ตอบได้ยากมาก ๆ
เนื่องจากมันขึ้นอยู่กับ context ที่พบเจอด้วย
แต่สิ่งที่เราควรต้องตอบให้ได้ว่า
เราจะ Mock พวก dependency ต่าง ๆ ไปทำไม
เพราะว่าใช้ของจริงไปเลยสิ มันจริงกว่า ถูกต้องกว่า !!

ก่อนอื่นแนะนำให้เข้าใจก่อนว่า Mock มันคือ

หนึ่งในรูปแบบหนึ่งของการจำลอง dependency
ซึ่งเราจะเรียกว่า Test Double มีทั้ง

  • Dummy
  • Stub
  • Spy
  • Mock
  • Fake

มีเป้าหมายเพื่อทดสอบการทำงานในส่วนที่สนใจ
โดยที่สามารถกำหนดสถานการณ์ หรือ หรือจำลองผลการทำงานของ dependency
ให้เป็นไปตามที่เราต้องการ ทั้ง success และ fail
โดยสามารถใช้งานได้ในการทดสอบแต่ละชนิดด้วย เช่น

  • Unit test
  • API test
  • UI test

ผลที่ตามมาคือ เราสามารถทดสอบการทำงานในแต่ละส่วนได้รวดเร็วขึ้น
การทดสอบสามารถทำซ้ำ ๆ ได้บ่อยตามที่เราต้องการ

แต่ถ้าทำการจำลอง dependency มากเกินไป
หรือลงรายละเอียดมากไป
ก็จะทำให้เกิดปัญหาได้ ลองอ่านเพิ่มเติมได้ที่ Mocking is a code smell

เนื่องจากการจำลองมันก่อให้เกิดปัญหาดังนี้

  • มักจะมีสิ่งที่เพิ่มเข้ามาในการจำลองมากกว่าของจริง เช่น property/method เป็นต้น
  • ทำการ return ข้อมูลต่างจากของจริง
  • มีการทำงานที่แตกต่างจากของจริง
  • หนักกว่านั้น เมื่อของจริงมีการเปลี่ยนแปลง ในส่วนของการจำลองไม่เป็น ปัญหาเกิดแน่นอน
  • ยิ่งมี dependency มาก ๆ ยิ่งทรมาน ดังนั้นควรกลับไปดูการออกแบบแล้ว ว่าทำไมมี dependency เยอะแบบนั้น

ดังนั้นอาจจะต้องดูด้วยว่า สิ่งที่เราต้องการคืออะไรกันแน่

มันจะช่วยเราหรือทำร้ายมากกว่ากัน
จากนั้นทำการเลือก และลงมือทำ วัดผล
ว่าสิ่งที่คิด และผลที่ออกมาหลังการลงมือทำเป็นอย่างไร
เพื่อปรับปรุงต่อไป

ยกตัวอย่างเช่น

เราสนใจที่ business logic เป็นหลัก เนื่องจากมีความซับซ้อน
ดังนั้นจึงพยายามที่จะจำลอง dependency ที่ถูกใช้งาน
เช่น database, external api เป็นต้น
แต่ถ้าสามารถทดสอบกับระบบจริง ๆ ได้หรือบ่อยที่สุด จะเป็นสิ่งที่ดีที่สุด

สุดท้ายแล้ว จำเป็นต้องยก use case และสิ่งที่ต้องการมาเป็นที่ตั้ง
จากนั้นจึงมาพูดคุย ออกแบบ วางแผนกัน
ว่าควรจะใช้หรือไม่ใช้
น่าจะเป็นแนวทางที่เหมาะสมกว่า

VDO จากงาน DevOps Enterprise Summit

$
0
0

ไปเจอ web รวบรวม VDO ต่าง ๆ จากงาน DevOps Enterprise Summit
จาก community ในประเทศต่าง ๆ ตั้งแต่ปี 2014 ถึง 2022
ลองไปดูและศึกษาเพิ่มเติมกันครับ
มีหลาย ๆ เรื่องที่น่าสนใจมาก ๆ

Viewing all 2000 articles
Browse latest View live