序章

このガイドは、DigitalOceanチュートリアルの作成者向けに確立されたベストプラクティスと強力な推奨事項を要約するための取り組みです。 これは、DigitalOceanの教材で一貫性、技術的正確性、および使いやすさの基盤を提供することを目的としています。

This guide is by nature both a work in progress and an opinionated document, based on the growing experience of in-house technical writers and editors, community managers, and engineers.  その推奨事項は変更される可能性があり、幅広い読者とエンドユーザーを念頭に置いた教育コンテンツ向けに特別に作成されています。

ソフトウェアのソースとインストール

Many tutorials will rely on existing tutorials as prerequisites. Put all prerequisites for the article (including any nested prerequisites for the prerequisites) into the article, rather than having deeply nested prereq lists.

優先ソース

大まかに、優先度の高い順に、次のインストールメカニズムを使用します。

  1. プロジェクトが推奨する方法、最良と評価された場合。 多くのプロジェクトはすぐに変更され、公式リポジトリを超えることをお勧めしますが、一部のインストール（ curl | bash パターン）それらを使用するかどうかについての判断の呼び出しが必要です。
  2. 現在の配布およびリリース用の公式パッケージリポジトリ。
  3. 言語固有の公式パッケージ（NPM、CPAN、PIP、RubyGems、Composerなど）
  4. プロジェクト固有のパッケージリポジトリ（例： Nginxは、最新バージョン用の独自のリポジトリを提供します）、またはUbuntuでは信頼できるPPAを提供します。 これらがプロジェクトの開発者やDebian/Ubuntuパッケージメンテナなどの信頼できるソースからのものであることを確認してください。
  5. プロジェクトのGitHubリリースページまたは同様の公式Webソースからのバイナリ。
  6. wgetまたはcurlインストールスクリプトがシェルにパイプされ、スクリプトの検査に関する適切な警告が表示されます。

推奨される設置場所

一般的に、不必要な合併症は避けてください。 ソースまたはバイナリからインストールされたパッケージ化されていないソフトウェアの場合、非常に珍しい場合や競合が発生する場合を除いて、通常はデフォルトのインストールプレフィックスを受け入れる必要があります。

パッケージまたは他のインストール方法で提供されていない場合は、サービス指向ソフトウェアに対して、配布に関する公式の推奨事項に準拠したinitスクリプトを提供する必要があります。

Linuxシステムでは、自己完結型のバイナリまたはディレクトリを /opt およびスタンドアロンスクリプト /usr/local/bin.

ソフトウェアとシステムのメンテナンス

UbuntuとDebianシステムには unattended-upgrades 少なくともセキュリティ更新プログラムがインストールおよび構成されている。 状況に応じて、自動再起動やすべての自動更新を行わないことをお勧めします。

We generally recommend using the apt command for Ubuntu 18.04 and newer. Change apt-get と apt-cache to use apt. When updating apt commands, do not use the -y flag; readers should be guided through any necessary inputs and prompts.

For CentOS and Rocky Linux tutorials, we now recommend using dnf, which has superseded yum and provides better performance.

If a tutorial relies on the latest updates, call update と upgrade during Step 1 setup or as needed. Call update first so that your server pulls the latest versions of packages. When including upgrade, which downloads and installs new versions for every package, please be aware that some users may choose to keep certain packages at a lower version.

サービス管理

従来の互換性コマンドが利用可能な場合でも、必ずネイティブのinitシステムコマンドを使用してください。 たとえば、 sudo systemctl start [service_name] それでも sudo service [service_name] start 動作します。

起動時にサービスを有効または無効にする方法に関する情報を提供します。 インターフェイスで明確に示されていない場合に、サービス関連のコマンドの結果を検査する方法を示します（journalctl -u, systemctl status、など）。

経験則として、サービスのリロードよりも再起動を優先します。 ほとんどの場合、一瞬のサービス中断を回避するよりも既知の状態を確認することが重要です。また、完全なサービス障害が発生した場合は、再起動の方が便利です。

ブートストラップシステム

構成管理ワークフローの一部でない限り、ほとんどの場合、ユーザーデータスクリプトを優先し、ユーザーデータのbashスクリプトよりもcloudinitスクリプトを優先します。

ロギングとトラブルシューティング

インストールされているサービスのログにアクセスする場所と方法を説明します。  関連する場合は、説明してください systemctl と journalctl サービスステータスとログ出力をチェックするためのコマンド。 可能な場合は、一般的な障害のケースを診断するための簡潔な提案を提供してください。

パッケージやその他のインストールメカニズムで処理されない場合は、必ずログローテーションを処理してください。

次のプレーンテキストログファイルには、 tail -F、 いいえ tail -f、後者は名前の変更を超えてファイルを追跡せず、ユーザーがログを監視しているときにログがローテーションされると混乱を引き起こす可能性があるためです。

