本を読む

• 標準入力の中に、変数で与えられる ascii 文字が何個あるかを計算したい - スタック・オーバーフロー

　GNU grep依存でよければ-o（マッチした部分を抜き出す）と-c（カウント）で行けるかと思ったら、うまくいかなかった。

$ sep=x
$ echo xabcxghi | grep -ocFe "$sep"
1

　GNU grepのmanを見ると、-cはマッチした行数をカウントするようだ。

-c, --count
       Suppress  normal output; instead print a count of matching lines
       for each input file.  With the -v,  --invert-match  option  (see
       below), count non-matching lines.

　というわけで-cをやめてwcに。

$ echo xabcxghi | grep -oFe "$sep" | wc -l
2

　人気コミックシリーズ「Q.E.D. iff」「C.M.B.」の最新刊が、今回も同時発売された。さらにその半月ぐらい前に、著者の初めての小説本「捕まえたもん勝ち！ 七夕菊乃の捜査報告書」が発売されている。

　「捕まえたもん勝ち！」の主人公の七夕菊乃（キック）が、今回の「Q.E.D. iff」「C.M.B.」の両方にゲスト出演しているので、3冊まとめてメモ。なお、話がつながっているわけではないので、どの順番で読んでもいいと思う。強いていえば、人物像がわかるという意味では、「捕まえたもん勝ち！」が最初か。

　以下、ネタバレに気をつけているつもりだけど、未読の方は念のためご注意を。

　「捕まえたもん勝ち！ 七夕菊乃の捜査報告書」は、元気印の女子高生が、地元アイドルと大学生を経て、キャリア官僚として警視庁の新人女性刑事に就任し、事件に遭遇する話だ。語り口としては「Q.E.D.」シリーズで水原さん視点になったエピソードのような感じで、筆者の漫画の絵を想像しながら読んだ。とはいえ、苦学生だし、塔馬君がいないし、キャリア官僚だしで、まるきりのおバカキャラではない感じ。

　まるきり1つの事件でも、短編連作でもなく、いくつかの事件によって主人公が成長していく姿を長編として描いている。警察での事件は、誰が犯人だという推理小説というより、足で証拠を集める捜査や警察内のしがらみなどの警察小説っぽい要素が多め。まあ、そのへんのギャップも伏線のうちなんだけど。

　結末は、推理としてではなくストーリー構成としてなんとなく想像はついたけど、それに向けてあのことが推理としての伏線になっていたとは、というのはヤラれた感じだった。

　「Q.E.D. iff」は、「イーブン」と「不完全な密室」の2編を収録している。「イーブン」は、大学生の男女関係と盗難事件がからまった事件だ。塔馬君は、どことどこがつながって、誰が何を考えているかを整理して推理する。

　「不思議な密室」は、「捕まえたもん勝ち！」の七夕菊乃がゲストで登場する話だ。これも、1人の人物が元でこんがらがってしまった複数の事件を、塔馬君が整理して推理し、真相を暴く。わかりやすそうな要素が一番の罠というたくらみ。七夕菊乃はここでは、エリート官僚である面や、警察組織の一員である面を中心に見せていて、どちらかというと大人しめ。

　「C.M.B.」は、「動く岩」「いつかの文学全集」「ツノゼミ」「見えない射手」の4編を収録している。

　「動く岩」は、仲間たちが行った宿で、動く岩の伝説によって死人が出る話。あのシーンの絵面が伏線だったとは。

　「いつかの文学全集」は、夫を亡くした主婦がハワイで事件に巻き込まれる話。文学全集を読むことがやりたいことだったけど、さて……という物語。

　「ツノゼミ」は、コンサルティング会社での昇進競争を軸に、誰が誰を騙しているのかという、伏線だらけのトリッキーな話。いきなり一人の男の嫌味な語りで始まるのだけど、最後まで読んで、あれはそういう意味だったのかと。

　「見えない射手」は、七夕菊乃がゲストで登場する話だ。劇団の舞台で起きた殺人事件を、追う。七夕菊乃はここでは、地元アイドル出身で、身体能力が高く、ちょっと天然なところがあるという面を中心に、派手に暴れている。

　ヒラリー・クリントン vs. ドナルド・トランプの大統領選は、政策論争を放り出して、非難合戦のプロレスに終始しているとは多くの人が言っているところだ。本書で町山氏が書いているところによると、トランプはかつてアメリカンプロレス団体WWEのビンス・マクマホンとリングで対決したことがあり（といっても直接リングに上がったわけではなく代理レスラー対決）、そのコンセプトを真似てキャラを作っているのだそうな。それをもって、米全土にいるWWEが好きでエリートを嫌う層（いわく「ジャイアン」）が現在の支持者の中心になっているんだとか。

