まずはOllamaをインストール

公式ページからダウンロードします
https://ollama.com/

表示されているコマンドをターミナルに貼り付けて実行すればollamaがセットアップされます

Gemma4をインストールする

Gemma4について、Gemma4自身に聞いてみたら以下の回答が返ってきました

君自身について紹介してほしい
Gemma4は誰が作成して、いつ公開されたのか・・

ご質問ありがとうございます。私自身についてご紹介させていただきますね。✨

私は**Gemma 4（ジェマ フォー）**という名前の大規模言語モデル（Large Language Model: LLM）です。

🤖 基本情報
モデル名: Gemma 4
開発元: Google DeepMind（グーグル・ディープマインド）
モデルの性質: 私は「オープンウェイト」モデルとして設計され、研究者や開発者の皆様がより幅広く、責任を持ってAIの技術を活用していただくことを目的として公開されています。
⚙ 私の仕組みと得意なこと
私は、膨大な量のテキストデータやコードデータを用いてトレーニングされた結果、人間が使う自然な言葉のパターン、論理的な推論、そしてプログラミングの構造を理解することができます。

具体的には、以下のようなことが可能です。

知識の提供: 幅広いトピックについて、正確で包括的な情報を提供します。
対話: 人間との会話の流れを理解し、自然な会話を続けることができます。
論理的推論: 指示された手順に従って思考し、問題を分解して解決策を導き出すことができます。
コーディング: プログラミングのコード生成、レビュー、デバッグ、最適化を行うことができます。（これはさきほどのプログラミングのお手伝いに活かせる部分です）
📅 公開について
「いつ公開されたか」という点については、継続的に改良が加えられている最先端の技術基盤の上に成り立っています。私はGoogle DeepMindによって継続的に研究・開発され、その最新の成果として、オープンな形で開発者コミュニティの皆様に提供されています。

要約すると、私はGoogle DeepMindが生み出した、オープンな知性を搭載したAIアシスタントです。

私について何かご不明な点や、試してみたいことはありますか？何でもお気軽にお尋ねください！

回答内に（これはさきほどのプログラミングのお手伝いに活かせる部分です）とありますが
これは事前に「プログラミングできる？」と質問していたからです

本題のGemma4のセットアップですが、ollama導入後にプロンプトに以下を入力するだけです

ollama run gemma4:[利用したいモデルの種類]

後は自動でモデルのダウンロードが行われ、ダウンロードが終了すればターミナルからでも、GUI画面からでも利用できるようになります

早速使ってみる

今回はollamaのGUIから少し使ってみました
まずは挨拶から

無事に実行できました！
ちなみに自分が利用しているPCの環境は
・MacBookPro 2019年モデル
・CPU Intel 2.6GHz
・メモリ 16GB
ということで、正直AIで遊びにはかなり厳しい環境です・・・

ということで今回はエッジデバイス向けの「gemma4:e4b」を使ってます

モデルの種類が何種類かありますが
・gemma4:e2b、e4b→エッジデバイス向け
・gemma4:26b 31b→ワークステーション向け
ということで、当然ながらワークステーション向けのほうがベンチマークは良い結果が出力されています

お金があれば、26bや31bのモデルも動かしてみたいものです・・・

色々応用ができそうなGemma4

ということでGemma4のすごく簡単な紹介でした！
個人のPCでも動作可能で、しかも商用利用も可能という、夢が広がるモデルです！

個人的には、ChatGPTやClaude が利用制限に引っかかってしまったときの代替モデルとして利用できないかなーと考えたりしています
が、PCスペックが貧弱だから厳しいかなぁ・・・

投稿 Gemma4をOllamaから利用してみる は Sheltie Garage Tech に最初に表示されました。

Localを使用してみる

docker composeで構築してもよいでのすが、もう少し簡単にできないかなと思い、今回はLocalというツールを利用することにしました
実際にサイト構築までやってみます

まずは公式ページのDownloadからダウンロード
ダンロード時はメールアドレスが必要でした
その後、インストールを実施し、Localを実行します

初期はこんな感じ
Create a new siteをクリックして新しいサイトを作成します

Create a new siteを選択してContinueをクリックします

サイト名を入れます

PreferredかCustomを選択します
PHPバージョンやHTTPサーバー、DBを変更したい場合はCustomを選択します

ユーザー名、パスワード、メールアドレスを設定します

サイトが追加されました
起動した状態で追加されるようなので、右上のWP Adminをクリックして管理画面を表示します

WP Adminをクリックすると、いつものWordPressログイン画面になるので設定したユーザーIDとパスワードでログインします
以上で、WordPressのローカル構築は完了しました
これで、心置きなく検証が行えますね!

その他

バックアップからの復元など、大きなファイルをアップロードする場合、色々設定が変更になると思います

Site folderをクリックすると、サイトを構成するファイル群にアクセスできます

appにWordPress、confにnginxなどの設定ファイルが入っています

いったん、以上

ざっとですがLocalの紹介でした
GUIベースでWordPressを構築できるので、これなら非エンジニアの方でも簡単にWordPressを構築できそうです

1冊ですべて身につくWordPress入門講座 [ Mana ]

created by Rinker

¥2,200 (2026/04/05 21:11:25時点 楽天市場調べ-詳細)

• Amazon
• 楽天市場
• Yahooショッピング

HTMLサイトをWordPressにする本 [ 久保田 涼子 ]

created by Rinker

¥2,640 (2026/04/05 21:11:25時点 楽天市場調べ-詳細)

• Amazon
• 楽天市場
• Yahooショッピング

投稿 LocalでローカルWordPressを構築する は Sheltie Garage Tech に最初に表示されました。

そこで発生した問題が「別アプリから接続する時、サービス名がblue、greenで切り替わってしまうと接続できなくなる」というもの
今回はdocker composeのaliases機能を利用して、上記問題に対処しました

aliases機能とは?

ChatGPTに聞いてみたところ「同じネットワーク内で、そのサービスに対する“追加のホスト名”を付ける機能」とのこと
念の為公式ドキュメントを見てみると「ネットワーク上のサービスの代替ホスト名を宣言します」とのこと
ChatGPTの説明で大丈夫そうですね

ということで、aliasesを使用すると、同一のdocker network内でaliasesで指定したホスト名でもサービスが動いているコンテナにアクセスできるようになります

自分のプロジェクトでは以下のように設定しています

    networks:
      ride_webservice_network:
        aliases:
          - ride-batch

冒頭で紹介した通り、ブルーグリーンデプロイメントを行うために、サービス名をそれぞれブルー/グリーンで分けており、サービス名だけを頼りに接続設定を行うとデプロイのタイミングで通信が行えなくなります
上記のようにaliasesを設定しておくことで、ブルー/グリーンが入れ替わっても「ride-batch」という名称を接続が行えるようになります

以上

ということで、短いですがdocker composeのaliasesという機能の紹介でした

docker composeも環境構築のための最低限の機能しか利用していなかったのですが、調べてみると便利機能が色々ありそうです
最近ではAIに気兼ね無く聞くことができるので、開発もインフラ関連も新しい発見だらけで勉強になりますわ

投稿 docker composeのaliasesを利用してみる は Sheltie Garage Tech に最初に表示されました。

自分はVer3.0を利用しており、収容先ホストが変更となった対象にも含まれていたので、おそらく障害の影響を受けてしまったようです。

何が起こったか

症状として、Dcokerコンテナが起動できなくなり、Dockerデーモンの再起動を試してみたらDockerデーモンも起動できなくなった、という症状が起きました。

復旧のため、VPSを再起動したら今度はVPSも起動できなくなった、という流れです。初めての出来事だったため、かなり焦りました

復旧方法

VPSに関してはConoHaのWebコンソールからログインを行い、復旧しました

サーバー一覧のコンソールをクリックすればWebコンソール画面にアクセスできます。
余談ですが、ConoHaのコントロールパネルがバレンタイン仕様になっていて、とても可愛いです！

ここからはスクショを撮っておらず記憶ベースになりますが、以下の作業で復旧させました

rootユーザーでログイン

VPSの起動に失敗していると、「rootユーザーでログインすると、メンテナンスモードになります」のような画面が表示されているので、rootユーザーでログインします

システムログ確認

以下のコマンドでシステムログを確認します

journalctl -xb

今回のケースでは、以下のようなエラーが発生していました

/dev/vda2 ファイルの整合性が壊れている(UNEXPECTED INCONSISTENCY: RUN fsck MANUALLYのような表記)

ファイルシステムの復旧

ログに出力されていた通り、fsckを利用してファイルシステムのチェックと復旧を行います

fsck -y /dev/vda2

-yオプションはエラーを自動で復旧するオプションです。これがないとエラーを修正する際、毎回聞かれます
自分の場合、修正数が多かったため-yオプションを付けてすべて復旧としました

fsckコマンドが終了したら、VPSを再起動して正常に起動するか確認します

Dockerファイルシステムの復旧(は、できなかった・・・)

VPSはfsckで復旧しましたが、Dockerは起動できないままでした。
エラーを確認するとDockerが管理しているファイルシステムが破損している可能性があり、もっとも簡単な復旧方法は/va/lin/dockerディレクトリの作り直しでした(要するに、Dockerコンテナに関連するすべての設定やファイルを失う)

自分の場合、対象がWebサーバーだったので残しておきたいデータが無く、簡単に復旧する可能性がある方法としてDockerファイルを削除する方法で対処しました。
行ったことは以下のコマンドを実行しただけです

mv /var/log/docker /var/log/docker.broken
mkdir /var/log/docker

ディレクトリを作り直した後、Dockerデーモンの起動、各種Dockerコンテナが正しく起動するようになりました
ただし、Dockerのネットワーク設定や、ボリューム設定も消えてしまっているため、これらの設定は戻す必要があります

以上です

今夏はVPSのハードウェア故障というなかなかにレアな障害に遭遇しました。
幸い、Webサーバーだったため失っても良いデータしか保存されていなかったのが幸いです。

後は環境はdocker-composeで管理していたため、環境復旧もかなり簡単に行うことができました。
今回は色々と運が良かったと思います。

ただ、これがDB環境だったら話が変わってきますね。
DBデータはmysqldumpでバックアップは取っていますが、正しく復元できるかなど、訓練を行っておいたほうが良さそうです。
オブジェクトストレージについては・・・　流石に壊れないと思っています・・・

［改訂第3版］Linuxコマンドポケットリファレンス （ポケットリファレンス） [ 沓名亮典 ]

created by Rinker

¥2,618 (2026/04/05 21:11:41時点 楽天市場調べ-詳細)

• Amazon
• 楽天市場
• Yahooショッピング

投稿 Conohaちゃん壊れる は Sheltie Garage Tech に最初に表示されました。

TraefikとCloudflareが干渉してサイトアクセス不可に！

自分のサイトはTraefikに特定の国以外からのアクセスはブロックする設定を入れていました

先日Cloudflare無料版を導入し、しばらく問題なく動作していたのですが、ある日突然403エラーが発生し、サイトにアクセスできなくなってしまいました
Traefikのログを確認すると、[SG](シンガポール)からのアクセスのため遮断されたことがわかりましたが、VPNを使用しているわけでもなく、国内からのアクセスがシンガポールとして検知されてる原因が、この時点ではわかりませんでした

ログ内に残っていたIPアドレスを確認すると、シンガポールに設置されたCloudflareのサーバーと判明！
今まではおそらく国内に設置されていたエッジサーバーからのアクセスだったため問題なくサイトが動作していましたが、何かのタイミングでエッジサーバーがシンガポールに変わってしまい、国外アクセスとみなされブロックされたようです

Cloudflareに特定の国からのアクセスはブロックする設定を導入する

ここから本題ですが、Cloudflare無料版にも、指定した国から(またはそれ以外から)のアクセスをブロックするための設定があることがわかりました
そこで、Traefikのアクセスブロックは削除し、Cloudflare側で管理するようにしました

Cloudflare > セキュリティ > セキュリティルールから設定できます

今回は「日本」「アメリカ」からのアクセスのみ許可する設定を導入します
(Xアカウント連携を使用している関係で、アメリカからのアクセスも許可する必要がありました)

赤枠内のルールを作成からルールが作成できます

設定内容は上記のようにしました
上記例では直接式を記載していますが、「式ビルダーを使用」をクリックするとGUIを利用してルールを作成できます
今回は「日本とアメリカ以外はブロック(日本でもない、かつ、アメリカでもない国はブロック)」というルールとしました

ちなみに、無料版では5つまでルールが作成できます

以上です

Cloudflareで特定の国からのアクセスをブロックする機能を紹介しました
ウェブサイトを公開していると、セキュリティや特定の国のみにサービスを提供したいという理由などでアクセスブロックは頻繁に利用される機能かと思います

Cloudflareでは標準で機能として準備されており、かつ無料版でも利用できるというのがありがたいですね
うまく活用して、サイトのセキュリティを高めましょう！

Mastering Cloudflare Optimizing Security, Performance, and Reliability for the Web【電子書籍】[ Robert Johnson ]

created by Rinker

¥1,437 (2026/04/05 21:11:25時点 楽天市場調べ-詳細)

• Amazon
• 楽天市場
• Yahooショッピング

Webブラウザセキュリティ Webアプリケーションの安全性を支える仕組みを整理する

created by Rinker

• Amazon
• 楽天市場
• Yahooショッピング

投稿 Cloudflare無料版に海外からのアクセスブロック設定を導入する は Sheltie Garage Tech に最初に表示されました。

本当にこれでいいのかという思いもあるため、最近は
・AIにコードを作ってもらう
・中身をレビューしながら既存コードにマージ
みたいなことを行っております

さて、最近作成したプログラムで「単体テストするから、項目を箇条書きで出力して」とAIにお願いしたら、ご丁寧にGoのテストコードが出力された

「そうか、単体テストはもう手動で行う時代では無いのか」と思いつつ、いままでの経験上、ほとんどテストコードを書いたことが無いので、Go言語で単体テストをどうやって記述するのか、改めて学んでみることにした

2段階認証の認証コードを生成するロジックを例に、内容を紐解く

まずはAIが生成したテストコードは以下になります

package service

import (
	"testing" // Goの標準テストパッケージ
)

// テスト関数は必ず "Test" で始まる
// 引数は *testing.T を受け取る
func TestGenerateVerificationCode(t *testing.T) {
	// テスト実行
	code, err := GenerateVerificationCode()
	
	// ========================================
	// アサーション（検証）
	// ========================================
	
	// 1. エラーがないことを確認
	if err != nil {
		t.Errorf("エラーが発生しました: %v", err)
		return // エラーがあったらここで終了
	}
	
	// 2. コードが6桁であることを確認
	if len(code) != 6 {
		t.Errorf("コードの長さが不正です。期待値: 6, 実際: %d", len(code))
	}
	
	// 3. コードが数字のみであることを確認
	for _, char := range code {
		if char < '0' || char > '9' {
			t.Errorf("数字以外の文字が含まれています: %s", code)
			break
		}
	}
	
	// ここまで来たらテスト成功！
	t.Logf("生成されたコード: %s", code) // ログ出力（-v オプションで表示）
}

テストコードファイル名

Goのテストコードはテスト対象のファイル名 + _test.goとなる。大文字小文字の区別あり
これは必須条件で、Goでは_test.goのファイルを特別に扱う
・_test.goは本番バイナリに含まれない
・_test.goはgo buildでビルドされない
・_test.goはgo testでのみコンパイルされる
という特徴がある

引数「t *testing.T」について

tオブジェクトはテスト制御用オブジェクト
go testコマンドの実行で自動で設定される

以下のメソッドが呼び出された場合、テストは失敗となる

    t.Error("失敗")      
    t.Errorf("失敗")     
    t.Fatal("失敗")      
    t.Fatalf("失敗")     
    t.Fail()            
    t.FailNow()         

逆にテスト関数が終了するまで上記関数が呼ばれなければ、テストは成功扱い
単純に情報を出力するだけであれば、Log(またはLogf)関数を利用する

テストの実行方法

テストの実行にはgo testコマンドを利用する

現在のフォルダ配下にあるテストすべてを実行
go test ./...

指定のパッケージのテストを実行
go test ./internal/service/ -v

指定のテストのみ実行
go test ./internal/service/ -v -run TestGenerateVerificationCode

基本的なアサーション

基本的にはGo標準のlen関数や<>などの比較演算子を利用してアサーション(検証)を実行する

// エラーチェック
if err != nil {
    t.Errorf("エラーが発生: %v", err)
}

// 値の比較
if actual != expected {
    t.Errorf("期待値: %v, 実際: %v", expected, actual)
}

// 文字列の長さチェック
if len(str) != 6 {
    t.Errorf("長さが不正: 期待 6, 実際 %d", len(str))
}

// nilチェック
if value == nil {
    t.Error("値がnilです")
}

// 範囲チェック
if count < 0 || count > 100 {
    t.Errorf("範囲外: %d", count)
}

以上の知識を得たうえで最初のテストコードを眺めてみると、実行していることは至ってシンプルで
・認証コード生成関数を実行
・実行結果を検証：エラーが発生していないか
・実行結果を検証：コードが6桁か
・実行結果を検証：すべて数字か
の検証を行っているだけの内容となる

今後は積極的に使っていきたいテストコード

以前勤務していた会社ではJava(JTest)を利用して単体テストコードを作成していたけど、モックの使い方などが独特で馴染めなかった記憶があります

Goに関しても、DBやキャッシュと行った部分にはモック的なものを利用する事になりそうですが、それらについては、また次の課題として取り組んでいこうと思います。

GitHubにCIの仕組みが導入されているので、単体テストコードの整備ができればプルリクのたびに自動でテストを実行し、危険なコードはマージを行わないようなワークフローが構築できますね

※記事中のプログラムには生成AIを利用したコードが含まれます

投稿 Go言語の単体テスト入門 は Sheltie Garage Tech に最初に表示されました。

サイトにはDataDogを入れていて、負荷が高い状態が一定時間続いたら個人Slackに通知が来るようになっています
が・・・、ちょうど友人とDiscord中にアラートが鳴っていたので対応できなかったのですが、ちょうどDDos攻撃を受けていて負荷が高まっていたようです

結果、今回はConoHaさんの対応で攻撃は遮断されたわけですが、個人でも何かしらの対策をしなきゃいけないということで、CloudFlareの無料プランを利用してみることにしました

ちなみに、個人開発アプリは日本、アメリカ以外のアクセスはTraefikで遮断していますが、それでも攻撃を受けました
結局プロキシなどでアクセス元を偽装されれば意味ないですね

早速CloudFlareに申し込んでみる

CloudFlareにアクセスすると、無料で始めるというボタンがあるので、そこをクリック
アカウント作成後、ドメインを指定する画面が出てくるので、導入したいドメインを設定します
AI Crawlerの設定はデフォルトにしました(全ページブロック)

上記の画面の前に料金プランを選ぶ画面があるのでFree Planを選べばOK
次の画面でDNSレコードの追加が出てくるのでRecommendedの選択肢にチェックを入れてContinueをクリック

CloudFlareが自動である程度のDNS設定を行ってくれるのですが、すべてのレコードを追加してくれるわけではありません
画面上部に注意が出ているように自動追加できなかったレコードは手動で追加する必要があります
自分はここの注意書きをよく読まずそのまま続けてしまい、バックエンドのAPIと通信ができなくなりました
(自動でバックエンドAPIへのDNSが追加されておらず、それに気づかなかった・・・　英語だからとよく読まずに設定を進めたのが原因)

このようにレコードが追加されます
すべてのDNSが追加されているか確認しましょう

最後に、ネームサーバーの設定を変更して、CloudFlare経由でサイトにアクセスされるように変更します
自分はGMO ConoHaでDNSもドメインも管理しているので、ConoHaの管理画面からネームサーバーを変更します

ちなみに、ConoHaの場合DNSSECのオプションは無いようなので、特に設定はおこなませんでした

ネームサーバー設定から、CloudFlareが指定したネームサーバーを指定します
他の設定は削除するよう書かれていたため、既存のネームサーバーは設定後削除しました

あとはCloudFlareが有効になると、メールで通知が飛んでいます
これでCloudFlareの設定は完了です

設定自体はそこまで難しくありませんが、英語のページが連続するのでそこだけちょっと大変かもしれません・・・

終わりに

今回はCloudFlareの無料プラン導入のステップを紹介しました
自分もまだ導入したばかりで、これから設定などをちゃんと見ていく段階です
一応、無料プランでもDDos Protectionが有効になっているので、同じ用にDDos攻撃を受けてサーバー負荷が上がらないか監視していこうと思います

それにしても、利用者が自分しか無い無いようなサーバーにDDos攻撃を仕掛けるなんて・・・　何が目的なのか？

Webブラウザセキュリティ Webアプリケーションの安全性を支える仕組みを整理する

created by Rinker

• Amazon
• 楽天市場
• Yahooショッピング

Instant CloudFlare Starter【電子書籍】[ Jeff Dickey ]

created by Rinker

¥2,287 (2026/04/05 21:11:42時点 楽天市場調べ-詳細)

• Amazon
• 楽天市場
• Yahooショッピング

投稿 CloudFlare(無料枠)を自作Webアプリに導入 は Sheltie Garage Tech に最初に表示されました。

ただこれだとめんどくさいだけでなく、エラー発生の際にアラートを出すことも難しいため、なにか良いツールが無いか調べたところGrafana + Loki + Promtailの構成にたどり着きました

各ツールについて簡単なまとめ

Grafanaとは・・・
様々なデータソースから取得した情報をダッシュボードに表示したり、グラフとして表示するためのツール

Lokiとは・・・
ログの収集、検索を行うためのシステム

Promtailとは・・・
ログを収集し、Lokiにデータを送るためのエージェント

なので、仕組みとしては
Promtailがコンテログを収集してLokiに集約、集約されたデータをGrafanaで表示したり、Grafanaで実行した検索クエリをLokiが実行して、結果をGrafanaで表示する　というように、3つのツールが連携して動くようです

Grafana + Loki + Promtailの構成例

Grafana + Loki + Promtailの環境自体もDocker composeで作成します
今回はほとんどの内容をClaude(Sonnet 4.5)に作ってもらってます

services:
  # ログ集約システム
  loki:
    image: grafana/loki:3.5
    container_name: loki
    ports:
      - "3100:3100"
    volumes:
      - ./loki-config.yml:/etc/loki/config.yaml
      - loki-data:/loki
    command: -config.file=/etc/loki/config.yaml
    user: "0"  # rootユーザーで実行（Mac環境での権限問題回避）
    networks:
      - staging-network
    restart: unless-stopped

  # ログ収集エージェント
  promtail:
    image: grafana/promtail:3.5
    container_name: promtail
    volumes:
      - ./promtail-config.yml:/etc/promtail/config.yml
      # Mac用のログパス設定
      - /var/log:/var/log:ro
      # Docker Desktop for Macの場合
      - /var/lib/docker/containers:/var/lib/docker/containers:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
    command: -config.file=/etc/promtail/config.yml
    networks:
      - staging-network
    depends_on:
      - loki
    restart: unless-stopped

  # ダッシュボード
  grafana:
    image: grafana/grafana:11.3.0
    container_name: grafana
    ports:
      - "3101:3000"
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=admin
      - GF_USERS_ALLOW_SIGN_UP=false
    volumes:
      - grafana-data:/var/lib/grafana
      - ./grafana-datasources.yml:/etc/grafana/provisioning/datasources/datasources.yml
    networks:
      - staging-network
    depends_on:
      - loki

networks:
  staging-network:
    external: true

volumes:
  loki-data:
  grafana-data:

Grafana + Loki + Protmailの構成例です
上記のdocker composeファイル1つの中にまとめられています

上記はローカル環境の例でMacBook上に構築されたアプリ実行環境(Webアプリ、MySQLなどのインフラが複数のdocker containerで動作している環境)のログを監視できます

apiVersion: 1

datasources:
  - name: Loki
    type: loki
    access: proxy
    url: http://loki:3100
    isDefault: true
    editable: true
    jsonData:
      maxLines: 1000

上記は「grafana-datasources.yml」の構成例です

auth_enabled: false

server:
  http_listen_port: 3100
  grpc_listen_port: 9096
  log_level: info

common:
  instance_addr: 127.0.0.1
  path_prefix: /loki
  storage:
    filesystem:
      chunks_directory: /loki/chunks
      rules_directory: /loki/rules
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory

# Loki 3.x の新しいストレージ設定
pattern_ingester:
  enabled: true

query_range:
  results_cache:
    cache:
      embedded_cache:
        enabled: true
        max_size_mb: 100

schema_config:
  configs:
    - from: 2024-01-01
      store: tsdb
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h

# Loki 3.x でのストレージ設定
storage_config:
  tsdb_shipper:
    active_index_directory: /loki/tsdb-index
    cache_location: /loki/tsdb-cache
  filesystem:
    directory: /loki/chunks

# コンパクション設定（Loki 3.x）
compactor:
  working_directory: /loki/compactor
  compaction_interval: 10m
  retention_enabled: true
  retention_delete_delay: 2h
  retention_delete_worker_count: 150
  delete_request_store: filesystem

# ログの保持期間とクエリ制限
limits_config:
  retention_period: 744h  # 31日間
  max_query_length: 721h
  max_query_series: 500
  max_query_parallelism: 32
  split_queries_by_interval: 15m
  # Loki 3.x の新機能: パターン検出
  allow_structured_metadata: true
  volume_enabled: true

ruler:
  alertmanager_url: http://localhost:9093
  storage:
    type: local
    local:
      directory: /loki/rules
  rule_path: /loki/rules-temp
  ring:
    kvstore:
      store: inmemory

# Loki 3.x: クエリスケジューラー設定
query_scheduler:
  max_outstanding_requests_per_tenant: 2048

# フロントエンド設定
frontend:
  encoding: protobuf
  log_queries_longer_than: 5s
  compress_responses: true

上記は「loki-config.yml」の設定例です

