ブックマークサービスQiNeel関連の記事や身の回りのよしなしごとをそこはかとなく書きつくっています。
前回に引き続きFluentdの話。今回はmultilineパーサーについてです。
このパーサーは正規表現で複数行を解析できるので、regexpの上位互換みたいなもんか。じゃあ何も考えずmultilineにしとけばええやん！と思っていたら・・・
なぜか最後の行が出力されない。
これでしばらく悩んだんですが、そもそも考えてみたら次の行頭が確定するまで現在の行全体が確定しないわけですからそりゃそうですね。
というわけで、しばらく入力がなかったら自動的に行を確定させるためにmultiline_flush_intervalを設定しましょう。
これも数日ハマったので、同じようなハマり方をしている人のために残しておきます。
クラウド全盛期の今、ロギングツールも各クラウドの機能に取って代わられている感がありますが、まだまだ現役なFluentdの話です。
Fluentdで収集したログをAWS S3にアップロードする場合、セキュリティー対策として（アカウントが乗っ取られたときにログを盗まれないように）アクセスキーやロールにWRITE権限しかつけないことがあります。
そのときは、out_s3プラグインの設定で以下の項目を無効にしましょう。
auto_create_bucket false check_bucket false check_object false
よく考えれば当たり前なのですが、諸々の存在チェックはS3側に読みに行くので、READ権限が必要です。これらを無効にしておかないと、エラーが出てログを収集できなくなります。
知り合いの子がこんなことを𝕏にポストしていました。
ローカルやと 8080 でちゃんと動くのに Docker にのせたら8080でリッスンしてないのなんで
— OJI (@OldBigBuddha) September 22, 2023
ローカルコンピューター内で作ってみたサーバーをDockerイメージ化すると、ちゃんとポートもマッピングしているのに外からアクセスできない。うん、Dockerのあるあるですね。
答えはコレ。
8080で動いてるプログラム、listenするhostが127.0.0.1やlocalhostだったりしませんか？
— seigo2016 (@seigo2018) September 22, 2023
0.0.0.0とかにすると動くかもです。
あーそうだそうだ。しょっちゅう忘れる。度々ハマるくせに、そもそもDockerイメージの設定ファイルを作る頻度自体がそこまで高くないので、次回作るときまでに諸々忘れているアレです。覚書としてここに残しておこう。
ちなみにChatGPTに聞いてみたところ
などをチャックするように言われましたが、0.0.0.0のことは指摘してくれませんでした。。。
オープンコーラのような、レシピがOSSになっているやつではありません。
簡単にまとめると
Terraformとは何か？については、今回の主題ではないので説明は省略します。知らなくてもこの記事の理解に支障はありません。
元々このTerraformはOSS（MPL）として提供されていたのですが、v1.6からライセンスが変更されました。
こちらによると、商用利用が一部制限され、Terraform作成元のHashiCorpと競合するような使い方をするとこの制限に引っかかりそうです。単にインフラ整備のために使うなら問題なさそうですね。
とはいえ、それでも今後のリスクがあるので、ライセンス変更前のバージョンからフォークしてOpenTFという新しいOSSが誕生しました。まあ最近よくある流れです。
ただ、このOpenTFという名前もHashiCorpの商標の侵害の可能性があるねということで新たな名前を募集したところ、OpenTofuが支持を集めたようです。OpenTofuのロゴ画像は一部黄色いので、どちらかというと揚げ豆腐なんでしょうか。
こちらによると、OpenTofuのいいところは
だそうです。なるほど確かに。
OSS企業がプロダクトのライセンスを商用利用を制限する方向に変更するのはここ数年よく見るパターンですが、このOpenTofuは名前に恥じない健康的なプロダクトになって欲しいものです。
ところで、さくらインターネットではたこ焼きのレシピをオープンソースとして公開しています。。。と思ったらライセンスが明記されていなかった。
7/13-15に、函館で開催されたJANOG50 Meetingに参加しました。久々のオフラインイベントです。JANOGに参加するのは今回が初めてで、会社のサービス宣伝と協業先を探すために参加してみました。
日本中のネットワーク関連企業が参加するカンファレンスで、インターネットが壊れたときは大抵この中のどこかが関連していると言っても過言ではないでしょう。
飛行機の都合で前泊＆後泊したので、実質7/12-16の一週間近い出張でした。
セキュリティ・キャンプ2022全国大会の選考が先日締め切られました。若いエンジニアのみなさんは未来のIT業界を背負うべく、こういう場所でしっかり学んでいってください。
ワシはもう若くないからええんじゃ。
さて、応募課題の中でちょっとおもしろい問題があったので考察してみましょう。
最近ハマったので記録を残しておきます。まあ例によって原因は単純なミスなんですが、例によって仰々しく書いてみます。。
図のようなネットワーク構成を想定してください。
この状態でA→Bにpingを飛ばすとちゃんと返事が返ってくるのに、逆方向（B→A）は返ってこないという摩訶不思議な現象が発生していました。
補足として、firewalldやufw等のファイヤーウォールは特に入れておらず、ルーティングテーブルも適切に設定されています。
なお、これはクイズではないので、唯一の正解にたどり着く情報が与えられているわけではありません。ただし、よく読めば「ここが怪しいんじゃない？」とわかるヒントは入れてあります。
ウェブサービスを作っていると、大きなファイルを認証付きでダウンロードさせたいけど、ダウンロード処理自体はアプリケーションサーバーを経由したくない場合があります。
それだけならアプリケーションサーバーから300系のリダイレクトを使えばいいんですが、クライアント側に実体のURLを知られたくない場合もあります。
例えばこんな状況。
以前、さくらのナレッジにいまさら聞けないNode.jsという記事を投稿しました。そこの「C10K問題の解決方法」という項目に
構成によっては、同じウェブサーバー内でApacheの前段にNGINXを配置するだけで負荷が下がることもあります。
と書いたところ「なんで？」という問い合わせがあったので、ちょっと解説します。
単純に考えるとNGINXのプロセスが走る分負荷が上がりそうな気がしますが、どういうからくりがあるのでしょうか。
ウェブサービスの経営陣には、新しい機能を開発してナンボという意識があるんじゃないでしょうか（※個人の感想です）。
まあ間違ってはいないんですよ。ウェブサービスは流行り廃りが激しく、世間で騒がれているサービスが翌年には閑古鳥が鳴いているという状態も珍しくありません。そんな中で生き残るには、便利な機能を次々と発表していくのも戦略です。
が、それと同じくらい、いやそれ以上に安定稼働させることが重要です。
今、仕事でウェブサービスの信頼性向上のためにいろいろやってます。
もう少し具体的に言うと、サービスの障害にいかに対応していくかという点です。タイトルに「ウェブサービスの」と書きましたが、別にウェブサービスに限った話ではありません。もっと一般的な（IT以外の分野にも）言えることですが、仕事柄ウェブサービスに多く関わっているのでこう表現します。
今回は、障害対応関連について現在取り組んでいることをツラツラと書いていきます。とは言っても、きちんと対応している人・組織にとっては別に目新しい内容は何もありません。目からウロコが落ちるようなことも多分ありません。
そのへんを踏まえてお読みください。