Update: Lens The Kubernetes IDE

Lens The Kubernetes IDE

สวัสดีครับ DevOps 101 ของเราวันนี้ นำเสนอ Lens ครับ .. ตอนนี้ ก็ออกมาถึง version 5.x.x กันแล้ว ณ ตอนที่ผมเขียน blog ก็เป็น version 5.1.3 เพื่อนๆ บางท่าน อาจจะเคยใช้งานกันมาบ้างแล้ว .. แต่สำหรับบางท่านที่ยังไม่เคยใช้งาน อาจจะยังสงสัยว่ามันคืออะไรกัน เจ้า Lens .. จากคำอธิบายในเว็บของเค้าคือ ..

“Lens is the only IDE you’ll ever need to take control of your Kubernetes clusters. It’s built on open source and free.”

สรุปสั้นๆ เข้าใจง่ายๆ ก็คือ Lens เป็น IDE ที่ช่วยจัดการ Kubernetes (k8s) cluster ของเรา เป็น Open Source และ Free 🙂
สำหรับท่านที่เคยใช้ kube-proxy ที่เป็น Dashboard ของ k8s เอง .. จะพบว่า มันใช้งานไม่ค่อยสะดวกเท่าไรนัก .. ลองเปลี่ยนมาใช้ Lens ดูครับ จะพบว่าสะดวกกว่ามากๆ ..

สำหรับวิธีการติดตั้ง Lens ก็ไป download ได้เลยครับที่ https://k8slens.dev/ มีทั้งบน Mac OS, Windows และ Linux ครับ .. ตัว Lens เองจะใช้ file config เดียวกับ kubectl ของเราคือจะอยู่ที่ ~/.kube/config ซึ่งถ้าใครใช้งาน kubectl ได้อยู่แล้ว ก็จะไม่มีปัญหา อะไร .. แต่ถ้าเปิด Lens ขึ้นมาแล้ว ยังใช้งานไม่ได้ ก็ให้ไปลองดูที่ ~/.kube/config ว่ามีค่า config ต่างๆ ถูกต้องไหม .. หรือถ้าใครใช้ EKS อยู่ วิธีการง่ายๆ ก็คือ การสั่ง update kube config ครับ ดังตัวอย่าง ..

aws eks update-kubeconfig --name tono-eks \
--region ap-southeast-1 \
--profile tono-admin

สิ่งที่อยากจะนำเสนอเพิ่มเติม สำหรับเจ้า Lens ก็คือ Lens Metrics ซึ่งตรงนี้ จะทำให้เราดู resource ของ k8s cluster เราได้ง่ายขึ้น สะดวกขึ้นครับ .. จริงๆ แล้ว ก็คือการติดตั้ง Prometheus + Kube State Metrics + node exporter เข้าไป เพื่อเก็บ metrics ต่างๆ จาก k8s cluster เราลงบน Prometheus นั่นเองครับ .. มาดูวิธีการ enable ตรงนี้กันครับ ..

1.คลิกขวาที่ icon ของ k8s cluster ของเรา แล้วเลือก Settings

คลิกขวา ที่ icon k8s cluster แล้วเลือก Settings

2.มาที่ Lens Metrics แล้วทำการ Enable PROMETHEUS, KUBE STATE METRICS, NODE EXPORTER จากนั้นกด Apply

Lens Metrics กด Enable ทั้ง 3 อัน

3.กลับมาที่หน้าหลักของ Lens ไปที่ Workloads > Pods ก็จะเห็นว่า pods ต่างๆ ที่เกี่ยวข้องกับ Lens Metrics ของเราเขียวแล้ว

Pods ที่เกี่ยวกับ Lens Metrics เขียวแล้ว

4.กดไปที่ Cluster หรือ Nods ก็จะเห็น Metrics ต่างๆ แสดงผลแล้วครับ

แสดง Metrics ของ k8s cluster ได้แล้ว

ขั้นตอนต่างๆ ก็ง่ายๆ ประมาณนี้ครับ เราก็จะได้ Lens Metrics ที่เป็น Dashboard & Monitoring สำหรับ ดู รายละเอียดต่างๆ ของ k8s cluster ของเรากันแล้วครับ ..

Update!!! (2021-09-25) Grafana Dashboard

วันนี้ มา update การทำ Dashboad & Monitoring ของ k8s cluster ที่จะดูได้ละเอียดกว่านี้ ด้วย Grafana ครับ ..

หลายๆ ท่าน คงอยากมี dashboard (Grafana) เอาไว้ดู metrics ต่างๆ ของ k8s cluster ของเรา ให้คนในทีมได้เอาไว้ดู ในทุกที่ ทุกเวลา .. ซึ่งเราก็สามารถติดตั้งได้ผ่าน Lens เลยครับ โดยมีขั้นตอน เพิ่มเติมดังนี้ ..

1.ไปที่ Apps > Charts แล้ว search “prometheus-operator”

prometheus-operator

2.กด install ใน namespace ที่เราต้องการ ในที่นี้ผม create ns ชื่อ prometheus มาเพิ่มเติม

หรือถ้าอยากลอง install เอง ก็สามารถทำตามขั้นตอน ของ prometheus-operator ได้ตามนี้เลยครับ ..
[Link] https://github.com/prometheus-operator/prometheus-operator

3.ไปที่ Network > Services จะพบ service ที่ชื่อ “prometheus-operator-xxx-grafana”

prometheus-operator-grafana

4.ทำการ login เข้า Grafana โดย default user-password สามารถดูได้ที่ Configuration > Secrets เลือกดู secret “prometheus-operator-xxx-grafana”

prometheus-operator-grafana-password

5.ไปที่ Dashboard จะเห็นว่า มี k8s cluster dashboard ที่จำเป็นมาให้เราเรียบร้อย

Grafana k8s Dashboard & Monitoring

เป็นอย่างไรกันบ้างครับ ไม่ยากเลยใช่ไหมครับ? แต่การที่เราจะ expose Grafana dashboard ของเรา ให้คนอื่น สามารถเข้ามาได้นั้น เราต้องมี ingress มาต่อ กับ service grafana ของเราด้วยนะครับ .. ในครั้งต่อไป ผมจะมาพูดถึงการสร้าง ingress ให้กับ k8s cluster ของเรากันครับ .. 🙂

Facebook Comments Box

DevOps 101 Jenkins set Time Zone

