Azure認證帳號開戶 Azure 微軟雲國際站企業級 Linux 服務器安裝

微軟雲Azure / 2026-04-28 14:17:09

前言：把 Linux 裝進 Azure，別讓它「自帶災難」

如果你曾經在自建機房安裝 Linux，應該很懂那種感覺：插上 ISO、等它跑完、分割磁碟、設網卡，最後看著主控台出現登錄提示字樣，心裡就會冒出一句——「終於好了。」

但在 Azure 上安裝企業級 Linux 服務器，事情通常不只是「安裝」而已。它更像是：你要先決定未來三年可能會出現的需求，然後用一套可維運、可擴充、可追蹤的方式把系統放進雲裡。你可以把它想像成：不是在租屋處搬床而已，而是要順便把水電網路、監控滅火、門鎖鑰匙和緊急聯絡人都一併搞定。

本文以「Azure 微軟雲國際站企業級 Linux 服務器安裝」為主題，從零開始整理一套清晰流程：規劃 → 建立資源 → 設定網路安全 → 初始化系統 → 企業級維運（監控、標籤、備份、擴充策略）→ 常見問題排障。你照做，基本上就能讓 Linux 在 Azure 上穩定落地。

第一步：先想清楚「你要什麼」，不要只想「怎麼裝」

企業級安裝的關鍵不在於跑哪個命令，而在於前期決策。你可以先回答下面這些問題（不用寫得很正式，心裡有底就行）：

你需要的 Linux 發行版與版本？

常見選擇：Ubuntu Server、Debian、Red Hat Enterprise Linux（RHEL）、SUSE Linux Enterprise Server（SLES）。若你有既有作業系統標準，請優先對齊；如果沒有，企業級通常會考量長期支援（LTS）、訂閱/授權、以及你團隊的熟悉度。

工作負載型態是什麼？

Web/應用伺服器：通常需要穩定網路、適當的 CPU/記憶體、以及可預測的儲存延遲。
Azure認證帳號開戶 資料庫：你會更在意 IOPS、延遲、以及快照/備援策略。
批次/背景運算：可能更在意吞吐量與成本效率。

網路架構要怎麼做？

至少你要想清楚這幾件事：

是否需要公開網路（Public IP）？還是只要內網？
是否要用 NSG（Network Security Group）做入站/出站控制？
是否要跟現有 VNet/On-prem 互通（VPN/ExpressRoute）？

安全策略：你準備用什麼方式控管 SSH？

企業級通常不建議「把 SSH 直接開給全世界」。較常見做法是：只允許特定 IP 或透過跳板機（Jumpbox/Bastion）進入；搭配金鑰驗證、禁用密碼登入、以及基本的權限最小化。

第二步：在 Azure 上建立資源的「企業級習慣」

開始前，請確認你用的是 Azure 微軟雲國際站對應的訂閱（Subscription）。若你有不同環境（Dev/Stage/Prod），也要先對齊資源群組（Resource Group）與命名規範。

資源群組（Resource Group）與命名

建議命名包含：環境、地區、系統用途。例如：

rg-prod-eastus-web
rg-dev-tw-ks-hpc

這樣你在數百個資源裡找某台 VM 的時候，不會像在 IKEA 裡找螺絲包。

Azure認證帳號開戶標籤（Tags）：讓你未來的自己感謝你

企業級最常見的「救命稻草」之一就是 Tag。至少建議包含：

environment：prod/dev/test
application：app 名稱
owner：負責人或團隊
costCenter：成本中心
dataSensitivity：例如 public/internal/confidential

之後做成本分析、權限管理、或稽核時，Tag 會變成你的超能力。

第三步：建立 Linux VM（從零到可連線）

下面以 Azure Portal 的流程來描述，你也可以用 ARM/Bicep/Terraform 實作自動化（企業級通常會走 IaC）。但為了讓你能快速上手，我先用 Portal 版本講清楚每個關鍵點。

選擇基礎項目：Compute、OS 與映像

在「建立虛擬機（Virtual Machine）」後，通常會看到：

Subscription：選對訂閱
Resource group：選擇或建立
Virtual machine name：命名（建議可追溯用途）
Region：選擇靠近使用者或資料的地區
Image：選擇 Linux 發行版與版本

企業級常見做法是把 OS 映像標準化：例如永遠使用某個 LTS 版本、或特定的映像（若公司有自建 golden image，更是加分）。

