こまぶろ

技術のこととか仕事のこととか。

『つくって、壊して、直して学ぶ Kubernetes入門』を読んだ

『つくって、壊して、直して学ぶ Kubernetes入門』を読んだ。

※翔泳社の直販サイトSEshopでは5/9までPDF版が50%ポイント還元で買える。

www.seshop.com

著者の方のブログ。

blux.hatenablog.com


Dockerは業務でも日頃から使っているが、Kubernetesは使ったことがなく、ちゃんと勉強したこともなかった。「Kubernetesが必要になるようなシステムは稀」という言説をしばしば目にすることもあり、まぁ必要になったら勉強すればよかろうというスタンスでいたのだけれど、何も知らないのもあれだよなという思いもないではなかったので、TLで話題になっていて(前述の翔泳社の50%還元もあり)読むことにした。

全体像〜Part 1 つくってみようKubernetes

この本の想定読者は、「Docker は触ったことがあるものの、Kubernetes を全く触ったことがない方」であり、自分はまさにこれに当てはまっている。最後まで読み進めても、知らないのはKubernetesエコシステムの話がほとんどで、書籍の狙い通りの学習をすることができたと思う。

内容としては、タイトルの通り、Kubernetesクラスタを作成し、(誤った設定をapplyして)壊し、kubectlなどを駆使しながら調査し、設定を間違いを修正して直す、というのがメイン(Part 2)で、Part 1ではその前段としてのKubernetesの入門の入門(Docker入門を含む)、Part 3ではKubernetesの仕組みやエコシステムを構成する周辺ツールの解説などやや発展的な内容が扱われている。

自分は前述の通り、Kubernetesの知識はほとんどなく、PodとかServiceっていう概念があるんでしょ、という程度のところからスタートしているので、Part 1の内容から役に立った。Dockerの入門も一応あるので、「Dockerを使ったことがある人」でなくても読むことはできると思う。

Part 2 アプリケーションを壊して学ぶKubernetes

本編ともいえるPart 2では、Kubernetesの最も基本的な単位であるPodから始まって、ServiceやConfigMap、各種probe、リソースに関する設定項目、スケジューリングのための設定などを学んだ。Kubernetesを使ったことはないが、AWS上でコンテナアプリケーションをECSなどを使って運用していたりはするので、「Kubernetesではこういうふうに扱うのかー」と思いながら理解した部分も多かった。

ハンズオンでは、トラブルシューティングの際に問題の切り分けを行うためのアプローチの仕方やそこで使う基本的なコマンドが説明されており、わかりやすかった。とはいえ、この本のトラブルシューティングの例は実際に起きるものよりはかなり単純化されたもので、この本を読んだだけで実践までできるようになるわけではないとはレビュワーの方も述べているので、本格的に実践していくにあたってはChapter 12で紹介されているようなより発展的な書籍やリソースが必須になるのだろう。入門者の立場からすると勉強になったしわかりやすかったと思うが、その先まで見据えたときに本当に入門書としての役割を果たせているかの評価は今の自分にはできない。

ハンズオンパートについてよかった点を1つ挙げておく。今回自分はMacでハンズオンの部分を実践したが、ローカルクラスタを作るツールとして本書で主に使われているkindのおかげで環境が汚れることを気にせずにクラスタを作っては捨てるのを繰り返すことができたのが快適だった。ハンズオンの類では書かれている通りに動かなかったり、うっかりミスでローカル環境を汚してしまって進められなくなるというのが起きがちだと思うのだが、その心配がなかったのが著者の意図した学習体験をスムーズに実現する上で役に立っていたと思う。

Part 3 壊れても動くKubernetes

Part 3は、Kubernetesのアークテクチャ、Kubernetesを利用する際の開発フローやオブザーバビリティについてで、開発フローの章ではHelmやKustomize、オブザーバビリティの章ではGrafanaやPrometheusの使い方の説明をしていた。個々のツールについての解説はそこまでボリュームが大きいわけでもなくあっさりとしたものだったとは思うが、詳細については別の書籍や公式ドキュメントを参照すべきだろう。

