คู่มือ: ปลายทางการดีพลอยและโดเมนของคุณเอง

การดีพลอยไปยังเซิร์ฟเวอร์ของคุณเองหมายถึงการมอบสิทธิ์เข้าถึงแบบใกล้เคียง SSH ให้กับเอเจนต์บนเครื่องที่คุณจ่ายเงินเอง ซึ่งอาจมีสิ่งอื่นอยู่แล้ว นั่นเป็นระดับความเชื่อใจที่ต่างจากการเผยแพร่ไปยังซับโดเมนฟรี และการตั้งค่าก็สะท้อนสิ่งนั้น — ไม่กี่ช่องกรอกครั้งเดียว จากนั้นการสร้างทุกครั้งหลังจากนั้นจะเหลือแค่การกดปุ่ม นี่คือสิ่งที่คนถามจริงๆ ก่อนและหลังตั้งค่า

ต้องใช้อะไรบ้างในการสร้างเป้าหมาย?

ห้าอย่าง ใน การตั้งค่า → ดีพลอย:

1. ชื่อที่คุณจะจำได้ในภายหลัง — "prod-vps", "client-hostgator", อะไรก็ได้ที่ยังจำได้แม้อยู่ในดรอปดาวน์ตอนสี่ทุ่ม
2. โฮสต์และพอร์ต
3. ข้อมูลรับรอง SFTP
4. เส้นทาง webroot

ไม่ต้องใช้ API token ไม่ต้องติดตั้ง CLI บนเซิร์ฟเวอร์ ไม่ต้องคอยดูแล cron job ถ้าโฮสต์ของคุณให้สิทธิ์เข้าถึง SFTP — ซึ่งครอบคลุมเกือบทุกโฮสต์แบบแชร์ ทุก VPS ทุกกล่อง managed WordPress — คุณเสร็จภายในประมาณสองนาที

รหัสผ่านหรือคีย์?

คีย์ ถ้าโฮสต์ของคุณรองรับ รหัสผ่านก็ใช้งานได้ดีและเราจัดเก็บแบบผูกกับบัญชีของคุณ แต่คีย์คือความลับที่น้อยลงหนึ่งอย่างที่ต้องเก็บไว้ที่ไหนสักแห่ง — ความแตกต่างระหว่าง "เพิกถอนคีย์" กับ "รีเซ็ตรหัสผ่านทุกที่ที่บังเอิญใช้รหัสผ่านนั้นซ้ำ" หากมีอะไรผิดพลาดในภายหลัง การตั้งค่า SFTP ของโฮสต์แบบแชร์ราคาถูกจำนวนมากรองรับแค่การยืนยันตัวตนด้วยรหัสผ่านเท่านั้น ซึ่งก็ใช้ได้เช่นกัน แค่อย่าใช้รหัสผ่านนั้นซ้ำที่อื่น

จะหาเส้นทาง webroot ที่ถูกต้องได้อย่างไร?

นี่คือส่วนที่คนมักเข้าใจผิดในครั้งแรก เพราะคำตอบที่ผิดยังดูสมเหตุสมผล มันไม่ใช่โฮมไดเรกทอรีของคุณ ไม่ใช่ /var/www — มันคือโฟลเดอร์ที่แน่ชัดที่เว็บเซิร์ฟเวอร์ของคุณถูกตั้งค่าให้ให้บริการจาก

หากคุณไม่แน่ใจ ให้ลองวางไฟล์ทดสอบ test.txt ลงในโฟลเดอร์ที่คุณคิดว่าถูกต้องโดยใช้ SFTP client ใดก็ได้ แล้วตรวจสอบว่ามันโหลดได้ที่ yoursite.com/test.txtหากตั้งค่าผิด การดีพลอยจะยังคงรายงานว่าสำเร็จ — เอเจนต์เขียนไฟล์ลงในโฟลเดอร์ที่ผิดอย่างซื่อสัตย์ และคุณก็จะจ้องมองไซต์ที่ยังไม่เปลี่ยนแปลง สงสัยว่าทำไม

เป้าหมายเดียวครอบคลุมได้มากกว่าหนึ่งโดเมนหรือไม่?

ได้ และส่วนนี้คือสิ่งที่ประหยัดเวลาได้จริงเมื่อคุณผ่านไซต์แรกไปแล้ว เป้าหมายคือเซิร์ฟเวอร์เดียวและชุดข้อมูลรับรองเดียว — ไม่ได้ผูกกับโดเมนเดียว ใน การจัดการโดเมน คุณผูกแต่ละโดเมนกับเป้าหมายพร้อมการโอเวอร์ไรด์ webroot ของตัวเอง รันสามไซต์บน VPS เดียวด้วย Nginx server blocks?