สวัสดีครับทุกท่าน DevOps 101 ของเราวันนี้ จะมาพูดถึงการ set Time Zone ของ Jenkins กัน .. ผมเชื่อว่าทุกคนคงเคยใช้ Jenkins กันมาแล้ว ก็เลยไม่ได้ลงรายละเอียดตรงส่วนของการใช้งาน Jenkins .. แต่อาจจะเขียนบทความแยก ในส่วนของการ ติดตั้งใช้งาน Jenkins และการสร้าง CI/CD Pipeline บน Jenkins (Jobs) แยกไปอีกบทความนึงนะครับ ..

โดยปกติแล้ว Jenkins จะอ้างอิงเวลา ที่เป็น UTC นะครับ .. เวลาเรา build Jobs เราอาจจะอยากดูเวลาที่เป็นเวลาประเทศไทย (UTC +7) เราก็ต้องนับ +7 เอาเอง ถึงจะเป็นเวลาจริงๆ ณ ตอนนั้น ใน Time Zone ของเรา .. แต่มี trick ง่ายๆ ในการ set ให้ Jenkins แสดงเวลา เป็น Time Zone ของเราครับ แบ่งเป็น 2 วิธีคือ ..

1.Set ให้ทั้งระบบแสดงเวลาให้ default เป็น Time Zone ที่เราต้องการ

เลือก Manage Jenkins > Script Console จากนั้น ใส่ script ดังนี้ครับ แล้วกด Run

System.setProperty('org.apache.commons.jelly.tags.fmt.timeZone', 'Asia/Bangkok')

2.Set การแสดงผล ของแต่ละ user ให้เป็น Time Zone ที่เราต้องการ

เลือก People > เลือก user เราเอง > Configure > User Defined Time Zone จากนั้นให้เลือก Time Zone ที่เราต้องการครับ

เสร็จแล้วจะเห็นว่า เวลาที่แสดง จะเป็นเวลาที่ตรงกับเวลา ที่เป็น Time Zone ของเราครับ ตัวอย่างผมใส่ Asia/Bangkok เวลาที่แสดง ก็จะเป็นเวลา ณ ปัจจุบัน ของประเทศไทยครับ

ก็สั้นๆ ง่ายๆ นะครับ ในการปรับเวลาของ Jenkins ให้ตรงกับ Time Zone ของเรา ทำให้เราดูได้ง่ายขึ้นครับ .. 🙂

Facebook Comments Box

ออกแบบ DevOps Architecture CI/CD Pipeline ให้เหมาะกับงาน และองค์กร

DevOps Architecture CI/CD Pipeline

สวัสดีครับ .. DevOps 101 ของเรา วันนี้มีโจทย์ มาอันนึงครับ ให้ออกแบบ Architecture, Tech Stack และ CI/CD Pipeline ของ Application ที่มีคนใช้งานจำนวนมาก app นึง ให้กับองค์กร ขนาดใหญ่ ระดับพนักงาน 200,000 คน ++ ..

จริงๆ ในการออกแบบ ไม่มีอะไรถูกอะไรผิดครับ .. หลักการง่ายๆ ก็คือ “Simply the best” .. ทำให้ deploy ง่ายๆ .. รองรับ load สูงๆ ให้ได้ .. มีระบบ Monitoring ที่ดี .. และเหมาะสม กับงานและองค์กร ..

เนื่องจาก ทางองค์กร มี Single Sign-On อยู่แล้ว ซึ่งสามารถใช้งานผ่าน AWS Cognito ได้ .. เราก็เลยสามารถ ใช้งานได้เลย และเอาไปต่อกับ CI/CD Tools ที่จำเป็นของเราได้ ไม่ว่าจะเป็น GitLab, Jenkins, Nexus Repository และอื่นๆ ในอนาคต ..

ในที่นี้ ตัว Application เราเลือกพัฒนาโดยใช้ Next.js เพราะว่า ต้องรองรับ user ที่เข้าใช้งานหลากหลาย ไม่ว่าจะเป็น บน Desktop และ Mobile .. และทางทีม Developer มีความเชี่ยวชาญในส่วนของ Next.js อยู่แล้ว .. ในส่วนของ CI/CD Tools เราเลือกใช้ Jenkins และทำ CI/CD Pipeline เป็น Jenkinsfile (Declarative Pipeline) แบบง่ายๆ stage ตรงไปตรงมา ใครมาอ่าน ก็เข้าใจ .. เพราะว่าอนาคต เราอยากเอา template นี้ ไป reuse ให้ทีมอื่น ในองค์กร เราได้ใช้ตามด้วย ..

ในส่วนของ Artifactory ที่ใช้เก็บ Docker Images และ binary files ต่างๆ เราเลือกใช้ Nexus Repository เป็น private repository ของเรา .. ส่วน SCM (Source Code Management) อันนี้จริงๆ เราคิดว่า เป็นอะไรก็ได้ ไม่ว่าจะ github, gitlab, ecr, bitbucket .. แต่องค์กรเรามี GitLab อยู่แล้ว ก็เลยใช้ตัวนี้ไปเลย .. ส่วนของ static code scan เราเลือกใช้ SonarQube แต่สิ่งที่เราอยากดูจริงๆ ก็เป็นส่วนของ code coverage มากกว่า ..

ในส่วนของ Server ที่เราจะใช้ในการ deploy ตัว Application ของเราขึ้นไป เราเลือกใช้ Amazon EKS (มันคือ k8s cluster บน AWS) เพราะว่าเราไม่ต้องวุ่นวายในการสร้าง k8s cluster ขึ้นมาใช้งานเอง และตัว cost ของ Amazon EKS ก็ไม่ได้แพงกว่า EC2 ธรรมดา เท่าไรนัก ..

ทำไมถึงเลือกใช้ EKS ไม่ใช้ ECS ?

– ผมเองต้องออกตัวไว้ก่อนครับ ว่าความรู้เกี่ยวกับ ECS ของผม แทบจะเป็น 0 .. แต่จากการได้เข้า training กับ AWS ในส่วนของการใช้งาน ECS + DevOps .. ทำให้ผมพอได้รู้บ้างว่า ตัว ECS ทำงานอย่างไร .. เราสามารถ ทำอะไรกับมันได้บ้าง .. ทำให้ผมตัดสินใจได้ทันที ว่างั้นเราไป EKS เถอะ .. เพราะว่า ในการทำ Application ที่รองรับคนใช้งานจำนวนมากนั้น .. การ scale และการ monitoring metrics ต่างๆ ถือว่าเป็นเรื่องสำคัญมาก ซึ่งผมเองคิดว่า EKS ที่เป็น k8s cluster eco system มัน flexible กว่า .. อาจจะเป็นเหตุผลที่เอนเอียงนิดหน่อย จากการที่ผมคุ้นเคยกับ Container Platform ที่เป็น k8s ด้วย .. (k8s, OpenShift)

