kakakakakku blog

Weekly Tech Blog: Keep on Learning!

WIP プルリクエストの誤った merge を避ける GitHub Apps「WIP」と GitHub 新機能「Draft pull requests」

チーム開発をしていると,プルリクエストを WIP (Work In Progress) として送る場面は多くある.例えば,コードを書く前に設計相談をしたり,レビュー依頼をする前にパッケージ構成など全体感を相談したり,プロトタイプなどを一時的に公開することもある.進捗状況を可視化できたり,根本的な手戻りを減らせるメリットもある.

WIP を制御するツール 3選

WIP を積極的に使うとしても,WIP のまま誤ってプルリクエストを merge してしまう可能性もあり,WIP を制御するツールを使うことが多いと思う.僕自身が使っている(使ってきた)WIP 制御ツールを紹介しようと思う.今後は最後に紹介する GitHub 新機能「Draft pull requests」を積極的に使っていこうと思う.

  • Chrome 拡張「Do Not Merge WIP for GitHub」
  • GitHub Apps「WIP」
  • GitHub 新機能「Draft pull requests」

Chrome 拡張「Do Not Merge WIP for GitHub」

以前は Chrome 拡張「Do Not Merge WIP for GitHub」を使っていた.プルリクエストのタイトルに "WIP" と入っていると「Merge pull request」ボタンを押せないように制御してくれる.比較的長く使っていたけど,自分自身が誤って merge をしないように制御できるだけで,チーム開発の場合はメンバー全員に Chrome 拡張をインストールしてもらう必要があった.

chrome.google.com

GitHub Apps「WIP」

去年頃からは GitHub Apps として公開されている「WIP」を使っている.プルリクエストのタイトルに "WIP" など以下のキーワードが含まれている場合,Checks に該当して「Merge pull request」ボタンを押せないように制御してくれる.

  • wip
  • work in progress
  • 🚧

github.com

サンプルリポジトリに「WIP」を導入して,タイトルに "WIP" と含まれているプルリクエストを用意した.以下のようになる.

f:id:kakku22:20190221200953p:plain

さらに「WIP」では GitHub Marketplace で Pro 契約をすると .github/wip.yml を使って細かく設定を書くことができる.以下のように書くと,対象をタイトル以外に広げることもできるし,独自のキーワードを設定することもできる.

locations:
- title
- label_name
- commit_subject
terms:
- do not merge
- 

github.com

GitHub 新機能「Draft pull requests」

すると今月,GitHub に新機能「Draft pull requests」が追加された.プルリクエストを「ドラフト版」として送ることができる機能で,今までのように明示的に WIP と書く必要がなくなった.本当に必要だった機能と言える.

github.blog

サンプルリポジトリで試したところ,プルリクエストのステータスが「Draft」になった.「Merge pull request」ボタンを押せないように制御してくれる.さらに「ドラフト版」を通常のプルリクエストに昇格する場合は「Ready for review」ボタンを押す.ただし,一度押すと戻すことはできなさそうだった.既存のプルリクエストもあるし,もしかしたら「ドラフト版として送り忘れる」こともありそうなので,GitHub Apps「WIP」と併用しつつ,今後は公式機能を積極的に使っていこうと思う.

f:id:kakku22:20190221212121p:plain

まとめ

  • WIP を制御するツール 3選
    • Chrome 拡張「Do Not Merge WIP for GitHub」
    • GitHub Apps「WIP」
    • GitHub 新機能「Draft pull requests」
  • 今後は GitHub 新機能「Draft pull requests」を積極的に使っていこうと思う
    • 既存のプルリクエストを「ドラフト版」に戻すことができないため,GitHub Apps「WIP」と併用すると良さそう

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

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

nikuyoshi.booth.pm

目次

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

情報収集の分類

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

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

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

Web API: The Good Parts

Web API: The Good Parts

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

本書では「情報収集」の中に「質問をする」「技術者と交流をする」など,ソフトスキルに分類されるスタイルも紹介されていて素晴らしかった.個人的には「質問をする」よりも「雑談をする」という表現を使うことが多く,コミュニケーションを通じて「質問 → 回答」という定型的な情報以外にも「少し関連する情報」も得られる可能性がある.積極的に質問(雑談)をするべきだし,組織的にも質問(雑談)を常にできるような文化を根付かせて置く必要がある.最近モブプログラミングが流行っている背景も関連していると思う.さらに質問(雑談)をすると「オートクライン」と引き起こすことができるのもメリットと言える.詳しくは以下の記事にまとめてある.あと質問をする目安として「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レベルある.プログラミング講師をしていたときに「プログラミング初心者に検索して!と言っても検索キーワードすら考えることができず,もっと具体的にサポートすると学習効率が高まる」という経験があり,まさに論文と同じ状況と言える.知れて良かった!

https://dl.acm.org/citation.cfm?id=352194dl.acm.org

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

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

まとめ

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

nikuyoshi.booth.pm

関連記事

著者 @nikuyoshi の記事!

nikuyoshi.hatenablog.com

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

kakakakakku.hatenablog.com

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

最近も 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 ごとに設定を変更できるため柔軟性がある

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

「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」も合わせて使おう!もっと普及すると良いな!

FaaS フレームワーク「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 buildfaas-cli pushfaas-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 builddocker 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 のログを出力するときに,デフォルトの挙動だと stderrstdout に統合するため,もし統合を解消する場合は 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 = 10sleep_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

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 のアーキテクチャが詳しく載っていて,参考になった.