fluentdでGoogle Compute Engineのログを一つに集約する | A-TAK
前回、Google Compute EngineでオートスケールするWebサーバーを構築しましたが、ログが各サーバーに分散したり、インスタンスが終了するとログも消えるので、Fluentdでログを一カ所に集めることにしました。 オートスケールは便利だがどこに接続しているかわからん前回の記事↓ 前回、GCE上に負荷に応じて自動でサーバーが勝手にできあがっては消えていくオートスケールのWordPressサーバーを構築しましたが、問題が起きたときのログを確認するのが非常に面倒だと気づきました。 MarsEditからWordPressに画像投稿すると、絶対に投稿に失敗するという問題が起きていまして(現在は解決)、ただWebサーバーが複数あるので、一体どこのサーバーにエラーログが残っているかわからない。片っ端から見るのは面倒…。 Fluentdというのが流行 最初はsyslogでログを転送して一カ所に
Google Container Engineに移行した その4 | A-TAK
前回まででNginxとphp-fpmをビルドしてGoogleのリポジトリにアップしました。今回はGoogle Container Engine(GKE)のクラスタを作成します。 前回の記事Google Container Engineに移行した その3 | A-tak-dot-com その前にDBとNFSサーバを作る 今回、DB(MariaDB)とWordPressのファイルを置くNFSサーバーはコンテナではなく普通のVMとして立ち上げる想定にしています。作成方法は過去記事を参考にしてください。 お名前．ｃｏｍ VPSからGoogle Compute Engineにサーバー移行した その2 | A-tak-dot-com これを先につくっておかないとコンテナがNFSをマウントできなくてコンテナ起動に失敗するので先に用意しておく必要があります。 クラスタを作成するクラスタを作成します。 [b
Google Container Engineに移行した その5 オートスケール | A-TAK
Google Container Engineに移行した その5 オートスケール※Amazonのアソシエイトとして、A-TAK.COMは適格販売により収入を得ています ※本サイトではその他アフィリエイトも利用しております。 前回までのGKE 前回はGoogle Container Engine(GKE)でnginx + PHP-FPMでWordPressのコンテナを作成しました。 Google Container Engineに移行した その4 | A-tak-dot-com 今回は、負荷が上がってきたときに自動でポッドを追加し、さらにノード(VM)も増やしていく設定を行います。 GKEのオートスケールの動き 以下のような動きになる。 PodのCPU使用率が上がるKubernetesのオートスケール機構によりPodのレプリカが作成され複数のPodができるノードの負荷が上がるとGCEのオート
「WebAPI 設計のベストプラクティス」に対する所感 - Qiita
「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Payforward