個人的に印象に残ったのは、Pull型とPush型の違いが複数の箇所で出てきたことだ。まず、Kubernetesのアーキテクチャとして、Control Planeから個々のWorker Nodeに指示を与えるのではなく、Worker Nodeが Control Planeを参照して動作するという話。また、CIOpsとGitOpsの違いとして、前者がCI側からのPush型であるのに対し、後者はCIに対するPull型であるという話。そして、DatadogとPrometheusのデータ収集の仕方について、前者がPush型であるのに対して後者がPull型であるという話が出てきた。Push型とPull型の違いというのは様々な場面に出てくる設計上の違いで、どちらを採用するかによってシステムが持つ性質が変わってくる。これは日頃のソフトウェア開発でもよく出てくる設計判断のポイントだと思うが、この書籍の中だけでも上記の3つが出てきていたのが印象に残った。

おわりに

前述の通り、自分は本当に入門者であるので、この本が入門書としての役割を適切に果たせているかどうかの判断はできない。しかし、総じて読みやすかったとは思うし、つまずいてしまって先に進めないとか、書籍の説明が前提としている事柄がわからなくて困るという場面がなかったことは確かだ。本番の運用に足る知識を得られたとは思わないが、概要の理解はできたと感じるので、読む前に感じていた「Kubernetesは当面は使う機会がないけど、全く知らないのもなー」という漠然とした問題関心には十分に応えてくれたと思う。

続:Keynote で作成したスライドを Speaker Deck にアップロードすると Transcript が文字化けする問題への対応

Keynote で作成したスライドを Speaker Deck にアップロードすると Transcript が文字化けする問題があり、その対処法を以下の記事で紹介していた。

ky-yk-d.hatenablog.com

最近のMacはPostScriptをビルトインでサポートしなくなった

しかし、記事の中で言及していたMacの「プレビュー」がPostScriptファイルのサポートをやめてしまったため、現在ではPostScriptからPDFに変換する部分は別のツールを使って行う必要がある。

support.apple.com

代わりのツールの一つ:Ghostscript

この記事では、代替の方法のひとつとして、Ghostscriptを紹介する。

www.ghostscript.com

Macの場合、Homebrewでインストールするのが簡単だろう。

$ brew install ghostscript

GhostscriptでPostScriptからPDFに変換する

Keynoteから「プリント」→「PostScriptとして保存」として作成したPostScript(ps)ファイルを、Ghostscriptの ps2pdf を使ってPDFに変換することができる。

$ ps2pdf input.ps output.pdf

こうして作成したPDFをSpeaker Deckにアップロードすれば、文字化けを回避することができる。

補足

手元の環境で作成したpsファイルでは、 ps2pdf では以下のようにエラーになり変換できなかった。

$ ps2pdf input.ps output.pdf
GPL Ghostscript 10.03.0: PDFDocEncoding ad is undefined

@toshimaru_eさんの手元では ps2pdf でも変換ができているようなので、ファイル側に問題があるように思われる。

なお、原因は特定できていないのだが、同じファイルもPDF 1.3を用いる ps2pdf13 を使えば変換することができた。

$ ps2pdf13 input.ps output.pdf

謝辞

以前書いた記事の方法が現在では一部使えなくなっていること、Ghostscriptで代替できることを指摘してくださり、 ps2pdf での動作の状況も教えていただいた@toshimaru_eさんに感謝します。

MacでDocker Desktop4.27.0に上げたらMySQL 5.7(amd)のコンテナが動かなくなった場合の対処法

追記

Docker Desktop は runcの脆弱性対応で2024/2/2現在の最新はv4.27.1になっています。

www.docker.com

環境

事象

Docker Desktopのバージョンをv4.27.0に上げたところ、これまで使用できていたmysql:5.7のDockerコンテナが起動できなくなった。

エラーメッセージは、以下のようなもの。

