GoogleCloudの無料枠でWordPressを立ち上げて、運用してみたいと思います。

 GoogleCloudからWordPress設定①AWSは12か月だけだが、GoogleCloudは常時無償枠が以下のスペックで使用できるそうで、費用がかさんできたのでこっちで試してみる。

＜無料枠＞

ロケーション：バージニア州北部を除く米国リージョン

CPU：e2-micro

ディスク：標準永続ディスクの上限30GB（少なくすれば別インスタンスも立てられる）

 VM作成手順上記の構成でVMを作成
ネットワーキングで「HTTPSアクセス」「ロードバランスのヘルスチェック」にチェックを入れた
SSHから接続し、正常に起動しているかを確認

 Swap領域の作成メモリが1GBでアップデートも厳しいため、標準永続ディスクから1GBをスワップ領域として割り当てる。GoogleCloudでインスタンスを作成した場合、スワップ領域は作成されないらしい。
SSHでインスタンスへ接続し、以下の作業を実施
// 使用できるメモリ容量を確認
 free -h　→Swapが0になっている
 // スワップ領域の割り当て
 dd if=/dev/zero of=/swapfile bs=1M count=1000 status=progress
 chmod 600 /swapfile
 mkswap /swapfile
 swapon /swapfile
 // 起動時にマウントさせるため、/etc/fstabに追記
 vi /etc/fstab
     /swapfile none swap sw 0 0
// 再起動
shutdown -r now
// ディレクトリがマウントされているか確認
free -h　→Swapに容量が表示されていればOK
あとはアップデート等を実施。

 請求アラートの設定お金をかけたくないので1円でも発生したらアラートを発生させる。
予算とアラートを選択
予算名と予算額（今回は1円）を入力
50%とかアラート基準を設定（今回はすべて1円）し、OKする

saku

GoogleCloudからWordPress設定②

静的IPの作成とインスタンスへの適用などを行う。

静的IPの作成

★注意：作成だけして適用しないと、課金されるらしい。インスタンス削除→IPだけ残っている場合も課金対象とのこと。

VPCネットワーク＞ IPアドレス＞外部静的アドレスを予約しますをクリック
名称を付け、ネットワーク階層はスタンダード、今回はIPv4で作成
適用先は作成済みのインスタンスを選択
作成されると、自動付与されていたIPから設定したIPに変更される

docker engineのインストール（Debian）

今回は参考記事にDocker上での構築があったのでそのまま試してみる。
参考記事はUbuntuだったので、Debianで公式サイトに沿って進めた。

#現在入っているdocker関連をすべて削除する
for pkg in docker.io docker-doc docker-compose podman-docker containerd runc; do sudo apt-get remove $pkg; done

#SSHから接続してインストール実施（下準備）
sudo apt-get install ca-certificates curl

#その他手順書通りに進める
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

#ファイルの書き換えなどをする、/dev/nullなので削除かな
echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian \
    $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
    sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

#dockerのインストール
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

#hello-worldコンテナの起動
sudo docker run hello-world

#以下が表示されればOK
    Hello from Docker!
    This message shows that your installation appears to be working correctly.

    To generate this message, Docker took the following steps:
     1. The Docker client contacted the Docker daemon.
     2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
        (amd64)
     3. The Docker daemon created a new container from that image which runs the
        executable that produces the output you are currently reading.
     4. The Docker daemon streamed that output to the Docker client, which sent it
        to your terminal.
    
    To try something more ambitious, you can run an Ubuntu container with:
     $ docker run -it ubuntu bash
    
    Share images, automate workflows, and more with a free Docker ID:
     https://hub.docker.com/
    
    For more examples and ideas, visit:
     https://docs.docker.com/get-started/

 #イメージが入っているか確認
 sudo docker images

 #dockerのバージョンを確認し、正常にインストールできているかを確認
 sudo docker version
     Client: Docker Engine - Community
     Version:           27.4.1
     API version:       1.47
     Go version:        go1.22.10
     Git commit:        b9d17ea
     Built:             Tue Dec 17 15:45:56 2024
     OS/Arch:           linux/amd64
     Context:           default
    
    Server: Docker Engine - Community
     Engine:
      Version:          27.4.1
      API version:      1.47 (minimum version 1.24)
      Go version:       go1.22.10
      Git commit:       c710b88
      Built:            Tue Dec 17 15:45:56 2024
      OS/Arch:          linux/amd64
      Experimental:     false
     containerd:
      Version:          1.7.24
      GitCommit:        88bf19b2105c8b17560993bee28a01ddc2f97182
     runc:
      Version:          1.2.2
      GitCommit:        v1.2.2-0-g7cb3632
     docker-init:
      Version:          0.19.0
      GitCommit:        de40ad0