ユーザーとグループの管理

作成 sudo rootを直接使用する代わりにユーザー。  このタスクを前提条件として説明している適切な初期サーバーセットアップガイドを参照してください。

Debianベースのディストリビューションでは、 adduser sammy と deluser --remove-home sammy それぞれ; RHELベースのディストリビューションでは、 adduser sammy （でパスワードを設定します passwd sammy 必要に応じて）および userdel -r sammy.

許す sudo 特権 usermod -aG sudo sammy Ubuntuで。 CentOSはもう少し複雑です。 最新バージョンは usermod -aG wheel sammy、ただし、一部のバージョンでは visudo コメントを外す wheel 最初に権限をグループ化します。 具体的には、CentOS5では sudo インストールする必要があり、Wheelグループのコメントを解除する必要があります visudo; CentOS6では sudo はすでにインストールされていますが、Wheelのコメントを解除する必要があります。 CentOS7には sudo Wheelグループはすでに設定されています。

特権エスカレーションされたコマンドを使用する場合は、必ず記述どおりにテストしてください。 環境変数を渡すには sudo、 使用する sudo -E command_to_run （環境全体で信頼されている場合）または sudo FOO=BAR command_to_run. ルートシェルが必要なインスタンスの場合は、 sudo -i. リダイレクトが必要なインスタンスの場合は、 tee -a 宛先ファイルを置き換えるのではなく、追加するには： [sudo] command_to_run | sudo tee [-a] file_to_change.

優先ツール

インタラクティブシェルの場合、GNU / LinuxシステムでBashを想定します。これは、関連する場合に明示的に言及されています。 FreeBSDでは、tcshを使用します。これは、箱から出してすぐに利用でき、便利な機能を備えているためです。

テキストエディタの場合、「[推奨]またはお気に入りのテキストエディタを使用する」というコピーを含め、それらのコピーと貼り付けのコマンドに次の初心者向けのエディタを含めます。 Linuxでは、デフォルトで nano; FreeBSDでは、デフォルトで ee. vi（m）は許容されますが、初心者にとってつまずきとなる可能性のある入門トピックでは避けてください。

ファイル転送については、一般的にお勧めします sftp ほとんどの場合、プッシュ機能はありませんが、インタラクティブでscpに似た用途に使用されます。 scp 同様に受け入れられます。 rsync バックアップや大きな転送（または多くの小さなファイル）に役立ちます。 いかなる状況でもFTPを使用しないでください。 また、標準化に努めています curl 以上 wget その堅牢性のため。 wgetの利点は、主に再帰的なダウンロードです（つまり、 私たちの種類のコンテンツでは一般的ではない特別なユースケース）。

付属のマシンの場合 iproute2 ユーティリティ、私たちはそれらよりもそれらを好む net-tools 廃止されたと見なされるスイート。 一般に、 iproute2 のようなユーティリティ ss 複数のインターフェイス、IPv6、新しいカーネル機能などのサポートが向上します。 同様に、使用する必要があります ip route 以上 route, ip addr show 以上 ifconfig、など。 古いユーティリティの出力はデフォルトで少しきれいな場合がありますが、エッジケースも処理しないため、出力自体の信頼性は少し低くなります。 可能な場合は、使用可能なフラグを使用して、より詳細な出力を制御します。

スクリプティング

システム管理チュートリアルのコンテキスト内では、通常、長いカスタムスクリプトや長いシェルスクリプトは避けてください。

著者が作成したスクリプト（および場合によっては他のリソース）は、公開されたチュートリアルへのリンクとともに、do-communityGitHubアカウントの記事ごとのリポジトリに存在する必要があります。 一般的に、適切なスクリプト作成方法に従ってください。 たとえば、ユーザーが入力する必要のある変数をスクリプトの上部、できれば適切にマークされたセクションに配置します。 Provide in-line comments where needed to provide human-readable scripts. Ensure that your descriptions of the code are not exclusively provided in comments, but that you also provide prose descriptions with further explanation than appears in comments.

好む /bin/sh に bash 移植性やクロスプラットフォームの再利用が懸念される場合は、Bash固有の機能を避けてください。 小さなタスクにはシェルとcoreutils/標準のUnixツールを使用します。 メリットが大きい場合を除いて、純粋にグルー言語タスクのために新しい依存関係を導入することは避けてください。 好む #!/usr/bin/env interpreter に #!/path/to/interpreter.

一般的に、 cron 定期的なタスクをスケジュールするために使用しますが、systemdタイマーも使用できます。

ファイルシステムの場所

Use your_server_ip と your_domain when possible instead of documentation IP ranges or example.com.

