うなすけとあれこれ

2020年03月27日

OCI Runtime Spec v1.0.2 is coming soon

Oci runtime spec

以前、udzuraさんがOCI Runtime Specを簡単にまとめた以下のようなブログを書かれていました。

OCI Runtime Specification を読む - ローファイ日記

この記事にてまとめられているのは 95a6ecf であり、このrevisionから一番近いreleaseはpre-releaseである v1.0.0-rc2 です。

さて、 v1.0.2 のリリースがそろそろということもあり、ここでは簡単のため、v1.0.0-rc2からv1.0.2までの間に入った変更について見てみようと思います。ただし全部は取り上げません。

v1.0.0-rc3

https://github.com/opencontainers/runtime-spec/releases/tag/v1.0.0-rc3

rcの間は駆け足で行きます。 Windowsについての記述が追加されています。 #565, #573 それに関してか?consoleのサイズについての情報を格納するfiledが #563 で追加されています。これらはMicrosoftの人によるcommitですね。

v1.0.0-rc4

https://github.com/opencontainers/runtime-spec/releases/tag/v1.0.0-rc4

いくつかのresouceに負の値を指定できるようになっています。でもmemory usage limitとかに負を指定できて嬉しいんだろうか? #648

v1.0.0-rc5

https://github.com/opencontainers/runtime-spec/releases/tag/v1.0.0-rc5

platformについての記述がREQUIEDに指定されています。 #695 それに関連してWindowsやSolarisについての記述が追加されたり修正されたり。 #673

あ、rc4 で負の値を指定できるようになったいくつかのfieldで、またunsignedに戻されていますね。#704

libseccompのバージョンが v2.3.0からv2.3.2に上がっています。 #705

v1.0.0-rc6

https://github.com/opencontainers/runtime-spec/releases/tag/v1.0.0-rc6

最後のrc release。 WindowsでのCPU使用率についての記述がperecnt指定からmaximum指定になっていたり。#777 指定したいパーセントに100を掛けた値を設定するように読めますけども。

やっぱりmemory usageに負の値を指定できるようになりました。-1 を指定するとunlimitedの意味になるようですね。 #876

platformについてのfiledが削除されました。runcでは使用されておらず、image-specのみが気にすることだろうということで? #850

v1.0.0

https://github.com/opencontainers/runtime-spec/releases/tag/v1.0.0

first release!

disableOOMKiller がmemory section配下に移動しました。#896 breaking chnageとされているのはこれだけ。

v1.0.1

https://github.com/opencontainers/runtime-spec/releases/tag/v1.0.1

ほぼほぼwordingやtypo fixですね。当然ですけど。

v1.0.2 (予定)

https://github.com/opencontainers/runtime-spec/pull/1037

v1.0.1に比べるとたくさんあります。 差分は(多分)これ https://github.com/opencontainers/runtime-spec/compare/v1.0.1…c4ee7d1

hookが追加されました。 createContainer, startContainer, createRuntimeの3つです。代わりにprestartがdeprecatedに指定されています。LXCと同じ名前だとか。 #1008

memoryに関してcgroupのuse_hierarchyが使用できるようになっています。 #985 第3回 Linuxカーネルのコンテナ機能[2] ─cgroupとは?(その1):LXCで学ぶコンテナ入門 -軽量仮想化環境を実現する技術|gihyo.jp … 技術評論社

WindowsにおいてDeviceをschemaに含められるようになっています。 #976

libseccompが v2.4.0になり、SMCP_ACT_LOGが使用できるようになっています。#1019 syscallのlogを残すようにする設定? http://man7.org/linux/man-pages/man3/seccomp_init.3.html

また、実装の一覧にgVisor、kara-container、crunが追加されています。crunはOCIのC実装で、runcより高速に動作するようです。元々はRedHatのgiuseppe氏による個人project?がContainers org配下に移動しています。 https://github.com/containers/crun

まとめ

取り上げられていない変更がめちゃくちゃあるので気になった人は直接見てください。

Tweet
2020年03月27日
2020年02月25日

EC2インスタンスにRDPで手軽に接続したい

download rdp file dialog

どういうことがしたいのか

適当なWindowsが動いているEC2インスタンスがあり、それにリモートデスクトップしてもらいたいということが皆さんにもあるかと思います。そういう時、冒頭の画像にあるように、AWSコンソールからEC2インスタンスを作成し、「接続」からの「リモートデスクトップファイルのダウンロード」からダウンロードしたファイルを開くことで、ユーザーのパスワードを入力すればもう接続できる、というお手軽便利機能があります。

しかし、ざっとaws-sdkを眺めてみましたが、このファイルをAPI経由で取得する方法が見当りませんでした。

では、リモートデスクトップで作業してもらう人にAWSのコンソールには入ってほしくない、というときにはどうすればよいでしょう。