ในส่วนของ Dashboard & Monitoring Tools ในที่นี้เราเลือกใช้ APM (Application Performance Monitoring) + ELK Stack ในการ monitoring Application ของเรา ที่เป็น Next.js .. ในส่วนของตัว EKS (k8s Cluster) เราเลือกใช้ Lens + Prometheus เป็น manage และ monitoring metrics ต่างๆ .. แต่ตัว Lens เอง มันคือดูแบบ เครื่องใครเครื่องมัน .. อนาคต ถ้าเราอยากทำเป็น dashboard ให้ทั้งทีม ได้ดูผ่านจอ TV LED ร่วมกัน ก็น่าจะเอา Grafana มาทำ dashboard ในส่วนนี้ .. ส่วนตัว Alert Notification เราใช้เป็น webhook ของ MS Teams เพราะว่าทีมเรา และองค์กรเรา ใช้ MS Teams เป็นหลัก ในการทำงานอยู่แล้ว ..

Tech Stack

– Next.js
– GitLab
– Jenkins
– Nexus Repository
– SonarQube
– nginx
– Docker
– Kubernetes (k8s)
– AWS Cognito
– AWS EKS
– Elasticsearch
– Logstash + APM
– Kibana
– Prometheus
– Lens/Grafana
– Microsoft Teams

Jenkins Pipeline Examples

https://github.com/pornpasok/demo-app-k8s

สำหรับท่านใด ที่สนใจ ในการออกแบบ Architecture, Tech Stack และ CI/CD Pipeline ก็สามารถ มา comment พูดคุย แลกเปลี่ยน ปรึกษากันได้ตรงนี้นะครับ .. อย่างที่ผมเน้นย้ำตลอด ไม่มีแบบไหนผิด แบบไหนถูก .. แต่แบบไหนที่เหมาะกับเรา นั่นแหละ คือดีที่สุด ครับ .. 🙂

Facebook Comments Box

DevOps 101 Amazon EKS Upgrade node group (instance type)

Amazon EKS

วันนี้มีเรื่องเร่งด่วน เกี่ยวกับ การ scale out Amazon EKS ก็เลยมาเขียนไว้ กันลืม .. และเป็นการแบ่งปันความรู้ เผื่อเพื่อนๆ ท่านอื่น เจอปัญหาแบบผม และต้องการแก้ไข ให้เร็วที่สุด ..

Elastic Kubernetes Service (Amazon EKS) เป็นอีก service นึงบน AWS ที่เป็นที่นิยมใช้งานกัน ทำให้เราไม่ต้องยุ่งยาก ในการสร้าง kubernetes (k8s) cluster เอง .. โดยเราสามารถ create k8s cluster ของเราขึ้นมาใช้ได้ง่ายๆ ดังนี้ ..

0. Create EKS Cluster

eksctl create cluster \
--name tono-eks \
--version 1.19 \
--region ap-southeast-1 \
--nodegroup-name t3-medium \
--node-type t3.medium \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--ssh-access=true \
--ssh-public-key tono-eks \
--managed --profile tono-admin

0.1 Update kubernetes config

จากนั้น ให้เราทำการ update kubernetes config (~/.kube/config) ด้วยคำสั่ง ..

aws eks --region ap-southeast-1 update-kubeconfig --name tono-eks --profile tono-admin

เพียงเท่านี้ เราก็จะมี k8s cluster ของเราไว้ใช้งานแล้วครับ .. ซึ่งถ้าเรา install เองแบบ k8s hard way จะยุ่งยากมากกกกกก (ก.ไก่ ล้านตัว) +___+

*** เพิ่มเติม –profile tono-admin คือให้ ไปใช้ profile ที่ชื่อ tono-admin ที่เรา config ไว้ใน ~/.aws/credentials

 

แต่เรื่องมันไม่จบเพียงเท่านี้ครับ .. เมื่อเราใช้ไปสักพักนึง EKS Cluster ที่เราสร้างขึ้นมาใช้งาน อาจจะไม่เพียงพอที่จะรองรับ load สูงๆ ได้ .. ที่หน้า console ของ AWS EKS เอง จะมีแค่ให้เลือก เพิ่มจำนวน worker node เท่านั้น ไม่สามารถ แก้ไข instance type เพื่อเพิ่ม spec ได้โดยตรง .. (ทำได้ แต่ต้องไปแก้ Auto Scaling groups ซึ่งยุ่งยาก พอสมควร) แต่เรามีวิธีการใช้ CLI eksctl ในการปรับแต่ง EKS Cluster ของเรา ง่ายๆ ดังนี้ครับ ..

ตัวอย่าง ผมจะเปลี่ยนจากเดิม ที่ใช้ instance type จาก t3.medium เป็น t3.xlarge และ version 1.19 –> 1.20 นะครับ .. ก็จะมี step ดังต่อไปนี้ ..

1. Check EKS node group

eksctl get nodegroups --cluster=tono-eks --profile tono-admin

CLUSTER NODEGROUP STATUS CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID ASG NAME
tono-eks t3-medium ACTIVE 2021-04-01T04:26:02Z 1 4 3 t3.medium AL2_x86_64 eks-cabc45d7-245e-c62e-ca22-bba57282fd0a

จะเห็นว่า ตอนนี้ spec ของ EKS Cluster เรา มีรายละเอียดดังด้านบน

2. Create new node group

eksctl create nodegroup \
--cluster tono-eks \
--version 1.20 \
--name t3-xlarge \
--node-type t3.xlarge \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--node-ami auto --profile tono-admin

รอจนเสร็จ จะขึ้น all nodegroups have up-to-date configuration

3. Delete old node group

eksctl delete nodegroup --cluster tono-eks --name t3-medium --profile tono-admin

รอจนเสร็จ จะขึ้น deleted 1 nodegroup(s) from cluster “tono-eks”

eksctl_delete_nodegroup

จากนั้นเราก็จะได้ EKS Cluster เป็น worker node ชุดใหม่ ครับ ดังรูป ..

lens_k8s_monitoring_tools

หรือถ้าไม่มี Lens (k8s monitoring tools) ไว้ดู status ของ EKS Cluster แบบผม ก็สามารถใช้ CLI kubectl ได้ครับ ดังนี้

4. Show EKS nodes

kubectl get node

