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

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

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

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

提案された変更を詳しく調べて、破壊的なものが何も発生していないことを確認するため、通常、sudo apt-get upgradeよりもsudo apt-get dist-upgradeをお勧めします。 2つのコマンドは非常に似ていますが、一部の変更が抑制されているため、upgradeの使用は予測が難しい場合があります。 特定のパッケージを保留すると、バージョンの不一致が発生し、本番システムで問題が発生する可能性があります。
aptと一部のドキュメントが不足しているため、Ubuntu 16.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のコメントを解除する必要があります。 CentOS 7には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ユーティリティが付属しているマシンでは、considered obsoleteであるnet-toolsスイートよりもユーティリティを優先します。 一般に、ssのようなiproute2ユーティリティは、複数のインターフェイス、IPv6、新しいカーネル機能などをより適切にサポートします。 したがって、同様に、routeよりもip route、ifconfigよりもip addr showなどを使用する必要があります。 古いユーティリティの出力はデフォルトで少しきれいになっている場合もありますが、エッジケースも処理しないため、出力自体の信頼性は少し低くなります。 可能であれば、使用可能なフラグを使用して、より詳細な出力を制御します。

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

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

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

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

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

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

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

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

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

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

これは、本質的に意見のある生きた文書であり、頻繁に更新されます。 技術は急速に変化しており、DigitalOceanでは常に最新の情報を提供するよう努めていますが、エラーに気づいた場合やフィードバックがある場合は、以下のコメントを監視します。