Make your own CI/CD pipelines: ใครๆ ก็ทำ CI/CD ของตัวเองได้ด้วย Rancher และ CircleCI

 

เมื่อวันอาทิตย์ที่ผ่านมา (10/06/2018) มีโอกาสได้ไปเล่า การทำ CI/CD ด้วยตัวเองมาที่งาน Code Mania 111: Diversity Makes Us Stronger 

ซึ่งเป็นที่มาของ Blog นี่ที่มีมูลค่าถึง 25,000+ บาท ไว้จะเล่าต่อว่าทำไม??

ไหนๆก็เตรียมสไลด์มาละ มีภาพประกอบละ ก็ถือโอกาสมาเล่าอีกครั้งในบล็อกร้างๆที่นี่ เผื่อสรุปให้ใครที่ไม่ได้เข้าฟัง

โดยคอนเซป ของครั้งนี้คือ ” ใครๆ ก็ทำ CI/CD ของตัวเองได้ด้วย Rancher และ CircleCI “

 

 

What is CI/CD ? 

ที่นี่ก่อนเราจะไปไกล เรามาตั้งคำถาม และ ตอบคำถามกันให้ชัดๆว่าเจ้า CI/CD นี่มันคืออะไร

Continuous integration , Continuous Delivery , Continuous Deployment  ก็คือชื่อเต็มๆของมัน และ เดววนะ แค่ CD ก็มีตัวย่อถึงสองคำ

แต่จริงๆจะบอกว่า เราอย่าไปสนใจชื่อมันเลย ดูรูป ก็น่าจะเข้าใจได้ในระดับหนึ่ง สำคัญคือ เรามองว่ามันคือ Process ตั้งแต่ Source ของเรา ในที่นี่ อาจจะเป็น GITHUB ไปจนถึงไหน เช่น CI เรา Focus กระบวนการต่างๆ ในขั้นตอน Build  หากให้เจาะภาพชัดขึ้น ก็คือ การทำ รวมไฟล์ การ Build ต่างๆนาๆ
แต่สำหรับ CD เรามองมันเป็น Process ที่ต่อเนื่องยาวไปจนถึงปลายทางซึ่งคือ Server ( Production หรือ Staging ) ก็ว่ากันไป

สรุป เราจะมาพาเอา Code ของเรา ไม่ว่ามันจะอยู่ที่ GITHUB หรือ ใครกำลังจะย้ายไป GITLAB เราจะถีบมันขึ้น Production อย่าง Automatic ว่างั้นเหอะ

 

Why we need CICD? 

โอเคมาลองดูว่า  Process ถ้าเราจะ Deploy Application ของเราคร่าวๆ เป็นยังไง ยกตัวอย่างถ้าเราเขียน Node.js สิ่ง basic สุดที่เราจะทำการ Deploy App ของเรานั้นก็คือการเริ่มที่จะ SSH ไปยัง Server จากนั้นรัน Git clone, npm install เพื่อติดตั้งสิ่งต่างที่จำเป็น , npm start สั่งรัน App ของเรา

 

ซึ่งมันอาจจะมองเร็วๆ เหมือนเออ ก็จริง ก็น่าจะมีแค่นี้ ไม่ใช่หรอ จะมาเสียเวลาเข้าฟัง Session นี้ หรือ เสียเวลาอ่านบทความนี้ต่อทำไม

โอเค ถ้าผมลอง เพิ่ม Process อีกหน่อย ถ้าเรามี Test ด้วยเราก็ควรรัน Test ก่อนขึ้น Production ถูกมั้ยครับ

 

มันก็ดูยังไม่ได้แย่อะไร ก็แค่พิมคำสั่งเพิ่มขึ้นบรรทัดนึง จะไปหนักหนาอะไร   ถูกมั้ย ก็ดูสบายๆ

 

 

แต่ถ้าเป็นภาพนี้ละ ? ถ้าเราไม่ได้ Deploy ไปแค่ Server เดียว แต่เราต้อง Deploy ไปอีก 4-5 Server ต่อ 1 Service

