サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
Node.js Docker baseイメージには alpine < distroless < ubuntu+slim 構成がよさそう はじめに この記事は、DockerCon 2022 で発表された Bret Fisher の "Node.js Rocks in Docker, DockerCon 2022 Edition" を参考にしています。 base イメージの選択肢に関する話は、動画の前半一部分だけですが、他にも Node.js で Dockerfile を書く時のベストプラクティスが数多くまとまっているので、是非チェックしてみてください。 node:alpine イメージを使わない base イメージサイズを小さく保ちたい、という点で気軽に利用される事が多い alpine イメージですが、Official の README には下記の記載があります。 This variant
distrolessは、Googleが提供している、本当に必要な依存のみが含まれているcontainer imageです。そこにはaptはおろかshellも含まれておらず、非常にサイズの小さいimageとなっています。余計なプログラムが含まれていないことは attack surfaceの縮小にも繋がり、コンテナのセキュリティについての事業を展開しているSysdig社が公開しているDockerfileのベストプラクティスとしてもdistroless imageを使うことが推奨されています。 Dockerfileのベストプラクティス Top 20 | Sysdig 軽量Dockerイメージに安易にAlpineを使うのはやめたほうがいいという話 - inductor’s blog また先日、inductorさんがこのようなブログ記事を書き話題になりました。この記事からdistroless ima
この記事は はてなエンジニア Advent Calendar 2021 11日目の記事です。 コンテナのベースイメージとしてdistrolessを選択肢にするということがここ最近増えてきました。 そんなdistrolessを非rootユーザで使おうとしたらとても簡単だったのでその紹介です。 どのくらい簡単かというと、Goのアプリケーションであれば以下のように変えるだけで対応できます。(コメントアウト部分は元々のrootユーザで動かしていた場合のもの) FROM golang:1.17 as builder WORKDIR /go/src COPY go.mod go.sum . RUN go mod download COPY . . RUN go build -o /out/myapp . # FROM gcr.io/distroless/static:latest FROM gcr.i
こんにちは もしくは こんばんわ！ ANDPADボード プロダクトテックリードの原田 土屋(tomtwinkle)です 最近めでたく戸籍が代わり名字がリネームされました この記事はDebian12 bookwormが正式リリースされ、Debian11 Bullseyeが今までの流れでいうと来年辺りEOLになりそうな雰囲気なので今のうちに切り替えておこうと奮闘した記録とAlpine Linuxからdistrolessに変更したらKubernetesのpreStopが上手く動かなくなった件の対応をした記録の合せ技です。 TL;DR DockerのBuild base imageを Debian11 Bullseye から Debian12 bookworm にしただけで docker build がコケるようになったなら docker/buildx のversionを上げてみよう circle
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに NRI OpenStandia Advent Calendar 2021、15日目はコンテナ について考えます。 Linuxのコンテナ技術はプロダクション環境でも当たり前のように使われています。これに伴いコンテナ開発・運用の様々なベストプラクティスが提案されています。distrolessなコンテナもベストプラクティスとして提唱されているものの1つです。 本記事ではこのdistrolessなコンテナについて考えます。 #distrolessイメージを作成するでは実際にdistrolessなコンテナイメージを作成します。 dist
今回は NestJS を使っていますが、ビルド後のファイルと node_modules を使っているだけですので、Express やほかの FW でも同様にできると思います。 Distroless とは？ Google 製の Docker イメージです。 アプリケーションとそのランタイムの依存関係だけが含まれています。 本番環境に特化したイメージであり、ランタイムに不要なプログラム（シェルなど）を含まないのでパフォーマンスの向上・セキュリティ向上が見込めます。 また alpine ではなく Distroless を使う理由はこちらの記事が参考になるので、気になる方はこちらを参照してください。 Distroless で本番環境を作ろうとなったきっかけの記事でもあります。 結果 削減対策なし slim マルチビルド slim マルチビルド distroless
![Distrolessを使った2021年最新のDocker環境を試した[Node.js/NestJS]](/image.pl?url=https%3a%2f%2fcdn-ak-scissors.b.st-hatena.com%2fimage%2fsquare%2fd34e7557e0feb47857bd327d826dccc878abfa2b%2fheight%3d288%3bversion%3d1%3bwidth%3d512%2fhttps%253A%252F%252Fres.cloudinary.com%252Fzenn%252Fimage%252Fupload%252Fs--GFszclOe--%252Fc_fit%25252Cg_north_west%25252Cl_text%253Anotosansjp-medium.otf_55%253ADistroless%252525E3%25252582%25252592%252525E4%252525BD%252525BF%252525E3%25252581%252525A3%252525E3%25252581%2525259F2021%252525E5%252525B9%252525B4%252525E6%2525259C%25252580%252525E6%25252596%252525B0%252525E3%25252581%252525AEDocker%252525E7%25252592%252525B0%252525E5%252525A2%25252583%252525E3%25252582%25252592%252525E8%252525A9%252525A6%252525E3%25252581%25252597%252525E3%25252581%2525259F%2525255BNode.js%2525252FNestJS%2525255D%25252Cw_1010%25252Cx_90%25252Cy_100%252Fg_south_west%25252Cl_text%253Anotosansjp-medium.otf_37%253Anecocoa%25252Cx_203%25252Cy_121%252Fg_south_west%25252Ch_90%25252Cl_fetch%253AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzg5ZmE0OTIyMzIuanBlZw%253D%253D%25252Cr_max%25252Cw_90%25252Cx_87%25252Cy_95%252Fv1627283836%252Fdefault%252Fog-base-w1200-v2.png&f=jpg&w=240)
What's Inside Distroless Container Images: Taking a Closer Look GoogleContainerTools' distroless images are often mentioned as one of the ways to produce small(er), fast(er), and secure(r) containers. But what are these distroless images, really? What's the difference between a container image built from a distroless base and one built FROM scratch? Let's dive in! Why Do We Need Distroless Images?
概要 distrolessは、Googleが提供している必要最小限の依存のみが含まれるDebian10(buster)を基に作成されたコンテナイメージです。 imageのサイズが本当に小さく、aptやshellさえも含まれておりません。 よくベースとして利用されるLinuxディストリビューションは、基本的な設定ファイルやパッケージが大体含まれます。(カーネルを除く) なので、実際使用しないような不要なファイルが多数含まれているのが現状です。 distrolessは、このような不要なファイルを削除し、本当に必要な最小限のファイルのみを含んだimageとなっております。 何が嬉しいのか 上記にも挙げたのですが、嬉しさポイントは以下の２点です。 セキュア => 本当に実行に必要なのファイルのみを含んだimageとなっているので、不要なバグや脆弱性を埋め込みにくいという点が、セキュアだといえます。
きっかけ 元々、distroless-rubyは手作業で必要なファイルを抜き出して作成したものでした。 Rubyが動くdistroless image は作ることができるのか - Qiita Rubyのdistroless imageをmagicpakで構築できるのか？ ただ、この方針ではsinatraなどRuby単体で完結するプログラムは手軽に動かすことはできても、外部に依存するものがあるプログラムを動かすことはできません。具体的な例を挙げるならPostgreSQLをRubyで使用するために必要なpq gemはlibpq-devをapt経由でインストールする必要がありますが、distroless image内にはaptが存在しないのでインストールすることができません。multi stage buildを使用し、aptによって追加されたファイルを持ってくることも出来無くはないですが、依存す
distroless image distrolessは、Googleが提供している、本当に必要な依存のみが含まれているcontainer imageです。そこにはaptはおろかshellも含まれておらず、非常にサイズの小さいimageとなっています。余計なプログラムが含まれていないことは attack surfaceの縮小にも繋がり、コンテナのセキュリティについての事業を展開しているSysdig社が公開しているDockerfileのベストプラクティスとしてもdistroless imageを使うことが推奨されています。 また先日、inductorさんがこのようなブログ記事を書き話題になりました。この記事からdistroless imageのことを知った方も多いと思います。その中で僕が趣味で作った distroless-ruby を取り上げてくださり、ありがたいことに僕の所有しているものの
概要 distrolessは、Googleが提供している必要最小限の依存のみが含まれるDebian10(buster)を基に作成されたコンテナイメージです。 imageのサイズが本当に小さく、aptやshellさえも含まれておりません。 よくベースとして利用されるLinuxディストリビューションは、基本的な設定ファイルやパッケージが大体含まれます。(カーネルを除く) なので、実際使用しないような不要なファイルが多数含まれているのが現状です。 distrolessは、このような不要なファイルを削除し、本当に必要な最小限のファイルのみを含んだimageとなっております。 何が嬉しいのか 上記にも挙げたのですが、嬉しさポイントは以下の２点です。 セキュア => 本当に実行に必要なのファイルのみを含んだimageとなっているので、不要なバグや脆弱性を埋め込みにくいという点が、セキュアだといえます。
きっかけ 元々、distroless-rubyは手作業で必要なファイルを抜き出して作成したものでした。 Rubyが動くdistroless image は作ることができるのか - Qiita Rubyのdistroless imageをmagicpakで構築できるのか？ ただ、この方針ではsinatraなどRuby単体で完結するプログラムは手軽に動かすことはできても、外部に依存するものがあるプログラムを動かすことはできません。具体的な例を挙げるならPostgreSQLをRubyで使用するために必要なpq gemはlibpq-devをapt経由でインストールする必要がありますが、distroless image内にはaptが存在しないのでインストールすることができません。multi stage buildを使用し、aptによって追加されたファイルを持ってくることも出来無くはないですが、依存す
こんにちは、X（クロス）イノベーション本部 ソフトウェアデザインセンター・セキュリティグループの大西です。現在、DockerとTypeScriptを使ってシステムを開発中です。DockerのDistrolessイメージの中で、ORMのPrismaを使おうとするとエラーが出てハマってしまったので、エラー解消の方法についてお話ししたいと思います。 まずは少し、DistrolessイメージとPrismaについて説明します。 Distrolessイメージとは Googleが公開しているDistrolessイメージとは、アプリケーションの実行に必要な最小限のファイルのみが入っている超軽量なDockerイメージです。それゆえ、普通のOSに入っているようなパッケージマネージャーやシェルなどは入っていません。最も小さいサイズのものでgcr.io/distroless/static-debian11はたった
はじめに AWS ECS+ECRで動いているpythonのサービスがあった ただし、ECRのスキャン機能でものすごい数の脆弱性が出ていた... 1つずつ解消していくのは現実的ではないため、distrolessコンテナを導入することになった distrolessとは Googleが提供しているコンテナイメージ アプリケーションとそのランタイム依存関係のみ含まれる(=必要最小限) パッケージマネージャー、シェルなどは含まれない 導入メリットとして、①軽量であること、②セキュアであることが挙げられる やったことざっくりと 以前は「python:3.9.13-slim-buster」のイメージを使用してビルドしていた これを1段階目「python:3.9.13-slim-buster」→2段階目「gcr.io/distroless/python3」のマルチステージビルドにする 1段階目 パッケージ
distrolessは通常はインストールされているパッケージが 全く入っていない軽量なDockerイメージ。殆どなにも入っていないので、デプロイ／ビルドが高速で行えて セキュリティ的にも堅牢な所からGoogleを含むいろいろなところで採用されている。 だが個人的にはデバッグに対してかなり不安があった。netstat,tcpdump,ps,nslookup,ping…などのデバッグに必要な コマンドが何1つ入っていないし,パッケージマネージャーも入っていないのであとからインストールするのも難しい。 またシェルすら入っていないので、distrolessで作成されたPodにkubectl execで乗り込む事もできない。 $ kubectl exec -it testpod /bin/bash # bashが無いので当然無理 OCI runtime exec failed: exec faile
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
