デジタルオーシャンのチュートリアルのための技術的な推奨事項とベストプラクティス

1年 ago

優斗, 朝陽

2 minutes

以下の文を日本語で自然な言い方に言い換えてください。一つのオプションだけで構いません。

イントロダクション

このガイドは、Silicon Cloudのチュートリアルの著者向けに確立されたベストプラクティスと強力な推奨事項をまとめたものです。Silicon Cloudの教材において一貫性、技術的な正確性、利用の容易さを提供することを目的としています。

このガイドは進行中の作業であり、意見の強い文書であり、社内の技術ライターや編集者、コミュニティマネージャー、エンジニアの経験に基づいています。その推奨事項は変更される可能性があり、広範な読者やエンドユーザーを対象にした教育コンテンツに特化して書かれています。

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

多くのチュートリアルは、前提条件として既存のチュートリアルに依存することがあります。必要な前提条件（前提条件の中にネストされている前提条件も含む）を、深くネストされた前提条件のリストを作るのではなく、記事内にまとめて記載してください。

好ましい情報源

以下に示すインストールメカニズムを、おおよその好みの順に使ってください。

適切な警告と共に、シェルにパイプされるwgetやcurlのインストールスクリプトを検査するように注意してください。

好ましい設置場所

一般的には、不必要な複雑さを避けるべきです。ソースコードやバイナリからインストールする際には、通常はデフォルトのインストール先を選択するべきです。ただし、非常に珍しい場合や競合を引き起こす場合などは、別のインストール先を選択するべきです。

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

Linuxシステムでは、自己完結型のバイナリやディレクトリは/optに配置し、単独のスクリプトは/usr/local/binに配置します。

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

以下の文を日本語で言い換えますが、一つのオプションだけで構いません：
UbuntuとDebianシステムでは、最低限セキュリティ更新がインストールおよび設定された無人運用アップグレードが必要です。文脈に応じて、自動再起動や自動全更新はお勧めしません。

通常、Ubuntu 18.04以降では、aptコマンドの使用をおすすめします。apt-getとapt-cacheの代わりにaptを使用してください。aptコマンドを更新する際、-yフラグは使用しないでください。必要な入力やプロンプトについて読者に案内してください。

CentOSおよびRocky Linuxのチュートリアルでは、yumの代わりによりパフォーマンスの向上したdnfの使用をおすすめします。

最新のアップデートに依存しているチュートリアルの場合、ステップ1のセットアップ中または必要な時にアップデートとアップグレードを呼び出してください。アップデートを先に呼び出すことで、サーバーがパッケージの最新バージョンを取得します。アップグレードも含んだ場合は、全てのパッケージの新しいバージョンをダウンロードしてインストールしますが、一部のユーザーは特定のパッケージをより低いバージョンに保持することを選択する可能性があることに注意してください。

サービスマネジメント

レガシー互換コマンドが利用可能であっても、必ずネイティブの起動システムコマンドを使用してください。例えば、「sudo service [service_name] start」が機能する場合でも、「sudo systemctl start [service_name]」を使用してください。

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

原則として、サービスの再起動をリロードよりも選ぶ方が好ましいです。ほとんどの場合、一瞬のサービスの中断を避けるよりも、既知の状態を確保することがより重要であり、再起動は完全なサービスの障害が発生した場合にもより有用です。

ブートストラッピングシステム

設定管理ワークフローの一部でない限り、一般的にはユーザデータスクリプトを好み、その中でもクラウディニットスクリプトをユーザデータ内のbashスクリプトより好む。

ログ記録およびトラブルシューティング

インストールされたサービスのログへのアクセス方法と場所について説明します。必要な場合は、サービスの状態とログの出力を確認するために使用するsystemctlとjournalctlのコマンドについて説明します。一般的な障害の診断に役立つ簡潔な提案が可能な場合は提供します。

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

以下の平文ログファイルについては、「tail -f」ではなく、「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というコマンドでsammyユーザーにsudo特権を付与します。CentOSは少し複雑です。最新のバージョンでは、usermod -aG wheel sammyを使用しますが、一部のバージョンでは事前にwheelグループの許可を解除するためにvisudoが必要です。具体的には、CentOS 5ではsudoをインストールし、visudoを使用してwheelグループのコメントを解除する必要があります。CentOS 6ではsudoはすでにインストールされていますが、wheelのコメントを解除する必要があります。CentOS 7ではsudoがインストールされ、wheelグループもすでに設定されています。