WordPressのインストール

ここから参考記事に戻って作業。mariaDBとnginxを使用する。

#使用ディレクトリの作成とcomposeファイルの取得
cd
mkdir wp
cd wp
curl -sSL https://raw.githubusercontent.com/bitnami/containers/main/bitnami/wordpress/docker-compose.yml > docker-compose.yml


#ランダムパスワードの作成（これ使わなくても適当なランダム値もOK）
openssl rand -base64 12

#設定ファイルを編集する
cp -p docker-compose.yml docker-compose.yml.org
sudo vi docker-compose.yaml
    mariadb:
        image: docker.io/bitnami/mariadb:latest　→変更
    wordpress:
        image: docker.io/bitnami/wordpress-nginx:latest　→変更
        environment: 
                  - WORDPRESS_USERNAME=wordpress_admin　→追記
                  - WORDPRESS_PASSWORD=（さっき作成したパスワード）　→追記

  #WordPressをdockerからデプロイ
  sudo docker compose up -d

  #http://xxx.xxx.xxx.xxx/wp-admin/index.php　からサインインできるかを確認する

WordPressに接続できない場合（FW）

上記の設定で接続できない場合は、GoogleCloudのファイアウォールルールを追加してみる。
手順は以下の通り。

VPCネットワーク＞ファイアウォールポリシーに移動
ファイアウォールルールを作成　をクリック
以下の設定で作成
・ネットワークはdefault
・トラフィックの方向は下り
・ターゲットは「ネットワーク上のすべてのインスタンス」
・ソースフィルタはIPv4で、範囲を「0.0.0.0/0」とする
・プロトコルとポートから「TCP　80,443」を入力
作成をクリック
アクセスがIPアドレスからできるかを確認する

saku

 GoogleCloudからWordPress設定③-1ドメイン作成→SSL/TLS証明書設定、WordPressの設定など

 ドメインの取得今回は初回だったので、お名前.comから新規作成した。

オプションなどはすべて外して登録。

 SSL/TLS証明書の登録https://vps.xserver.ne.jp/support/manual/man_ssl_install_flow_lets_encrypt.php

Let's Encryptを利用したかったので、手順に従ってサーバーに設定をかけた。
アップデートしてから、Certbotをインストールする
#アップデート
sudo apt update
#certbotのインストール
sudo apt install certbot python3-certbot-nginx（apacheだったらpython3-certbot-apache）
SSL/TLS証明書の取得
 #certbotの実行
 sudo certbot --nginx -d ドメイン名
 →自身のメールアドレスを入力し、利用規約に同意
証明書の自動更新設定

Let's EncryptのSSL/TLS証明書の有効期限は3ヶ月であるため、期限が迫った際に自動で更新できるように設定することを推奨します。
 #crontab.dの下層にファイル作成
 sudo vi /etc/cron.d/letsrncrypt-renew
 #以下の設定値を入力（毎月1日の00：00に実行する、その前に停止と開始）
 0 0 1 * * root certbot renew --pre-hook "service nginx stop" --post-hook "service nginx start"
 #cronの再起動
 sudo systemctl restart cron

saku

 dockerに関するエラー発生いくつかトラブルが設定時に発生したので確認。

 docker compose up -d で実行するも80番ポートが使用しているとエラーError starting userland proxy: listen tcp 0.0.0.0:80: bind: address already in use

というエラーが表示され、wordpressが起動できなかった。

→再起動時にnginxが起動していた（status=Enableだった）ので、停止して起動したところ解決。

 no configuration file provided: not foundと表示されdocker compose up -dが実行されない今までの手順でルートディレクトリの中に「wd」というdocker用のディレクトリを作成して、そこにyamlファイルなどを格納していたのに、cdをせずに実行していた。

このエラーはdocker-compose.ymlが見つからないときに表示される。

