BPF Performance Toolsを読んだ感想

BPF Performance Toolsを読んだので、感想ブログです。

先に感想を言っておくと「最高」でした。

BPF Performance Toolsとは？ 

NetflixでKernel・パフォーマンスにかかわるチューニング・アーキテクチャを専門にしているBrendan Greggさんが書いた本です。BPFのiovisorというTracing分野の第一人者でもあります。

www.brendangregg.com 

2019年12月に発売したばかりなので、BPFの分野では最新の本でしょう。他の著書に有名な本として(日本語版の)「詳解システム・パフォーマンス」があります。

BPF Performance Toolsは「詳解システム・パフォーマンス」第二弾と言えるかもしれません。ちなみにページ数は880Pあり、Kindleで表示される読み終わるための平均的な時間は「27時間30分」で、大作RPG並です。

www.oreilly.co.jp

読書時のレベル

BPF is 何くらいのレベル。インフラ経験は2年目くらい。

BPFという単語はCiliumとかカンファレンスとかで聞いたことがあった程度

「BPF Performance Tools」の良いところ

先にBPF Performance Toolsの良いところを書いておきます。

  • BPFをかなり詳細に扱った本(英語でも数は少ない。2冊くらい？)
  • NetflixやShopifyなどの実例が多く載っており、本番環境で実践することを念頭に置かれている
  • BPFプログラムを使ったTracingをするときの考え方や戦略が載っている
  • CPU/メモリ/ファイルシステム/ネットワークなど、レイヤごとに戦略、ツールなどを詳細に紹介している

BPFって何？ あと何に使えるの？

BPFはよく名前を聞きますが、「なんだか分からないけどすごいもの」くらいの印象しかありませんでした。バズワードかな、くらいに思っていましたが、本書を読んで印象が180度変わりました。

Brendan GreggさんがBlogで「Linux BPF Superpowers」という記事を公開していますが、Linux上でなんでもできるマジックツール、という表現がしっくり来るかもしれません。

BPFの由来・用途 

簡単に由来や用途についてまとめます。

BPFはBerkeley Packet Filterの略で、パケットフィルターの名前のとおり、登場当初の1992年はネットワーク用途のものでした。

ただし、現在では名前こそパケットフィルターを冠していますが、システムコールのフィルタリングやトレーシング、セキュリティなど様々な用途に使われています。

eBPFというextended Berkeley Packet Filterという名称もありますが、どうやら現在はBPFとeBPFは特に区別していないそうです(BPF Performance Toolsでも言及されていましたが、BPFとeBPFを同じものとして扱ってます)。

Linux Observability with BPFというO'reilly本もありますが、とくにTracingやObservabillityを確保するためにBPFツールを使うこともできます。

shop.oreilly.com

Linux Traditional Observability

たとえば、「なんかいつもより調子悪いサーバーがあるので見てみよう」と思った時にすることといえば、 だいたい次のようなことをすると思います。

  1. サーバーにSSHする
  2. uptimeでLoad Averageを確認する
  3. psコマンドでプロセスの状態を確認する
  4. pidstat, mpstatなどでCPU使用率を確認する
  5. freeやsarなどでメモリ消費量を確認する
  6. iostatやsarなどでI/Oを確認する
  7. netstatやsarなどでネットワーク状況を確認する

調子の悪いサーバーがあれば、SSHしてLinuxコマンドで状況を確認します。 

BPF Performance Toolsの3章にも載っていましたが、Netflixのパフォーマンスエンジニアがサーバーにログインして60秒で確認する内容がまとまっています。使われるのは伝統的なコマンドです。

↑のTweetで反響があったように、Linuxの基礎は10年以上の時を経ても変わっていません。

しかし、BPFはこれまでの伝統的なツールでは手が届かなかった領域に容易に手を入れられるようになってきています。そうしたBPFを活用したTracingプログラムが、今後は主流になっていくかもしれません。

 同じくBPF Performance Toolsの3章にはBPFを使ったTracingプログラム「bcc」のChecklistが載っています。これらのBPFツールが今後、topコマンドやsarコマンドと同じように当たり前に使われていくかもしれません。

  1. execsnoop
  2. opensnoop
  3. ext4slower(or btrfsslower, xfsslower, zfsslower)
  4. biolatency
  5. biosnoop
  6. cachestat
  7. tcpconnect
  8. tcpaccept
  9. tcpretrans
  10. runqlat
  11. profile

Linux Observability with BPF

BPFの仕組みの詳細は本記事では省きますが、Linuxの既存の仕組みを活用しています。

システムコールをフィルタリングできると書きましたが、BPFを使ったプログラムは次のEvent Sourceなどを使ったトレーシングができます。

Event Source 概要
kprobe Kernel Level Dynamic Tracepoint
uprobe User Level Dynamic Tracepoint
tracepoints Kernel Level Static Tracepoint
USDT User Space Static Tracepoint
Dynamic USDT User Space Dynamic Tracepoint
PMCs Programmable Hardware Counters
perf event Perfコマンドで使われているイベント

 これらはBPFのためだけに用意されたわけではなく、Linuxの長い歴史の中で築き上げられたものです。BPFはこれらを活用して、伝統的なツールでは探りきれない部分を探ることができます。

BPFの仕組みの詳細は、BPF Performance Toolsの第2章やLinux Observability with BPFに詳しく載っています。

BPFは様々な可能性を秘めたマジックツールです。BPF Peformanace Toolsでは、特にパフォーマンスを上げるためのツールではなく、パフォーマンスを上げるためのボトルネックを探すためのツールとしてBPFを活用しています。

bccとbpftrace

次の図は、Tracingを主としたBPFツール「bcc」と「bpftrace」で使える、レイヤーごとのTracing Commandをまとめたものです。

f:id:go_vargo:20200311002620p:plain

出典: http://www.brendangregg.com/blog/2019-07-15/bpf-performance-tools-book.html

かなりの数があります。伝統的なLinuxコマンドではレイヤーによっては調べることがそもそもできないものもありますが、これらのTracingツールを使えばそうしたレイヤーの状態も確認することができます。

たとえば、bccのChecklistにあったexecsnoop, biolatency, tcpconnectを例にコマンドの出力を確認してみます。

execsnoop

f:id:go_vargo:20200329011956p:plain

execsnoop
biolatency

f:id:go_vargo:20200329012103p:plain

biolatency
tcpconnect

f:id:go_vargo:20200329012236p:plain

tcpconnect

それぞれのCommandで、Traditional Toolでは見れない情報が分かりやすく取得できることが分かると思います。

注意点としては、bccでしか使えないコマンド・bpftraceでしか使えないコマンドがあり、目的によっては使い分ける必要があります。

  • bccは、どちらかというと既にできているツールを使うために使う初心者向け
  • bpftraceは、目的に合わせて自分でスクリプトを書くために使う中級者・上級者向け

といった感じでしょうか。

Gregg先生のブログ記事「Learn eBPF Tracing: Tutorial and Examples」でも、

  1.  初心者: bccのツールを使ってみる
  2. 中級者: bpftraceのツール(スクリプト)を作ってみる
  3. 上級者: bccのツールを開発する、bccやbpftraceにコントリビュートする

という段階での実践を進めています。

bccを試してみたい人は、Local Kubernetesを構築するMinikubeで簡単に試すことができます。MinikubeはVMを立てて、その上でKubernetesを作ってくれるツールですが、ここではVM部分だけを使います。

VM DriverはWindows・Linux・Macのどれでも動くVirtualBoxで試すのがオススメです。(Docker Driverだと動かないので気をつけてください)

minikube.sigs.k8s.io

BPF Performance Toolsの構成

ここまで前置きが長くなりましたが、ここからようやく本の内容紹介です。

BPF Performance Toolsは全18章 + Appendixの構成です。簡単に各章の内容をまとめると、次の感じになります。

 1. Introduction

BPFやeBPFの説明や、bcc, bpftraceの簡単な説明、kprobe, uprobe, tracepoints, USDTなどの簡単な説明などを行う導入部です 

2. Technology Background

BPFの技術を支えるBackgroundを詳細に解説している章です。2章が難易度としては一番高いかもしれません。

BPFの歴史から始まり、BPFの仕組み、Kernel Modulesとの比較、Event Sources(kprobe, uprobe, tracepoints, USDTなど)の仕組みを詳細に説明しています

3. Performance Analysis

 Performance Analysisの方法論・コマンドなどをまとめた章です。「詳解システム・パフォーマンス」で紹介された内容も多くあります。

冒頭で前述した「Netflixのperformance engineerがサーバログインしてから最初の60秒で確認する内容」やBPFツール(bcc)を使った調査方法なども簡単に紹介されています。

4. BCC

bccのコンポーネントや仕組み、インストール要件、ツールの特性の他、bccの中の代表的なツールとしてfunccount, stackcount, trace, argdistなどが紹介されています。

章の最後には「BCC Internals」として、仕組みの詳細や開発者向けのDebugの情報なども紹介されています。

5. bpftrace

4章と同じ構成で、bpftraceのコンポーネントや仕組み、インストール要件、ツールの特性などが紹介されています。

bccとbpftraceの大きな違いとして、bccで使えるようなツールを備えている一方で、bpftraceはDtraceのようなスクリプトを書けることが特徴の一つです。5章ではそのスクリプトの書き方がまとめられています。後半の章でもbpftraceのソースがかなりの量で紹介されているので、この書き方をある程度押さえておくとソースが読みやすくなります。

章の最後には4章と同じく、「bpftrace Internals」として、仕組みの詳細や開発者向けのDebugの情報なども紹介されています。

【6章以降の補足】

6章のCPUsから10章のNetworkingは「BPF Performance Tools」の核と言えます。

「詳解システム・パフォーマンス」でも「CPU」「メモリ」「ファイルシステム」「ディスク」「ネットワーク」のテーマを、6章から10章までのそれぞれの章で取り扱っていました。「BPF Performance Tools」も同じテーマをそれぞれの章で取り扱っています。

