前書き

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

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

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

優先ソース

大まかな降順の優先順位で、次のインストールメカニズムを使用します。

  1. 最高と評価された場合の* project推奨方法*。 多くのプロジェクトはすぐに変更され、公式リポジトリを超えることをお勧めしますが、一部のインストール( `+ curl | bash +`パターンなど)では、それらを使用するかどうかの判断が必要です。

  2. 現在のディストリビューションおよびリリースの*公式パッケージリポジトリ*。

  3. 言語固有の公式パッケージ(NPM、CPAN、PIP、RubyGems、Composerなど)

  4. プロジェクト固有のパッケージリポジトリ(例: Nginxは、最新バージョン用に独自のリポジトリを提供しています)、またはUbuntuでは、信頼できるPPAです。 これらがプロジェクトの開発者やDebian / Ubuntuパッケージメンテナーなどの信頼できるソースからのものであることを確認してください。

  5. *プロジェクトのGitHubリリースページ*または同様の公式Webソースからのバイナリ。

  6. * `+ wget `または ` curl +`スクリプトをインストールする*シェルにパイプされ、スクリプトの検査に関する適切な警告が表示されます。

優先インストール場所

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

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

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

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

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

提案された変更を綿密に調べて破壊的なものが何も起きていないことを確認するため、一般的には `+ sudo apt-get upgrade `よりも ` sudo apt-get dist-upgrade `をお勧めします。 2つのコマンドは非常に似ていますが、一部の変更が保留されているため、「 upgrade 」の使用は予測しにくい場合があります。 特定のパッケージを保留すると、バージョンの不一致が発生し、実稼働システムで問題が発生する可能性があります。 + Ubuntu + 16.04では、 ` apt `のドキュメントがなく、ディストリビューションの優先パッケージマネージャーに関する混乱があるため、引き続き ` 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 +」を使用してください。

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

ルートを直接使用する代わりに、 `+ 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 *」グループのコメントを外す必要があります。 CentOS 6では、 ` sudo `はすでにインストールされていますが、* wheel *のコメントを外す必要があります。 CentOS 7には ` 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)は許容されますが、初心者向けのつまずきを引き起こす可能性がある入門的なトピックでは避けてください。

ファイル転送では、プッシュ機能が欠けていますが、ほとんどの場合、対話型およびscpに似た用途で「+ sftp 」をお勧めします。そのため、「 scp 」も受け入れられます。 ` rsync `は、バックアップと大きな転送(または多くの小さなファイル)に役立ちます。 どのような状況でもFTPを使用しないでください。 また、堅牢性のために、「 wget 」よりも「 curl 」で標準化するよう努力しています。 ` wget +`の利点は、主に再帰的なダウンロード(つまり、 私たちの種類のコンテンツでは一般的ではない特別なユースケース)。

`+ iproute2 `ユーティリティを搭載したマシンでは、http://lartc.org/howto/lartc.iproute2.html [廃止予定]である ` 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インタプリタ+`を優先します。

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

ファイルシステムの場所

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

Webサーバー

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

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

セキュリティ

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

具体的には、セキュリティで保護されていない接続を介してパスワードとキーマテリアルを送信しないでください。 データベース接続、ロギング、クラスター管理、およびその他のサービスは、常に暗号化することが理想的です。 ウェブベースのコントロールパネルはhttps://www.digitalocean.com/community/tags/let-s-encrypt?type=tutorials[HTTPS接続で提供]でなければならず、サポートされているサービスにはTLS / SSLを使用する必要があります。 プレーンHTTPのような公開サービスは、ユーザーが引き続き提供または提供する必要があるため、許可されますが、一般的な場合、特に動的コンテンツの場合は強く推奨されません。

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

SSH

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

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

インタラクティブキーにはパスフレーズを使用しますが、非インタラクティブプロセスには使用しません。 SSHアカウントの所有権を設定またはコピーして、ルートアカウントからユーザーのホームディレクトリに変更します。 実用的な場所にhttps://www.digitalocean.com/community/search?q=fail2ban[fail2ban]をインストールします。

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

SSL / TLS

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

ドメイン名のないホストの場合、適切な強度の自己署名証明書をお勧めします。 繰り返しますが、https://cipherli.st/に加えて、https://www.digitalocean.com/community/tutorials/how-to-create-a-self-signed-sslなどのガイドで使用されている自己署名証明書の作成を参照してください。 -certificate-for-nginx-in-ubuntu-16-04 [このNginxの自己署名証明書ガイド]。 https://www.digitalocean.com/community/tutorials/how-to-create-a-self-signed-ssl-certificate-for-apache-in-のように、暗号化を有効にするときに強力なDiffie-Hellmanキーを設定しますubuntu-16-04 [Apacheの自己署名SSL証明書]およびhttps://www.digitalocean.com/community/tutorials/how-to-create-a-self-signed-ssl-certificate-for-nginx-in -ubuntu-16-04 [Nginx]。

VPN

サーバー間の一般的な暗号化通信のソリューションとしてVPNをお勧めします。 複数のサービスをサーバー間で保護する必要がある場合、VPNはますます重要になります。各サービスを個別に暗号化する代わりに、すべての内部通信をVPNにパイプできます。 これは、問題のサービスがネイティブ暗号化をサポートしていない場合に特に便利です。

通常、サーバー間の通信にはOpenVPNよりもTincをお勧めします。 詳細については、https://www.digitalocean.com/community/tutorials/how-to-use-ansible-and-tinc-vpn-to-secure-your-server-infrastructure [Ansible and Tincに関するこの記事]をご覧ください。詳細と実装。

結論

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