1. Home（グラスタの場所一覧表〜入手範囲別〜）
  2. 個人サイト制作：サイトマップ
  3. Google App Engineで広告なしサイト作成
fein's personal site
fein's personal site

個人サイト制作：サイトマップへ戻る

Google App Engineで広告なしサイト作成

Google App Engineは、あなたのWebサイトやアプリをインターネット上に簡単に公開できるサービス。
プログラムを書いたら、Googleのサーバーで動かせるようにしてくれます。
面倒な設定は不要で、すぐに始められます。

ただ…正直にお話をすると、まったくもってITの知識がゼロの状態だと、敷居が高いかもしれません。
もし勉強するお時間があるなら、クラウドサービスのメリットを享受できますよ？
下品な広告が付かない自由な個人サイトを、無料で作ることができてしまいます。

個人サイトをクラウドサービスで公開する

フェードアウト効果の草花写真

Azureならほとんど専用サービスとも言える「Azure Static Web Apps」というプロダクトがあるんですよね。
HTML、CSS、JavaScriptなどの静的コンテンツを簡単にデプロイし、グローバルに配信するためのサービスとなります。

GCPだと「Firebase Hosting」もあって、これでも良いと思います。
私がひとまずGoogle App Engineを選んだのは、App Engineのほうが歴史が長く、専門書の出版数も多いからです。
FirebaseはGoogleに買収され、その後でFirebase Hostingが導入されたんだよね。

AWSにも「AWS Amplify」というのがありますよ。
静的ウェブサイトやシングルページアプリケーション（SPA）のホスティングを提供し、グローバルCDN、カスタムドメイン、継続的デプロイなどの機能を備えています。

情報商材屋ではないのでね。今は骨組みだけですが、徐々に内容を具体化していきます。
個人サイトについてX（旧Twitter）でよく話題になるhtml・css・JavaScriptというのは、要するにフロントエンドに関するコードなんですよね。
バックエンドは、例えば私がローカルサーバーを立てるのにインストールしたPythonなんかがそうです。
それで、ここでお話ししているクラウドというのは…一言で書くのは極めて難しいですが、インフラと言えば良いでしょうか。
個人サイト作るだけなのにサーバー実機なんか買わないでしょ？

ホスティング先のクラウド選び

まずは料金が安いGoogle Cloudから探してみるのがいいんじゃないかな。
私は次のようにして、ひとまずApp Engineを試しています。
  1. Google Cloudからプロダクトを選択。より詳しくやりたいことが具体的になっている場合はGoogle Cloud プロダクト
  2. 大項目を選択する。─ ここではサーバーレスを選択します。なぜサーバーレスなのかですが、アプリケーション ホスティングの概要に詳しく書いてあります。いきなりIaaSを検討しなくて良いでしょう。 ─
  3. Cloud Run・Cloud Functions・App Engine・Workflows・API Gatewayをさっと見てから…
  4. AWS サービスや Azure サービスと Google Cloud を比較するで似たようなサービスをそれぞれ調べる。
  5. それらのプロダクトの中から、自分のニーズにあったものを選ぶ。

レンタルサーバー VS クラウドサービス

やってることは似たようなもんだと思うんですけどね。
AWS、GCP、Azureなどのクラウドサービスの台頭は、レンタルサーバー業界に大きな影響を与えています。
これらのクラウドサービスは、スケーラビリティ、柔軟性、コスト効率の面で優れており、多くの企業や個人が従来のレンタルサーバーから移行する要因となっているんですよね。

コストで比べる

クラウドサービスは従量課金制や無料の初期利用枠を提供しており、初期コストを抑えたいユーザーにとって魅力的です。
私なんか思いっきりこのタイプですよ。
クラウドにホスティングすれば、無料で広告無しの自由自在なWebサイトにできるのです。

技術で比べる

クラウドサービスは最新の技術を迅速に取り入れることができ、セキュリティやパフォーマンスの面でも優れています。
さすがにAWS、GCP、Azureのクラウドですからね。

運用の簡便さで比較する

クラウドサービスは、インフラの管理を自動化するツールやサービスを提供しており、ユーザーはより簡単に運用できます。
開発環境を整えるために個人でハイスペックPCを用意する必要がないのですよ。
私はずっとロースペックパソコンでWeb書いてます。

市場の変化

個人サイトを作る人が減少し、SNSやブログサービスの利用が増えていることも影響していますね。
私が「無料＆格安でWebサイトを作る」にてお勧めしている Google Sites はホームページ作成サービス、Blogger はブログサービスです。
それで、イーロンマスクによってXの将来が不透明になってきたから、昔のように個人サイトが注目されるようになってきたという流れです。