各章に共通している構成として、各テーマごとに次のようにまとまっています。

  • Learning Objectives: その章で学べること
  • Background: その章の対象技術の基礎知識(※CPUの章なら、CPUの基礎知識)
  • BPF Capabilities: BPFを使って、どういったトレースが実行できるか
  • Traditional Tools: 伝統的なトレース方法の紹介
  • BPF Tools: BPFのツール(bcc, bpftraceの両方)とワンライナー紹介

BPF CapabilitiesにはStrategyとして、どの部分をどの順番に見ていくと良い、という戦略をGregg先生が教えてくれるので、この部分だけでもすごく価値があります。

6. CPUs

CPUに特化した説明がまとまっています。

Traditional Toolsとして、次のツールを紹介しています。

Tool Description
uptime Load Averageと起動時間を表示する
top プロセスごとのCPU timeやシステム全体のCPU modeを表示する
mpstat CPUごとのCPU modeを表示する
perf タイムサンプリングのプロファイル
Ftrace Kernel Functionの統計やEventトレーシング

また、CPU関連のBPF Toolとして次のツールのUsage・Output・Args・SourceCode(bpftraceのみ。bccはなし)などが詳細に説明されています。

Tool Source Description
execsnoop bcc/bpftrace 実行されているプロセスを一覧表示
exitsnoop bcc exitしたプロセスと理由を表示
runqlat bcc/bpftrace CPU run queue latencyをまとめる
runqlen bcc/bpftrace CPU run queue lengthをまとめる
runqslower bcc 規定値より遅いrun queueの表示
cpudist bcc on-CPU timeをまとめる
cpufreq book プロセスごとのcpu frequencyのサンプリング
profile bcc CPU stack traceのサンプリング
offcputime bcc/book off-CPU stack traceと時間をまとめる
syscount bcc/bpftrace system callをカウント
argdist bcc system call解析に利用可能
trace bcc system call解析に利用可能
funccount bcc function callをカウント
softirps bcc software 割り込み時間をまとめる
hardirps bcc hardware 割り込み時間をまとめる
smpcalls book SMP call functionの時間をまとめる
llcstat bcc プロセスごとのLLCヒット率をまとめる

Traditional Toolsと比べても、CPU関連だけでもかなりのツールがあります。 BPFツールは単一目的のツールがほとんどなので、このコマンドだけ押さえればいいというものではなく、状況やレイヤーに応じてコマンドを使い分けていきます。

また、cpudistでon-CPU time, offcputimeでoff-CPU timeがわかるので、何か重い処理があったときにCPUかそれ以外に問題があるのか、切り分けに役立ちそうです。

7. Memory

Memoryに特化した説明がまとまっています。

Traditional Toolsとして、次のツールを紹介しています。

Tool Description
dmesg OOM Killer event詳細
swapon Swap device設定の表示
free システム全体のメモリ状況の表示
ps プロセス統計
pmap アドレスセグメントごとのprocess memoryの表示
vmstat システム全体の様々な統計の表示
sar page faultとpage scanner rateを表示可能
perf メモリ関連のPMC統計とevent sampling

また、Memory関連のBPF Toolとして次のツールが詳細に説明されています。

Tool Source Description
oomkill bcc/bpftrace OOM Kill eventの情報を表示
memleak bcc memory leak code pathを表示
mmapsnoop book システム全体のmmap(2)をトレース
brkstack book user stack traceとbrk(2) callを表示
shmsnoop bcc shared memory callを表示 
faults book user stack traceごとにpage faultsを表示
ffaults book ファイル名ごとにpage faultsを表示
vmscan book VM scannerのシュリンク・拡張を測定
drsnoop bcc reclaim eventのトレースとlatencyの表示
swapin book プロセスごとのswap-inを表示
hfaults book プロセスごとにhuge page faultsを表示
8. File Systems

File Systemsに特化した説明がまとまっています。

Traditional Toolsとして、次のツールを紹介しています。

Tool Description
df file systemの使用状況を表示
mount file systemの一覧やtypeを表示
strace system callをトレースでき、file systemのオペレーションも確認できる
perf file systemのtracepointsをトレースできる
fatrace Linux fanotify API(file access notify)に利用できるトレーサー

また、VFS, File Sysmte関連のBPF Toolとして次のツールが詳細に説明されています。

Tool Source Description
opensnoop bcc/bpftrace openされたファイルをトレース
statsnoop bcc/bpftrace stat(2) callをトレース
syncsnoop bcc/bpftrace sync(2) callをトレース
mmapfiles book mmap(2) fileをカウント
scread book read(2) fileをカウント
fmapfault book file map faultsをカウント
filelife bcc/book short lived fileのライフスパンを表示
vfsstat bcc/bpftrace VFS operationの統計
vfscount bcc/bpftrace すべてのVFS operationをカウント
vfssize book VFS read/write sizeを表示
fsrwstat book file system typeごとのVFS read/writeを表示
fileslower bcc/book 遅いfile read/writeを表示
filetop bcc top(1)コマンドのファイル版
filetype book file typeとプロセスごとのVFS read/writeを表示
writesync book sync flagによるregular fileへのwriteを表示
cachestat bcc Page cacheの統計
writeback bpftrace write-back eventとlatencyの表示
dcstat bcc/book directory cache ヒット統計
dcsnoop bcc/bpftrace directory cache lookupをトレース
mountsnoop bcc システム全体のmount, umountsをトレース
xfsslower bcc 遅いXFS operationを表示
xfsdist bcc XFS operation latency ヒストグラムを表示
ext4dist bcc/book ext4 operation latency ヒストグラムを表示
icstat book inode cache ヒット統計
bufgrow book buffer cache growthを表示
readahead book read ahead ヒットと効率を表示

 Traditional ToolsだとVFS, File Systemレイヤーのトレース方法が少なかったですが、かなりの種類のBPFツールがあり、よりObservabilityを確保する方法が増えました。

9. Disk I/O

DISK I/Oに特化した説明がまとまっています。

Traditional Toolsとして、次のツールを紹介しています。

Tool Description
iostat diskごとのI/O統計をまとめる
perf block tracepointを使ったdisk解析に利用可能
blktrace block I/O eventをトレース

また、Disk I/O関連のBPF Toolとして次のツールが詳細に説明されています。

Tool Source Description
biolatency bcc/bpftrace block I/O latencyのヒストグラムを表示
biosnoop bcc/bpftrace disk I/OをPIDとlatencyなどとまとめる
biotop bcc top(1)のblock I/O版
bitesize bcc/bpftrace プロセスごとのdisk I/O sizeをヒストグラムで表示
seeksize book disk I/O seekのsizeを表示
biopattern book diskアクセスパターンをrandom/sequentialに分類
biostacks book I/O initialization stack traceとlatencyを表示
bioerr book disk errorをトレース
mdflush bcc/bpftrace md flush requestをトレース
iosched book I/O schedulerのlatencyをまとめる
scsilatency book SCSI command latencyを表示
scsiresult book SCSI command resultを表示
nvmelatency book NVME driver command latencyを表示

Disk I/Oに関してもiostat以外の選択肢が増えたのは嬉しいです。 

10. Networking

Networkingに特化した説明がまとまっています。

Traditional Toolsとして、次のツールを紹介しています。

Tool Description
ss Socket 統計
ip IP 統計
nstat Network stack 統計
netstat Network stack 統計と状態を表示するマルチツール
sar Networkとその他の統計を表示するマルチツール
nicstat Network interface 統計
ethtool Network interface driver 統計
tcpdump 解析用のパケットキャプチャ

 また、Networking関連のBPF Toolとして次のツールが詳細に説明されています。

Tool Source Description
sockstat book high-level socket 統計
sofamily book プロセスごとに、new socketのaddress familiyをカウント
soprotocol book プロセスごとに、new socket protocol(TCP,UDP,UNIX)を表示
soconnect book socket IP-protocol connectionをカウントする
soaccept book socket IP-protocol acceptをカウントする
socketio book I/Oをカウントしつつsocket詳細をトレース
socksize book socket I/O sizeをプロセスごとのヒストグラムで表示
sormem book socket receive bufferとoverflowの状況を表示
soconnlat book stackと一緒にIP socket connection latencyをまとめる
solstbyte book socket first byte latencyをまとめる
tcpconnect bcc/bpftrace/book TCP active connection(connect())をトレース
tcpaccept bcc/bpftrace/book TCP passive connection(accept())をトレース
tcplife bcc/book TCP sessionのlifespanをトレース
tcptop bcc top(1)のTCP版
tcpretrans bcc/bpftrace TCP retransmitをトレース
tcpsynbl book TCP SYN backlogをヒストグラムとして表示
tcpwin book TCP send congestion widow sizeや他のパラメータを表示
tcpnagle book TCP nagleの状況とtransmit delayをトレース
udpconnect book new UDP conncetionをトレース
gethostlatency book/bpftrace library call経由でDNS lookup latencyをトレース
ipecn book IP inbound explicit congestion notificationをトレース
superping book ICMP echo latencyをトレース
qdisc-fq(多数) book FQ qdisc queue latencyを表示
netsize book net device I/O sizeを表示
nettxlat book net device transmission latencyを表示
skbdrop book kernel stack traceと一緒にsk_buff dropをトレース
skblife book sk_buffのlifespanを表示
ieee80211scan book IEEE 802.11 WiFi scanningをトレース

Socket、TCPはかなりの数のBPFツールがありますが、UDPはまだまだ数が少ないです。今後の開発に期待しています。 

Networkingの章で、特に面白かったのが次のGregg先生の開発エピソードです。

11. Security

BPFツールを活用したセキュリティ関連の説明がまとまっています。ここでだけ紹介されているBPFツールとして、elfsnoop, modsnoop, bashreadline, shellsnoop, ttysnoop, eperm, capable, setuidsなどがあります。

12. Languages