RDPファイルの生成

ところで、ダウンロードしたRDPファイルを見てみると、中身はテキストになっていました。

auto connect:i:1
full address:s:ec2-192-0-2-1.ap-northeast-1.compute.amazonaws.com
username:s:Administrator

なんとなく自動で生成できそうに見えます。そして、それぞれがどのような値なのかがここに記載されていました。

サポートされるリモート デスクトップ RDP ファイルの設定 | Microsoft Docs

auto connect:i:1 についてはこのドキュメントに記載がないので触らないようにして、full address:s:には いわゆるPublic DNS (IPv4)を設定してやればよさそうです。

また接続するユーザーも、 username:s: で自由に設定できそうですね。

まとめ

パスワードだけは別で伝えないといけないのは仕方ありませんが、作業のおまかせが手軽にできそうでよかったです。

Tweet
2020年02月25日
2020年01月01日

初めての同人誌作成、サークル参加を振り返って

ブースの様子

参加を決めるまで

C96で友人のサークルをお手伝いしているとき、「サークル参加申込書買ってくるけど、どうする?」と聞かれ、勢いで「僕のぶんもお願い!」と言ったのが全ての始まりでした。 この時、そもそもサークルが存在しない状態であり、その上、何を同人誌として頒布するのかなどは何一つ決まっていませんでした。

その後、直近にあった出来事からサークル名を「キリンセル」とし、まずは日々更新しているpixivFANBOXのまとめを冊子にし、余力があればその他にも技術的なことをまとめて本にしようということになりました。

何なんだマジで pic.twitter.com/DeuNKCpVl3

— うなすけ(C97火曜日南リ17a) (@yu_suke1994) July 16, 2019

結果としては余力などなく。

FANBOXまとめを入稿するまで

正直なところ、楽観視していました。というのも、本にする内容は既に大量に存在しているからです。

実際にはログインしないと読めない秘密のコンテンツをどのようにローカルにdumpし、組版ツールに流し込むかなどの部分で大幅にてこずりました。

組版自体はRe:VIEWを使うことにし、TechBooster/ReVIEW-Template の構成をベースにしました。ここで大分楽ができました、ありがとうございます。

このとき、印刷会社の入稿締め切りスケジュールを見ながら作業していたのですが、できあがった原稿が200ページを超えることがまだわかっていませんでした。そしていざ入稿しようとすると、「そのページ数では入稿できない」という事態になり、あわてて別の印刷会社を探すことになったりもしました。

入稿締め切りのギリギリまで表紙のデザイン作業をすることになったりもして、余裕をもったスケジュールがどれだけ大切かを思い知らされました。 (ページ数的に背表紙が存在することが判明したのが結構遅かった)

うなすけファンブックを入稿するまで

ファンブックは、主体として動いていたのは蜘蛛糸まなさんなので僕はされるがまま、という感じではありましたが、まれに進捗をつついたり、インタビューの文字起こしをしたりなどのお手伝いをやっていました。これも結構ギリギリまで作業することになってしまい、朝5時くらいまで手を動かす日もありました。

当日までの準備

上記の作業と平行して、当日必要なさまざまなものの準備をしていました。

当初、交通系ICカードが使えることからCoineyを申請したのですが、審査が通らずSquareの導入となりました。また、審査に必要であることからサークルWebサイトの作成も平行して行っていました。 (このカード決済用端末に使えるので、iPad Proを買ったり……)

他にも、会計用のコインケース、サークルクロス、お品書き用のポスタースタンドなどなどの購入、当日売り子として手伝ってくれる友人(コミケ初参加)のためにどのようなことをすべきか、どのようなスケジュールでの行動かなどをまとめたものの作成、両替など、様々なタスクにずっと追われていました。

あと、告知配信とか。

当日

オペレーションについて

キャッシュレス決済は、事前告知配信に来ていただいた(であろう)方々や、同業の方々はすぐクレジットカードを出してくださいました。が、イベント全体としてはやはり現金決済が主流なので、はじめは現金で支払おうとした方も多かった印象です。

単純な決済にかかる時間としては、EMV Contactless = pixiv PAY < 現金決済 < Squareカード決済(要サイン) の順で所要時間が短い(早い)印象でした。

このあたりは、iDやQUICPayが使用できるようになるとまた変わるかもしれないですね。

売上げについて

売上げの管理は、クレジットカードと現金による決済はSquareにて一元管理するようにしました。これだと、レポート画面でどの時間帯にどれだけ売上げがあったのかなどの詳細な情報が入手できてとても便利でした。

事前決済について

事前決済はpixiv PAYによるものを、FANBOXまとめのほうでだけ受け付けていました。利用があってよかったです。

ファンカードについて

