จัดการเซิร์ฟเวอร์ Linux หลายเครื่อง

สิ่งที่คุณกำลังสร้าง

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

ดังนั้นคู่มือนี้จึงจัดตามขนาดกลุ่มเซิร์ฟเวอร์: 2 ถึง 5 เครื่อง, 5 ถึง 20 เครื่อง, และมากกว่า 20 เครื่อง รวมถึงชั้นที่ตัดขวางทุกขนาดและไม่มีใครเขียนไว้: บัญชีรายการ, สุขอนามัยของกุญแจ, ทางเข้าเดียว, และการสำรองข้อมูลที่คุณได้กู้คืนจริงแล้ว สำหรับแต่ละเครื่องมือคุณจะได้รับสามสิ่ง: สิ่งที่มันใช้แทนที่, ค่าใช้จ่ายในการตั้งค่าเป็นนาที, และจุดบกพร่องหนึ่งจุดที่ทำให้เจ็บตัวจริงๆ ผมบริหารโฮสต์ VPS มาสิบห้าปี; รายการด้านล่างคือสิ่งที่รอดชีวิตจากการปะทะกับเหตุขัดข้องตอนตีสอง ไม่ใช่สิ่งที่สาธิตได้สวยงาม

ข้อกำหนดเบื้องต้นและข้อควรระวังที่ควรรู้

คุณต้องมีการเชื่อมต่อ SSH แบบใช้คีย์ที่ใช้งานได้แล้วกับทุกเซิร์ฟเวอร์ (หากคุณยังพิมพ์รหัสผ่านอยู่ ให้จัดการเรื่องนั้นก่อน ใช้เวลาแค่สิบนาที และทุกอย่างต่อจากนี้ถือว่าคุณใช้คีย์แล้ว) มีผู้ใช้ sudo ที่ไม่ใช่ root และเซิร์ฟเวอร์ที่ใช้ระบบปฏิบัติการเวอร์ชันปัจจุบัน คำสั่งในที่นี้ใช้ Ubuntu 24.04 เป็นหลัก แต่ไม่มีอะไรที่จำเพาะเจาะจงกับ Ubuntu ยกเว้น apt

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

เซิร์ฟเวอร์ 2 ถึง 5 เครื่อง: ~/.ssh/config คือเครื่องมือที่ถูกมองข้ามมากที่สุดที่คุณมีอยู่แล้ว

สิ่งที่มันใช้แทน: ไฟล์ข้อความที่เก็บรายการหมายเลขไอพี, การขุดค้นประวัติเชลล์ (ssh 203.0 แล้วกด Ctrl-R ลุ้นเอา), และการพิมพ์ -p 2222 -i ~/.ssh/other_key ซ้ำไปซ้ำมา ต้นทุนการตั้งค่า: 15 นาที ครั้งเดียว จุดที่มักพลาด: ซ็อกเก็ตมัลติเพล็กซ์ที่ค้างคา ซึ่งจะกล่าวถึงด้านล่าง

ในขนาดเท่านี้คุณไม่จำเป็นต้องใช้ซอฟต์แวร์ใดๆ คุณแค่ต้องตั้งค่าไคลเอนต์ที่คุณมีอยู่แล้วให้ทำงานอย่างที่คุณต้องการ ~/.ssh/config เปลี่ยนเซิร์ฟเวอร์ทุกเครื่องให้เป็นชื่อเพียงคำเดียว และเข้ารหัสเส้นทางให้ คุณจึงไม่ต้องคิดถึงมันอีกเลย:

Host *
    ServerAliveInterval 30
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h-%p
    ControlPersist 10m

Host bastion
    HostName 10.0.0.10
    User matt

Host web1
    HostName 10.8.0.11
    User matt
    ProxyJump bastion

Host db1
    HostName 10.8.0.12
    User matt
    Port 2222
    ProxyJump bastion