プログラミング言語のトレースについてまとまっています。C言語とJava, Bash,その他の言語(JavaScript, C++, Golang)をテーマに取り扱っています。

BPFでのstack traceを有効にするには、frame pointer registerを有効にした上で(言語のRuntimeを)ビルドする必要があるので、そこはネックになりそうです。

13. Applications

プログラム言語の次は、Application(Software)のトレースについてまとめています。この章ではMYSQLを題材にして、6章から紹介されてきたBPFツールやMySQL用のBPFツールを使って解析をしていきます。

14. Kernel

これまでシステムの各レイヤーやプログラミング言語やアプリケーションのトレースが説明されてきましたが、Kernel自体のトレースが14章のテーマです。

loads, wakeuptime, offwaketime, mlock, mheld, kmem, kpages, memleak, slabratetop, mumamove, workqなどのBPFツールが紹介されています。

15. Containers

ContainerやNodeのトレースについてまとめている章です。この章でもContainer向けのコマンドが紹介されていますが、どちらかというと6章「CPU」〜10章「Networking」の内容が重要になってくると、本文中にもあります。

Traditional Toolsは、sytemd-cgtop, kubectl top, docker stats, perfなどが紹介されています。

対してBPFツールは、runqlat, pidness, blkthrot, overlayfsが紹介されています。

16. Hypervisors

Hypervisorのトレースについてまとまっている章です。xenhyper, cpustolen, kvmexitsなどが紹介されています。

17. Other BPF Performance Tools

bccとbpftrace以外のBPF Performance Toolを紹介した章です。17章では、次のツールが紹介されています。

18. Tips, Tricks, and Common Problems

最終章です。

BPFツールを作ったり、トレースしたりするときのTipsやテクニック、アドバイスなどが載っています。トレースにかかるOverheadの計算式や開発の極意など12個もアドバイスがあり、「Gregg先生は読者の心も読めるのか？」と思うような的確ぶりでした。

Kubernetes上のBPFによるトレーシング

ここまでが本の内容でしたが、人によっては面白いかもしれないので、自分が仕事で(たまに)使っているBPFツールによるトレーシングについて簡単に書こうと思います。

普段から使っているわけではありませんが、すぐに解決できない問題があった時はBPFツールを使って問題解決をすることがあります。

Kubernetes上のPodに、Ephemeral Containersのような形でPodを立てて、そのContainer内でbccやbpftraceを使っています。

BPFツールを自作するレベルではないので、基本的にbccとbpftraceに用意されているツールを利用しています。

この方法があれば、Traditional Toolsだけでは取れない領域も情報が取得できるようになるのですが、今だと次のような課題もあります。

  • Nodeレベルでしかトレースできない(Containerごとに取れない)
  • Node上に複数プロセスが立ち上がっていると、対象コンテナ以外のノイズが酷い
  • 複数Podがいると、トレースしたいPodがいるNodeをうまくコントロールしないとトレースできない

上記のように、複数プロセス・複数のNode、複数のPodがあると非常に目当てのトレースがしにくいです(Kubernetesとは相性が悪いですね)。

ただし、業務でも役立っています。たとえば、ある時 特定のApplicationのAPIをコールすると、Nginxが502を返すという問題がありました。その時点では、ログらしいログがなく原因が不明でした。

原因自体はOOM KillによってプロセスがKillされて、Nginx → App間で応答できなくなり502が発生していたのですが、signalやkillsnoop, sysdig inspectを使って、SIGKILLを実行したプロセスを特定し、oomkillでOOM Killが発生していることが特定でき、原因を解明できました。

PerformanceチューニングにもBPFを活用したいので、いずれは用意されていないツール用に自作の道に進むかもしれません。

感想

かなり分厚い本ですが、これだけ多くの話題とツールを扱っているので納得の重厚さでした。インフラを始めたばかりの頃は、topコマンドやpsコマンドなどを見ても、情報量が多くてどこを見ていいか戸惑ったり、表示されている数字が何を意味しているのか、よく分からないことが多くありました。

初めて本書で触れたBPF Toolsたちも同じで、表示される数字が何を示しているのか、どのパターンでどんなコマンドを使っていけばいいのか、まだまだ分からないことが多いです。本の分量や内容ともに一度読めば理解できるものではないと思っています。きっと、何度もコマンドを打って、考えなくても分かるようにしないとなぁ、と思っています。

また、bccやbpftraceに出てくるBPFツールは特定レイヤーにおける単一目的を持ったツールばかりなので、これさえ押さえておけば良いという代物ではありません。結局Linuxの各レイヤーの振る舞いの理解や、OS・カーネルの動作の理解が必要になった上で、適切なツールの選択が重要になってきます。

ただ確実に言えることは、BPF Performance Toolsで出てきたBPFツールは強い武器になる、ということです。Netflixのエンジニアが本番で活用しているように、システムでPeformanceの問題が出た時にその原因を特定するための手がかりになってくれます。この武器を繰り返し使って、手に馴染ませていくのが今後の課題になりそうです。

 

以上

2019年の振り返り(go_vargo)

年をブログで振り返るのは初めてですが、振り返りです

2019年はどんな年だったか

自分にとってはチャレンジの一年だったなー、と。

チャレンジというよりは、初めて挑戦したことが多いという方が正しいかもしれません。

よく頑張れたなー、と我ながら思います。

何に挑戦したか

 とりあえず初めて挑戦したことを箇条書きすると、

  • ブログ
  • Qiita(今年だと思ったら正確には去年の12月だった)
  • Advent Calander
  • 英語の技術本を読む
  • CKA/CKAD
  • 転職
  • LT登壇
  • セッション登壇
  • カンファレンス登壇
  • OSSコントリビュート(ソース)
  • 技術書典で技術書(同人)執筆, 出版
  • 商業本出版(技術書典底本)
  • Reddit投稿

でした。

 

簡単に時系列で1年を振り返ると、

12月: おうちK8s構築, 初Qiita

  1月: 転職活動開始

  2月: 内定

  3月: 前職のPJ2本, 退職活動, 技術書(Helm)執筆, 初LT

  4月: 初技術書典, CNDF2019のLT登壇, 退職

  5月: 商業版執筆, 転職(5/16), CKA取得, 初GCP

  6月: CKAD取得, Cloud Native Tokyo LT登壇

  7月: 実践Helm出版, Docker Meetup LT, Kubernetes Meetup セッション(CI/CD)

  8月: 技術書(Custom Controller)執筆

  9月:技術書典 Kubernetes Meetup セッション(Controller)

10月: Minikubeにコントリビュート開始

11月: CNDK2019登壇, KubeCon NA2019

12月: 執筆中

という感じでした。

 

技術研鑽、転職、外部発表、OSSコントリビュートなどだけもう少し振り返りたいと思います。

技術研鑽

自分が価値観として、一番重きを置いているのがこの部分で、今年は特にKubernetesのスキルを上げようと思っていました(単に大好きだからです)。

Kubernetesは、2018年の10月から仕事で使い始めたので、ようやく1年を超えました。

2019年に入るまでは、標準リソース(Pod, Serviceなど)の知識がある程度でした。

Kubernetesベースでの2019年のスキル目標は

  • K8sエコシステムをCNCF Trail Mapの1~5くらいまでを把握,実際に使うこと
  • CKA / CKADを取得すること
  • CRD + Custom Controllerを作れるようになる

を立ててました。

これらは問題なくクリアできたかな、と思います。

特に良かったのがCKA/CKADの取得と、Custom Controllerの作成でした。

 

CKA/CKADを取得したあたりから、Kubernetesの分散コンポーネントのそれぞれの役目・目的が明確にわかるようになって、問題が起きた時のトラブルシュート力が上がった気がします。

 

Custom Controller作成の方は、嬉しい誤算でした。

やり方を調べても複数の方法があって、それを体系的にまとめた方法がドキュメント・Webサイトとしてまとまっておらず、Programming Kubernetesが出た時は本当に嬉しかったです(Kubernetes哲学やapi-machineryを深く知りたい人は読むべき本です)。

しかし、ちょうどKubebuilderがv1からv2に切り替わっていく時期で、Programming KubernetesでもKubebuilder v2については対象外だったので、あっという間に元の混沌に戻ってしまいました。

技術書典7の「実践入門Kubernetes カスタムコントローラへの道」はそのフラストレーションを解消できるように、執筆当時の最新バージョンで書こうと決めてました。

結局参考になるものが世界中になかったので(たぶんapi-machineryのContributorの人の頭の中にだけはあったと思う)、client-goやSample Controllerのソースをひたすらデバッグしていきました。

その成果は次の資料と本にまとめていますが、これを経験したおかげで結果的にKubernetesのAPI哲学や基本メカニズムについて造詣を深めることができました。

Kubernetesに対するレベルはすごく上がったと思います。

 

speakerdeck.com

 

毎回技術書を書く時は、自分のやったことのない・知らないものをテーマにしようと考えていますが、HelmもCustom Controllerも一から書いたことで自分の力になりました。技術研鑽という観点だと、やり切って良かったなと思っています。

ちなみに当たり前ですが、本を書くのはめちゃくちゃ疲れる、というのを学んだ一年でした。

技術書典後も書いているから、人の2倍は技術書典している気がする(え、もう次！？)

転職

2019/5月に転職したので、だいたい半年が過ぎました。

前職はSIerで、レガシーシステムの開発・保守をすることが多かったのですが、Cloud Native系の勉強会・カンファレンスに出まくって「自分も同じように(仕事で)Cloud Nativeやりたい！」と思って転職しました。

転職前は外部発表が皆無に等しかったのですが、Cloud Nativeを実践している会社にスカウトをもらえて、今は楽しくCloud Nativeをやってます。

 

(履歴書には書いてあるけど)、実はインフラを職種で始めたのが2018年10月くらいからで、まだ一年とちょっとくらいの経験です。

新しい環境・新しい技術スタック・大規模な環境など、非常に刺激的でした。

転職して良かったー、というのが一番大きな感想です。

 

