序章

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

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

前提条件

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

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

開発サーバーの準備

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

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

  • 本番サーバーへのSSHキーアクセスを構成する
  • イニシャルを転送する git 本番サーバーへのリポジトリ
  • 本番サーバーをとして追加します git 私たちのサイトリポジトリのリモート

始めましょう。

本番サーバーへの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 代わりに、フォルダはメインフォルダにあります。 ベアリポジトリは、コンテンツをプッシュするプロセスを簡素化するため、通常、リモートサーバーに使用されます。

メインのHugoリポジトリからベアリポジトリを作成します。 /tmp ディレクトリ。 ベアレポは通常、トレーリングで識別されます .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, nginx、 と pygments
  • HugoとHugoテーマをインストールします
  • 構成、設定 nginx ホームディレクトリ内の場所からファイルを提供する
  • 作成する post-receive リポジトリにプッシュされた新しいコンテンツをデプロイするためのスクリプト

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

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

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

  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バージョンについては、「ダウンロード」セクションまで下にスクロールしてください。 アーキテクチャに対応するリンクを右クリックします。

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

本番サーバーで、ホームディレクトリに移動して使用します 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;

. . .

の「username」を必ず置き換えてください root 本番サーバー上の実際のユーザー名を使用したディレクティブ。 終了したら、ファイルを保存して閉じます。

変更を適用するには、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 repoは、実際には親ディレクトリ内の場所を指す単なるシンボリックリンクです。ダウンロードした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. 末尾を含めるようにしてください /$PUBLIC_WWW caommandが正しく解析されるようにします。

最後に行うセットアップ手順は、 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.