DigitalOceanのチュートリアルに関する技術的な推奨事項とベストプラクティス

序章

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

これは本質的に、社内のテクニカルライターと編集者、コミュニティマネージャー、およびエンジニアの成長する経験に基づいた、進行中の作業と意見のあるドキュメントの両方です。その推奨事項は変更される可能性があり、幅広い読者とエンドユーザーを念頭に置いた教育コンテンツ向けに特別に作成されています。

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

優先ソース

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

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

推奨される設置場所

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

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

Linuxシステムでは、自己完結型のバイナリまたはディレクトリを/optに配置し、スタンドアロンスクリプトを/usr/local/binに配置します。

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

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

提案された変更を詳しく調べて、破壊的なものが何も発生していないことを確認するため、通常はsudo apt-get upgradeよりもsudo apt-get dist-upgradeをお勧めします。 2つのコマンドは非常に似ていますが、upgradeを使用すると、一部の変更が抑制されるため、予測が難しくなる可能性があります。特定のパッケージを保留すると、バージョンの不一致が発生し、本番システムで問題が発生する可能性があります。 aptのドキュメントが不足していることと、ディストリビューションの優先パッケージマネージャーに関する混乱があるため、Ubuntu16.04では引き続きapt-getを使用します。

サービス管理

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

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

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

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

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

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

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

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

次のプレーンテキストログファイルには、tail -fではなくtail -Fを使用します。後者は名前変更全体でファイルを追跡せず、ユーザーがログを監視しているときにログをローテーションすると混乱を招く可能性があります。

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

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

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

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

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

優先ツール

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

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

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

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

スクリプティング

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

著者が作成したスクリプト（および場合によっては他のリソース）は、公開されたチュートリアルへのリンクとともに、do-communityGitHubアカウントの記事ごとのリポジトリに存在する必要があります。一般的に、適切なスクリプト作成方法に従ってください。たとえば、ユーザーが入力する必要のある変数をスクリプトの上部、できれば適切にマークされたセクションに配置します。また、注意深くコメントするようにしてください。 DOチュートリアルにインライン化されたスクリプトの本体は、ブラックボックスとして機能するべきではありません。ユーザーはそれを読んで意味を理解できるはずです。

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

一般に、定期的なタスクのスケジューリングにはcronを使用しますが、systemdタイマーも使用できます。

ファイルシステムの場所

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

Webサーバー

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

今後は、提供されているデフォルトファイルを変更するのではなく、新しいApache仮想ホストファイルまたはNginxサーバーブロックファイルを作成することをお勧めします。これにより、よくある間違いを回避し、デフォルトのファイルをフォールバック構成として意図したとおりに維持できます。

安全

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

具体的には、パスワードとキーマテリアルをセキュリティで保護されていない接続を介して送信してはなりません。データベース接続、ロギング、クラスター管理、およびその他のサービスは、理想的には常に暗号化する必要があります。 WebベースのコントロールパネルはHTTPS接続で提供する必要があり、TLS/SSLはサポートされているサービスに使用する必要があります。プレーンHTTPのような公開サービスは、ユーザーが引き続き提供したい、または提供する必要があるため、許可されますが、一般的な場合、特に動的コンテンツの場合は、強くお勧めしません。

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

SSH

隠すことによるセキュリティのメリットが低いという慣行を回避するために、デフォルトのSSHポートを変更しないことをお勧めします。ポートを変更すると、ログから雑多なものを取り除くのに役立つ場合がありますが、これは、それが主な懸念事項である特定の状況でのみ行う必要があります。

パスワード認証を無効にし、rootに対してキーのみの認証を使用するか、またはrootログインを完全に無効にします。強力なSSHキー、少なくとも2048ビットのRSAを使用するようにしてください。ただし、4096を推奨します。 ECDSAは技術的な理由から推奨されなくなり、Ed25519および楕円曲線アルゴリズムは十分に広くサポートされていません。

インタラクティブキーにはパスフレーズを使用しますが、非インタラクティブプロセスには使用しません。 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にパイプすることができます。これは、問題のサービスがネイティブ暗号化をサポートしていない場合に特に役立ちます。

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

結論

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