　というあたりを語った渋谷でのトークショーの内容を文章にまとめて加筆修正した電子書籍だ。

　そのほか、共和党と民主党の立場が1960年代にねじれた歴史や、トランプ支持者に多いと言われる白人ブルーカラー層が選挙のサイレントマジョリティとなってきた流れ、そしてその層がどんどん減っている（それがその層が過激な主張に飛びつく理由とも言われてるけど）これからなどが語られている。

　評判いいらしいと聞いていたけど、アニメ化したのをきっかけに読んでみた。まずは1巻を読んだら、いま最新刊の10巻まで一気に読んでしまった。

　織田信長を中心に戦国の人達をデフォルメしてキャラを強調し、かわいいキャラで、4コマギャグまんがにしている。ただし、4コマ完結ではなくて、どんどんストーリーが続いていくタイプの4コマだ。印象的かつ盛りすぎないキャラが、けっこう史実や最新の説をふまえたストーリと組み合わさって、物語として読ませる。たとえば、信長が下戸で甘党という設定が何度もネタになっているけど、これはそういう説をふまえてのことらしい（諸説あるらしいけど）。

　主人公が子供っぽい天才女忍者で、全体のトーンは朗らかだし、各人物は良いところを描く方針になっている。たとえば、松永弾正はチョイワルおやじ武将だし、斎藤龍興や朝倉義景は愚かなんだか賢いんだかわからない武将として登場する。とはいえ、比叡山焼き討ちとかのヘビーなエピソードも描き込まれている。

　というわけで、自分の中では「風雲児たち」と同じカテゴリーに入った（異論は認める）。

　「下町ロケット」の池井戸潤が7月に出した新作「陸王」は、埼玉県行田市の小さな足袋会社が、大きなスポーツ用品会社と戦う痛快ストーリーの小説だ。

　行田市といっても知名度低いと思うけど、「のぼうの城」の忍城のあるところだ。「のぼうの城」も、小が大を翻弄する話だった。ロッキーやゴリアテvs.ダビデをはじめ、古今東西、こういう話は痛快ストーリーの定番だよね。

　この話では、足袋会社が発売する新技術のランニングシューズを大メーカーが潰しにきて、戦う。ただ「下町ロケット」などと比べると主人公である会社社長の個性が薄め。どちらかというと、故障から復帰しようとするランナーが主人公っぽい。さらに個性が強いのが、一度会社を潰して嫌味なキャラになったけど心の奥では熱いものを持った飯山と、現場第一で経営なんてどこ吹く風というカリスマシューフィッターの村野の、50代のオッサン2人だ。いい味出してるなあ。

　レッドハットのイベント「Red Hat Forum 2016」で、Publickeyの新野さんをモデレーターにしてパネリストに前佛さんなどが並んだ、コンテナ／Dockerをテーマにしたパネルディスカッションがありました。

　だいたいメモったので、ほぼそのままブログに残しておきます。

メンバー

• Publickey 新野淳一氏

パネリスト：

• Ian Lewis氏 グーグル株式会社 Google Cloud Platform Developer
• 小俣裕一氏 株式会社ディー・エヌ・エー SWET Gr, Quality Management Dept, System Management Unit Software Engineer in Test
• 前佛雅人氏 さくらインターネット株式会社 技術本部ミドルウェアグループ
• 木村貴由氏 レッドハット株式会社 カスタマーエクスペリエンス＆エンゲージメント アプリケーションプラットフォームサポート シニアソフトウェアメンテナンスエンジニア

自己紹介

• 新野：コンテナにどんなメリットがあるか
• それを引き出すのにどんなプラットフォーム？
• などついて話しあう

• まず自己紹介

• Ian：Google Cloud PlatformのDeveloper Relation
• 開発者の支援、コミュニティの支援、OSS開発を中心に

• 小俣：10月から部署名がかわった
• SWET（Software Engineering Test）
• クラウドのユーザー側として

• 前佛：テクノロジーエバンジェリスト
• 弊社の技術を紹介する
• コンテナは前職つながり。Dockerのトレーナー
• 趣味でDokerのドキュメント翻訳

• 木村：RHでOpenShiftのサポート
• もうかなり多くのお客様が使っている（アメリカ）
• 調査の手伝いなど

コンテナのメリットは

• 新野：コンテナとは何か。木村さん
• 仮想化とどう違うか

• 木村：仮想化とよく対比されるが
• 共通する点としては
• どちらも隔離されたランタイムを提供
• 大きく違うのは
• コンテナはLinuxのOSの機能で隔離。なのでLinuxのみ
• 仮想化はほかのOSも