saku

 ドメインとIPの紐づけお名前.comでドメイン作成後、以下手順でAレコードの作成が必要。
対象のドメインを選択し、ドメイン設定＞DNS設定/転送設定を選択
ドメインを選び、DNSレコード設定からAレコードを追加する

saku

 GoogleCloudからWordPress設定③-2certbotのdockerからの起動がいまいち分からず、取り急ぎhttps-portalで動かしてみる。
docker-compose.ymlの編集
sudo vi docker-compose.yml
#Service以下に追記
     https-portal:
     image: steveltn/https-portal:1
     ports:
       - '80:80'
       - '443:443'
     links:
       - wordpress
     # restart: always
     environment:
       DOMAINS: 'my-domain.com -> http://wordpress:8080'
       STAGE: 'production'
       CLIENT_MAX_BODY_SIZE: 30M
       # FORCE_RENEW: 'true'
     volumes: 
       - https-portal-data:/var/lib/https-portal
 #wordpressのportsをコメントアウト
     #ports:
     # - '80:8080'
     # - '443:8443'
 #最終行に追記
     https-portal-data:
docker compose up -dで立ち上げ
CSSのhttpアクセスをhttpsに変更するため、wordpress_dataディレクトリのパーミッション変更
#パーミッション変更
chmod 644 /var/lib/docker/volumes/wp_wordpress_data/_data/wp-config.php
#wp-config.phpの38行目付近に追記
define('FORCE_SSL_ADMIN', true);
if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) &&
$_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' ) {
$_SERVER['HTTPS']='on';
 }
HTTPSでのアクセスができるか、ドメイン名で接続してみて確認

saku

 クラウドサービスにおけるアーカイブストレージの検討ファイルサーバーのBCP対策としてパブリッククラウドのアーカイブストレージを検討。

主だった製品をまとめておく。

 AWS→S3 GracierシリーズAWSはS3の中からアーカイブストレージとして2種類。

このストレージクラスは、使用頻度の少ないファイルを長期的に保存する際に有効。

Gracierは、以下の3つに分岐する。月一度でやりとりがある際などに使う。
最小保存期間を下回る場合は、最小期間分が最低でも請求されるので注意。

 ・S3 Glacier Instant Retrival最もスタンダードなS3に近い。即時アクセスが可能。

最小サイズが128KB。

最小保存期間は90日。

基本料金は1GBあたり0.004$/月（米国バージニア北部）。

ex.)医療データ、分析データ、メディアファイル

 ・S3 Glacier Flexible Retrivalデフォルトで3～5時間で取り出し可能、オプションで1～5分、大容量ファイルで5～12時間。

早く取り出したければ追加料金の支払いで可能。年に数回程度とかによさそう。

最小サイズが40KB。

最小保存期間は90日。

基本料金は1GBあたり0.0036$/月（米国バージニア北部）。

ex.)メディアアーカイブ、バックアップデータ、コンプラ用のデータ保存

 ・S3 Glacier Deep Archive最も低コストだが、最も取り出しに時間がかかる（標準12時間）。大容量では48時間。

最小サイズが40KB。

最小保存期間は180日。

基本料金は1GBあたり0.00099$/月（米国バージニア北部）。

ex.)法規制に基づくデータ保存、歴史的なアーカイブ、ほぼ使わないバックアップ

 Google Cloud→Standard Storage以外
 ・Nearline Storage月1回程度のアクセスが見込まれる場合。定期的だが頻繁ではないアクセスで使う。

1GBあたり0.010$/月（アイオワ）。

最小保存期間は30日。

 ・Coldline Storage年数回のアクセスの場合。長期保存で使用可能。

1GBあたり0.004$/月（アイオワ）。

最小保存期間は90日。

ex.)復旧用バックアップ、法的要件などのアーカイブ

 ・Archive Storage非常にアクセス頻度が低く、コスト効率の良いストレージクラス。

1GBあたり0.0012$/月（アイオワ）。

最小保存期間は365日。

ex.)数年に一度レベルのアーカイブ、企業の保管義務用アーカイブ
Google CloudはクラスAオペレーション、クラスBオペレーション、無料のオペレーションに分かれていて、1000オペレーション単位で請求が発生する。

 Azure→Azure Blob Storageのクールアクセス層以下
 ・Azure Blob StorageAzureのオブジェクトストレージサービス。テキストデータや画像データなどの非構造化データを保存