おそらく、これからも昔ながらの「レンタルサーバー」は、１つまた１つとサービス終了していくのではないかと。
その頃にはAWS、GCP、AzureなどのクラウドサービスがもっとIT初心者にも使いやすくなっていることでしょう。

個人サイトなら Cloud run と App Engine どちらが有利か？

フェードアウト効果の草花写真

Google Cloudの「Cloud Run」と「App Engine」はどちらもサーバーレスのコンピューティングサービスです。
Cloud Runはコンテナベースで任意の言語やライブラリを使用できます。
リクエストに応じて自動的にスケールし、アイドル状態ではゼロまでスケーリングダウンします。
そのため、使用したリソースに基づいて課金され、アイドル状態のコストは低く抑えられます。

一方、App EngineはPaaS（Platform as a Service）です。
アプリケーションコードをデプロイするだけでインフラの管理をGoogleに任せることができます。
スタンダード環境とフレキシブル環境があります。
スタンダード環境は自動スケーリング、フレキシブル環境はカスタマイズ可能なインフラを提供します。
ソースコードを直接デプロイでき、特定のランタイム環境を選択するだけで動作します。
しかし、インスタンスベースの課金モデルでアイドル状態でも一定のコストが発生します。

静的ウェブサイトのホスティングに関しては、Cloud Runはコンテナを使用します。
静的ファイルを含むコンテナイメージを作成し、それをデプロイすることでホスティングが可能です。
スケーリングの柔軟性とコスト効率の面で優れているんですよね。
一方、App Engineは特にスタンダード環境での静的ファイルのホスティングが簡単で設定も少なく済みます。
しかし、アイドル状態のコストが発生する点に注意が必要です。

とはいえ、標準環境であれば無料枠があるわけです。
総合的に見ると、静的ウェブサイトのホスティングにはCloud Runがより適しているように思えますが、どちらのサービスも優れた機能を持っているため、具体的なニーズに応じて選択することが重要です。

クラウドサービスには無料枠がある

ここで、無料枠の話をしましょう。
静的ウェブサイトのホスティングに関して、Google Cloud RunとGoogle App Engineの無料枠を比較すると、以下の点を考慮する必要があります。

Google Cloud Run

Google App Engine

比較ポイント

静的ウェブサイトのホスティングに関しては、アクセス頻度や必要なリソースに応じて選ぶと良いでしょう。

頻繁にアクセスされるサイトならApp Engine
短時間で多くのリクエストがある場合はCloud Run
これは目安に過ぎませんが、私の場合、旬な話題や時事ネタなど、浮き沈みが激しいものは避けています。 よって、App Engineが有利であろうと判断してるんだよね。

Google Kubernetes Engine と Cloud Run の違い

「Cloud Run」と「Google Kubernetes Engine (GKE)」は、どちらもGoogle Cloudが提供するコンテナ運用サービスですが、用途や特徴が異なります。
Cloud Runはサーバーレスプラットフォームで、ステートレスなコンテナアプリケーションをサーバーレス環境で実行するためのもので、インフラ管理の手間を大幅に削減できます。
自動スケーリング機能によりリクエスト数に応じてスケールし、リクエストがない場合はゼロにスケールします。
デプロイも簡単で、単一のコマンドで可能です。

一方、GKEはKubernetesをベースにしたコンテナオーケストレーションプラットフォームで、ステートフルおよびステートレスなアプリケーションの両方をサポートします。
クラスタの構成や管理を細かくカスタマイズでき、ネットワーキング、ストレージ、オブザーバビリティなどの設定が可能です。
GKEはCPU使用率やカスタムメトリクスに基づいて水平Pod自動スケーリングを行い、データベースやセッション管理が必要なステートフルなアプリケーションにも対応しています。

Cloud Runはステートレスなアプリケーションを迅速にデプロイしたい場合やインフラ管理の手間を最小限に抑えたい場合、トラフィックの予測が難しい場合に向いてるかな。個人サイトに向いてるのはこっちだと思う。
GKEはステートフルなアプリケーションをデプロイしたい場合やKubernetesの高度な機能をフル活用したい場合、細かいカスタマイズが必要な場合に適しています。

個人サイト向けのapp.yaml設定

App Engineの「app.yaml」ファイルは、Google App Engineアプリケーションのデプロイや動作に関する重要な情報をまとめて管理するためのものです。
このファイルには、アプリケーションの動作に関するさまざまな設定が含まれています。

