1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

さくらのVPSにデプロイした後、実際につまずいたポイント3つ(SSL・cron・DBバックアップ)

1
Posted at

前回、さくらのVPSへのデプロイ手順を記事にしましたが、デプロイが終わった後にも地味にハマりやすいポイントがいくつかありました。今回はその中でも特につまずきやすい「SSL証明書」「cron設定」「DBバックアップ」の3つについて、実際の対処法をまとめます。

この記事の対象者

  • さくらのVPSへのデプロイは完了したが、その後の運用設定でつまずいている人
  • Let's Encryptでの証明書発行やcron、DBバックアップを初めて自前で構築する人

1. SSL証明書(Let's Encrypt)の設定

さくらのVPSはレンタルサーバーと違い、SSL証明書の発行・更新をすべて自分で行う必要があります。

つまずきポイント

  • ドメインのDNS設定が反映される前に証明書発行コマンドを実行してしまい、認証に失敗する
  • Webサーバー(Nginx/Apache)の設定で、証明書発行用の.well-knownへのアクセスがブロックされていて認証が通らない
  • 証明書の自動更新(cron)を設定し忘れ、90日後に有効期限切れで気づく

対処法

# certbotのインストール(Nginxの場合)
sudo apt install certbot python3-certbot-nginx

# 証明書の発行
sudo certbot --nginx -d example.com -d www.example.com

# 自動更新のテスト(実際には更新されない)
sudo certbot renew --dry-run

DNS反映の確認はdig example.comでAレコードが正しく向いているかを事前に確認してから実行すると失敗が減ります。また、certbotインストール時に自動更新用のcronやsystemdタイマーが登録されるので、systemctl list-timersで登録されているか確認しておくと安心です。

2. cron設定

アプリ側の定期処理(バッチ処理、メール送信、集計処理など)をcronで動かす際、ローカル環境では動いていたのに本番のVPS上で動かないというケースがよくありました。

つまずきポイント

  • cron実行時の環境変数がシェルログイン時と異なり、PHPやNode.jsのパスが通らずコマンドが失敗する
  • 実行ユーザーの違いにより、ファイルの読み書き権限でエラーになる
  • ログを出力する設定にしていなかったため、失敗しても気づけない

対処法

# crontab編集
crontab -e

# 例: 毎日3時に実行し、ログを残す
0 3 * * * /usr/bin/php /var/www/app/artisan schedule:run >> /var/log/cron_app.log 2>&1

コマンドやPHP/Nodeのパスはwhich phpやwhich nodeでフルパスを確認し、crontab内では必ずフルパスで指定するようにしています。また、必ず標準出力・標準エラーをログファイルに残す設定にしておくことで、後から失敗に気づけるようにしています。

3. DBバックアップ

さくらのVPSはDBのバックアップも自前で仕組みを作る必要があります。最初は手動でmysqldumpを叩いていましたが、当然忘れる/漏れるので自動化しました。

つまずきポイント

  • バックアップは取れていたが、同じサーバー内にしか保存しておらず、サーバー障害時に一緒に失われるリスクがあった
  • バックアップファイルが日々増え続け、ディスク容量を圧迫していた
  • 文字コードの設定が原因で、リストア時に文字化けが発生した

対処法

#!/bin/bash
DATE=$(date +%Y%m%d)
mysqldump -u user -p'password' --default-character-set=utf8mb4 dbname > /home/backup/db_$DATE.sql

find /home/backup -name "db_*.sql" -mtime +7 -exec rm {} \;

このスクリプトをcronで毎日実行しつつ、外部のオブジェクトストレージ(例: さくらのオブジェクトストレージやS3互換サービス)にも定期的にアップロードするようにして、サーバー障害時にもバックアップが残るようにしています。

# cron例(毎日4時にバックアップ実行)
0 4 * * * /home/backup/backup_db.sh

まとめ

デプロイ自体がゴールではなく、SSL更新・定期処理・バックアップといった「継続的に動かし続けるための仕組み」まで作って初めて本番運用と言えると感じました。特にcronとバックアップは、動いているように見えて実は失敗していたということが起きやすいので、必ずログとアラートをセットで用意しておくことをお勧めします。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?