การตั้งค่าสามอย่างนี้ทำงานให้ ProxyJump กำหนดเส้นทางการเชื่อมต่อผ่านบาสชันในขั้นตอนเดียว ดังนั้น ssh db1 จากร้านกาแฟจึงทะลุผ่าน bastion ไปได้อย่างโปร่งใส ไม่ต้องใช้การส่งต่อเอเจนต์ ไม่ต้องใช้คาถา ProxyCommand และเซิร์ฟเวอร์ส่วนตัวก็ไม่จำเป็นต้องเปิดพอร์ต SSH สาธารณะเลย (อ่านเพิ่มเติมในส่วนที่เกี่ยวข้องกับหลายหัวข้อ) ControlMaster auto ร่วมกับ ControlPersist ทำมัลติเพล็กซ์การเชื่อมต่อผ่าน TCP session เดียว ดังนั้น ssh, scp, หรือ rsync ครั้งที่สองและครั้งต่อๆ ไปที่เชื่อมต่อไปยังโฮสต์เดียวกันจะเชื่อมต่อได้ทันทีแทนที่จะต้องเจรจาใหม่ ซึ่งความแตกต่างนี้จะชัดเจนมากเมื่อ Ansible เข้ามาเกี่ยวข้อง และเนื่องจาก scp, rsync, และ Ansible ต่างก็อ่านไฟล์เดียวกันนี้ ทุกชื่อที่คุณกำหนดไว้ที่นี่จึงใช้ได้กับทุกที่

จุดที่มักพลาด: การเชื่อมต่อหลักอาจมีอายุยืนเกินกว่าประโยชน์ของมัน และโหมดความล้มเหลวสองแบบจะแสดงอาการต่างกัน เมื่อเซิร์ฟเวอร์รีบูตหรือ Wi-Fi ของคุณหลุด โปรเซสหลักจะถูกทิ้งไว้โดยถือ TCP session ที่ตายแล้วโดยที่มันยังไม่รู้ตัว และ ssh web1 ครั้งถัดไปจะค้างเงียบอยู่บนซ็อกเก็ตที่ไม่ได้นำไปสู่ที่ใดเลย อีกกรณีหนึ่ง sshd จำกัดจำนวน session ต่อการเชื่อมต่อไว้ที่ 10 (MaxSessions ใน sshd_config) ดังนั้น session มัลติเพล็กซ์ที่สิบเอ็ดไปยังโฮสต์หนึ่งจะแสดงข้อความ:

mux_client_request_session: session request failed: Session open refused

ทั้งสองกรณีมีวิธีแก้ไขเดียวกัน: ssh -O exit web1 จะฆ่าโปรเซสหลัก และการเชื่อมต่อครั้งถัดไปจะเริ่มต้นใหม่ คุณอาจเห็น ControlSocket ~/.ssh/cm-matt@web1-22 already exists, disabling multiplexing เป็นครั้งคราว อันนี้ไม่มีอันตราย: สอง session แข่งกัน และการเชื่อมต่อยังคงทำงานได้ แค่ไม่ได้ใช้มัลติเพล็กซ์

เครื่องมือคู่หูสองอย่างสำหรับขนาดนี้ tmux บนเซิร์ฟเวอร์แต่ละเครื่องใช้แทน nohup, งานที่หายไปเมื่อ Wi-Fi หลุด, และ "ฉันปิดแล็ปท็อปไม่ได้ การย้ายข้อมูลกำลังทำงานอยู่" ต้นทุนการตั้งค่า: sudo apt install -y tmux, สองนาที, บวกกับความจำของกล้ามเนื้อสำหรับ tmux new -s work และ tmux attach -t work จุดที่มักพลาดคือการซ้อนกัน: tmux ข้างใน tmux จะกลืน prefix key ของคุณ ดังนั้นให้รันมันบนเซิร์ฟเวอร์หรือบนแล็ปท็อป อย่างใดอย่างหนึ่ง ไม่ใช่ทั้งสองอย่าง หากคุณรัน agent session ที่มีอายุยาวนาน สิ่งนี้สำคัญเป็นสองเท่า มันเป็นรูปแบบเดียวกับ การรัน Claude Code ใน tmux บน VPS ซึ่ง session ต้องมีอายุยืนกว่าการเชื่อมต่อ SSH

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

5 ถึง 20 เซิร์ฟเวอร์: ใช้ config เป็นโค้ด มิฉะนั้นดริฟต์จะชนะ