これだけ見るとHappyだけど、最近だとYAMLとシェルとPipelineだけ作ることに飽きてきてしまったので(Cloud Nativeも地道な作業の積み重ねなのだ)、コードを書いて自動化を進めるものとかにコミットできたらなーと思ってます。

最近だとBerglas Secretがその一つで、来年もそっちを継続して進めたいところです。

 

業務でもすごく大きなプラットフォームの構築・運用をやっていたので、桁がこれまでの感覚と違っていて、未だに(RPSとかQPSとかの)数値感が形成できていません。

そのため、来年はその辺の感覚値を自分の中に形成したいところです。

キャパシティプランニングとパフォーマンスチューニングができるようになりたい...

外部発表

2019年で、LT → セッション → カンファレンスと段階的に発表できたのが良かったです。

発表の中でも、「ゼロから始めるKubernetes Controller」は国内外でも評価していただいてやって良かったのと、「Production Ready Kubernetesに必要な15のこと」も同じく反響が大きくてCNDK2019でBest Speakerに選んでいただけて光栄でした。

 

外部発表することで、多くの方と知り合い・お話しすることができて楽しかったです。

Twitterとかでも話しかけていただけるとすごく喜びます。

 

以下は登壇したものです。

 

CNDF2019 LT

やさしい会 LT

Cloud Native Meetup Tokyo#8

Docker Meetup Tokyo#31

Kubernetes Meetup Tokyo#21

Kubernetes Meetup Tokyo#23

Cloud Native Days Kansai 2019

Kubernetes Invitational Meetup Tokyo#4

 

自分のモチベーションとして、すでに多く語られているものは自分がやっても意味がないなと思ってしまうので、誰も言及してなさそうなものを来年も発表したいなーと思っています(今考えているのはkube-api-serverとかkubeletとか)。

えてしてそういうものはDeep Diveになってしまうので、そういうところの需要があるところはあるのだろうか...

探り探りやっていこうと思います。

OSSコントリビュート

OSSコントリビュートは、エンジニアだったらやってみたい！ と思っていたのですが、ようやく挑戦できました。

今は、Minikubeにコントリビュートしています。

数えたらPR数はまだ8個でした。がっつりGoのコードを書いてます。

 

ソフトウェア開発スキルを伸ばせたり、熟練のエンジニアからレビューしてもらえたり、(時間を使うこと以外は)良いことずくめだなーと思います。

リリースノートに自分の名前が載っていると、その喜びがひときわ強くなります。

コントリビュート始める前はなぜか恐い恐いと思っていたのですが、不思議です。

 

書こうと思うと、色々エピソードもあるのですが、それらはコントリビュータ体験記として技術書典8の同人誌に書こうと思ってます。

 

OSSコントリビュートのモチベーションは、Kubernetesリポジトリに貢献(コミット)したい、という気持ちです。

今までKubernetesをいかに上手く使うか、という観点でしたが、これからはKubernetesを作る側にシフトしていきたいなと考えるようになりました。

kubernetes/kubernetesにコミットするのが一番ですが、いきなり行くのは無理だな、と判断してMinikubeにコントリビュートし始めました。

しかし、Minikubeへのコントリビュートは上に書いた通り非常に良いことが多かったので、来年も含めて末長く続けていきたいと思っています。

来年やりたいこと

最後に来年やりたいことをまとめて終わりです。

 

来年挑戦したいことは、KubernetesのDeep Dive, カーネルと英語です。

Kubernetes Deep Dive

2019年はControllerのDeep Diveをしていましたが、同じことを他のコンポーネントでもやりたいなーと思っています。

本当はkube-api-serverは2019年中にはやりたかったけど、忙しくて断念しました。

技術書典で出展したり外部発表したり、とかは実際に検証したあとで考えようと思います。

カーネル

ゲーム会社のインフラをやっているので、インフラの業務としてボトルネックの改善があるのですが、低レイヤーを知らないと話にならないなとこの半年で思い知りました。

カーネルも覚えることが多いのは本の分厚さで表れていますが、ちょっとずつ挑戦しようと思います。

今年読んだ本は「Linuxのしくみ」「ふつうのLinuxプログラミング」「詳解 システム・パフォーマンス」を読みました。

今は「Linux Observability with BPF」を読んでいて、その次に「BPF Performance Tools」に行こうと思っています。

来年は「Linux Kernel Development」と「詳解 Linuxカーネル」を読みたいな...
おすすめ本があったら教えていただきたいです(切実に)

英語

来年もコントリビューションやCloud Nativeを続けていくにあたって、英語でContributorと会話できないと話にならないなとKubeCon NA2019で痛感しました。

KubeCon NA2019ではMinikubeのメンテナーたちと会って話して奇跡的に相手の意図が理解できましたが(多分優しく話してくれていた)、確実に意思疎通できるようになりたい(ならないといけない)と実感しました。

継続的かつ長期的に訓練しないと身に付かないと思っているので、年単位で頑張っていきたいところです。

最後に

2018年以前までは主業務のほとんどが上流で、Excelとパワーポイントで資料を作成する毎日で、ちゃんと技術と向き合ったエンジニアになりたいと思っていました。

2019年はインプットもアウトプットも業務もきちんとできて、ようやくエンジニアをちゃんと名乗れるな、と安堵しています。

 

2019年は自分なりに頑張った年でしたが、頑張りすぎた面もありました。

スケジュールが完全に土日消失前提だったので、もっと余裕を持ちたいと思います。

仕事しつつ、発表資料作りつつ、執筆しつつ、コントリビュートしつつ、英語の勉強しつつ、技術の勉強しつつ、は自分には無理というのがよくわかったので、来年は要所要所で抑えつつやっていきたいと思います。

 

今年一年、多くの方々と交流し、お世話になりました。

本当にありがとうございました。

来年も発表を聞いたり、発表をしたり、お話ししたりして、楽しく技術に打ち込んでいきたいと思います。

来年もよろしくお願いします！！

技術書典7で「実践入門 Kubernetesカスタムコントローラへの道」を頒布します

目的

2019/09/22(日)の技術書典7で「実践入門 Kubernetesカスタムコントローラへの道」を頒布します。

この記事は、その本の内容紹介になります。

公開ページでは文字上限があるので、載せられない情報を中心に挙げていきます。

 

techbookfest.org

 

 

どんな本を書くのか

タイトル通り、Kubernetesの「カスタムコントローラ」がテーマの本です。

f:id:go_vargo:20190826014403p:plain

表紙

Kubernetesには拡張機能として、主に次の３つの機能があります。

  1. Admission Webhook
  2. CRD + Custom Controller(= Operatorとも呼ばれる)
  3. API Aggregation

本書はこのうち、近年注目が集まっている2のCRD + Custom Controllerを中心にした本です。

 

Custom Controllerに興味を持った人なら共感いただけることですが、現状Custom Controllerに関する情報は散逸し、非常に敷居が高い分野です。

誰でも手に入る書籍としては、先日ブログ記事で挙げた「Programming Kubernetes」しかありません(さらに英語です)。

go-vargo.hatenablog.com

 

もちろん英語や中国語のブログなどで、Controllerに触れたものは数多くあります。

しかし、これまたややこしいことに、Controller自作のための方法がいくつかあり、初見で見た場合は混乱すること間違いなしです。

私もその一人でした。

 

そのため、Controller・Operatorを自作したい人が、どういうツールを使って、どのように実装していくのかを悩まずに最短の道のりで辿り着けるように、という想いを込めて執筆しているのが本書になります。

 

なぜ書くのか

Custom Controllerだけでなく、Custom API Serverなどの幅広いKubernetesの実装について触れている「Programming Kubernetes」は、ブログ記事でも書きましたが、Kubernetesプログラミングに挑戦したい誰もが読むべきだと考えています。

 

であれば、わざわざ同人誌など書かずに「Programming Kubernetes」を読めばいいではないか、と思うかもしれません。

しかし、あえて誤解を恐れずに言うと、「Programming Kubernetes」を読むだけで、Controller・Operatorを開発するのは難しい、と考えています。

 

理由はいくつかあります。

  1. Custom Controller, Custom API Serverなど幅広い情報を取り扱っているため、Custom Controller実装の章が全体から見ると比較的内容が薄い
  2. 2019/08に販売されたProgramming Kubernetesだが、すでに一部の内容が古くなってしまった(これはSDKの開発サイクルが早すぎるためです)

もちろん、ブログの記事に書いた通り、Programming Kubernetesは控え目に言って(個人的に)最高なので、読むべき良著であることに変わりはありません。

 

しかし、本書では、本書を読み、サンプルコードを実際に実装することで、この本を読んだ誰もがOperatror開発の一歩を踏み出せるようになることを最終目標としています。

 

そのため、Programming Kubernetesとは別の観点で書き上げています。

例えるなら...

  • Programming Kubernetes: KubernetesのControl Planeの実装全般
  • Kubernetesカスタムコントローラへの道: Custom Controllerに特化した実践入門書

といった違いがあります。

 

私も初めてController開発に挑戦したときに、主に次のことで悩みました。

・ツール多すぎ。結局なに使えばいいの…

・ツール使ったら結局どこのなにを修正すれば良いの…

・なにから手をつければいいの(結局なにすればいいの)…

 

試行錯誤・四苦八苦しながら進めていった分、本書が、迷わずOperator実装というゴールに辿り着けるための道標になれば、これに勝る喜びはありません。

 

この本で何が学べるのか

大きく分けて、2つあります。

  1.  KubernetesのController部分の実装の仕組みに詳しくなれる
  2.  Kubernetes Custom Controller・Operator実装に必要なことを学べる 

1. KubernetesのController部分の実装の仕組みに詳しくなれる

Custom Controller・Operatorを実装するための方法には、主に次の3つの方法があります。

  1. KubernetesのController実装と同じ伝統的な方法(client-go + code-generatorライブラリを利用)
  2. KubebuilderというSDKを利用する方法
  3. Operator SDKというSDKを利用する方法

