Dockerのログ出力先

Docker

ツイートしてて自己完結してしまったので記録のために。

前提と考察

  • Unixの世界では、stdout(標準出力)とstderr(標準エラー出力)という二つの出力チャンネルが標準として提供されている。
  • Twelve-Factor Appでは、アプリケーション側はログをイベントストリームとして出力し、実行環境側のほうで開発環境であればstdout、運用環境ならばfluentdなどに送って処理するべきとされている。
  • 近年[要出典]のログは、そもそも古臭いNCSA combinedアクセスログのような複雑怪奇な正規表現で取り出すようなテキストではなく、最初からJSONやLTSVなど構造化されたデータとして扱われるべきものである。
  • Dockerではコンテナのログをlogging driverという仕組みで処理し、stdoutとstderrを1行1エントリとしてloggin driverに送る。logging driverは標準出力なりFluentdなりAWS CloudWatch Logsなりに送る。
  • コンソールアプリでパイプ使う場合は、docker runに-aでstdoutだけ出力できるので、きちんとやる必要があれば出力はstdoutでパイプにつなぎ、ログはstderr経由でloggin driver送り、という使い分けができそう(未確認)

参考リンク

docs.docker.com

docs.docker.com

sourceでstdoutかstderrか取れる。

12factor.net

 

SORACOM Discovery 2019で登壇します(Serverless × IoT)

7/2のIoTカンファレンス「SORACOM Discovery 2019」で、サーバーレス×IoTで話します。

毎日の料理を楽しみにするためにIoTサービスを開発するクックパッドのkannyさん、 日本のサーバーレス推進の第一人者である吉田さんと一緒に、 なぜIoTで「サーバーレス」という考え方・手法が重要なのかを議論します。

f:id:nekoruri:20190518122355j:plain

"IoTを超えて"新しい世界を作りたい人、是非登録してお越しください！

 

www.discovery2019.soracom.jp

もう「サーバーレスだけどサーバあるじゃん」という話をしたくない

3年ぐらい同じ事を言い続けてるんだけど、そもそもサーバーレスという言葉の由来はソフトウェアアーキテクチャの話*1。

一つのタスクの実行期間を超えて、ファイルシステムやメモリ上の変数などサーバ固有のリソースに依存しないという、12 Factor Appから死ぬほど言われ続けている制約を満たすプログラミングモデルがサーバーレスの本質です。この制約に視点を置くとサーバーレスとしか言いようがない。

これを真面目にやろうとすると、キューやPub/Subによる非同期タスク（イベント駆動）が必要になってきます。これを整理したのがリアクティブシステム、わかりやすく関数という枠にはめたのがAWS LambdaをはじめとするFaaSです。

 

その一方で、これを満たしたソフトウェアは、AWSなりAzureなりGCPなりクラウド基盤側が勝手にサーバを増やしたり減らしたりできて、完全従量制にできたりメリットがたくさんでてきます。そういうゼロからスケールできるフルマネージドサービスの性質もサーバーレスと呼んでいます。

メリットが分かりやすいためクラウドベンダーが主張したいのはこちらの性質なんですが、でもこれって「所有せず利用する」というクラウドコンピューティング全体の流れの延長線上でしかないんですよね*2。

 

この設計と運用の二つの性質が混ざったのが現在の「サーバーレス」です。

というわけで、サーバーレスという単語に関しては、

　× サーバが無い
　○ プログラマがサーバを気にしない
　◎ プログラマがサーバを(設計上)気にしてはいけない＋(運用上)気にしない

と捉えるのが良いと思います。単純に「サーバが無い」というだけの解釈をしやすいのは事実なので、こういう理解をした方が楽しいよ、という話です。

日本語圏だとサーバと言えばサーバマシン（ハードウェア）を指すことがほとんどですが、英語Wikipedia見ると、サーバマシンよりも先にクライアント・サーバにおける提供側の"a computer program or a device"が先に来ますし、サーバの仮想化はVirtual ServerではなくVirtual Machineなんですよね。この英語と日本語でのニュアンスの違いが大きいのかなという気はします。

（追記 2023-12-17：正直名前として良くないとちょっぴり思ってはいます）

 

という話をまとめて書いてあるのでみんな買ってください😇

nekoruri.booth.pm

追記

(2019-05-11 10:00)

あまり記事の意図が伝わってない感じなので、脚注に書いていたことを本文に組み入れました。