NAME STATUS ROLES AGE VERSION
ip-192-168-31-151.ap-southeast-1.compute.internal Ready 13m v1.20.4-eks-6b7464
ip-192-168-54-97.ap-southeast-1.compute.internal Ready 13m v1.20.4-eks-6b7464
ip-192-168-74-140.ap-southeast-1.compute.internal Ready 13m v1.20.4-eks-6b7464

ปล. สำหรับท่านที่ใช้ k8s แล้วต้องการความสะดวก ในการ monitoring แนะนำ Lens ครับ สะดวกมากกว่าใช้ CLI (kubectl)
Lens: https://k8slens.dev/

เรียบร้อยละครับ เพียงเท่านี้ เราก็สามารถ เพิ่ม spec หรือ scale out EKS Cluster ของเรา ให้รองรับ load สูงๆ ได้แบบง่ายๆ และรวดเร็ว ทันใช้งาน ครับ 🙂

รายละเอียดเพิ่มเติม: https://docs.aws.amazon.com/eks/latest/userguide/migrate-stack.html

Facebook Comments Box

DevOps 101 Nexus Repository

สวัสดีครับ วันนี้ผมจะมาพูดถึง tools อีกตัวนึง ที่สำคัญมาก ในการทำ CI/CD นะครับ
นั่นก็คือ Repository ที่เอาไว้เก็บของต่างๆ ของเรา ไม่ว่าจะเป็น docker images, libs, หรือ files binary ต่างๆ ที่นิยมกัน ก็จะมี JFrog Artifactory กับ Nexus วันนี้ ผมจะมาพูดถึงเจ้า Nexus กันนะครับ ..

รายละเอียด เพิ่มเติม https://www.sonatype.com/products/repository-pro

ความสามารถของเจ้า Nexus นั้นมีมากมายมากครับ และมี version ที่เป็น OSS อีกด้วย

ส่วนตัวที่ผมใช้ ก็จะใช้เป็น docker repository กับ docker proxy เพื่อใช้งาน ในองค์กร ทั้งแบบ On-Prem และแบบ Public ครับ หลายๆ ท่านอาจจะคุ้นกับ docker hub จะคล้ายๆ กันเลยครับ ..

อธิบายเพิ่มเติมนะครับ

Docker Repository = ที่เก็บ docker images ของเราครับ มองว่าเป็น docker hub ส่วนตัว ประมาณนั้นครับ ..
Docker Proxy = มองว่าเป็น proxy ที่ไปดึง docker images จากที่อื่นอีกที เช่นไปดึงจาก docker hub อะไรพวกนี้ .. ที่ต้องมี docker proxy นอกเหนือจากช่วย caching docker images แล้ว บางที่ network ภายใน ไม่สามารถ access public โดยตรงได้ ก็เลยต้องใช้เป็น docker repository (docker proxy) ภายในแทนครับ ..

มาดูวิธีการติดตั้งกันครับ ในที่นี่ จะติดตั้งแบบใช้ docker นะครับ (อันนี้ตามสะดวกเลยครับ)

1. Create directory nexus-data

mkdir ~/nexus-data

2. Docker Run

docker run -d -p 8081:8081 -p 5000:5000 -p 5001:5001 --name nexus -v ~/nexus-data:/nexus-data sonatype/nexus3

ที่เรา expose ออกมา 3 port ก็เพื่อเอาไว้ จัดการเรื่องต่างๆ ดังนี้ครับ
– Port 8081 สำหรับหน้า Nexus Dashboard
– Port 5000 สำหรับ docker pull
– Port 5001 สำหรับ docket push

3. จากนั้นเข้า หน้า Nexus Dashboard ด้วย IP:PORT

http://localhost:8081/

4. จะขึ้นหน้า ให้เรา Login จาก password ที่ได้จาก file admin.password

cat ~/nexus-data/admin.password
89e5664b-f748-49e4-a7dc-cdcc3febdd6b

5. เมื่อทำการ update new password เรียบร้อยแล้ว จะเข้ามาที่หน้าแรกของ nexus ให้คลิกที่ รูปเฟือง แล้วเลือก Repositories > Create repositories

Create repositories

6. จะเห็นว่า มีให้เราเลือกเยอะแยะมากมาย ว่าจะ create repositories ประเภทไหนกันบ้าง ..

Select Recipe

ในที่นี้ ผมจะเลือกเป็น docker (hosted) เพื่อเอาไว้เก็บ private docker images ที่เอาไว้ใช้กันเองภายในองค์กร หน่วยงาน แทน public docker repository พวก docker hub ..

7. เลือก Create repository: docker (hosted) ใส่ค่าต่างๆ ประมาณนี้

Name: docker-private
HTTP: 5001 (Port 5001 จะเอาไว้ใช้ docker push)

Create repository: docker (hosted)

8. ต่อมาเลือก Create repository: docker (proxy) ใส่ค่าต่างๆ ประมาณนี้

Name: docker-hub
Remote storage: https://registry-1.docker.io
Docker Index: Use Docker Hub

Create repository: docker (proxy)

9. จากนั้นเลือก Create repository: docker (group) เพื่อรวม docker (hosted) และ docker (proxy) เข้าด้วยกัน ใส่ค่าต่างๆ ประมาณนี้

Name: docker-group
HTTP: 5000 (Port 5000 จะเอาไว้ใช้ docker pull)

Create repository: docker (group)

ตรงด้านล่าง ในส่วนของ Group

Member repositories: ให้คลิกเลือก docker-private และ docker-hub มาอยู่ในส่วนของ Members

Member repositories

*** เพิ่มเติม ***

สำหรับ docker repository ที่ URL ไม่มี SSL (https) เราต้องทำการ set เพิ่มเติม ในส่วนของ Docker Desktop ให้รองรับ insecure-registries โดยไปที่ Preferences > Docker Engine จากนั้น เพิ่มส่วนนี้ลงไป ..

“insecure-registries”: [“IP:5000”, “IP:5001”],

โดย IP ก็คือ IP ของ Server เรา หรือถ้าเป็น domain ก็ใส่ ชื่อ domain ลงไป

insecure-registries

ในกรณีที่เรา ต้องการ ให้ docker pull ได้แบบ anonymous ไม่ต้องมีการ login
ให้มาติ๊กที่ Allow anonymous docker pull: ในส่วนของ docker-group ครับ

Allow anonymous docker pull:

จากนั้น ให้ไปที่ Realms เลือก Docker Bearer Token Realm เป็น Active

Docker Bearer Token Realm

จากนั้นไปที่ Anonymous Access ติ๊ก Allow anonymous users to access the server ในส่วนของ Realm: เลือก Docker Bearer Token Realm