KubernetsのReplicaSetやDeployment, ServiceなどのResourceにも、それを管理するControllerがあります。

 

それらのControllerは1のclient-go + code-generatorライブラリを利用した方法で実装されています。

本書では、client-goのコンポーネントの説明をした後で、Sample Controllerという1の方法で実装されたサンプルリポジトリの内容を解説します。

github.com

 

Sample Controllerの実装が理解できれば、同じ仕組みを使っているため、その知識は既存のKubernetesのController実装の理解にも繋がります。

 

 

例えば本書を読めば、次のような図の意味が理解できるようになるでしょう。

f:id:go_vargo:20190826021511p:plain

よく見かけるやつですが、最初は理解不能でした

 

2. Kubernetes Custom Controller・Operator実装に必要なことを学べる 

Kubebuilder, Operator SDKも利用するには、ある程度お作法・実装方法を学ぶ必要があります。

 

公式チュートリアルもあるので、ある程度迷うことは少ないかもしれません。

(とはいえ、全ての実装の解説があるわけではありません)

 

特にKubebuilderはメジャーバージョン(v2.0.0)が2019/08/23(このブログ公開の3日前)に出たばかりです。

Programming Kubernetesは、Kubebuilder v1での実装が掲載されているので、参考にできるのは次の公式チュートリアルだけです。

 

book.kubebuilder.io

 

「Kubernetesカスタムコントローラへの道」では、KubebuilderとOperator SDKのそれぞれのサンプルリポジトリを用意しています。

 

それぞれの実装で細かくコミットを残し、本文中の解説とリンクするようにコミット先のリンクを脚注に掲載しています。

少なくとも、本文とコミット履歴を見比べながら写経すれば、誰でもOperatorを実装できるように注力しています。

 

また、次のような図の意味が理解できるようになるでしょう。

 

f:id:go_vargo:20190826021603p:plain

これもよく見かけますが、最初は理解不能でした

最後に本の章立てを説明して、終わりたいと思います。

 

章立て・構成

1章 CRDとController

Kubernetesの3つ存在する拡張機能の概要と、そのうちの一つであるCRD・Controllerについて説明します。

次のテーマを取り扱います。

 

・Kubernetesのハイレベルアーキテクチャ

・Control Loop（Reconciliation Loop）

・Kubernetesの拡張機能(Admission, CRD, API Aggregation) 

・CRDとCR

・CRDの応用機能

・ControllerとCRDを自作するために必要なもの

 

2章 client-goと知っておくべき周辺知識

Kubernetesの実装でも使われているライブラリ「clinet-go」と、Kubernetesの実装を見るにあたって必要なコンポーネントについて解説します。

次のテーマを取り扱います。

 

・Kind, Resource, Object

・client-goとapimachinery

・Informer

・Workqueue

・runtime.Object

・Scheme

 

3章 Sample Controller解説

本章では、その「Sample Controller」の仕組みをコードベースで解説します。

次のテーマを取り扱います。

 

・Sample Controllerは何をするためのものか？

・Sample Controllerディレクトリ構成

・Sample ControllerのCRD

・types.go

・main関数

・メインロジック（Reconcile）

 

4章 controller-runtimeとcontroller-tools

本書では、Kubebuilderが利用しているSDK「controller-runtime」と「controller-tools」の使い方を説明します。

v0.2.0のcontroller-runtimeとcontroller-toolsを、Controller開発に必要な部分に特化して説明します。

次のテーマを取り扱います。

 

・controller-tools markers

・Controller Manager

・Metrics

・Leader Election

・Reconcile

 

5章 KubebuilderでSample Controllerを実装しよう

Kubebuilderで、実際のControllerを実装します。

3章のSample Controllerを題材に、Kubebuilderで再実装に挑戦します。

 

第５章と第６章は、実際に手を動かして実装してもらえるように、細かくコミットをきって、本文中の解説とリンクして脚注にコミット履歴を連携しています。

(電子版でないとリンクを辿るのが厳しいですが、ご容赦ください)

 

最新版のKubebuilder v2.0.0で実装します。

 

6章 OperatorSDKでSample Controllerを実装しよう

絶賛執筆中です。

後日更新します。

 

9/7追記 無料サンプル版を第１章まで公開しています。

 

こちらも合わせて読んでいただけると幸いです。

go-vargo.booth.pm

 

 

最後に

 

在庫の準備数は、サークルチェック数を元に決めようと考えています。

この記事を読んで興味が出た方は、サークルチェックをしてくださると幸いです。

 

techbookfest.org

 

 

当日は、

  • 物理本 + ダウンロードカード
  • ダウンロードカードのみ

という形態で、頒布します(どちらも¥1,500)。

電子版は、後日BOOTHでも取り扱う予定です。

 

それでは、9/22当日はお06C「アルハンブラの畔」にてお待ちしています。

Programming Kubernetesを読んで学んだこと

Programming Kubernetesの紹介

「Programming Kubernetes」はO’Reilly社から出版されているKuberntesのアーキテクチャやCustom Controllerの実装、Custom API Serverの実装などについて掘り下げている本です。

Kubernetesのハイレベルアーキテクチャに触れている本は、日本語でもいくつかありますが、ソースベースのローレベルアーキテクチャで触れている本は本書しかないのではないかと思います(私が知らないだけかもしれません)。

 

著者は元Red Hat → AWSのDeveloper AdvocateのMichael HausenblasさんとRed Hatのprincipal engineerのStefan Schimanskiさんです。

 

www.oreilly.com

 

2019/07/21に購入し、2019/08/05に読み終わったので、感想をまとめたいと思います。

個人的な感想としては、控えめに言って最高です。

 

読み通したばかりですが、早速2週目に入ろうと思います。

 

Kubernetes拡張の前提

本書ではKubernetesの拡張機能に焦点が当てられています。

Kubernetesの拡張機能には主に次の2つの方法があります。

  1. CRD + Custom Controller (Operator)
  2. API Aggregation(Custom API Server)

1のCRDは自分の独自Resouceを定義し、それをReconcileするControllerを実装する方法です。

2のAPI AggregationではKubernetesのAPI Aggregation Layerに自分で作成したCustom API Serverを登録することで、API Serverを拡張する方法です。

 

「Programming Kubernetes」は1と2をどちらも実装レベルで解説をしています。

私は勝手に1のCustom Controllerだけを対象にしているのかと勘違いしていました。

 

2のCustom API Serverを導入している企業事例などは聞いたことがなかったので(知っている人はぜひ教えてください)、人類にこの話題は早すぎるのでは、と一瞬思いましたが、API Serverの実装を通しで見ることで、API Serverのアーキテクチャに詳しくなることができました。

 

Programming Kubernetesを読むべきなのは誰？

  • Kubernetesのアーキテクチャに詳しくなりたい人(特にControllerとAPI Server部分)
  • Custom ControllerやOperatorの実装を読めるようになりたい人
  • Custom ControllerやOperatorを自作できるようになりたい人
  • API Serverの実装を読めるようになりたい人
  • Custom API Serverを自作できるようになりたい人
  • Kubernetesにコントリビュートしたい人

が対象になるかと思います。

 

Programming Kubernetesの章立て

 

  1. Introduction: Kubernetesがなぜ今のアーキテクチャを採用しているのか
  2. Kubernetes API Basics: API Objectの説明
  3. Basics of client-go: Informer, API Machinery, Schemeなどの説明
  4. Using Custom Resources: CRDと機能(Validation, SubResource)の説明
  5. Automating Code Generation: code-generatorの説明
  6. Solutions for Writing Operators: Controller実装方法の説明
  7. Shipping Controllers and Operators: Controller/Operatorのデリバリ
  8. Custom API Servers: Custom API Serverの説明と実装・デプロイ
  9. Advanced Custom Resources: convert, admission webhook, Structural Schemasなど

Programming Kubernetesを読んだ感想まとめ

「Programming Kubernetes」を読んだ全体の感想をまとめます。

一言でいうなら、「Programming Kubernetesを読むべきは誰？」に一つでも当てはまる人は読むべきだと思います。

 

Cutom Controllerの実装やCustom API Serverの実装などに興味がない人でも、

  • なぜそのアーキテクチャを導入しているのか
  • 複数のバージョンの整合性を合わせるために内部で何を行なっているのか
  • Controller / API Serverがユーザに見えない裏側で何をしているのか
  • Kubernetes自体の実装がどのようにされているのか

といったディープな内容が学べます。

 

自分自身、Kubernetes The-Hard WayやCKAの学習を通じて、Kubernetesのアーキテクチャについて詳しくなったつもりでいました。

しかし、実際に本を読んでみると知らないことだらけで、正直一度読んだだけでは理解できていないと感じることも多いです(特にローレベルな箇所)。

それでも通しで読んだことで、前述したディープな内容を、ある程度説明できるようになったと思います。

 

以下は、各章ごとの感想メモです。

 

1. Introduction

Introductionでありながらも非常に内容が濃いです。

抜粋ですが、次の内容が載っています。

  • Event: Edge-driven-trigger vs Level-driven-trigger
  • なぜControllerがReconcileを採用しているのか
  • 悲観的ロックと楽観的ロック

よくKubernetesはImmutable Infrastructureを実現でき、Reconcileを行うことで理想の状態を現実に近づける、という説明は多くの方が聞いたことがあると思います。

しかし、なぜそうしたモデルやロジックを採用したのか、というアーキテクチャの背景に触れたものはほとんどありません。

そうした原点から説明してくれていたので、非常に好奇心をそそられました。

 

2. Kubernetes API Basics

API用語についてまとまっています。

Kind, Object, API Group, Version, ResourceなどREST APIとGoで必要な内容がまとまっています。

実例を用いてくれていますが、イメージがついていない箇所もあったので私は自分でも追加で調べました。

 

3. Basics of client-go

client-go, clientset, informer, deepcopy, apimachinery, workqueueなどの、Kubernetesの実装を見る上で避けて通れない要素を学びます。

 