มันจะเริ่มไม่สนุกละ นึกภาพว่า หากเราแค่แก้ Bug หรือ อะไรเล็กน้อยๆ แต่ต้องรีบอัพเดทให้ user เราได้ใช้งาน

เราอาจจะ Fix Issue แค่ 10-15 นาที แต่เสียเวลาอีกเท่าไหร่ ในการไล่ SSH ไป Deploy App เราทีละ Server ละ

เรื่องนี้จะเริ่มมีบทดราม่าละ เริ่มจะไม่สนุกอีกต่อไป เชื่อเรา เราเจอมาแล้ว Y_Y

 

 

และยัง มันยังไม่จบ ถ้าหากคุณใช้ Docker แล้วด้วย Step ในการ Deploy ก็ยิ่งเพิ่มขึ้นอีกหลายขั้นเลย ไม่ว่าจะเป็น Build , push , pull , run

แค่คิดก็เหนื่อยแทนแล้วเอาจริงๆ

 

แนะนำพระเอกของเรา 2 คน

 

 

พระเอกคนแรก : CircleCI

ว่ากันสั้นๆ เจ้า CircleCI มันคือ online service (tools) ที่ออกแบบมาเพื่อ CI/CD โดยเฉพาะ จะเหมือนพวก Drone.io หรือ อื่นๆต่างๆนาๆ แต่ แต่

จะไม่เหมือนกับ Jenkins ที่ตาลุงนั้นถูกออกแบบมาให้เพื่อ Task Automate ซึ่งไม่ได้เจาะจงแค่ CI/CD ส่วนตัวเคยใช้รู้สึกว่ายังเหนื่อยเกินไป

ที่เราจะมาใช้มันเพื่อ CI/CD ไม่คุ้มสักเท่าไหร่

และ เจ้า circleCI ประสิทธิ์ภาพค่อนข้างดี Build เร็วสุดดด ใช้งานง่ายด้วยการเขียน Config เป็นหลัก

แถมมม สิ่งที่ชอบที่สุดคือ เราเขียน Config ใน sourcecode ของเรา แปลว่าเรา Commit มันไปกับ GIT ของเราด้วย เราสามารถเห็นการเปลี่ยนแปลง

จากอดีตถึงปัจจุบันได้ ไม่ต้องห่วงว่าอยู่ๆใกล้จะเปลี่ยนอะไรบน Service แล้วเราไม่รู้  เพราะหลักการของมันคือ ตัว CircleCI มันจะมาอ่านไฟล์ Config

ที่อยู่ใน Repo ของเราเอง

 

 

พระเอกคนที่สอง : Rancher

ถ้าจะให้นิยามมัน เราคงเรียกได้ว่ามันคือ Tools ที่รวมความสามารถในการบริหารจัดการ สร้าง ลบ ต่างๆนาๆ สำหรับ Server และ บริหารจัดการ Docker Container สำหรับ Deploy แอปของเรา ไว้ในตัวเดียว

แปลว่าอะไร แปลว่าเราสามารถใช้มันในการสั่งสร้าง Cloud service ขึ้นใหม่ หรือ สั่งลบ ได้จากตัว Rancher เอง โดย Official สามารถเชื่อมต่อได้หลายเจ้า ร่วมถึง DigitalOcean ด้วย  ที่นี่การจะใช้ Rancher Deploy แอปของเรา เราจะต้องผ่านการเตรียม Docker Image ที่พร้อมใช้งานก่อน

เพราะ Rancher มันทำหน้าที่แค่หยิบไอ้ Docker Image ไป Build ไป Deploy บน Server ต่างๆที่มันจัดการให้เรา

 

โดย Rancher ตอนนี้ มี 2 Version หลักๆ

  • Rancher 1.6 โดย นี้เปิดให้เราเลือกได้ว่าส่วนจัดการ Docker Contrainer เราจะใช้อะไร Cattle , Docker swarm, Kubernetes
  • Rancher 2.0 โดย เวอร์ชั่นนี้ Rancher ได้เปลี่ยนมา Focus ที่การใช้ร่วมกับ Kubernete เป็นหลัก เรียกได้ว่ามัน ในส่วนที่จัดอการ Docker contrainer มันผลักภาระไปใช้ Kubenete นั้นแหละ

