自分自身の情報収集スタイルを定期的に見直そう /「ソフトウェアエンジニアの情報収集について」を読んだ

本

@nikuyoshi に献本を頂き，去年「技術書典4」と「技術書典5」で頒布された「ソフトウェアエンジニアの情報収集について（改訂版）」を読んだ．本書は約50ページと薄く，すぐに読むことができる．重要なのは本書を読み終えることではなく「自分自身の情報収集スタイルを定期的に見直すこと」だと思っていて，むしろ読み終えてからがスタートと言える．厳選されたサイトの紹介以外に，情報収集のテクニックも紹介されている．

nikuyoshi.booth.pm

はじめに
- 本書における情報収集の分類について
- この本で説明する内容
- この本で説明しない内容
- 意見と質問
依頼事項を満たすための情報収集について
- 検索の効率化
- よい質問の仕方
- 0から技術を学ぶ時に行っていること
日々の情報収集について
- 社外の技術者と交流する
- Podcast
- メール
- Twitter
- 日常会話
役に立つ豆知識
- 原因調査で使えるコマンド、ツールなど
- 実践例題集

情報収集の分類

本書は「情報収集」を以下の2種類に分類している．本書に書いてある通り，シチュエーションによって情報収集のスタイルは異なり，うまく言語化されていると感じた．

依頼事項を満たすための情報収集
日々の情報収集

本書にも「依頼事項を満たすための情報収集」の中に「書籍から学ぶ」とある通り，僕自身も技術書を積極的に読んでいる．個人的に電子書籍は得意ではなく，物理本を読むことが多く，読みながら付箋を貼るスタイルをずっと貫いている．付箋は「自分だけの検索インデックス」と言い換えることもできて「依頼事項を満たす」ときに便利なリファレンス本は常に机の上に置いてある．具体的には「実践ハイパフォーマンス MySQL」や「Web API: The Good Parts」など．

実践ハイパフォーマンスMySQL 第3版

作者: Baron Schwartz,Peter Zaitsev,Vadim Tkachenko,菊池研自,株式会社クイープ
出版社/メーカー: オライリージャパン
発売日: 2013/11/25
メディア: 大型本
この商品を含むブログ (7件) を見る

Web API: The Good Parts

作者: 水野貴明
出版社/メーカー: オライリージャパン
発売日: 2014/11/21
メディア: 大型本
この商品を含むブログ (9件) を見る

質問をする / 技術者と交流をする

本書では「情報収集」の中に「質問をする」や「技術者と交流をする」など，ソフトスキルに分類されるスタイルも紹介されていて素晴らしかった．個人的には「質問をする」よりも「雑談をする」という表現を使うことが多く，コミュニケーションを通じて「質問 → 回答」という定型的な情報以外にも「少し関連する情報」も得られる可能性がある．積極的に質問（雑談）をするべきだし，組織的にも質問（雑談）を常にできるような文化を根付かせて置く必要がある．最近モブプログラミングが流行っている背景も関連していると思う．さらに質問（雑談）をすると「オートクライン」と引き起こすことができるのもメリットと言える．詳しくは以下の記事にまとめてある．あと質問をする目安として「Google : The 15 Minute Rule」が挙げられていた．

kakakakakku.hatenablog.com

The Five Orders of Ignorance

本書を読んで「無知にはレベルがある」ことを発表した論文「The Five Orders of Ignorance」があることを知った．具体的には「0 OI / 1 OI / 2 OI / 3 OI / 4 OI / 5 OI」となり，計5レベルある．プログラミング講師をしていたときに「プログラミング初心者に検索して！と言っても検索キーワードすら考えることができず，もっと具体的にサポートすると学習効率が高まる」という経験があり，まさに論文と同じ状況と言える．知れて良かった！

dl.acm.org

アウトプットも「情報収集」と言えるのでは？

本書は「情報収集」をテーマにしているため，主に「インプット」にフォーカスした内容になっている．個人的に補足をするならば「アウトプット」も情報収集に繋がると思う．アウトプットをする過程でインプットを整理することもできるし，さらにアウトプットを読んだ人からフィードバックを頂くことで，もう1度学び直すことができる．さらにアウトプットを必要としている人は他人だけではなく「過去の自分」や「未来の自分」だったりもする．うまく学習サイクルを回すためには「インプットとアウトプットのバランス」が重要だと思う．

まとめ

「ソフトウェアエンジニアの情報収集について（改訂版）」を読んだ
- 献本あざます！
単なる情報収集スタイルの紹介ではなく「質問をする」などソフトスキルに分類されるスタイルも紹介されていた
個人的には「アウトプット」も情報収集に繋がると思う

nikuyoshi.booth.pm

著者 @nikuyoshi の記事！

nikuyoshi.hatenablog.com

よりアカデミックに「学び」を知るなら「エンジニアの知的生産術」を読むと良さそう．

kakakakakku.hatenablog.com

2019-02-09

htmllint で Inline Configurations を使って Lint ルールをカスタマイズする

HTML

最近も HTML を書く機会が多く，HTML を実装するときには「htmllint」と CircleCI を組み合わせて Lint を実行している．「htmllint」の紹介記事は前に書いてある．

kakakakakku.hatenablog.com

the i tag is banned

Font Awesome を使って <i class="far fa-smile-wink"></i> のように絵文字を HTML に追加したら，エラーになった．「htmllint」の Lint ルールの中に tag-bans がある．今回は Font Awesome を使いたく，i タグを tag-bans から除外する必要があった．

the i tag is banned

i タグ以外だと，b タグと style タグも同じ Lint ルールでエラーになる．

the b tag is banned
the style tag is banned

