DevOps BKK 2018 Experience

ของแจกภายในงาน

งานนี้เป็นการรวมตัวกันของกลุ่มคนที่สนใจ DevOps เป็นครั้งแรกที่จัดขึ้นในไทย

มีหัวข้อที่น่าสนใจหลายเรื่องอยู่ จริงๆ อยากฟังทุกเรื่องแหละ แต่ต้องเลือกเข้านะ

ของแจกในงานก็มีกระเป๋าหนึ่งใบที่ใส่ใบปลิวต่างๆ เช่น docker cheat sheat ของสักบริษัทหนึ่ง แล้วก็มีสมุด ปากกา สำหรับจดโน้ต ซึ่งภายในสมุดก็มี kubectl cheat sheat กับ vim cheat sheet

ต่อไปนี้ ผมจะเล่าเฉพาะในส่วนที่ผมเข้าใจหรือจำได้นะครับ


Scale MongoDB on Docker Swarm

เรื่องนี้เล่าโดย ท่านนายกฯ (นายกสมาคมโปรแกรมเมอร์ไทย) ซึ่งได้ไปงาน MongoDB World มา

ก็เริ่มจากปูพื้นเรื่อง DevOps ว่าองค์กรส่วนใหญ่จะแบ่งงานเป็น 3 ส่วน คือ dev test production (infra) โดย dev จะเล่นของใหม่ๆ เช่น ภาษาเวอร์ชันใหม่ หรือ ไลบราลี่เวอร์ชันใหม่ แต่พอ code เวอร์ชันใหม่แล้ว ทำให้ environment ของเครื่องที่รัน code ไม่สามารถรัน code ชุดใหม่ กับ ชุดเก่าพร้อมกันได้ (เกิด conflict) แต่เมื่อมี container technology (docker) เกิดขึ้นทำให้สามารถแยก environment ของแต่ละ container ได้ จึงเข้าแก้ปัญหาดังกล่าวไป

MongoDB เป็น NoSQL อันดับหนึ่ง เนื่องจากสามารถใช้งานได้ดีทั้งระบบขนาดเล็ก และขนาดใหญ่

Docker Swarm ทำ cluster management เป็นการจัดการ docker หลายๆ container ให้ทำงานร่วมกันง่ายขึ้น

การ Scale MongoDB เริ่มจากรัน Primary MongoDB มาหนึ่ง container เพื่อเอาไว้ติดต่อกับตัว app แล้วก็รัน Secondary MongoDB เป็น worker อีกหลายตัว (แล้วแต่ว่าต้องการ worker กี่ตัว) แล้วก็นำแต่ละ container มา join กันเพื่อให้สื่อสารกันได้ แนวคิดประมาณนี้


A 360 degree of DevSecOps

ผมได้คำคมจาก session นี้มาหนึ่งประโยค คือ

Security is everyone’s responsibility

ก็คือทุกคนต้องให้ความสำคัญกับเรื่อง security นั่นเองไม่ว่าจะอยู่ตำแหน่งใดก็ตาม

DevSecOps คือ การนำเรื่อง Security มาแทรกเข้าไปในแต่ละขั้นตอนของ DevOps นั่นหมายถึง คนที่ทำ DevOps ต้องตระหนักถึงเรื่อง Security ด้วย

จึงมีแนวคิดหนึ่งที่จะทำให้เกิดการผสมผสานระหว่าง DevOps กับ Security นั่นก็คือ

Pushing Left

กล่าวคือ โดยปกติ DevOps ก็จะมีขั้นตอน code => test => build => deploy (คร่าวๆ ) ซึ่งเราจะค่อยๆ แทรกเรื่อง security เข้ามาในขั้นตอนทางซ้ายก่อน แล้วค่อยๆ แทรกเข้ามาเรื่อยๆ จนเป็น DevSecOps ที่สมบูรณ์

7 THINGS THAT CAN NEGATIVELY IMPACT YOUR SECURITY CULTURE

เป็นอุปสรรค 7 อย่างที่จะทำให้ DevSecOps เกิดขึ้นได้ยาก (ลองอ่านดูได้ใน Reference Link ด้านล่าง)

มีข้อหนึ่งที่น่าสนใจ คือ ความเข้าอกเข้าใจกันของทีม DevOps กับทีม Security ไม่ว่าจะงานใดก็ตามข้อนี้เป็นสิ่งสำคัญที่จะทำให้งานมีประสิทธิภาพดีขึ้น เรามาดูกันว่าทีม Security เขาให้ความสำคัญเรื่องใดบ้าง

สิ่งที่ทีม Security ให้ความสำคัญ ได้แก่

  1. Availability ความสามารถในการเข้าถึงข้อมูล อยากได้ ต้องมีให้
  2. Integrity ความน่าเชื่อถือของข้อมูล ว่าจะไม่ถูกปรับปรุง แก้ไขโดยมิชอบ
  3. Confidentiality การกำหนดสิทธิ์การเข้าถึงข้อมูลว่า ใครสามารถทำอะไรกับข้อมูลใดได้บ้าง