โดยในบทความนี่เราจะ Focus ที่ Rancher 1.6 ด้วยความที่เราใช้ Rancher มาปีกว่าละ เริ่มจาก Version นี้มา ยังไม่ได้เปลี่ยนไป Rancher 2.0 ที่พึ่งจะเปิดตัวมาได้เดือนเศษ ส่วนตัวยังมีความกังวลในหลายๆจุด ด้วยความที่เป็นของใหม่ แน่นอนบัคต้องมาแน่นอนน ด้วยความที่ CI/CD ควรเป็นระบบที่เราต้องวางใจมันได้ระดับหนึ่ง ไม่ควรสร้างปัญหาเพิ่ม เราเอามันมาใช้เพราะต้องการลดเวลางานเรา ไม่ใช่มารับมือกับบัคที่ไม่รู้จะโผล่มาตอนไหน

 

สรุปภาพรวม

  • เราเก็บ Code ของเราไว้ที่ github / gitlab โดยใน Code ของเราจะมี config ของ circle ci ด้วย 1 ไฟล์
    • ทุกครั้งที่มีการ commit ,  push ขึ้น github จะส่ง webhook ไปบอก circle ci ให้ทำงาน
  • Circleci รับบทเป็นผู้ทำงานถึกแทนเราทั้งหมด
    • ไม่ว่าจะเป็น npm install , Docker build image , push  ทุกอย่าง
    • รวมถึงเป็นคนไปสะกิดบอก Rancher ให้ไปหยิบของ Docker image ไป Deploy ด้วย
  • Rancher ผู้ control ทุกอย่างที่เกี่ยวกับ Server
    • เมื่อ circleci มาสะกิด  rancher จะทำการ Deploy service เราไปยัง Server ต่างที่มันดูแลอยู่

 

และ Rancher ไม่ได้ใช้ Spec server สูงอะไร แค่แรม 2 GB ก็เพียงพอแล้ววว เอาจริงๆ

ซึ่งหากเรารัน Rancher ของเราที่ Scaleway


เพียง 150 บาทต่อเดือน  ก็เพียงพอสำหรับการที่เราจะมี CI/CD ของตัวเองแล้วว
ส่วน Circleci Plan Free สามารถใช้งานได้มากพอระดับหนึ่งเลย ถ้าจำไม่ผิดน่าจะ 1500 นาทีสำหรับการ build ต่อเดือน

 

4 Steps for making your pipeline

  1. Prepare your Rancher server
  2. Add new server (worker)
  3. Dockerfile
  4. Circleci config

 

Prepare your Rancher server

ในหน้าเว็บของ Rancher มีหลากหลายวิธีสำหรับการ Deploy มาก

  • SINGLE CONTAINER
  • SINGLE CONTAINER – EXTERNAL DATABASE
  • SINGLE CONTAINER – BIND MOUNT MYSQL VOLUME
  • Full Active/Active HA

แต่ในบทความนี้ เราจะโฟกัสกันที่ SINGLE CONTAINER – EXTERNAL DATABASE คือการ Deploy และเชื่อมให้เจ้า Rancher ไปใช้ Mysql ภายนอก

เพื่อไม่ให้ลำบากมานั่งดูว่าจะ setup ยังไง เราได้เตรียม docker-compose สำหรับงานนี้ให้เรียบร้อย

https://github.com/Ima8/Make-your-own-CI-CD-pipelines

แค่เอาไป docker-compose up -d จบ

Rancher ของขึ้นจะพร้อมทำงานที่ Port :8080 ในเวลาไม่นาน

 

!! คำเตือนกรุณา เปลี่ยน Password ใน Docker-compose.yml ก่อนนำไปใช้งานจริง  

 

Rancher first time

 

