DigitalOcean教程的技术建议和最佳实践
2017-02-01
分类：系统运维
阅读()
评论()
介绍
本指南旨在总结针对DigitalOcean教程作者的已建立的最佳实践和强有力的建议。它旨在为DigitalOcean的教学材料的一致性，技术正确性和易用性提供基础。 根据内部技术作家和编辑，社区管理者和工程师的日益增长的经验，这本质上是一个正在进行的工作和一个有意见的文件。其建议可能会更改，并专门针对教育内容，包括广泛的读者和最终用户。
软件来源和安装
首选来源
按粗体，按优先级降序，使用以下安装机制：
- 该项目推荐的方法 ，当评价最好。 许多项目改变很快，并建议超越官方的存储库，但一些安装（如
curl | bash模式）需要一个判断调用是否使用它们。
- 当前发行版和发行版的官方软件包存储库 。
- 特定语言的官方包 （NPM，CPAN，PIP，RubyGems，Composer等）
- 特定于项目的软件包存储库 （例如Nginx为最新版本提供自己的软件库），或者在Ubuntu上，可信的PPA。确保这些是来自一个值得信赖的来源，如项目的开发人员或Debian / Ubuntu软件包维护者。
- 来自项目的GitHub的二进制文件发布页面或类似的官方Web源。
wget或curl安装脚本管道到shell，并有关于检查脚本的适当警告。
首选安装位置
一般来说，避免不必要的并发症。对于从源代码或二进制文件安装的未打包软件，通常应该接受默认安装前缀，除非它非常不寻常或引入冲突。 如果不是通过包或其他安装方法提供，则应为面向服务的软件提供符合发布的官方建议的初始化脚本。 在Linux系统上，在
/opt和独立脚本中将自包含的二进制文件或目录放在
/usr/local/bin 。
软件和系统维护
Ubuntu和Debian系统应该进行
unattended-upgrades ，至少安装和配置安全更新。在上下文中，我们建议不要自动重新启动或自动更新所有。 我们通常建议使用
sudo apt-get dist-upgrade而不是
sudo apt-get dist-upgrade
sudo apt-get upgrade ，仔细观察建议的更改以确保没有任何破坏性。 这两个命令非常相似，但使用
upgrade可能不太可预测，因为一些更改被阻止。 保留某些包装可能导致版本不匹配，从而可能导致生产系统出现问题。 我们将继续在Ubuntu 16.04上使用
apt-get ，因为缺少
apt的文档以及一些关于分发首选软件包管理器的动荡。
服务管理
确保使用本机init系统命令，即使有旧版本的兼容性命令可用。例如，使用
sudo systemctl start [service_name]即使
sudo service [service_name] start将工作。 提供有关如何在启动时启动或禁用服务的信息。指示在没有由接口明确指示（
journalctl -u ，
systemctl status等）时如何检查服务相关命令的结果。 Preferences作为经验法则重新启动重新加载服务。在大多数情况下，确保已知状态比避免分秒服务中断更重要，并且在完全服务故障的情况下重新启动也更有用。
自举系统
除非它是配置管理工作流的一部分，更喜欢用户数据脚本，并且在大多数情况下，更喜欢cloudinit脚本在用户数据中bash脚本。
日志和故障排除
说明在何处以及如何访问已安装服务的日志。在相关的情况下，请解释
systemctl和
journalctl命令以检查服务状态和日志输出。在可能的情况下，提供简明的建议诊断常见的故障情况。 确保在任何情况下处理日志轮换，而不是由程序包或其他安装机制处理。 对于以下纯文本日志文件，请使用
tail -F ，而不是
tail -f ，因为后者不会跨越重命名跟踪文件，并且如果在用户观看日志时旋转日志，可能会导致混乱。
用户和组管理
创建
sudo用户，而不是直接使用root。参考适当的初始服务器设置指南，作为先决条件解释此任务。 在基于Debian的发行版上，分别使用
adduser sammy和
deluser --remove-home sammy添加和删除用户; 在基于RHEL的分发上，使用
adduser sammy （如果需要，请使用
passwd sammy设置密码）和
userdel -r sammy 。 使用
usermod -aG sudo sammy在Ubuntu上授予
sudo权限。 CentOS有点复杂。 现代版本使用
usermod -aG wheel sammy ，但有些版本需要
visudo才能取消
wheel组权限的注释。 具体来说，在CentOS 5上，需要
sudo ，并且需要用
visudo注释
轮组; 在CentOS 6上，
sudo已经安装，但是
轮需要取消注释; CentOS 7有
sudo和
轮组已经设置。 使用特权升级命令时，请确保将其测试为已写。要通过
sudo传递环境变量，请使用
sudo -E command_to_run （如果对整个环境可信）或
sudo FOO=BAR command_to_run 。 对于需要根shell的实例，请使用
sudo -i 。 对于需要重定向的实例，使用
tee -a来追加而不是替换目标文件：
[sudo] command_to_run | sudo tee [-a] file_to_change
[sudo] command_to_run | sudo tee [-a] file_to_change 。
首选工具
对于交互式shell，假设在GNU / Linux系统上的Bash，在相关时明确提到。在FreeBSD上，使用tcsh，因为它是开箱即用的，并有有用的功能。 对于文本编辑器，我们包括副本“use [preferred]或您最喜欢的文本编辑器”，并在命令中包括以下初学者友好的编辑器用于这些复制和粘贴。在Linux上，我们默认为
nano ; 在FreeBSD上，我们默认为
ee 。 vi（m）是允许的，但在介绍性主题中可以避免它，它可能为初学者提供一个绊脚石。 对于文件传输，我们通常建议
sftp在大多数情况下为其交互和scp相似的用途，虽然它缺乏推功能，所以
scp也是可以接受的。
rsync对于备份和大型传输（或许多小文件）很有用。 不要在任何情况下使用FTP。 我们还努力标准化
wget
curl ，因为它的鲁棒性。
wget的优势主要是递归下载（即一种特殊的用例，这种情况对我们的内容来说不常见）。 在使用
iproute2实用程序的机器上，我们更喜欢使用
net-tools套件，这被
视为已过时 。 一般来说，类似
ss
iproute2实用程序将更好地支持多个接口，IPv6，新的内核功能等等。所以同样，我们应该使用
ip route
route ，
ip addr show超过
ifconfig等。“有时，老的实用程序输出是一个但是输出本身不太可信，因为它们不处理边缘情况。当可能时，我们将使用可用的标志控制更详细的输出。
脚本
在系统管理教程的上下文中，通常避免冗长的自定义脚本和长shell脚本。 作者编写的脚本（可能还有其他资源）应该存放在do-community GitHub帐户中的每篇文章存储库中，并返回到发布教程的链接。遵循一般的良好的脚本实践。例如，放置任何变量，用户必须在脚本的顶部填充，最好在一个很好的标记部分。还要确保慎重地评论;在DO教程中内联的脚本的主体不应该作为一个黑盒子。用户应该能够通过阅读它的意思。 在可移植性或跨平台重用是需要关注的时候，首选
/bin/sh到
bash ，并避免Bash特有的功能。 使用shell和coreutils /标准Unix工具进行小任务; 避免引入新的依赖关系纯粹为胶合语言任务，除非好处是重大的。 首选
#!/usr/bin/env interpreter到
#!/path/to/interpreter 。 一般来说，使用
cron来调度重复任务，但systemd计时器也是可以接受的。
文件系统位置
在下载脚本或数据时，请确保用户位于可写目录中或路径已明确指定。对于应该可供引用或重用的文件，请使用用户的主目录，除非它们属于文件系统上其他位置的某个标准明确定义的路径（例如
/opt或
/etc ）。 对于一次性文件，请使用
/tmp 。
Web服务器
我们建议使用Debian样式的配置目录，以便在默认情况下不以此方式构造它。总是测试配置更改（Apache sues
sudo apachectl configtest ，Nginx使用
sudo nginx -t ）。
/var/www/html应该用作所有Web服务器的文档根目录。 Nginx的
/usr/share/nginx/html默认值应该更改，因为该目录由所有者拥有，并且可能会被软件包更新修改。这在Ubuntu 16.04中不再是一个问题，但仍然与以前的版本相关。
安全
加密和验证系统之间的所有连接。不鼓励（明确或隐含地）用户以清楚的方式发送凭据或传输非公开数据。 具体来说，密码和密钥材料不得通过不安全的连接传输。理想情况下，数据库连接，日志记录，集群管理和其他服务应始终加密。基于Web的控制面板必须
通过HTTPS连接提供 ，并且TLS / SSL应用于支持它的服务。面向公众的服务（例如纯HTTP）是允许的，因为用户可能仍然希望或需要提供它们，但在一般情况下应该强烈反对，特别是对于动态内容。 避免通过模糊或字幕构成低利益安全的做法，例如更改默认的SSH端口。请配置防火墙。我们特定于发行版的建议是Ubuntu的
ufw ，Debian的
iptables和CentOS的
firewalld 。 但是，
iptables在各个平台之间是最一致的，并且有许多工具可以挂钩。 管理SELinux，注意它已关闭。
SSH
我们建议不要更改默认SSH端口，以避免低利益的安全性通过隐蔽实践。更改端口可能有助于削减日志中的碎片，但这只应该在主要关注的特定情况下进行。 禁用密码认证并对root使用纯钥验证，或者完全禁用root登录。确保使用强SSH密钥，至少2048位RSA，但建议4069; ECDSA不再被推荐用于技术原因，Ed25519和椭圆曲线算法没有得到足够广泛的支持。 对任何交互式密钥使用密码，但不用于非交互式过程。设置或复制SSH密钥的所有权并将其从根帐户更改为用户主目录。在实际操作中安装
fail2ban 。 请注意，虽然SSH代理转发对于像CoreOS这样的平台上的正常工作流程是必需的，但它有一些安全问题。基本上，任何在主机上拥有权限的用户都可以使用转发套接字连接到本地ssh-agent。
SSL / TLS
我们强烈建议使用Let's Encrypt以方便使用，并建议使用TLS。使用强SSL安全;看看
https://cipherli.st/ （现代和传统的建议）。 对于没有域名的主机，我们建议使用足够强度的自签名证书。再次，看看
https://cipherli.st/加上自签名证书创建中使用的指南，像
这样的自签名证书Nginx指南 。 启用加密时设置强Diffie-Hellman密钥，如在
Apache和
Nginx
上的自签名SSL证书中 。
VPN
我们建议VPN作为服务器之间的通用加密通信的解决方案。当在服务器之间需要保护多个服务时，VPN变得越来越有价值;而不是单独加密每个服务，所有内部通信可以被管道连接到VPN。如果有问题的服务不支持本机加密，这是特别有用的。 我们通常建议在OpenVPN上使用Tinc来进行服务器到服务器的通信。您可以阅读
关于Ansible和Tinc的
这篇文章，了解更多详细信息和实现。
结论
这本质上是一个有见地的，活的文档，并且将经常更新。技术变化很快，我们在DigitalOcean尽力跟上，但如果你注意到任何错误或有反馈，我们将监测以下评论。
觉得文章有用就打赏一下文章作者
支付宝扫一扫打赏
微信扫一扫打赏
