guni.log

日々の進捗・ポエムのごった煮

2020年振り返り

今年の記憶がコロナで掻き消える前に,今年あった出来事を振り返ろうと思う. そして,来年の抱負を書いておく.

1月

  • IPSJ全国大会の論文の執筆
  • 卒論の執筆

2月

  • 卒論の発表

3月

4月

  • 香川大学大学院 工学研究科 信頼性情報システム工学専攻 入学

5月 - 7月

8月

9月

10月 - 12月

  • バイト(ヘルプデスク)を辞めた
  • 研究,講義,就活の3つに苦しめられる

2020年 まとめ

思ったより就活に体力と時間を使った一年だった. まだ選考中の企業があるため,どこに就職するかは確定していないが,基盤系のソフトウェアエンジニアをやりたいと考えている.

大学院生になって思ったことは講義が予想以上に忙しかった. それで研究,講義,就活を同時進行して生活が大変なことになってしまった.

新しいマシンを組んでその上で好きなだけKubernetesで遊べるようになった. 研究システムのデプロイや,いろんな検証環境に使っている. あとはストレージ周りをいい感じにしたいので,色々思案中.

2021年の抱負

研究,講義,就活をある程度やったおかげか,単位もなんとか取れそうで,内定も頂いたので,来年度は研究に集中することができそう. 他にも勉強したいことは山程あるので,大学にいるうちにいろんなことを勉強しようと思う.

あと,今年こそブログの更新頻度をあげようと思う. ゼミの自分の週間報告にブログにしたら面白そうな技術系の話がいくつかあるので,これらをパブリックにする癖をつけたらいい感じに更新頻度も上がるんじゃないかなあ.

来年勉強していきたいこと

  • Kubernetes
    • 大学みたいなあまりスケールしない環境では必要に迫られにくく,家で細々とやっている.
    • 業務では使うだろうから,How toだけでなくアーキテクチャへの理解を深めたい
  • eBPF
    • 今はトレースツールを書いて,研究のベンチマークとかで使ったりしている程度
    • libebpfやCO-REが気になっている
  • OS
    • x86 OS自作本を途中まで読んで積んでいる…
    • RustでOSを作ってみたいと思っている
  • Network
    • CNI(Container Network Interface) あたりを追っていくのにもうちょっと基礎的な知識をつけたいかなあ.
    • XDPとか触ってみたい
  • 英語
    • Reading やListeningだけじゃなくてWritingを鍛えたい
    • 英語論文かけたら良いなあ

コンテナイメージ(の依存)はどの程度小さくすべきか?という話

全国のDockerfile職人の方々,コンテナイメージのダイエットはどのようにやっていますか? 今回はコンテナイメージの容量というよりは,依存を小さくするという意味で, コンテナイメージ内にシェルやcoreutilなどを入れるかどうかといった話について,議論したのでその内容をまとめていきたいと思います.

コンテナイメージを小さくすると何が嬉しいのか

コンテナイメージの容量を小さくするという観点だと,デプロイが高速になるため,スケールアウトするのが速くなります. また,依存を減らすという観点でいうと,脆弱性を利用した攻撃対象領域(attack surface)が少なくなります.

(余談) 後述するようなscratchにバイナリを配置するだけのコンテナイメージなら,アプリケーションしか実行しないので, Linuxのセキュリティ機構であるseccompやAppArmorの設定もアプリケーションにフィットした設定を用いる事ができると思います.

どうやってコンテナイメージの容量を小さくするのか

コンテナイメージをダイエットさせる方法としてaptなどのパッケージマネージャのcacheを消す,マルチステージビルドを使う,Alpine Linux, Scratchなどの容量の小さいイメージをベースに使うなどのテクニックを使います. ここではあまりそれらについて深く言及はしません.

これらのテクニックを用いて,コンテナイメージの容量を小さくするのは良いのですが, どこまでコンテナイメージを小さくさせるべきなのでしょう. 極端な話,コンテナ上で動くアプリケーションがGoの静的リンクされたバイナリであれば,以下のようなコンパイルしたあとscratchに配置するだけで軽量なイメージが作れると思います.

FROM golang:1.15-alpine3.12 as builder

WORKDIR /src

RUN apk add --no-cache make

COPY go.mod .
COPY go.sum .
RUN go mod download

COPY . /src
RUN make build

FROM scratch
COPY --from=builder /src/bin/hello /hello

ENTRYPOINT ["/hello"]