参考サイト

yaml.org

ランタイムの指定

使用するプログラミング言語やランタイム環境を指定します。
app.yamlファイルでは、アプリケーションがどのプログラミング言語やランタイム環境を使うかを指定することができます。
これをもって、Google App Engineがアプリケーションを正しく実行するための環境を準備することになります。

プログラミング言語

アプリケーションが書かれている言語です。
例えば、Python、Java、Node.jsなどです。

ランタイム環境

アプリケーションを実行するためのソフトウェア環境です。プログラミング言語に対応したランタイムが用意されています。
例えば、Pythonを使ってアプリケーションを作成している場合、runtime:として記述されることになるでしょう。
Python 3.9のランタイム環境を使用することを指定すると、Google App EngineはPython 3.9を使ってアプリケーションを実行します。
同じようにnodejs14などを使うこともできます。
このように、app.yamlファイルで使用するプログラミング言語やランタイム環境を指定することで、アプリケーションが正しく動作するように設定します。

ハンドラの設定

URLパスとそれに対応するリクエストハンドラを定義します。
前述のようにapp.yamlは、Google App Engineでアプリケーションの設定を行うためのファイルです。
このファイルの中で、「URLパス」と「リクエストハンドラ」を定義します。

URLパス

ユーザーがウェブブラウザに入力するアドレスの一部です。
例えば、/homeや/aboutなどです。

リクエストハンドラ

特定のURLパスにアクセスがあったときに、そのリクエストを処理するプログラムや関数のことです。
簡単に言うと、app.yamlファイルで「このURLにアクセスがあったら、このプログラムを実行してね」と指示を出している感じです。
例えば、次のような設定があったとします


# yamlの記述内容
handlers:
- url: /home
 script: home.app
- url: /about
 script: about.app

この場合、ユーザーが/homeにアクセスすると、home.appというプログラムが実行され、/aboutにアクセスすると、about.appというプログラムが実行されます。

インスタンスの設定

インスタンスのスケーリングやクラスを設定します。
app.yamlファイルでインスタンスのスケーリングやクラスを設定することで、アプリケーションのパフォーマンスを最適化し、コストを管理することができます。

インスタンスのスケーリング

アプリケーションの負荷に応じてインスタンスの数を増減させる仕組みです。
例えば、アクセスが多いときにはインスタンスを増やし、少ないときには減らすことで、効率的にリソースを使うことができます。

インスタンスのクラス

インスタンスの性能やコストに関する設定です。
例えば、高性能なインスタンスを使うか、低コストなインスタンスを使うかを選ぶことができます。

例えば、次のようなことを指定していきます。

環境変数の設定

アプリケーションで使用する環境変数を定義します。
環境変数を使うことで、アプリケーションのコードを変更せずに設定情報を変更することができます。
セキュリティが向上し、設定の管理が簡単になります。

環境変数

アプリケーションが動作する際に必要な設定情報を外部から渡すためのものです。
例えば、データベースの接続情報やAPIキーなど、アプリケーションのコードに直接書きたくない情報を環境変数として設定します。

app.yaml

ファイルで環境変数を定義することで、これらの情報を簡単に管理できます。

例えば、DATABASE_URL: "mysql://user:password@localhost/dbname"としてデータベースの接続情報を指定します。この情報を使って、アプリケーションはデータベースに接続します。
APIについてはAPI_KEY: "your-api-key-here"と書くことで、外部のサービスを利用するためのAPIキーを指定します。このキーを使って、アプリケーションは外部サービスにアクセスします。

静的ファイルとディレクトリを設定する方法

静的ファイルの設定

静的ファイルを提供するためには、app.yamlファイルにstatic_filesまたはstatic_dirを使用してハンドラを定義します。
static_filesの使用例
static_filesを使用すると、特定のファイルパターンに一致するファイルを提供できます。 

# yamlの記述内容
- url: /static(.*)
 static_files: static/\1
 upload: static/(.*)

(.*)
これは正規表現のパターンで、任意の文字列（0文字以上）にマッチします。
括弧で囲まれているため、キャプチャグループとして機能します。
つまり、マッチした部分を後で参照できるように保存します。

\1
これはキャプチャグループの参照です。
正規表現のパターンで最初にキャプチャされたグループ（この場合は(.*)）を指します。
\1は最初のキャプチャグループ、\2は2番目のキャプチャグループ、というように続きます。

url: /static/(.*):

/static/に続く任意の文字列にマッチします。
例えば、/static/image.pngや/static/css/style.cssなどです。