เรื่องที่สำคัญเรื่องหนึ่งเลยคือ หลังจากที่เข้ามาครั้งแรก กรุณา ได้โปรด เข้าไป Set access control ด้วยครัชชช ผมเจอหลายเคสที่เปิด โล่งๆ ไม่มีการ Set access control นานหลายเดือน

นั้นหมายความว่า ใครก็สามารถ Access มาจัดการ Server ของคุณได้อย่างอิสระนะ อย่าลืมว่าเราใช้ Rancher คุม server ของเรา ฉะนั้น ป้องกันอย่าให้ใครมา Access เจ้า Rancher.

และล่าสุดหลังจากที่เราไปบรรยายที่ CodeMania เนื่องจากเวลาเหลือน้อยเลยข้ามตรงนี้ไป เลยเป็นที่มาของงงง

 

มีใครสักคนเข้ามาที่ Rancher ที่เราไม่ได้ Set access control วันนั้น เนื่องจากตั้งใจว่าจะปิดหลังจากจบ Session แต่ด้วยความหมดพลังและลืมมันไป
สุดท้ายจึงเป็นที่มาของ 25 servers ที่งอกตามมา และ เลือก Package ที่แพงที่สุดดด!! WTF!! โกรธอะไรฉันนนนน  $885.92 พอคำนวณเป็นเงินไทยแล้วลมจับเลยยย

 

ฉะนั้นใครที่อ่านบทความนี้ จงเซ็ท Access control สะ

 

 

ส่วนประกอบหลักของ Rancher

 

  1. Environment : เป็นสร้างสภาพแวดล้อม โดยเราสามารถแยกสภาพแวดล้อมออกจากกันเป็นส่วนๆได้ และในจุดนี้เองเป็นตัวกำหนดว่าเราจะใช้อะไรในการ Manage Docker contrainer ของเรา ซึ่งส่วนตัวผมและบทความนี้เราจะใช้ Cattle กันครับ ซึ่งเป็น Product ที่ Rancher เป็นคนทำออกมาเอง
  2. Stack: เป็นการกรุ๊ป Service ไว้ด้วยกัน เช่น เราใช้สำหรับ Stack staging , หรือ Stack RabbitMQ เป็นต้น
  3. Service: คือตัว Service ที่เราจะรัน มองว่ามันคือ Docker image ที่เราจะรันก็ได้
  4. Container:  1 service สามารถเอาไปรันได้หลาย Container อาจจะ 1 server 1 container หรือ 1 server หลาย container ก็ได้ ขึ้นอยู่กับเราออกแบบยังไง เช่น ตัว Application เราอาจจะจำกัดว่า 1 contrainer ใช้ CPU ได้ 1 core ดังนั้นถ้าจะสเกลให้ใช้ได้หลาย CPU Core ก็จำเป็นที่จะต้อง Deploy หลาย Contrainer ใน 1 server เป็นต้น

 

Environment

โดยในการสร้าง Environment นั้น หลักการค่อนข้างตรงไปตรงมา เราต้องการ Environment ชื่ออะไร และ จะให้จัดการ Docker Contrinner ด้วย Platform ใด ไม่ว่าจะเป็น Cattle( ส่งที่ Rancher เป็นคนทำเอง) หรือเจ้าอื่นๆ ไม่ว่าจะเป็น Kubernetes ก็เช่นกัน ซึ่งในบทความวันนี้เราจะโฟกัสไปที่การใช้ Cattle ซึ่งมันค่อนข้างง่ายและตรงไปตรงมา ปัจจุบันผมใช้เจ้านี้มาก็ไม่เจอปัญหาจุกจิกกวนใจอะไร 

 

 

Add new stack

 

การ Add stack ก็เสมือนการที่เรากรุ๊ป Service ของเราเป็นส่วนๆนั้นเอง เช่น Stack สำหรับ Message queue อย่าง RabbitMQ , Stack สำหรับ web frontend เป็นต้น