当日、ファンカードによるディスカウントはありませんでした。みんな電子書籍で欲しいのか、それとも来れなかったのか…… ただ、事前決済リンクからの購入であればファンカード提示はなくてもよいので、それも若干あるかもしれません。

コミケそのものについて

ほぼ立ちっぱなしの6時間でした。自分のサークルに居たい気持ちとあちこちに挨拶&買い出しに行きたい気持ちとの戦いで、簡単な挨拶でそそくさ退散してしまったブースがいくつもあります。サークル出展って大変ですね。 当日、差し入れを下さった皆さんありがとうございました。全て美味しく頂きました。

振り返ってKPT

Keep

Problem

Try

Tweet
2020年01月01日
2019年12月25日

C97の4日目南リ17aでFANBOXのまとめ本を頒布します

お品書き

概要3行

もっと詳しく

コミックマーケット 97 4日目(2019-12-31 火曜) 南リ17a サークル名「キリンセル」にて、以下3冊の同人誌を頒布します。

この同人誌は、僕がpixivFANBOXに投稿しているOSS watchをまとめて時系列順に読めるように編集したものになります。01では 2018年05月から2018年9月末まで、02では2018年10月から2019年3月末までの投稿を集録しています。

(01には、少しだけでしたがpixivFANBOXには投稿していない、社内にだけ公開していた頃のものも収録しています)

また、どちらにも付録として、pixivFANBOXへの投稿をどのようにRe:VIEW形式によるテキストにまとめなおしたかを書き下ろしとして集録しています。

価格は1冊2,000円となります。pixivFANBOXにて支援していただいている方々には、特別に値引きがあります。当日はファンカードを売り子に提示できるようにしてください。詳しくはFANBOXの投稿をご確認ください。

また、物理本が売れ残ったらBOOTHにて販売します。電子書籍版もBOOTHにて販売する予定です。

FANBOXにて支援して頂いている方々には、電子版のPDFを後日配布させていただきますが、500円プラン以上 とさせていただきます。

当日の支払い方法ですが、Squareによるクレジットカード決済 (VISA・Mastercard・American Express・JCB・Diners Club・Discover) またはpixiv PAY、または現金でのお支払いを受け付けております。

なるべくクレジットカードもしくはpixiv PAYでの決済をお願いします

(回線状況によっては現金しか使用できない可能性があります)

取り置きについて

取り置きとして、pixiv PAYでの事前決済を受け付けています。以下のQRコードを読み取ってください。当日は受け取りの際にpixiv PAYアプリの購入履歴画面を提示して前払い済みであることを証明してください。

取り置きQR

ほとんどの内容を無料で公開しているので、物理の冊子はあまり買われないかも?という予測をし、あまり数を用意していません。どうしても冊子として欲しい!という場合は取り置きをおすすめします。

(もし取り置きのみで用意している分がなくなってしまったら、pixivFANBOXで支援していただいている方のぶんを優先で確保します)

うなすけファンブックについて

詳しくは28日の配信にて明らかになります!!!!!!

長々と書きましたが、当日、会場でお会いできることを楽しみにしています!

Tweet
2019年12月25日
2019年12月16日

平成Ruby会議01参加記

Heiseirubykaigi 01

Speaker and Staff

平成Ruby会議01に、発表者として、また当日スタッフとして参加しました。

資料はこれです。

heiseirubykaigi-1

もともと平成.rbのメンバーの一員であったということもあり、平成Ruby会議で何かしらお手伝いできればなと思ってはいたのですが、仕事、プライベート(原稿)などの兼ね合いで当日のみのお手伝いとなりました。 (スタッフ用のchat roomにも参加していましたが、トーク採択には関わっていません)

また別件で、発表内にもあるようにWindows環境でのテストに悪戦苦闘していたこともあり、これで何か話せそうだということでCfPに応募したところ採択されたので、発表者としても参加することができました。

感想

懇親会で、このような会に参加するのが初めての方や学生の方が多く、「平成」の名を冠することが良い方向に働いたようでとてもよかったです。

また個人的には、Re:VIEWについて高橋会長にご挨拶できたこと、 #unasukefm まだですかという声を沢山頂けたことが、もう、たまらなく嬉しかったです。

あ、あとこれ。

エモ散らかしてて限界なんだが #heiseirubykaigi https://t.co/SgSXIRv1bp

— うなすけ(C97火曜日南リ17a) (@yu_suke1994) December 14, 2019
Tweet
2019年12月16日
2019年11月29日

Middlemanで生成したHTMLの<img>にloading="lazy"を付与するgemを作りました

performance

ChromeがNative lazy loadingをサポートするようになったので、僕のblogでもこれを使おうと作ってみたgemになります。

Markdownの変換に介入する

Chrome v76から、Native lazy loadingがサポートされるようになりました。