Anonymous Access

มาถึงวิธีการทดสอบครับ

ให้เราลอง ทดสอบง่ายๆ ประมาณนี้

# Docker Login
docker login http://IP:5000
docker login http://IP:5001
# Docker Pull
docker pull IP:5000/nginx
# Docker Build
docker build -t IP:5000/demo-app .
# Docker Tag
docker tag IP:5000/demo-app IP:5001/demo-app
# Docker Push
docker push IP:5001/demo-app 
# Docker Run
docker run -p 5000:5000 IP:5000/demo-app 

เพียงเท่านี้ เราก็จะได้ docker repository ของเราเองมาใช้แล้วครับ 🙂

แล้วพบกับ การแนะนำ tools ต่างๆ ที่จำเป็น และมีประโยชน์ สำหรับ DevOps (CI/CD) ในตอนต่อไปเร็วๆ นี้ครับ ..

Facebook Comments Box

trick ในการใช้งาน IoT SIM แบบไหนประหยัดสุด?

true แบบเติมเงิน

วันนี้ ผมจะมาเล่า trick เล็กๆ น้อยๆ ในการเลือกใช้งาน IoT SIM สำหรับ อุปกรณ์​ IoT ของเรากันนะครับ .. ว่าทำอย่างไร จะคุ้มค่าและประหยัดสุด ..และพูดถึงเหตุผลที่ทำไม ผมยังไม่เลือกใช้บอร์ด NB-IoT ของค่ายมือถือต่างๆ ..

ปัจจุบัน ค่ายมือถือ ไม่ว่าจะเป็น ais, dtac, true ต่างก็ออกบอร์ด NB-IoT ของตัวเองกันออกมา พร้อมกับแถม package data สำหรับ IoT ให้ด้วย .. แต่ราคาผมมองว่ายังสูงไปครับ คือประมาณ 2-3000 บาท/บอร์ด ..

ส่วนราคา โดยประมาณ สำหรับ package ที่แต่ละค่ายตั้งไว้ ก็ประมาณนี้ครับ
ais 350 บาท/ปี
dtac 420 บาท/ปี
true 330 บาท/ปี

ให้ data ประมาณ 10MB/ปี (น้อยมาก) แต่อุปกรณ์ IoT เรา ก็ใช้ส่ง data ขนาดเล็กเข้าไปเก็บใน server อีกทีนึงครับ ส่วนใหญ่จะเอาไว้ทำ Sensors Node กัน .. ไม่ได้ต้องการ data มากมายอะไร ..

สรุป ข้อดี/ข้อเสีย ของ บอร์ด NB-IoT ของค่ายมือถือ

ข้อดี
– สะดวก ใช้งานได้ทันที
– มีการรับประกัน ถ้าบอร์ดมีปัญหา

ข้อเสีย
– แพง ถ้าเรานำไปใช้งานหลายๆ จุด ก็จะใช้งบประมาณจำนวนมาก
– ไม่สามารถนำ SIM ไปใช้ร่วมกับอุปกรณ์อื่นได้ เพราะส่วนใหญ่เป็น e-SIM
– ไม่สามารถย้ายค่ายได้ เพราะบอร์ด ผูกติดกับค่าย

ด้วยเหตุผลด้านบน เมื่อเปรียบเทียบข้อดี ข้อเสีย ของบอร์ด NB-IoT จากค่าย ผมเลยยังไม่เลือกใช้งาน เพราะว่างานที่ผมทำ ต้องใช้หลายจุด ต้องใช้งบประมาณอย่างประหยัด .. และที่สำคัญ Wi-Fi เข้าไม่ถึง ก็เลยไม่สามารถใช้บอร์ด ที่รองรับระบบ Wi-Fi ได้ +___+

แล้วแบบนี้ ซื้อพวก SIM เทพใช้ จะคุ้มไหม?

– ไม่คุ้มแน่นอนครับ ด้วยเหตุผลด้านบน คือ เราใช้ data จริงๆ น้อยมาก พวก SIM เทพ เหมาะกับคนที่ใช้ data จำนวนมากๆ ดูหนัง ฟังเพลง หรือ ทำเป็น AP ในพื้นที่ห่างไกลอินเตอร์เน็ตเข้าถึง .. บ้านผมเอง ก็ใช้ครับ ..

แล้วทำยังไง ถึงจะใช้อุปกรณ์ IoT ได้อย่างประหยัดดีล่ะ?

TTGO T-Call v1.4

– ใช้บอร์ดที่ใส่ SIM ได้ ราคาประมาณ​ 300-500 บาท
– ใช้ SIM ทรู แบบเติมเงินครับ data 1MB ประมาณ 1 บาท เท่านั้น เติม 10 บาท อยู่ได้ 30 วัน
1 ปี เราก็จะใช้เงินเพียงประมาณ 120 บาท เท่านั้นครับ ประหยัดกว่าเยอะ ..

ใครมี trick เพิ่มเติมอะไร ก็มาเล่าสู่กันฟังได้นะครับ หรืออยากสอบถามอะไรเพิ่มเติม ก็ comment เข้ามาได้ครับ 🙂

Facebook Comments Box

ESP Weather Station

ESP Weather Station


คลิปสอนทำ Weather Station แบบง่ายๆ ราคาไม่ถึง 300 บาท

สวัสดีปีใหม่ 2021 ครับ เพื่อนๆ พี่ๆ น้องๆ ทุกท่าน ขอให้ปีนี้เป็นปีที่ดีนะครับ 🙂
ปีที่ผ่านมา ผมเองก็ไม่ได้มา update blog ส่วนตัวเลยครับ +___+

วันนี้มีโอกาสดี ได้หยุดยาว กลับมาอยู่บ้านที่จันทบุรี ก็เลยถือโอกาส เขียนเล่าวิธีการ
ทำ Weather Station แบบง่ายๆ และราคาถูกมาก ไม่เกิน 300 บาท ที่ใครๆ ก็ทำเองได้ ..

ตัวอย่าง ที่ผมทำเล่น ไว้ที่สวนที่จันทบุรี จะประมาณนี้ครับ
https://tonofarm.herokuapp.com/

Weather Station Dashboard

ในส่วนของ Dashboard ที่ใช้แสดงผล จะใช้ของฟรี บน Cloud ของ Heroku นะครับ (ฟรีแต่ต้องเอามาประกอบร่างกันเอง + Coding นิดหน่อย)
ถ้าใครยังไม่เคยใช้งาน Heroku ลองเข้าไปอ่านบนความที่ผมเคยเขียนไว้ ได้ครับ ..
https://ton.packetlove.com/blog/iot/line-bot-node-js-mqtt-esp32-iot-2.html

