Pythonによるテスト駆動開発, 3rd Edition

第11章 サーバのデプロイ準備

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

この章では、デプロイの準備について説明する。 実際のサーバーを起動し、 インターネット上で実際のドメイン名でアクセス可能にし、 SSHやAnsibleでリモート操作するために必要な 認証と資格情報をセットする。

サイトホスティング用サーバの手動プロビジョニング

「デプロイ」を次の2つのタスクに分けられる：

1. コードをホストできる新しいサーバを準備する。 これにはオペレーティングシステムの選択、 ログイン用の基本資格情報の取得、 DNSの設定が含まれる。

2. 既存サーバへのアプリケーションデプロイ これにはDockerイメージのサーバへの展開、 コンテナの起動、データベースや外界との通信設定が含まれる

コードとしてのインフラツールを使えば両方を自動化できるが、 プロビジョニング部分はベンダ固有の要素が強い。 だから本書の目的上、手動プロビジョニングで十分だ。

注記

もう一度強調しておくが、デプロイの手法は状況によって大きく異なる。 結果として、普遍的なベストプラクティスはほとんど存在しない。 だから、ここで私がやっている具体的な手順を覚えようとするより、 その背景にある考え方を理解すべきだ。 そうすれば、将来遭遇する具体的な状況でも、同じような思考を応用できる。

サイトのホスティング先を選ぶ

現在では様々な解決策が存在するが、 大きく二つのタイプに分類される：

1. 自分でサーバを運用する（おそらく仮想サーバ）— 別名 VPS（仮想専用サーバ）

2. プラットフォーム・アズ・ア・サービス（PaaS）の利用 Herokuや私の元勤務先であるPythonAnywhereのようなサービス

PaaSでは専用サーバは提供されない。 代わりに抽象化レベルの高い「サービス」をレンタルする形だ。 特に小規模サイトの場合、 PaaSは自社サーバ運用に比べて多くの利点があり、 検討することを強く推奨する。 しかし本書では、いくつかの理由からPaaSは使わない。 主な理由は、特定の商用プロバイダーを推奨することを避けたいからだ。 次に、各PaaSの提供内容は大きく異なり、 デプロイ手順もそれぞれ大きく異なる。 一つを学んでも、他について必ずしも理解できるわけではない。 本書を読む頃には、いずれかのプロバイダーがプロセスやビジネスモデルを根本的に変えている可能性もある。

代わりに、昔ながらのサーバ管理の基本を少しだけ学ぶ。 SSHや手動デバッグも含まれる。 これらは消えることはまずない。 少し知っておけば、現場のベテランたちから 多少の尊敬は得られるだろう。

自分たちのサーバを立ち上げる

サーバの立ち上げ方については指示しない。 Amazon AWS、Rackspace、DigitalOcean、データセンター内の自社サーバ、 階段下の物置に置いたRaspberry Pi—— どれを選んでも構わない。ただし以下の条件を満たす限りだ：

• サーバは Ubuntu 22.04（通称「Jammy/LTS」）で動作している。

• root権限でアクセスできる。

• サーバーはパブリックインターネット上に存在する（つまりパブリックIPアドレスを持つ）。

• SSHで接続できる（非rootユーザアカウントの使用を推奨する。sudo アクセス権と公開鍵/秘密鍵認証を設定すること）。

ディストリビューションとしてはUbuntuを推奨する。人気があるし、俺も慣れているからだ。 ...