• site-a → /var/www/site-a
• site-b → /var/www/site-b
• site-c → /var/www/site-c

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

เอเจนต์ทำอะไรจริงๆ เมื่อเชื่อมต่อ?

อันดับแรก มันจะสำรวจดูรอบๆ — แบบอ่านอย่างเดียว ยังไม่มีการเขียนอะไร การตรวจสอบนั้นเช็คหา:

• โฟลเดอร์ว่างเปล่า
• เวอร์ชันก่อนหน้าของการสร้างชิ้นนี้เอง
• การติดตั้ง WordPress เก่า
• ตัวยึดตำแหน่ง "เร็วๆ นี้" ที่โฮสต์ของคุณวางไว้เป็นค่าเริ่มต้น

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

• A .well-known โฟลเดอร์สำหรับการยืนยัน SSL
• ไดเรกทอรี uploads ที่ไม่มีใครใส่ไว้ใน git
• A wp-config.php ที่ไม่มีใครอยากให้แตะต้อง

งานตรงนี้ใกล้เคียงกับ "หาว่าอะไรเปลี่ยนแปลงแล้วปรับให้สอดคล้องกัน" มากกว่า "ลบทิ้งแล้วแทนที่"

จากนั้น ก่อนที่ไบต์เดียวจะถูกเขียนทับ webroot เดิมจะถูกจับภาพเป็นเวอร์ชันบนโฮสต์ของคุณเอง ไม่ใช่ระเบียนในฐานข้อมูล ไม่ใช่ diff ที่เราคำนวณแล้วหวังว่าจะถูกต้อง — แต่เป็นสแนปช็อตจริงของสิ่งที่อยู่ตรงนั้น สิ่งนี้สำคัญที่สุดในการดีพลอยครั้งแรกไปยังเป้าหมายใดๆ เพราะการดีพลอยนั้นจะลงทับ บางสิ่งเสมอ แม้ว่าสิ่งนั้นจะเป็นความว่างเปล่าก็ตาม โฟลเดอร์ว่าง ก็สแนปช็อตว่าง เว็บไซต์แบบ static อายุห้าปีที่ไม่มีใครจำได้ว่าสร้างขึ้นมาอย่างไร — ถูกเก็บรักษาไว้อย่างแม่นยำ โดยไม่มีค่าใช้จ่าย ก่อนที่จะถูกแตะต้อง การดีพลอยครั้งแรกนี้ยังเป็นครั้งที่คุณมั่นใจน้อยที่สุด จึงเป็นครั้งที่สิ่งนี้สำคัญที่สุด

มันอัปโหลดซอร์สโค้ดของฉันหรือไซต์ที่ build แล้ว?

ไซต์ที่ build แล้วเสมอ สำหรับไซต์แบบ static นั่นคือหน้าที่ถูกสร้างขึ้น สำหรับ framework build — Next.js, Vite, อะไรก็ตามที่ประเภทไซต์ต้องการ — มันคือผลลัพธ์ที่คอมไพล์แล้ว โฟลเดอร์ dist หรือ build ไม่ใช่ source tree ฉันคิดว่านี่เป็นทางเลือกที่ถูกต้อง แม้ว่ามันจะหมายความว่าคุณไม่สามารถ SSH เข้าไปและรัน npm run dev กับสิ่งที่อยู่บนเซิร์ฟเวอร์ได้ การอัปโหลดซอร์สโค้ดจะหมายความว่า production webroot ของคุณต้องการ Node runtime และ build toolchain เพียงเพื่อให้บริการ HTML — เปลี่ยนเซิร์ฟเวอร์ shared hosting ที่ไม่เคยตั้งใจให้รัน build pipeline ให้กลายเป็นเซิร์ฟเวอร์ที่รันได้ และเปลี่ยนทุกการดีพลอยให้กลายเป็น "หวังว่าเซิร์ฟเวอร์จะมีหน่วยความจำพอที่จะทำให้เสร็จ npm install" การจัดส่งเฉพาะผลลัพธ์ที่คอมไพล์แล้วทำให้ webroot เป็นสิ่งที่เซิร์ฟเวอร์ไฟล์แบบ static คาดหวังไว้พอดี น่าเบื่อ แต่ความน่าเบื่อคือสิ่งที่คุณต้องการตอนตีสองเมื่อมีบางอย่างผิดพลาดและคุณกำลังจ้องมองโฟลเดอร์นั้นพยายามหาว่าจริงๆ แล้วอะไรกำลังถูกให้บริการอยู่

ฉันจะรู้ได้อย่างไรว่าการดีพลอยสำเร็จจริง?