Stack ในส่วนของ Dashboard ที่ผมเลือกใช้ จะเป็น PHP+MySQL ที่ทุกคนสามารถเรียนรู้ได้ง่าย และรวดเร็ว และส่วนของ graph Time series จะเป็น Highcharts ที่ใช้งานได้ง่ายมาก ..

ส่วนของ Hardware จะใช้เป็น ESP8266 (NodeMCU v3) + BME280 Sensor (Temperature, Humidity, Pressure) แค่นี้ ก็ใช้งานได้ละครับ ..
แต่ถ้าใครอยากได้ Options เสริม ทำให้ สามารถนำ Weather Station ของเราไปตั้งที่ไหนก็ได้ ก็ต้องเพิ่ม ในส่วนของ Battery ซึ่งในที่นี้ ผมเลือกใช้เป็น 18650 1 ก้อนครับ + Solar Panel + TP4056 1A Micro USB Battery Charger แค่นี้ก็เหลือๆ อยู่ได้สบายๆ เป็นปีๆ ครับ เพราะว่า ใช้เทคนิค ที่เรียกว่า Deep Sleep Mode ทำให้ Weather Station ของเรา ประหยัดพลังงานได้มาก ..

สรุป Stack ที่เราจะใช้ และ อุปกรณ์ ที่เราจะต้องใช้กันมีประมาณนี้ครับ สามารถดัดแปลงแก้ไข ได้ตามความเหมาะสม ..

มาเริ่มกันเลยดีกว่าครับ .. 🙂

0.ความรู้ที่ต้องมี ในบทความนี้

– การใช้งาน Arduino IDE เบื้องต้น
– การเขียน HTML, PHP เบื้องต้น
– การใช้งาน DB MySQL (MariaDB) เบื้องต้น
– การใช้งาน Git เบื้องต้น
– ตัวอย่าง code https://github.com/pornpasok/esp-weather-station

1.เตรียมอุปกรณ์

Hardware
– ESP8266 หรือ ESP32 ก็ได้ครับ ในที่นี้ผมใช้ NodeMCU v3 ราคา 54 บาท
– BME280 (Temperature, Humidity, Pressure) ราคา 80 บาท

Options
– Battery 18650 1 ก้อน ราคา 50 บาท
– Solar Panel 6V ราคา 30 บาท
– TP4056 1A Micro USB Battery Charger ราคา 8 บาท
– กล่องกันน้ำ IP66 ราคา 90 บาท

2.สมัครใช้บริการ Heroku สำหรับใช้งาน PHP+MySQL

– ทำตามที่ผมเคยเขียนไว้ในบทความก่อน ได้เลยครับ
https://ton.packetlove.com/blog/iot/line-bot-node-js-mqtt-esp32-iot-2.html
– เลือก Add-ons JawsDB Maria (ฟรีนะครับ)

JawsDB Maria

3.จากนั้นเราจะได้ หน้าตา Dashboard สำหรับ DB ของเรา ซึ่งจะมีค่าต่างๆ ที่จำเป็นดังนี้

Host: xxxx.cbetxkdyhwsb.us-east-1.rds.amazonaws.com
Username: xxxjmq9y0lbpccfl
Password: xxxqfwd3ch9ynzom
Port: 3306
Database: xxxt7s4yvc54h02i

DB Information

4.ทำการ Clone Soure Code ที่ผมทำไว้ให้เป็นตัวอย่างลงมา

– git clone https://github.com/pornpasok/esp-weather-station
– จะมี files ต่างๆ ประมาณนี้

tree
.
├── NodeMCUv3_BME280_deepsleep.ino (สำหรับ Upload ลง ESP8266 ของเรา)
├── README.md
├── SensorData.sql (สำหรับ import DB Structure ลง DB ที่ Heroku)
├── esp-database.php (สำหรับ config การ connect DB ที่ Heroku ค่านี้ได้จากข้อ 3.)
├── esp-post-data.php (สำหรับ รับค่าจาก อุปกรณ์ IoT ของเรา ในที่นี้คือ ESP8266)
├── esp-style.css (สำหรับ ตกแต่งหน้าตา Dashboard)
├── images
│   ├── dashboard01.png
│   ├── dashboard02.png
│   ├── dashboard03.png
│   └── esp-weather-station.jpg
└── index.php (หน้าแสดงผล ของ Dashboard)

5.Import DB Structure ลง DB ที่เราได้จาก Heroku

– ในที่นี้ ใช้ได้หลายวิธี แล้วแต่ถนัด แต่ส่วนตัวผมใช้ extensions “MySQL Client for vscode
– จากนั้น ให้นำค่า Host, Username, Password, Port ที่ได้จาก ข้อ 3. มา config เพื่อใช้งาน
– จากนั้นคลิกขวา ที่ DB เลือก Import Sql แล้วเลือก file “SensorData.sql” ที่เราทำการ clone มาจาก ข้อ 4. แค่นี้ เราก็จะได้ โครงสร้างของ tables ใน DB ของเราแล้ว ..

vscode Import Sql

6.แก้ไข config file “esp-database.php” และ “esp-post-data.php”

– นำค่า Host, Username, Password, Database ที่ได้จาก ข้อ 3. มาแก้ไข ใน file “esp-database.php

$servername = "HOSTNAME";
$dbname = "DBNAME";
$username = "USERNAME";
$password = "PASSWORD";

– แก้ไข file “esp-post-data.php” ใสส่วนของ

$api_key_value = "********";

ค่า api_key_value เรากำหนดเองได้เลย และจะต้องเอาไปใช้ ในส่วนของ อุปกรณ์ IoT (ESP8266) ของเรา

7.ทำการ push App (Dashboard) ของเรา ขึ้น Heroku

– ทำตามนี้ได้เลยครับ https://devcenter.heroku.com/articles/getting-started-with-php

เท่านี้ เราก็จะได้ App (Dashboad) ในฝั่งของ Heroku Cloud กันแล้วครับ .. 🙂
มาต่อกันที่ฝั่งของ อุปกรณ์ IoT (ESP8266) ของเรากันดีกว่าครับ ..

8.การต่อวงจร BME280 wiring to ESP8266/ESP32

The ESP8266 I2C pins are:
– GPIO 5 (D1): SCL (SCK)
– GPIO 4 (D2): SDA (SDI)

BME280 wiring to ESP8266

