Ubuntu 14.04でGitフックを使用して本番環境にHugoサイトを展開する方法

前書き

Hugoは静的なサイトジェネレーターであり、単純なマークアップ言語で記述することで、Webコンテンツを簡単に作成および公開できます。 Hugoは、提供された要件に従ってコンテンツを解析し、テーマを適用して、任意のWebサーバーまたはホストで簡単にホストできる一貫したWebページを生成できます。

https://www.digitalocean.com/community/tutorials/how-to-install-and-use-hugo-the-static-site-generator-on-ubuntu-14-04 [以前のガイド]では、 Ubuntu 14.04システムにHugoをインストールし、それを使用してコンテンツを作成する方法。このガイドでは、新しいコンテンツを実稼働Webサーバーに自動的にデプロイするために使用できるシステムを `+ git +`でセットアップする方法を示します。

前提条件

このガイドでは、https：//www.digitalocean.com/community/tutorials/how-to-install-and-use-hugoで説明されているように、開発マシンとしてUbuntu 14.04マシンが稼働していることを前提としています。 -ubuntu-14-04の静的サイトジェネレーター[Hugoインストールガイド]。

実際の運用Webサイトに対応するために、* 2 * Ubuntu 14.04サーバーをセットアップします。このサーバーで、 `+ sudo +`権限を持つ非rootユーザーを作成したことを確認してください。 https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04 [初期サーバーセットアップガイド]に従って、このアカウントを作成できます。

開発サーバーの準備

開発サーバー（以前のHugoガイドで設定されたサーバー）で開始します。前回使用したのと同じ非ルートアカウントを使用して、そのサーバーにログインします。

このサーバーでいくつかのことを実行して、ワンステップのデプロイメントをセットアップする必要があります。必要がある：

運用サーバーへのSSHキーアクセスを構成する
最初の `+ git +`リポジトリを本番サーバーに転送します
本番サーバーをサイトリポジトリにリモートの「+ git +」として追加します

始めましょう。

実稼働サーバーへのSSHキーアクセスの構成

最初に行うことは、2つのサーバー間のSSHキーアクセスを構成することです。これにより、毎回パスワードを入力する必要なく展開できます。各展開でパスワードの入力を求められる場合は、この手順をスキップできます。コンテンツをプッシュする前に再考する小さなチャンスとして、展開プロセス中にパスワードプロンプトを保持したい人もいます。

最初に、開発サーバーのアカウントでSSHキーペアが既に構成されているかどうかを確認します。

ls ~/.ssh/id_rsa

次のような行が返された場合、SSHキーペアはまだ構成されていません。

Outputls: cannot access /home/demouser/.ssh/id_rsa: No such file or directory

次のように入力して、不足しているキーペアを作成できます。

ssh-keygen

すべてのプロンプトでEnterキーを押して、パスワードなしのキーを作成します。

一方、 `+ ls +`コマンドで次のような行が表示された場合、アカウントに既にキーがあります：

Output/home/demouser/.ssh/id_rsa

キーペアを取得したら、これを入力して公開キーを運用サーバーに転送できます。コマンドで、このガイドの前提条件フェーズで運用サーバーで構成した非ルートアカウント名に置き換えます。

ssh-copy-id @

これら2台のコンピューター間でSSHを使用するのが初めての場合は、「yes」と入力して接続を確認するよう求められます。その後、本番サーバーのユーザーパスワードの入力を求められます。公開鍵は本番サーバーに転送され、次回パスワードなしでログインできるようになります。

`+ ssh +`コマンドで本番サーバーのホスト名を尋ねることにより、この機能をテストします：

ssh @ cat /etc/hostname

今回はパスワードの入力を求められないはずです。実稼働サーバーのホスト名を受け取る必要があります。

Output

初期Gitリポジトリを運用サーバーに転送する

次に、Hugoリポジトリの初期クローンを運用サーバーに転送する必要があります。後で本番サーバーで `+ post-receive `フックを設定するためにこれが必要になります。これを実現するには、 ` git +`リポジトリの「ベア」クローンを作成し、それを他のサーバーにコピーする必要があります。