2024-02-01 17:38:46 2024-02-01 17:38:46+09:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.43-1.el7 started.
2024-02-01 17:38:46     qemu: uncaught target signal 11 (Segmentation fault) - core dumped

対処法

MySQL 5.7の公式Dockerイメージにはarm版が存在せず、amd版をApple Silicon上で動作させていたが、バージョンが上がったことでqemuでは動作しなくなった模様。

qemuではなくRosettaを使うように設定を変更することで、動作するようになった。Docker DesktopのSettings > General から、"Use Rosetta for x86/amd64 emulation on Apple Silicon"にチェックをつけて再起動すればよい。

SettingsのGeneralタブで、Use Rosetta for x86/amd64 emulation on Apple Siliconにチェックがついています

なお、macOSがMonteleyではこの設定項目が表示されずRosettaが使えないようなので、その場合はVentura以降にOSバージョンを上げればよい。また、macOS 14.1以降でDocker Desktopを動かしている場合はデフォルトでqemuではなくRosettaが使われるようになっているとのこと。

Rosetta for LinuxはAppleシリコンを搭載したMacのmacOS 13.0以降で使用可能。macOS 14.1以降ではデフォルトで有効になっているとのことです。

www.publickey1.jp

良い子のみんなは早くMySQL 5.7を脱却して8.0に行きましょう

2023年に読んで印象に残った本、読書に関するふりかえり

年の瀬なので、今年読んだ本のふりかえりをば。それではレッツゴー!

実践的データ基盤への処方箋

会社でデータ基盤周りのことを考える機会があったので読んだ。データ基盤素人にもわかりやすく書かれていたと思う。最初の一冊として良いというのを同僚のデータエンジニアからも言われた。

Webブラウザセキュリティ

認証認可周りを触る機会があったので読んだ。Webアプリケーションのセキュリティに関しては徳丸本などもあるけど、この本はブラウザに特化していて仕様の話なども充実しているので面白かった。

図解即戦力 暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書

これも認証認可周りを触るときに読んだ。「図解」とあるので初歩的なものをイメージしがち(自分はそう)なのだが、これはなかなか骨太で、数学的な部分も入ってくる。しかしそれでいて読みづらくはないというのが素晴らしいと思う。

誤謬論入門

ky-yk-d.hatenablog.com

ブログにしたもの。IT系とは別のところで反響が大きかった。インターネット上の言説に違和感を感じるときにこの本の整理を参照すると少し違和感をクリアにできる。

アジャイルプラクティスガイドブック

Rettyの常松さんの著書。スクラム関係の本やアウトプットが多いのに対して、アジャイルの技術的プラクティスについてはあまりまとまった形で出てくることがないなと感じているなかで、待望の一冊だった。

アジャイル開発をする上で悩んでいることがある開発者のみなさんは自分も運営で関わっているScrum Developers Night!をよろしく(以下のページは前回開催時のもの。次回開催の案内は2月を予定していますので、Scrum Masters Night!*1のconnpassのグループに参加して通知をお待ちください)。

smn.connpass.com

世界一流エンジニアの思考法

マイクロソフトの牛尾さんの著書。noteやブログで牛尾さんがどういうことを感じている/考えているのかは以前からウォッチしていたが、それが書籍という形でまとまったもの。想定読者としては現場のエンジニアよりも「管理者」向けの側面が大きい(倉貫さんの『人が増えても速くならない』に近いものがある)と感じるのだが、最初の方に書かれている牛尾さんの周囲の優秀なエンジニアの行動パターンの話は非常に興味深く読んだ。

特に、「理解に時間をかける」という話が印象的だった。自分の所属する会社でも学習への投資が積極的に行われている(下記のブログ参照)のだが、ついつい目の前の仕事を前に進めるために不十分な理解を放置して進んでしまいがちだと感じていたのだが、やはり理解に時間をかけてスキルを伸ばすことが将来的にいい仕事をするためにも必要で、自社のマネージャーもそれを期待しているということもあって、この本を読んだ頃からは以前よりも「理解に時間をかける」ようになった(もちろん時にはスピードを重視しないといけない場合もあるだろうけど)。

