From Zero to a Live Cloud Server
Buy the instance, secure it, install Docker, point your domain at it — the exact ordered steps from console to a live service.
Buying the right thing
- Region: pick the region physically closest to your users (Beijing/Shanghai/Guangzhou for their respective demographics)
- Image: Ubuntu 22.04/24.04 LTS or your team's familiar RHEL-family; LTS saves you upgrade churn
- Disk: 40-60GB system SSD is enough for most API servers; data goes on a separately mounted data disk or cloud DB
- Bandwidth: 1-5Mbps fixed for start; scale up or switch to traffic billing once you have numbers
Two resources people regret skimping on: memory (OOM-kill under load, JVM especially) and bandwidth (a single image-heavy page can saturate 1Mbps in a second).
First-hour hardening
The order matters: new cloud IPs are scanned within minutes. Do the hardening before deploying anything.
# 1. 用 SSH 密钥登录、禁掉密码登录（控制台先绑定公钥）
ssh-keygen -t ed25519 -C 'me@laptop'
ssh-copy-id -i ~/.ssh/id_ed25519.pub ubuntu@1.2.3.4
# 2. 改 SSH 端口 + 只允许密钥
sudo sed -i 's/^#Port 22/Port 22960/' /etc/ssh/sshd_config
sudo sed -i 's/^#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart sshd
# 3. 防火墙只放最小集合
sudo ufw default deny incoming
sudo ufw allow 22960/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable
# 4. 自动安全更新（Ubuntu/Debian）
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
# 5. 非root日常用户 + sudo
sudo adduser deploy && sudo usermod -aG sudo deploy- Cloud security group = outer firewall; ufw/iptables = in-host firewall — configure BOTH
- Fail2ban for SSH brute force: it costs nothing and stops weeks-long credential stuffing
- Never expose MySQL/Redis ports to 0.0.0.0 — bind to 127.0.0.1 or keep them in the VPC
Domain, filing (备案) and DNS
| Case | Need ICP filing | Notes |
|---|---|---|
| 域名指向国内云服务器（80/443 web） | 必须 | 未备案会被服务商随时拦截、存在关站风险 |
| 只做 API/非 80 端口（1.2.3.4:8080） | 仍需备案（运营商/不影响端口服务也称需） | 实务上无备案 80/443 才被拦，但建议备 |
| 域名解析到海外服务器 | 不需要 | 但国内访问速度/合规另有成本 |
| 只买域名不做站 | 不需要 | 建议持有后即备（以免后续麻烦） |
If your site serves HTTP on 80/443 from a Chinese mainland server without an ICP filing, the provider will block it sooner or later. Budget 1-3 weeks for filing and do it before launch, not after.
# DNS 解析记录类型速记
A example.com → 1.2.3.4 （IPv4）
AAAA example.com → 2606:4700::... （IPv6）
CNAME www.example.com → example.com. （别名跳转）
MX example.com → mail provider （邮件交换）
TXT _dnsauth.example → key-1234 （域名所有权验证）Daily ops: monitoring, snapshots, backups
A server without monitoring and backups is a time bomb. Install the basics the same day you launch.
# 1. 云厂商监控插件+告警（控制台一键装 agent）
# 最低限度告警：CPU>80% 持续5分钟、内存>85%、磁盘>90%、带宽>阈值
# 2. 定时快照策略（控制台配，每天凌晨自动快照，保留7天）
# 3. 应用层备份脚本（crontab -e）
0 3 * * * /opt/backup/pg_dump.sh >> /var/log/backup.log 2>&1
# 4. 检查备份真的能恢复：每季度做一次恢复演练An unverified backup is a hypothesis. Periodically restore a snapshot/backup to a scratch instance and actually start the service against it — this is the only proof that counts when production dies at 3am.
买对东西
- 地域：选离用户物理距离最近的地域（华北/华东/华南各自对应人群）
- 镜像：Ubuntu 22.04/24.04 LTS，或团队熟悉的 RHEL 系；LTS 省去频繁升级
- 系统盘：40-60GB SSD 对大多数 API 服务足够；数据放独立数据盘或云数据库
- 带宽：起步 1-5M 固定带宽；有了真实流量数据后再调整或改按流量计费
两样最容易被省出事的资源：内存（高负载下 OOM，JVM 尤甚）和带宽（一个多图页面一秒就能把 1M 带宽吃满）。
上线第一小时的安全加固
顺序很重要：新云 IP 几分钟内就会被扫描。先加固再部署任何东西。
# 1. 用 SSH 密钥登录、禁掉密码登录（控制台先绑定公钥）
ssh-keygen -t ed25519 -C 'me@laptop'
ssh-copy-id -i ~/.ssh/id_ed25519.pub ubuntu@1.2.3.4
# 2. 改 SSH 端口 + 只允许密钥
sudo sed -i 's/^#Port 22/Port 22960/' /etc/ssh/sshd_config
sudo sed -i 's/^#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart sshd
# 3. 防火墙只放最小集合
sudo ufw default deny incoming
sudo ufw allow 22960/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable
# 4. 自动安全更新（Ubuntu/Debian）
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
# 5. 非root日常用户 + sudo
sudo adduser deploy && sudo usermod -aG sudo deploy- 云安全组是第一层防火墙，ufw/iptables 是主机内第二层——两层都要配
- 装 fail2ban 防 SSH 爆破：零成本，挡掉经年累月的撞库
- 绝不把 MySQL/Redis 端口开放到 0.0.0.0——绑定 127.0.0.1 或留在内网
域名、备案与 DNS 解析
| 情形 | 是否需备案 | 说明 |
|---|---|---|
| 域名指向国内云服务器（80/443 web） | 必须 | 未备案会被服务商随时拦截、存在关站风险 |
| 只做 API/非 80 端口（1.2.3.4:8080） | 仍需备案（运营商/不影响端口服务也称需） | 实务上无备案 80/443 才被拦，但建议备 |
| 域名解析到海外服务器 | 不需要 | 但国内访问速度/合规另有成本 |
| 只买域名不做站 | 不需要 | 建议持有后即备（以免后续麻烦） |
如果用国内大陆服务器通过 80/443 提供网站服务而没有 ICP 备案，服务商会随时拦截。预算 1-3 周备案时间，上线前办，别上线后补。
# DNS 解析记录类型速记
A example.com → 1.2.3.4 （IPv4）
AAAA example.com → 2606:4700::... （IPv6）
CNAME www.example.com → example.com. （别名跳转）
MX example.com → mail provider （邮件交换）
TXT _dnsauth.example → key-1234 （域名所有权验证）日常运维：监控、快照与备份
没有监控和备份的服务器就是定时炸弹。上线当天就把基础件装好。
# 1. 云厂商监控插件+告警（控制台一键装 agent）
# 最低限度告警：CPU>80% 持续5分钟、内存>85%、磁盘>90%、带宽>阈值
# 2. 定时快照策略（控制台配，每天凌晨自动快照，保留7天）
# 3. 应用层备份脚本（crontab -e）
0 3 * * * /opt/backup/pg_dump.sh >> /var/log/backup.log 2>&1
# 4. 检查备份真的能恢复：每季度做一次恢复演练没验证过的备份只是假设。定期把快照/备份恢复到临时实例并真正启动服务——这是凌晨三点生产挂掉时唯一算数的证据。