こんな読まれると思っていなかったのでポイントをあまり気にせず書いていたのですが、伝えたいのは以下の2点です。

  • サーバーレス（Serverless）という単語にも理由があるし、サーバマシン、サーバプロセスへの依存排除というこの抽象化の世界は面白いので、そう単語自体を否定しないで欲しい。
  • 「こういう背景もあるのか」ということで一定の納得をしてもらい、この名前の話はとっととやめて、サーバーレス技術を使っていかに楽に楽しくシステムを作るかの話をしたい。

(2023-12-17 18:00)

薄い本へのリンク、もう4版がでているのでそちらに切り替えました。

*1:「Developers working in a distributed world are hard pressed to translate the things they’re doing into sets of servers.」とあるとおり、そもそも分散システムでものを作ってる人達はサーバとかいう考え方じゃないよね、という背景

*2:まあ実は一つめの話も、関数型プログラミングで言われるような、副作用排除、宣言型などのプログラミングの抽象化の流れの延長線上ではあります。

CROSS Study #2 で登壇してきた #cross_study

同人 技術書典 ssmjp同人部 めもおきば

技術書典でふらふらしていたら、当日のじゃない方の非公式アフターで喋ることになりました。

cross-party.connpass.com

 

パネルセッション前半の「技術書典6 非公式振り返り」で、ssmjp同人部からほかに2人もいるので、どちらかというと個人サークル「めもおきば」の人よりの立場で好き放題話させていただきました。

まあ詳しい内容は実況勢がたくさん居たのでTogetterを見ていただくとして。

togetter.com

話したこととその補足です。

書き手として

もともと「普段考えていることを整理してアウトプットする機会」と位置付けていることもあり、技術書典の一般の「売れ筋」であるような解説書とかとはちょっと違う路線で、クラウドやセキュリティをテーマに、全体像や技術トレンドから勝手に分析した考え方のような「読んだ人に新しい視点を提供できる本」というエモい路線を中心にひた走っています。

そこを評価していただいている方がいて本当にありがたいかぎりです。

引き続き、エモいポエムコラム本というジャンルを確立すべく頑張っていきます。
d.nekoruri.jp

ネタ出し

私の場合は、Workflowyにネタ帳の階層を作って放り込んでます。

workflowy.com

まあぶっちゃけツールは何でも良いですが、スマホロック解除して10秒ぐらいで入力できる状況で敷居を下げておくとよいです。24時間常時ブレスト状態。とにかくキーワードを放り込んでおいて、あとで考えます。

人によってはボイスメモとかもありかもですね。最近だとScrapboxが人気なのかな。

scrapbox.io

scrapbox.io

あと、Twitterとかに書いちゃって満足してしまったネタをあとからきちんとまとめたいときは、Twilogでキーワード検索してその日の自分の前後ツイートを読み返したりします。外部記憶と検索重要。

twilog.org

入稿について

頑張れば短い時間でも本は出ます。

とはいえ極道入稿は悪です。誰も幸せにしないので早めに頑張ろう。

湊川さんも言っていたとおり早割（今回のねこのしっぽ様だと最大20%割引）で出せばその分同じ予算で1.25倍刷れて完売リスクを減らせますし、告知などにも時間を割けます。

今回の締切ラッシュの中で、自分の中で1ページ1時間というペース配分がはっきり確立したのは良かったなと思っています。要するに100ページの本を書こうと思ったら100時間かかるので、毎日3時間掛けても一ヶ月かかるわけです。3日徹夜しても24ページにしかなりません。いいですねおれ。はやくフォルダとファイルとレポジトリを作るんだ。

読み側として

今回もたくさんフルスタックしました。ありがてえ。

とはいえ途中で力尽きてしまい、お昼ぐらいまでに回れたのは1/3ぐらいで、残りはかなり遅めの時間でしかも最後の方まで人が多かったため流す感じになってしまったので、あとで他の方の戦利品写真をみて入手し損ねた本がかなりあったのが残念なところです。

それでもかんたん後払いシステムの電子書籍サービスが始まったこともあり、電子書籍での頒布を続けているサークル様がたくさん増えたという印象を受けました。じつにありがてえ。

今回は使えるサークル全てかんたん後払いシステムで決済しました。入手した本のリストも取れるしDLCもあるしほぼ良いことづくめなのですが、その結果として人類は頒布価格を見なくなり書典破産の危機が迫っています。ありがてえ。

 