スクリプトまたはデータをダウンロードするときは、ユーザーが書き込み可能なディレクトリにいること、またはパスが明示的に指定されていることを確認してください。 参照または再利用できるはずのファイルについては、ファイルシステムの他の場所にある標準の明確に定義されたパス（ファイルシステムなど）に属していない限り、ユーザーのホームディレクトリを使用します。 /opt また /etc). 使い捨てファイルの場合は、 /tmp.

When a tutorial relies on a specific directory, be sure to provide the cd commands that route the reader to that directory before they run commands.

Webサーバー

デフォルトでそのように構造化されていないディストリビューションには、Debianスタイルの設定ディレクトリをお勧めします。  常に構成の変更をテストします（Apacheは sudo apachectl configtest、およびNginxは sudo nginx -t). /var/www/html すべてのWebサーバーのドキュメントルートとして使用する必要があります。 Nginxの /usr/share/nginx/html そのディレクトリはパッケージの更新によって所有され、変更される可能性があるため、デフォルトを変更する必要があります。  これはUbuntu16.04では問題ではなくなりましたが、以前のリリースには引き続き関連します。

For Apache or Nginx tutorials, use dedicated virtual host blocks instead of editing the default config files. This route can avoid common mistakes and maintain the default files as the fallback configuration as intended.

安全

システム間のすべての接続を暗号化および認証します。 （明示的または暗黙的に）ユーザーに資格情報を送信したり、非公開データを平文で送信したりすることを奨励しないでください。

具体的には、パスワードとキーマテリアルをセキュリティで保護されていない接続を介して送信してはなりません。 Database connections, logging, cluster management, and other services should ideally be encrypted at all times.

Web-based control panels must be served over HTTPS connections, and TLS/SSL should be used for services where it’s supported. All web servers should be HTTPS-enabled (or capable, at least). Use a certbot prerequisite to provide SSL certification. Public-facing services like plain HTTP are permissible, as users may still want or need to offer them, but should be strongly discouraged in the general case, especially for dynamic content. For articles that provide a plain HTTP connection, add a note or warning label to discourage plain HTTP and encourage HTTPS.

デフォルトのSSHポートを変更するなど、隠すことや演劇によって利益の少ないセキュリティを構成する方法は避けてください。 ファイアウォールを構成してください。 ディストリビューション固有の推奨事項は次のとおりです。 ufw Ubuntuの場合、 iptables Debianの場合、および firewalld CentOSの場合。 でも、 iptables プラットフォーム間で最も一貫性があり、それに接続する多くのツールがあります。

SSH

Maintain the default SSH port as a norm. Changing the port should only be done in specific situations where that is a primary concern.

Disable password authentication and use key-only authentication for root or, alternatively, disable root login completely. Use strong SSH keys: at least 2048-bit RSA but recommended 4096; ECDSA is no longer recommended for technical reasons; and Ed25519 and elliptic curve algorithms are not widely supported enough.

インタラクティブキーにはパスフレーズを使用しますが、非インタラクティブプロセスには使用しません。 SSHキーの所有権を設定するか、コピーして、rootアカウントからユーザーのホームディレクトリに変更します。 fail2banを実用的な場所にインストールします。

CoreOSなどのプラットフォームでの通常のワークフローにはSSHエージェント転送が必要ですが、セキュリティ上の懸念がいくつかあることに注意してください。 基本的に、ホストに対するアクセス許可を持っている人は誰でも、転送ソケットを使用してローカルのssh-agentに接続できます。

SSL / TLS

使いやすさのためにLet’sEncryptの使用を強くお勧めし、TLSをお勧めします。 強力なSSLセキュリティを使用してください。 https://cipherli.st/ （最新の推奨事項と従来の推奨事項の両方）をご覧ください。

ドメイン名のないホストの場合は、十分な強度の自己署名証明書をお勧めします。 繰り返しになりますが、 https://cipherli.st/ に加えて、このNginxガイドの自己署名証明書などのガイドで使用される自己署名証明書の作成を確認してください。 ApacheおよびNginxでの自己署名SSL証明書のように、暗号化を有効にするときに強力なDiffie-Hellmanキーを設定します。

VPN

サーバー間の一般的な暗号化通信のソリューションとしてVPNをお勧めします。 サーバー間で複数のサービスを保護する必要がある場合、VPNの価値はますます高まります。 各サービスを個別に暗号化する代わりに、すべての内部通信をVPNにパイプすることができます。 This approach is particularly useful if the services in question don’t support native encryption.

サーバー間の通信には、通常、OpenVPNではなくTincをお勧めします。 詳細と実装については、AnsibleとTincに関するこの記事をお読みください。

結論

これは本質的に意見のある生きた文書であり、頻繁に更新されます。 技術は急速に変化し、DigitalOceanはそれに追いつくために最善を尽くしますが、エラーに気付いたりフィードバックがあったりした場合は、以下のコメントを監視します。