理由としては htmllint init コマンドで生成されるデフォルトの .htmllintrc だと，以下のように i タグは禁止されている．

{
    （中略）
    "tag-bans": [
        "style",
        "b",
        "i"
    ],
    （中略）
}

よって .htmllintrc を修正すれば，エラーを無くすことができる．

{
    （中略）
    "tag-bans": [
        "style",
        "b"
    ],
    （中略）
}

Inline Configurations

.htmllintrc 以外に Lint ルールをカスタマイズする方法があるのかを調べるために Wiki を読んだところ，.htmllintrc に設定をする「Global Options」だけでなく，HTML に直接アノテーションを書く「Inline Configurations」もサポートされていた．

「Inline Configurations」を使うと，HTML ごとに設定を変更できるため柔軟性がある．具体的には以下のように HTML のコメント形式でアノテーションを書くことで i タグのエラーを無くすことができる．

<!DOCTYPE html>
<!-- htmllint tag-bans="['style','b']" -->
<html>
  <head>

もし tag-bans の Lint ルールを全て無効化する場合は，以下のようにアノテーションを書くこともできる．

<!DOCTYPE html>
<!-- htmllint tag-bans="false" -->
<html>
  <head>

まとめ

「htmllint」で Lint ルールをカスタマイズする方法は「Global Options」と「Inline Configurations」がある
HTML に直接アノテーションを書く「Inline Configurations」を使うと，HTML ごとに設定を変更できるため柔軟性がある

2019-02-06

JetBrains プロダクトを管理するプロダクト「JetBrains Toolbox App」

JetBrains RubyMine

「JetBrains IntelliJ IDEA」や「JetBrains RubyMine」など，JetBrains プロダクトを使って開発をしている人は多いと思うけど，個人的にオススメな「JetBrains Toolbox App」の話をすると，あまり知られていなく，まだまだ普及していなさそうに感じる．「JetBrains Toolbox App」とは，簡単に言うと「JetBrains プロダクトを管理するプロダクト」と表現することができ，無料で使うことができる．今回は普及のためにも「JetBrains Toolbox App」の便利さを紹介したいと思う．

www.jetbrains.com

アップデート / インストール

Toolbox App を使うと「インストール済の JetBrains プロダクトを最新版にアップロード」することができる．今までプロダクトごとに最新版にアップロードしていた人にとっては非常に効率良く使えるようになる．個人的には RubyMine と GoLand と PyCharm Community を使っていて，以下のキャプチャから PyCharm Community を最新版にアップデートできることがわかる．さらに Toolbox App では，新しくプロダクトをインストールをすることもできるため，JetBrains のウェブサイトにアクセスする必要もなくなる．

f:id:kakku22:20190205225154p:plain

複数バージョン対応

Toolbox App を使うと，例えば The Early Access Program (EAP) など「複数バージョンの JetBrains プロダクトをインストール」することもできる．個人的には RubyMine (EAP) を使うことがある．

f:id:kakku22:20190205225212p:plain

プロジェクト管理

多くの GitHub リポジトリを並行して開発する場合など，プロジェクトが多い場合に「Toolbox App から簡単にプロジェクトにアクセス」することもできる．JetBrains プロダクトを最初に起動するのではなく，Toolbox App からプロジェクトを検索できるのは非常に便利で，実際に使えばすぐに感じてもらえると思う．以下のキャプチャは載せられるようにサンプルプロジェクトを開いた状態にしてある．

f:id:kakku22:20190205225300p:plain

詳細設定

JetBrains プロダクトごとの Settings 画面では「自動更新設定」や「Maximum Heap Size 設定」などもできる．JetBrains プロダクトを使っているとメモリ不足になる場合があり，Maximum Heap Size を増やす Tips を知っている人も多いと思う．Toolbox App から直接 Maximum Heap Size を設定できるのは地味に便利だったりする．

f:id:kakku22:20190205225340p:plain

まとめ

JetBrains プロダクトを使っているなら「JetBrains Toolbox App」も合わせて使おう！もっと普及すると良いな！

2019-01-31

FaaS フレームワーク「OpenFaaS」を実践的に学べる公式ワークショップ

Docker Serverless OpenFaaS

Docker Swarm と Kubernetes をサポートしている FaaS フレームワークとして「OpenFaaS」がある．CNCF Cloud Native Landscape を見ても Serverless カテゴリに入っている．OpenFaaS は前から気になっていたけど，今まで試したことがなく，最近 GitHub に OpenFaaS 公式のワークショップがあることを知って，さらに日本語版も用意されていたため，今回はワークショップを進めながら OpenFaaS を学ぶことにした．

www.openfaas.com

アジェンダ

Lab 1 : まずはOpenFaaSの準備
Lab 2 : OpenFaaSを試してみよう
Lab 3 : はじめてのfunction
Lab 4 : functionについてさらに掘り下げてみよう
Lab 5 : Gitbotを作ろう
Lab 6 : functionでHTMLを扱ってみよう
Lab 7 : 非同期 function
Lab 8 : 応用編 - タイムアウト
Lab 9 : 応用編 - functionのオートスケール
Lab 10 : 応用編 - secretの使い方
Appendix

英語版だと，既に「Lab 11 - Advanced feature - Trust with HMAC」まで追加されている．

github.com

Lab 1 : まずはOpenFaaSの準備

Lab 1 では，OpenFaaS を動かす環境を構築する．今回は「Docker Desktop for Mac + Docker Swarm」を使うことにした．Docker Swarm ではなく Kubernetes もサポートしているけど，ワークショップの推奨構成は Docker Swarm となる．

$ docker --version
Docker version 18.09.1, build 4c52b90

次に「OpenFaaS CLI」をインストールする．今回は brew を使った．

