開発者ドキュメント

Ubuntu14.04でGitフックを使用してHugoサイトを本番環境にデプロイする方法

序章

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

以前のガイドでは、HugoをUbuntu 14.04システムにインストールし、それを使用してコンテンツを作成する方法について説明しました。 このガイドでは、gitを使用してシステムをセットアップする方法を示します。このシステムを使用して、新しいコンテンツを本番Webサーバーに自動的に展開できます。

前提条件

このガイドでは、Hugoインストールガイドで概説されているように、Ubuntu14.04マシンが開発マシンとして稼働していることを前提としています。

Ubuntu14.04サーバーをセットアップして、実際の本番Webサイトにサービスを提供します。 このサーバーで、sudo権限を持つroot以外のユーザーを作成したことを確認してください。 初期サーバーセットアップガイドに従って、このアカウントを作成できます。

開発サーバーの準備

開発サーバー(前のHugoガイドでセットアップしたサーバー)から始めます。 前回使用したのと同じ非rootアカウントを使用してそのサーバーにログインします。

ワンステップ展開のセットアップを行うには、このサーバーでいくつかのことを行う必要があります。 必要がある:

始めましょう。

本番サーバーへのSSHキーアクセスを構成する

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

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

  1. ls ~/.ssh/id_rsa

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

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

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

  1. ssh-keygen

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

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

Output
/home/demouser/.ssh/id_rsa

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

  1. ssh-copy-id username@production_domain_or_IP

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

sshコマンドを使用して運用サーバーのホスト名を要求することにより、この機能をテストします。

  1. ssh username@production_domain_or_IP cat /etc/hostname

今回はパスワードの入力を求められることはありません。 本番サーバーのホスト名を受け取る必要があります。

Output
prodserver

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

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

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

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

  1. git clone --bare ~/my-website /tmp/my-website.git

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

  1. scp -r /tmp/my-website.git username@production_domain_or_IP:

本番サーバー用のGitリモートを追加する

実稼働サーバーにベアgitリポジトリがあるので、追跡されたリモートリポジトリとして実稼働サーバーを追加できます。 これにより、新しいコンテンツを本番サーバーに簡単にプッシュできるようになります。

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

  1. cd ~/my-website

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

  1. git remote add prod username@production_domain_or_IP:my-website.git

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

本番サーバーのセットアップ

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

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

本番サーバーにGit、Pygments、Nginxをインストールします

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

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

  1. sudo apt-get update
  2. sudo apt-get install git nginx python-pip

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

  1. sudo pip install Pygments

ダウンロードが完了したら、開発マシンにリモートリポジトリが正しく設定されていることをテストできます。 開発マシンで、Hugoプロジェクトディレクトリに移動し、git ls-remoteコマンドを使用します。

  1. cd ~/my-website
  2. git ls-remote prod

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

Output
103902f5d448cf57425bd6830e544128d9522c51 HEAD 103902f5d448cf57425bd6830e544128d9522c51 refs/heads/master

本番サーバーにHugoをインストールします

本番サーバーに戻り、Hugoをインストールする必要があります。 開発サーバーでコンテンツを構築する代わりに、git pushごとに本番サーバーで静的アセットを構築します。 これを行うには、Hugoをインストールする必要があります。

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

  1. uname -i

次に、Hugoリリースページにアクセスします。 最新のHugoバージョンについては、「ダウンロード」セクションまで下にスクロールしてください。 アーキテクチャに対応するリンクを右クリックします。

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

  1. cd ~
  2. wget https://github.com/spf13/hugo/releases/download/v0.14/hugo_0.14_amd64.deb

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

  1. sudo dpkg -i hugo*.deb

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

  1. hugo version

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

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

次に進む前に、Hugoテーマを本番サーバーに複製する必要があります。

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

デプロイ中に生成されたファイルを提供するようにNginxを構成する

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

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

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

  1. mkdir ~/public_html

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

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

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

/ etc / nginx / sites-available / default
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サーバーを再起動します。

  1. sudo service nginx restart

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

Hugoサイトをデプロイするための受信後フックを作成する

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

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

  1. cd ~/my-website.git/hooks

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

  1. nano post-receive

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

パブリックWebフォルダーはPUBLIC_WWW変数で指定され、バックアップWebフォルダーはBACKUP_WWW変数でアクセスできるようになります。 最後に、MY_DOMAINをサーバーのドメイン名またはパブリックIPアドレスに設定します。

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

〜/ 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=server_domain_or_IP

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

その後、環境がデプロイメント用にセットアップされていることを確認しましょう。 展開中に新しいコピーのクローンを作成するため、既存の作業ディレクトリをすべて削除します。 また、問題が発生した場合に復元できるように、Webディレクトリをバックアップしたいと思います。 ここではrsyncを使用します。これは、cpよりも一貫して、空のディレクトリとコンテンツを含むディレクトリを処理するためです。 caommandが正しく解析されるように、$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=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コマンドをリセットして、スクリプトが終了しようとしたときにバックアップコピーが新しいコンテンツをすぐに上書きしないようにします。

〜/ 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=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が適切なタイミングでスクリプトを呼び出せるように、スクリプトを実行可能にするだけです。

  1. chmod +x post-receive

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

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

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

post-receiveフックスクリプトをテストすることから始めましょう。 これにより、~/public_htmlディレクトリにWebコンテンツの初期コピーを入力できるようになります。 また、スクリプトの主要コンポーネントが期待どおりに機能していることを確認するのにも役立ちます。

  1. bash ~/my-website.git/hooks/post-receive

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

Output
Cloning 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開発に使用しているマシンに戻ることができます。 そのマシンで、新しい投稿を作成しましょう。

  1. 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に追加し、変更をコミットします。

  1. git add .
  2. git commit -m 'Deployment test'

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

  1. git push prod master

ここで、Webブラウザーで本番サイトに再度アクセスすると、新しいコンテンツが表示されます。

http://production_domain_or_IP

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

結論

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

デプロイメントシステムに含まれる実際のメカニズムはかなり基本的なものです。 ただし、これらは、Webサーバー上でローカルコンテンツをすばやく簡単に取得するための保守が容易なシステムの基盤を形成します。 展開プロセスは自動化されているため、単純なgit push以外の変更を行うためにサーバーと対話する必要はありません。

モバイルバージョンを終了