序章
Hugoは静的サイトジェネレーターであり、単純なマークアップ言語で記述してWebコンテンツを簡単に作成および公開できます。 Hugoは、提供された要件に従ってコンテンツを解析し、テーマを適用して、任意のWebサーバーまたはホストで簡単にホストできる一貫性のあるWebページを生成できます。
以前のガイドでは、HugoをUbuntu 14.04システムにインストールし、それを使用してコンテンツを作成する方法について説明しました。 このガイドでは、git
を使用してシステムをセットアップする方法を示します。このシステムを使用して、新しいコンテンツを本番Webサーバーに自動的に展開できます。
前提条件
このガイドでは、Hugoインストールガイドで概説されているように、Ubuntu14.04マシンが開発マシンとして稼働していることを前提としています。
秒Ubuntu14.04サーバーをセットアップして、実際の本番Webサイトにサービスを提供します。 このサーバーで、sudo
権限を持つroot以外のユーザーを作成したことを確認してください。 初期サーバーセットアップガイドに従って、このアカウントを作成できます。
開発サーバーの準備
開発サーバー(前のHugoガイドでセットアップしたサーバー)から始めます。 前回使用したのと同じ非rootアカウントを使用してそのサーバーにログインします。
ワンステップ展開のセットアップを行うには、このサーバーでいくつかのことを行う必要があります。 必要がある:
- 本番サーバーへの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
キーペアを取得したら、これを入力して公開キーを本番サーバーに転送できます。 コマンドで、このガイドの前提条件フェーズで実稼働サーバーで構成した非rootアカウント名に置き換えます。
- ssh-copy-id username@production_domain_or_IP
これら2台のコンピューター間でSSHを初めて使用する場合は、「yes」と入力して接続を確認するように求められます。 その後、運用サーバーのユーザーパスワードの入力を求められます。 公開鍵は本番サーバーに転送されるため、次回はパスワードなしでログインできます。
ssh
コマンドを使用して運用サーバーのホスト名を要求することにより、この機能をテストします。
- ssh username@production_domain_or_IP cat /etc/hostname
今回はパスワードの入力を求められることはありません。 本番サーバーのホスト名を受け取る必要があります。
Outputprodserver
初期Gitリポジトリを本番サーバーに転送する
次に、Hugoリポジトリの初期クローンを本番サーバーに転送する必要があります。 後で本番サーバーにpost-receive
フックを設定するために、これが必要になります。 これを実現するには、git
リポジトリの「ベア」クローンを作成し、それを他のサーバーにコピーする必要があります。
ベアリポジトリは、作業ディレクトリのない特別なgit
リポジトリです。 従来のgit
リポジトリでは、プロジェクトファイルはメインディレクトリに保持され、git
バージョン管理データは.git
と呼ばれる隠しディレクトリに保持されます。 ベアリポジトリにはプロジェクトファイルの作業ディレクトリがないため、通常は非表示の.git
フォルダーに保持されるファイルとディレクトリは、代わりにメインフォルダーにあります。 ベアリポジトリは、コンテンツをプッシュするプロセスを簡素化するため、通常、リモートサーバーに使用されます。
/tmp
ディレクトリのメインHugoリポジトリからベアリポジトリを作成します。 ベアリポジトリは通常、末尾の.git
サフィックスで識別されます。 このコピーを作成するには、git clone
コマンドを--bare
オプションとともに使用します。
- git clone --bare ~/my-website /tmp/my-website.git
scp
を使用して、このベアリポジトリを本番サーバーに転送できます。 リポジトリがリモートシステム上のユーザーのホームディレクトリに配置されるように、コマンドの最後に必ず末尾の「:」を含めてください。
- scp -r /tmp/my-website.git username@production_domain_or_IP:
本番サーバー用のGitリモートを追加する
実稼働サーバーにベアgit
リポジトリがあるので、追跡されたリモートリポジトリとして実稼働サーバーを追加できます。 これにより、新しいコンテンツを本番サーバーに簡単にプッシュできるようになります。
Hugoディレクトリに戻ります。
- cd ~/my-website
リモートの名前を決めるだけです。 このガイドでは、prod
を使用します。 次に、リモートシステム上のベアリポジトリの接続情報と場所を指定できます。
- git remote add prod username@production_domain_or_IP:my-website.git
本番サーバーにgit
をインストールするまで、このリモートリンクをテストすることはできません。
本番サーバーのセットアップ
開発マシンが完全に構成されたので、本番システムのセットアップに進むことができます。
本番システムでは、次の手順を完了する必要があります。
git
、nginx
、およびpygments
をインストールします- HugoとHugoテーマをインストールします
- ホームディレクトリ内の場所からファイルを提供するように
nginx
を構成します post-receive
スクリプトを作成して、リポジトリにプッシュされた新しいコンテンツをデプロイします
本番サーバーにGit、Pygments、Nginxをインストールします
最初に行うべきことは、git
、pygments
、およびnginx
をサーバーにインストールすることです。 プロジェクトリポジトリはすでにサーバー上にありますが、プッシュを受信して展開スクリプトを実行するには、git
ソフトウェアが必要です。 コードブロックにサーバー側の構文の強調表示を適用するには、pygments
が必要です。 nginx
を、訪問者がコンテンツを利用できるようにするWebサーバーとして使用します。
ローカルパッケージインデックスを更新し、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 ~/my-website
- git ls-remote prod
git
が開発マシンと本番マシンのリポジトリ間の接続を確立できる場合、次のような参照のリストが表示されます。
Output103902f5d448cf57425bd6830e544128d9522c51 HEAD
103902f5d448cf57425bd6830e544128d9522c51 refs/heads/master
本番サーバーにHugoをインストールします
本番サーバーに戻り、Hugoをインストールする必要があります。 開発サーバーでコンテンツを構築する代わりに、git push
ごとに本番サーバーで静的アセットを構築します。 これを行うには、Hugoをインストールする必要があります。
開発マシンで使用したのと同じ方法を使用してHugoをインストールできます。 本番サーバーのアーキテクチャを確認することから始めます。
- uname -i
次に、Hugoリリースページにアクセスします。 最新のHugoバージョンについては、「ダウンロード」セクションまで下にスクロールしてください。 アーキテクチャに対応するリンクを右クリックします。
uname -i
コマンドでx86_64
が生成された場合は、右クリックしてamd64.deb
で終わるリンクをコピーします。uname -i
コマンドでi686
が生成された場合は、右クリックしてi386.deb
で終わるリンクをコピーします。
本番サーバーで、ホームディレクトリに移動し、wget
を使用してコピーしたリンクをダウンロードします。
- cd ~
- wget https://github.com/spf13/hugo/releases/download/v0.14/hugo_0.14_amd64.deb
ダウンロードが完了したら、次のように入力してパッケージをインストールできます。
- 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
変更する必要がある唯一のオプションは、server_name
です。これは、運用サーバーのドメイン名またはIPアドレスを指し、root
ディレクティブは、public_html
を指します。作成したディレクトリ:
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /home/username/public_html;
index index.html index.htm;
# Make site accessible from http://localhost/
server_name server_domain_or_IP;
. . .
root
ディレクティブの「username」を、運用サーバー上の実際のユーザー名に置き換えてください。 終了したら、ファイルを保存して閉じます。
変更を適用するには、Nginxサーバーを再起動します。
- sudo service nginx restart
これで、Webサーバーは、public_html
ディレクトリに配置したファイルを提供する準備が整いました。
Hugoサイトをデプロイするための受信後フックを作成する
これで、post-receive
デプロイメントフックスクリプトを作成する準備が整いました。 このスクリプトは、新しいコンテンツをプロダクションコードにプッシュするたびに呼び出されます。
このスクリプトを作成するには、本番サーバーのベアリポジトリのhooks
というディレクトリに移動します。 今すぐそのディレクトリに移動します。
- cd ~/my-website.git/hooks
このディレクトリにはかなりの数のサンプルスクリプトがありますが、このガイドにはpost-receive
スクリプトが必要です。 hooks
ディレクトリにこの名前のファイルを作成して開きます。
- nano post-receive
ファイルの先頭で、これがbashスクリプトであることを示した後、いくつかの変数を定義することから始めます。 GIT_REPO
をベアリポジトリに設定します。 これを変数WORKING_DIRECTORY
で指定された一時リポジトリに複製して、Hugoがその中のコンテンツにアクセスして実際のサイトを構築できるようにします。 git
リポジトリのthemesディレクトリは、実際には親ディレクトリ内の場所を指す単なるシンボリックリンクであるため、ダウンロードしたHugoテーマと同じ場所に作業ディレクトリのクローンが作成されていることを確認する必要があります。 。
パブリックWebフォルダーはPUBLIC_WWW
変数で指定され、バックアップWebフォルダーはBACKUP_WWW
変数でアクセスできるようになります。 最後に、MY_DOMAIN
をサーバーのドメイン名またはパブリックIPアドレスに設定します。
そのことを念頭に置いて、ファイルの先頭は次のようになります。
#!/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=server_domain_or_IP
変数を設定したら、スクリプトのロジックから始めることができます。 まず、bashのset -e
コマンドを使用して、エラーが発生した場合にスクリプトをすぐに終了するように指定します。 これを使用して、問題が発生した場合にすぐにクリーンアップします。
その後、環境がデプロイメント用にセットアップされていることを確認しましょう。 展開中に新しいコピーのクローンを作成するため、既存の作業ディレクトリをすべて削除します。 また、問題が発生した場合に復元できるように、Webディレクトリをバックアップしたいと思います。 ここではrsync
を使用します。これは、cp
よりも一貫して、空のディレクトリとコンテンツを含むディレクトリを処理するためです。 caommandが正しく解析されるように、$PUBLIC_WWW
の後に末尾の/
を含めるようにしてください。
最後に行うセットアップ手順の1つは、trap
コマンドを設定して、「終了」信号を受信した場合に応答するようにすることです。 set -e
コマンドが含まれているため、展開内のコマンドが失敗するたびに終了シグナルが発生します。 この場合、トラップによって指定されたコマンドは、バックアップコピーをWebディレクトリに復元し、作業中のgit
ディレクトリのインスタンスをすべて削除します。
#!/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=server_domain_or_IP
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
コマンドをリセットして、スクリプトが終了しようとしたときにバックアップコピーが新しいコンテンツをすぐに上書きしないようにします。
#!/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=server_domain_or_IP
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 ~/my-website.git/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
Webブラウザで本番サーバーのドメイン名またはIPアドレスにアクセスすると、サイトの現在のバージョンが表示されます。
http://production_domain_or_IP
これで、Hugo開発に使用しているマシンに戻ることができます。 そのマシンで、新しい投稿を作成しましょう。
- hugo new 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://production_domain_or_IP
導入システムは正常に動作しているようです。
結論
このガイドでは、訪問者にWebコンテンツを提供するための専用の本番サーバーを別に設定します。 このサーバーでは、Hugoがコンテンツを正しく構築して提供できるように、複数のコンポーネントをインストールして構成しました。 次に、開発マシンからサーバーに新しいコンテンツをプッシュするたびにトリガーされる展開スクリプトを作成しました。
デプロイメントシステムに含まれる実際のメカニズムはかなり基本的なものです。 ただし、これらは、Webサーバー上でローカルコンテンツをすばやく簡単に取得するための保守が容易なシステムの基盤を形成します。 展開プロセスは自動化されているため、単純なgit push
以外の変更を行うためにサーバーと対話する必要はありません。