$ brew install faas-cli

$ faas-cli version
  ___                   _____           ____
 / _ \ _ __   ___ _ __ |  ___|_ _  __ _/ ___|
| | | | '_ \ / _ \ '_ \| |_ / _` |/ _` \___ \
| |_| | |_) |  __/ | | |  _| (_| | (_| |___) |
 \___/| .__/ \___|_| |_|_|  \__,_|\__,_|____/
      |_|

CLI:
 commit:  a141dedf94ffeed84412365fd591bdc8999c5a1b
 version: 0.8.3

github.com

最後に OpenFaaS をデプロイする．OpenFaaS の公式リポジトリを git clone し，deploy_stack.sh を実行すると，Docker Swarm にデプロイできる．OpenFaaS フレームワークとして，複数のコンテナが動いていることも確認できる．

$ git clone https://github.com/openfaas/faas

$ cd faas && \
  git checkout master

$ ./deploy_stack.sh --no-auth

$ docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                         PORTS
j8sukvimvk20        func_alertmanager   replicated          1/1                 prom/alertmanager:v0.15.0
azd1ypjtat6r        func_faas-swarm     replicated          1/1                 openfaas/faas-swarm:0.6.1
xslhyv2k81ij        func_gateway        replicated          1/1                 openfaas/gateway:0.9.14       *:8080->8080/tcp
lmuottao09ga        func_nats           replicated          1/1                 nats-streaming:0.11.2
kslgx10aa2md        func_prometheus     replicated          1/1                 prom/prometheus:v2.3.1        *:9090->9090/tcp
ocpfj4xiofns        func_queue-worker   replicated          1/1                 openfaas/queue-worker:0.5.4

github.com

さらに OpenFaaS にはコンソールもあり，既に http://localhost:8080/ui/ にアクセスすると，接続できるようになっている．

f:id:kakku22:20190130214050p:plain

Lab 2 : OpenFaaSを試してみよう

Lab 2 では，OpenFaaS の公式リポジトリにある stack.yml を使って，実際に Function をデプロイする．

$ faas-cli deploy -f https://raw.githubusercontent.com/openfaas/faas/master/stack.yml
Parsed: https://raw.githubusercontent.com/openfaas/faas/master/stack.yml
Deploying: hubstats.

Deployed. 202 Accepted.
URL: http://127.0.0.1:8080/function/hubstats

Deploying: nodeinfo.

Deployed. 202 Accepted.
URL: http://127.0.0.1:8080/function/nodeinfo

Deploying: echoit.

Deployed. 202 Accepted.
URL: http://127.0.0.1:8080/function/echoit

Deploying: wordcount.

Deployed. 202 Accepted.
URL: http://127.0.0.1:8080/function/wordcount

Deploying: base64.

Deployed. 202 Accepted.
URL: http://127.0.0.1:8080/function/base64

Deploying: markdown.

Deployed. 202 Accepted.
URL: http://127.0.0.1:8080/function/markdown

コンソールから Function を実行することができる．例えば，Markdown を HTML に変換する function/markdown Function がある．

f:id:kakku22:20190130214110p:plain

他には入力した文章から文字数をカウントする function/wordcount Function など，計6種類あった．

f:id:kakku22:20190130214130p:plain

OpenFaaS には Function を公開できる仕組みとして「Function Store」がある．今回はアスキーアートを表示する function/figlet Function をコンソールからデプロイした．

f:id:kakku22:20190130214151p:plain

github.com

また faas-cli list --verbose を実行すると，Function ごとの実行回数 (Invocations) を確認できる．

$ faas-cli list --verbose
Function                        Image                                       Invocations     Replicas
figlet                          functions/figlet:0.9.6                    6                  1
nodeinfo                        functions/nodeinfo:latest                 0                  1
wordcount                       functions/alpine:latest                   3                  1
echoit                          functions/alpine:latest                   0                  1
hubstats                        functions/hubstats:latest                 0                  1
markdown                        functions/markdown-render:latest          5                  1
base64                          functions/alpine:latest                   0                  1

最後はモニタリング関連の話題となり，OpenFaaS を Docker Swarm にデプロイしたときに，実は Docker Compose によって Prometheus も起動していて，OpenFaaS のメトリクスを取得している．今回は Prometheus を可視化するために Grafana を起動する．

$ docker service create -d \
--name=grafana \
--publish=3000:3000 \
--network=func_functions \
stefanprodan/faas-grafana:4.6.3

さっそく http://127.0.0.1:3000/dashboard/db/openfaas にアクセスすると，Grafana で OpenFaaS のメトリクスを可視化できるようになっている．OpenFaaS だけではなく，Prometheus や Grafana も合わせて試せるのは良い点だと思う．

f:id:kakku22:20190130214222p:plain

Lab 3 : はじめてのfunction

Lab 3 では，公式テンプレートから Function を作る．現時点で「計15種類」のテンプレートが公開されている．今回使う Python 3 以外にも，Go や Ruby も用意されていた．

$ faas-cli template pull

$ faas-cli new --list
Languages available as templates:
- csharp
- csharp-armhf
- dockerfile
- go
- go-armhf
- java8
- node
- node-arm64
- node-armhf
- php7
- python
- python-armhf
- python3
- python3-armhf
- ruby

github.com

今回は Python 3 テンプレートを使って hello-openfaas Function を作る．テンプレートは --lang オプションで指定する．なお --prefix オプションで指定するのは Function 名のプレフィックスで，今回は Docker Hub に公開することを前提に，Docker Hub のアカウント名を指定する．

$ faas-cli new --lang python3 hello-openfaas --prefix="kakakakakku"
Folder: hello-openfaas created.
  ___                   _____           ____
 / _ \ _ __   ___ _ __ |  ___|_ _  __ _/ ___|
| | | | '_ \ / _ \ '_ \| |_ / _` |/ _` \___ \
| |_| | |_) |  __/ | | |  _| (_| | (_| |___) |
 \___/| .__/ \___|_| |_|_|  \__,_|\__,_|____/
      |_|


Function created in folder: hello-openfaas
Stack file written: hello-openfaas.yml

Function を作ると，合わせて Stack ファイルも作られる．以下に hello-openfaas.yml を載せておく．

provider:
  name: faas
  gateway: http://127.0.0.1:8080
functions:
  hello-openfaas:
    lang: python3
    handler: ./hello-openfaas
    image: kakakakakku/hello-openfaas:latest

そして，単純な文字列 "Hello OpenFaaS" を返す実装を handler.py にして，hello-openfaas Function をデプロイする．今回は faas-cli build → faas-cli push → faas-cli deploy のフローになる．さらに Function の実行は faas-cli invoke でできる．

$ faas-cli build -f ./hello-openfaas.yml

$ faas-cli push -f ./hello-openfaas.yml

$ faas-cli deploy -f ./hello-openfaas.yml
Deploying: hello-openfaas.

Deployed. 202 Accepted.
URL: http://127.0.0.1:8080/function/hello-openfaas

$ faas-cli invoke hello-openfaas
Reading from STDIN - hit (Control + D) to stop.
Hello OpenFaaS

コマンドの裏側では docker build と docker push が実行されているため，Docker Hub を見ると，Docker イメージも公開されている．

f:id:kakku22:20190130214324p:plain

次に外部 API と連携し，宇宙飛行士の名前をランダムに表示する astronaut-finder Function を実装し，デプロイする．特別な内容はなく，実行結果を載せておく．

$ echo | faas-cli invoke astronaut-finder
Oleg Kononenko is in space

$ echo | faas-cli invoke astronaut-finder
Anne McClain is in space

今度は Docker Compose のように，OpenFaaS で複数の Function を管理する設定を試す．faas-cli new コマンドには --append オプションがあり，複数の Function を同じ Stack ファイルにまとめることができる．

$ faas-cli new --lang python3 first
$ faas-cli new --lang python3 second --append=./first.yml

最後にカスタムバイナリの紹介で，faas-cli new コマンドの --lang オプションには，プログラミング言語だけではなく dockerfile も指定することができる．これは指定した Docker イメージをテンプレートにできる機能で，Function をカスタマイズするときに必要になりそう．

$ faas-cli new --lang dockerfile sorter --prefix="kakakakakku"

Lab 4 : functionについてさらに掘り下げてみよう

Lab 4 では，詳細な Function 管理を学ぶ．OpenFaaS では「Watchdog」と呼ばれる HTTP サーバも起動していて，標準入力と標準出力をプロキシする役割となる．Function のログを出力するときに，デフォルトの挙動だと stderr を stdout に統合するため，もし統合を解消する場合は Stack ファイルに以下の設定を追加する必要がある．

environment:
  combine_output: false

次に OpenFaaS で Function を組み合わせたワークフローを実現する方法を学ぶ．大きく2種類あり「クライアント側でパイプを使って組み合わせる方法」と「Function から Function を呼び出す方法」がある．お手軽に実現するなら「クライアント側でパイプを使って組み合わせる方法」を使う．

$ echo -n "" | faas-cli invoke nodeinfo | faas-cli invoke markdown

Lab 5 : Gitbotを作ろう

Lab 5 では，OpenFaaS で GitHub の Webhooks を受け取る Function を実装する．機能としては GitHub Issue が作られると，Function が Webhooks を受け取り，GitHub Issue のタイトルと本文を分析してポジティブかどうかを判定し，結果を GitHub Issue のラベルに登録する．ただし，ローカルに構築した OpenFaaS 環境では Webhooks を受け取れないため，今回は ngrok コンテナを起動し，トンネルを作る．

$ faas-cli list --gateway http://xxxxxxxx.ngrok.io/
Function                        Invocations     Replicas
figlet                          0                  1
env                             0                  1
nodeinfo                        0                  1
wordcount                       0                  1
sorter                          0                  1
sentimentanalysis               0                  1
echoit                          0                  1
hubstats                        0                  1
hello-openfaas                  0                  1
markdown                        0                  1
base64                          0                  1
astronaut-finder                0                  1

まず，Webhooks を受け取る issue-bot Function を作る．手順と実装は省略する．事前に GitHub の Settings で Webhooks を設定しておく必要もある．

$ faas-cli new --lang python3 issue-bot --prefix="kakakakakku"
$ faas-cli build -f ./issue-bot.yml
$ faas-cli push -f ./issue-bot.yml

Webhooks を受け取れることを確認したら，今度はタイトルと本文がポジティブかどうかを判定する function/sentimentanalysis Function を呼び出せるように修正する．最後に GitHub の Personal Access Tokens を env.yml に設定し，issue-bot Function の環境変数として読み込むことで，GitHub Issue のラベルを登録できるようにする．function/sentimentanalysis Function の実行例を以下に載せておく．

$ echo -n "I am really excited to participate in the OpenFaaS workshop." | faas-cli invoke sentimentanalysis
{"polarity": 0.375, "sentence_count": 1, "subjectivity": 0.75}

$ echo -n "The hotel was clean, but the area was terrible" | faas-cli invoke sentimentanalysis
{"polarity": -0.31666666666666665, "sentence_count": 1, "subjectivity": 0.8500000000000001}

実際に OpenFaaS 経由で GitHub Issue にラベルを登録できた．

f:id:kakku22:20190130214346p:plain

Lab 6 : functionでHTMLを扱ってみよう

Lab 6 では，HTTP サーバのように HTML を返す Function を作る．Function の作成は今まで通り．

$ faas-cli new --lang python3 show-html --prefix="kakakakakku"

重要なのは Stack ファイルで，以下のように content_type: text/html を指定すると，レスポンスの Content-Type を固定することができる．

provider:
  name: faas
  gateway: http://127.0.0.1:8080
functions:
  show-html:
    lang: python3
    handler: ./show-html
    image: kakakakakku/show-html:latest
    environment:
      content_type: text/html

HTML を返す Function を実装し，以下の URL にアクセスすると，ウェブページにアクセスできる．

http://127.0.0.1:8080/function/show-html
http://127.0.0.1:8080/function/show-html?action=new
http://127.0.0.1:8080/function/show-html?action=list

最後は JavaScript も組み合わせて，入力した文字列をアスキーアートに変換する function/figlet Function を呼び出すアプリケーションを実装した．

http://127.0.0.1:8080/function/show-html?action=figlet

f:id:kakku22:20190130214404p:plain

Lab 7 : 非同期 function

Lab 7 では，Function を「同期的」に実行する方法と「非同期的」に実行する方法を学んだ．具体的には faas-cli invoke コマンドには --async オプションがあり，非同期的に実行することができる．非同期的に実行をすると，Function は Gateway から 「202 Accepted」のレスポンスを受けることになる．また HTTP ヘッダーに X-Callback-Url を設定することにより，Function の実行後にコールバックを受けることもできる．Function の特性に応じて，非同期的な実行が必要になる場面もありそう．

$ echo -n "" | faas-cli invoke long-task --async
Function submitted asynchronously.

さらに OpenFaaS は非同期実行のために「NATS Streaming」を採用していると書いてあった．確かに docker service ls で確認したコンテナの中にも NATS があった．NATS は CNCF (Cloud Native Computing Foundation) にも所属するメッセージングサービスを提供するミドルウェアで，前から試したいと思っていたところだった．

nats.io

Lab 8 : 応用編 - タイムアウト

Lab 8 では，Function のタイムアウト設定を学んだ．OpenFaaS では「計4種類」の環境変数でタイムアウトの時間を制御することができる．

sleep_duration
read_timeout
write_timout
exec_timeout

今回は sleep_duration = 10 と sleep_duration = 2 の動作を確認した．

provider:
  name: faas
  gateway: http://127.0.0.1:8080
functions:
  sleep-for:
    lang: python3
    handler: ./sleep-for
    image: kakakakakku/sleep-for:latest
    environment:
      sleep_duration: 10
      read_timeout: 5
      write_timeout: 5
      exec_timeout: 5

以下のような結果となり，sleep_duration = 10 の場合はワークショップの記載内容と少し差があった．

$ echo | faas-cli invoke sleep-for
Server returned unexpected status code: 502 -

$ echo | faas-cli invoke sleep-for
Starting to sleep for 2
Finished the sleep

Lab 9 : 応用編 - functionのオートスケール

Lab 9 では，OpenFaaS のオートスケールを学んだ．具体的には Prometheus の Alertmanager と連携する仕組みになっている．

docs.openfaas.com

function/nodeinfo Function を大量に実行するときに，Mac だと記載されているコマンドだと使えなかった．

$ while [ true ]; do curl -X POST http://localhost:8080/function/nodeinfo\; done;
while>

今回は以下のコマンドを実行した．

$ while :
  do
    curl -X POST http://localhost:8080/function/nodeinfo
  done

Prometheus のアラート画面を見ると，FIRING / PENDING になっていることを確認できた．faas-cli list でも，実行回数 (Invocations) が増えていた．

$ faas-cli list | egrep 'Function|nodeinfo'
Function                        Invocations     Replicas
nodeinfo                        1447               1

f:id:kakku22:20190130234728p:plain

Lab 10 : 応用編 - secretの使い方

Lab 10 では，OpenFaaS と「Docker secrets」を組み合わせて，機密情報を扱う方法を学んだ．

docs.docker.com

今回は GitHub の Personal Access Tokens を Docker secrets に登録し，Function から参照するように issue-bot Function をリファクタリングした．環境変数ではなく Docker secrets を使う Lab があるのは素晴らしいと思う．

$ echo -n xxx | docker secret create auth-token -
$ docker secret inspect auth-token

ワークショップ改善（プルリクエスト）

ワークショップを進めながら気になった点を修正して，プルリクエストを2個送った．

github.com

ワークショップ改善（フィードバック）

プルリクエストは送らなかったけど，ワークショップを改善できる点をまとめておく．OpenFaaS コミュニティに届くと良いなぁー！

全体的に
- mkdir を実行する手順が微妙で，ディレクトリ階層が /openfaas/faas/lab2/lab3 のようになってしまう
- Lab ごとに起点となるディレクトリ直下で mkdir をすると良さそう
Lab 3
- 「複数のfunctionの管理」のところにある faas-cli new でも --prefix を付けると良さそう
Lab 6
- HTML に指定されているフォントが「Roboto Mono」で，等幅フォントではないため，アスキーアートの表示が崩れてしまう
- 例えば「Courier New」など，等幅フォントに変更すると良さそう
Lab 7
- 正式表記にするならば「Github」ではなく「GitHub」にすると良さそう
Lab 8
- echo | faas-cli invoke sleep-for で 502 が返ってくるため，最新バージョンでの出力結果に更新すると良さそう
Lab 9
- 正式表記にするならば「AlertManager」ではなく「Alertmanager」にすると良さそう
- Alertmanager | Prometheus

まとめ

「OpenFaaS」を学ぶために OpenFaaS 公式ワークショップを試した
- 日本語版もある
OpenFaaS の基礎から応用まで幅広く学ぶことができた
OpenFaaS だけではなく Prometheus や Grafana や NATS Streaming も学べる題材になっている
ワークショップの所要時間は3,4時間程度だと思う（個人差あり）

参考資料

OpenFaaS のアーキテクチャが詳しく載っていて，参考になった．

2019-01-21

Docker 公式のセキュリティ診断ツール「Docker Bench for Security」を試した

Docker

最近 Docker 関連のセキュリティツールを調査する機会があり，今回は「Docker Bench for Security」を試したログを残しておく．「Docker Bench for Security」は Docker から公式に提供されているセキュリティ診断ツールで，具体的には「CIS Docker Community Edition Benchmark v1.1.0」をサポートしている．

github.com

コンテナ実行

「Docker Bench for Security」を実行する方法は複数ある．1番簡単なのはコンテナを実行する方法で，Docker イメージ「docker/docker-bench-security」が Docker Hub に公開されている．

https://hub.docker.com/r/docker/docker-bench-security

注意点としては，コンテナから CAP_AUDIT_CONTROL ケーパビリティなどの特権を許可する必要があることと，診断対象となるディレクトリをコンテナから参照できるようにする必要がある．GitHub に載っているコマンドはあくまでサンプルで，systemd を指定しているため，CentOS 7 系を前提にしているように思う．

$ docker run -it --net host --pid host --userns host --cap-add audit_control \
    -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
    -v /var/lib:/var/lib \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v /usr/lib/systemd:/usr/lib/systemd \
    -v /etc:/etc --label docker_bench_security \
    docker/docker-bench-security

シェル実行

「Docker Bench for Security」のリポジトリを clone して docker-bench-security.sh を実行すると，シェルですぐに診断ができる．診断項目を include / exclude するオプションもあり，柔軟に使える．

$ ./docker-bench-security.sh

$ ./docker-bench-security.sh -c check_1_1

$ ./docker-bench-security.sh -c check_1_1,check_1_2

$ ./docker-bench-security.sh -h
  usage: docker-bench-security.sh [options]

  -b           optional  Do not print colors
  -h           optional  Print this help message
  -l FILE      optional  Log output in FILE
  -c CHECK     optional  Comma delimited list of specific check(s)
  -e CHECK     optional  Comma delimited list of specific check(s) to exclude
  -i INCLUDE   optional  Comma delimited list of patterns within a container name to check
  -x EXCLUDE   optional  Comma delimited list of patterns within a container name to exclude from check
  -t TARGET    optional  Comma delimited list of images name to check

ちなみに docker-bench-security.sh の内部では ss コマンドを使っているため，Mac で Docker for Mac を診断しようとすると，以下のエラーが出る．とは言え，Mac で診断をするシチュエーションはあまりなさそう．

$ ./docker-bench-security.sh
ss command not found.

診断項目

GitHub Wiki などに診断項目の一覧がまとまってなく，自分用に整理をした．診断項目の実装は GitHub で tests ディレクトリ直下のシェルを読めばわかる．基本的にはシェル芸で実装されている．

1 - Host Configuration
- 1.1 - Ensure a separate partition for containers has been created
- 1.2 - Ensure the container host has been Hardened
- 1.3 - Ensure Docker is up to date
- 1.4 - Ensure only trusted users are allowed to control Docker daemon
- 1.5 - Ensure auditing is configured for the Docker daemon
- 1.6 - Ensure auditing is configured for Docker files and directories - /var/lib/docker
- 1.7 - Ensure auditing is configured for Docker files and directories - /etc/docker
- 1.8 - Ensure auditing is configured for Docker files and directories - docker.service
- 1.9 - Ensure auditing is configured for Docker files and directories - docker.socket
- 1.10 - Ensure auditing is configured for Docker files and directories - /etc/default/docker
- 1.11 - Ensure auditing is configured for Docker files and directories - /etc/docker/daemon.json
- 1.12 - Ensure auditing is configured for Docker files and directories - /usr/bin/docker-containerd
- 1.13 - Ensure auditing is configured for Docker files and directories - /usr/bin/docker-runc
2 - Docker daemon configuration
- 2.1 - Ensure network traffic is restricted between containers on the default bridge
- 2.2 - Ensure the logging level is set to 'info'
- 2.3 - Ensure Docker is allowed to make changes to iptables
- 2.4 - Ensure insecure registries are not used
- 2.5 - Ensure aufs storage driver is not used
- 2.6 - Ensure TLS authentication for Docker daemon is configured
- 2.7 - Ensure the default ulimit is configured appropriately
- 2.8 - Enable user namespace support
- 2.9 - Ensure the default cgroup usage has been confirmed
- 2.10 - Ensure base device size is not changed until needed
- 2.11 - Ensure that authorization for Docker client commands is enabled
- 2.12 - Ensure centralized and remote logging is configured
- 2.13 - Ensure operations on legacy registry (v1) are Disabled (Deprecated)
- 2.14 - Ensure live restore is Enabled
- 2.15 - Ensure Userland Proxy is Disabled
- 2.16 - Ensure daemon-wide custom seccomp profile is applied, if needed
- 2.17 - Ensure experimental features are avoided in production
- 2.18 - Ensure containers are restricted from acquiring new privileges
3 - Docker daemon configuration files
- 3.1 - Ensure that docker.service file ownership is set to root:root
- 3.2 - Ensure that docker.service file permissions are set to 644 or more restrictive
- 3.3 - Ensure that docker.socket file ownership is set to root:root
- 3.4 - Ensure that docker.socket file permissions are set to 644 or more restrictive
- 3.5 - Ensure that /etc/docker directory ownership is set to root:root
- 3.6 - Ensure that /etc/docker directory permissions are set to 755 or more restrictive
- 3.7 - Ensure that registry certificate file ownership is set to root:root
- 3.8 - Ensure that registry certificate file permissions are set to 444 or more restrictive
- 3.9 - Ensure that TLS CA certificate file ownership is set to root:root
- 3.10 - Ensure that TLS CA certificate file permissions are set to 444 or more restrictive
- 3.11 - Ensure that Docker server certificate file ownership is set to root:root
- 3.12 - Ensure that Docker server certificate file permissions are set to 444 or more restrictive
- 3.13 - Ensure that Docker server certificate key file ownership is set to root:root
- 3.14 - Ensure that Docker server certificate key file permissions are set to 400
- 3.15 - Ensure that Docker socket file ownership is set to root:docker
- 3.16 - Ensure that Docker socket file permissions are set to 660 or more restrictive
- 3.17 - Ensure that daemon.json file ownership is set to root:root
- 3.18 - Ensure that daemon.json file permissions are set to 644 or more restrictive
- 3.19 - Ensure that /etc/default/docker file ownership is set to root:root
- 3.20 - Ensure that /etc/default/docker file permissions are set to 644 or more restrictive
4 - Container Images and Build File
- 4.1 - Ensure a user for the container has been created
- 4.2 - Ensure that containers use trusted base images
- 4.3 - Ensure unnecessary packages are not installed in the container
- 4.4 - Ensure images are scanned and rebuilt to include security patches
- 4.5 - Ensure Content trust for Docker is Enabled
- 4.6 - Ensure HEALTHCHECK instructions have been added to the container image
- 4.7 - Ensure update instructions are not use alone in the Dockerfile
- 4.8 - Ensure setuid and setgid permissions are removed in the images
- 4.9 - Ensure COPY is used instead of ADD in Dockerfile
- 4.10 - Ensure secrets are not stored in Dockerfiles
- 4.11 - Ensure verified packages are only Installed
5 - Container Runtime
6 - Docker Security Operations
- 6.1 - Avoid image sprawl
- 6.2 - Avoid container sprawl
7 - Docker Swarm Configuration
- 7.1 - Ensure swarm mode is not Enabled, if not needed
- 7.2 - Ensure the minimum number of manager nodes have been created in a swarm (Swarm mode not enabled)
- 7.3 - Ensure swarm services are binded to a specific host interface (Swarm mode not enabled)
- 7.4 - Ensure data exchanged between containers are encrypted on different nodes on the overlay network
- 7.5 - Ensure Docker's secret management commands are used for managing secrets in a Swarm cluster (Swarm mode not enabled)
- 7.6 - Ensure swarm manager is run in auto-lock mode (Swarm mode not enabled)
- 7.7 - Ensure swarm manager auto-lock key is rotated periodically (Swarm mode not enabled)
- 7.8 - Ensure node certificates are rotated as appropriate (Swarm mode not enabled)
- 7.9 - Ensure CA certificates are rotated as appropriate (Swarm mode not enabled)
- 7.10 - Ensure management plane traffic has been separated from data plane traffic (Swarm mode not enabled)

改善 : 1 - Host Configuration

今回は Amazon Linux 2 を検証用ホストとして，Docker 18.06.1-ce のデフォルト状態に対して「Docker Bench for Security (1 - Host Configuration)」を実行した．すると，計7項目が WARN になった．今回は「auditd」 で Docker 関連の監査ログを取れるようにする．

$ ./docker-bench-security.sh -c check_1,check_1_1,check_1_2,check_1_3,check_1_4,check_1_5,check_1_6,check_1_7,check_1_8,check_1_9,check_1_10,check_1_11,check_1_12,check_1_13

（中略）

[INFO] 1 - Host Configuration
[WARN] 1.1  - Ensure a separate partition for containers has been created
[NOTE] 1.2  - Ensure the container host has been Hardened
[INFO] 1.3  - Ensure Docker is up to date
[INFO]      * Using 18.06.1, verify is it up to date as deemed necessary
[INFO]      * Your operating system vendor may provide support and security maintenance for Docker
[INFO] 1.4  - Ensure only trusted users are allowed to control Docker daemon
[INFO]      * docker:x:993:
[WARN] 1.5  - Ensure auditing is configured for the Docker daemon
[WARN] 1.6  - Ensure auditing is configured for Docker files and directories - /var/lib/docker
[WARN] 1.7  - Ensure auditing is configured for Docker files and directories - /etc/docker
[WARN] 1.8  - Ensure auditing is configured for Docker files and directories - docker.service
[INFO] 1.9  - Ensure auditing is configured for Docker files and directories - docker.socket
[INFO]      * File not found
[INFO] 1.10  - Ensure auditing is configured for Docker files and directories - /etc/default/docker
[INFO]      * File not found
[INFO] 1.11  - Ensure auditing is configured for Docker files and directories - /etc/docker/daemon.json
[INFO]      * File not found
[WARN] 1.12  - Ensure auditing is configured for Docker files and directories - /usr/bin/docker-containerd
[WARN] 1.13  - Ensure auditing is configured for Docker files and directories - /usr/bin/docker-runc

[INFO] Checks: 13
[INFO] Score: -7

以下の設定になるように /etc/audit/rules.d/audit.rules を修正する．

$ auditctl -l
-w /usr/bin/docker -p wa
-w /var/lib/docker -p wa
-w /etc/docker -p wa
-w /usr/lib/systemd/system/docker.service -p wa
-w /lib/systemd/system/docker.socket -p wa
-w /usr/bin/docker-containerd -p wa
-w /usr/bin/docker-runc -p wa

すると，WARN を残り1個まで改善できた．項目 1.1 は docker info -f '{{ .DockerRootDir }}' で取得できるディレクトリを別ファイルシステムにすると改善できる．今回は実施しなかった．

$ ./docker-bench-security.sh -c check_1,check_1_1,check_1_2,check_1_3,check_1_4,check_1_5,check_1_6,check_1_7,check_1_8,check_1_9,check_1_10,check_1_11,check_1_12,check_1_13

（中略）

[INFO] 1 - Host Configuration
[WARN] 1.1  - Ensure a separate partition for containers has been created
[NOTE] 1.2  - Ensure the container host has been Hardened
[INFO] 1.3  - Ensure Docker is up to date
[INFO]      * Using 18.06.1, verify is it up to date as deemed necessary
[INFO]      * Your operating system vendor may provide support and security maintenance for Docker
[INFO] 1.4  - Ensure only trusted users are allowed to control Docker daemon
[INFO]      * docker:x:993:
[PASS] 1.5  - Ensure auditing is configured for the Docker daemon
[PASS] 1.6  - Ensure auditing is configured for Docker files and directories - /var/lib/docker
[PASS] 1.7  - Ensure auditing is configured for Docker files and directories - /etc/docker
[PASS] 1.8  - Ensure auditing is configured for Docker files and directories - docker.service
[INFO] 1.9  - Ensure auditing is configured for Docker files and directories - docker.socket
[INFO]      * File not found
[INFO] 1.10  - Ensure auditing is configured for Docker files and directories - /etc/default/docker
[INFO]      * File not found
[INFO] 1.11  - Ensure auditing is configured for Docker files and directories - /etc/docker/daemon.json
[INFO]      * File not found
[PASS] 1.12  - Ensure auditing is configured for Docker files and directories - /usr/bin/docker-containerd
[PASS] 1.13  - Ensure auditing is configured for Docker files and directories - /usr/bin/docker-runc

[INFO] Checks: 13
[INFO] Score: 5

改善 : 4 - Container Images and Build File

次に「Docker Bench for Security (4 - Container Images and Build File)」を実行した．すると，計1項目が WARN になった．

$ ./docker-bench-security.sh -c check_4_1,check_4_2,check_4_3,check_4_4,check_4_5,check_4_6,check_4_7,check_4_8,check_4_9,check_4_10,check_4_11

（中略）

[INFO] 4.1  - Ensure a user for the container has been created
[INFO]      * No containers running
[NOTE] 4.2  - Ensure that containers use trusted base images
[NOTE] 4.3  - Ensure unnecessary packages are not installed in the container
[NOTE] 4.4  - Ensure images are scanned and rebuilt to include security patches
[WARN] 4.5  - Ensure Content trust for Docker is Enabled
[PASS] 4.6  - Ensure HEALTHCHECK instructions have been added to the container image
[PASS] 4.7  - Ensure update instructions are not use alone in the Dockerfile
[NOTE] 4.8  - Ensure setuid and setgid permissions are removed in the images
[PASS] 4.9  - Ensure COPY is used instead of ADD in Dockerfile
[NOTE] 4.10  - Ensure secrets are not stored in Dockerfiles
[NOTE] 4.11  - Ensure verified packages are only Installed

[INFO] Checks: 11
[INFO] Score: 1

項目 4.5 は「Docker Content Trust (DCT)」を有効化すると改善できる．

docs.docker.com

今回は環境変数 DOCKER_CONTENT_TRUST を設定して診断をすると，改善できた．

$ export DOCKER_CONTENT_TRUST=1
$ ./docker-bench-security.sh -c check_4_1,check_4_2,check_4_3,check_4_4,check_4_5,check_4_6,check_4_7,check_4_8,check_4_9,check_4_10,check_4_11

（中略）

[INFO] 4.1  - Ensure a user for the container has been created
[INFO]      * No containers running
[NOTE] 4.2  - Ensure that containers use trusted base images
[NOTE] 4.3  - Ensure unnecessary packages are not installed in the container
[NOTE] 4.4  - Ensure images are scanned and rebuilt to include security patches
[PASS] 4.5  - Ensure Content trust for Docker is Enabled
[PASS] 4.6  - Ensure HEALTHCHECK instructions have been added to the container image
[PASS] 4.7  - Ensure update instructions are not use alone in the Dockerfile
[NOTE] 4.8  - Ensure setuid and setgid permissions are removed in the images
[PASS] 4.9  - Ensure COPY is used instead of ADD in Dockerfile
[NOTE] 4.10  - Ensure secrets are not stored in Dockerfiles
[NOTE] 4.11  - Ensure verified packages are only Installed

[INFO] Checks: 11
[INFO] Score: 3

プルリクエストを出した 🎉

docker-bench-security.sh の実装を読みながら README.md に書いてあるオプション一覧を確認したところ，今月に追加されたオプション -t が README.md に反映されていないことに気付いた．さっそく README.md を修正し，プルリクエストを出して，すぐに merge してもらえた！

github.com

なお Docker (Moby) 関連のリポジトリにプルリクエストを出す場合，コミットメッセージに署名を追加する必要がある．詳しくは CONTRIBUTING.md に書いてある．覚えておこう！

github.com

まとめ

「CIS Docker Community Edition Benchmark v1.1.0」をサポートしている診断ツール「Docker Bench for Security」を試した
コンテナを実行する方法とシェルを実行する方法がある
例えば auditd を有効化するなど，診断結果を使って改善できる
README.md を修正するプルリクエストを出して merge してもらえた！