โดยการสร้าง Stack ใหม่เราจะสร้างแบบง่ายๆ แค่ตั้งชื่อ อย่างเดียวก็ได้ หรือ เราอยากจะสร้าง Stack พร้อมกับ สร้าง Service ภายใน Stack ของเราด้วยการใช้ Docker-compose และ Rancher-compose ในครั้งเดียวเลยก็ได้

โดยความแตกต่างระหว่าง Docker-compose และ Rancher-compose คือ

  • Docker-compose เป็นตัวจัดการด้าน Image สิ่งที่เราจะ Deploy ว่า Deploy อะไร หรือ Service ไหน link กับ Service ไหน เสมือนเราเขียน Docker-compose ปกติเลย
  • Rancher-compose แต่สิ่งที่เพิ่มขึ้นมาอย่างเจ้านี้คือ การที่จะมาเป็นตัว Control ภาพรวมอีกที เช่น กำหนดว่าจะให้ Deploy service ใน Docker-compose นั้นกี่ contrainer  หรือ การเขียน config สำหรับ
    health_check เพื่อให้ตัว Rancher คอยเช็คได้ว่า Service ที่เรากำลัง Deploy นั้น ให้ดู health check ที่ port ไหน หรือ Path ไหนอะไรยังไง เป็นต้น

 

จากภาพเป็นตัวอย่าง Stack ที่ชื่อ “Staging” ซึ่งเราทำการกรุ๊ป Service ต่างๆ สำหรับ Staging ไว้ตรงนี้ เผื่อให้ง่ายต่อการ Monitor และ จัดการ ต่างๆนาๆ  โดยในหน้านี้เราจะเห็นได้ว่ามันจะแสดงเลยว่า Service ของเรานั้น ชื่ออะไร , รันด้วย Docker image อะไร , รันอยู่กี่ Containner

 

 

ตัวอย่างการสร้าง Service ใหม่ ซึ่งเพื่อนๆสามารถไปลองเล่น ลองสร้างได้เลย ซึ่งในงานก็มีการทำ Demo เพื่ออธิบายสเตปการสร้างต่างๆนา โดยหลักๆ ตรงนี้ แค่เราตั้งชื่อ และ ระบุว่าจัด Deploy ด้วย Docker Image อะไร ซึ่งประกอบอื่นๆเราสามารถค่อยๆเล่น ค่อยๆศึกษาได้ภายหลัง

 

Add new server (worker)

 

ด้วยหนึ่งในความสามารถหลักของ Rancher นั้นคือการจัดการ Server (Cloud server) ให้เราด้วย ไม่ว่าจะเป็นการ สร้าง ลบ และ แก้ไขบางอย่าง ทำให้เราแทบไม่ต้องขยับไปข้างนอก Rancher เลย

วิธีการค่อนข้างง่ายและตรงไปตรงมาเสมือนเราใช้งานผ่านหน้าเว็บของ Cloud เจ้านั้นๆเลย

 

ยกตัวอย่างเช่น ถ้าหากต้องการจะให้ Rancher ไปสร้าง Server ที่ DigitalOcean ให้ เราแค่ไปนำ Access Token จากหน้าเว็บมาผ่านการคลิกลิงค์ “Apps & API” แล้วนำ Access Token นั้นมากรอก จากนั้นเราก็แค่คลิกๆ เลือกๆ แต่ละ option เช่น Region ไหน , Size ไหน เป็นต้น

 

ในการสร้าง Server เจ้า Rancher จะทำการสร้าง Private-Public key ให้เองเลย แล้วทำการไปผูกกับ DigitalOcean ให้เรียบร้อย ทำให้มีความปลอดภัยสูงมาก เนื่องจากจะล็อกอินเข้า Server ที่สร้างใหม่นั้น ทำได้เพียงต้องอาศัย Pair key ดังกล่าวเท่านั้น

 

ฉะนั้นย้ำอีกครั้ง เราต้องรักษาให้ Server Rancher ของเรารอดปลอดภัย มีความปลอดภัยมากที่สุด ไม่ว่าจะเป็นการอย่าลืมตั้งรหัส ทั้งตัว Rancher เอง และ รหัสสำหรับตัว Server ที่ Rancher อยู่ก็ควรมีความปลอดภัยที่เพียงพอ

 