ベアリポジトリは、作業ディレクトリのない特別な `+ git `リポジトリです。従来の ` git `リポジトリでは、プロジェクトファイルはメインディレクトリに保持され、 ` git `バージョン管理データは ` .git `と呼ばれる隠しディレクトリに保持されます。裸のリポジトリにはプロジェクトファイルの作業ディレクトリがないため、通常、非表示の ` .git +`フォルダーに保持されるファイルとディレクトリは、代わりにメインフォルダーにあります。ベアリポジトリは、コンテンツをプッシュするプロセスを簡素化するため、通常リモートサーバーに使用されます。

`+ / tmp `ディレクトリにあるメインのHugoリポジトリからベアリポジトリを作成します。ベアリポジトリは通常、末尾の「 .git 」サフィックスによって識別されます。このコピーを作成するには、 `-bare `オプションを指定した ` git clone +`コマンドを使用します。

git clone --bare ~/ /tmp/.git

`+ scp +`を使用して、このベアリポジトリを運用サーバーに転送できます。リポジトリがリモートシステム上のユーザーのホームディレクトリに配置されるように、コマンドの最後に必ず末尾の「：」を含めてください。

scp -r /tmp/ @:

実稼働サーバー用のGitリモートを追加する

本番サーバーに裸の `+ git +`リポジトリがあるので、本番サーバーを追跡リモートリポジトリとして追加できます。これにより、新しいコンテンツを運用サーバーに簡単にプッシュできるようになります。

Hugoディレクトリに戻ります。

cd ~/

必要なのは、リモートの名前を決定することだけです。このガイドでは、「+ prod +」を使用します。次に、リモートシステム上のベアリポジトリの接続情報と場所を指定できます。

git remote add prod @:

実稼働サーバーに `+ git +`をインストールするまで、このリモートリンクをテストすることはできません。

実動サーバーのセットアップ

開発マシンが完全に構成されたので、本番システムのセットアップに進むことができます。

本番システムでは、次の手順を完了する必要があります。

+ git +、 + nginx、および` + pigments`をインストールします
HugoおよびHugoテーマをインストールする
ホームディレクトリの場所からファイルを提供するように `+ nginx +`を設定します
リポジトリにプッシュされた新しいコンテンツをデプロイするための `+ post-receive +`スクリプトを作成します

実稼働サーバーにGit、Pygments、およびNginxをインストールします

最初にすべきことは、サーバーに + git +、 + pygments +、および `+ nginx `をインストールすることです。プロジェクトリポジトリは既にサーバー上にありますが、プッシュを受け取り、展開スクリプトを実行するには、 ` git `ソフトウェアが必要です。コードブロックにサーバー側の構文強調表示を適用するには、 ` pygments `が必要です。コンテンツを訪問者が利用できるようにするWebサーバーとして「 nginx」を使用します。

ローカルパッケージインデックスを更新し、Ubuntuのデフォルトリポジトリから「+ git 」と「 nginx」をインストールします。 `+ pygments `を取得するには、Pythonパッケージマネージャーである ` pip +`をインストールする必要があります。

sudo apt-get update
sudo apt-get install git nginx python-pip

次に、 + pip`を使用して + pygments`をインストールできます。

sudo pip install Pygments

ダウンロードが完了したら、開発マシンでリモートリポジトリを正しくセットアップしたことをテストできます。 *開発マシン*で、Hugoプロジェクトディレクトリに移動し、 `+ git ls-remote +`コマンドを使用します。

cd ~/
git ls-remote prod

`+ git +`が開発マシンと本番マシンのリポジトリ間の接続を確立できる場合、次のように参照のリストが表示されます。

Output103902f5d448cf57425bd6830e544128d9522c51    HEAD
103902f5d448cf57425bd6830e544128d9522c51    refs/heads/master

実稼働サーバーにHugoをインストールする