Kubernetesなどで使われているCoreDNSの公式イメージなどはまさにそのように提供されています. しかし,ベースにscratchを用いるとシェルも無ければlsもcatもありません. そのためコンテナ内で docker execkubectl exec でシェルを実行したり,デバッグ用のコマンドを使うことができません.

これは運用時つらいからベースをalpineやubuntuにしているという人が自分の観測範囲では多い気がしています. 検証などでシェルで入るのが手っ取り早いから,catでコンテナ内部のファイルの状態を見たいからなどの理由だと思います.

コンテナイメージにシェルやcoreutilって必要なのか?

そもそもcatやls,bashがコンテナイメージになくてもデバッグや検証とかできるんじゃないか?という仮説を考えてみます. 一応,ここではコンテナ内部に入ってアプリケーション自体に変更を加えるということは除外します. シェルやcoreutilなどが必要のない,アプリケーションだけが入ったコンテナイメージを運用する上で障害になることをいくつか考えました.

  • Q1. そもそもメトリクスやログを適切に吐いていればシェルがなくても問題ないのでは
    • ログやメトリクスを適切に吐くことが一番難しい
    • 必要なメトリクスがなかったらコンテナホストか,コンテナ内にツールを入れたり,メトリクスツールに変更を加える必要がある.
  • Q2. コンテナの中にシェルで入る必要はなくて,コンテナホストからプロセスが見えるんだからホストから見れば良くないか?
    • コンテナノードにSSHできないサービスも有る (AWS Fargateなどコンテナノホストを抽象化するサービスなど)
  • Q3. コンテナの中にログファイルがあるけどシェルがなかったら読めないよね?
    • ログはstdout, stderrに吐いてたりしてください
  • Q4. そもそもアプリケーションがシェルに依存しているんだが?
    • それはシェル入りのコンテナ使ってください
  • Q5. 開発ではシェルが入ったコンテナを使っているが,本番環境と開発環境で違うコンテナイメージを使うというのはアンチパターンじゃないか?
    • 環境ごとに違うイメージを使うのはアンチパターンだと思うけど,ビルド引数とかでビルドステージを切り替えて,ビルドステージ,実行ステージで分けて使えばいいんではないだろうか.

コンテナイメージ内に検証などでシェルやcatなどのコマンドを使ってデバッグしたかったら十分にOveservabilityの仕組みを導入することとが必要で,コンテナ内に状態を持たせないことが必要かなと. また,外部コマンドに依存したアプリケーションはその外部コマンドの脆弱性を定期的にスキャンしながら同梱したイメージを使えばよいのではなかろうかと.

まあ,PythonRubyみたいな言語はそもそも言語処理系をアプリケーションのコンテナイメージに入れる必要があるので,今回の話はシングルバイナリを吐ける言語が前提なんてですけどね….

まとめ

コンテナイメージをどこまで小さくするかはワークロード次第ですが,シングルバイナリのアプリケーションに限って言えば,十分にOveservabilityが確保できていて,開発にも支障がなければscratchベースだったり,シェルや他の依存が全く無くても良いと考えています. でもそれでも心理的にシェルがあったほうが安心だという気持ちはとても良くわかります.しかしマニュアル運用をできないようにシェルをコンテナイメージから無くすべきなのかもなあと思う今日このごろです.

もうちょっと運用サイドのエンジニアの方々の意見も聞いてみたいと思います. 実際,自社でscratchベースのコンテナイメージを自分たちで作ってホストしている方々ってどれぐらいいらっしゃるんでしょうね.

シェルなどが入っていないコンテナイメージをデバッグ,検証したかったら,KubernetesのEphemeral Containerあたりを使ってデバッグするのも良いと思います. 次回あたりにKubernetesのEphemeral Containerの機能を深堀りして使ってみたときのアレコレを書いていきます.

2019年振り返り

お久しぶりです。毎年恒例の振り返り記事です。

今年の取り組み

1. 初のISUCON予選参加

大学の先輩2人とチームを組んで出場しました。自分はNginxのHTTP/2化や静的ファイルのサーブなどをやってました。来年ははじめに計測をシュッとできるようにツール群を用意できるようにしたいですね。APMの計測をしなかったために気づけなかったボトルネックがあったので。本戦にいつか出たいので、精進します。来年組んでくれる人を募集しています。

2. Cloud Nativeへの取り組み

CNDT(Cloud Native Days Tokyo), CNDF(Cloud Native Days Fukuoka)などのイベントに参加し、Kubernetesなどの技術を中心にCloud Nativeに関する取り組みを学びました。