Native lazy-loading for the web

ところで僕のblogは、本文をMarkdownで記述したものをHTMLに変換しています。Markdown記法で画像を挿入した場合に、どのようにloading属性を付与すればいいのでしょうか。Markdown内にHTMLを記述した場合、それはそのまま出力されるので、手でタグを書くことで実現できますが、果たしてそのようなことをしたいでしょうか。面倒です。

なので、Markdownの変換過程に介入することで解決できないだろうかと思い、調べてみました。

僕のblogでは、Markdown engineとしてRedcarpet gemを使用しています。そして、RedcarpetにはCustom Rendererという仕組みがあります。これで、![alt text](src) の変換に介入します。

Railsでカスタムmarkdownを実装する - k0kubun’s blog

class CustomRenderer < ::Redcarpet::Render::HTML
  def image(link, title, alt_text)
    "<img loading=\"lazy\" src=\"#{link}\" alt=\"#{alt_text}\" />"
  end
end

上記のようなコードで、 に loading attrを付与することができます。そして、それをgemにしたのがこれです。

実際には loading 属性には lazyの他にも autoとeagerを指定できるので、gemでもRendererをそれぞれ使い分けることでlazy以外を指定できます。 (なのでgem名にlazyと入れたのはちょっと失敗だったかもしれない)

ここまでが表参道.rb #51 での発表内容になります。

omotesandorb #51

生成されたHTMLを改変する

ところで、この手法は上手くいきませんでした。実際にこのgemを使用してblogをdeployすると、画像が全てリンク切れとなってしまったので、急いでrevertしてdeployをし直しました。

この原因は、Middleman側の設定である asset_hash を有効にしていたためです。この設定によって尊重されるべきMiddleman側のCustom Rendererを自分のgemで上書いてしまっていたために、画像のsrcが正しくないものになってしまっていました。

asset_hash を有効にしたまま loading="lazy" をするには、もう変換後のHTMLを編集するMIddleman pluginを作成するしかなさそうです。

という訳で、after_build のタイミングで以下のようなコードを実行するようなgemを作成しました。

def after_build(builder)
  files = Dir.glob(File.join(app.config[:build_dir], "**", "*.html"))
  files.each do |file|
    contents = File.read(file)
    replaced = contents.gsub(%r[<img], "<img loading=\"#{options[:loading]}\"")
    File.open(file, 'w') do |f|
      f.write replaced
    end
  end
end

このコードは、build directory 以下に存在する .html ファイルについて、全ての <img> タグに対して loading 属性を付けて上書き保存します。

ここまでが表参道.rb #52 での発表内容になります。

omotesandorb #52

改変してはいけない <img> を除外する

この実装では、 pre や code の内部の img にも loading 属性を付与してしまいます。これはどうやって解決するか悩んだのですが、Nokogiriによって親に pre 、 code 、blockquote がある img に関しては属性を編集しない、というように処理を変更しました。

https://github.com/unasuke/middleman-img_loading_attribute/pull/1/files#diff-ea964f9b9ef0f5bc6bdab0998e722d4e

まとめ

これで、ようやく僕のblogでlazy image loadingが実現できました。といってもChrome v76以降のみですが。

ということで、Starやpull reqなど頂けると大変ありがたいです。

Tweet
2019年11月29日
2019年10月28日

Awayのスーツケースを買いました

Away

スーツケースがあると便利

スーツケースを持っていなかった(Dockercon 2016のときに使っていたのは帰国時に壊れた )ので、RubyKaigiや帰省などの遠出のときには、少し大きいトートバッグ のなかに全部詰めこんでいました。

ふつうの帰省時にはこれで問題なかったのですが、冠婚葬祭で礼服も持ち帰らないといけないときに、このスタイルだと礼服だけ別で持つ必要があり、移動がとても大変でした。

スーツケースを検討する

さすがにスーツケースが欲しいなと思いはじめたのは、まつもとりーさんのnoteを読んでからでした。

これを見て、REMOWAのスーツケースよさそう、とはなったのですが、新規に購入するとなると思ったより高価なので、とりあえずレンタルしてRubyKaigi 2019で使ってみました。

デカいスーツケース、荷物をたくさん入れられて便利!!!!!!!!!!!!!!!!!!!!!!!!!!!!

— うなすけ (@yu_suke1994) April 14, 2019
また、そのときにhmskさんが使っていたスーツケースを見て、これもいいなと思って調べたところ、REMOWAほど高価でなく手が届きそうなので迷いがでてきました。

機内持ち込めてバッテリーとラップトップ用のスリーブが付いたAway届いた。かわいい。 https://t.co/M8XUZU0nYL pic.twitter.com/IciROgwXMC