この領域は本書以外にはドキュメントが全くない状態なので、この領域を調べる際は本書がバイブルになると思います。

 

(自分の読書メモを載せようと思っていましたが、とても量が多いので割愛)

 

よくCustom Controllerの登竜門としてSample Controllerが例として挙げられていますが、初見では全く意味が分からないでしょう。

本章を読んで初めて、コードの意味を読み取れるようになると思います。

 

また、KubebuilderやOperator SDKを使えば隠蔽されている領域ではありますが、この領域の内容を知らないと、オーパーツを動かしているかのように原理を知らないまま実装することになるのではないかと思っています。

 

4. Using Custom Resources

CRDについてまとまっています。

公式ドキュメントでも細かく触れられていますが、意外と機能が多いので、本章で頭の整理ができました。

次の内容が取り上げられています。

  • CRD Type Definition
  • Validation
  • Sub Resource
  • Dynamic Client, Typed Client

後半のDynamic Client, Typed Clientは1度目の読解では理解できませんでした

 

v1.15でbetaになったStructural Schema周りは9章で取り上げられています。

 

5. Automating Code Generation

code-generatorの内容がまとまっています。

code-generatorで使うタグの内容がまとまっています。

README含めて、ドキュメントがほとんどない領域だったので、こちらも本書がバイブルになると思います。

 

6. Solutions for Writing Operators

cnatというCustom ResourceのControllerを実装していきます。

github.com

  • client-go + code-generator
  • Kubebuilder v1
  • Operator SDK

のそれぞれの方法で、実装方法が説明されています。

 

少し残念なのが、実装の詳細は、比較的 端的に書かれていることです。

これは本書がCustom Controllerだけでなく、それを取り巻く内容とCustom API Serverなどの幅広い内容を扱っているため、薄くならざるを得なかったのではないかと(個人的に)考えています。

 

やはりControllerを書くためには、自分で手を動かす必要があるのかな、というのが本章を読んだ感想です。

 

唐突な宣伝ですが、技術書典7で「実践入門 Kubernetesカスタムコントローラへの道」を出す予定です。

正直Custom Controllerを作りたい人は全員Programming Kubernetes読めばいいじゃんという気持ちもありますが、この本を読んでもやっぱりController自作は難しいなー、という気持ちから現在執筆中です。

当然Programming Kubernetesからもめちゃくちゃインスパイアを受けていますが、実践入門の名の通り、より簡易に入門できる本を目指しています(目指しているだけかもしれない)。

 

 

7. Shipping Controllers and Operators

ControllerやOperatorをK8sクラスタにデリバリするための方法やツールがまとめられています。

 

Controllerを作って終わり、ではなく、その後のデリバリも考慮に入れているのが非常に素晴らしいです。

 

パッケージングやライフサイクルマネジメント、Production Readyなマニフェスト(RBACの考慮)などに焦点が当てられています。

 

よく、Controllerのバージョンアップはどうするんだ、といった意見をTwitterなどで見ることもありますが、そちらは第8章と第9章で書かれているConversion Webhookがその課題を解決する気がします。

 

8. Custom API Servers

API ServerとCustom API Serverについてまとまっています。

本書の中で一番難しかった気がします。

 

通常のマスターコンポーネントのAPI Serverについてもまとまっているため、どんな処理が内部で行われているかイメージがつきます。

 

A Pizza RestaurantというCustom API Serverを題材にCustom API Serverの実装とデプロイについても焦点を当てています。

 

github.com

 

API Server内のConversionとValidation, Admission(Defaulting)などの機能について詳細に書かれています。

知らないことが特に多かった章でした。

 

API ServerではConversionとValidation, Admissionがあり、CRDにも同じようにConversinやAdmissionの機能を、似た形で輸入しているらしいです(v1.15でbeta)

そのため第9章を読む前に、本章を読んで理解を深めることが推奨されています。 

本章内でも触れられていますが、たとえCustom API Serverを使わないとしても読み通した方が良いです。

 

この領域の学び方についてもまとめられていたので、紹介します。

  • KubernetesになんのAPIがあって、どのように実装されているか調べる
  • 自分のCustom API Serverを作る
  • Kubernetes内部の仕組みを学ぶ
  • 将来、Kubernetesにコントリビュートする

 

9. Advanced Custom Resources

CRDの応用機能についてまとまっています。

第8章で触れていたConversionやAdmissionの、CRD版の機能について焦点が当たっています。

 

また、v1.15でbetaになったStructural Schemaについての説明もありました(簡単にいうとOpenAPI v3 shemeに則っているフォーマット)。

これと合わせて、DefaultingやPruningなどの機能がCRDで有効になります。

 

終わりに

以上が本書の感想です。

読書メモを見たら、非常に量が多くて驚きました(残念ながらここでは概要だけで詳細にはほとんど触れていません)。

 

読み通して学んだ・理解したことは多くあれど、それでもローレベルな箇所で理解ができていないところも多くあるので、今後も学んでいく所存です。

 

誰かと答え合わせしたいなー...

技術書典6 サークル出展振り返りとまとめ 〜技術書執筆ってソフトウェア開発やん〜

バルゴ(@go_vargo)です。

2019年4月14日に開催された技術書典6で初サークル参加をしました(技術書典自体も初参加でした)。

このブログはそのサークル参加活動の全体的な振り返りです。

 

参加準備においてはしがないラジオのgamiさん(@jumpei_ikegami)の

【保存版】 #技術書典 初出展マニュアル【表紙入稿データサンプル付き】 - #がみぶろ

を大いに参考にさせていただきました。

この記事がなかったら乗り切れなかったです...ありがとうございます

  

techbookfest.org

 

techbookfest.org 

 

前提と環境、参考図書

この記事の内容はあくまで一例です。

色々な選択肢とメリット・デメリットがあると思います。

私も何がベストプラクティスかはわかりません。参考程度に見ていただけると幸いです。

 

前提

  • 物理本の印刷所は日光企画さんを利用
  • ダウンロードカードの印刷所はグラフィックさんを利用
  • オンデマンド印刷で特殊加工なし
  • 頒布形式はB5サイズの物理本 + ダウンロードカード
  • 表紙イラストやダウンロードカードのデザインは友人(Vtuber)に頼む

環境

  • PC: MacBook Pro13inch 2018
  • OS: MacOS Mojave
  • 執筆ソフト: Re:VIEW 2.0(Docker for Mac)
  • エディター: Atom 

参考図書

参考ブログ

 

モチベーション

書こう！ と思った理由は色々あります。色々あるので箇条書きで

  • もともと同人活動に興味があった(どちらかというとコミケとか)
  • Meetupで執筆者たちに会って気運が高まった
  • CloudNative系で何かアウトプットしたかった(登壇は難しそうだと思った)
  • 技術書執筆を通して技術力を高めたかった

その中で「Helm」をテーマに選んだ理由は次のような理由です。

 今だから書きますが、今回のテーマの「Helm」に関しては別に専門家でも達人でもありません。

もっというと業務で使うこともありませんでした。

ドキュメントを読んで一から勉強したり、公式リポジトリを見たり、PRを送ったり、Slackのチャンネルを見たり話しかけたりしてました。

本の内容自体は、Helm(v2)を理解できるよう色々なエッセンスを詰め込みましたが、最初から理解していたわけではありません。

 

スケジュール

日付 やったこと 備考
01/06 サークル申し込み応募開始  
01/09 サークル申し込み 転職活動開始した頃だったので悩みました
01/09 サークルカットのイラストを依頼 友人のVtuberに頼みました。Helmなのでイメージは舵で
01/19 「技術書典6 はじめてのサークル参加meetup(休日版)」に参加する Re:VIEW本を購入する
01/19 依頼したサークルカットのイラストを受領し、技術書典マイページを更新する Vtuberが良い感じに仕上げてくれる
01/31 サークル申し込み応募終了  
02/05 当落発表 転職活動中だったので受かってしまったか...となる。書くしかない
02/07 表紙などのデザインを依頼 対象は①表表紙 ②裏表紙 ③ダウンロードカード
02/10 Re:VIEW用環境構築 最初はC89-FirstStepReVIEW-v2を使っていたが途中でビルドエラーになった時にReVIEW-Templateに切り替えた
02/20 サークル配置発表日 Kubernetes関連なのでクラウド島に
03/17 技術書典6 もくもく執筆レビュー会 ～進捗はそこにあるか～に参加する ある程度書いている人も全く書いてない人もいた
03/17 一般参加者向け正式サイトオープン ここから宣伝が始まる
03/24 表表紙と裏表紙のイラストが完成  
04/01 原稿入稿予定日 20%OFFの恩恵にあやかろうとしたが完成せず断念
04/02 原稿入稿日 15%OFFの恩恵にあやかる
04/02 ダウンロードカード入稿第一回目 NGがあり翌日にリトライ
04/03 ダウンロードカード入稿第二回目 2回目の正直でOKに
04/05 サークル通行証が発行される サークル主含めた枚数なので注意
04/06 ダウンロードカード受領  
04/06 かんたん後払いの設定をしておく 絶対やった方が良いと思う
04/10 見本誌の提出締め切り  
04/13 小物の準備

意外とやることが多い。

4/15のCNDF 前夜祭MeetupのLT資料も用意する
04/14 技術書典6当日 わいわい
04/14 BOOTHにて電子版の販売を開始する  
04/15 CloudNativeDays Fukuoka参加 福岡へ飛ぶ。クラウドネイティブやっていく
02/10~04/02 ひたすら書く 一番重要。頑張る

 

出展に関する留意点

