Ghostは、軽量で高速なオープンソースのCMSプラットフォームであり、メンバーシップWebサイトの構築に重点を置いています。
Ghost自体からいつでもマネージドホスティングを選択できます。ただし、これはオープンソースソフトウェアであるため、自分のサーバーで自由にホストして自分で管理することもできます。
LinodeやDigitalOceanなどのクラウドサービスのおかげで、Ghostがインストールされた新しいLinuxサーバーをデプロイするのは数回クリックするだけです。
Linode |開発者向けの独立したオープンクラウド私たちの使命は、クラウドコンピューティングをシンプルで手頃な価格で、すべての人が利用できるようにすることでイノベーションを加速することです。
Linode 
Ghostをクラウドサーバーにデプロイするのは比較的簡単な作業ですが、Ghostの管理は必ずしも簡単ではない場合があります。
LinuxハンドブックをホストするためにGhostインスタンスを管理して数か月になります。そして、この経験は、Ghostの公式ドキュメントにはおそらくないいくつかのことを私たちに教えてくれました。
この記事では、Ghostを利用したブログを本番サーバーにデプロイする前に考慮すべきいくつかの重要な要素について説明します。
この記事は、開発者コミュニティによって構築および管理されているGhostのDockerイメージに関するものであることに注意してください。DevOpsコミュニティでは、私たちが常に努力しているのは、NoOpsと呼ばれる状態に可能な限り近づくことです。しかし、実際的な意味では、それは常にパラドックスのままです。
ここでは、NoOpsと同じ目標を達成しようとしていますが、必要に応じて人間の介入を伴うハイブリッドな見通しを持っています。
それで、さらに遅れることなく、安定した最小限のメンテナンスのGhostインスタンスを確保するための基本事項を紹介します。
1。メール設定を正しく設定してください
Ghostインスタンスを介して、メンバーやサブスクライバーへのさまざまな種類のメールをフォローします。
- トランザクションメール：メンバーのログイン、サインアップの確認など
- 一括メール：Ghostを介してメールニュースレターを送信するため
Ghostを介してニュースレターを配信したくない場合は、任意のSMTPサービスを使用できます。それ以外の場合は、Mailgunを使用する必要があります。
理論的には、GhostインスタンスはNodemailerのおかげでダイレクトメールサービスを使用できるはずです。
ただし、これにより、一部のサインアップが失敗し、「有効な電子メールアドレスを入力してください」というエラーメッセージが表示される場合があります。
これが、MailgunまたはAmazonSESでSMTP設定をセットアップする必要がある理由です。 SendGridやMailchimpなどの他のメールリレーサービスを試すこともできます。
Mailgunを介して構成された一般的なSMTP設定は、次のようになります（バインドマウントされたファイルconfig.production.jsonを介して設定） ）：
"mail": {
"transport": "SMTP",
"options": {
"service": "Mailgun",
"host": "smtp.eu.mailgun.org",
"port": 465,
"secureConnection": true,
"auth": {
"user": "replace-me-with-a-mailgun-configured-email-address",
"pass": "replace-me-with-the-relevant-mailgun-apikey"
}
}
},SMTPポート番号に注意してください 。ポート番号が原因でメールが失敗することがあります。私たちの場合、一部の電子メールはポート587で失敗し、ポート465で動作し始めました。
ドメインの確認と、電子メールの送信にも必要なDNSレコードの更新に関する詳細については、Mailgunのこのドキュメントをここで確認してください。
一般に、ドメイン名パネルのDNSレコード設定内でMailgunから取得したMX、CNAME、およびTXTレコードを更新する必要があります。 Linodeでは、次のようになります：
メンバーにニュースレターをまとめて送信する場合、Ghost構成内にニュースレターを実装するために利用できる唯一のサービスはMailgunです。バルクメールサービスは、従来のSMTPサービスとはまったく異なります。
メンバーのGhostで一括メールを正しく構成するには、最初にメンバーシップが有効になっていることを確認する必要があります。それは明らかな要件です。
次に、[メール]セクションまで下にスクロールして、[メールニュースレターの設定]を展開します。
Mailgunで構成されたドメイン名とAPIキーを入力します。 Mailgunリージョンは、「EU」または「US」のいずれかになります。適切なものを選択してください。
上記のSMTP設定の例を思い出すと、リージョン名「EU」はホストの名前であるsmtp.eu.mailgun.orgで認識できます。 。
Mailgunで構成されたドメイン名とAPIキーの詳細については、こちらをお読みください。ドメイン名の選択については、こちらを確認してください。
2。データベースにはSQLiteではなくMySQLまたはMariaDBを選択してください
Ghostブログを本番環境で使用する予定の場合は、Ghostコンテナ内でデフォルトで提供されているSQLiteデータベースを使用しないことをお勧めします。
推奨されるデータベースをMySQLまたはMariaDBとして使用する理由は、かなりの数のメンバーがいて、Ghost自体からメールマガジンを送信したい場合に非常に重要です。
私たちはそれを難しい方法で学びました。当初、ニュースレターの作成と送信にはMailerLiteを使用していました。次に、Ghostの組み込みのニュースレター機能を利用することにしました。
この時点で、約1,100人のメンバーがいます。そして、SQLiteが一度にこれらの多くのクエリを処理できなかったため、これは問題を引き起こしました。新しく作成された投稿は送信できませんでした。ログにこのエラーが表示されました：
Processed job threw an unhandled error
"The email service was unable to send an email batch."
Error ID:
24bf8000-4f50-11eb-adf5-73dcc562a630
Error Code:
SQLITE_ERROR
それではありませんでした。それは1100人のメンバーを輸出することさえ拒否しました。ダウンロードが開始されません。バックアップ全体をJSON形式でダウンロードし、そこからメンバー情報を抽出しました。
これを修正するには、SQLiteからMySQLまたはMariaDBに移行します。これにより、不要なオーバーヘッドが発生し、移行中に不要なダウンタイムが発生する可能性があります。したがって、予防策として、最初にMySQLまたはMariaDBを使用してGhostをデプロイすることをお勧めします。
以下は、Ghost onDockerComposeの一般的なMariaDBデータベースサービス構成の例です。
db:
image: mariadb:10.5.3
volumes:
- ghostdb:/var/lib/mysql
restart: on-failure
environment:
MYSQL_RANDOM_ROOT_PASSWORD: 1
MYSQL_USER: rename-me
MYSQL_PASSWORD: replace-me
MYSQL_DATABASE: rename-me3。ログローテーションを有効にする
ログローテーションは、必要な期間が経過した後にログファイルを自動的にリセットするプロセスです。これは、巨大なログファイルが積み重なってサーバーのディスクスペースに不必要に侵入することを回避するのに役立ちます。一般的に、Ghost構成に次のスニペットを含めないと、ログファイルが15〜20GBの巨大なサイズに蓄積されます！：
"logging": {
"path": "content/logs/",
"level": "info",
"rotation": {
"enabled": true,
"count": 15,
"period": "1d"
},
Ghostへのログインの詳細な概要については、関連するドキュメントページにアクセスしてください。
3。リバースプロキシを使用する
Ghostをデプロイする前に、最初からリバースプロキシを使用することは常に追加の利点です。短期的にも長期的にもWebアプリケーションの管理がはるかに簡単になります。
複数のDockerアプリでNginxリバースプロキシを使用する方法NginxリバースプロキシとDockerコンテナーを使用して、同じサーバーに複数のWebサービスをデプロイする方法を学びます。
Linux HandbookDebdut Chakraborty 
4。ダウンタイムなしでGhostを更新する
リバースプロキシを使用する場合、ダウンタイムなしでGhostインスタンスを更新するのは簡単な作業です。
これが私がお勧めするものです。 Ghostインスタンスの新しいDockerイメージ（最新バージョンのGhostを使用）の通知を受け取るようにDockerNotifyを設定します。
次に、このチュートリアルに従ってDockerコンテナを更新します。
ダウンタイムがゼロのDockerコンテナの更新貴重なアップタイムを犠牲にすることなく、日々のDevOpsアクティビティで非常に役立つステップバイステップの方法論。LinuxハンドブックAvimanyuBandyopadhyay 
幸い、更新を実行するときにダウンタイムはまったくありません。すでに管理パネルにログインしている場合（たとえば、記事の作成中）、異常に気付くことはありません。
ただし、ログインしていない場合は、更新後に古いコンテナを削除するまで、新しいログインを試行すると、管理パネルは自身をロードしようとし続けます。
ただし、本番環境では、アップグレードを実行している間も、Ghostブログ自体はフロントエンドで引き続き利用できます。
6。常に再起動ポリシーを設定します
Ghost Dockerコンテナーを使用しているため、再起動ポリシーは常に非常に重要であり、構成内で指定する必要があります。これにより、メンテナンスイベントが原因で物理サーバーが再起動されるたびに、Ghostコンテナが常に再起動します。
一般的なDocker構成でライブ復元が有効になっている場合は、on-failureを使用することをお勧めします ポリシーを再起動します。再起動ポリシーをよりよく理解するには、そのようなポリシーの完全なリファレンスについて公式ドキュメントを確認してください。
通常、DockerComposeファイルのサービス内で次のような再起動ポリシーを設定します。
restart: on-failure
LinuxハンドブックAbhishekPrakash 
7。外部Dockerボリュームを使用する
Ghostをデプロイする前に手動で作成されたボリュームを使用すると、将来必要になった場合にコンテンツを（同じサーバー内または別のサーバー内で）簡単に移行できます。 Ghostコンテナで使用するボリュームを作成および指定するのはあなた自身であるため、データをより細かく制御できます。それ以外の場合は、ローカルで作成するためにDockerComposeに任せる必要があります。
Ghostコンテナ用の外部Dockerボリュームを作成するには、次のコマンドを使用します。
docker volume create ghost
ghost は外部DockerGhostボリュームの名前です。
数千人のユーザーのパフォーマンスを向上させるためにMySQLまたはMariaDBデータベースを選択することについてはすでに説明したので、そのボリュームも同じ方法で作成する必要があります。
docker volume create ghostdb
ghostdbの場所 は外部DockerGhostデータベースボリュームの名前です。
上記で作成したこれらの特定のボリュームを使用するようにDockerComposeに指示するには、DockerComposeファイルのボリュームセクションが次のようになっている必要があります。
volumes:
ghost:
external: true
ghostdb:
external: true
これらのDockerボリュームが本質的に外部であると指定した方法に注意してください。
ボーナスのヒント：定期的なバックアップをスケジュールする
Linode、Digital Ocean、またはその他の同様のクラウドサーバープロバイダーを使用している場合は、Ghostをデプロイするサーバーを作成するときに常にバックアップを有効にすることを強くお勧めします。
たとえば、Linode上に1 GBのRAM（nanodeと呼ばれる）を備えたサーバーを作成すると、バックアップを有効にするように求めるチェックボックスが表示されます。実稼働サーバーをデプロイするときは常に、最初の起動のためにサーバーを実際に開始する前に、サーバーを有効にすることをお勧めします。
また、crontabに基づいてサーバーにスクリプトをデプロイし、Ghostの外部Dockerボリュームのスナップショットを手動で取得することもできます。
技術的には、前のポインタ7で説明したボリュームデータ、特にghost およびghostdb 、ローカルに/var/lib/docker/volumes/ghost/_dataに常駐します および/var/lib/docker/volumes/ghostdb/_data それぞれ。それらを効果的にアーカイブするために、tarを使用してこれら2つのディレクトリを定期的にバックアップできます。
これらのtarがいつになるかがわかるので、 アーカイブはアーカイブ後にすぐに利用できるようになります。また、ローカルシステムに別のスクリプトをデプロイして（自宅/オフィスで毎日特定の時間にライブで実行されていると想定）、GhostサーバーにSSHで接続してそれらのアーカイブをフェッチすることもできます。このようにすると、インターネットへのアクセスに関係なく、Ghostブログのローカルで更新されたコピーを常に利用できるようになります。
または、データベースコマンドmysqldumpを使用してMySQLデータベースをバックアップするための論理バックアップアプローチを使用することもできます。 MariaDBでは、コマンドはmariadb-dumpと呼ばれます これは、同じmysqldumpへのシンボリックリンクにすぎません。 コマンド。
物理バックアップと論理バックアップの優れた比較は、ここにあります。
これは、Ghostインスタンスをデプロイした後に発生する可能性のあるメンテナンスの問題を最小限に抑え、防止するためのさまざまなアプローチをまとめたものです。 Ghostで独自のブログを立ち上げたり使用したりするときに役立つことを願っています。
Ghostを使用して旅を続け、展開時に異なる構成で回避できた可能性のある他の問題が発生した場合は、この記事を更新します。
上記のポインタについて何か提案がある場合、または新しいものがある場合は、以下の会話セクションでそれらを共有してください。よろしくお願いします。