— Kengo Hamasaki (@hmsk) March 27, 2019
これから結婚式など礼服が必要になるイベントが増えることを考えると、スーツケースは確実に必要なので、現時点で手が届くAwayのものを買うことに来めました。

スーツケース、まつもとりーさんオススメのREMOWAはちょっと高価が過ぎるのでhmskさんの使ってるAwayにしようと思ったが日本に発送できなそうでア

— うなすけ (@yu_suke1994) May 31, 2019

ただ公式では日本への発送はしておらず、BUYMAを利用して代理購入 → 日本への発送 という手続を踏みました。

購入したモデル

https://www.awaytravel.com/suitcases/bigger-carry-on-pocket/asphalt

これです。

Away

大きすぎず、小さすぎずちょうどいいサイズで気に入ってます。

Tweet
2019年10月28日
2019年09月25日

Container Runtime Meetup #1でNOTIFY SOCKETについて話してきました

git grep NOTIFY_SOCKET

Container Runtime Meetup #1 - connpass に参加して NOTIFY_SOCKET について調べたことを話してきました。

この記事ではその内容の書き起こしと、その場で行われた会話についてのメモについて書きます。

参加するきっかけ

@udzuraさんにそそのかされたことがきっかけです。

@yu_suke1994⁩ 情報です https://t.co/U5zsvUlz30

— Uchio KONDO 🔫 (@udzura) August 27, 2019

あまりよくないExecuteをすると、普段はRails APIを運用していてRubyしか書いておらず、Goも数年前にCLI toolを作った程度で、GoやLinuxのコンテナ回りに詳しいという訳ではありません。

読む対象について

connpassのイベント概要に

少人数の輪読形式です。「参加枠1」の方々にはあらかじめ「runc run」周辺のコードをざっと読んできてもらい、当日、それに関連するトピックをそれぞれ発表して頂きます。「聴講のみ」の方々は、発表の必要はありません。

とあったので、その時点での最新リリースである v1.0.0-rc8 を対象に読むことにしました。

https://github.com/opencontainers/runc/releases/tag/v1.0.0-rc8

runc run が実行されたとき、呼び出される実体は run.go だろうとアタリをつけ、周辺を読んでいきます。

        status, err := startContainer(context, spec, CT_ACT_RUN, nil)
        if err == nil {
            // exit with the container's exit status so any external supervisor is
            // notified of the exit with the correct exit status.
            os.Exit(status)
        }

https://github.com/opencontainers/runc/blob/v1.0.0-rc8/run.go#L76

まずここで startContainer によりContainerがstartするものと思われます。中を見ていきます。