特権を上げたコマンドを使用する際には、そのままで実行できるかテストするようにしてください。環境変数をsudo経由で渡す場合は、「sudo -E command_to_run」と入力してください（環境全体を信頼している場合）または「sudo FOO=BAR command_to_run」と入力してください。ルートシェルが必要な場合は、「sudo -i」と入力してください。リダイレクトが必要な場合は、「sudo tee [-a] file_to_change」と入力してください。ファイルの置き換えではなく追記するために「tee -a」を使用してください。

希望するツール

インタラクティブシェルに関しては、関連する場合には明示的にBash on GNU/Linuxシステムを使用することとします。しかし、FreeBSDではデフォルトで利用可能な便利な機能を持つtcshを使用してください。

テキストエディターに関して、コピーに「[好きな]もしくはお気に入りのテキストエディターを使用してください」と記載し、コピー＆ペーストに向いた以下の初心者向けエディターをコマンドに含めます。Linuxではnanoを、FreeBSDではeeをデフォルトとします。vi(m)は許容しますが、初心者にとってつまずきの原因となる可能性がある入門テーマでは避けてください。

ファイルの転送については、通常はインタラクティブでscpと似たような使い方ができるsftpを推奨していますが、push機能がないため、scpも利用可能です。バックアップや大容量の転送（または多数の小さなファイル）にはrsyncが便利です。どんな場合でもFTPは使用しないでください。また、頑強さを理由にcurlをwgetよりも標準化するよう努めています。wgetの利点は主に再帰的なダウンロード（つまり、われわれのコンテンツには一般的でない特殊な使用方法）です。

iproute2ユーティリティが搭載されたマシンでは、時代遅れとされるnet-toolsスイートではなく、iproute2ユーティリティを優先します。一般的に、ssのようなiproute2ユーティリティは、複数のインタフェースやIPv6、新しいカーネルの機能などに対してより良いサポートを提供します。したがって、routeの代わりにip route、ifconfigの代わりにip addr showなどを使用するべきです。古いユーティリティの出力は時にデフォルトでは少し見やすいですが、エッジケースの処理がうまくいかないため、出力自体は信頼性に欠けることがあります。可能な場合は、利用可能なフラグを使用してより詳細な出力を制御します。

脚本化する

システム管理のチュートリアルの中では、通常、長いカスタムスクリプトや長いシェルスクリプトは避ける方が良いです。

著者が作成したスクリプト（および他のリソース）は、公開されたチュートリアルへのリンクを含んだ記事ごとのリポジトリに保存されるべきです。一般的なスクリプティングのベストプラクティスに従ってください。例えば、ユーザーが入力する変数はスクリプトのトップに、可能な限り明示的に配置しましょう。人間に読みやすいスクリプトを提供するために、必要に応じて行内コメントを追加してください。コードの説明はコメントだけではなく、コメントに記載されている以上の詳細な説明を含む文章の形でも提供してください。

ポータビリティやクロスプラットフォームの再利用が懸念される場合は、bashではなく/bin/shを選択し、Bash固有の機能を避けてください。小さなタスクにはシェルとcoreutils/標準のUnixツールを使用し、新しい依存関係を導入することは避けてください（ただし、メリットが大きい場合は除く）。インタープリターには#!/usr/bin/envを使用し、#!/path/to/interpreterを避けてください。

一般的には、繰り返しタスクのスケジュールにはcronを使用しますが、systemdのタイマーも利用できます。

ファイルシステムの場所

できる限り、ドキュメントのIP範囲やexample.comの代わりに、your_server_ipやyour_domainを使用してください。

スクリプトやデータをダウンロードする際は、ユーザーが書き込み可能なディレクトリにあるか、パスが明示的に指定されていることを確認してください。参照や再利用のために利用可能なファイルは、ユーザーのホームディレクトリを使用してください。ただし、特定の標準的な場所（例：/optや/etcなど）に所属する場合はそちらを利用してください。使い捨てのファイルには/tmpを使用してください。

特定のディレクトリに依存するチュートリアルでは、読者がコマンドを実行する前に、そのディレクトリへ誘導するためのcdコマンドを必ず提供してください。

ウェブサーバー

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