• 新野：いちばん違うのはハイパーバイザーの有無？

• 木村：ハイパーバイザーとゲストOS
• 制限はあるが
• リソース効率がよい、起動停止が速い、軽量
• ストレスを感じなくなるレベルで軽量

• 普及したのにもう一つ理由
• Dockerの登場
• イメージフォーマットとイメージ共有基盤
• セットアップ済みのコンテナイメージが利用できる
• →インストールという概念がなくなる

• Ian：JenkinsがJavaで作られている。実行にJavaランタイムが必要
• DockerのJenkinsイメージならランタイムが入っている

• 新野：利点2つ。軽量、イメージ
• 前佛さん、本当ですか？

• 前佛：本当ですw
• 仮想サーバーを立ち上げる必要がない

• 新野：小俣さん。実際に使ってますか？
• 何がいいか

• 小俣：テスト。サーバーサイド。
• 開発者視点では、開発ツールチェーンを入れる必要がない
• RailsではRuby、Rails、ライブラリ、DB…
• テストは多くのターゲット
• MySQLだったりPostgreSQLだったり
• OSのバリエーションも
• いちいちインストールするのは大変
• DBのインストールの学習コストもかかる

• 新野：テスト用のデータはDockerで？

• 小俣：データは入っていない
• 外からロード

• 新野：ほかのメリット

• 小俣：スマートフォンのテストファーム
• 実機を数十台、リモートで
• バックエンドOSの違いなど

• Dockerを使わなくても設定は自動化するが
• その準備で5〜10倍のコスト削減

• 新野：ここまで、Dockerイメージがポータブルという話
• 軽量という点は？

• 小俣：私はフロントのサービスで使っていないので、それほど軽量であるメリットを感じていない

• 木村：軽量化のメリットは、待たなくていいことと、数の積み上げ
• 1000台となると、オーバーヘッドが積み上がる

• 新野：密度もいわれる

• 木村：集約率は1.x倍ぐらい上がる

コンテナで困ること

• 新野：木村さんは話がうますぎる気がするw
• コンテナで困っているお客さんの話は？

• 木村：ある
• コンテナに持っていくときに
• カーネルに特定のパラメータを設定するもの
• 商用ソフトはインストールの要件が決まっていたり

• 新野：小俣さんは困ったこと

• 小俣：違う使いかたで
• ゲームのプラットフォームでコンテナを使うか議論したことがある
• 不利ということになった

• 新野：その話を続けて
• 本番で使うかどうか
• DeNAで本番で使っていない背景

• 小俣：オンプレミスのサーバーを4千台（2千台×2重）
• AWSのサーバーも
• 2種類対応
• 新しいプラットフォームをもちこむ学習コスト、調査コスト、運用コストの不安
• VMとは分離方式が違う。自信が持てない

• もう1つの理由
• コンテナを使ってもVMを使っても、運用に人員が必要
• 監視にも人が必要
• データストア、ログ、セキュリティスキャンなど
• 新規人材が不足。新しい学習コストはかけられない
• GAEではそこから解放される

• 新野：Ianさん、どう思うか

• Ian：コンテナー化には学習コスト、コンテナ化コスト、デプロイを考えるのが必要
• スケールも楽になるプラットフォームがいいんじゃないかということだと思う
• 実際には、その間のようなサービスがいいんじゃないか

• 新野：コンテナでGAEみたいに使えるもの

• 前佛さん。運用コストが変わらないというのは

• 前佛：はい、そうです
• 個人的な意見
• Dockerの学習コスト
• 開発が速い
• 日々バージョンアップ
• 3か月に一度、仕様が変わる

• 木村：最近でいうと
• Docker 1.1で下回りがかわった
• Docker 1.12でオーケストレーションが入った

• 前佛：そういうのを追いながらになる

• 新野：どこから情報

• 前佛：じつは最近はまっている
• 昔はDockerのブログで追えた
• 最近は技術的なことが載らなくなった
• DockerのSlideShareに技術系資料

• Docker captainという制度がはじまった
• ユーザーが情報を出す制度
• そのへんはDockerのTwitterアカウントで

さくらのサービス「Arkas」

• 新野：次の話題
• 中間的なコンテナプラットフォームの話
• ベンダーさんの声。前佛さん、Arkasについて

• 前佛：Arkasというコンテナサービス
• 何でもできるものではない
• いまβサービス
• やりたいことはサーバーフロントエンドのコンテナを簡単にデプロイ
• 本番環境にはサーバーやネットワークを用意しなくちゃならない
• コンテナを実行してスケールできる