自分や周囲を見ているとKubernetesを導入することより、CI/CDや自動テスト、ステートレスアプリケーションの実装などに注力していくことがCloud Nativeへの近道なのかなあという印象です。

研究や業務等で分散システムの設計を行うときなどに活かせるようにやっていこうと思います。

3. 卒業研究本格始動

研究室に配属されたのは去年の10月で、研究テーマを決めたのが今年の4月からでした。 論文を読んだり、研究システムの実装をするのはとても楽しかったです。 研究システムの開発にも、インターンや個人開発で学んだことを活かすことができてよかったと思います。自動テスト、CI/CDの導入など、システムの保守を行いやすくするための取り組みで、実装はストレスなくできたと思います。

最近の関心事は、ContainerやBPF、WebAssembly Runtimeなど、Sandboxを構成するための要素についてです。

来年度に向けて

そろそろ自分の方向性を決めねばならないと思っています。自分は運用がしたいのか、開発がしたいのかまだはっきり決められていないのが現状です。ただ、どちらかというと基盤開発がしたいという気持ちはあるので、Software Engineerを目指しています。

就職活動

来年は就活なので、企業の方々はよろしくお願いいたします。

  1. 希望職種: Software Engineer, Site Reliability Engineer
  2. 分散システムの基盤となる技術、システムの開発を行いたい
  3. 勤務地: 東京or福岡希望
  4. OSS活動もしたい
  5. RustやGoを書くようなお仕事がしたい

自分の技術スタック

正直どれも浅い感じはしますが、ちょくちょく触ってるのは以下

詳しくはWantedly

www.wantedly.com

CloudNative Days Tokyo 2019にスカラシップで参加した話

遅くなりました 7/22, 23のCloudNative Days Tokyo 2019に参加してきました。 人生初東京なのでいろいろ戸惑いながらの参加です。 CNTD2019の学生スカラーシップ枠で参加させていただきました。

参加理由については、KubernetesやOpenStackについての企業の取り組みなどを知ることができる良い機会だと思い、参加しました。 また、企業の課題感を知ることで、研究の方向性などに活かして行きたいです。

CNDT2019のテーマ: 「+Native」

今までよりもっとクラウドにネイティブに、クラウドにのせただけではなく、 よりクラウドに適した形にというものでした。
CNCF landscapeのロードマップや、自分たちのプロダクトが抱えている課題に向き合って、 システムの基盤を変えていきたいと思うようになりました。

https://raw.githubusercontent.com/cncf/trailmap/master/CNCF_TrailMap_latest.png

各セッションについて

以下、自分が聴講したセッションについていくつか抜粋して紹介します。

How Kata protects containers

Kata Containerのアーキテクチャの話。 VMで使用するカーネルの変更、QEMUの代わりにIntelのnemuを使うことも可能とのこと。 資料はあげられてないっぽい?

OCIv2?!軽量高速なイケてる次世代イメージ仕様の最新動向を抑えよう!

今後のOCIの標準化仕様についての話 。 Runtime, Image, Distributionの中で、Image, Distributionの話が多かった気がする。

OCIv2?!軽量高速なイケてる次世代イメージ仕様の最新動向を抑えよう!

Prometheus setup with long term storage

サーバ監視ツールであるPrometheusのメトリクスなどをどう保持するか、どう冗長化するかという話

Prometheus setup with long term storage - Speaker Deck

実録!CloudNativeを目指した230日

GMOペパボのOpenStack上でのアプリケーションの運用から、 OpenStack上にKubernetesを構築し、 その上でアプリケーションを稼働させるようになるまでの話。

実録!CloudNativeを 目指した230日 / cloud-native-days-tokyo-2019 - Speaker Deck

最近のDockerの新機能

セッション当日に発表されたDockerの新機能についての紹介。 GPU対応、非特権モード、Buildkitによる高速なビルド、その他プラグインなど。

[CNDT] 最近のDockerの新機能

How cgroup-v2 and PSI Impacts Cloud Native?

Cgroup v2とCgroup単位での負荷を見るPSIというカーネルの機能についての話。 Cgroup v2へのOCI対応状況についてや使用方法について。OCIで規格が定まるのはまだ先の印象。 また、PSIはプロセス単位で、ロードアベレージのように負荷状況を取得できるカーネルの機能。 Linux 4.20から使用可能。

How cgroup-v2 and PSI Impacts Cloud Native? - Speaker Deck

まとめ