【保存版】 #技術書典 初出展マニュアル【表紙入稿データサンプル付き】 - #がみぶろでも触れてありますが、私からも下記は気をつけた方が良いかなと思いました。

  • 印刷用の本文入稿データは、ページ数を4の倍数にする必要がある
  • ページ数が決まらないと背幅が決まらず表紙データを確定できない
  • 印刷用のデータ入稿は、本文(PDF/X)と表紙(PSD)データを分けておく
  • 印刷用のPDFはノンブルを付けたりフォントを埋め込んだり加工が必要
  • 電子版(PDF)は本文と表紙を結合するor別データとして提供する(任意)
  • 値札の用意やお品書きなどは完全にDIYなので頑張る。最悪本当の手作りでもなんとかなる

 

やっていったこと詳細

※必要になった時に気長に読んでください

 01/09 サークル申し込み

 転職活動を開始したこともあり悩みましたが、結局申し込みました。

 たしか深夜3時くらいだったので、変なテンションだったのかも。

 

 入力情報は下記

  • サークル情報(サークル名とか頒布物とか。後から更新も可能)
  • サークルカット(あれば)
  • 代表者情報
  • 備考

01/09 サークルカットのイラストを依頼

サークルカットは申し込み締め切りの1/31までに登録する必要があったので、友人に頼みました。

伝手がない場合はTwitter上で募集したりプロに依頼したり、自分で書いたりと、いくつか方法があります。

 

f:id:go_vargo:20190418143648p:plain

01/19 「技術書典6 はじめてのサークル参加meetup(休日版)」に参加する

TechBoosterさんが主宰のMeetup「技術書典6 はじめてのサークル参加meetup(休日版)」に参加して、色々な疑問を解消しました。

techbookfest.connpass.com

 

ダウンロードカードってなんなの？ とか 印刷所に何をどう持ち込めば良いか分からない！ とか素朴な疑問を解消できます。

事前に参加しておいてよかったな、と今でも思います。 

01/19 依頼したサークルカットのイラストを受領し、技術書典マイページを更新する 

ジェバンニが良い仕事をしてくれるので、技術書典のマイページからサークルカットを登録します。

Webサイト用と印刷用のグレースケール化したものの2種類が必要なので注意しましょう

01/31 サークル申し込み応募終了

当落日を待つのみ・・・

02/05 当落発表

運命の当落日です。

自分は落ちたら潔く転職活動に専念しようと思っていましたが、当選しました。

書くしかない...!

02/07   表紙などのデザインを依頼

当選したので、改めてイラスト・デザインを発注しました。報酬は焼肉です。

  • 表表紙
  • 裏表紙
  • ダウンロードカード

を依頼しました。後からA2ポスターのデザインもお願いしました。

02/10 Re:VIEW用環境構築

執筆で使うRe:VIEWの環境構築やGitHubリポジトリの作成、CircleCIでのPipeline構築をしました。

詳細は下記を読むことをオススメします。自分で調べるのは結構大変だと思います。

この2冊は、執筆以外の準備も含めて何度も何度も読み返していました。

 

booth.pm

 

techbooster.booth.pm

 

Re:VIEWはVersion2を使っていましたが、改善版のVersion3が存在しています。

今回の執筆では躓きたくなかったので 2系のまま使っていました。

次回からは3系にしようと思っています。

 

表記ゆれもCIでチェックできるので、表記ゆれの対象になるルールは早めに追加しておくと吉です。

02/20 サークル配置発表日

配置場所が発表されます。

自分はKubernetes関連の周辺エコシステムなのでクラウド島に配置になりました。

クラウドネイティブ関連は今回一箇所に集まっていましたね。

03/17 「技術書典6 もくもく執筆レビュー会 ～進捗はそこにあるか～」に参加する

TechBoosterさんが主宰のMeetupでサークル出展者限定のもくもく会に参加しました。

techbookfest.connpass.com

 

基本はもくもく、質問があればTechBoosterさんに聞けたり、達人出版会の方にレビューしていただいたりすることができます。

 

参加して一番良かったのはその場で知り合えたサークル仲間が増えたことです。

ジャンルも内容も違う方達でしたが、同じ目標を向く仲間が増えたのは心強かったです。 

03/17 一般参加者向け正式サイトオープン

一般参加者向けに公開用サイトがオープンしました。

ここからBlogやTwitterでの宣伝が加速していきます。

03/24 表表紙と裏表紙のイラストが完成

ジェバンニが再び良い仕事をしてくれます。

3月末といえば原稿ができていてもおかしくない時期ですが、まだまだ本文は完成せず・・・

 

f:id:go_vargo:20190418143917p:plain

04/01 原稿入稿予定日

この時点で本文だけで130ページほどありました。

書きたいことを書き終えて、あとは校正と見直しチェックを残した状態です。

 

そんな中、体調を崩してしまい発熱・・・

どうしても早割の恩恵を受けたくて横になりながら校正をしていました

誰だ、こんなに書いたやつは・・・ 

02/10~04/02 ひたすら書く

ひたすら書きます。

2月/3月は終電まで残業しつつ、転職活動と退職交渉をしていたので基本は土日に執筆していました。

ただでさえ中々発生しないビッグイベントをしつつ並行して書くと、ストレスが爆発するので執筆に専念する環境をなるべく整えましょう(体重が3,4kgほど減りましたが、最近ようやく戻りました)。

内容に妥協しないぞ！ と決意するもページ数が130を超えた時点で印刷代が爆上がりする&締め切りが3日早まるという理由から内容を削る方向に...

 

以下ポエムです

 

技術書執筆ってソフトウェア開発じゃね？

と書いている最中に思いました。

ソースにあたるのが本文で、CIで静的解析したりビルドで成果物(PDF)を作ったりします。

いかにもソフトウェア開発っぽくないですか？

 

要件(何を書くか)を決めて、設計(どういった目次で章立てするか)を考え、実装し(本文を書く)、試験(校正)をしていきます。

 

ソースを書いていると「ああ、ここはこうした方がもっとよくなるな」と仕様変更(発注元: 自分)が入りますし、「ここ間違ってるじゃん！」とバグの修正も行います。

ビルドが成功し、成果物(PDF)を見て「よし、ここは作り直しだ！」なんていう確認作業はまさにテストです。

少しずつ書いてPDFを眺めるのはユニットテストですし、節をくっつけて章単位で振り返るのは結合テストで、丸ごと全章通すのは総合テストです。

 

確認したはずなのにバグ(誤字・脱字など)は後からいくつも見つかるし、完璧なものよりもまずは納期！ といって進めていくのはプロジェクトあるあるじゃないでしょうか。

 

書き方の統一をしたり、ファイルの命名規約を決めたり、リファクタリングをしたり、ソフトウェアの問題が起きて解消できないときはどう対策するかどう回避するか対応を考えたりしつつ、決められた納期に向かって成果物を作っていくのは、一大プロジェクトです。

 

何事にも通じるものはあるんだなー、と感じた技術書執筆でした。

04/02 原稿入稿日

04/01の時点で入稿できなかったため、リベンジで翌日に入稿しました。

USBにデータを入れて、日光企画さんの御茶ノ水店に直接持ち込みました。

 

技術書典しめきり＆新刊応援企画が実施されています。

キャンペーンとしてA2ポスターが無料なので、申し込みました。

事前にA2ポスター用のテンプレートを取得してイラストを仕上げておく必要があります。

 

f:id:go_vargo:20190418150308p:plain

 

申し込み情報は次のような情報を入力します。 

  • 全般
    • 書籍タイトル:自作アプリをHelm化して簡単デプロイ
    • サイズ: B5
    • 表紙込みページ数: 128ページ
    • 印刷部数: 100冊
    • トジ方向: 左トジ
    • トジ種類: 平トジ（固定）
  • 表紙
    • 用紙: NPホワイト200kg
    • PP加工: なし
    • 作成環境（表紙）: Windowsでclip studio paint ex ver1.6.8
    • 作成環境（本文）: MacOSでPDF/X(Re:VIEW + Adobe Acrobat)
  • 本文
    • 用紙: 上質90kg
    • 作成環境: MacでPDF/X出力
  • 搬入
    • イベント名: 技術書典6
    • 会場名: 池袋サンシャインシティ2F展示ホールD
    • スペースNo: う44
    • サークル名: アルハンブラの畔
    • 全部搬入？: 100冊全部搬入
  • 連絡先
    • 氏名
    • 電話番号
    • メールアドレス
    • 住所

 

入稿プランも事前に決めておく必要があります。

 

私は本文124ページ + 表紙4ページ = 全128ページ

オンデマンド平トジフルカラーセット(表紙カラー,本文モノクロ)

で申し込みました。

早割が効いて15%OFFでした（ページ数が多いので割引が効くか効かないかが死活問題でした）。

 

当初サークルチェック数が50いかないくらいだったので部数は非常に悩みましたが、50部の予定から100部に変更しました。

当日の状況を振り返ると150部は刷れば良かったな、と今は思いますが、当時は100部も刷って本当に大丈夫なのだろうか...と不安でした。ほぼ運ゲーです(当日の呼びかけ方でも結果が変わってくるので)。

部数は予想できてもあくまで予想なので、お財布とよく相談して申し込むことをオススメします。

 

入稿プランを決めるには次の要素を決める必要があります。

分からないものがあれば事前に調べておきましょう。

  • オフセット印刷(大量印刷向け)/オンデマンド印刷(少部数向け)
  • プラン(スタンダードフルカラー)
  • 表紙の用紙、印刷方法、PP貼り
  • 本文の用紙、印刷方法
  • トジ方法、トジ方向
    • オフセットで横書きなら、普通は「平トジ/左トジ」
  • ページ数(本文のページ数、表紙のページ数)、発行部数
  • 遊び紙の有無

 

持っていったデータのPDFサイズがB5のはずがA4だったり、表紙幅の計算が足りなく「このままだと見切れてしまう」状態になったりと、トラブルもありましたが、店員さんが非常に優しく教えていただいてなんとかなりました。

以下詳細です。

 

PDF A4問題

PDFサイズがB5のはずがA4だったのは次のnoteにもありますが、MacのプレビューアプリのデフォルトサイズがA4だったため、気づかずにA4で保存してしまっていたためでした。