• 新野：フロントエンドというのはWebサーバー向け？

• 前佛：いまのところは

• 新野：そこを選んだ理由

• 前佛：コンテナのメリットのある部分
• インフラの部分は生臭い。冗長性、可用性
• Arkuasはさくらのクラウド + CoreOS、オーケストレータ/スケジューラ
• 可用性を求めると現場は大変だろうなと

オーケストレータ/スケジューラとは

• 新野：オーケストレータ/スケジューラとは？
• Mesos、Marathon、Zookeeper、何？

• 前佛：よしなに処理してくれる
• Mesos。コンテナだけではなく、10台のサーバーにジョブを投げてよしなに実行してくれるツール
• その上でジョブを動かすMarathon
• 冗長性のためにZookeeper

• オーケストレータ/スケジューラというのは各社定義が違う
• 私の定義は
• あるべき状態を維持してくれるもの

• 新野：落ちても再起動してくれる？

• 前佛：はい

• 新野：木村さんの定義は違う？

• 木村：オーケストラには指揮者
• その指揮者がオーケストレータ

• 新野：Ianさん

• Ian：「管理」に近い意味
• ノードを追加、コンテナを削除など、いろいろあった
• オーケストレータがおまかせで、あるべき状態に

• 新野：前佛さんに戻して
• いままでアプリを手で起動していた
• コンテナだと200個立ち上げる
• その自動化レイヤー？

• 前佛：近いと思います

• 新野：なぜArkasではCoreOSやMesosを選んだか

• 前佛：その当時あった技術で、使いやすそうだったから
• Mesosはコンテナ専用ではなく、複数のサーバーで分散処理するもの
• コンテナに対応したので
• 2年前

• 新野：今だったら違う判断？

• 前佛：はい
• そのときどきの技術
• とはいえ、裏側は知らなくても使っていただけるサービスにしたい

Googleのコンテナ利用

• 新野：Googleではすべてコンテナ

• Ian：本番でコンテナを使っている
• 10年ぐらい
• オーケストレーションのシステムも社内で作った

• 新野：Dockerは何年前ぐらい

• 木村：3年ぐらい

• Ian：コンテナの技術が、Linuxカーネルに入った
• 知っている人は使えた
• 使いやすくはなかった
• コンテナという機能ではなく、いろいろな機能の組合せで実現
• cgroup、namespace…
• Dockerが出て、つかいやすいものが出た
• Googleは自分たちでかなり前から
• オーケストレーションをどうするか、社内で考えた
• 自分たち用のシステムを作った
• ベストプラクティスがない時代から
• やり直したい部分、Dockerを使うとどうなるか、と考えて、経験をもとにほかの人が使えるシステムとして、Kubernetesを作った

• Kubernetesはコンテナのオーケストレーション
• 複数クラウド対応のロードバランサーなども
• 　他社のクラウドもGoogleにも、オンプレミスでも
• オープンソースなのでどこでも

• コンテナオーケストレーション図解
• Webアプリをデプロイするとき
• それをAPIで伝える
• Kubernetesが自分の持っているリソースのうち空いているところにデプロイしてくれる
• デプロイした後に、リソースを食っているとき、リソースを分散してくれる

• 新野：KubernetesをもとにGoogle Container Engineも動いている？

• Ian：Kubernetesで簡単に立ち上げるプラットフォーム
• APIか画面からKubernetesのクラスタを作れる

Red Hatのコンテナプラットフォーム

• 新野：RHのコンテナプラットフォーム

• 木村：Linuxカーネルの機能をサポート
• 「本番環境では不安がぬぐえない」正しい
• Dockerはセキュリティリスクがある
• それを解消するためにRHが製品化
• 周辺ツールが圧倒的に足りない
• 運用のためのプラットフォーム
• 穴をうめてあげる

• 足りないところ
• Kubernetesで
• オーケストレーションとスケジューリングはできる
• UIは使いやすくない
• ネットワークもプラグイン機能まで
• レジストリ
• イメージのビルド
• そこにいっぱい機能を追加したのがOpenShift

• 新野：OpenShiftはソフトウェア？ サービス？

• 木村：OSS。
• サービスもあるが、想定ユーザーはちょっと違い、社内にコンテナプラットフォームを持ちたいというお客様
• コンテナの特性が役立つのは開発。が、それをパブリッククラウドでやると課金が大きい
• 基本的には製品として提供

現状

• 新野：小俣さん。ユーザーとしてどう聞いたか

• 小俣：GUIがあるのかと。勉強不足だった

• 新野：欲しい方向に進化している？