実際にKubernetesで運用を行う知見や、企業の課題感を知ることができました。 クラウドにのせることを目的とするのではなく、回復性、管理力、可観測性を意識しながら、 課題を解決するためにシステムの基盤を改善できるエンジニアになりたいと思うようになりました。 また、自分の研究がコンテナランタイムについてなので、周りに色々聞いてみると、 「Kubernetesを使いこなすのに精一杯でRuntimeまで手が回ってない」 という反応がぼちぼちあったので、色々課題感の乖離を感じました。 今後、Kubernetesが成熟してもRuntimeまで手を入れて、クラスタを組むのはクラウドベンダと、ごく一部の企業ではないかという印象を受けました。

余談と後日談

人生初東京の感想

  • 人がいっぱい
  • 電車の頻度すごい
  • 店の中とか基本的に狭い

福岡のほうが好きかも…。ご飯美味しいし

香川に戻って風邪ひきました。4日ぐらい布団で寝込んでました。 ちゃんとした栄養とってなかったのと、空気が悪かったのと、室内と外との温度差、旅行による疲労っぽいです。

Docker Registry HTTP API v2でDockerイメージのダウンローダを作った話

久しぶりにtechな記事書きます.
コンテナ作るとき,OSのイメージの用意とかめんどうですよね.
僕はdebootstrapとかpacstrapとか使ってました.
でもroot権限が必要だったり,ダウンロードに時間がかかります.

そこでDocker Registry HTTP API v2を使ってみます.
HTTPでdocker pullみたいなことができるすごいやつ.
しかもOCIで標準化されるコンテナイメージの配布方法にはこれをベースにするらしい.

docs.docker.com

cromwellも内部はこれを採用しています.
今回はこの部分を取り出してCLIツールとして作って公開しました.
ほぼcromwellからの輸入なので開発時間は20分も無いですね.

github.com

今回作ったやつ github.com

Rustで開発してるのでcargoですぐにインストール可能です.

$ cargo install oci-fetcher

oci-fetcher + unshare + で非特権コンテナ!

alpineのイメージをとってきて雑に非特権コンテナを作ってみます.

$ oci-fetcher pull -n library/alpine -o alpine-test
$ ls alpine-test/
bin  cromwell  dev  etc  home  lib  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

それっぽいディレクトリができてますね. あとはunshareしてchrootするだけで非特権コンテナっぽい何かができました

$ unshare --user --cgroup --mount --ipc --pid --net --uts -r --fork bash
[root@archlinux ~]# chroot alpine-test /bin/sh
/ # id
uid=0(root) gid=0(root) groups=65534(nobody),0(root),65534(nobody)

改善点

DockerHubにしか対応していないので,他のレジストリに対応していきたいですね.

第81回IPSJ全国大会参加レポ

3/14~3/16まで開催されたIPSJ全国大会に参加してきました。
私は「OS・クラウド」の学生セッションで発表させていただきました。

研究の概要

研究についてですが、コンテナランタイムの研究をしています。 今のテーマはVMMなしで、ホスト-コンテナ間、コンテナ間を分離して、 別のユーザのコンテナやホストにを保護する高レベルランタイムを開発することです。 (正直なところ、論文提出した1週間後にpodmanのv1.0.0がリリースされて焦りました)

研究システムの概要

一応システムもOSSとして公開しています。 cromwellはrust製のrootlessコンテナランタイムです。 いわゆるプロセス型のランタイムで、手法としてはpodmanに近いです。 詳しい記事は今週中に投稿したいですね。

OCI対応はまだまだ先なので、やっていきたいですね。 star, PR待ってます。

github.com

発表について

緊張してガタガタでした。 会場見渡して、論文で見たことある人や、インターンでお世話になった人、研究室の先輩がおられたので、 心臓バクバクでした。 やっぱり場数をもっと踏んでおきたいと思いましたね。 質疑は一応答えられたと思います。 ただ、冗長な答え方になってしまっていたので、明確に答えてから付け加えることがあれば、話せばいいかなという感じにしたいですね。

結果としては、学生奨励賞を頂きました。 10月ぐらいから時間を見つけて開発、研究してきたので、報われました。

IPSJ-ONE 感想

夕飯まで時間あるし、見ていこうかなぐらいに思ってたIPSJ-ONE、めっちゃ良かった(語彙不足)。 いろんな研究会の人が研究について紹介してくださったのですが、 他分野の人間にもすごくわかりやすくて、ワクワクする紹介でした。 ああいう発表ができるようになりたいなあと憧れますね。

ペパボ訪問