Dockerfile

การที่จะ Deploy application ของเราด้วย Rancher นั้น ทุกอย่างจะต้องถูก Deploy ผ่าน Docker เท่านั้น  นั้นหมายความว่าเราจะต้องเตรียม Docker image ของเราที่ภายในประกอบไปด้วย Application ที่พร้อมรันเลย

 

ตัวอย่าง Dockerfile นี้ คือการสร้าง Docker image สำหรับ Nodejs application   ซึ่งข้อสำคัญคือ จะต้องทำการ Build และ Push Docker image นี้ขึ้นไปยัง Dockerhub หรือ Docker registry ใดๆ ก่อน เนื่องจากตัว Rancher เองจะไม่ได้สามารถ Build Docker ได้ จะทำเพียงการหยิบ Docker image มาใช้ตรงๆเลย ซึ่งตรงนี้ละเราจะผลักหน้าที่ให้ Circleci เป็นคนจัดการ Build และ Push Docker image ให้กับเรา

 

Circleci

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

 

ก่อนอื่นเลย ข้อดีอย่างหนึ่งที่ชอบของ circleci คือเราไม่ต้องมานั่งเขียนหรือกำหนดสิ่งที่จะให้มันทำที่อื่น เช่น Jenkins เราก็ไปเขียน Task ต่างๆที่จะให้ทำบนตัว Jenkins เอง แต่เจ้า Circleci เราแค่สร้างไฟล์ config ไว้ในโฟลเดอร์โปรเจ็คเราเลย จากนั้นมันจะหยิบไปอ่านเอง

แต่ Path ไฟล์จะต้องตามที่มันกำหนด นั้นก็คือ “ /.circleci/config.yml”

 

โดย โครงสร้างของไฟล์ Config จะมีหน้าตาประมาณนี้

  • version ตอนนี้มีให้เลือกเขียนได้ 1 หรือ 2 แต่ตัว Circleci เองพยายามผลักดันให้เปลี่ยนไปใช้ 2 ให้หมด ฉะนั้นตัวอย่างจากนี้ไปเราก็จะใช้ Version 2 เช่นกัน
  • Jobs เป็นการ Define job หรือ สิ่งที่จะทำ เป็นส่วนๆ เพื่อเราจะแยกการทำงานให้สามารถทำพร้อมกันได้
  • workflows เป็นการ หยิบ Jobs ให้มาสามารถ ที่จะรันมันไปพร้อมกัน ได้ เช่นเรา Define Job เป็น Build และ Test เราอาจจะสั่งให้มันทำแยกกัน แล้วสุดท้ายค่อยเขียนให้ Deploy หาก Test ผ่านก็ได้

ดูเพิ่มเติม https://circleci.com/docs/2.0/configuration-reference/

 

 

ตัวอย่าง Circleci config สำหรับการ Deploy nodejs Application หลังจากที่เรามี Dockerfile ที่พร้อมใช้งานแล้ว

โดยสิ่งที่ Circleci ไฟล์นี้ทำคือ สร้าง Task ชื่อ Build

และให้มี Base ในการ Build ครั้งนี้ เป็น Docker image ที่มี Nodejs มาให้แล้ว

Branches คือเป็นการบอกว่าเราจะให้ทำการ Build หรือ ทำงานต่อจากนี้ เฉพาะ Branch ที่กำหนดเช่นในเคสนี้ก็คือ Master และ Staging เท่านั้น

จากนั้น “Step” คือสิ่งที่จะให้ circleci มันทำได้อะไรบ้าง

  • checkout เป็น keyword ที่มันจะไปทำการ Checkout code ของเราจาก GIT ออกมาให้
  • RUN คือเราสามารถเขียน shell command ได้ ตรงนี้เลย
  • setup_remote_docker เพื่อให้เราสามารถใช้งาน Docker ในนี้ได้