เมื่อคุณมีเซิร์ฟเวอร์เกินห้าเครื่องขึ้นไป วิธีคิดที่ว่า "เดี๋ยวจัดการทีละเครื่องเอง" จะเลิกเป็นวิธีการ และกลายเป็นคำโกหกที่คุณบอกตัวเอง เครื่องมือในระดับนี้ทั้งหมดมีเป้าหมายเพื่อจัดการกับศัตรูตัวเดียวกัน นั่นคือ ดริฟต์ (ความแตกต่างที่ค่อยๆ เกิดขึ้นจากการตั้งค่า)

Ansible เข้ามาแทนที่การรันคำสั่งวนลูปผ่านชื่อโฮสต์แบบเชลล์, แทนที่หน้า wiki หัวข้อ "การตั้งค่าเซิร์ฟเวอร์ใหม่" ที่ข้อมูลล้าสมัยไปแล้วสามขั้นตอน, และแทนที่ความกังวลว่า web3 ได้รับการแก้ไขจริงหรือไม่ ต้นทุนการตั้งค่า: 30 นาทีเพื่อให้ได้ playbook แรกที่ใช้งานได้, sudo apt install -y ansible บนแล็ปท็อปหรือกล่องสำหรับจัดการ (apt จะให้ Ansible รุ่นเก่ากว่า ซึ่งเพียงพอสำหรับทุกอย่างที่นี่; วิธีการติดตั้งแบบ pipx ของบทเรียนนี้จะให้รุ่นปัจจุบัน), ไม่มีเอเจนต์บนเซิร์ฟเวอร์, ทุกอย่างทำงานผ่านการตั้งค่า SSH ที่คุณสร้างไว้แล้ว นี่คือการอัปเกรดครั้งใหญ่ที่สุดในหน้านี้ และคำแนะนำแบบทีละขั้นตอนทั้งหมดอยู่ใน บทเรียน Ansible playbook แรก; นี่คือโครงสร้างของ inventory ที่ทำให้มันทำงานได้:

[web]
web1 ansible_host=10.8.0.11
web2 ansible_host=10.8.0.12

[db]
db1 ansible_host=10.8.0.21 ansible_port=2222

[all:vars]
ansible_user=matt
ansible_ssh_common_args='-o ProxyJump=bastion'

เนื่องจาก Ansible เรียกใช้ไบนารี OpenSSH ~/.ssh/config ที่คุณเขียนไว้ในส่วนที่แล้วจึงมีผลทันที inventory ที่มีแค่ชื่อเปล่าๆ เช่น web1 จะทำงานได้โดยไม่ต้องมีตัวแปรใดๆ เลย ตัวแปรที่แสดงข้างต้นทำให้ inventory สมบูรณ์ในตัวเอง ซึ่งจะคุ้มค่าในวันที่คุณรันมันจากเครื่องที่ไม่ใช่แล็ปท็อปของคุณ

ทดสอบด้วย ansible all -i inventory.ini -m ping; ผลลัพธ์ที่ถูกต้องจะพิมพ์ "ping": "pong" สำหรับทุกโฮสต์ เป็นสีเขียว ความล้มเหลวแรกที่คุณจะพบมีลักษณะดังนี้:

web1 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: matt@10.8.0.11: Permission denied (publickey).",
    "unreachable": true
}

นั่นไม่ใช่ปัญหาของ Ansible เพราะ ssh matt@10.8.0.11 ธรรมดาก็ล้มเหลวในลักษณะเดียวกัน แก้ไข SSH ก่อนเสมอ Ansible จะดีได้ก็ต่อเมื่อเลเยอร์ที่อยู่ข้างใต้นั้นแข็งแรงดี ข้อควรระวังนอกเหนือจากนั้น: Ansible ต้องการ Python บนทั้งสองฝั่ง ดังนั้นอิมเมจที่เล็กมากจริงๆ อาจตอบกลับ /usr/bin/python3: not found คำสั่ง apt install python3 เพียงครั้งเดียว มันจะไม่รบกวนคุณอีกเลย

unattended-upgrades เข้ามาแทนที่คุณในฐานะคนที่คอยอัปเดตแพตช์ความปลอดภัยให้กับเซิร์ฟเวอร์ N เครื่อง Ubuntu Server 24.04 ที่เป็นรุ่นมาตรฐานจะติดตั้งมาให้ล่วงหน้าและโดยปกติเปิดใช้งานสำหรับอัปเดตความปลอดภัยอยู่แล้ว ดังนั้นงานตรงนี้คือการตรวจสอบ ไม่ใช่การติดตั้ง:

cat /etc/apt/apt.conf.d/20auto-upgrades

ทั้งสองบรรทัดควรลงท้ายด้วย "1" อิมเมจแบบ minimal และ cloud บางตัวอาจมาพร้อมกับฟีเจอร์นี้ที่ถูกปิดอยู่ และ sudo dpkg-reconfigure -plow unattended-upgrades จะเขียนไฟล์นั้นใหม่หากของคุณเป็นเช่นนั้น ต้นทุนการตั้งค่า: สองนาทีในการตรวจสอบต่อเซิร์ฟเวอร์ หรือหนึ่ง task ของ Ansible สำหรับทั้งหมด ข้อควรระวัง: โดยค่าเริ่มต้น มันจะไม่รีบูต ดังนั้นอัปเดตความปลอดภัยของเคอร์เนลจะถูกนำไปใช้เพียงครึ่งเดียวจนกว่าคุณจะรีบูต คู่มือ unattended-upgrades ฉบับสมบูรณ์ ครอบคลุมถึงการรีบูตอัตโนมัติ, การเลือกสิ่งที่ต้องการแพตช์, และการอ่านบันทึกของมัน

การมอนิเตอร์แบบรวมศูนย์ เข้ามาแทนที่การรู้ปัญหาจากลูกค้า ซึ่งเป็นระบบมอนิเตอร์ที่แพงที่สุดเท่าที่เคยมีมา สองเครื่องมือ แต่ละตัวมีจุดประสงค์ต่างกัน: Uptime Kuma ตอบคำถามว่า "มันยังออนไลน์อยู่หรือไม่?" ด้วยการตรวจสอบ HTTP, TCP, และ ping พร้อมแจ้งเตือนไปยังทุกช่องทาง และใช้เวลาติดตั้งสิบนาทีใน Docker; Zabbix ตอบคำถามว่า "มันกำลังจะล่มหรือไม่?" ด้วยแนวโน้มของดิสก์, หน่วยความจำ, และ CPU ผ่านเอเจนต์บนทุกโฮสต์ และต้องใช้เวลาช่วงบ่ายหนึ่งในการติดตั้ง เริ่มต้นด้วย Kuma; เพิ่ม Zabbix เมื่อสถานะ "ออนไลน์แต่ประสิทธิภาพลดลง" เริ่มทำให้คุณเสียเงิน ข้อควรระวังสำหรับทั้งสองอย่างคือตำแหน่งการติดตั้ง และมันสำคัญพอที่จะถูกกล่าวถึงเป็นอันดับแรกในส่วนข้อผิดพลาดด้านล่าง

แผงควบคุมเว็บ ใช้เมื่อจำเป็นเท่านั้น Webmin เข้ามาแทนที่การจำว่า Ubuntu เก็บสิ่งต่างๆ ไว้ที่ไหน และสำหรับทีมที่มีทักษะหลากหลายหรือเซิร์ฟเวอร์ที่คุณต้องจัดการแค่ปีละสองครั้ง มันมีประโยชน์อย่างแท้จริง; การตั้งค่าใช้เวลาสิบนาที ข้อควรระวังคือมันเป็นเว็บแอปพลิเคชันที่มีสิทธิ์เทียบเท่า root คอยรับการเชื่อมต่อที่พอร์ต 10000 และอินเทอร์เน็ตก็สแกนหามันอยู่ตลอดเวลา หากคุณรันมัน ให้ผูกมันเข้ากับ localhost หรือที่อยู่ VPN เท่านั้น ห้ามผูกกับ 0.0.0.0 บนอินเทอร์เฟซสาธารณะ และหากคุณกำลังมองหาแผงควบคุมเพราะรู้สึกว่า SSH ช้า ให้กลับไปอ่านส่วนก่อนหน้านี้อีกครั้ง; ~/.ssh/config บวกกับ Ansible นั้นเร็วกว่าแผงควบคุมใดๆ เมื่อกำหนดค่าเสร็จแล้ว

20+ เซิร์ฟเวอร์: จุดสิ้นสุดที่แท้จริงของคู่มือนี้