*本番サーバー*に戻って、Hugoをインストールする必要があります。開発サーバーでコンテンツを構築する代わりに、 `+ git push +`のたびに運用サーバーで静的アセットを構築します。これを行うには、Hugoをインストールする必要があります。

開発マシンで使用したのと同じ方法でHugoをインストールできます。運用サーバーのアーキテクチャを確認することから始めます。

uname -i

次に、https：//github.com/spf13/hugo/releases [Hugoリリースページ]にアクセスします。最新のHugoバージョンの「ダウンロード」セクションまでスクロールします。アーキテクチャに対応するリンクを右クリックします。

`+ uname -i `コマンドが ` x86_64 `を生成した場合、右クリックして ` amd64.deb +`で終わるリンクをコピーします
`+ uname -i `コマンドが ` i686 `を生成した場合、右クリックして、 ` i386.deb +`で終わるリンクをコピーします

実稼働サーバーで、ホームディレクトリに移動し、 `+ wget +`を使用してコピーしたリンクをダウンロードします。

cd ~
wget https://github.com/spf13/hugo/releases/download/

ダウンロードが完了したら、次を入力してパッケージをインストールできます。

sudo dpkg -i hugo*.deb

Hugoにバージョン番号を表示するように依頼して、インストールが成功したことをテストします。

hugo version

Hugoが利用可能になったことを示すバージョン行が表示されます。

OutputHugo Static Site Generator v0.14 BuildDate: 2015-05-25T21:29:16-04:00

先に進む前に、Hugoテーマを運用サーバーに複製する必要があります。

git clone --recursive https://github.com/spf13/hugoThemes ~/themes

展開中に作成されたファイルを提供するためのNginxの構成

次に、Nginxの構成を少し変更する必要があります。

展開を簡素化するために、生成されたコンテンツを `+ var / www / html `ディレクトリに配置する代わりに、コンテンツはユーザーのホームディレクトリ内の ` public_html +`というディレクトリに配置されます。

さあ、今すぐ `+ public_html +`ディレクトリを作成しましょう：

mkdir ~/public_html

次に、デフォルトのNginxサーバーブロック構成ファイルを開いて、必要な調整を行います。

sudo nano /etc/nginx/sites-available/default

変更する必要がある唯一のオプションは、実稼働サーバーのドメイン名またはIPアドレスを指す「+ server_name 」と、作成した「 public_html 」ディレクトリを指す「 root +」ディレクティブです。

/ etc / nginx / sites-available / default