The ESP32 I2C pins are:
– GPIO 22: SCL (SCK)
– GPIO 21: SDA (SDI)

BME280 wiring to ESP32

9.ใช้ Arduino IDE แก้ไข code ในส่วนของ อุปกรณ์ IoT (ESP8266)

– แก้ไข file “NodeMCUv3_BME280_deepsleep.ino” ตามระบบ WIFI และ URL App เรา

const char* ssid = "WIFI-SSID";
const char* password = "WIFI-PASSWORD";
const char* serverName = "http://app-name.herokuapp.com/esp-post-data.php";
String apiKeyValue = "********";
String sensorName = "BME280";
String sensorLocation = "37.8718992,-122.2585399";

– จากนั้นทำการ Upload code แล้วเปิด Serial Monitor ดู ว่ามี Error อะไรไหม? ถ้าทุกอย่างปกติ ก็จะได้ข้อความดังภาพด้านล่าง ก็ถือว่าเป็นอันใช้ได้ 🙂

Arduino Serial Monitor

10.ทดลอง เข้า หน้าเว็บ Dashboard ของเรา ที่ทำไว้

– เข้าด้วย URL: https://app-name.herokuapp.com/
ตัวอย่างของผมคือ https://tonofarm.herokuapp.com/

ส่วน Options เพิ่มเติม ที่จะนำไปต่อยอด ก็ประมาณนี้ครับ

– ใช้ Battery 18650
– ใช้ Solar Panel + ชุด Charge Battery
– ใส่กล่อง IP66 กันน้ำ เผื่อเอาไปใช้ Outdoor
– เพิ่ม-ลด Sensors ตามความต้องการ
– ปรับแต่ง Dashboard ให้เหมาะสมตามความต้องการ

เป็นอย่างไรกันบ้างครับ ไม่ยากใช่ไหมครับ เอาไว้ทำเล่นๆ เราก็จะได้ Weather Station ของเราเองเอาไว้ใช้งาน และสามารถเข้าจากที่ไหน ก็ได้ เพราะอยู่บน Heroku Cloud ที่สำคัญ ฟรีด้วยครับ 🙂

สำหรับเพื่อนๆ ท่านใด ที่ติดปัญหา ตรงไหน สามารถสอบถามกันเข้ามาได้นะครับ
LINE ID: pornpasok

LINE ID: pornpasok

Add Friend

Source Code: https://github.com/pornpasok/esp-weather-station

รายละเอียดเพิ่มเติม: https://randomnerdtutorials.com/cloud-weather-station-esp32-esp8266/

Facebook Comments Box

สวัสดี ปีใหม่ 2020 ครับ

Happy New Year 2020

สวัสดีปีใหม่ 2020 ครับ เป็นประจำทุกปี ที่จะต้องมา update เรื่องราวระหว่างปี ที่ผ่านไป เพื่อเก็บไว้เป็นความทรงจำ

สำหรับปี 2019 ที่ผ่านมา นับว่าเป็นปี ที่มีความเปลี่ยนแปลงอย่างมาก ต้องย้ายถิ่นฐานที่อยู่ ไปหลายแห่ง ตามงานที่ทำ ทั้งย่าน บางนา, Big C รามคำแหง, เมืองทองธานี, อารีย์ งานที่ทำหลักๆ ก็ยังเป็นทางด้าน DevOps CICD, AI, และงานที่ปรึกษา ในด้านการวางระบบ ว่าทำอย่างไร จะทำให้ระบบ รับ load สูงๆ ได้ โดยการนำเอา Open Source มาใช้งาน ให้เกิดประสิทธิภาพสูงสุด และลดค่าใช้จ่าย ในการซื้อ Software และ License ให้ได้มากที่สุด ..

สำหรับปี 2020 นี้ งานที่ทำ จะเป็นงานที่ท้าทายมาก ต้องเปลี่ยนตัวเองเยอะมากเหมือนกัน จาก stack ที่ไม่คุ้นเลย ทางฝั่ง Microsoft มาเป็น Open Source บน Container Platform แต่ถ้าทำได้สำเร็จ ก็จะเป็นสิ่งที่ดี สร้าง value ให้องค์กร ได้เยอะมาก เลยทีเดียว ..

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

ในด้านการเดินทาง ปีที่ผ่านมา ถือว่าเดินทางน้อยกว่าปีอื่นๆ มาก เพราะว่า ทำงานประจำ หาเวลา เดินทางทีละหลายวันยาก แต่ปีนี้ ถ้าอะไรเข้าที่เข้าทาง ก็น่าจะพอมีเวลามากขึ้น ยังมี checklist ที่ที่อยากไป อีกเยอะมาก ในโลกนี้ ถ้าไม่ไปช่วงนี้ ไม่รู้จะไปช่วงไหน ..

Facebook Comments Box

ทดสอบการใช้งาน OpenShift 4.2 (OCP4)

OCP4 (OpenShift 4.2)

สวัสดีครับ หลังจากที่ทดลองใช้งาน OpenShift 4.2 มาเดือนกว่าๆ ตั้งแต่เริ่มต้น Prepair Architecture
และร่วมกับ Vendor จากทาง Red Hat (MFEC) ทำการ Install ตลอดจนการแก้ไข จนเริ่มต้นใช้งานได้
เลยจะมาเขียนสรุปไว้เป็นความคิดเห็นสำหรับผู้ที่สนใจ จะใช้งานตัว OpenShift Container Platform (OCP4)

สำหรับตัว OpenShift 4.2 มีอะไรใหม่ๆ ออกมาเพิ่มเติมจาก 3.xx เยอะมาก อ่านรายละเอียดได้ที่
https://blog.openshift.com/introducing-red-hat-openshift-4-2-developers-get-an-expanded-and-improved-toolbox/

ในความคิดเห็นส่วนตัว สำหรับผม ที่ได้ลองเล่น ลองผิดลองถูกมาบ้าง ขอแบ่งเป็นข้อๆ ดังนี้