まあ、そんな感じで「めもおきば」「ssmjp同人部」ともども引き続きよろしくお願いします。

 

パスポートと公開鍵の議論ポイント

www.osstech.co.jp

 

この記事をきっかけに公開鍵暗号やPKIの在り方について議論が盛り上がってるので、ポイントになりそうな話をまとめてみます。

パスポートにおける公開鍵暗号のおさらい

上の記事を読んでください、という感じなのですが、ざっくりまとめると以下の仕組みです。

・ICカードにアクセスするためのBasic Access Control：いわゆるPINとかに相当します。「パスポート番号 + 生年月日 + パスポートの有効期限」とのことなので、要するにパスポートの顔写真のページを見た人ならば分かる情報です。

・データの電子署名を確認するPassive Authentication：Basic Access Controlを通ると、券面のデータ及び、そのハッシュ値：SOD(Security Obeject Document)、SODに対する電子署名が取得できます。この電子署名は、最終的に各国が運用する独自ルートCAである「CSCA：Country Signing CA」が最上位となっています。

・カードが複製されないことを保証するActive Authentication：パスポート上のICカードが一枚ずつ持つ鍵対（秘密鍵・公開鍵）を利用した電子署名によって、物理的な耐タンパー性とあわせてそのカードが複製されていないことを保証します。

今回は、このCSCAの公開鍵証明書の入手が問題となっています。

情報開示請求に対する外務省の回答

技術的に判断できる前半については、散々言われているとおり、公開鍵証明書の秘匿性そのものにパスポートの安全性を依存するようでは論外なので、この不開示理由ははっきり間違っていると断言できます。

後半は「共通認識」があるとのことなので、外務省の回答者がそう思うんならそうなんでしょう、外務省の回答者の中では。

外務省はCSCAの公開鍵証明書を公開すべきかどうか

それでは一つ戻って「外務省はCSCAの公開鍵証明書を公開すべきかどうか」というポイントに戻ると、技術的にはいくつかの議論ポイントがあるように思います。あえて擁護側の立場を取ってみます。

なお本筋である「情報公開制度への対応として公開するべきかどうか」の話はこの記事ではスコープ外とし、あくまで暗号学的観点からの思考実験です。

1. そもそも公開鍵証明書を公開する理由がない

公開鍵暗号アルゴリズムにおける公開鍵は、その利用相手にのみ公開鍵を届ければ良く、公開鍵という名前に反して「万人に公開される」必要はありません。これはPKIにおける公開鍵証明書に関しても同様で、ルートCAにより発行される下位の公開鍵証明書を検証する相手が入手できれば良いものです。

今回で言えば、外務省が手間を掛けて(後述)その公開鍵証明書を、想定された利用者(ここも後述)以外に公開する必要はありません。

2. 公開鍵証明書を安易に開示すると、公開鍵配送問題が発生する

公開鍵暗号を利用したPKIの信頼性は、その「トラストアンカー(信頼の起点)」となるルートCAの公開鍵証明書を、いかに安全に入手するかに依存しています。

安易にトラストアンカーを送ってしまうと、その途中で差し替えられてしまうなどの攻撃が考えられます。

CSCAの公開鍵証明書を入手しようと言うからにはそれを利用することが想定されるわけですが、情報開示請求という手続きの仕組みで、公開鍵証明書をセキュアに開示することが困難である、という判断はありえます。少なくとも「手間」は掛かるでしょう。

個人的には、国民からの請求に応じてトラストアンカーを開示するからには、それを正しく利用できるようにするために「請求した国民まで安全に届ける義務」が発生するのではないかと考えます。なので、もし情報公開制度により開示されるのであれば、そういった条件付けは必要かも知れません。

3. 公開鍵証明書を公開したほうが安全になるわけではない

暗号アルゴリズムの安全性は、そのアルゴリズムがたくさんの研究者の目に晒されることによって維持されていることはご存知の通りです。パスポートのICカードの場合は、利用しているRSAは既知のアルゴリズムであり、公開鍵そのものを公開したからといって「よりセキュアになる」わけではないです。

むしろ、今後新しいRSAへの攻撃手法が見つかった際に、公開鍵を知っていることで秘密鍵を入手しやすくなる可能性は否定できません。その場合に、脆弱になった古い鍵対を捨て（revoke）、対策されたアルゴリズムでCSCA鍵対を作り直して公開鍵を再配布する必要がありますが、利用している相手が限られている方が良い、とは言えます。