อย่างในเคสเราครั้งนี้ สิ่งที่เราจะให้มันทำคือ

  1. สั่ง Yarn install เพื่อติดตั้ง Dependencies สำหรับ node js project ของเรา
  2. setup_remote_docker เพื่อเตรียม Docker ให้เราสามารถใช้งานได้
  3. Docker login ….. เพื่อที่เราจะได้จัดการ Push image ที่เราจะทำต่อจากนี้ไปยัง Docker hub ได้
    1. โดยในที่นี่ผมใช้ environment ช่วยในเก็บ username และ password เพื่อไม่ให้ password หลุดไปไว้ใน Code ของเรา บางทีเราอาจจะมีทีมที่ทำงานในกันหลายคน การที่ Password ฝังไว้ใน Repo เลย ย่อมไม่ใช่เรื่องดีแน่
  4. Docker build สั่ง Build image จาก Dockerfile ของเรา
  5. Docker push ส่ง docker image ของเราไปยัง Docker hub

มาถึงจุดนี้เรา ทำให้ทุกครั้งที่เรา Push Code ไปยัง Master หรือ Staging มันจะทำการ Build image ของเรา ให้พร้อมใช้งานละ

อีกสเตปสั้นๆคือ เราจะไปกระซิบบอก Rancher ยังไง ให้จัดการเอา Docker Image อันใหม่ของเราขึ้นไป Deploy ใหม่

 

Rancher api client

https://github.com/etlweather/gaucho

อีกหนึ่งพระเอกของเราเลย เป็น Python CLI tool สำหรับไปสั่งงาน Rancher ผ่าน API ของ Rancher ให้เราสามารถที่จะกระซิบไปบอกเจ้า Rancher ให้ทำงานต่างๆนาๆได้

 

 

โดยเพื่อให้ง่ายในการจัดการ เราก็จัดการใช้เจ้า gaucho ผ่าน Docker image ที่เขาทำไว้ โดยสิ่งที่เราต้องทำคือ ไปนำ Rancher access key และ secret key มากำหนดใน environment  ด้วย ส่วน cattle_url ให้เรากำหนดเป็น url ของ rancher ตรงๆเลยก็คือ http://0.0.0.0:8080/

แต่!! สิ่งหนึ่งที่สำคัญคือ เราต้องระบุ ID ของ Service ปลายทางที่เราจะสั่ง upgrade ด้วย

โดยวิธีดูก็คือ

 

 

เข้าไปที่หน้า Service นั้นๆ แล้วดูที่ url เราจะเห็นเลขตามลูกศรที่ชี้เลย แต่ละ service เลขจะไม่เหมือนกัน ให้เราเอาค่านี้ละไปเก็บไว้ใน environment  อย่างในตัวอย่างคือชื่อ RANCHER_API_SERVICE

เพียงเท่านี้ เราก็สามารถสั่งให้มัน upgrade service ของเราได้อย่างอัตโนมัติ แล้ว

 

conclude

ทั้งหมดทั้งมวล ทำให้เมื่อเรา Push โค้ดขึ้น Repo ของเรา มันจะส่ง Webhook ไปบอก Circleci และ Circleci จะไปแอบดู Config.yml แล้วทำตาม Step ต่างๆนาๆที่เรา สั่งมันไว้ ไม่ว่าจะเป็น yarn install , docker build , docker push และ กระซิบไปบอก Rancher ให้ Deploy service เรา

 

โดยทุกคนสามารถดูตัวอย่าง Code พร้อมใช้งานจริงได้ที่

github.com/Ima8/Make-your-own-CI-CD-pipelines 

 

หวังว่าทุกคนที่อ่านบทความนี้จะสามารถมี CI/CD pipelines ของตัวเองได้นะครับ 🙂

 

ขอบคุณที่อ่านจนจบ

สงสัยตรงไหน ทักเฟสมาคุยมาถามได้เลย FB: Issaret Prachitmutita

 

ขอบคุณครับ.

 

1 comment

Leave a Reply