するために最適化されている。

4つのアクセス層があり、データの使用頻度に応じてユーザーがアクセス層を選択できる。

・ホットアクセス層

・クールアクセス層

・コールドアクセス層

・アーカイブアクセス層

費用計算としては、最初の50TB/月、500TB以内/月、500TB以上/月で変化してくる。

現状50TBを超えることが考えにくいので、ストレージコストは50TBで計算。

 ・ホットアクセス層データへのアクセスや変更が頻繁に行われる場合に選択。

ストレージコストは最も高額だが、アクセスコストは最も安価。

最初の50TBは、月に0.02$/GB。

 ・クールアクセス層データのアクセスや変更の頻度が低いデータの保存に最適。

ホットアクセス層に比べるとストレージコストは安く、アクセスコストは高い。

最低保存期間は90日。

最初の50TBは、月に0.011$/GB。

 ・コールドアクセス層クールアクセス層とおおよそ同じ。

最低保存期間は90日。

最初の50TBは、月に0.0045$/GB。

 ・アーカイブアクセス層データへのアクセスがほとんど行われないデータの保存に最適。

ストレージコストは最も安価だが、データ取得にかかるコストが高く、取得までの時間も長くなる。

最低保存期間は180日。

最初の50TBは、月に0.002$/GB。

saku

Nextgen Galleryを使うには

php-xmlをインストールしておかないとアップロードエラーが発生する。
WordPressセットアップ時には入れていないので注意。

saku

AWSのEC2を使わない家計簿アプリの作成

妻から家計簿をつけたいと話をされたので、家計簿アプリを作ってみることにした。
データベースの知識も応用情報受験以来なので復習しながら、かつEC2を使わずLambdaなどを活用してみる。
AWSの実務経験はないために、Claudeと壁打ちをしながら進めていく。

saku

 AWSの無料枠利用における費用について（by Claude）
 無料利用枠でカバーされる部分AWSは12か月間の無料利用枠を提供しています（一部サービスは無期限）。個人のポートフォリオ用途であれば、以下のように多くの部分が無料枠内で収まる可能性が高いです：
Amazon RDS PostgreSQL
無料枠: 12か月間、db.t2.micro/db.t3.micro インスタンス 750時間/月 + 20GB汎用SSD

小規模アプリなら無料枠内で十分対応可能

注意点: 無料期間終了後は月額約$15-25程度
AWS Lambda
無料枠: 毎月100万リクエスト + 40万GB秒のコンピューティング時間（無期限）

個人使用レベルなら無料枠内に収まる可能性が非常に高い

注意点: 大量アクセスがあった場合のみ課金発生
API Gateway
無料枠: 12か月間、100万回のAPIコール

個人使用なら無料枠内に収まる可能性が高い

注意点: 無料期間終了後、100万リクエストあたり約$3.50
AWS Amplify
無料枠: 12か月間、ビルド時間5分/日、保存容量5GB、データ転送15GB/月

小規模サイトなら無料枠内で十分

注意点: 無料期間終了後、ビルド分数単位の課金とホスティング料金が発生
追加のコスト要因
データ転送料金
AWS外へのデータ転送には料金がかかる場合がある

小規模アプリでは通常月額$1以下
Amazon Cognito（ユーザー認証を追加する場合）
50,000ユーザーまで無料

認証されたユーザーごとに料金発生（月額数セント程度）
総コスト概算
開発/テスト期間（12か月無料枠内）: 実質$0

12か月後の運用コスト:
最小限の利用（個人使用レベル）: 月額約$15-30

注意: トラフィックやデータ量が増えると増加
コスト管理のためのアドバイス
AWS Budgetsを設定
予算アラートを設定して予期せぬ課金を防止
無料利用枠追跡ダッシュボードを定期確認
AWS Management Consoleで利用状況をモニタリング
不要なリソースの削除
使用していないときはRDSインスタンスを停止

開発が終わったらテスト用リソースを削除
Savings Plans/リザーブドインスタンスの検討
長期運用の場合、コスト削減プランの検討
ポートフォリオ用途であれば、無料利用枠内か、非常に少額のコストで運用できる可能性が高いです。何か特定のサービスのコストについてさらに詳しく知りたいことはありますか？