static_files: static/\1:

マッチしたURLのパスの部分（(.*)）をstatic/ディレクトリ内の対応するファイルにマッピングします。
例えば、/static/image.pngがリクエストされた場合、static/image.pngファイルが提供されます。

upload: static/(.*):

App Engineにアップロードされるファイルのパスを指定します。
static/ディレクトリ内の任意のファイルがアップロード対象となります。
この設定があることで、/static/に続く任意のパスがstaticディレクトリ内の対応するファイルにマッピングされ、App Engineにアップロードされるファイルも同様に指定されます。

static_dirの使用例

static_dirを使用すると、ディレクトリ全体を静的ファイルとして提供できます。


# yamlの記述内容
- url: /static
 static_dir: static

この例では、/static URLに一致するリクエストがstaticディレクトリ内のファイルにマッピングされます。

app.yamlの構文例

下記コードのコピペはお勧めできません

費用がかかる可能性がありますよ。
あくまでも私の環境に沿った上でのコードですから、ちゃんと意味を理解してから書いた方が良いです。 


runtime: python38  # Python 3.8のランタイムを使用
instance_class: F1  # 使用するインスタンスタイプ
env: standard  # 標準環境でデプロイ

runtime_config:
  document_root: www  # ドキュメントルートのディレクトリを指定

automatic_scaling:
  min_idle_instances: 0  # 最小アイドルインスタンス数
  max_idle_instances: 2  # 最大アイドルインスタンス数
  max_concurrent_requests: 100  # インスタンスごとの最大同時リクエスト数

handlers:
- url: /  # ルートURLにアクセスがあったとき
  static_files: www/index.html  # www/index.htmlを返す
  upload: www/index.html  # アップロードするファイルパスの指定

- url: /favicon.ico  # /favicon.icoにアクセスがあったとき
  static_files: www/favicon.ico  # www/favicon.icoを返す
  upload: www/favicon.ico  # アップロードするファイルパスの指定

- url: /(.*)  # 任意のURLにアクセスがあったとき（正規表現を使用）
  static_files: www/\1  # wwwディレクトリ内の対応するファイルを返す
  upload: www/(.*)  # アップロードするファイルパスの指定

app.yaml構文例の説明

GCP・AWS・Azureで独自ドメインを使う

GCP、AWS、Azureのいずれかを使用して独自ドメインを購入し適用する方法をサーっと書きますか。
そんなに難しくありませんが、大したものではないとはいえ費用がかかるからね。
ナシで済ませられるなら、それで良いと思いますけど。
独自ドメインなしでもGoogle検索に乗せることは可能ですよ？

Google Cloud Platform (GCP)のケース

Amazon Web Services (AWS)のケース

Microsoft Azureのケース

Webサイト制作に関係するミドルウェア

ミドルウェアというのは、オペレーティングシステム アプリケーションソフトウェアの間に位置するソフトウェアのことです。
OSが提供する基本機能とアプリケーションが必要とする特定の機能の橋渡しをする役割を持っています。
Webサイト制作に関連するミドルウェアには、以下のようなものがありますね。

Webサーバ

データベースサーバ

アプリケーションサーバ

クラウドサービスの中でミドルウェアの管理を気にせずに利用できるものとして、GCP、AWS、Azureには以下のようなサービスがあります。

Google Cloud Platform (GCP)

Amazon Web Services (AWS)

Microsoft Azure

これらのサービスは、ミドルウェアの管理を気にせずに利用できるため、開発者の負担を軽減します。

Webサイト制作とスケーリング・負荷分散

Webサイト制作では、スケーリングと負荷分散が重要です。
小規模な静的ウェブサイトレベルであれば、ここまで把握しなくて良いと思いますけどね。
「ふーん…」くらいの気持ちで眺めてもらえれば。
GCPはGoogle Cloud Load BalancingとAutoscaling。
AWSはElastic Load Balancing (ELB)とAuto Scaling。
AzureはAzure Load BalancerとAzure Virtual Machine Scale Sets。
このようなプロダクトを使うことで、トラフィックの負荷分散と自動スケーリングを実現します。

GCPのケース

Google Cloud Load Balancing
GCPのロードバランシングは、複数の仮想マシン（VM）インスタンスに対してトラフィックを分散します。

Autoscaling
GCPのAutoscalingは、管理されたインスタンスグループ（MIG）内のVMインスタンスを自動的に追加または削除します。次の条件に基づいてスケーリングが行われます。