หลังจากอัปโหลดแล้ว เอเจนต์จะเข้าไปที่ URL ที่ใช้งานจริงและตรวจสอบว่าโหลดขึ้นหรือไม่ — ไม่ใช่ error 500 ไม่ใช่หน้าว่างเปล่า สิ่งที่พบ รวมถึงสิ่งใดก็ตามที่สังเกตเห็นระหว่างการตรวจสอบที่ต้องการความเห็นของคุณ ("webroot นี้มีโฟลเดอร์ wp-content ที่ฉันปล่อยไว้ไม่แตะต้อง ยืนยันว่านั่นคือสิ่งที่คาดไว้") จะปรากฏในเธรดแชทของ build นั่นคือรูปแบบตลอดทั้งแพลตฟอร์มนี้ ไม่มีความสำเร็จแบบเงียบๆ ไม่มีความล้มเหลวแบบเงียบๆ ที่กลายเป็น support ticket เอเจนต์จะบอกคุณว่ามันเห็นอะไรและตัดสินใจอะไร ในเธรดเดียวกับที่คุณขอให้ build

ประวัติเวอร์ชันมีอะไรอยู่บ้าง?

ทุกการดีพลอยจะเพิ่มเวอร์ชันใหม่ — ไม่ใช่แค่ครั้งแรก ดังนั้นประวัติจึงไม่ใช่การ build ของคุณที่ถูกวางบนไทม์ไลน์นามธรรม แต่เป็นลำดับที่แท้จริงของสิ่งที่ถูกให้บริการจาก webroot นั้น เรียงตามลำดับ เริ่มจากสิ่งที่อยู่ตรงนั้นก่อนที่คุณจะมาถึง เวอร์ชันหนึ่งคือสถานะก่อนใช้แพลตฟอร์มเสมอ ถูกจับภาพโดยอัตโนมัติ คุณไม่ต้องคิดถึงมันเลย

การ revert คืนค่าอะไรจริงๆ?

เวอร์ชันไลฟ์ก่อนหน้าอย่างแม่นยำ — ไม่ใช่การรัน build เก่าซ้ำ ไม่ใช่การประมาณ แต่เป็นไฟล์จริงที่กำลังให้บริการทราฟฟิกก่อนหน้านี้ นั่นเป็นการรับประกันที่แข็งแกร่งกว่าฟีเจอร์ "rollback" ส่วนใหญ่ที่ฉันเคยใช้ที่อื่น ซึ่งมักหมายถึง "ดีพลอยใหม่จาก commit เก่า" และแอบสมมติว่ากระบวนการ build ของคุณเป็นแบบ deterministic และสภาพแวดล้อมของคุณไม่ได้เปลี่ยนแปลงไป ที่นี่การ revert คือการคืนค่าสแนปช็อตที่รู้ว่าใช้งานได้ ซึ่งเป็นเหตุผลที่มันปลอดภัยที่จะใช้ในยามกดดัน — คุณไม่ต้องคิดว่า rollback อาจทำงานต่างจากสิ่งที่มันกำลัง rollback กลับไป

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

คลิกเดียว คืนค่าเวอร์ชันก่อนหน้า เสร็จสิ้น เหตุผลเบื้องหลังการปฏิบัติต่อสิ่งนี้เป็นฟีเจอร์ระดับต้นแทนที่จะเป็นสิ่งที่คิดทีหลังอยู่ใน Iterating without fear — ควรอ่านสักครั้งก่อนที่คุณจะต้องใช้มัน ทั้งประวัติและปุ่มควบคุมการคืนค่าอยู่บนการ์ด build และในหน้าประวัติของเป้าหมายเอง

สิ่งนี้สำรองข้อมูลฐานข้อมูลของฉันด้วยหรือไม่?

ไม่ และฉันขอพูดตรงๆ ดีกว่าปล่อยให้ใครสันนิษฐานเป็นอย่างอื่น ประวัติเวอร์ชันบนโฮสต์ครอบคลุมเฉพาะสิ่งที่ pipeline การดีพลอยนี้ใส่ลงใน webroot หากไซต์ของคุณมีฐานข้อมูล หรือไฟล์ที่ผู้ใช้อัปโหลด หรือสิ่งอื่นใดที่เปลี่ยนแปลงนอกเหนือจากการดีพลอย นั่นเป็นเรื่องแยกต่างหากโดยสิ้นเชิง — การ revert ไม่ได้แตะต้องมันและไม่ควรถูกเข้าใจผิดว่าเป็นกลยุทธ์การสำรองข้อมูลที่ครอบคลุมสิ่งนั้น