選擇大小（Size）與效能：別只看「能不能跑」

Azure認證帳號開戶 VM 大小會影響：

CPU/記憶體是否足夠
網路吞吐與延遲（不同 SKU 可能差異）
成本

企業級的建議是：先估算負載，再用監控資料迭代。若你一開始就選太小，後續擴容會讓你在部署時心情很複雜；選太大則會讓財務部開始跟你聊天。

磁碟與快取：你用錯，效能會「默默不對」

Azure VM 通常包含 OS Disk，並且可另外掛載 Data Disk。

企業級請特別注意：

OS Disk 類型：依需要選擇（例如 Premium SSD / Standard HDD 等）
Data Disk：資料、日誌、快取可能要分離
快取設定（Caching）：例如 Read-only 或 Read-write，但要依工作負載決定

簡單一句話：資料庫、吞吐敏感的服務，通常更需要考慮 IOPS/延遲；靜態內容或輕量服務則可以更保守省成本。

網路：讓 VM 放在正確的保護網裡

在「網路」設定中，你會看到：

Virtual Network（VNet）：選擇既有或新建
Subnet：通常可為各系統分網段
Public IP：決定是否暴露到公網
Network Security Group（NSG）：入站/出站規則

企業級安全建議：若服務不需要公網存取，優先不要配置 Public IP。若需要外部存取，請搭配 Load Balancer 或 Application Gateway，把攻擊面縮小。

入站規則：SSH 不是「隨便開」

在 NSG 中通常要控制：

SSH（22/TCP）：只允許特定來源 IP（例如公司辦公室固定 IP 或 VPN 出口）
HTTP/HTTPS：若是 Web 服務再開給必要的來源
其他端口：以最小必要為原則

千萬不要一時手滑讓 0.0.0.0/0 直接打進來。你可能覺得「反正有防火牆」，但防火牆不是心理安慰，它是實際控制。

管理登入：使用 SSH 金鑰、禁用密碼

在建立 VM 時，請選擇使用 SSH 公鑰（Public Key）登入，並且設定使用者帳號（例如 azureuser 或根據公司規範的 admin 帳號）。

企業級常見的下一步是：在 OS 初始化後禁用密碼登入，並確保 /home/username/.ssh/authorized_keys 權限正確。

第四步：啟動後的系統初始化（比你想的還重要）

VM 建立完成後，你會得到 IP（或只有內網 IP）。下一步就是連線並做初始化。

連線方式：SSH 到你應該能連的地方

使用 SSH 連線：

ssh -i your_key.pem username@vm-ip

Azure認證帳號開戶 如果你連不上，先別急著猜命。優先檢查：

NSG 是否允許入站 22/TCP
是否需要 Public IP 或 VPN/跳板機
安全群組是否有其他層級限制
OS 防火牆（ufw/firewalld）是否阻擋

更新套件：讓系統先變「不脆弱」

連線後先做更新（以 Debian/Ubuntu 範例）：

sudo apt-get update
sudo apt-get -y upgrade

Red Hat 系列則是：

sudo dnf -y update

企業級的最佳實務是：不要每天手動更新到天亮，而是用基線流程（Baseline）或自動化更新策略管理。

建立「維運者」帳號並控制權限

Azure認證帳號開戶 不要只有一個 root 帳號在那邊孤獨地撐場面。常見做法：

建立一般使用者
透過 sudo 配置最小必要權限
必要時使用角色分離（例如運維帳號、部署帳號）

如果你需要企業合規，還可能要整合集中式身分管理（例如 Azure AD/Entra ID + Just-In-Time）。

Azure認證帳號開戶 SSH 強化：把常見攻擊擋在門外

建議做至少以下幾項（以 OpenSSH 為例）：

確認密碼登入已禁用：PasswordAuthentication no
限制使用者與金鑰：AllowUsers 或使用設定白名單
必要時關閉不必要的轉送（如 AllowTcpForwarding / X11Forwarding 視需求）

改完 sshd_config 後記得：

sudo systemctl restart ssh

小提醒：改 SSH 設定請在你仍保持連線的狀態下操作，避免重啟後自己把自己踢出去。你可以把它想像成：你在廚房調味時，別把自己鎖在門外。

設定主機名稱與網路解析

設定主機名（hostname），並確認 DNS/hosts 正確。企業級通常會有命名規範與內網解析機制（例如透過自建 DNS 或 Azure DNS Private Resolver）。

