前回の続きです。公開方法について書きます。

種類


静的サイトジェネレータはhtmlをアップロードするだけというのもあるのですが、ざっと思いつくだけで以下の方法があります。

  • Webサーバで配信
  • GitHubPages(GitLabPagesなど)
  • Netlify
  • AWS S3

おそらく、最も有名なのはGitHubPagesだと思います。本サイトも以前はGitHubPagesで配信していましたが、現在はVPSのnginx経由で配信しています。

それぞれについて


それぞれの公開方法についてザックリと記述します。

Webサーバで配信

VPSなりEC2なりでサーバを構築して、そこにApacheなりnginxなりのWebサーバを構築して配信する方法です。このサイトはこの方法をとっています。

GitHubPagesなど

おそらく、最もメジャーな方法として広まっている気がします。生成したhtmlをそのまま公開できるのでデプロイも不要です。ただ「閲覧(リクエスト)数に制限がある」との記述をどこかで見かけた気がします。このサイトも以前はGitHubPagesを利用していました。また、同様にGitLabPagesとかでもほぼ同じ方法を取ることができるのではないかと思います。

Netlify

私は利用したことがないのですが、静的サイトのホスティングサービスらしいです。StaticGenページの「Deploy to Netlify」を利用するとGitHub経由で簡単に公開できるらしいです。「閲覧(リクエスト)数の制限」はGitHubより緩いというのをどこかで見た気がします。(つまり、閲覧数が増えた場合はNetlifyの方が良いということです)

StaticGenより

AWS S3

AWS S3は静的サイトとして利用できるのでそのまま放り込んで利用するというやり方です。Cloud Frontとの連携できるなど、AWSの機能と連携できるのは強いと思われます。

デプロイについて


さて、公開方法に応じてデプロイ方法は異なりますが、大きく分けて3つになるのではないかと思います。(すみません、図があれば好ましかったのですが、現状作図方法がないので文字でお送りします)

生成後の資産をそのまま上げる

GitHubPagesの場合ですと、生成後の資産(html・css・js)をそのまま上げると公開することができます。わかりやすいですね。また、AWS S3の場合でもAWS CLIでS3にそのまま流し込むという方法も考えられます。

自前のインスタンスにWebサーバで配信しているという場合も同様で、rsyncやSFTPでの送信も考えられますね。

サーバ側で生成を行う

自前のインスタンスを用いる場合はローカルマシンではMarkdownのみ管理して生成をサーバ側で行うという方法も考えられます。この場合はサーバ側にMarkdownからhtmlへの生成処理が必要になります。

CIサービスを利用して生成を行う

どの方法で公開するとしてもこの方法は利用できるのではないかと思います。前述の方法でサーバ側での生成処理をCIサービスにやってもらうという形ですね。また、最も広まっているように見受けられます。流れとしてはローカルマシンで記事を書いてGitHubなどにpushしてそれをトリガーとしてCIサービス(CircleCIなど)をキックします。後はCIサービスでホスティングサービスもしくは自前のサーバにデプロイするという方式です。このサイトも一時期はこの方法を取っていました。

まとめ


組み合わせによっていろいろな方法が考えられますし、こういうの考えるのは楽しいですね。ただ、一番楽なのはGitHubPagesだと思います。

続き


次回、Hexoでハンズオンです。

つづき