これらの機能を組み合わせることで、GCP上でのアプリケーションはトラフィックの増減に柔軟に対応し、コスト効率を高めることができます。

AWSのケース

Elastic Load Balancing (ELB)
ELBは、複数のEC2インスタンスに対してトラフィックを自動的に分散する機能を持っています。
これにより、特定のインスタンスに負荷が集中することを防ぎ、アプリケーションのパフォーマンスを維持します。
また、ELBは各インスタンスに対して定期的にヘルスチェックを行い、異常が検知されたインスタンスにはトラフィックを送信しないようにします。

Auto Scaling
Auto Scalingは、トラフィックの変動に応じてEC2インスタンスの数を自動的に増減させる機能です。
あらかじめ設定したルールに基づいて、必要なリソースを確保し、運用の手間を大幅に削減します。

連携の仕組み

ELBの種類

ELBとAuto Scalingを連携させることで、トラフィックの変動に合わせて適切なリソースを自動的に確保し、トラフィックを最適に分散させることができます。
Webアプリケーションのパフォーマンスと可用性を高く維持できますね。

Azureのケース

Azure Load Balancer
Azure Load Balancerは、複数の仮想マシン（VM）に対してトラフィックを分散するサービスです。
特定のVMに負荷が集中することを防ぎ、アプリケーションのパフォーマンスを維持します。

Azure Virtual Machine Scale Sets
Azure Virtual Machine Scale Setsは、トラフィックの増減に応じてVMの数を自動的に調整するサービスです。
必要なリソースを自動的に確保し、コスト効率を高めることができます。

連携方法

このように、AzureでもAWSと同様に、負荷分散と自動スケーリングを組み合わせて効率的なリソース管理が可能です。

Webサイト制作とネットワーク

ネットワークなんて本格的にやるとめちゃくちゃ難しいですけどね。
でもこのくらいなら…といいますか、個人でWebサイト作って遊ぶときに知っておくと便利な知識くらいは、書いていこうかと思います。

※この項はクラウドのネットワークページへ移植すること

ネットワークアドレスは、特定のネットワークを識別するためのアドレスです。
例えば、IPアドレス 192.168.1.0 は、192.168.1.0/24 ネットワークのネットワークアドレスです。
このアドレスは、ネットワーク内のすべてのデバイスが属する共通の識別子となります。

ホストアドレスは、ネットワーク内の個々のデバイス（ホスト）を識別するためのアドレスです。
例えば、192.168.1.10 は、192.168.1.0/24 ネットワーク内の特定のデバイスのホストアドレスです。
ホストアドレスは、ネットワークアドレスとサブネットマスクを組み合わせて決定されます。

CIDR（Classless Inter-Domain Routing）表記は、IPアドレスとサブネットマスクを簡潔に表現する方法です。
例えば、192.168.1.0/24 は、IPアドレス 192.168.1.0 とサブネットマスク 255.255.255.0 を表します。
/24 は、ネットワーク部分が24ビットであることを示しています。

サブネットは、大きなネットワークを小さなネットワークに分割するための方法です。
その結果、ネットワークの管理が容易になり、効率的なIPアドレスの利用が可能になります。
例えば、192.168.1.0/24 ネットワークを 192.168.1.0/26 と 192.168.1.64/26 の2つのサブネットに分割することができます。

DMZ（Demilitarized Zone）は、内部ネットワークと外部ネットワーク（インターネット）の間に配置される中間ネットワークです。
DMZに配置されたサーバーは、外部からアクセス可能でありながら、内部ネットワークへの直接アクセスを防ぐ役割を果たします。
このため、セキュリティが強化されます。

サイトマップ

アナザーエデン関連ページ・サイトマップ

アナザーエデンの強敵戦やストーリーコンテンツのリスト、お勧めバッジなどを掲載したコーナーです。
期間限定のない普通のRPGですので、初心者でも安心して続けていけるゲームとなっています。
もっとも重要なグラスタについては、場所別に網羅した表があります。

個人サイトのホスティングとコンテンツ作成

個人でウェブサイトを作るにはどうすればいいか。
HTML・CSS・JavaScriptの書き方はもちろん、無料かつ広告なしでホームページを作る方法を掲載したコーナーです。
Webデザインやレイアウトについても書いてあります。

魚釣りなどアウトドアのエリア

ゲームとパソコンだけじゃなく、アウトドアも趣味なんです。
このコーナーでは魚釣りの記録とか、魚料理のレシピ、はたまたサイクリングなどなど。
アウトドアに関連するコンテンツが詰め込まれています。