はてなブックマーク

背景 https://github.com/orisano/sqlc-gen-ts-d1 というプラグインを作成していて生成コードの好みが人によって大きく異なると感じることがありました。 一つのプラグインで生成コードをカスタマイズできるアプローチには保守性的な意味でも限界があるだろうと思いました。 気軽にプラグインが作れるようになることで自分の好みのコードが生成できるし、好みが似通ったコミュニティにメンテンスされているプラグインが一つでもあれば幸せな人も増えるかなと思ったため記事を書くことにしました。 とはいえ sqlc を使い始めるとき最初にプラグインを書くことはまずないし、デフォルトの生成コードが好みでなかったりそもそも対応してない場合は選択肢から外れるだけだと思います。 なので sqlc を使いたいという情熱のある人やプラグインを作りたいという人の役に立てばと幸いです。 plugin

https://blog.cloudflare.com/how-to-stop-running-out-of-ephemeral-ports-and-start-to-love-long-lived-connections/ を読んでいて理解できなかったところをまとめた記事です。 元記事の簡単な概要 エフェメラルポートが枯渇しないようにローカルポートの再利用をしたい。 TCP の普通のユースケースでは自動で再利用されるので困らない。 送信元アドレスを固定する場合はうまく再利用できなかったが 2015 年から IP_BIND_ADDRESS_NO_PORT が追加され問題なく再利用できるようになった。 送信元ポートも固定する場合は SO_REUSEADDR を使うことで再利用ができる。 ところが UDP ではローカルポートの再利用がうまく動かないし、TCP のような簡単な回避策はない。 いか

この記事は Recruit Advent Calendar 2021 の15日目の記事です。 TL;DR 従来のレイヤー並列の pull より Range リクエストを用いたチャンク並列の pull によって速度が 2~5倍速くなる可能性がある。 ECR は Public だと region ごとに速度が大きく異るので安定した速度を求める場合は Private にする。 (pull through cache を活用すると良い) 2022/10/9 追記: ECR の Public が適切な Pop から返ってくるようになっていた。 その Benchmark も取得し、結果を追記した。 ap-northeast-1 では6倍近く早くなっていて region による差が小さくなっていた。 背景・動機 コンテナイメージは一つ以上のマニフェスト、そこから得られるコンフィグとレイヤーから構成される

TL;DR kaniko を理解してない限りコンテナから出してはいけない. kaniko を使っていればmulti stage buildだろうとCIのcacheについて余計なことを考えなくてよい (Dockerfileの書き方はcacheを意識して) kaniko とは github.com kanikoはGoogleが作っているコンテナの中やKubernetes上で動くコンテナのbuilderです. Cloud Buildなどで使うことができます. kaniko の内部実装 早速ですが kanikoのbuildの詳細を調査するために以下から実装を読み進めました. 8c732f6f52bb334727194d090826e8dbd1df3793 における実装の詳細です. github.com Directory /kaniko 以下が内部状態 (1) /kaniko/<image nam

表題の通りなのですが, monorepoにおけるdocker buildの話です. build contextの話 まずこの問題を認識する上で必要なのがbuild contextの理解です. docs.docker.com Best practiceでも触れられている通り, build contextの概念は非常に重要です. When you issue a docker build command, the current working directory is called the build context. By default, the Dockerfile is assumed to be located here, but you can specify a different location with the file flag (-f). Regardless of

CIの時間を短くする活動を行っており, 特にその一部のアプリケーションコンテナの継続的 docker buildの改善について書きたいと思います. CIにおけるMulti-stage Builds Multi-stage Buildsについては以下の記事を参照すると良いと思います. docs.docker.com Multi-stage Buildsは最終イメージサイズを簡単に小さくするために導入された機能です. イメージサイズを小さくするだけではなく様々な活用方法が生み出されました. medium.com speakerdeck.com 今では効率的なdocker buildにはMulti-stage Buildsは欠かせないものになっています. Multi-stage Builds以前のCI環境では1 Dockerfile 1 Cacheの考え方で問題なかったのですが, Multi-s

CIの時間を短くする活動を行っており, 特にその一部のアプリケーションコンテナビルドの改善について書きたいと思います. TL;DR コンテナイメージを小さくするのは pull / push のコストを減らすため ベースイメージを小さいものにする (ex. alpine linux, distroless) Multi-stage Buildsを活用する イメージに不要なファイルが含まれていないかを確認する. dlayer コンテナイメージを小さくするために なぜ小さくするのか pull / pushのコストを減らすためです. CIの時間を短くするという文脈においては 成果物の push 依存イメージの pull (docker-compose を用いたテストなど) docker build が主な改善対象になります. (1), (2) に関してはコンテナイメージを小さくすることで直接的な効

CIの時間を短くする活動を行っており, 特にその一部のアプリケーションコンテナの継続的 docker buildの改善について書きたいと思います. TL;DR dockerd の内部でイメージの子についての情報を持っている イメージ自体は親の情報しか持ってない cache対象のイメージは, 親イメージの子の中にcompare で同一とみなされる最新のもの 同一のものかどうかと言うのは命令, LABEL, ENV, ENTRYPOINT, EXPOSE, VOLUMEが変更されていないということ COPY, ADDは内部的にコマンドにコメントを埋め込む. そのコメントの中にコピーするファイルのハッシュが含まれている. コピーするファイルのハッシュが変わった場合に命令(に付随するコメント)が変わるのでcacheがbustedになる 前提 アプリケーションはすべてコンテナ化されている CI上でコ

github.com GitHub - go-openapi/loads: openapi specification object model の速度を改善したときの話をしたいと思います. go-openapi/loadsはgoでopenapiのschemaを読み込むためのライブラリです. 調査の結果json.Unmarshalが重く,このライブラリのAnalyzedという関数から呼び出されていることがわかっていました. 実際に見てみると以下のような実装でした. // Analyzed creates a new analyzed spec document func Analyzed(data json.RawMessage, version string) (*Document, error) { if version == "" { version = "2.0" } if ver