第五步：企業級儲存配置（OS/資料/日誌分開才睡得著）

很多人上線後才發現：原來日誌爆量把磁碟填滿，或資料寫入延遲讓服務慢到像在「考古」。所以企業級儲存設計要先想好。

OS Disk 與 Data Disk 的角色分離

建議做：

OS Disk：放系統與程式（/、/usr、/var 中非高吞吐資料）
Data Disk：放應用資料、上傳檔、快取等
必要時分出日誌目錄：例如 /var/log 或應用自訂 log 目錄

初始化 Data Disk：格式化與掛載

假設你新增了一顆資料磁碟（以 /dev/sdc 為例），流程大致是：

sudo lsblk
sudo mkdir -p /data
sudo mkfs.ext4 /dev/sdc
sudo mount /dev/sdc /data

之後一定要讓它在重開機仍能掛載，通常用 UUID 寫入 /etc/fstab：

sudo blkid /dev/sdc

然後編輯 /etc/fstab，把 UUID 對上 mount point。

企業級建議再加一個：使用 mount options（例如 noatime）依需求調整，並在上線前做壓測或至少寫入測試，確保延遲符合預期。

第六步：安裝常用企業軟體與基礎服務（但要「可控」）

企業級不是把所有軟體丟上去，而是建立可控、可回滾、可追蹤的基線。

時間同步：讓日誌時間對得上

時間錯亂是很麻煩的事，會讓你排查事故時像在讀錯年份的歷史書。請確保：

chrony 或 systemd-timesyncd 正常運作
時區與 NTP 設定符合企業規範

基礎工具：你未來維運會用到

curl / wget
vim 或你偏好的編輯器（但要控制權限）
net-tools/ss（視系統）
fail2ban（若允許）

如果你有 CM 工具（Ansible、Chef、Puppet 或企業自建管線），就把這些放進基線腳本，不要靠「手動安裝祈禱法」。

監控與日誌：別等問題發生才想看

企業級一般會導入 Azure Monitor / Log Analytics 或其他 SIEM。至少要做到：

CPU/Memory/Disk 使用率
網路吞吐與連線狀況
系統日誌（syslog/journald）
應用日誌（依應用種類）

如果你已經使用某套監控平台，請統一 Agent 部署流程，並設置收集規則和告警閾值。

第七步：備援、備份與災難復原（DR）要從一開始就規劃

如果你打算只做「目前能跑」，那你會在未來某個夜裡迎接驚喜。企業級至少要考慮：磁碟備份、快照、以及在區域性故障時的恢復策略。

備份策略：系統與資料要分開想

系統（OS）備份：用來快速恢復服務環境
資料備份：看你的 RPO/RTO 需求決定頻率
測試還原：備份存在不等於能用，記得定期演練

快照/復原點（Recovery Point）與復原時間（Recovery Time）

Azure認證帳號開戶 RPO 是你最多能接受「丟掉多少資料」；RTO 是你希望「多久恢復服務」。不同應用的要求不同，所以不要用同一套策略硬套所有 VM。

第八步：部署流程最佳化（讓它可重現、可擴充）

企業級最漂亮的狀態是：你可以一鍵重建同樣的 VM，而不是靠記憶力。你可以用：

IaC：Bicep / ARM / Terraform
自動化配置：Ansible / cloud-init / 自建腳本
映像快取：若使用自建 golden image，部署速度會大幅提升

當你未來要擴一台、換版本、或把壞掉的 VM 替換掉時，你會感謝你當初沒有偷懶。

第九步：常見踩雷點與排障清單（避免踩到地雷還說不痛）

問題 1：SSH 連不上

排查順序建議：

NSG 是否允許 22/TCP 入站來源 IP
是否配置 Public IP 或你正在用正確的網路路徑（VPN/內網）
OS 是否允許 sshd：systemctl status ssh
ssh 設定是否禁用了你的用戶或金鑰

小技巧：先用 Azure 的診斷機制或 VM 串接序列主控台（若啟用）觀察錯誤，會比盲猜有效得多。

問題 2：磁碟滿了（尤其是 /var/log 或根目錄）

常見原因：

日誌未設輪替（logrotate）
應用把資料寫到預設路徑
沒有針對 data disk 設定掛載或 fstab 失效

排查命令：

df -h
sudo du -sh /var/log/* 2>/dev/null | sort -h | tail -n 20

問題 3：效能不穩、延遲偏高