• 小俣：していると思う

• 新野：それを受けてIanさんと前佛さんに
• Ianさん、GAEとコンテナ。そういう方向に？

• Ian：できるだけラフに使えるように
• GAEもあるが、GKEも進化させる

• 新野：OpenShiftとKubernetesは同じようなコンポーネント
• Arkuasは違う構成だが、目指すところは同じ？

• 前佛：どうだろう
• ノリではじめたところがあってw
• とりあえずコンテナを動かしたいこと

• Kubernetesはサポートがついた？

• 木村：メジャーバージョンが出てから7年

• 前佛：いまの機能は、とりあえず動かすなら充分
• 長期に使うには、そちらでいいんじゃないですかw

• 新野：共通していること。周辺が充実して手間なく使えるように

• 木村：ツールやノウハウが浸透していない
• OpenShiftはとりあえずえず機能はそろった
• まだ埋められる役割はあるが

従来型のアプリもコンテナに？

• 新野：既存のRHELは金融などレガシーなアプリも動いている
• それらもコンテナに乗っていく？

• 木村：はい
• 実際にサポートしているのは、銀行やキャリアなどが多い
• 絶対に落とせないシステム
• いまのトレンドは落ちても障害にならないように作る
• リカバリ、影響範囲コントロール
• マイクロサービス
• それとコンテナが相性がいい

• 新野：その場合、既存のサービスそのままではなく、作りかえる？

• 木村：モノリシックなアプリを、複雑でなければ、不可能ではない
• が、業務アプリは複雑。コンテナ化が難しい
• ポータブルなコンテナにするには設定をコンテナの外に
• 旧来のアプリはそんな機構ないので改修が必要

• 新野：前佛さん、Dockerに詳しい人として
• 既存アプリをDockerにのせてうれしい？

• 前佛：うれしい場合はある
• 開発
• テストが速い、高速なデプロイ
• 運用は死ぬw
• 密度が上がる部分
• 仮想化のときといっしょ。仮想化は監視ツールが整った
• つめこみすぎると、いったん障害が起きると被害が大きい
• 監視が必要

• コンテナのメリットをいかすには運用フローがかわる
• 物理・仮想化・クラウドは運用が同じだった
• コンテナでは変わる
• 監視ポイントも変わる

• Ian：まさにそのとおりだと思う
• 仮想マシンで管理していた人が、コンテナになると、VMもコンテナも管理
• それが監視が大変

• 前佛：だからKubernetesやOpenShiftが便利ということですねw

• 新野：それって本当にそういう方向に進化している？

• 前佛：そうでないと回らなくなる

• 新野：そういう危機意識がある人がコントリビュートすると

• 前佛：貢献もそうだが
• まずは使ってみること
• 頭で考えてもわからない
• 何がいいか悪いか、自分の言葉で説明できるように

今後は？

• 新野：最後に、今後、どう変わっていくか、変わってほしいか

• Ian：2つ
• 1つは、コンテナは、RHやGoogleが基礎的な部分を必死で作ってきた時代だった
• たとえると、Linuxを使えるようにすること
• その上にディストリビューションができた
• その上にいろいろなアプリケーション、エコシステム
• いまのコンテナは基礎の部分ができつつ、若干ディストリビューションができつつあるところ
• それがどんどん進化していくと思う

• あとは、低レイヤー
• これまでDocker。コンテナの標準化がこれから
• Open Container。
• イメージフォーマット、実行方法などを定義
• これから

• 小俣：まだ足りない部分があると思っていた
• RHがいうように進化してきている
• 開発したオープンソースの最新版を開発者がコンテナで提供するようになると助かる
• あと、個人的に
• 子供の教育をRaspberry Piなどの小さいデバイスで、RubyやNode
• 開発用のツールチェーンのインストールや差異がトラブルになる
• それをDockerで

• 前佛：個人的な期待としては
• コンテナで開発や運用が、本来したかった方向になるかなと
• これまで80年代の手法をひきずってきた
• コンテナの軽さで、業務フローまで変えられるのではないか

• 木村：3点
• 1。いまマイクロサービスにシフト
• 影響範囲を限定して開発
• これにコンテナがマッチ
• 2。環境構築の容易性
• Jenkins、MySQL、アプリケーションサーバー
• イメージ化されて
• 新しい開発者にもすぐ環境を手渡せる
• 開発が高速化されることが期待
• 3. DevOpsを手助けするツール
• 開発したものをそのままテスト環境や本番環境に
• それをプラットフォームが吸収してくれる
• 開発のサイクルを速く

• 新野：リアリティのある話を聞けた
• みなさんの参考になるのではないかと思う