4. かといって公開鍵を秘匿した方が暗号学的に安全になるわけでもない

発端の記事にもある通り、CSCA公開鍵証明書そのものがもともと公開情報であるため、外務省が秘匿したからと言って、言うまでもなく暗号学的に安全になることはありません。

ここからは、一般論として別の可能性に触れておきます。

たとえば、鍵対（公開鍵と秘密鍵）を生成するときに、脆弱性のある実装を用いると公開鍵から秘密鍵を入手できます*1

ほかにも、RSAには脆弱な運用パターンがいくつもあります。 

とはいえ、さすがにそんな脆弱性のある実装でCSCAの鍵対を生成することはさすがに考えられない（うえに、さすがに他国から指摘されているだろう）と思われるので、この可能性は考えないことにしたいです。

いずれにせよ、現実的にCSCA公開鍵証明書は公開状態にあるため、直接は関係無い話です。おそらく暗号解読研究者の方々はとっくに入手できるルートから入手して攻撃を試みていることでしょう。 

マイナンバーカードとの違い

似たような話題として、同じブログの方によって話題となったマイナンバーカード上の公的個人認証に関する仕様公開がありました。

www.osstech.co.jp

マイナンバーカード（の公的個人認証）とパスポートの最大の違いは、そもそもが利活用を目的として設計されているはずの公的個人認証の公開鍵証明書に対して、パスポートは相手国や航空会社での利用のみが想定されているという部分です。

そもそもカジュアルにパスポートのICカード上の情報が認証として一般的に利用されるようになると、そこにはパスポート上の記載事項が載っています。顔写真のデジタルデータが取得できるほか、指紋や虹彩情報などの生体情報を記録することも今後考えられます。

www.mofa.go.jp

日本が導入したIC旅券に記録される生体情報は、ICAO（国際民間航空機関）が策定したIC旅券の国際標準において必須と規定されている顔画像・国籍・氏名・生年月日・旅券番号など旅券面の記載事項が記録されます。しかし、指紋は記録されません。なお、いくつかの国では、指紋を記録しており、また、虹彩情報を記録するための研究が進められています。

そういった前提がある以上、入出国や航空機搭乗のような場面でなく広く利活用されるべきものではないように思います。

《追記：2019-04-25 10:23》

……と思っていた時期もありましたが、以下の意見を見て考えを変えました。

この現状を鑑みると、暗号学的な多少のリスクよりも、民間がパスポートの暗号学的検証をできないことによる社会的なリスクの方が大きいように思います。

もともとGitHub SSH公開鍵などの過去を踏まえた上で、公開鍵だから必ずしも万人に公開することが良いわけでは無いというモチベーションからの記事でしたが、少なくともパスポートに関しては、政府としてCSCA公開鍵証明書を公開し活用を促進するべきでしょう。

個人の生体情報を含みうるデジタルデータが幅広く利活用されてしまうのには抵抗があるのですが、次世代のIC旅券とかでうまい落としどころがあると良いなと思います。とはいえ現状では犯罪対策の方が優先でしょうね。

《追記：2019-04-26 06:00》

公開鍵証明書を単に公開鍵と書いていたところを、公開鍵証明書と公開鍵にきちんと分けました。これにあわせ、PKIと公開鍵暗号の話を整理しました。

自分としては、公開鍵アルゴリズムとの関係が分かりやすいよう、ルートCAの自己署名証明書を公開鍵と簡略化したつもりだったのですが、かえって混乱を招いてしまったようです。申し訳ありません。

また最上位CAとルートCAなど表現がブレていた部分も直しました。

結論

まとめると、あくまで技術的には「公開鍵は一般に公開されても公開されなくても良い」というように思います。その上で、パスポートのCSCA公開鍵証明書に関しては公開が望ましい、というのが結論です。

このように、いくつかの議論ポイントがある以上、公開鍵暗号だから「公開」されるべきだろう、という直感的な発想で思考停止してしまうのはちょっともったいないな、と感じたので思考実験気味にまとめてみました。

 

まあでもそれはそれとして、外務省の中の人そこまで考えてないと思います。

ちなみに、パスポートの規格を決めるICAO(国際民間航空機関)は以下のようにおっしゃっています。

https://www.icao.int/security/mrtd/Lists/FAQ/FAQ.aspx

Can CSCA Certificates be published on a state’s website, or would this be a breach of ICAO standards?
（公開して良い？ICAO違反にならない？）