ApacheやNginxのチュートリアルでは、デフォルトの設定ファイルを編集する代わりに、専用のバーチャルホストブロックを使用してください。この方法を使うと、よくあるミスを避けることができ、デフォルトのファイルを予定どおりのフォールバック設定として維持することができます。

セキュリティ

システム間のすべての接続を暗号化して認証してください。ユーザーに対して明示的または暗黙的に、クリアテキストで資格情報や非公開データを送信することを促さないでください。

具体的には、パスワードや鍵の素材は安全ではない接続経由で送信してはいけません。データベース接続、ログ記録、クラスター管理、その他のサービスは望ましい場合には常に暗号化されるべきです。

ウェブベースのコントロールパネルはHTTPS接続で提供する必要があり、対応している場合はTLS/SSLを使用するべきです。すべてのウェブサーバーはHTTPS対応することが望まれます（少なくとも対応可能であるべきです）。SSL認証を提供するために、certbotの前提条件を使用してください。公開向けのサービスであるプレーンなHTTPは許容されますが、一般的なケースでは特に動的コンテンツにおいては強く推奨されません。プレーンなHTTP接続を提供する記事には、プレーンなHTTPを非推奨とし、HTTPSを推奨するための注記や警告ラベルを追加してください。

日本語でのパラフレーズ例：「デフォルトのSSHポートの変更など、利得の低いセキュリティ手法や見せかけを避けてください。ファイアウォールを設定してください。私たちのディストリビューションごとのおすすめは、Ubuntuの場合はufw、Debianの場合はiptables、CentOSの場合はfirewalldです。ただし、iptablesはプラットフォームによって最も一貫性があり、多くのツールがそれにフックしています。」

SSH (Secure Shell) 彼は、セキュアシェル (SSH)

デフォルトのSSHポートを標準として維持してください。ポートの変更は、それが主要な懸念事項である特定の状況に限って行われるべきです。

パスワード認証を無効化し、ルートユーザーにはキー認証のみを使用するか、代わりにルートログインを完全に無効化してください。強力なSSHキーを使用してください：少なくとも2048ビットのRSAキーが推奨ですが、4096ビットが望ましいです。エクリプトアルゴリズムは、技術的な理由で推奨されなくなっています。Ed25519と楕円曲線アルゴリズムも十分にサポートされていませんので、広く利用されていないです。

パスフレーズを対話型のキーに使用し、非対話型のプロセスには使用しないでください。SSHキーをルートアカウントからユーザーのホームディレクトリに設定、コピー、所有権を変更してください。可能であれば、fail2banをインストールしてください。

普段の作業フローにおいて、CoreOSのようなプラットフォームではSSHエージェントのフォワーディングが必要ですが、セキュリティ上の懸念があります。要するに、ホストの権限を持つ人は誰でも、フォワーディングソケットを使用してローカルのsshエージェントに接続することができます。

SSL/TLSを日本語で言い換えると：セキュアソケット層/トランスポート層セキュリティ

Let’s Encryptの利用を強くお勧めし、TLSを推奨しています。強力なSSLセキュリティを使用してください。https://cipherli.st/を参照してください（モダンなものと旧来の推奨事項の両方を含みます）。

ドメイン名を持たないホストには、十分な強度の自己署名証明書をおすすめします。次に、https://cipherli.st/を参照して、このNginxガイドのような自己署名証明書の作成方法を確認してください。暗号化を有効にする際には、ApacheやNginxでの自己署名SSL証明書を設定するように強力なDiffie-Hellman鍵を設定してください。

VPN (Virtual Private Network)を日本語で言い換えると、仮想プライベートネットワークです。

私たちは、サーバー間の一般的な暗号化通信の解決策としてVPNをおすすめします。複数のサービスをサーバー間で保護する必要がある場合、各サービスを個別に暗号化する代わりに、すべての内部通信をVPNに接続できます。特に、対象のサービスがネイティブの暗号化をサポートしていない場合に、このアプローチは非常に有用です。

サーバー間通信については、一般的にOpenVPNよりもTincをおすすめしています。詳細や実装については、AnsibleとTincに関するこの記事をお読みください。

結論 (ketsuron)

これは本来、主観的な意見が含まれる文書であり、頻繁に更新されます。テクノロジーは急速に変化するため、Silicon Cloudではできる限り追従していますが、もし間違いやフィードバックがあれば、コメントを監視しています。