ข้อดี
– เป็น Enterprise Container Platform สำหรับ On-Premise ที่มี Support จาก Red Hat
– ใช้งานง่าย มี Template สำหรับหลายๆ Language ยอดนิยม, Database ที่เป็น Open Source และ CI/CD Tools
– มี Web Console ที่มี UI ใช้งานได้ง่าย แบ่งเป็น 2 Level คือ Developer/Admin
– มี CLI “oc” ที่ใกล้เคียงกับ “kubectl” ทำให้ใช้งานได้สะดวกสำหรับ คนที่ใช้ k8s มาก่อน
– สามารถ build microservices ได้จากหลากหลายวิธี จาก git และ template ที่มีมาให้
– สามารถมันจัดการ route ระดับ ingress ได้ดีมาก เราสามาถสำหนด endpoint ที่ต้องการได้ (HAProxy)
– มี Topology ที่ทำให้เห็น รายละเอียด และความสัมพันธ์ ระดับ service ได้ชัดเจน และจัดการตรงนี้ได้เลย
– มี Service Mesh ที่ทำให้รู้รายละเอียด ระดับ traffic ของแต่ละ service (Istio, Kiali and Jaeger)
– มี Images registry build-in มาด้วยในตัว
– มี Cloud-native CI/CD with Pipelines (Tekton) หรือจะใช้ Jenkins ด้วยก็ได้
– มี Dashboard และ Monitoring ที่ละเอียดจาก Grafana + Prometheus
– การใช้งานง่าย เหมาะสำหรับผู้เริ่มต้นใช้งาน Container
– Documents ตัว OpenShift จาก Red Hat เอง ค่อนข้างละเอียด และดีมาก

ข้อเสีย
– ราคาสำหรับตัว Enterprise ค่อนข้างสูง
– การ Install ระบบค่อนข้างวุ่นวาย ต้องใช้ การ config DNS และ LB ในการ Install
– เนื่องจากเป็น CoreOS ทำให้ มี tools ต่างๆ ในการวิเคราะห์ปัญหา ติดมาด้วยน้อยมาก
– สำหรับคนที่เคยใช้ Docker หรือ Kubernetes (k8s) มาก่อน ก็ใช่ว่าจะใช้งานง่าย +___+
– ด้วยความที่เน้น เรื่อง security ทำให้ หลายๆ Docker Images ไม่สามารถใช้งานบน OCP4 ได้

สำหรับใครที่อยากทดสอบการใช้งาน ก็เข้าไป Download ตัว Red Hat CodeReady Containers (CRC)
มาทดลองเล่นดูก่อนก็ได้ครับ (เครื่องต้องสเปคสูงหน่อย)
https://developers.redhat.com/products/codeready-containers

ผมเองก็ยังมือใหม่สำหรับ OpenShift 4.2 แต่แนวโน้ม บริษัทขนาดใหญ่ จะไปทางนี้กันหมด
ศึกษาไว้ ก็ไม่เสียหาย ใครที่ทดลองใช้งาน แล้วติดปัญหายังไง หรือมีอะไรจะแนะนำ
ก็เข้ามาพูดคุยกันได้นะครับ LINE ID: pornpasok 🙂

Facebook Comments Box

DevOps CI/CD คืออะไร?

CICD Flow

เนื่องในโอกาส ที่มาเริ่มงานใหม่ ด้าน Banking Technology (FinTech) ได้ครบ 1 เดือน ในส่วนของ DevOps เลยจะมาเขียนเล่าว่า การทำงานของ DevOps มีอะไรบ้าง CI/CD คืออะไร? ทำไมสมัยนี้ ถึงเป็นคำที่นิยมใช้กัน ในสายงาน software developer ..

DevOps จริงๆ แล้วเป็นคำใหม่ ที่เอาคำว่า Developer กับ Operator มารวมกัน สมัยก่อน Developer เป็นคนพัฒนา code แต่ไม่มีสิทธิ deploy code ขึ้นใช้งานเอง ต้องมีทีม Operator มาทำการ deploy ให้อีกทีม ซึ่งทั้ง 2 ทีมนี้เป็นคนละทีมกัน ทำให้การทำงานยุ่งยาก เกิดความผิดพลาด และใช้เวลานาน ในการ deploy แต่ละครั้ง ..

CICD

CI/CD (Continuous Integration, Continuous Delivery) เป็นกระบวนการในการทำงาน ตั้งแต่การ Plan -> Code -> Build -> Test -> Release -> Deploy -> Operate -> Monitor หรือบางทีเรียกสั้นๆ ว่า Pipeline ซึ่งสมัยนี้ ก็มี tools ต่างๆ ที่ทำหน้าที่พวกนี้ เยอะมากทั้ง On-Premise และ On-Cloud ที่เรารู้จักกันดี ก็น่าจะเป็น Jenkins ที่เข้ามามีบทบาทมาก ในการทำ CICD ..

ขอบเขตของการทำงาน ของ DevOps แต่ละที่เท่าที่ผมได้เคยลงไปสัมผัส จะไม่เหมือนกัน ขึ้นอยู่ว่า scope ที่ทำได้ มีระดับไหน บางที่ ก็คือทำตั้งแต่ต้นน้ำ ยันปลายน้ำ คือตั้งแต่วางแผน สร้าง Infrastructure เอง ทำ ENV ให้ Dev ใช้ เขียน Pipeline ตลอดจน ทำ Load Test, Performance Test, Security Test และระบบ Monitor & Alert เองทั้งหมด แบบนี้ก็ดีตรงที่จะรู้และเข้าใจ ในแต่ละส่วนอย่างดี ทำให้งานออกมามีประสิทธิภาพ ควบคุมได้ แต่ถ้ามี หลายๆ Project ก็คงทำแบบนี้ไม่ไหว ..

บางที่ DevOps จะมีหน้าที่แค่ทำระบบให้ Dev มาใช้งาน แต่จะไม่มีสิทธิ ในการทำอย่างอื่นเอง แบบด้านบน แบบนี้ ก็จะทำให้ ควบคุมอะไรไม่ได้ทั้งหมด แต่ถ้ามีหลายๆ Project ก็จะรองรับการทำงาน ได้เต็มที่ ..

สำหรับแนวคิด และ Tools ในการทำงานแบบ DevOps (CI/CD) ไม่มีแบบไหนผิด แบบไหนถูก ขึ้นอยู่กับการเอามาประยุกต์ใช้งาน ให้เหมาะสมกับงานของเรา องค์กรของเรา เพื่อทำให้งาน เกิดประสิทธิภาพสูงสุด ตอบโจทย์ผู้ใช้งาน product ของเราให้ดีที่สุด .. และที่สำคัญ ต้อง Monitor ได้ ต้องมี Dashboard เอาไว้ Tracking Metric ต่างๆ ได้ ..

สำหรับใครที่กำลังหางาน DevOps สมัครกันเข้ามาได้ครับ รับรองว่า งานท้าทาย สนุก แน่นอนครับ 🙂
https://th.jobsdb.com/th/th/job/devops-engineer-300003001969662

Facebook Comments Box