Certificates are public information and as such can be published on a website. This is not a breach of ICAO standards. 
（証明書は公開情報だから好きにして。違反じゃないよ）

 

 

暗号技術入門 第3版

暗号技術入門 第3版

 

 

*1:詳しくはこちら。何度見てもひどい……。

新刊オンライン頒布のお知らせ

技術書典 同人 めもおきば

技術書典6おつかれさまでした。

今回の新刊を含めて、Gumroadでのオンライン頒布を始めました。

めもおきば TechReport 2019.04 (￥500)

■ いまどきのコンピューティングについて考えよう

サーバーレスや、Kubernetesを中心とするクラウドネイティブの動きが盛んですが、そういった中で、開発のしやすさ、スケーラビリティ、セキュリティ、様々な観点で「きれいで実用的な設計」について、流行りのキーワードを入口に掘り下げてみた、というのが今回のテーマです。自分のアプリケーションを設計するときに、少しでも取り入れられるエッセンスがあればな、と思います。

以下のようなキーワードを取り上げました。

コンピューティング／Function as a Service／関数型プログラミングと副作用とスケーラビリティ／分散処理による並列と複製／イベント駆動とCQRSとGraphQL／認証と認可とマイクロサービス／エッジとクラウドとオンプレミス／No-Codeとエンドユーザコンピューティング

■ ストリーミング処理エンジンためしてみた

上の記事にも書いたとおり、非同期のストリーミング処理の重要性が大いに増えています。そんな中、PubSub + FaaSだけではつらい場面が増えてきているため、いわゆるデータ解析の文脈からいくつも生まれているストリーミング処理エンジンがあります。

その中で、特に最近注目しているものについて、Getting Startedレベルですがさわってみたのでその紹介です。

Apache Spark Streaming／Kafka Streams／Apache Flink

■ ねこるり用語辞典

「めもおきば」の中の人の発言に出てくる用語を解説します。Jargon file 的なやつ。一度やってみたかったんですよね、こういうの。

アウトプットしないのは知的な便秘／世の中のことはだいたいガチャで説明ができる／もったいない・ほんともったいない・超もったいない／○○したら負け／制約／抽象化戦争

Serverlessを支える技術 第3版 (￥1,000)

サーバーレス本第3版です。

第2版の2018年8月からの8ヶ月で、Azure Functions 2.0、AWS Lambdaの大幅バージョンアップなどがあったため、細かく現状にあわせて追加された機能の紹介も入れています。また、昨年あたりからのGraphQLの急速な普及に伴って、CQRSまわりやストリーミング処理の解説も増やしました。

さらに、2018年のKnativeの公開に始まり、技術書典6直前のGoogle Cloud Next 2019で発表されたGoogle Cloud Runを中心に、Kubernetes／Dockerの世界観とFaaSの世界観の関係について、個別に節を設けて解説しました。

ボリューム的には、本文が96ページから105ページになりました。

めもおきば TechReport 総集編 Vol.1 (￥1,000)

特に説明も不要かなあと思うのですが、昨年までの総集編です。

・TechReport 2015.12（コミックマーケット89）
　　Hardening 10 ValueChain 体験記
　　クラウド四方山話「サーバーレスアーキテクチャ」
　　2015 年振り返りと2016 年予想
・TechReport 2016.12（コミックマーケット91）
　　2016 年振り返りと2017 年予想
・TechReport 2017.08（コミックマーケット92）
　　SORACOM 買収からわかるIoT の未来
　　私もセキュリティ・キャンプに参加したい！
　　Bluetooth mesh ってどうよ
・TechReport 2017.12（コミックマーケット93）
　　Hardening 2017 Fes レポート
　　2017 年振り返りと2018 年予想
・TechReport 2018.04（技術書典4）
　　なろう！フルスタックエンジニア
　　htc vive 買ってみた
　　Microsoft MVP Global Summit 行ってきた
・TechReport 2018.10（技術書典5）
　　サーバーレスで実現するストリーム処理徹底活用術

めもおきば TechReport 2018.12 (￥200)

毎年冬コミでは、その年の振り返りと来年はやりそうな技術についてキーワードを紹介しています。2018年末は、以下のキーワードを取り上げました。

「2018 年予想」の振り返り／GraphQL によるAPI 設計手法の変化／非同期通信／ストリーム処理／ワイヤレスIoT／VR エコシステム／技術系同人誌／カラオケの原盤権／新しいプログラミング言語の普及