tech.bm-sms.co.jp

Linuxのしくみ

ky-yk-d.hatenablog.com

こちらもブログにしたもの。秋以降は『プログラマーのためのCPU入門』、『コンテナセキュリティ』、そして現在は『詳解システム・パフォーマンス』と(アプリケーション開発者から見た)低レベルのところに意識的に取り組んでいる。記事にも書いたが、最初に読む本として『Linuxのしくみ』は非常におすすめ。

プロダクトマネージャーのしごと

自分はプロダクトマネージャーではないが、プロダクトマネージャーに限定されない仕事の考え方の話も書かれているという評判を目にして読んだ。たしかにそういう側面もある本で、時々読み返す本になりそうだと思った。

特に印象に残っているのは「過剰コミュニケーション」の話と、

「最初のドラフトは1ページで、作るのに1時間以上かけない」という話。

数年前、私はビジネスパートナーたちに「チームにドキュメントに使う時間と労力を減らせとコーチする割には、いまだにあなた自身は内部ミーティング資料を念入りに作り込んでいるんですね」と指摘されました。私が「当然ですよ。あなたたちは優秀だからいいけど、私は仕事をちゃんとやってるって思わせたいんです」と言うと、全員が一瞬固まりました。「はぁ」。

(『プロダクトマネージャーのしごと』p.154)

www.mindtheproduct.com

www.onepageonehour.com

2024年に向けて

来年の4月でソフトウェア開発者として働き始めてから7年が経つことになる。

ソフトウェア開発関連の書籍を読むことはキャリア初期から自分を大いに助けてくれてきたのだが、この1,2年くらいは仕事で向き合う課題が単なる知識不足では解決できないものが多くなってきて、以前ほど書籍を読むことの意義が感じられなくなってきている側面があり、以前ほどたくさん本を読まなくなっていた(2022年末のサッカーW杯でサッカーにどハマりして休日の夜が欧州サッカーで消費されるようになったのと、2023年1月クールのアニメ「お兄ちゃんはおしまい!」で声優・アーティストの石原夏織さんのファンとしての動きを再開したのとで、そもそも学習にかける時間が減ってしまったというのも大きいのだが)。


www.youtube.com

しかし、2023年後半からはややバランスを取り戻して、学習への時間を増やし始められている。書籍を読むことで解決する仕事上の課題が増えたわけではないのだが、周りのシニアなエンジニアと話していると自分が知らないことをたくさん知っているなと感じることが多くあるので、仕事基準ではなく人基準で足りないところを埋めていこうと思って勉強をしている。

また、↓で書いた毎日1ページでもいいので本を読むという活動に参加したこともいいきっかけになっている。やはりピアプレッシャーは習慣化の大きな助けになる。

この活動は「みんチャレ」というアプリを使ってやっていて、5人1組でヨーイドンで始めるものなので現在自分の参加しているグループに追加で参加してもらうことはできないのだが、仲間さえ集まれば簡単に(アプリは無課金でも利用できる)始められるので、興味がある人がいたら周囲の人に声をかけてみるといいと思う。

minchalle.com

そういうわけで、2024年はより一層ペースを守って勉強することを重視したいと思います。みなさん良いお年を。

*1:Scrum Developers Night!はScrum Masters Night!の派生イベントで、同じconnpassに同居しています。Scrum Masters Night!もエンジニア歓迎だと思うのでそちらもぜひどうぞ。

1年間積読になっていた『Linuxのしくみ』を読んだ

この記事は、「積読 Advent Calendar 2023」6日目の記事です。

adventar.org

昨日の記事は @hanhan1978 さんの記事でした。


『[試して理解]Linuxのしくみ ―実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】』を読みました。発売日は2022年10月17日で、発売されて割とすぐに買った記憶がある(現在は3刷までは少なくとも出ているようだが、手元にあるのは1刷)のですが、1年経ってようやく読みました。

gihyo.jp

なぜ買ったのか

