並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 116件

新着順 人気順

distrolessの検索結果1 - 40 件 / 116件

  • Dockerfileのベストプラクティス Top 20

    本文の内容は、2021年3月9日にÁlvaro Iradierが投稿したブログ(https://sysdig.com/blog/dockerfile-best-practices/)を元に日本語に翻訳・再構成した内容となっております。 Dockerfileのベストプラクティスのクイックセットをイメージビルドに適用することで、セキュリティ問題を防ぎ、コンテナ化されたアプリケーションを最適化する方法を学びます。 コンテナ化されたアプリケーションやマイクロサービスに精通している人なら、自分のサービスがマイクロサービスであることに気づいているかもしれません。しかし、脆弱性の検出、セキュリティ問題の調査、デプロイ後の報告や修正など、管理のオーバーヘッドがマクロな問題になっています。 このオーバーヘッドの多くは、セキュリティをシフトレフトし、開発ワークフローの中で可能な限り早く潜在的な問題に取り組むこ

      Dockerfileのベストプラクティス Top 20
    • 軽量Dockerイメージに安易にAlpineを使うのはやめたほうがいいという話 - inductor's blog

      はじめに やめろ、ではなく、やめたほうがいい。です。自分のユースケースに合ってるか今一度確認することを推奨します。基本的にはAlpineは避けたほうが良い、というのが2021年時点での私の認識です。 なんで? libcに一般的な互換性が不足しているからです。Ruby、Python、Node.jsなどでNativeモジュールをバンドルしているアプリケーションの場合、パフォーマンスの劣化や互換性の問題にぶち当たる場合があります。 superuser.com あとは他のベースイメージの軽量化もそれなりに進んできていて、Alpineが定番軽量イメージと言う認識は2018年頃には消えつつあったかなという認識でいます。 どうすりゃええねん ※Debian Slimがあるやんってツッコミ結構もらったんですが、Slimは当たり前過ぎてもう紹介しなくていいかなっていう甘えで省略していました。よろしくおねがい

        軽量Dockerイメージに安易にAlpineを使うのはやめたほうがいいという話 - inductor's blog
      • Linuxコンテナの「次」としてのWebAssembly、の解説

        はじめに WASMをブラウザの外で動かすトレンドに関して「Linuxコンテナの「次」としてのWebAssemblyの解説」というタイトルで動画を投稿したのですが、動画では話しきれなかった内容をこちらの記事で補完したいと思います。 2022年もWebAssembly(WASM)の話題が多く発表されましたが、そのひとつにDocker for DesktopのWASM対応があります。FastlyやCloudflareもエッジ環境でWASMを動かすソリューションを持っていますし、MSのAKS(Azure Kubernetes Service)でもWASMにpreview対応しています。WASM Buildersでも2023年のWASMの予想としてWASMのアプリケーションランタイム利用に関して言及されました。 WASMといえば元々ブラウザ上で高速にC++のコードなどを実行するところから始まっている

          Linuxコンテナの「次」としてのWebAssembly、の解説
        • シェルスクリプトを書くのをやめる - blog.8-p.info

          今年から、できるだけシェルスクリプトを書くのをやめようとしている。私が毎日 zsh に打ち込んでいるのも広義のシェルスクリプトだし、自分用の雑なスクリプトを書くことはあるけれど、チームの他の人も将来に使ったり改変したりするようなものは、なるだけ他の言語を使っている。 シェルスクリプトを書くのは難しいし、その難しさは、学ぶに値しないといったら言い過ぎかもしれないけれど、2021年に初心者が取り組むべき問題とは言い難いと思う。 シェルは悪いプログラミング言語である Bash Strict Mode とかを使ってみても、シェルスクリプトには落とし穴が多すぎる。自分で書いたものを自分で使っている分には大丈夫なのだけど、スクリプトがチーム内で使われるようになると、考慮していなかったところ、例えばファイル名に空白文字が含まれるとか、そういうレベルの微妙なところで、ちゃんと書かれていないスクリプトは壊れ

          • Dockerfileのベストプラクティスとセキュリティについて - エニグモ開発者ブログ

            こんにちは、主に検索周りを担当しているエンジニアの伊藤です。 この記事は Enigmo Advent Calendar 2020 の 17 日目の記事です。 みなさんは適切なDockerfileを書けていますか?とりあえずイメージのビルドが出来ればいいやとなっていませんか? 今回は自戒の意味も込めて、改めてDockefileのベストプラクティスについて触れつつ、 そもそもDockerfileを書かずにコンテナイメージをビルドする方法とコンテナセキュリティに関する内容についてまとめてみました。 Dockerfileのベストプラクティス イメージサイズは極力小さくしよう ビルドキャッシュを活用しよう Dockerfileに関する悩みどころ Dockerfileを書かないという選択肢 Buildpack Cloud Native Buildpacks CNBの仕組み デモ CNBのメリット セキ

              Dockerfileのベストプラクティスとセキュリティについて - エニグモ開発者ブログ
            • Dockerfileのベストプラクティス - Qiita

              業務やプライベートでのハンズオンを通して得た知見を元に、dockerfileの実践的な書き方を記載いたしました。 軽量なdocker imageを作る観点とセキュリティーの観点を踏まえた内容になっております。なにか付け足す点などあればコメントいただければと思います。 軽量なimageを作る観点 軽量なimageの使用 Dockerfileでimageを指定する際に、軽量なimageを使用することが進めれている。 docker docsでも代表的な軽量なimageのalpineをおすすめしている。 Whenever possible, use current official images as the basis for your images. We recommend the Alpine image as it is tightly controlled and small in s

                Dockerfileのベストプラクティス - Qiita
              • 初学者のための正しいシェルとカーネルの概念 ~ 大学も技術者認定機関も間違いだらけ - Qiita

                なんだろう、嘘つくのやめてもらっていいですか? 大学も技術者認定機関も、いつまで古いまたは間違ったシェルとカーネルの概念を説明し続けるのでしょうか? シェルはカーネルの言葉をユーザーの言葉に翻訳したり、出力結果をユーザーに中継したり、カーネルを防御したりする層ではありません。指定したコマンドを実行するだけのプログラムです。勉強中の学生か代理執筆業者が適当な文献を調べて書いたとしか思えません。そして他人の説明を自分の言葉に置き換えるのが上手い人がおかしな説明をさらに広めています。個人サイトやオンライン学習サイト程度であれば適当なことを書いていても気にも留めませんが、大学や技術者認定機関のような正しいことを書いているに違いないと思えるような所までもが間違ったことを書いているから困ったものです。 みなさんは大学や技術者認定機関が言っていることなら正しいと思いこんでいないでしょうか? そんなことあ

                  初学者のための正しいシェルとカーネルの概念 ~ 大学も技術者認定機関も間違いだらけ - Qiita
                • Dockerfileを書かずにBuildpacksで圧倒的に軽量なDockerイメージを作成する(539MB->245MB) - 🤖

                  はじめに 2018 年 10 月に Cloud Native Buildpacks は Cloud Native Computing Foundation (CNCF)に Sandbox として受け入れられました。 CNCF には Kubernetes, Prometheus, Envoy, Fluentd など有名プロジェクトも多く受け入れられています。 Buildpacks を使うことで、Dockerfile を書かなくても Docker イメージを作成できます。 また、作成されるイメージはかなり軽量でした。 buildpacks.io 試してみた 今回は、以下のリポジトリの Java アプリケーションの Docker イメージを作成します。 github.com インストール # Mac $ brew install buildpacks/tap/pack # Linux $ wge

                    Dockerfileを書かずにBuildpacksで圧倒的に軽量なDockerイメージを作成する(539MB->245MB) - 🤖
                  • Go製アプリケーションのコンテナ化にはkoを推したい - YAMAGUCHI::weblog

                    はじめに こんにちは、Google Cloudでオブザーバビリティを担当しているものです。Cloud Operations suiteをよろしくおねがいします。(宣伝終わり) この記事はGo Advent Calendar 2021 その1の22日目の記事です。昨日は @sago35tk さんの「ESP32 向けに TinyGo をセットアップする」でした。TinyGoのコアな情報を日本語で教えてくれるtakasagoさんには本当にいつも感謝しています。 さて、今日はGo製のアプリケーションをdockerlessでコンテナ化できるkoの紹介をします。koは本当にイチオシのツールで、みんなに使ってもらいたいのでぜひ使ってください。 github.com DockerによるGo製アプリのコンテナ化 まず最もポピュラーと思われるDockerを用いた場合のGo製アプリケーションのコンテナ化の方法に

                      Go製アプリケーションのコンテナ化にはkoを推したい - YAMAGUCHI::weblog
                    • コンテナのベストプラクティスに対しておこがましくも言ってみる - Qiita

                      最近実際に開発現場にコンテナを導入してきた経験から、公式ドキュメントに記載されているベストプラクティスに実際どうなんだということを言ってみようと思います。公式に書いてあることを間違ってると指摘という意図はありません 発言は個人の見解に基づくものであり、所属組織を代表するものではありません。 2023/12/3更新: 燃えかけてるのでタイトルを変えました。 補足: こちらの環境は下記を想定しています。 Java CICD/本番環境イントラネット内に整備 WF開発 マルチステージ・ビルドを使う マルチステージビルドの目的 公式ドキュメントには、下記のように記載があります。 マルチステージ・ビルド は、中間レイヤとイメージの数を減らすのに苦労しなくても、最終イメージの容量を大幅に減少できます。 つまり、最終イメージの容量を減らすことが目的であって、その一つの手段としてマルチステージビルドを進めて

                        コンテナのベストプラクティスに対しておこがましくも言ってみる - Qiita
                      • スタートアップで働くエンジニアが銀の弾丸を求めて愚直に働いている話 ~ 銀の弾丸なんてものは存在しない ~ - ANDPAD Tech Blog

                        こんにちは。こんばんは。おはようございます。アンドパッドで現在はバックエンドの方のエンジニアをやっている北村です。 アンドパッドには2021年4月にJOINしまして、現在までANDPADボード(以下ボード)の開発に携わっています。ANDPAD施工管理が比較的長期間の工事をターゲットにしているのに対してANDPADボードは1日〜数日の間に短期間の工事や施工を行う際のスケジュール管理を行えるサービスです。 lp.andpad.jp 半年ほど前に同チームのバックエンドエンジニアの原田さんに技術的負債を粉砕する記事を投稿してもらいました。今回はその続きの話をしようと思います。 前回記事は塵積もった技術的負債に対する技術的なアプローチがメインでしたが、今回はプロセスやチームビルディングの参考になりそうな話をバックエンドエンジニア目線で書いたものになります。 ANDPADボードの開発チーム紹介 話をイ

                          スタートアップで働くエンジニアが銀の弾丸を求めて愚直に働いている話 ~ 銀の弾丸なんてものは存在しない ~ - ANDPAD Tech Blog
                        • Node.jsコンテナイメージを極限まで軽量化! サイズを1/10以下に|SHIFT Group 技術ブログ

                          はじめにSHIFT DAAE の shinagawa です。表題の通りNode.jsで作成したコンテナのイメージサイズの軽量化に挑戦しました。 背景近年の多様化・高速化するビジネスに対応するITシステムの構築を実現する「クラウドネイティブ」の構成要素の一つとして 「コンテナ」という仮想化技術が存在し、当部門でも活用を進めております。 このコンテナイメージを作成するにはアプリケーションコードやライブラリ・モジュールなどの依存物、ランタイム等を1つのイメージとして組み立てて作成しますが、 この構成要素が増えるとイメージサイズが肥大化し保管時のストレージのコストの増加やイメージの転送、環境への展開に時間がかかることになります。 従ってイメージのサイズを削減することは、これらの点を改善することにつながります。 ここではネット上で紹介されている、あらゆる打ち手を組み合わせてコンテナイメージの軽量化に

                            Node.jsコンテナイメージを極限まで軽量化! サイズを1/10以下に|SHIFT Group 技術ブログ
                          • Ubuntuが.NET 6/ASP.NETをネイティブサポートすると発表。最適化されたコンテナイメージをCanonicalが配布開始

                            Ubuntuが.NET 6/ASP.NETをネイティブサポートすると発表。最適化されたコンテナイメージをCanonicalが配布開始 マイクロソフトとCanonicalは、Linuxの代表的なディストリビューションの1つであるUbuntuが.NET 6をネイティブにサポートすると発表しました(マイクロソフトの発表、Canonicalの発表)。 Canonicalはパッケージマネージャやシェルなどを省いて徹底的にスリム化し、.NET 6とASP.NETランタイムに最適化したUbuntu 22.04 LTSのコンテナイメージの配布を開始します。またUbuntu 22.04 LTSのホストOSでは「apt install dotnet6」コマンド一発で.NET 6のインストールが可能になります。 @Microsoft and Canonical announce native .NET avai

                              Ubuntuが.NET 6/ASP.NETをネイティブサポートすると発表。最適化されたコンテナイメージをCanonicalが配布開始
                            • Docker/Kubernetes 実践コンテナ開発入門 改訂新版を出版します

                              こんにちは、ビコーペガサスです。この度、「Docker/Kubernetes 実践コンテナ開発入門 改訂新版」を出版します。本書は2018年に出版した初版を全面改訂したものです。 【新刊】2024年2月24日発売『Docker/Kubernetes実践コンテナ開発入門 改訂新版』本体3,600円+税,山田明憲 著,Docker/Kubernetesを実践で使いこなす!コンテナ開発・運用の第一歩!https://t.co/jRfsDFnuKu pic.twitter.com/dd0qo4DZM1 — 技術評論社販売促進部 (@gihyo_hansoku) February 13, 2024 「改訂新版」のモチベーション 初版の出版から早5年半が過ぎ、コンテナ技術の情報は大きく変化しました。コンテナ技術の基本的な部分は変わらないとはいえ、初版の内容が陳腐化するだけの時間が流れたことは否定しよう

                              • Dockerfileのベストプラクティス - Qiita

                                業務やプライベートでのハンズオンを通して得た知見を元に、dockerfileの実践的な書き方を記載いたしました。 軽量なdocker imageを作る観点とセキュリティーの観点を踏まえた内容になっております。なにか付け足す点などあればコメントいただければと思います。 軽量なimageを作る観点 軽量なimageの使用 Dockerfileでimageを指定する際に、軽量なimageを使用することが進めれている。 docker docsでも代表的な軽量なimageのalpineをおすすめしている。 Whenever possible, use current official images as the basis for your images. We recommend the Alpine image as it is tightly controlled and small in s

                                  Dockerfileのベストプラクティス - Qiita
                                • ちっちゃなScalaコンテナを作つコツ(6 MiBだぞ) - Lambdaカクテル

                                  おなじみの画像 JavaやScalaといったJVM言語のDockerイメージは、JVMを同梱しなければならない都合で肥大化しがちである。特に何もしなくても、例えば一般的なamazoncorretto:21のイメージサイズは217.7 MBもある。 hub.docker.com これにさらにビルド済みのJARファイルが載ってくるので、結構大きくなってしまうのだ。 そこで、Scalaのコンテナイメージのサイズをなんとか小さくできないかと、考えた。すると、JVMを使ったまま70 MiBくらいに縮めることができた。 github.com コンテナイメージのサイズを小さくするために、何をしたかを書いていく。ちなみに題材としたアプリケーションはちょっとしたHello, Worldをするだけのもので、ライブラリはCatsに依存させた。 JVM使う編 マルチステージビルドを行う Alpineなどの軽量ラン

                                    ちっちゃなScalaコンテナを作つコツ(6 MiBだぞ) - Lambdaカクテル
                                  • Pythonの機械学習用Docker imageのサイズ削減方法の紹介 - エムスリーテックブログ

                                    エムスリーエンジニアリンググループ AIチームの笹川です。 バスケと、ロードバイクが趣味なのですが、現在、NBAのplayoffと、Tour de Franceが同時に開催されていて大変嬉しい毎日を過ごしています。 特にNBAのplayoffは、連日overtimeとなるような激戦や、giant killingがあったりのアツい戦いが繰り広げられていて最高です。 そういう状況なので(?)、今回は先日取り組んだ、Pythonの機械学習バッチを実行するdocker imageのサイズ削減についてのアツい戦いについて紹介したいと思います。 膝の上に登って寝る為に、筆者がデスクに戻るのを机の下で待ち構える犬氏(かわいい) 今回の取り組みでは、もともと3GB程度だったPythonのML用のimageを、約2.0GBに削減することができました(それでもなかなかのサイズ。MLのimageは特に大きい印象

                                      Pythonの機械学習用Docker imageのサイズ削減方法の紹介 - エムスリーテックブログ
                                    • PythonのDockerfileをセキュアにするためのベストプラクティス - Qiita

                                      はじめに PythonのDockerfileを作成する際、ネット上で適切な情報が見つからず、試行錯誤することがあります。そこで、ここでまとめてみます。 完成品 # 開発用ステージ FROM python:3.11-bullseye AS developer ENV PYTHONUNBUFFERED=1 WORKDIR /app RUN apt-get update \ && apt-get install -y --no-install-recommends \ bash=5.1-2+deb11u1 \ && apt-get -y clean \ && rm -rf /var/lib/apt/lists/* COPY requirements.txt ./ RUN pip install --no-cache-dir -r requirements.txt COPY . . # ビルド用ス

                                        PythonのDockerfileをセキュアにするためのベストプラクティス - Qiita
                                      • 仕事でPythonコンテナをデプロイする人向けのDockerfile (2): distroless編 | フューチャー技術ブログ

                                        なお、distrolessのイメージは2種類(3通りの名前)がありますが、Python 3.5はバグ修正はせず、セキュリティ修正のみでサポート期限が2020/9/13というステータスなので、本エントリーでは3.7の方のみを扱います。 gcr.io/distroless/python3: Python 3.5.3 gcr.io/distroless/python3-debian9: Python 3.5.3(上のイメージと同一) gcr.io/distroless/python3-debian10: Python 3.7.3 一応サンプル等もありますが、どれも1ファイルで構成されたサンプルスクリプトばかりです。前回のsite-packagesにコピーする方法を軽く試したところうまく動かず、シェルもpipもensurepipもないため、ビルドイメージにすることもできません。いろいろ調べた結果、

                                          仕事でPythonコンテナをデプロイする人向けのDockerfile (2): distroless編 | フューチャー技術ブログ
                                        • JavaのDockerイメージ何選ぶ? | フューチャー技術ブログ

                                          Javaアドベントカレンダーにエントリーした記事になります。 Javaのイメージを作る上で、どのDockerイメージをベースに選べばいいのか、というのを軽く調べ始めたら、選択肢がたくさんでてきたので、ちょっと突っ込んで調べてみました。 以前、仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で書いたOS名とかは今回は紹介しませんので、busterとかalpineとかwindowsservercoreってなによ?というお話はそちらの記事を参照してください。一点アップデートがあるのは、Debian 11がリリースされて、イメージとしてbullseyeというのが追加された点ですね。あとはfocal=Ubuntu 20.04LTSというのを覚えてもらえれば。 JDK周りのニュースOracle JDKが無償配布をやめて、無償利用としてはOpenJDKを、

                                            JavaのDockerイメージ何選ぶ? | フューチャー技術ブログ
                                          • Serverless Framework+mangum+FastAPIで、より快適なPython API開発環境を作る - JX通信社エンジニアブログ

                                            はじめに 最近ハイボールにハマっているSREのたっち(@TatchNicolas)です。 昨日オンライン開催されたJAWS DAYS 2020にて、JX通信社もサーバレスをテーマとして発表をしました。(by 植本さん) 発表でもありましたように、上記プロジェクトにおいて開発当時はスピードを優先してプロジェクトメンバーの手に馴染んでいて分担もしやすいフレームワークとしてFlaskを採用しました。 一方で、JX通信社としてはFlaskよりもFastAPIを使うプロジェクトが増えてきており、今後もその傾向は続く見込みです。 そこで、特設ページ作成やAPI提供など初動としての開発が一段落したのを機に、JAWS DAYSで発表した仕組みを今後のために発展させる検証をしたので紹介します。 TL; DR; JAWSでは Serverless Framework+awsgi+Flaskな構成でスピーディに

                                              Serverless Framework+mangum+FastAPIで、より快適なPython API開発環境を作る - JX通信社エンジニアブログ
                                            • 3Dモデルの配信サーバーでRustとZstandardを採用して数倍のパフォーマンス向上を実現した - pixiv inside

                                              はじめに こんにちは、VRoid部所属のエンジニアのyueです。 この度VRoid Hubで3Dモデルの配信サーバーの見直しを行い、技術選定から始めRustとZstandard (zstd)を採用した実装に切り替えました。 結論から見るに従来のNode.js製サーバーと比べて以下のことを実現しました。 最大のレスポンス時間が 1.5 ~ 2.5s から 300 ~ 400msまで低下 平均のレスポンス時間が 700 ~ 800ms から 150 ~ 200msまで低下 サーバーのCPU使用率が ~ 50% から ~ 10%まで低下 docker image のサイズが ~ 346mb から ~ 21mb程度まで削減 配信されるファイルサイズが平均 10 ~ 20% 軽量化されました レスポンス時間 CPU使用量 (上からAVG(MAX), AVG, AVG(MIN)) メモリー使用量に関し

                                                3Dモデルの配信サーバーでRustとZstandardを採用して数倍のパフォーマンス向上を実現した - pixiv inside
                                              • Laravel を Docker で動かしてホスティングするまで

                                                ひょんとしたことから PHP をやることになったのですが、Laravel を コンテナでホスティングするのが難しすぎて困っています。とりあえず今できていることをメモです。こうした方が良いよ的なアドバイスがあったら教えて欲しいです。 ちなみに本当は昨日公開予定のブログでしたが、Xが急遽OGPに対する仕様を変えたのでそれを踏まえた新しいOGイメージでお送りします。 注意 ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ この文章は PHP + Laravel歴 1週間ちょっとのペーペーによって書かれたものです。apache も fastcgi も初見です。書かれている内容を間に受けないでください。 ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑ tl;dr Docker で動かす最小構成がわからないのですが、とりあえずこう書けば動きはします。 FROM php:8.2-f

                                                  Laravel を Docker で動かしてホスティングするまで
                                                • Node.jsアプリケーションのDockerイメージのサイズを削減する方法について調べた - The Third Law

                                                  Next.jsアプリケーションのDockerイメージのサイズが大きくて困っていたので調べていたところ、Next.jsの公式ドキュメントにDocker Imageというセクションがあり、おすすめ設定が記載されているのを見つけました。以前はここまで詳細な記述はなかったのですが、つい10日ほど前に追加されたようです。 ドキュメントには一番おすすめの方法だけ書かれているのですが、もともと「What is the best way to use NextJS with docker? · Discussion #16995 · vercel/next.js · GitHub」というdiscussionがあり、ドキュメントの記述はここでの議論が元になっているようです。Discussionではいくつか例が示されているのですが、それぞれさまざまな最適化テクニックが利用されており、どれくらいの容量になるか気

                                                    Node.jsアプリケーションのDockerイメージのサイズを削減する方法について調べた - The Third Law
                                                  • goのLambdaはコンテナイメージでよくない? - エムスリーテックブログ

                                                    【Unit4 ブログリレー8日目】 こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 今日の記事は、タイトルのとおりgoのLambdaはコンテナイメージで管理するのがオススメって話です。 城島高原パーク(きじまこうげんパーク)は、大分県別府市の城島高原にある遊園地。本文には関係ありません。 go1.xランタイムのサポート終了 コンテナイメージにする利点 起動時間は遅くならないの? 構成 処理本体 main.go Dockerfile 本番実行用イメージ ローカル実行用イメージ ローカルで実行 Lambdaの設定 まとめ We are hiring! go1.xランタイムのサポート終了 先日、AWS Lambdaの go1.x ランタイムのサポート2023/12/31で終了することが話題になっていました。 「なっていました」と伝聞なのは、Unit4ではすで

                                                      goのLambdaはコンテナイメージでよくない? - エムスリーテックブログ
                                                    • Node.js Docker baseイメージには alpine < distroless < ubuntu+slim 構成がよさそう

                                                      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

                                                        Node.js Docker baseイメージには alpine < distroless < ubuntu+slim 構成がよさそう
                                                      • distroless imageを実用する | うなすけとあれこれ

                                                        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

                                                          distroless imageを実用する | うなすけとあれこれ
                                                        • Top 20 Dockerfile best practices

                                                          Learn how to prevent security issues and optimize containerized applications by applying a quick set of Dockerfile best practices in your image builds. If you are familiar with containerized applications and microservices, you might have realized that your services might be micro; but detecting vulnerabilities, investigating security issues, and reporting and fixing them after the deployment is ma

                                                            Top 20 Dockerfile best practices
                                                          • Kubernetes 1.18の新機能を学び、使ってみよう

                                                            はじめに Kubernetes 1.18(以降、1.18)が2020年3月24日にリリースされました。ここではリリースノートで紹介された5つの注目機能に加えて、筆者が注目するHorizontalPodAutoscalerのspec.behaviorフィールドの追加、ノードローカルDNSキャッシュ、Pod StartupProbeを紹介し、最後にStartupProbeを試していきます。 Kubernetes 1.18注目の新機能 最初に1.18リリースノートにおける5つの注目機能について、それぞれ解説します。 Topology Manager(ベータ) Topology Managerは、NUMA(Non-Uniform Memory Access、ヌマ)の環境において、コンテナの使用するCPUとデバイスの同一ソケット(NUMAノード)への割り当てを可能にします。Topology Mana

                                                              Kubernetes 1.18の新機能を学び、使ってみよう
                                                            • EKSコンテナ移行のトラブル事例:推測するな計測せよ -CoreDNS暴走編- - MonotaRO Tech Blog

                                                              こんにちは、モノタロウの SRE グループ・コンテナ化推進チームの田中です。 現在、私たちはシステムモダナイゼーションのプロジェクトの一環として、200以上のエンドポイントを持つモノリスのバックエンド API を EC2 上から Kubernetes マネージドサービスの EKS(Elastic Kubernetes Service)に移行しています。ノードは Fargate を使用し、監視には Datadog と Sentry を導入しています。 今回、EC2 に流れているリクエストを全て EKS に振り分けを行おうとしておりました。その際に外部(DB、 サービス)への疎通ができないといった内容の Sentry のエラーが大量に発生し、切り戻しをせざるを得ない状況に陥ったのです。エラー内容を詳しくみたところ名前解決に関するものであり、今回私たちは CoreDNS の設定を行うことで解決し

                                                                EKSコンテナ移行のトラブル事例:推測するな計測せよ -CoreDNS暴走編- - MonotaRO Tech Blog
                                                              • マルチアーキテクチャ対応イメージのビルドをどうにか早くしたかった - ぽよメモ

                                                                マルチアーキテクチャ対応イメージって何? どうやって作るか docker manifestコマンドを使う docker buildxコマンドでビルドする buildxとQEMUによるビルドは遅い CIでのビルドを速くしたい アーキテクチャごとに別ジョブでビルドする クロスビルドを活用する buildxに対する雑感 結論 参考 マルチアーキテクチャ対応イメージって何? 最近ではApple Siliconの登場や、Oracle CloudのAmpere A1 Computeインスタンスなど、ARMアーキテクチャ採用のプロセッサに実際の開発などで触れる機会も増えてきました。 現在広く流通するx86_64に対応するIntelやAMD製のプロセッサと比べて、ARM系のCPUには高い省電力性能などに期待が集まっています。趣味開発レベルの話をすると、Oracle CloudのAlways FreeなA1

                                                                  マルチアーキテクチャ対応イメージのビルドをどうにか早くしたかった - ぽよメモ
                                                                • distrolessのnonrootイメージを使おう - Re:cohalz

                                                                  この記事は はてなエンジニア 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

                                                                    distrolessのnonrootイメージを使おう - Re:cohalz
                                                                  • Google Cloud Run と AWS Lambda のコールドスタート時間を言語別に観察してみる - Qiita

                                                                    コンテナをリクエスト処理時間ベースの料金体系で実行できるサーバレス環境としては、Google の Cloud Run(2019年11月GA)と AWS Lambda(2020年12月にコンテナに対応)が特に有名でしょう。 これらの環境は、一度起動したコンテナインスタンスをしばらく生かしておき、その後のリクエストに使いまわします。しかし、生きているインスタンスが足りない場合は新たなコンテナの起動から始めるいわゆる「コールドスタート」となり、応答のオーバーヘッドが大きく増加します。用途によっては、このコールドスタートにかかる時間が問題になります。 Cloud Run と Lambda でのコールドスタートの様子を観察するため、いくつかの言語で "Hello, World!" を返すだけのWebアプリコンテナを作り、コールドスタートの時間を「雑に」観察してみました。 注意: コストや性能は考慮し

                                                                      Google Cloud Run と AWS Lambda のコールドスタート時間を言語別に観察してみる - Qiita
                                                                    • 仕事ですぐに使えるTypeScript - PDF版

                                                                      TypeScript Future Corporation 2022 11 14 i TypeScript 1 3 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5 . . . . . . . . .

                                                                      • ko を使用して Go アプリケーションを Cloud Run に迅速にデプロイ | Google Cloud 公式ブログ

                                                                        ※この投稿は米国時間 2021 年 2 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。 開発者がコンテナを使用して作業することが多くなるに従い、ソースコードからアプリケーションがデプロイされるまでの時間を短縮することの重要性が増しています。コンテナ イメージのビルドをより迅速かつ容易にするため、Google は Cloud Build、ko、Jib、Nixery などのテクノロジーを開発し、クラウドネイティブの Buildpacks のサポートを追加しました。これらのツールのいくつかは、Docker エンジンや Dockerfile を使用せず、ソースコードから直接コンテナ イメージをビルドすることに特にフォーカスしています。 特に Go プログラミング言語を使用すると、ソースコードからコンテナ イメージをビルドすることがはるかに簡単になります。この記事で

                                                                          ko を使用して Go アプリケーションを Cloud Run に迅速にデプロイ | Google Cloud 公式ブログ
                                                                        • Spring Boot アプリケーションを AWS Fargate に最適化する | Amazon Web Services

                                                                          Amazon Web Services ブログ Spring Boot アプリケーションを AWS Fargate に最適化する この記事は Optimize your Spring Boot application for AWS Fargate (記事公開日: 2022 年 7 月 25 日) を翻訳したものです。 中断や需要のピークに迅速に対応するには、起動時間を短縮することが重要です。それによってリソース効率を高めることができます。AWS Fargate では、基盤となるコンテナホストの面倒を見る必要はありません。しかしながら、コンテナとアプリケーションの起動時間を短縮するために、いくつかの変更が必要になることがよくあります。 この記事では、Fargate 上で実行される Java アプリケーションに適用する最適化手法について説明します。この記事では特に Java Spring B

                                                                            Spring Boot アプリケーションを AWS Fargate に最適化する | Amazon Web Services
                                                                          • Designing a secure container image registry | Amazon Web Services

                                                                            Containers Designing a secure container image registry As organizations move to containers, there can be a sense that they are losing control or visibility of the software that is deployed to their environments. Historically, once a server is in production, a scanning tool runs on a regular basis to detect vulnerabilities on the operating system. Once a vulnerability is detected, an operations eng

                                                                              Designing a secure container image registry | Amazon Web Services
                                                                            • KubeCon + CloudNativeCon Europe 2024 参加レポート - ZOZO TECH BLOG

                                                                              はじめに こんにちは。SRE部フロントSREブロックの三品です。 3月19日から3月22日にかけてKubeCon + CloudNativeCon Europe 2024(以下、KubeCon EUと呼びます)が行われました。今回弊社からはZOZOTOWNのマイクロサービスや基盤に関わるエンジニア、推薦システムに関わるエンジニアの合わせて4人で参加しました。 本記事では現地の様子や弊社エンジニアが気になったセッションや現地の様子について紹介していきます。 目次 KubeConEU2024の概要 セッションの紹介 現地の様子 ブースについて 参加に向けてのTips 最後に KubeCon EU 2024の概要 昨年4月にオランダ アムステルダムで行われたKubeCon EUの様子については昨年の参加レポートをご覧ください。 techblog.zozo.com 今年のKubeCon EUはフラ

                                                                                KubeCon + CloudNativeCon Europe 2024 参加レポート - ZOZO TECH BLOG
                                                                              • Buildpacksのビルダーをスクラッチから作ってみる | フューチャー技術ブログ

                                                                                TIGの渋川です。 CNCF連載の第4回は、CNCFのSandboxプロジェクトのBuildpacksについて紹介します。 https://buildpacks.io BuildpacksとはHerokuがオリジナルで作ったビルドツールです。HerokuのオリジナルはHerokuのプラットフォーム用のビルドツールだったと思いますが(使ったことはない)、CNCF版はコンテナイメージを作成します。オリジナル版とはいろいろ違いがあり、区別をつけるためにCloud Native Buildpacks(略してCNB)と呼称されているようです。 ツールの方針としては、ビルド設定ファイルのようなものを作らなくても(実行情報のみを書いたファイル、project.tomlは書ける)ソースコードを与えるだけで、Dockerfileなどを使わずにDockerimageが作れます。 使い方は簡単で、作業フォルダで

                                                                                  Buildpacksのビルダーをスクラッチから作ってみる | フューチャー技術ブログ
                                                                                • Debug Shell · OrbStack Docs

                                                                                  OrbStack Debug Shell provides useful commands & tools, making it easy to debug any container (even minimal/distroless/read-only containers that have no shell or commands). Compared to docker exec, Debug Shell has: Shell auto-complete and syntax highlightingEditors (nano, vim)Common tools (htop, curl, strace, ip, etc.)Colorful output in ls and other commandsPackage manager with over 80,000 packages