#技術書典 初サークル参加から「jQuery to Vue.jsで学ぶ レガシーフロントエンド安全改善ガイド」200部完売までの軌跡｜mugi_uno｜note

 

PDFをプレビューアプリで編集したのはノンブル用のフォント埋め込みをしたためですが、Re:VIEWによって書かれるページ番号がノンブルの代わりになったのでそもそもの対応が不要でした。

そのためノンブルを入れず、B5でビルドした状態でAdobe Acrobatで形式変更/モノクロ化だけ行いました。

 

参考: ノンブルってなんですか？

https://mikan-no-ki.com/faq/55

 

 ノンブルの埋め込み方法については技術同人誌を書こう！　アウトプットのススメが詳しく、AdobeAcrobatでの形式変更/モノクロ化については技術書をかこう！ ～はじめてのRe:VIEW～が詳しいです。

表紙見切れる問題

日光企画さんはホームページ上でテンプレートファイルを用意しています。

そのテンプレートファイルに背幅計算用の目盛りが付いていますが、どうやら背幅の計算が間違っていたらしく、そのまま印刷すると見切れる状態になってしまうようでした。

表紙イラストは完全に人任せだったので私はイラストツール自体持っていなく、どうしようかと路頭にくれていました。

しかし、店員さんがその場でPhotoShopを使って修正してくださり事無きを得ました(神！)

完全におんぶに抱っこになってしまい非常に申し訳なかったのですが、命拾いしました。

日光企画さん、ありがとうございます。

(最初から調整した状態で持っていきましょう！ 私もそうします) 

04/02 ダウンロードカード入稿第一回目

ダウンロードカードは、オンデマンド名刺(両面印刷/表面カラー/裏面モノクロ)で200部申し込みました。

ダウンロードカードはPSD形式のファイルをグラフィックさんでWeb入稿しました。

提出した結果、次の回答をいただきました。

 

テンプレートのレイヤーとデザインレイヤーが統合されており、テンプレートの青い罫線部分を削除することが出来ません

 

とのことだったので、Vtuberに直してもらいました。

04/03  ダウンロードカード入稿第二回目

ダウンロードカードを修正して再度アップロードしました。

修正後のチェックはOKでした。

 

f:id:go_vargo:20190418150932p:plain

 

ダウンロードカードはBOOTHにダウンロードカード用の0円の商品を置き、

パスワードを入力してZIPを解凍する形式を取りました。

 

ただ、技術書典6の数日前に公式でのダウンロード機能が配信されたため、

次回以降は公式機能の方を使おうと思います。

04/05 サークル通行証が発行される

サークル通行証が発行されます。デフォルトでは2枚で、サークル代表者含めた人数分なので注意が必要です。

04/06 ダウンロードカード受領

ダウンロードカードを受け取ります。

本の印刷の方は技術書典当日まで見れないので、初めて形あるものを見てテンションが上がります。

 

f:id:go_vargo:20190418152411j:plain 

04/06 かんたん後払いの設定をしておく

かんたん後払いは会場でキャッシュレスで買い物ができる仕組みです。

かんたん後払いを利用するには、事前に公式マイページで口座情報の登録が必要です。

 

詳細はリンクを参照してください。

blog.techbookfest.org

04/10見本誌の提出締め切り

見本誌の事前提出は技術書典6から必須になりました。

これも公式マイページから電子版をPDFで提出することができます。

 

詳細はリンクを参照してください。

blog.techbookfest.org 

04/13 小物の準備

小物として、見本誌カバーや値札、お品書きなどの準備が必要になります。

前日に行う必要はありませんが、Meetupに参加したり退職に伴う送別会に参加したりで小物の準備が遅くなりました。

 

以下準備したものです。

  • カード立て
  • ポスタースタンド
  • テーブルクロス
  • 両替用袋
  • 集金袋
  • 見本誌カバー
  • 見本誌用ブックスタンド
  • マーカー
  • 色鉛筆
  • スケッチブック
  • マーキングテープ
  • 両面テープ

  • ハサミ

  • 名札

カード立て

ダウンロードカードの見本や値札として利用しました。

値札を印刷して入れるカード立てに入れる例が一般的だと思いますが、

やり方(紙の種類・使用ソフト)が分からず、普通に手書きしました。

タカ印 ポップ スタンド カード立 L型 34-3220 透明 58×86mm表示 10個

タカ印 ポップ スタンド カード立 L型 34-3220 透明 58×86mm表示 10個

 

ポスタースタンド

日光企画さんで無料で作ったA2ポスター用に使いました。 

AZAKBL POPスタンド 長さ調節可能 フロアスタンド 持ち運びに便利 簡単収納 組み立て式 広告スタンド (１個入り)

AZAKBL POPスタンド 長さ調節可能 フロアスタンド 持ち運びに便利 簡単収納 組み立て式 広告スタンド (１個入り)

 

テーブルクロス

あの布です。1m×1mあれば十分です。

布人倶楽部 綿100% 無地オックス サックス 108cm幅x1mカットクロス

布人倶楽部 綿100% 無地オックス サックス 108cm幅x1mカットクロス

 

両替用袋

両替用の千円札を入れておきました。家にすでにあったものを使いました。

集金袋

売り上げのお札を入れておく袋です。家にすでにあったものを使いました。

見本誌カバー

ダイソーで書いました。2冊分買えばよかった。。。

見本誌用ブックスタンド

見本誌を置くブックスタンドを用意します。持っていなかったので次のものを購入しました。

actto BST-02 ブックスタンド

actto BST-02 ブックスタンド

 

マーカー

あると便利です。完売や在庫数などを書くのに使います

色鉛筆,スケッチブック

お品書きを書くためにスケッチブックと色鉛筆を使いました。

微妙にアナログでしたが、個人的には味が出て気に入っています。

マーキングテープ,両面テープ

物の固定に使います。 

ハサミ

ダンボールの開封に使います。カッターでも可。

名札

Twitterをアイコンでやっている場合はあった方が良いと思います。

ありがたいことに自分に会いに来てくれる人がいるときは、名札が識別子になります。

売り子も何人かいた時の識別に役立ちます。

ダイソーで買って、Excelで加工したものを印刷して入れました。

より良い方法があれば知りたい...

 

 

全く関係ありませんが、次の資料が同じく13日に用意したLT資料です。

だいぶ時間がなかったので1日で仕上げましたが、当日の発表では需要があったようで何よりでした。

speakerdeck.com

04/14 技術書典6当日

技術書典6当日です！

09:50くらいにサークル入場が開始され、まずはブースの場所と本が届いているかを確認します。

「おお、ほんとうに本になってる...！」と感動するのも束の間、1時間後には開場になるので急いで準備します。

作業スペースが意外と狭いので気をつけて作業します。

 

f:id:go_vargo:20190418160257j:plain

ブース設置の様子

完売自体は14:55頃でした。

もし、もう少し在庫があればもっと頒布できそうな気配もありそうでした。

 

物理本完売後もダウンロードカードの在庫は有りましたが、どちらかというと紙の本がないから仕方なく買っていく方も多いのかな、という印象でした。

完売以前にもダウンロードカード単体で購入いただける場合もありました。どちらも在庫を用意しておいた方が良いですね。

04/14 BOOTHにて電子版の販売を開始する

技術書典6当日の夜にBOOTHで電子版を販売しました。

手数料0なのでありがたいですね。

 

電子版は、もともと別データだった本文と表紙を結合する必要があります。

Re:VIEWの設定を変えて表紙のimgファイルを指定する方法もありますが、

2系だと扉絵を表示しないようにすると表紙も表示されないissueがあったため、

AdobeAcrobatでPDFを編集することで問題を回避しました(3系だと直っている)。

PDFは作れる。

 

形式もサークルによってPDFやEPUBなど色々な選択肢があります。

go-vargo.booth.pm

04/15 CloudNativeDays Fukuoka参加

技術書典が終わって翌日には福岡にイベントに参加しに行きました。

Cloud Nativeはやっぱり面白いなー、というのが一番の感想で色々な学びがありました。

cloudnativedays.jp

 

技術書典のすぐ後ということもありますが、本を購入してくださった方も何人かいらっしゃり、話ができたり本の出来を褒めていただいたりして非常に嬉しく思いました。

 

CloudNativeのMeetupやカンファレンスに参加する人たちならHelmを既に理解していて、もはや本など必要ないのではと謎の被害妄想に包まれていましたが、需要はちゃんとあったんだな、と知って安心しました。

(Helmを既に理解している人にはリファレンスとして使えるように設計していました)

 

気になる収支

気になるか分かりませんが予算感がわかるように、今回の収支を載せておきます。

支出

印刷費用 90,130 × 0.85(15%早割) = 76,610円

ダウンロードカード印刷費用 2,071円

サークル参加費: 7,000円

テーブルクロス: 950円

カード立て: 1,129円

ブックスタンド: 1,480円

ポスタースタンド: 1,080円

その他雑費(小物): 1,000円

イラスト報酬(焼肉代): 16,000円

自分の人件費: プライスレス

合計: 107,320円

収入

書籍(+ダウンロードカード) 1,000円 × 100部 = 100,000円

ダウンロードカード 1,000円 × 20枚 = 20,000円

BOOTH販売 1,000円 × 15 = 15,000円

 

次へのモチベーション

次回の技術書典7もサークル出展で参加したい！

という思いでいっぱいです。申し込みもまだまだですが、当選してほしいです。

当選したらKubernetesかCNCFでホストされているKubernetes周辺エコシステムで書くと思います。

すでに個人的にはネタが2つあります。

 

CNCFもプロダクトがたくさんあるのであと600冊は出せますね(出すとは言ってない)。

 

さいごに

以上がサークル参加のための活動の内容でした。

 

イメージ湧いたでしょうか？ 自分もやりたいと思ったでしょうか？

どんどんやっていきましょう！

 

ブログの内容は引用してもらって構いませんし、参考にしてくれたら書いた甲斐があります。