マルチステージビルドを活用したDockerイメージの軽量化手法
こちらの記事は某社によるアドベントカレンダー15日目の記事です。
近年の開発現場では、コンテナを使用する機会が増えてきています。
コンテナで開発をする時にイメージが重すぎてしまうなんてことはないでしょうか。
そのためビルドに時間がかかったりストレージを圧迫してしまいます。
その対策の一つとしてマルチステージビルドがあります。
最近実践で使う必要が出てきたため、忘備録として書いておこうと思います。
マルチステージビルドとは
マルチステージビルドとはコンテナイメージを構築する時にビルドステージと本番ステージを別々のコンテナで行われる仕組みのことになります。
それぞれのステージは以下の役割となります。
- ビルドステージ：必要なツールやライブラリを使用してアプリケーションをビルド
- 本番ステージ：ビルド成果物のみを含む最小限の環境を構築
これによりビルド時にコンテナに余計なファイル群などを持ち込むことがなくなります。
マルチステージビルド有無での比較
マルチステージビルドを使用するかしないかで、どの程度イメージの容量に差があるか見てみたいと思います。
サンプルコードはこちら
github.com
READMEの手順でビルドをして、イメージサイズを確認してみます。
$ docker images | grep django multi-stage-build-django-multi latest 32f318beef86 38 seconds ago 310MB multi-stage-build-django-simple latest f6a8b44b8a31 About a minute ago 1.11GB
800MBくらい少なくなりました。
マルチステージビルドのソースはこちらになります。
# ビルドステージ
FROM python:3.13-slim as builder
WORKDIR /app
RUN apt-get update && \
apt-get install -y --no-install-recommends \
build-essential \
gcc \
&& rm -rf /var/lib/apt/lists/*
RUN python -m venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# 本番ステージ
FROM python:3.13-slim as production
WORKDIR /app
RUN apt-get update && \
apt-get install -y --no-install-recommends \
libpq-dev \
&& rm -rf /var/lib/apt/lists/*
COPY --from=builder /opt/venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"
COPY . .
RUN useradd -m appuser && \
chown -R appuser:appuser /app
USER appuser
ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1
EXPOSE 8000
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "multi.wsgi:application"]
通常のビルドと異なる点は以下の通りです。
- ビルドステージに必要な依存関係をインストール
- venvを使用してビルド時の一時ファイルを除外しています。
- 必要なファイルのみを本番ステージにコピーし、必要なパッケージのみ含む環境となる
余計なものをコンテナに持ち込まないようにすることで大幅に削減することができました。
他に軽量化する方法
マルチステージビルド以外にも軽量化させる方法として以下の方法があります。
- アプリケーション実行時に不要なファイルやディレクトリを.dockerignoreで除外する
- アプリケーションの実行に必要なファイルのみをCOPYする
- distrolessやalpineなどの軽量なベースイメージを使用する
所感
今まで関わったプロジェクトで使われてるケースを見ることはあったのですが、実践で試すような機会がありませんでした。
非常に軽量化されるので積極的に使っていこうと思います。
参考
- Docker/Kubernetes実践コンテナ開発入門 改訂新版 gihyo.jp
Kotlin Fest 2024に参加しました
Kotlin Fest 2024に参加
Kotlin Fest 2024に行ってきました。 www.kotlinfest.dev
前回カンファレンスに参加してたのがPyConJP2019の時で、約5年前くらいなのですごい久々です。
Kotlinについて
ほとんど触ったことはありません。
先日軽くKotlin ツアーをやってみたくらいです。
karino2.github.io
ただ直近仕事でGoやTypeScriptを触ることがあるため、なんとなくは分かるくらいです。
雰囲気と感想
- Kotlinフェスも5年ぶりにオフで行われたのでだいぶ盛り上がっていた様子
Kotlin界隈はほとんど知り合いもなく、アウェーではあったものの十分楽しめる内容だった。
普段はサーバーサイドの仕事が多いので、その辺り関係してそうな例外処理の設計やユニットテスト、プラグイン、歴史の可視化とかを聞いていた。
例外設計について考えて Kotlin（Spring Boot&Arrow）で実践する
まだ JUnit を使ってるの？ kotest を使って快適にテストを書こう
K2のKotlin IDEプラグインの中を覗いてみよう♪
Kotlinの歴史を可視化する
あと途中セッションがある時間でも聞かないタイミングを作ったので、その時間にスポンサーブースを回ってJetBrainsのバッジをもらった。
頑張って起きて午前中のサーバーサイドプログラミング実践開発とクリエイティブコーディングの話は聞いておきたかった。
Kotlinで愉たのしむ クリエイティブコーディング
2024年版 Kotlin サーバーサイドプログラミング実践開発
おかげで今のKotlin事情を知れたのは良かった。
タイミング合えば来年も行こうかなと思います。
今年読んだ技術書を振り返る
こちらはジャンルなしオンラインもくもく会 Advent Calendar 2023の25日目の投稿です。
adventar.org
思いっきりクリスマス過ぎてしまい、年末まであとわずかな時間で書いている。
去年から個人で外部の読書会に参加してて、気づいたら参加してる流れで運営にも関わるようになった。
せっかくなので今年読書会で読んだのと個人的に読んだ技術書でも振り返る。
はじめよう! システム設計 ~要件定義のその後に
個人的に3年くらい前に読んだやつだが、改めて一緒に読むと見落としてたところが色々あった気がする。
確か年明けくらいまで読んでたのでだいぶ忘れてしまってる。
また定期で読み直した方がいいかもしれない。
SQL実践入門──高速でわかりやすいクエリの書き方
これはいつか読もうと思ってずっと放置してた本
実行計画について実務でも何回か経験してはいたが、いまいち分かってなかった。
この時に一通り読めてよかった。
Python FlaskによるWebアプリ開発入門
これは仕事でFlaskを使う必要があったので、Web開発部分だけ軽くやっておいたもの
物体検知まではやれてなかったので、時間があったらやっておきたい。
RDBエンジニアでもできる！MongoDBの構築と運用入門
だいぶ前に購入して一回読んだ程度しか見てなかったのもあり、読書会に候補であげて読んでた本
MongoDBの基本操作や構築などの情報がまとまっており、実務でやることになれば
とりあえずどうにかなるぐらいの話は載ってます。
ただレプリケーションの記載内容が不足してたので、構築したい場合は個別で調べる必要があります。
あと購入する場合、こっちで買ったほうが少しだけ補足やGrafanaの話とかあります。↓
RDBエンジニアでもできる！MongoDBの構築と運用入門 | 電子書籍とプリントオンデマンド（POD） | NextPublishing（ネクストパブリッシング）
システム開発のための見積りのすべてがわかる本
これも確か読書会に候補であげて読むことになったものだと思う。
見積もりがこれで精度が上がったかどうかはなかなか難しいなと思った。
イラストでわかるDockerとKubernetes
個人的に読んでた本
前から気になってたのだが、放置して読んでなかったのを非常に後悔した。
イラストが豊富で非常にわかりやすかった。
コンテナがよく分からない人はこれをまず読むのがいいと思う。
［試して理解］Linuxのしくみ ―実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】
今まで謎だったLinuxがどうなっているかが少しだけ理解できた。
これも適度に読み返しながら理解を深める必要がある1冊でした。
おかげでLinuxに対して興味を持てるきっかけにはなったと思う。
コンテナセキュリティ コンテナ化されたアプリケーションを保護する要素技術
コンテナのセキュリティ周りでよく分からなかった時があり、その直後くらいに出て読んだ本
内容的にあまり手を動かす要素は少なく、セキュリティ検証やツールについて解説された本です。
この本を読むことで、セキュリティ面で注意すべき点が明確になった。
また利用ツールは何があるかを知れたのはよかったと思う。
book.impress.co.jp
SQLクックブック 第2版
読書会で読んでみたのだが、とにかく大変だった一冊
それでも560ページ近くいろんなパターンのSQLレシピが紹介されており
初歩程度のことしか分かってない自分にとって、色々知ることができたのは収穫だった。
現場で役立つシステム設計の原則
だいぶ前から知ってたにも関わらず、全く読んでこなかったことを後悔した本
ソースコードを例に設計のやり方や考え方について少しだけ理解できた。
あくまで少しなので、改めて書き慣れた言語で書いて考えてみたい。
人が増えても速くならない ～変化を抱擁せよ～
この本は非エンジニアでも分かりやすい言葉で解説されている。
なんでソフトウェア開発にこんな時間がかかるの？と言ってる人にこの本を読んでもらえれば、
一定の理解はしてくれるのではないかと思う内容です。
GitLabに学ぶ 世界最先端のリモート組織のつくりかた
最近はリモートで仕事をすることはあるので、フルリモートもしくはハイブリッドで仕事をするといったことがあれば、 いくらかは参考にはなると思う。
Web APIの設計
個人的に読んではいたのだけど、改めて読書会でも読んだ。
API仕様書の話とかレスポンスのあたりを知らない人には分かりやすいかと思います。
ただ前編をおして、記憶に残りにくいところはあるかも
世界一流エンジニアの思考法
帯にも書いている
”三流プログラマ”でもできた〈生産性爆上がり〉の技術！
について書かれた本
この本のおかげで自分の非効率なマルチタスクを見直すきっかけになりました。
自分はまだまだ三流だと思っているので非常に共感できることばかりでした。
はじめての設計をやり抜くための本 第2版
設計でこれはどう書くんだっけ？って思った時に見返しておきたい。
設計についてこれでもかってくらい充実した内容でした。
3カ月で改善！システム障害対応 実践ガイド
前に書いた本なのですが改めて
システムに関わる人は誰しも読んでおくと良い本
なかなか障害に対応する実践的な本は珍しいかと思います。
基礎から学ぶコンテナセキュリティ――Dockerを通して理解するコンテナの攻撃例と対策
誤植や説明不足はあったものの
前に紹介したコンテナセキュリティの本と比較して、より実践的なツールの使用方法に焦点を当てている。
薄い本ですが、かなり使える内容だった。
実践でも積極的に取り入れたいと思いました。
『実践マイクロサービスAPI』
こちらの本はまだ読み途中です。
内容はタイトルの通りマイクロサービスを開発する上で特に必要なAPI設計、実装、ドメインなどについて解説している。
今までいくつかマイクロサービスの案件に関わったことがあるのですが、この本を読めば、マイクロサービスでの開発に遭遇しても困ることはないかと思います。
Web APIの設計より実践的な内容です。
www.seshop.com
こちらの本は自分が個人的に読書会をやりたいと思ったので、自分で立ち上げて始めている。
最後に
これは本を読むことだけではないが
結構マルチタスクで非効率なことをしてたので、先ほど紹介した世界一流エンジニア本で少しだけ改善できた。
一昨年より前は色々と停滞していたので、来年はもっとペースを上げていきたい。
システム障害対応実践ガイドを読んだ
こちらはITサービスマネージャー（保守運用・ITSM・IT service manager） Advent Calendar 2023の24日目の投稿記事です。
ちょうど今日システム障害対応 実践ガイドを読了した。
もう3ヶ月前、BPStudy#193〜システム障害は突然に/ 障害対応のポイントや改善方法を学ぼうという障害対応をテーマにしたイベントがあった。
その時、システム障害対応実践ガイドの著者から書籍プレゼントに応募し当選したが、受け取ってからはずっと読まずに放置してしまいました。
ちょうどアドベントカレンダーの季節となり、ITサービスマネージャー（保守運用・ITSM・IT service manager） Advent Calendar 2023があったので参加しつつ、本を読み終えるために書いたものです。
BPStudy#193〜システム障害は突然に/ 障害対応のポイントや改善方法を学ぼうの当時のイベントと書籍はこちら
bpstudy.connpass.com
3カ月で改善！システム障害対応 実践ガイド インシデントの洗い出しから障害訓練まで、開発チームとユーザー企業の「協同」で現場を変える
www.seshop.com
どういう本か
この本はシステム障害対応の方法について解説しています。
例えば現在何か案件に参画してて障害対応が起きても対応しっぱなしで、その後も改善がされてないなどよくあると思うのですが、そういった時に3ヶ月くらいかけて段階的に改善対応の方法について詳しく解説しています。
- また実践での改善だけでなく障害対応の目的や改善効果、障害対応を行なった後の振り返りやチェックすべきことなどについても記載されています。
ポイントなど
実践編において3ヶ月くらいの内容を1週間くらいの単位で段階的に解説しているのでどう改善すればいいかが分かりやすく書かれています。
例えば、障害が起きたときにログを確認する時に余計な情報などないか、またはアラートが来たときに不必要なものがないかといったことなどが挙げられています。実践する場合にどういった声がけをするといいかが解説されており、これらは1週間単位で記載がされてるので、それぞれのシチュエーションでどう聞き出せばいいか参考になるかと思います。
あと実際に障害が起きることを想定して、どう連絡を取るかを決めておくなどがあります。
実際起きた時に、いろんな部署や顧客を巻き込んで対応する必要があったりするので、Slackで大丈夫と思ってても別部署などでは別の連絡方法が必要になるといったことがあります。そのため、緊急での対応の認識合わせが重要と記載されていました。
所感
- 障害対応についても通常の開発と同じように属人化せず、誰でも対応できるようにするのが重要だと思った。
- 特定の人だけが対応するのは、いざその人がいなくなれば、その後で別の人が対応することになり、どう対応すべきかが分からなくなったりして、残った人達が苦労すると思われます。
- あと特定の人だけで常に対応することになると、負担も大きいと思われます。例えば連日障害が出てたり休日出勤も頻繁にあるなどしたら大変でしょう。
- この本にもあるように障害対応をするエンジニアやQA、顧客側も含めてお互いに協力体制を築くのが理想ではあるが、ここが一番大変だろうなという気がした。それぞれで立場的なところは話し合いができればどうにかなるかもしれないが、会社によって結構お役所的なところだったり心理的安全性の部分を考えると上手く進めるには別の障壁が大きいかもと思った。
この本には書かれてないのですが、BPStudyのイベントで著者の野村さんが言われてた、障害対応が長時間続く場合、必ず長時間対応してた人を休ませるという話があった。障害対応を行う人は責任感があり、無理をしやすいことが多いとのこと。 確かにその通りで、復旧に集中し過ぎると、対応している人の精神状態が後回しになりがちです。実際に起きた時は、この点にも注意したいと思います。
自分が心当たりのあった障害だと、開発環境にデプロイするたびに障害が起きてた時があり（本番リリースはいつも問題なしでした）、当然その度に対応してたのですが、その時システム周りについて誰も詳しい人がいなかったので、対策として毎回その時の障害報告をあげてもらってどういうことが起きて、どういう対策をしたかを残してもらうようにしました。
結果的に障害はそんなには減らなかったものの、今まで数時間かかって対処してたものをいくらか対応を時間を削減したり、どう対処すればいいか困ることは少なくなったと思います。Chapter1にあったROI（投資対効果: Return On Investment）ってどうやって算出してる値なんだろうと思って少しだけ調べた。利益金額÷投資金額×100（％）になってるっぽい
参考： ROI（投資利益率）とは？【意味をわかりやすく】計算方法 - カオナビ人事用語集
まとめ
この本は日々の障害対応に追われている人、頻繁な障害対応で困っている人、または重要なアラートや通知を見逃してしまう人に特におすすめです。
コンテナセキュリティ本の読書会
こちらはジャンルなしオンラインもくもく会アドベントカレンダー3日目です。
ちなみに日付が変わって4日になって書いてます。。。
8月くらいからこの本の読書会をやっている。
この本は開発時によく使用されてるコンテナのセキュリティについて
攻撃事例と対策
コンテナの仕組みとコンテナ型仮想化
主にはこのあたりについて手を動かして理解する本です。
よかった点
攻撃事例は実際手を動かして確認できるので、イメージはつきやすいです。 ただLinuxの知識はある程度ないと難しいところはありますが
セキュリティ対策として色々紹介されており、案件の状況とかに併せて使うのがいいのかなと思います。
注意点
誤植が多いため、正誤表など確認しつつ進めてもらった方が良さそうです。
手順にかなり不足してる点が多く、重複して必要な手順が省略されてる箇所などがあり検証に結構苦労しました。
特にP.149あたりに記載されてるRootlessですが構築した状態で、他で紹介されてるツールなど検証をしようとすると失敗するので、必ずRootlessでないDockerに戻して検証する必要があります。
実はまだ完全に読み終えていないので年内までに終わらせたいお気持ちです。
日報 2023-05-09
今日は少し残業したのと火曜は定期で読書会をやってたので業務外で個人的なことはあまりできず。
Web APIの設計の読書会は来週もやってます yuruora.connpass.com
そういえば時間が取れてなかったのは別でこれを見てたのもある。
日報 2023-05-08
忘れそうになったが、ふと思い出して書く
今日から連休あけなので業務がほとんど
ユニットテスト
今ひたすらユニットテストを書く作業をしている。
今更ながらモックも雰囲気で書いてたのを何となく理解しだした。
半年くらい前にもひたすらユニットテストを書く時があったものの
その時は書き方をどうにか覚えるので精一杯な感じだった。
改めて書くとまだまだ慣れないことが多い。
業務後は読み途中だったこれを写経してた
www.amazon.co.jp
比較的薄い本ではあるが、後半のハンズオンは実践的な内容になっていて助かっています。