server {
       listen 80 default_server;
       listen [::]:80 default_server ipv6only=on;

       root ;
       index index.html index.htm;

       # Make site accessible from http://localhost/
       server_name ;

. . .

`+ root +`ディレクティブの“ username”を本番サーバー上の実際のユーザー名に置き換えてください。完了したら、ファイルを保存して閉じます。

変更を適用するには、Nginxサーバーを再起動します。

sudo service nginx restart

これで、Webサーバーは、 `+ public_html +`ディレクトリに配置したファイルを提供する準備が整いました。

受信後フックを作成してHugoサイトを展開する

これで、 `+ post-receive +`デプロイメントフックスクリプトを作成する準備が整いました。このスクリプトは、新しいコンテンツを製品コードにプッシュするたびに呼び出されます。

このスクリプトを作成するには、本番サーバーのベアリポジトリに移動し、 `+ hooks +`というディレクトリに移動します。今すぐそのディレクトリに移動します。

cd ~//hooks

このディレクトリにはかなりの数のサンプルスクリプトがありますが、このガイドには `+ post-receive `スクリプトが必要です。 ` hooks +`ディレクトリにこの名前のファイルを作成して開きます：

nano post-receive

ファイルの先頭で、これがbashスクリプトであることを示した後、いくつかの変数を定義することから始めます。 `+ GIT_REPO `をベアリポジトリに設定します。 Hugoが内部のコンテンツにアクセスして実際のサイトを構築できるように、これを変数 ` WORKING_DIRECTORY `で指定された一時リポジトリにクローンします。 ` git +`リポジトリのテーマディレクトリは実際には親ディレクトリの場所を指す単なるシンボリックリンクであるため、ダウンロードしたHugoテーマと同じ場所に作業ディレクトリのクローンが作成されることを確認する必要があります。

パブリックWebフォルダーは `+ PUBLIC_WWW `変数で指定され、バックアップWebフォルダーは ` BACKUP_WWW `変数を介してアクセス可能な状態に保たれます。最後に、サーバーのドメイン名またはパブリックIPアドレスに「 MY_DOMAIN +」を設定します。

それを念頭に置いて、ファイルの先頭は次のようになります。

〜/ my-website.git / hooks / post-receive

#!/bin/bash

GIT_REPO=$HOME/my-website.git
WORKING_DIRECTORY=$HOME/my-website-working
PUBLIC_WWW=$HOME/public_html
BACKUP_WWW=$HOME/backup_html
MY_DOMAIN=

変数を設定したら、スクリプトのロジックを開始できます。まず、bashの `+ set -e +`コマンドを使用して、エラーが発生した場合にスクリプトをすぐに終了するように指定します。これを使用して、すぐに問題が発生した場合にクリーンアップします。

その後、展開のために環境が設定されていることを確認しましょう。展開中に新しいコピーを複製するため、既存の作業ディレクトリを削除します。また、何か問題が発生した場合に復元できるように、Webディレクトリをバックアップする必要があります。ここでは、空のディレクトリと内容が含まれるディレクトリを一貫して「+ cp 」よりも処理するため、「 rsync 」を使用します。コマンドが正しく解析されるように、「 $ PUBLIC_WWW 」の後に末尾の「 / +」を含めるようにしてください。

最後に行うセットアップ手順の1つは、「終了」シグナルが受信された場合に応答するように「+ trap 」コマンドを設定することです。 ` set -e `コマンドが含まれているため、デプロイメント内のコマンドが失敗するたびに終了シグナルが発生します。この場合、トラップで指定されたコマンドはバックアップコピーをWebディレクトリに復元し、作業中の ` git +`ディレクトリのインスタンスを削除します。

〜/ my-website.git / hooks / post-receive

#!/bin/bash

GIT_REPO=$HOME/my-website.git
WORKING_DIRECTORY=$HOME/my-website-working
PUBLIC_WWW=$HOME/public_html
BACKUP_WWW=$HOME/backup_html
MY_DOMAIN=

set -e

rm -rf $WORKING_DIRECTORY
rsync -aqz $PUBLIC_WWW/ $BACKUP_WWW
trap "echo 'A problem occurred.  Reverting to backup.'; rsync -aqz --del $BACKUP_WWW/ $PUBLIC_WWW; rm -rf $WORKING_DIRECTORY" EXIT

これで、展開を開始できます。 Hugoがレポジトリのコンテンツにアクセスできるように、ベアレポジトリの通常のクローンを作成します。次に、パブリックWebディレクトリからすべてのコンテンツを削除して、パブリックWebディレクトリで新しいファイルのみが使用できるようにします。その後、Hugoを使用してサイトを構築します。新しいクローンをソースディレクトリとして指定し、生成されたコンテンツをパブリックWebフォルダに配置するように指示します。また、実稼働サーバーのドメイン名またはIPアドレスを含む変数を渡して、リンクを正しく構築できるようにします。

Hugoがコンテンツを作成した後、作業ディレクトリを削除します。次に、スクリプトが終了しようとしたときにバックアップコピーが新しいコンテンツをすぐに上書きしないように、 `+ trap +`コマンドをリセットします。

〜/ my-website.git / hooks / post-receive

#!/bin/bash

GIT_REPO=$HOME/my-website.git
WORKING_DIRECTORY=$HOME/my-website-working
PUBLIC_WWW=$HOME/public_html
BACKUP_WWW=$HOME/backup_html
MY_DOMAIN=

set -e

rm -rf $WORKING_DIRECTORY
rsync -aqz $PUBLIC_WWW/ $BACKUP_WWW
trap "echo 'A problem occurred.  Reverting to backup.'; rsync -aqz --del $BACKUP_WWW/ $PUBLIC_WWW; rm -rf $WORKING_DIRECTORY" EXIT

git clone $GIT_REPO $WORKING_DIRECTORY
rm -rf $PUBLIC_WWW/*
/usr/bin/hugo -s $WORKING_DIRECTORY -d $PUBLIC_WWW -b "http://${MY_DOMAIN}"
rm -rf $WORKING_DIRECTORY
trap - EXIT

この時点で、スクリプトは終了しました。完了したら、ファイルを保存して閉じます。

今やらなければならないことは、スクリプトを実行可能にして、 `+ git +`が適切なタイミングでスクリプトを呼び出せるようにすることだけです：

chmod +x post-receive

これで展開システムが完成しました。テストしてみましょう。

展開システムをテストする

システムがセットアップされたので、先に進んでテストできます。

最初に、 `+ post-receive`フックスクリプトをテストします。これにより、 `+〜/ public_html +`ディレクトリにWebコンテンツの初期コピーを取り込むことができます。また、スクリプトの主要コンポーネントが期待どおりに機能していることを確認するのにも役立ちます。

bash ~//hooks/post-receive

これにより、スクリプトが実行され、通常の `+ git +`およびHugoメッセージが画面に出力されます。

OutputCloning into '/home/justin/my-website-working'...
done.
0 draft content
0 future content
4 pages created
0 paginator pages created
0 tags created
1 categories created
in 26 ms

ウェブブラウザで本番サーバーのドメイン名またはIPアドレスにアクセスすると、サイトの現在のバージョンが表示されます：

http://

image：https：//assets.digitalocean.com/articles/hugo_deployment_1404/initial_site.png [Hugo初期サイト状態]

これで、Hugoの開発に使用しているマシンに戻ることができます。そのマシンで、新しい投稿を作成しましょう。

hugo new post/Testing-Deployment.md

新しい投稿では、システムをテストできるようにコンテンツを少し入れてください。

〜/ my-website / content / post / Testing-Deployment.md

+++
categories = ["misc"]
date = "2015-11-11T16:24:33-05:00"
title = "Testing Deployment"

+++

## A Test of the New Deployment System

I hope this works!

次に、コンテンツを `+ git +`に追加し、変更をコミットします。

git add .
git commit -m 'Deployment test'

これで、すべてが計画どおりに進んだ場合、運用サーバーにプッシュするだけで新しい変更を展開できます。

git push prod master

これで、Webブラウザーで実稼働サイトに再アクセスすると、新しいコンテンツが表示されるはずです。

http://

image：https：//assets.digitalocean.com/articles/hugo_deployment_1404/new_content.png [Hugo new content]

展開システムは正常に動作しているようです。

結論

このガイドでは、Webコンテンツを訪問者に提供するための専用のプロダクションサーバーを設定します。このサーバーに、Hugoがコンテンツを正しく構築して提供できるように、複数のコンポーネントをインストールして構成しました。次に、開発マシンからサーバーに新しいコンテンツをプッシュするたびにトリガーされる展開スクリプトを作成しました。

展開システムに含まれる実際のメカニズムは、基本的なものです。ただし、Webサーバー上のローカルコンテンツを迅速かつ簡単に取得するための、メンテナンスが容易なシステムの基盤を形成します。展開プロセスは自動化されているため、単純な `+ git push +`を超えて変更を加えるためにサーバーと対話する必要はありません。

TOC

Ubuntu 14.04でGitフックを使用して本番環境にHugoサイトを展開する方法

前書き

前提条件

開発サーバーの準備

実稼働サーバーへのSSHキーアクセスの構成

初期Gitリポジトリを運用サーバーに転送する

実稼働サーバー用のGitリモートを追加する

実動サーバーのセットアップ

実稼働サーバーにGit、Pygments、およびNginxをインストールします

実稼働サーバーにHugoをインストールする

展開中に作成されたファイルを提供するためのNginxの構成

受信後フックを作成してHugoサイトを展開する

展開システムをテストする

結論

Related