去年の春休みにインターンシップで参加させていただいた、GMOペパボ福岡支社にお邪魔させていただきました。 ペパボ研究所の方々と研究の話ができてよかったです。 また、コンテナランタイムのOCI対応に悩んでいたため、@udzuraさんとお話させていただきました。 低レベルランタイムか、高レベルランタイムのどちらに寄せていくかというヒントもいただきました。 また、他の高レベルランタイムの話(kata, firacracker, gVisor, podman)などの話もさせていただきました。 サーベイが深くまでできてないと感じているので、卒論や来年のIPSJに向けて、時間をかけてやっていきたい気持ちです。

後日、ペパ研の方々や、さくらインターネットの方々に、餃子の李へ連れて行っていただき、餃子をごちそうになりました! 今まで食べた中で一番美味しかったので、最高でした! ごちそうさまでした!!

後日談

発表後日、インターン先でお世話になった@udzuraさんや、@yuuk1tさんにTwitterで褒めて頂いてめっちゃ嬉しかったです。

余談ですが、御二人のツイートのおかげで、Twitterのフォロワーが50人以上増えました。

謝辞

最後に,論文の添削や発表資料の添削、技術的な相談に載ってくださった先輩方に圧倒的感謝です。

2018年振り返り

忘年会で忘れる前にログに残して置こうと思ったので久々のブログ更新

目次

学部3年への進級

学年も上がり,専門的なことを学べる機会が増えてきた気がします.
OOPLやLinuxを学ぶのはもうちょっと早くても良い気がするのですが,うちの大学の事情というものでしょう.
3年になってレポートが一気に増えた気がするので,時間の管理に気を使わなきゃと思いながらもう年末ですよ.
来年からは頑張りたいですね.

SLPの退部

SLP(Student Laboratory Programming)というサークルに属していたのですが,一身上の都合により辞めました.
10月ぐらいに退部届だしましたかね.
2年半ぐらいお世話になったので,メンバーの方々には感謝です.

辞めてから技術的な話ができる場所が減ってしまったので,どこかそういうコミュニティ属するのもありですかね.
TOKYOに住みたい…

slp-kbit | Student Laboratory of Programming

インターンシップへの参加

春休みと夏休みに1社ずつ,インターンシップに行かせていただきました.
参加エントリもかいたのでよければ見ていってください.

guni1192.hatenablog.com

guni1192.hatenablog.com

developer.hatenastaff.com

ペパボインターンの後にインフラやりたいってなりだしたんですよね.
はてなではAWSでコンテナ周りのこといっぱい触れたし,SREの人から多くの刺激を受けることができました.
そのおかげで,方向性や,今後やっていきたいことをちょっとずつ見えてきました.

初の学会発表

夏休みに,人生初の学会発表しました.
ネタは大したものじゃないんですけど.
研究には時間をかけたいと思いました.はい.

研究室への配属

後期になって研究室に配属しました.
研究分野は分散Webシステムとか,アクセス制御システムなどなど.
新規の研究もインフラ系のことならいろいろ持ち込みできそうな印象でした.
3月ぐらいに学会発表するので,そのネタで卒論するのも有りかなあなどと.

技術的な進捗とか

友人とWebサービス作ったり,研究室のシステム開発の舵を切ったりしてますかね.
インフラがしたいだけなのにバリバリ開発もやってます. 言語は共同開発にはGo,個人開発ではレイヤー低いところ触ったりするのでRustみたいな感じです. 最近C++を書くことが少なくなってきた気がします.

あと,コンテナエンジンっぽいものも作ってます.
衝動で書いたものが意外にハマったのでもっといろいろやっていきたいところです.

github.com

最近の興味はコンテナのOCIやCRIの実装です.
haconiwaとかcri-oとかOSSの実装読みながら自分で車輪の再開発みたいなことをしているのが現状ですかね.
また,オーケストレーションも勉強しながらぼちぼち運用してます.
GKE使いすぎて無料枠使い切っちゃいました.
マネージドでなくていいから安いk8sクラスタが欲しいなあなどと.

その他心境の変化

最近はレイヤー低いところも触るようになってきた感じです.
ネットワークとかに強い友人ができたりしたので,ネットワークの勉強もしたいなあというお気持ち.

あと,酒を飲みに行く悪友が増えたもので,1週間の酒の量が増えました.
おかげで,ビール1杯で酔っていた人間が,日本酒2合+ビール2杯ぐらい飲めるようになってしまいました.

また,進路を固めないといけない時期になってきました.
院に行くか,就職するか,インフラエンジニアやSREになるか,研究職につくかなどなど.
未だに進路をちゃんと決められていないので,割と進路困ってる感じですかね.