เมื่อคุณมีเซิร์ฟเวอร์เกินยี่สิบเครื่อง คุณกำลังบริหารจัดการกลุ่มเซิร์ฟเวอร์ขนาดใหญ่ และชุดเครื่องมือจะเปลี่ยนรูปแบบไป: ใช้ Terraform หรือ OpenTofu เพื่อให้ตัวเซิร์ฟเวอร์เองสามารถสร้างซ้ำได้, ใช้ cloud-init หรือ golden image เพื่อให้เครื่องหนึ่งๆ สามารถทิ้งได้แทนที่จะซ่อม, ใช้การตั้งค่าแบบดึง (pull-based) หรือ CI pipeline เพื่อรัน Ansible ของคุณ เพราะการ push จากแล็ปท็อปเริ่มไม่สามารถขยายขนาดได้อีกต่อไป, และมีการจัดการความลับอย่างจริงจัง ตัว Ansible เองไม่ได้ล้มเหลวเมื่อมีเซิร์ฟเวอร์ยี่สิบเครื่อง มีหลายองค์กรที่ใช้มันกับเครื่องเป็นร้อยๆ โหนด แต่แนวปฏิบัติรอบๆ ตัวมันต้องแข็งแกร่งขึ้น และนั่นเป็นบทความคนละแบบกับที่เว็บไซต์นี้เขียน หากคุณอยู่ในระดับนั้น ส่วนด้านล่างนี้ยังคงเป็นของคุณ เพราะ inventory, กุญแจ และวินัยในการเข้าถึง คือสิ่งที่เครื่องมือจัดการกลุ่มเซิร์ฟเวอร์ขนาดใหญ่คาดหวังว่าคุณมีอยู่แล้ว

ชั้นที่ไม่มีใครบันทึก

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

ไฟล์รายการเซิร์ฟเวอร์ แม้เป็นไฟล์ข้อความธรรมดา ทันทีที่มีเซิร์ฟเวอร์สามเครื่อง ให้จดบันทึก: ชื่อ, ไอพี, ผู้ให้บริการ, สิ่งที่รันอยู่บนนั้น, และเหตุผลที่มันมีอยู่ การใช้ servers.md ใน git repo ก็พอใช้ได้ แต่ inventory ของ Ansible ข้างต้นดีกว่าเพราะเป็นเอกสารที่ทำงานได้ สิ่งที่มันมาแทนที่: คำถามตอนตีสองว่า "เดี๋ยว 10.0.0.40 คืออะไรนะ?" ค่าใช้จ่ายในการตั้งค่า: สิบนาที ข้อพึงระวัง: มันจะทำงานได้ก็ต่อเมื่อการสร้างเซิร์ฟเวอร์และการเพิ่มบรรทัดนั้นเป็นขั้นตอนเดียวกัน ไม่ใช่แยกกันทำ