ตัวอย่างการทำ DevSecOps เช่น

  • ถ้าใครทำ private git host อาจจะต้องทำการป้องกัน git host ล่มด้วยอาจจะเปิดเครื่องสำรองไว้ backup data
  • การพัฒนาซอฟแวร์ตาม 12 Factor App
  • conjur — open source security service
  • การป้องกัน docker image ถูก hack ด้วย Docker Notary

Automated Monitoring using Grafana

ลักษณะข้อมูลที่จะ monitor มีอยู่ 3 แบบ

  1. Log
  2. Metrics
  3. Check
https://image.slidesharecdn.com/codingdefinesmonitoring-161106123317/95/devops-coding-defines-monitoring-16-638.jpg?cb=1478435769

ใน session นี้ได้ demo ด้วย Grafana + Influxdb + telegraf โดย

  • Grafana เป็น dashboard แสดงข้อมูลต่างๆ จากการ Monitor
  • Influxdb เป็นตัวเก็บข้อมูล Monitor
  • telegraf เป็น sensor ที่รับข้อมูลจากการรัน CI และเขียนข้อมูลลง Influxdb

Infrastructure as code using Terraform

session นี้ได้เล่า Infrastructure as a Code โดยใช้ Terraform เป็นตัวอย่าง

ทำไมต้องทำ Infrastructure as a Code

นั่นก็เพราะว่า ทำให้การทำ provision ง่ายขึ้นด้วยการเขียน code มาชุดหนึ่ง แล้วรันมันที่ใดก็ได้ ไม่ต้องมา setup เองทีละเครื่อง ถ้ามีจำนวนเครื่องมากๆ การ setup เองแบบ manual ทำให้เสียเวลามหาศาล และจัดการได้ยากด้วย


Serverless Architectures on Docker

session นี้ตอนแรก อยู่ที่ห้อง conference 1 แต่เนื่องจากมีคนจะเข้าฟังเยอะมาก (fc ของ speaker มีเยอะ) จึงย้ายมาห้อง main stage ซึ่งมีขนาดใหญ่กว่า

ก็เล่าถึงความเป็น serverless ว่ามันเป็นอย่างไร โดยเล่าถึงความสัมพันธ์ระหว่าง Monolith => Micro Services => Functions (เรียงตามความใหญ่)

โดยเขาเปรียบ Monolith เป็นเมือง แต่ละ Service เป็นเขต แล้วก็ function เป็นส่วนเล็ก ๆ ส่วนหนึ่ง เช่น ถนน

ถ้าแอพเป็นแบบ Monolith เวลาแก้ funcion เดียวก็ต้อง build แอพทั้งหมดซึ่งใช้เวลานาน เหมือนกับปิดเมืองทั้งเมือง เพื่อซ่อมถนนเส้นเดียว

ถ้าแอพถูกแบ่งเป็น Micro Services เวลาแก้ function ก็เร็วขึ้นกว่าเดิม เวลา scale ก็เพิ่มเฉพาะ service ที่ใช้งานหนัก แต่บางครั้งเพิ่มไปก็ไม่ได้ใช้ตลอด ทำให้เปลืองพื้นที่แรม

แต่ถ้าแอพถูกแบ่งเป็น function แล้วใช้ Function as a Service (FaaS) ทำให้ประหยัดพื้นที่แรม เนื่องจากมันจะรันก็ต่อเมื่อมีการเรียกใช้เท่านั้น

FaaS ก็มีหลายตัวนะ เช่น AWS Lambda, Google Cloud Function

แล้วเขาก็ลอง demo ให้ดูว่าการรัน function บน docker container เป็นอย่างไร

มีคนเข้าไปเล่น server ที่เขา public ไว้จนค้างๆ

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

จริงๆ เปิดดู vim cheat sheet ในสมุดที่เขาแจกก็ได้ หรือ ไปดูที่


KONG API Gateway

session สุดท้าย เป็น session ปิดที่ฮามากๆ มีการปล่อยมุขแบบเดฟๆ ด้วย หาสาระมิได้ (ล้อเล่นนะ)

เขาเล่าว่า ก่อนที่จะมาใช้ KONG เขาเคยใช้ OpenResty

NGINX + Lua = OpenResty

ก็คือต้องเขียน config file ของ NGINX เวลาแก้ทีก็ต้อง restart NGINX ทีเพื่อให้มันทำงาน set ค่าตาม config file ใหม่ แต่การจะทำแบบนั้นได้แปลว่าคนทำต้องเข้าถึง server ได้เพื่อไปรัน restart NGINX ซึ่งมันจัดการยาก

ดังนั้น KONG จึงมาแก้ปัญหานี้

โดยเบื้องหลังแล้ว KONG ก็คือ NGINX กับ Lua เหมือนกัน แต่วิธี set ค่า config ต่างกัน คือ เราสามารถ set ค่า config ด้วยการยิง request แทนที่จะไปแก้ config file โดยเราที่ไม่ต้องสั่ง restart NGINX เองอีกต่อไป ทำให้แก้ config ได้ง่ายขึ้น

สามารถดูตัวอย่างได้ที่ Reference ด้านล่าง


Aphichan Chaiyutthasart

Written by

Writer, Reader, Fullstack Developer

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade