「Docker」タグの記事が3件件あります

lucaslorentz/caddy-docker-proxy で発生するエラー「Service is not in same network as caddy」に対する解決策です。

前提​

Docker Swarmでlucaslorentz/caddy-docker-proxy をデプロイし、各種コンテナへのリバースプロキシ用のラベルを適切に設定されている状態。

特に他にエラーが見られず設定に問題がないのにも関わらずエラーが発生する場合。

エラー内容​

エラーは以下の通りです。

"msg":"Failed to get ingress networks" "error":"Cannot find container id in cgroups" "msg":"Service is not in same network as caddy"

修正方法​

環境変数の CADDY_INGRESS_NETWORKS に属するネットワークを設定する。

例えば、externalの public ネットワークに参加しており、 public に属するコンテナへプロキシを行う場合は、 CADDY_INGRESS_NETWORKS=public と環境変数を設定する必要がある。

docker-compose.yml 例​

version: "3.7" services: caddy: image: lucaslorentz/caddy-docker-proxy:ci-alpine ports:

• 80:80
• 443:443 environment:
• CADDY_INGRESS_NETWORKS=public networks:
• public volumes:
• /var/run/docker.sock:/var/run/docker.sock
• caddy_data:/data restart: unless-stopped

networks: public: external: true

volumes: caddy_data:

Twitchで配信をしながら、勉強しつつ１０時間かけてクラスタ構築とクラスタへの移行を行いました。

クラスタを構築したのは良いもののデータベースを実行してるメインサーバが吹き飛んだので、やってからこの記事を書くまで時間が経過しました。

サーバが吹き飛んだことに関するIQ3まとめについては下記の投稿を見てください。

サーバーがカーネルパニック起こしたと思ったらハードウェアごと吹き飛んだ件

なぜクラスタを構築したのか？​

大きく２つの理由があります。

１つ目は学習目的です。クラスタに関して興味深くQiitaやZennその他様々な記事を目にしていましたが、いままで一度も構築したことがありませんでした。そこでやってみようと考えました。好奇心的なところが強いです。そもそもとして、私が自宅にサーバを持っている理由が学習目的なので、こういう感じで結構色々気軽にやってたりします。

２つ目は複数台管理が面倒くさかったです。クラスタ構築して運用できれば、個別にSSHでいちいちつないで細かく設定する必要がなくなるので、かなり管理の手間が減ると思いました。実際、楽になりました。初期に色々設定するという面ではかなり手間はありますが、そこさえ乗り越えれば楽です。

上記の２つの理由からクラスタ構築を自宅サーバ群で行いました。

自宅サーバ群について​

サーバ群なんて言っていますが、今回のクラスタ構築では３台のみで考えました。今後追加することも一応考慮しています。

１台目​

データベースやゲームサーバー、その他諸々一番色々やっているサーバ。スペックもメモリも一番ある。

ストレージは、SSDにOS、HDD２枚にそれぞれバックアップと本番の運用データが乗ってます。

OSはUbuntu Server 20.04、もともとはCentOSで運用していましたがCentOS 8でなくなるということでDebian系に乗り換えました。Ubuntuを選択した理由は、割と安定しながらも、バージョンを比較的新しいのを使ってくれるからです。後は最近のOSSとかがUbuntuで動かすことを想定して作ってることが多かったりするなんて理由もあります。あまり細かいことは考えてません。

２台目及び３台目​

Raspberry Pi 3 Model B+です。

どちらもTeam GroupのSDカード32GBを指してあります。

OSはUbuntu Server 20.04です。

基本的にデータを保持せず、サービスをDockerなどで動かしているだけです。このウェブサイトのウェブサーバーもラズパイで動作しています。データはデータベースやNASなどに放り込んであります。

後日、外部HDDをつなげてNAS化する計画がありますが、それはおいおいの話なので、ストレージは無いものとして扱います。

３台目以降​

現在はありませんが、今後追加する可能性があるという事を考慮して構築しました。まだ扱いを考えていますが、クラウドのクラスタを自宅サーバのクラスタと混ぜてしまってもいいかなと考えているので、そういった可能性も考慮しつつ作ります。

オーケストレーションに何を使うのか​

クラスタ構築で重要なオーケストレーションシステムをどのように選んだのかという話です。

最も有名なオーケストレーションシステムの１つとして、k8s（Kubernetes）があると思います。Googleが設計したやつで、デファクトスタンダードの立ち位置にあるオーケストレーションシステムです。

k8sは技術トレンドですし、扱えたらなんかカッケー！とは思いますが、ここは現実的な事を考えましょう。まずk8sはプロダクション環境で使われることが多く、そこで使うことを想定した作りとなっています。実際Googleさんとか色々な企業は数千ノードをk8sとかで扱っているとか...

しかし私は一般家庭、プロダクション環境ではないのです。もちろん数千ノードなんて扱うことは有りません。現在稼働させてるサーバーをオンプレ・クラウド合わせてもいいとこ１０数個です。まず２０ノードを超えることは有りません。ということはそこまで高性能である必要も無ければ、プロダクション環境に対応できるだけのスケールアウト可能なシステムである必要もありません。

k8sが無いとすると次に挙がってくるオーケストレーションシステムといえば、Docker Swarmです。これはDocker-ce自体に統合されているものなので、追加のインストールなどは必要なく、Docker engineが使えれば利用可能です。

補足ですが、「Docker Swarm 終了」や「Docker Swarm サポート終了」といったサジェストが出てきて、その旨の記述をするブログが散見されますが、終わったのは、Docker-Swarm-Mode-As-A-Serviceです。Docker Swarmが完全に削除されたわけではなく、開発が終了したわけではないです。

Is Docker Swarm Mode EOL?

これ以外に利用されるオーケストレーションとしてGKEやECS、OpenShift、Rancherなどなど色々ありますが、他のは情報少なかったり、クラウドでやること想定されてたりなので、考えないこととします。後は単純に導入の手間とコストに見合わないです。

Kubernetes vs Docker Swarm​

少なくとも私が自宅サーバ群でクラスタ構築するにあたり、どちらが良いのか。実際に検証したわけではありませんが、ある記事を見つけたのでそちらの情報を参照します。

[和訳]Docker SwarmとKubernetesの比較 #docker - クリエーションライン株式会社

ここでは技術コンサルタントのJeff NickoloffとDockerが契約して、パフォーマンス評価をした結果の和訳が掲載されています。

中身はここでは解説しないので、簡単に呼んで頂くとして、重要な２つのパフォーマンス評価項目とその結果に注目します。

評価項目は「コンテナの起動にかかる時間」と「高負荷状態での応答性」です。後者のような状態になることは想定してないし、プロダクションでもないので最悪time outしてもいいかなぐらいの気持ちではいますが、良いに越したことは有りません。

結果だけ書くと、コンテナの起動にかかる時間はDocker Swarmの方が５倍早く、クラスターの負荷率がほぼ100％であったとき、Kubernetesはクラスターの形成状態が10％～100％に到達するまで、Docker Swarmの98倍の時間がかかっています。

できることの幅は間違いなくk8sの方が良いです。ただしk8sは純粋に複雑なんです。ちょっとしたことをやるためにも色々やる必要があります。大規模なサービスを厳格に動かす場合、おそらくk8sは向いているでしょうが、自宅でちょっとクラスタを動かすぐらいであれば、複雑でパフォーマンスが出ないk8sよりもDocker Swarmの方が良いという結論になりました。

これは私の結論なので、自分で作る場合はぜひ自分で選択してほしいですが、少なくとも少ないサーバー台数で、１人でシンプルに物事を進めたいのであれば、Docker Swarmの方が向いていると思います。

WebUI​

さて一人で管理していくとなると、WebUIがあったほうが楽ですし、やりやすいです。全部CUIでやれという意見も理解はしますが、人間なのでGUIに甘えたいです。

ここに関しては割とすぐに決まりました。というかだいぶ前からクラスタ構築のための構想は頭で練っていて、もともとこれでいいでしょって感じで決めていました。

選ばれたのはPortainerでした。

Container Management | Kubernetes GUI | Docker Swarm GUI | Portainer

Dockerの WebUIで一番有名なのが、Portainerだと思いますね。なぜこれを選んだか話もしたいんですが、いうほど掘れる話題無いです。軽量で簡単に動かせて手間かからないのが、Portainerぐらいで他のWebUI系はパッとしなかった。

クラスタ構築してどうなったのか​

まだ結果は出ていません。現状大きな問題はなく順調に動いており、快適といえば快適という感じになっています。その一方、クラスタである必要はないと思うこともあります。今後の課題です。

また、時間が足りなかったりメンテナンスにそこそこな時間を割かなくてはいけないという点から、一部コンテナはStackとしてデプロイできていないです。さらには新たな問題点も見つけているので、今後の課題が積み重なっています。色々勉強しながら、ベストプラクティスを模索していきたいと思います。

今後、ちょこちょことこういう問題あった！解決した！といった系の投稿を小出ししていこうと思います。

大きなアウトプットしようとすると、時間ばかりが経過して何日も投稿しない日が続くのでね...

最近ノートパソコンが異常に重いと思ってタスクマネージャー眺めていたら、Vmmemなるプロセスがメモリを食いつぶしていました。

Vmmemってなんぞやって事で物知りのGoogle先生に聞いてみたら、どうやらWindowsでLinux動かす為のWindows Subsystem for Linux 2（WSL2）のプロセスみたいなんですよ。

でもWindowsに普通に入ってるシステムがメモリを食いつぶすなんて問題、普通であれば考えにくいので、もう少し調べたら「WSL 2 consumes massive amounts of RAM and doesn't return it」というGitHub issueが出てきました。

WSL 2 consumes massive amounts of RAM and doesn’t return it · Issue #4166 · microsoft/WSL

ほっとくとメモリ食いつぶすよっていう問題です。予想に反して、普通に問題でした。

私はDocker for Desktopを使っていて、WSL2をアンインストールすれば問題解決！みたいにはならないので解決方法も探したら、下記のQiitaの記事が出てきました。

WSL2によるホストのメモリ枯渇を防ぐための暫定対処 - Qiita

記事内で示されている対処法は、メモリサイズを固定して利用するメモリ量に制限かけるというものです。

一応、下記にやり方を示しておきます。

%USERPROFILE%に.wslconfigを作成する。​

%USERPROFILE%は C:\User\ユーザー名のこと。分からなければ、WindowsキーとRキーを同時押しして %USERPROFILE%を実行して表示された場所がそこです。

そこに.qslconfigを作ったらメモ帳か何かで開いて下記を記述してください。

[wsl2]
    memory=2GB
    swap=0

memoryが利用可能なメモリ量、swapがスワップメモリ量です。swapはお好みで、memoryは自分のパソコンのメモリとご相談ください。

WindowsにDocker for Desktop入れたらメモリが食いつぶされて枯渇していると悩んでいる方は、以上の解決策を試してみて下さい。