การดูแลกุญแจ: หมุนเวียนเดี๋ยวนี้ และใช้ SSH CA เมื่อถึงคราวจำเป็น แจกแจงว่ากุญแจของคุณอยู่ที่ไหนบ้าง (cat ~/.ssh/*.pub ฝั่งคุณ, ~/.ssh/authorized_keys ฝั่งเซิร์ฟเวอร์แต่ละเครื่อง), ลบเครื่องของอดีตพนักงานและอดีตเพื่อนร่วมงานออก, และหมุนเวียนอะไรก็ตามที่เก่าพอจนคุณบอกไม่ได้ว่ามันเคยไปอยู่ที่ไหนมา SSH certificate authority ที่ออกใบรับรองอายุสั้นแทนกุญแจถาวรเป็นคำตอบที่เป็นมืออาชีพ แต่คำแนะนำตามตรงคือ สำหรับเซิร์ฟเวอร์ต่ำกว่าสิบเครื่อง การจัดการ authorized_keys อย่างมีวินัยผ่าน Ansible ให้ประโยชน์ 90% ด้วยพิธีกรรมเพียง 10%

ทางเข้าเดียว ไม่ใช่ยี่สิบทาง ทุกพอร์ต SSH ที่เปิดสู่สาธารณะคือพื้นที่โจมตีที่คูณด้วยจำนวนเซิร์ฟเวอร์ รูปแบบที่ขยายได้ดี: ใช้ bastion host หนึ่งตัว หรือที่ดีกว่านั้นคือ WireGuard VPN บน VPS ที่คุณควบคุม และผูก SSH ของเซิร์ฟเวอร์อื่นทุกเครื่องไว้กับที่อยู่ส่วนตัวเท่านั้น บรรทัด ProxyJump ใน config ข้างต้นตั้งสมมติฐานเช่นนี้อยู่แล้ว อะไรก็ตามที่ต้องเปิดเป็นสาธารณะก็ควรได้รับ fail2ban เป็นปกติ ค่าใช้จ่ายในการตั้งค่า: หนึ่งชั่วโมง ครั้งเดียว ข้อพึงระวัง: ตรวจสอบว่าเส้นทางสำรองของคุณ (การเข้าถึงคอนโซลของผู้ให้บริการ) ใช้งานได้ ก่อนปิดพอร์ต 22 ทุกที่ ไม่ใช่หลังจากนั้น

สำรองข้อมูลที่ทดสอบด้วยการกู้คืน สำรองข้อมูลที่ไม่ได้ทดสอบเป็นเพียงสมมติฐาน ไม่ว่าคุณใช้กลไกใด สแนปช็อตของผู้ให้บริการ, restic, rsync ไปยังอีกเครื่องหนึ่ง เครื่องมือที่สำคัญจริงๆ คือรายการในปฏิทินที่คุณกู้คืนเซิร์ฟเวอร์หนึ่งเครื่องลง VPS ใหม่และยืนยันว่ามันบูตและให้บริการได้ ทุกเรื่องราวหายนะเกี่ยวกับสำรองข้อมูลที่ผมได้ยินในสิบห้าปีของการโฮสต์ ล้วนมีวลีว่า "ผมมีสำรองข้อมูล แต่มันกู้คืนไม่ได้"

ข้อผิดพลาด

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

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

ช่องโหว่ไฟร์วอลล์แบบ "ชั่วคราว" ufw allow 5432 เพื่อแก้ไขข้อบกพร่องบางอย่าง และสิบแปดเดือนต่อมา Postgres ก็ยังคงเปิดอยู่บนอินเทอร์เน็ต ตรวจสอบด้วย sudo ufw status numbered บนแต่ละเครื่อง หรือในครั้งเดียวด้วย ansible all -i inventory.ini -a "ufw status numbered" --become และลบกฎใดก็ตามที่คุณไม่สามารถระบุเหตุผลในปัจจุบันได้ หากกฎนั้นเป็นกฎชั่วคราวจริงๆ ให้เพิ่ม ufw delete ที่เกี่ยวข้องลงในหน้าต่าง tmux เดิมก่อนที่คุณจะปิดมัน

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

Root SSH ไปทุกที่ การใช้คีย์ root ร่วมกันหนึ่งดอกทั่วทั้งกลุ่มเซิร์ฟเวอร์ หมายความว่าแล็ปท็อปที่รั่วไหลเพียงเครื่องเดียวจะเป็นเจ้าของทุกสิ่ง และไม่มีบันทึกการตรวจสอบว่าใครทำอะไร ผู้ใช้เฉพาะบุคคล, sudo และ PermitRootLogin no ใน /etc/ssh/sshd_config บนทุกโฮสต์ ซึ่งขอย้ำอีกครั้งว่าเป็นงาน Ansible สามบรรทัด แทนที่จะเป็นการพิมพ์ทั้งเย็น

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

FAQ

เครื่องมือฟรีที่ดีที่สุดสำหรับจัดการเซิร์ฟเวอร์ Linux หลายเครื่องคืออะไร

สำหรับเซิร์ฟเวอร์ 2 ถึง 5 เครื่อง ~/.ssh/config ที่เขียนอย่างดีร่วมกับ tmux ดีกว่าสิ่งใดๆ ที่คุณจะติดตั้งเพิ่มเติม ตั้งแต่ประมาณห้าเครื่องขึ้นไป Ansible คือคำตอบมาตรฐาน: ไม่ต้องติดตั้งเอเจนต์, ฟรี, ทำงานผ่าน SSH ที่คุณมีอยู่แล้ว และเปลี่ยนการตั้งค่าเซิร์ฟเวอร์ให้เป็นไฟล์ใน git เพิ่ม Uptime Kuma สำหรับการแจ้งเตือนสถานะเปิด/ปิด; ทุกเครื่องมือที่ระบุชื่อในคู่มือนี้เป็นซอฟต์แวร์เสรี

ฉันสามารถจัดการเซิร์ฟเวอร์ Linux หลายเครื่องโดยไม่ใช้ Ansible ได้หรือไม่

ได้, สำหรับเซิร์ฟเวอร์ต่ำกว่าประมาณห้าเครื่อง การตั้งค่า SSH ที่ดี, ไฟล์ alias ที่ใช้ร่วมกัน, และวินัยก็เพียงพอแล้ว และมีคนจำนวนมากทำแบบนั้นมาหลายปี เกินกว่านั้น ทางเลือกอื่นที่ไม่ใช่ Ansible ไม่ใช่ "ไม่มีอะไร" แต่มันคือความแตกต่างที่ไม่มีเอกสารบันทึกไว้: เซิร์ฟเวอร์สิบแปดเครื่องที่แต่ละเครื่องถูกตั้งค่าต่างกันเล็กน้อยด้วยมือ หาก Ansible รู้สึกว่าหนักเกินไป ให้เริ่มด้วยเพลย์บุ๊กเดียวที่จัดการแค่ authorized_keys และ unattended-upgrades; แค่นั้นก็คุ้มค่ากับช่วงการเรียนรู้แล้ว

ฉันจะรันคำสั่งเดียวกันบนเซิร์ฟเวอร์ Linux หลายเครื่องพร้อมกันได้อย่างไร

ansible all -i inventory.ini -a "uptime" คือคำตอบที่สะอาดและไม่ต้องใช้เพลย์บุ๊ก ใช้แค่ไฟล์ inventory สำหรับการทำงานแบบโต้ตอบเคียงข้างกัน tmux สามารถกระจายการกดแป้นพิมพ์ไปยังทุกหน้าต่างย่อยด้วย setw synchronize-panes on แต่ให้มองว่านั่นเป็นลูกเล่น เพราะการกระจายคำสั่งแบบโต้ตอบไปยังเซิร์ฟเวอร์ที่ใช้งานจริง คือวิธีที่การพิมพ์ผิดครั้งเดียวกลายเป็นระบบล่มคูณ N

ฉันจำเป็นต้องใช้แผงควบคุมอย่าง Webmin เพื่อจัดการเซิร์ฟเวอร์ Linux หรือไม่

จำเป็น, ไม่ใช่ ทุกสิ่งที่แผงควบคุมทำได้ SSH และ Ansible ทำได้ซ้ำและตรวจสอบได้ดีกว่า Webmin มีที่ทางของมันเมื่อผู้ที่มีระดับทักษะหลากหลายดูแลเครื่องเดียวกัน หรือเมื่อคุณเข้าไปจัดการเซิร์ฟเวอร์นานๆ ครั้งจนการค้นหาเส้นทาง config ใหม่ทำให้เสียเวลาจริงๆ หากคุณใช้งานมัน ให้ปฏิบัติต่อมันเหมือนเว็บแอปที่มีสิทธิ์เทียบเท่า root: ผูกมันเข้ากับ localhost หรือที่อยู่ VPN เท่านั้น ห้ามผูกกับอินเทอร์เฟซสาธารณะเด็ดขาด

คนหนึ่งคนสามารถจัดการเซิร์ฟเวอร์ Linux ได้กี่เครื่องตามความเป็นจริง

ด้วยการจัดการด้วยมือ คุณภาพจะลดลงเมื่อมีจำนวนต่ำกว่าสิบเครื่อง ด้วยการตั้งค่าแบบโค้ด, การแพตช์อัตโนมัติ, และการเฝ้าติดตามแบบรวมศูนย์ คนที่รอบคอบหนึ่งคนสามารถดูแลเซิร์ฟเวอร์ 20 ถึง 50 เครื่องเป็นงานนอกเวลาได้ ข้อจำกัดจะกลายเป็นว่ามีสิ่งใหม่ๆ ที่ไม่คาดคิดพังบ่อยแค่ไหน ไม่ใช่งานดูแลประจำ ตัวเลขที่สำคัญไม่ใช่จำนวนเซิร์ฟเวอร์ต่อผู้ดูแล แต่เป็นจำนวนเครื่องที่ตั้งค่าเฉพาะตัวต่อผู้ดูแล: ทำให้มันใกล้ศูนย์เข้าไว้ และเพดานก็จะสูง