server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  # Dockerコンテナのログを収集
  - job_name: docker
    docker_sd_configs:
      - host: unix:///var/run/docker.sock
        refresh_interval: 5s
    relabel_configs:
      # コンテナ名をラベルに追加
      - source_labels: ['__meta_docker_container_name']
        regex: '/(.*)'
        target_label: 'container'
      # コンテナIDをラベルに追加
      - source_labels: ['__meta_docker_container_id']
        target_label: 'container_id'
      # コンテナのログパスを設定
      - source_labels: ['__meta_docker_container_id']
        target_label: '__path__'
        replacement: '/var/lib/docker/containers/$1/*-json.log'
      # イメージ名をラベルに追加
      - source_labels: ['__meta_docker_container_image']
        target_label: 'image'
      # ホスト名をラベルに追加
      - source_labels: ['__meta_docker_container_label_com_docker_compose_service']
        target_label: 'service'
    
    # JSON形式のログをパース
    pipeline_stages:
      - json:
          expressions:
            output: log
            stream: stream
            time: time
      - timestamp:
          source: time
          format: RFC3339Nano
      - output:
          source: output

  # システムログの収集（オプション）
  - job_name: system
    static_configs:
      - targets:
          - localhost
        labels:
          job: varlogs
          __path__: /var/log/*.log

上記は「promtail-config.yml」の構成例です

上記3つの設定ファイルをdocker composeと同じディレクトリに設置し、docker compose up -dコマンドを実行すればログ監視環境が完成します

Grafanaを利用してみる

docker compose で環境が起動したら、以下のURLでGrafana管理画面にアクセスできます
http://localhost:3101

ログインID / パスワードは以下になります
username:admin
password:admin
※ログイン後、パスワードの変更画面が表示されるので必要に応じて変更してください

ログ検索を行ってみる

無事にログインできたら、早速ログ検索を行ってみましょう

左のExplorerからログの検索が行えます

Label filtersの項目を以下のように設定します
検索用のクエリが自動で生成されます

あとは右上の青いボタンをクリックすればクエリが実行され、ログ検索結果が表示されます

自分も、まだここまでしか使い方を調べられていませんが、少なくとも各サーバーにログインしてdocker compose logsを叩くような運用と比較してかなりマシになった気がします

ログ検索以外にも、CPU使用率などのメトリクスを取得でいるようにすれば、その内容をGrafanaに表示して条件に応じてアラートを発生させる
ということもできるようです

ログについても、Errorレベルのログが出力されたタイミングでアラートを飛ばすことができるようなので、次はその設定にチャレンジてみたいと思います

以上

Grafana + Loki + Promtailを利用したdocker containerログ確認の紹介でした
Docker環境とAIの発達で環境構築もかなり楽に行えるようになったと感じました

ログ監視できる環境は良いのですが、余計なアラートが飛んだり、ログ検索データが多くなりすぎないようにログを適切に出力することも大切だなと感じました
(今作っているウェブサイトでは、そのあたりはできていないので・・・)

Getting Started with Grafana Real-Time Dashboards for IT and Business Operations【電子書籍】[ Ronald McCollam ]

created by Rinker

¥7,292 (2026/04/05 21:11:42時点 楽天市場調べ-詳細)

• Amazon
• 楽天市場
• Yahooショッピング

開発系エンジニアのためのDocker絵とき入門 [ 鈴木亮 ]

created by Rinker

¥3,080 (2026/04/05 21:11:42時点 楽天市場調べ-詳細)

• Amazon
• 楽天市場
• Yahooショッピング

投稿 Docker Composeで構築した本番環境のログ確認環境をGrafana + Loki + Promtailで構築する は Sheltie Garage Tech に最初に表示されました。

エラーメッセージ

たしかこのようなメッセージが表示されていたかと思います

TLS handshake failed for service

パスワードリセットなどでメールを飛ぶようにしているのですが、いつまでもメールが送信されないなぁと思って調べてみたら、上記のメッセージが表示されていました

Docker Mail Serverは構築手順にLet’s Encryptを利用した証明書の準備が含まれているのですが、何を勘違いしたのか「証明書は自動更新される」と勘違いしていました。実際には自動更新はされず、期限切れまでに証明書を再作成(更新)する必要があります

今回はCronで対応することにした

似たような質問がGitHubにありました
https://github.com/docker-mailserver/docker-mailserver/issues/656

自分はDockerを利用してLet’s Encryptを利用しているので、CronからDockerコンテナを起動するように設定しました
(上記のISSUEにもDockerコンテナを利用した設定例が書いてあります)

実際には、12/15にCronの実行が行われるので、その時にきちんと証明書が更新されるかは要チェックです

以上

ということで、Docker Mail Serverでメールが飛ばなくなってしまったお話でした
別途、Traefikを利用しており、そちらは証明書自動更新なので期限切れを意識していなかったのですが、Docker Mail Serverはじめ、MySQLやOpenSearchなどでも証明書は利用しているので、意外と証明書を利用している箇所が多くありました

それぞれの証明書が期限切れにならないように、きちんと管理する必要がありそうですね

Postfix実用ガイド [ カイル・D．デント ]

created by Rinker

¥3,520 (2026/04/05 21:11:43時点 楽天市場調べ-詳細)

• Amazon
• 楽天市場
• Yahooショッピング

投稿 Docker Mail Serverの証明書更新を忘れてメール送信不可！ は Sheltie Garage Tech に最初に表示されました。

GTIDベースのレプリケーションとは

GTID(Global Transaction ID)ベースのレプリケーションはMySQL5.6.11から利用可能になったレプリケーション方法
それまではバイナリログのポジションを基準にして、GTIDモードではプライマリDBでトランザクションのコミット毎に発行されるIDをベースにレプリケーションを行います
従来のレプリケーション設定時はマスターDBのbin-logやポジションなんかを調べてスレーブに設定する必要がありましたが、GTIDベースではそのような設定も不要となり、設定が大幅に簡略化されるそのこと

やってみる

早速レプリケーションを構成していきます
現在はDockerを利用してインフラを構築しています
レプリケーション構成は以下のようになります

services:
  db-primary:
    container_name: ride-mysql-primary
    image: mysql:9.4
    command: >
      mysqld
      --server-id=1
      --log-bin=mysql-bin
      --binlog-do-db=ride
      --character-set-server=utf8mb4 
      --collation-server=utf8mb4_unicode_ci 
      --default-time-zone=Asia/Tokyo
      --gtid-mode=ON
      --enforce-gtid-consistency=ON
    environment:
      MYSQL_ROOT_PASSWORD: password
      MYSQL_DATABASE: db
      MYSQL_USER: db_user
      MYSQL_PASSWORD: password
    ports:
      - 3306:3306
    volumes:
      - './primary-data:/var/lib/mysql'

  db-replica:
    container_name: ride-mysql-replica
    image: mysql:9.4
    command: >
      mysqld
      --server-id=2
      --relay-log=mysql-relay-bin
      --log-slave-updates=1
      --replicate-do-db=db
      --character-set-server=utf8mb4 
      --collation-server=utf8mb4_unicode_ci 
      --default-time-zone=Asia/Tokyo
      --gtid-mode=ON
      --enforce-gtid-consistency=ON
    environment:
      MYSQL_ROOT_PASSWORD: password
    ports:
      - 3307:3306
    volumes:
      - './replica-data:/var/lib/mysql'
    depends_on:
      - db-primary

docker compose up -dで起動すると、db-primary, db-replicaの2つのDBが立ち上がります

プライマリDBのデータレプリカDBに読み込み

プライマリDBのデータをエクスポートします(レプリカDBの初期データとして利用するため)

docker compose exec 出力元DB mysqldump -u root -p --all-databases --single-transaction > backup.sql

レプリカDBにデータベースを作成

# docker-compose.yml があるディレクトリで実行
echo "CREATE DATABASE db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;" | docker compose exec -T db-replica mysql -u root -ppassword

データをインポート

cat backup.sql | docker compose exec -T db-replica mysql -u root -ppassword

レプリケーションの設定

レプリケーションの設定を行います
まずはプライマリDBにレプリケーション専用のユーザーを作成

# docker-compose.yml があるディレクトリで実行
docker compose exec db-primary mysql -u root -ppassword -e "CREATE USER 'replicator'@'%' IDENTIFIED BY 'password'; GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'%'; FLUSH PRIVILEGES;"

レプリカDBにレプリケーションの設定を行います
GTIDベースでのレプリケーションのため、CHANGE_MASTER_LOGといったオプションは利用していません
GET_SOURCE_PUBLIC_KEY=1を設定していますが、レプリカDBからプライマリDBに接続する際にセキュアな接続を要求されたため、プライマリDBより公開鍵を取得するために設定しています

echo "CHANGE REPLICATION SOURCE TO SOURCE_HOST='db-primary', SOURCE_USER='replicator', SOURCE_PASSWORD='password', SOURCE_AUTO_POSITION=1, GET_SOURCE_PUBLIC_KEY=1; START REPLICA;" | docker compose exec -T db-replica mysql -u root -ppassword

最後にレプリカDBのレプリケーション状態を確認します

echo "SHOW REPLICA STATUS" | docker compose exec -T db-replica mysql -u root -ppassword

出力結果の Replica_IO_Running と Replica_SQL_Running が両方 Yesとなっていれば、レプリケーションが開始されています

あとはレプリカDBにデータ参照用のユーザーを設定すれば設定完了です

以上

ざっとですがGTIDベースのレプリケーション構築内容を紹介しました
以前(MySQL 5系)と比較して、確かに簡単に設定できました。特にマスターDBのbin-logやポジションを調査する必要がないのがありがたいですね

今回のケースでは(個人開発のため)DBを気軽に停止できる環境で行いましたが、停止が許されない環境では構築手順は事前に検証する必要があります

投稿 MySQL 9.4でGTIDベースのレプリケーションを設定する は Sheltie Garage Tech に最初に表示されました。