自分の主戦場とする領域の1つ下のレイヤの知識を知っておきたかったからです。

自分は普段、Webアプリケーションの開発をしていて、バックエンドを主に触っています。学生時代の専門は情報系ではなく、成り行きでソフトウェア開発の会社に就職することになってからプログラミングを学びました。

就職してからは、コードの書き方や設計の考え方、あるいは開発プロセスについて関心が強く本をよく読んでいたほか、仕事で使うミドルウェアやツールをユーザーとして学ぶ(ex. MySQLのインデックスの使われ方や最適化がどうとか)ことはあったものの、インフラのレイヤのことをちゃんと学ばない(仕事で接するたびにその部分だけ調べる程度)まま生きてきてしまいました。目の前の仕事をこなすだけならそこまで困るわけではないのだけど、技術者としてはやはりそこもわかるようになっておきたいなという思いを持っていました。

同じ背景で、少し前(2022年1月に読み終わっているようです)に『コンピュータアーキテクチャのエッセンス』は読んだものの、ハードウェアの話が中心なので正直ピンと来ず、自分の普段触っているレイヤとの隣接性も感じられなかったため、消化不良のままになっていました。

www.shoeisha.co.jp

そんな中で、『Linuxのしくみ』の増補改訂版が出るよ、カラーになって読みやすいよ、プログラマにもおすすめだよ、というのをTwitterで見かけて、これだったら興味を持てるかもしれないと思って買ったのでした。

なぜ1年間積んでいたのか

ここ1年、単純に本を読む量が減ってしまっていたというのがまず大きいです。理由は色々とありますが、これを書き始めると長くなるので省きます。

他には、やはり「仕事に短期的に直結しない本なので後回しになってしまった」というのもあります。そもそもの動機からして、「毎日の仕事をこなす分にはそこまで困っていないんだけど、読んでおきたい」という切迫感の弱いものだったし、仕事に直結する勉強(たとえば、アプリケーションの認証認可の部分を実装するにあたって、OAuthやOIDCの勉強をしたり、『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』を読んだり)と比べて具体的なきっかけを普通に仕事をしているだけで得ることが少ないので、一度積読になってしまったあとは手付かずになっていました。

なぜ今になって読んだのか

直接のきっかけは、最近仕事をしている中でスレッドやコンテキストスイッチの話を同僚とする機会があったからです。

幸いなことに現在同じチームで働いている同僚には低レベルのことをよくわかっているシニアなメンバーがいて、チーム内のコードレビューやモブプログラミングでそこの知識も踏まえて話をしてくれるのですが、「おっ、今この人の言っていることがわからないぞ」と思わされることが時折ありました(その都度説明してもらったり調べたりはする)。

そんな中で、先日スレッドやコンテキストスイッチの話になり、ぼんやりとはわかっているが理解度が全然足りないなということを改めて感じたので、重い腰を上げて読み始めました。

感想

非常に読みやすかったですし、自分が知りたいなと思っていたところを知ることができました。

「実験と図解で学ぶ」とあるように、文章での説明に加えて実験と図解が豊富にあるのですが、特に実験のパートが「サンプルコードとその出力」というプログラミング言語の書籍でよくあるものに留まっておらず、レイテンシやリソースの使用量などのデータを表やグラフにして掲載していたのが良かったです。仕組みを図や文章で説明するだけでなく、「その結果として、実行した際にどのような挙動になるのか」まで理解させてくれるのがこの本の良さだと感じました。

終章では、この本を読んだ後にどんな勉強をするとよいかという紹介がありましたが、自分の場合はWebアプリケーションの運用と開発のための知識・スキルをつけていきたいので、巨大積読である

を次は消化していきたいと思います。来年は積読を増やさず、これまでに積んできた書籍を着実に読んでいくぞ……!


『Linuxのしくみ』と前後して、関連する内容のある以下の本も読みました!積読を解消しているぞ!!!

*1:原書が『Linuxのしくみ』の終章でも紹介されていました。翻訳が出たのは今年になってからですね。