func startContainer(context *cli.Context, spec *specs.Spec, action CtAct, criuOpts *libcontainer.CriuOpts) (int, error) {
    id := context.Args().First()
    if id == "" {
        return -1, errEmptyID
    }

    notifySocket := newNotifySocket(context, os.Getenv("NOTIFY_SOCKET"), id)
    if notifySocket != nil {
        notifySocket.setupSpec(context, spec)
    }

https://github.com/opencontainers/runc/blob/v1.0.0-rc8/utils_linux.go#L405-L414

startContainer 内部、 411行目にて os.Getenv("NOTIFY_SOCKET") としている部分があります。この環境変数は何でしょう?気になったので、ここを掘っていきました。

この時点で僕の NOTIFY_SOCKET に対する認識は、

「環境変数がある状態で起動させると色々な通知が飛んでくるのだろうか?」

くらいのものでした。

Dive into code

では、 newNotifySocket で何が行われているかを見ていきます。

func newNotifySocket(context *cli.Context, notifySocketHost string, id string) *notifySocket {
    if notifySocketHost == "" {
        return nil
    }

    root := filepath.Join(context.GlobalString("root"), id)
    path := filepath.Join(root, "notify.sock")

    notifySocket := &notifySocket{
        socket:     nil,
        host:       notifySocketHost,
        socketPath: path,
    }

    return notifySocket
}

https://github.com/opencontainers/runc/blob/v1.0.0-rc8/notify_socket.go#L23-L38

この関数の返り値として、 notifySocket 構造体のインスタンス(のポインタ?)が得られます。

ちなみに notifySocket 構造体はこのように定義されています。

type notifySocket struct {
    socket     *net.UnixConn
    host       string
    socketPath string
}

https://github.com/opencontainers/runc/blob/v1.0.0-rc8/notify_socket.go#L17-L21

ところで newNotifySocket 関数の引数として渡される context *cli.Context は何でしょうか。

これはruncが採用しているCLIツール用パッケージ https://github.com/urfave/cli で定義されている Context 構造体を指しています

https://godoc.org/github.com/urfave/cli#Context

startContainer では、 newNotifySocket を呼んだ直後に、返ってきた notifySocket に対して setupSpec を呼んでいます。これも見ていきます。

// If systemd is supporting sd_notify protocol, this function will add support
// for sd_notify protocol from within the container.
func (s *notifySocket) setupSpec(context *cli.Context, spec *specs.Spec) {
    mount := specs.Mount{Destination: s.host, Source: s.socketPath, Options: []string{"bind"}}
    spec.Mounts = append(spec.Mounts, mount)
    spec.Process.Env = append(spec.Process.Env, fmt.Sprintf("NOTIFY_SOCKET=%s", s.host))
}

https://github.com/opencontainers/runc/blob/v1.0.0-rc8/notify_socket.go#L44-L50

この関数のコメントにもあるように、systemdが何か関係していそうだということがわかりました。

ここでの処理は runtime-spec を読むとわかりそうです。とりあえず、Process.Env に対して NOTIFY_SOCKET 環境変数を追加しているようです。

startContainer に戻ると、 createContainer を呼んだあとに notifySocket.setupSocket() を呼んでいます。これを見ていきます。

func (s *notifySocket) setupSocket() error {
    addr := net.UnixAddr{
        Name: s.socketPath,
        Net:  "unixgram",
    }

    socket, err := net.ListenUnixgram("unixgram", &addr)
    if err != nil {
        return err
    }

    s.socket = socket
    return nil
}

https://github.com/opencontainers/runc/blob/v1.0.0-rc8/notify_socket.go#L52-L65

net.UnixAddr とは何でしょうか。これの実体は https://golang.org/pkg/net/#UnixAddr にあります。

type UnixAddr struct {
    Name string
    Net  string
}

ここでの unixgram は datagram socketを指すようで、UDPのような送りっぱなしのプロトコルのようです。 ( https://github.com/golang/go/blob/master/src/net/unixsock_posix.go#L16-L27syscall.SOCK_DGRAM を参照 )

net.ListenUnixgram によってconnectionを張り、それを notifySocket.socket に格納したものを、 runner 構造体の notifySocket フィールドに入れています。

type runner struct {
    init            bool
    enableSubreaper bool
    shouldDestroy   bool
    detach          bool
    listenFDs       []*os.File
    preserveFDs     int
    pidFile         string
    consoleSocket   string
    container       libcontainer.Container
    action          CtAct
    notifySocket    *notifySocket
    criuOpts        *libcontainer.CriuOpts
}

https://github.com/opencontainers/runc/blob/v1.0.0-rc8/utils_linux.go#L254-L267

この後に、 notifySocket に対して行われている操作は、runner.run 内部で以下のコードを呼んでいる部分があります。

// Setting up IO is a two stage process. We need to modify process to deal
// with detaching containers, and then we get a tty after the container has
// started.
handler := newSignalHandler(r.enableSubreaper, r.notifySocket)

https://github.com/opencontainers/runc/blob/v1.0.0-rc8/utils_linux.go#L305-L308

一旦まとめ

一旦ここまでをまとめると、

といったところでしょうか。

NOTIFY_SOCKET を調べる

何やらsystemdが関係していそうなことはわかっているので、単純に NOTIFY_SOCKET でググってみると、いくつか記事が見付かりました。

freedesktop.orgでは

These functions send a single datagram with the state string as payload to the AFUNIX socket referenced in the \$NOTIFYSOCKET environment variable. If the first character of \$NOTIFY_SOCKET is “@”, the string is understood as Linux abstract namespace socket.

https://www.freedesktop.org/software/systemd/man/sd_notify.html#Notes

「sd_notifyの通信方法 - Qiita」では

systemdのマネージャ(デーモンプロセス)は、起動プロセスの最後の方でsdnotifyという関数を用いて、起動が完了したことをsystemd本体(PID=1)に通知する。(注:sdnotifyは実際にはもっと汎用的なステータス通知に使える。)

https://qiita.com/ozaki-r/items/ced43d5e32af67c7ae04

ざっくりとした理解でいくと、プロセスが起動した、などのステータスの通知に使用されているんだろうということがわかりました。

Dockerの場合

ここで、「ではDockerの場合はどうなのだろう」と思い、 https://github.com/docker/cli 内をgrepしましたが、見当りません。いや、Dockerはmobyに移行したのでした。 案の定、 https://github.com/moby/moby 内をgrepすると見付かりました。

$ git grep NOTIFY_SOCKET
libcontainerd/supervisor/remote_daemon.go:200:  // clear the NOTIFY_SOCKET from the env when starting containerd
libcontainerd/supervisor/remote_daemon.go:203:          if !strings.HasPrefix(e, "NOTIFY_SOCKET") {
vendor/github.com/coreos/go-systemd/daemon/sdnotify.go:49:// If `unsetEnvironment` is true, the environment variable `NOTIFY_SOCKET`
vendor/github.com/coreos/go-systemd/daemon/sdnotify.go:53:// (false, nil) - notification not supported (i.e. NOTIFY_SOCKET is unset)
vendor/github.com/coreos/go-systemd/daemon/sdnotify.go:54:// (false, err) - notification supported, but failure happened (e.g. error connecting to NOTIFY_SOCKET or while sending data)
vendor/github.com/coreos/go-systemd/daemon/sdnotify.go:58:              Name: os.Getenv("NOTIFY_SOCKET"),
vendor/github.com/coreos/go-systemd/daemon/sdnotify.go:62:      // NOTIFY_SOCKET not set
vendor/github.com/coreos/go-systemd/daemon/sdnotify.go:68:              if err := os.Unsetenv("NOTIFY_SOCKET"); err != nil {
vendor/github.com/coreos/go-systemd/daemon/sdnotify.go:74:      // Error connecting to NOTIFY_SOCKET

https://github.com/moby/moby/search?q=NOTIFY_SOCKET&unscoped_q=NOTIFY_SOCKET

ということは、Dockerを使っているだけでそのようなsocketが作成されているのではないでしょうか。調べてみましょう。

Docker daemonが動作しているマシン上で、systemdが関係していそうなunixドメインソケットの数を出してみました。

$ ss --family=unix | grep systemd | wc -l
110

けっこうな数ありますね。grepする単語を変えてみます。

$ ss --family=unix | grep container
u_str    ESTAB   0  0     /var/snap/microk8s/common/run/containerd.sock 21833469  * 21836828
u_str    ESTAB   0  0     /var/snap/microk8s/common/run/containerd.sock 21836830  * 21836829
u_str    ESTAB   0  0        /var/run/docker/containerd/containerd.sock 23108     * 23106   
u_str    ESTAB   0  0        /var/run/docker/containerd/containerd.sock 23114     * 23113   
u_str    ESTAB   0  0        /var/run/docker/containerd/containerd.sock 23110     * 25748   

それらしきものが存在しています。

もっと見ていきましょう。dockerdのpidを調べます。

$ ps aux --forest # 抜粋
root  601  /usr/bin/dockerd -H fd://
root  769   \_ containerd --config /var/run/docker/containerd/containerd.toml --log-level info
root 1213       \_ containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/61f9489e17355a4f00594feb5c
root 1230           \_ bash

pid 601 の環境変数を見てみます。

$ sudo cat /proc/601/environ # 改行を入れています
LANG=ja_JP.UTF-8
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/var/lib/snapd/snap/bin
NOTIFY_SOCKET=/run/systemd/notify
LISTEN_PID=601
LISTEN_FDS=1
LISTEN_FDNAMES=docker.socket
INVOCATION_ID=e65738cc4b8f461e968d23c6740a557e
JOURNAL_STREAM=9:22835

確かに NOTIFY_SOCKET がありますね。

ここまでのまとめと今後の目標

ここまでがMeetupでの発表内容になります。

当日の議論

ここからは、当日の発表のあと、その場で行われた議論の簡単な書き起しになります。

Tweet
2019年09月25日
2019年09月12日

フリーランスになっていました

社内でも僕しか持っていないTシャツ

2019年5月1日から、個人事業主として株式会社バンクで1日8時間の週4日間で稼動していました。

理由

「週4日労働にしたかった」 ためです。好きなようにコードを書いたり、映画など娯楽に興じたり、心身を養ったりする時間のために、もう1日休日が欲しいという気持ちは2019年になってから心のどこかにずっと引っかかっていました。

交渉の過程

ただ、フリーランスになるとは言ってもバンクを離れたくはありませんでした。当時から計画されていた新サービスの実装、まだまだ綺麗にし足りないコード、インフラ構成のキャッチアップ……やりたいことは山ほどありました。

なのでまずは人事の方に相談し、こちらの意向として

ということを伝えました。

結果としてですが、フリーランスとして契約をし直すということになりました。

最初に人事の方に「フリーランスを検討している」という意向を伝えたのが2月28日、面談を行ったのが3月8日、代表の光本さんと話したのが3月15日と19日、そこから総務の方と話し、有休の消化等の兼ね合いで、5月1日からフリーランスとして勤務する、という時系列になっています。

実力

その他、詳細や発表資料などについては https://unasuke.com/activity などにまとめてあります。また各種ポートフォリオサービスへのURLは以下になります。

これから

バンクでの契約が一区切りしたタイミングというのもあり、このタイミングで公開しました。一区切りしたとはいえ、契約更新のタイミングであったというだけで、まだバンクで引き続きお仕事をしています。

( ※ この日記は、フリーランスになった5月頃から、最初の契約更新のタイミングである11月1日に公開するつもりで下書きを作成していましたが、解散発表のタイミングで公開することにしました。 )

これからフリーランスとして仕事をしていくなかで、ずっとバンクだけと関わっていく訳ではないので、 興味のある方は声をかけていただけるとありがたいです。

(解散に伴なって色々あり、来年までは埋まっているかもしれません。状況を見つつ動きたいと思います。)

ただ、将来的に実家のある福井に戻りたいという展望があり、徐々に仕事をリモートで行えるようにしていきたいと思っているので、フルリモートが可能であると(より)嬉しいです。

また「交渉の過程」でも触れたように、「週4日勤務」という条件を満たせるのであれば正社員としてのオファーも嬉しいです。

参考文献

誰?

うなすけです。

Tweet
2019年09月12日
2019年08月10日

pixivFANBOXの #クリエイター優待 でOKAMURAのバロンを買いました

ありがとうございます

pixivFANBOXのクリエイター優待 で

FANBOXで支援者数が50名以上いる方を対象に特別価格で提供していたOKAMURAのオフィスチェアですが、この度なんと!対象を「支援者数10名以上」に緩和して再開しました 🎉🎉
今まで欲しくても手が届かなかった方はこの機会にぜひチェックしてみてください! #クリエイター優待https://t.co/qaektxPHCB

— pixivFANBOX公式 (@pixivFANBOX) July 1, 2019

#pixivFANBOX やっててよかった!!

— うなすけ (@yu_suke1994) July 1, 2019

毎月支援していただいている皆様、本当にありがとうございます。

バロンへの思い入れ

前職、spice life時代には、好きな椅子を何でも一つ購入できるという制度があり、覚えているだけでも社内にアーロンチェア、エンボディチェア、バロン、コンテッサがありました。

それらオフィスチェアのなかでも、僕の身体にはバロンがしっくりくるようで、いずれは自宅にもバロンを……という目標をその頃から立てていました。が、いわゆる高級オフィスチェアなのでなかなか手が出ずにいました。

そこにpixivFANBOXでのクリエイター優待としてオカムラのオフィスチェアを購入できるようになり、ついにこの時が!となったものの、公開当初は50人以上の支援がないと利用できず、僕は対象外で悔しい思いをしたものです。

【お知らせ】
FANBOXの支援者を集めているクリエイターを対象に!
なんと…!

OKAMURAのオフィスチェアを特別価格で購入できるようになりました〜 🎉

日頃の創作活動により集中できるように、普段より良い椅子を使ってみませんか??詳細はこちら↓↓ #クリエイター優待https://t.co/qaekty7iu9

— pixivFANBOX公式 (@pixivFANBOX) April 9, 2019

そして、今自宅で使っている椅子は、どこで買ったのかも覚えていない1、上京したとき購入したものです。座面はへたってほぼ板、というかネジか何かが座面に飛び出している、軋みがうるさい、腰が痛くなる……4年ちょっと使っている安物なので、こんなものでしょう。しかしストレスが溜まっていきます。

たぶんニトリの椅子

(部屋が汚ない)

そんなタイミングで、冒頭にあるようにOKAMURAのオフィスチェア優待が10人以上の支援者からでも申し込み可能と知ったときの嬉しさったらありません。

届いた

8月1日に申し込んで、8月9日に自宅に届きました。

オカムラ バロン

(部屋が汚ない)

最高の座り心地ですね。やはり良い椅子は良いです、ありがとうpixivFANBOX。ありがとう支援者の皆さん。重ねて御礼申し上げます。

旧椅子の処分

さて、注文時のオプションに「椅子引き取り」というものがあり、使用中の椅子を引き取ってくれるとのことで、これを有効にして注文しました。

しかし配送の方には「そんなのは聞いていない」と言われてしまい、アレ~となりました。注文確認メールにはしっかり「椅子引き取り」のオプションが有効になった状態になっている2のですが……まあ配送の方を詰めても何もいいことはない3ので、そのまま帰っていただき、こちらで処分することにしました。

我が家には2週間に1回くらいのペースで廃品回収のチラシが来るのですが、ある程度の見積りは書いてあるものの、やはり呼んでから法外に請求されるのは怖いので、行政の廃品回収をお願いすることにしました。行政だと値段が事前にわかるので最高、安心ですね。

そのかわり、狭い部屋に二脚の椅子でより狭いという状況がしばらく続きそうです。


  1. おそらく https://www.nitori-net.jp/store/ja/ec/Chair/WorkChair/6620437-6620439s の旧モデル 

  2. 郵送で届いた領収書にも「椅子引き取り」の文字がしっかり記載されていました……何? 

  3. でも服にOKAMURAのロゴが入ってたし社員かもしれなかったのでもうすこし追求してもよかったかもしれない? 

Tweet
2019年08月10日
古い投稿