並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 188件

新着順 人気順

dockerfileの検索結果1 - 40 件 / 188件

  • 今さら聞けないDocker入門 〜 Dockerfileのベストプラクティス編

    今時のアプリ開発において、コンテナは避けて通れないものになっています。そして数多くあるコンテナ実行環境の中でも、デファクトスタンダードと言えるのがDockerです。そんなDockerのイメージですが、皆さんは正しくビルドできていますか? そのコンテナは無駄に太っていませんか? 効率よく最短時間でビルドできていますか? セキュリティは大丈夫ですか? 今回はDockerfileの書き方をテーマに、「今さら聞けない」Docker入門をお届けします。

      今さら聞けないDocker入門 〜 Dockerfileのベストプラクティス編
    • ちっちゃな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カクテル
      • Dockerによる開発環境構築のための概念理解と方法解説 - Qiita

        この記事はNuco Advent Calendar 2023の9日目の記事です。 はじめに この記事ではDockerで開発環境を行うために理解してほしい概念と実際の開発環境の構築手順について解説を行います。大きく分けて、 ・Dockerの概念理解 ・開発環境の構築 これらの章により構成されています。この記事を読むことで、Dockerファイル、イメージ、コンテナ、Docker compose、compose.ymlを理解できるようになることを目指しています。Dockerに触れてみたい、Dockerの理解があやふやという方は参考にしてみてください! 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています!興味をお持ちいただける方は、こちらまで。 Dockerとは まず、Do

          Dockerによる開発環境構築のための概念理解と方法解説 - Qiita
        • 今更聞けないDockerのしくみ(「Dockerとは?」から「docker-composeファイルを1人で作れるようになる」まで) - Qiita

          今更聞けないDockerのしくみ(「Dockerとは?」から「docker-composeファイルを1人で作れるようになる」まで)RubyRailsDockerdockerfiledocker-compose はじめに なんとな〜くdockerを使い始めてはや4年ほど。 既存のプロジェクトにアサインされた場合はdockerファイルに何が記載されているかなんて意識せずコマンドを実行するだけで、何か自分で一から作る時は、誰かが作ったものをどこからか持ってきて済ませていた。 こんな感じなのでdockerをなんとなく扱えてはいるが細かいところを全く理解できてない。 今回は人に説明できるくらい理解できるようになろうとした男の記事です。 ハンズオン形式でやっていきますので一緒に手を動かしながらやってみていただけると嬉しいです。 対象とする読者 これからdockerをは0から理解したい人 なんとなくdo

            今更聞けないDockerのしくみ(「Dockerとは?」から「docker-composeファイルを1人で作れるようになる」まで) - Qiita
          • Docker Compose Watchのすすめ - Hatena Developer Blog

            やあ!id:cockscombです。日々の生活に役立つちょっとした知識を紹介していきます。最近は、Apple WatchやPixel Watchみたいな、ナントカWatchのリリースが多いですね。でも今日紹介するのは、WatchはWatchでも、Docker Compose Watchです。 Docker Composeは、複数のコンテナを扱った開発に用いる道具で、コンテナを活用した開発では当たり前に使われている。そのDocker Composeに、ファイルの変更を監視してコンテナの再構成を行わせるのが、Docker Compose Watchだ。Docker Compose 2.22以降で利用できる。最新のDocker Desktopにも付属している。 ホットリロードとコンテナ開発 Docker Compose Watchがどういうものかを説明する前に、Next.jsのホットリロードにつ

              Docker Compose Watchのすすめ - Hatena Developer Blog
            • 踏み台にはECSコンテナを。~ログイン有無を検知して自動停止させる~ - NRIネットコムBlog

              こんにちは、後藤です。今回はAWS構成における踏み台についての記事です。 データベースなどのインターネットに繋げたくないリソースに踏み台リソース経由でアクセスさせることは、セキュリティ設計としてよくある構成だと思います。 今回はその踏み台リソースに「ユーザーログイン有無を検知して自動停止する」ロジックを組み込んだ方法を共有します。 また、一般的によく用いられるのはEC2だと思いますが、今回はECS on Fargate(以降はFargateと略)を使います。しかも自動停止ロジックにLambdaを使いません!!コンテナの中で完結させます。 踏み台を設計する時に気になること そもそも踏み台について設計する際に何が気になるのでしょうか。それはOS管理負担と自動停止です。 踏み台にEC2を用いるとOSパッチ適用などの運用コストが発生します。業務系サーバでないのに心労が重なるのはなるべく避けたいとこ

                踏み台にはECSコンテナを。~ログイン有無を検知して自動停止させる~ - NRIネットコムBlog
              • 1時間でさわって学ぶDocker

                Dockerを触りながら学んでいく、初心者向けの記事です。 用語の解説等はほとんどせずに、とにかく触ってみることを目的としています。 Phase 1: Dockerの基本 コマンドを試しながら基本操作を学びます。 Phase 2: Dockerfileをもう少し書いてみる Dockerfileを使って、簡単なWebアプリケーションを作成します。 Phase 3: Docker Composeを使ってみる Docker Composeを使って、複数のコンテナを一括管理します。 Phase 1: Dockerの基本 Dockerの基本的な操作を試してみます。 プロジェクトフォルダの作成 次のコマンドを実行して、プロジェクトフォルダを作成します。

                  1時間でさわって学ぶDocker
                • Dockerの"分からない"を簡単にメモ - Qiita

                  概要 前提 規約 コンテナはエフェメラル(短命:ephemeral)であること .dockerignoreを有効活用する 不要なパッケージのインストールを避ける コンテナ毎に1つのプロセスだけ実行 レイヤーの数を最小に 複数行の引数はアルファベット順、改行すること Docker network 概要 bridge none host overlay ipvlan macvlan Docker Volume 概要 bind mount volume tmpfs mount Dockerfileを扱う まずはDockerfileを作成する! FROM:ベースイメージを作成 RUN: 任意のコマンドを実行する WORKDIR: ワークディレクトリを追加する レイヤーの確認 コンテナの生成と停止 imageを作成 runでコンテナを起動 stopでコンテナを停止 pruneでDockerのお掃除

                    Dockerの"分からない"を簡単にメモ - Qiita
                  • 複数の環境でDockerfileを共通化するために使えるtips

                    前提 コンテナを用いてアプリケーションのワークロードを構築することにはいくつかの利点があります。 なかでも、下記に上げられるポータビリティと環境の再現性は非常に強力です。 ポータビリティ コンテナは、アプリケーションとその依存関係をコンテナ内にパッケージ化します。 これにより、開発環境で構築したコンテナを本番環境にデプロイする際にも、一貫した動作が期待できます。 異なる環境間でアプリケーションを移行する際に、互換性の問題や依存関係の不一致が生じるリスクが低減され、ポータビリティが高まります。 環境の再現性 コンテナは環境に依存しないため、開発者が特定の環境でアプリケーションを構築した場合でも、他の開発者や運用チームが同じ環境を再現することが容易です。 コンテナイメージにはアプリケーションのコードとその実行環境が含まれており、イメージを共有することで他の人が同じ環境でアプリケーションを実行で

                      複数の環境でDockerfileを共通化するために使えるtips
                    • 今からDockerを始める人へ!Docker Initがアツい!

                      package main import ( "net/http" "github.com/labstack/echo/v4" ) func main() { e := echo.New() e.GET("/", func(c echo.Context) error { return c.String(http.StatusOK, "Hello, World!") }) e.Logger.Fatal(e.Start(":1323")) } # syntax=docker/dockerfile:1 # Comments are provided throughout this file to help you get started. # If you need more help, visit the Dockerfile reference guide at # https://docs.

                        今からDockerを始める人へ!Docker Initがアツい!
                      • オープンなLLMをDockerで動かす

                        次々と発表されるオープンな日本語大規模モデル どうなっているの??という感じですよね。 我らがnpakaさんは、さっそくGoogle Colabで動かしていらっしゃいます。 ただ、Google Colabだと毎回モデルのダウンロードが大変なので、ローカルでDocker使って手軽に動かせるといいな、ということでやってみました。 以下GitHubのリポジトリにDockerfileとサンプルプログラムをおいています。チャットっぽいことをできるようにしています。 上記で、サイバーエージェントとリンナのLLMが両方動きます。 使用環境 前提となる環境です。使用しているPCのスペックは以下です。 項目 内容

                          オープンなLLMをDockerで動かす
                        • Docker Init: Initialize Dockerfiles and Compose files with a single CLI command | Docker

                          Docker Init: Initialize Dockerfiles and Compose files with a single CLI command Docker has revolutionized the way developers build, package, and deploy their applications. Docker containers provide a lightweight, portable, and consistent runtime environment that can run on any infrastructure. And now, the Docker team has developed docker init, a new command-line interface (CLI) command introduced

                            Docker Init: Initialize Dockerfiles and Compose files with a single CLI command | Docker
                          • GitHub - ktny/AI_hatena_bookmarker: OpenAIで作るAIはてなブックマーカー

                            You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                              GitHub - ktny/AI_hatena_bookmarker: OpenAIで作るAIはてなブックマーカー
                            • Dockerfile自信持って書けてますか?おすすめlintツール 「hadolint」について紹介 - Qiita

                              はじめに Dockerfile、サッと書こうと思ったのに、書き始めたら意外と時間かかったりしますよね。 突き詰めるとすごく奥が深いなと思います。 公式のドキュメントでも、Dockerfileのベスト・プラクティスという形で公開してくれていますが、 これを毎回意識するのは大変です。 また、意識できていたとしても、複数人で管理していると、各個人のスキルレベルによって差が出てしまいます。 そんなときにおすすめのツールを見つけたので紹介します。 hadolintというツールです。 Haskell Dockerfile Linterの略だそうで、Dockerfileの静的解析を行ってくれるlintツールです。 hadolintを使うとこんな利点があります。 build前にシンタックスエラーなどに気付ける (地味にトライアンドエラーしてると時間食うんですよね...) 自然とベストプラクティスに則ったD

                                Dockerfile自信持って書けてますか?おすすめlintツール 「hadolint」について紹介 - Qiita
                              • 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、の解説
                                • buildkit/frontend/dockerfile/docs/syntax.md at dockerfile/1.4.3 · moby/buildkit

                                  You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                    buildkit/frontend/dockerfile/docs/syntax.md at dockerfile/1.4.3 · moby/buildkit
                                  • Node.jsコンテナイメージを極限まで軽量化! サイズを1/10以下に|SHIFT Group 技術ブログ

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

                                      Node.jsコンテナイメージを極限まで軽量化! サイズを1/10以下に|SHIFT Group 技術ブログ
                                    • コンテナビルド最新事情 2022版 ~TechFeed Conference 2022講演より | gihyo.jp

                                      本記事は、2022年5月に開催されたTechFeed Conference 2022のセッション書き起こし記事「コンテナビルド最新事情 2022版(inductor⁠)⁠ — TechFeed Conference 2022講演より」を転載したものです。オリジナルはTechFeedをご覧ください。 それではこれから、私@_inductor_が「コンテナビルド最新事情」ということでお話をしていきます。 今日は主に4つの話をしていきます。ちょっと駆け足になってしまいますが、コンテナビルド高速化に向けた4つの機能およびポイントについてお話しします。 今回お話すること Dockerfileの新しい記法 まず最初に、Dockerfileに新しい記法がいくつか増えています。それを実装しているのは BuildKitと呼ばれるDocker発のオープンソースのソフトウェアがベースになっていて、Dockerf

                                        コンテナビルド最新事情 2022版 ~TechFeed Conference 2022講演より | gihyo.jp
                                      • InnerLoop、OuterLoopの考えをどう取り入れるか? コンテナを活用した開発におけるCloud Native Buildpacksのすすめ

                                        クラウドの運用者に焦点を当てた、技術者向けの新しいテックイベント「Cloud Operator Days Tokyo 」。ここでヴイエムウェア株式会社の星野氏が「開発者と運用者の壁をぶち壊せ!InnerLoopとOuterLoopとは?」をテーマに登壇。続いて、コンテナ作成におけるInnerLoop、OuterLoopの考えかたの適用方法について話します。前回はこちらから。 コンテナ作成におけるInnerLoop、OuterLoopの考えかたの適用 星野真知氏:(スライドを示して)さて、これを紹介するまでが私のセッションですが、とはいえちょっとはテクニカルなことを話したほうがいいと思うので、この中でビルドクラスタを紹介したいと思います。 これは何かというと、InnerLoopとOuterLoopをつなぐ、ある意味門番の役割をするものだと思っています。このビルドの考えかたを持っている方は、け

                                          InnerLoop、OuterLoopの考えをどう取り入れるか? コンテナを活用した開発におけるCloud Native Buildpacksのすすめ
                                        • Dockerfile ベストプラクティス/2022夏 - Qiita

                                          今までなんとなくで済ませてきたDockerfileの設定ですが、あらためて公式のベストプラクティス1や公式のリファレンス2を読み解いていきたいと思います。 Dockerfileの各命令の意味や、キャッシュを有効活用するための注意点などについて触れていきます。 ※ベストプラクティスにある「stdinからdocker buildする方法」に関する項目は省略しました。 Dockerfileとは? Dockerイメージを作る際の指示が書かれたファイルです。 Dockerfileを元にイメージが作られ、このイメージを元にコンテナが作られます。 だからすでにイメージがある場合はDockerfileは不要なんですね。 Dockerfileを作る時の注意点 では、早速Dockerfileを作りましょう。 各命令の意味を調べていく前に、Dockerfileを作成するにあたって気を付けた方が良い点について整理

                                            Dockerfile ベストプラクティス/2022夏 - Qiita
                                          • Dockerfile の RUN instruction で heredoc 記法をそのまま使うとコマンドが non-zero exit status で死んでも docker build が成功してしまう - polamjaggy

                                            tl; dr Dockerfile の heredoc 機能の中で凝ったことをやるときはコマンド群の最初に set -e とか書くのが無難そう 近年 Dockerfile 内で heredoc 記法が使えるようになったことが知られていて、 www.docker.com 割と凝ったことができる機能で、シンプルには以下のように RUN にずらずら書くときシュッと書けて便利、というのがわかりやすいと思う。 思うんだけど、こういうふうに heredoc の中でなんかミスってしまったときに何が起こるかというと、 # syntax=docker/dockerfile:1.3-labs FROM debian RUN <<EOF apt-get install packagewhichdoesnotexists ls EOF こういう感じで docker build は成功扱いになってしまう。 % do

                                              Dockerfile の RUN instruction で heredoc 記法をそのまま使うとコマンドが non-zero exit status で死んでも docker build が成功してしまう - polamjaggy
                                            • gRPC サーバのビルドに Earthly を使ってみよう

                                              今 Earthly というビルドツールが (自分の中で) 俄かに話題になっています.自分で手を動かしてサンプルコードを作ってみたので,それを基に簡単に機能を紹介したいと思います.題材は Go + gRPC です. Earthly って何? Earthly は Makefile と Dockerfile を足したような書き味のビルドツールで, Makefile のように複数のタスクを定義し,タスクの中で Dockerfile を書くような感じでテストのような命令を実行したり,イメージを生成して保存したりできます. すでに他の方が Earthly を紹介している記事もあるのでぜひご覧ください. Earthly の大きな特徴は "Makefile + Dockerfile 風な構文の馴染みやすさ", "タスクをコンテナ上で実行することによる可搬性の高さ", "ビルドキャッシュの仕組みの簡単さ (

                                                gRPC サーバのビルドに Earthly を使ってみよう
                                              • あなたのDockerfileはベストプラクティスに従っていますか?(ベストプラクティスとチェックツール) - Qiita

                                                Dockerfileのベストプラクティス ベースイメージには公式のレポジトリを使用する FROM命令において、使用するベースイメージは公式のリポジトリのものを使用し、軽量なものが推奨されている。 例えば、Debian イメージなど。 FROM [--platform=<プラットフォーム>] <イメージ名> [AS <名前>] FROM [--platform=<プラットフォーム>] <イメージ名>[:<タグ>] [AS <名前>] FROM [--platform=<プラットフォーム>] <イメージ名>[@<ダイジェスト>] [AS <名前>]

                                                  あなたのDockerfileはベストプラクティスに従っていますか?(ベストプラクティスとチェックツール) - Qiita
                                                • Visual Studio Code と Docker コンテナを使って開発する - Pepabo Tech Portal

                                                  技術部データ基盤チームの @zaimy です。今回は、 Visual Studio Code(以下 VS Code)と Docker コンテナを使って開発環境を構築する方法を紹介します。 データ基盤エンジニアの開発環境として、Python を使用する単一コンテナを例に記述しますが、他の言語や Docker Compose を使う場合でも応用できます。 背景: M1 Mac (Monterey) に Python 3.8.12 をインストールできない 先日、業務で使用するマシンを Intel Mac から M1 Mac に切り替えたのですが、CPU アーキテクチャが異なることに加えて、OS のバージョンが上がったことで Apple Clang に下位互換性のない変更が入っており、業務上ある理由で必要な Python 3.8.12 のインストールが困難でした。 そこで、私の所属するチームは全員

                                                    Visual Studio Code と Docker コンテナを使って開発する - Pepabo Tech Portal
                                                  • GitHub - ktock/buildg: Interactive debugger for Dockerfile, with support for IDEs (VS Code, Emacs, Neovim, etc.)

                                                    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                                      GitHub - ktock/buildg: Interactive debugger for Dockerfile, with support for IDEs (VS Code, Emacs, Neovim, etc.)
                                                    • VSCode のリモートコンテナ機能を用いて、あるリポジトリ専用の環境を開発者間で統一する

                                                      概要 VSCode のリモートコンテナ機能を用いると、開発環境を dockerfile の形でコード管理することができます。これにより、開発者が開発に用いる環境をリポジトリごとに統一できます。 VSCodeのリモートコンテナ機能とは コンテナの中に開発環境を押し込んで、その中にディレクトリをマウントして開発するVSCodeの機能です。 リモートコンテナ機能を用いて開発するメリット リモートコンテナ機能を用いて開発することには以下のようなメリットがあります。 local環境を汚さない 複数のプロジェクトで開発するにつれて、local マシンにはそのための様々なアプリ・設定が導入されていきます。この状態には以下のような欠点があります。 導入されたアプリや設定が膨大になって管理しきれなくなり、何のために導入されたか、変更してよい設定なのかが分からなくなる 異なるプロジェクトで必要な設定・アプリ同

                                                        VSCode のリモートコンテナ機能を用いて、あるリポジトリ専用の環境を開発者間で統一する
                                                      • 作業環境をDockerfileにまとめて、macOSでもLinuxでもWSL2でも快適に過ごせるようになった話

                                                        こんにちは、CLI生活至上主義?の、 ひのしば です。 まぁ、至上主義というのは、ちょっと言い過ぎかもしれませんが、screen, vim, mutt, newsboat, pass, あとは、gitやssh 辺りを使う生活をしており、1日の作業がこれだけで完結するような事もあるような生活を送っています。 さて、そんな私が、ワークステーションサーバに、macOSや、Windows, Linuxから接続して操作するといった構成から、 作業環境をDockerfileにまとめ、手元で上がる環境をdockerコンテナへ統一し作業する構成とした話を紹介します。 この環境は、ここ数ヶ月、不自由なく使えている事もあり、自身の整理のためにも、どのような点が気になって対応したのかを挙げていきます。 詳細は下部に記載する通りですが、 例えば、dockerfile上のuidの問題に気をつける点、Linuxとma

                                                          作業環境をDockerfileにまとめて、macOSでもLinuxでもWSL2でも快適に過ごせるようになった話
                                                        • Docker Compose な開発環境にちょい足し3分で作るVSCode devcontainer

                                                          こんにちは、devcontainer職人です🧑‍🍳 今回紹介するのはDocker Composeを既に利用している開発環境にかんたんにdevcontainerを構築する方法を紹介します。 VSCodeのdevcontainerはとても良くできた開発環境構築方法なのですが、ちょっと難しそうと思われていたり、VSCode以外のエディタを使う人の開発体験が悪くなるのでは、などの懸念がありまだあまり使われていないような印象があります。今回はそんなdevcontainerを3分で作れるtipsを紹介します。 準備するもの Docker Composeで構築した開発環境 VS Code Docker Desktop for Windows/Mac Remote - Containers extension Docker Composeで構築した開発環境のサンプル 今回用意するのはサンプルとしてRu

                                                            Docker Compose な開発環境にちょい足し3分で作るVSCode devcontainer
                                                          • Dockerfiles now Support Multiple Build Contexts | Docker

                                                            The new releases of Dockerfile 1.4 and Buildx v0.8+ come with the ability to define multiple build contexts. This means you can use files from different local directories as part of your build. Let’s look at why it’s useful and how you can leverage it in your build pipelines. When you invoke the docker build command, it takes one positional argument which is a path or URL to the build context. Mos

                                                              Dockerfiles now Support Multiple Build Contexts | Docker
                                                            • hadolintを利用して容易にベストプラクティスに基づいたDocker環境を構築する | DevelopersIO

                                                              t_o_dと申します。 GAS開発の際に環境用としてチームメンバーにDockerfileを作成していただけましたが、そちらを利用して構築すると肥大な環境が出来上がりました。 そのため、hadolintというlintツールを利用して軽量化及びベストプラクティスに基づいた方法を記録いたします。 結論 以下、「修正前」と「修正後」のソース及びイメージサイズの比較です。 ※こちらを参考にしてより削減するため、本来の指摘とは関係ない「軽量なイメージの使用」を行なっています。 $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE before_image latest ****** 3 minutes ago 1.27GB after_image latest ****** 1 minutes ago 486MB hadolintを利用すれば軽量でベ

                                                                hadolintを利用して容易にベストプラクティスに基づいたDocker環境を構築する | DevelopersIO
                                                              • RubyのDockerイメージでよく使う環境変数

                                                                Ruby向けのDockerイメージで使いがちな環境変数について整理する。 GEM_HOME RubyGemsに対して、どのディレクトリにGemをインストールするかを指定する環境変数。例えば gem install foo を実行すると、この環境変数で指定したディレクトリにfoo gemがインストールされる。 Dockerでありがちな作戦として、/gem のような適当なパスにデータボリュームをマウントしておいて、そこにGemを永続化させておくというのがある。このときGEM_HOMEを /gem に指定しておくと、gem install bundler を実行したときそこにBundlerがインストールされ、更に /gem/bin/bundle も用意される。 BUNDLE_PATH Bundlerに対して、どのディレクトリにGemをインストールするかを指定する環境変数。例えば bundle i

                                                                  RubyのDockerイメージでよく使う環境変数
                                                                • Dockerfile のベスト・プラクティス — Docker-docs-ja 19.03 ドキュメント

                                                                  このドキュメントは、効率的なイメージ構築のために推奨するベストプラクティスを扱います。 Docker は Dockerfile に書かれた命令を読み込み、自動的にイメージを構築します。 Dockerfile はイメージを構築するために必要な全ての命令を、順番通りに記述したテキストファイルです。 Dockerfile は特定の書式と命令群に忠実であり、それらは Dockerfile リファレンス で確認できます。 Dockerfile の命令に相当する読み込み専用のレイヤによって、 Docker イメージは構成されます。それぞれのレイヤは直前のレイヤから変更した差分であり、これらのレイヤは積み重なっています。次の Dockerfile を見ましょう。 命令ごとに1つのレイヤを作成します。 FROM は ubuntu:18.04 の Docker イメージからレイヤを作成 COPY は現在のデ

                                                                  • 「chmod」を不用意に使うとDockerイメージの容量が肥大化してしまう

                                                                    Dockerの性能を最大限に引き出すためには、Dockerfileの記述を最適化し、ビルド後のイメージの容量をできるだけ小さくすることが大切です。さまざまなテクニックがDockerfileのベストプラクティス集などにまとめられるなど、多くのエンジニアの関心を集めているこの最適化問題について、エンジニアのヴァムシ・アトゥーリさんが「適切にchmodを利用することでコンテナイメージの容量を35%削減した」というブログ記事を投稿し、エンジニアが集うニュースサイト「Hacker News」で話題になっています。 `COPY --chmod` reduced the size of my container image by 35% https://blog.vamc19.dev/posts/dockerfile-copy-chmod/ `COPY –chmod` reduced the size

                                                                      「chmod」を不用意に使うとDockerイメージの容量が肥大化してしまう
                                                                    • executableの場所を探すときwhichではなくcommandを使う習慣 - yujioramaの日記

                                                                      whichを使わない一番の理由はcoreutilsに入ってないから(commandはたいていのshellでbuiltin functionになっている)。 ash(1): command interpreter - Linux man page dash(1) - Linux manual page Bash Builtins (Bash Reference Manual) たぶんDockerfileでいろいろやっているときに身についた振る舞いだと思う。 ポータビリティを高めるとかの高い意識ではなく、何度もcommand not foundに遭遇して面倒になったことが主な動機で、そこから派生してwhichコマンドの存在を無視する(頼らない)ようになった感じ。 あと、軽量なDockerイメージを作るのがかっこいいと見做された時期があって(時期というより原則だけど)、インストールするパッケージ

                                                                        executableの場所を探すときwhichではなくcommandを使う習慣 - yujioramaの日記
                                                                      • GitHub - roottusk/vapi: vAPI is Vulnerable Adversely Programmed Interface which is Self-Hostable API that mimics OWASP API Top 10 scenarios through Exercises.

                                                                        You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                                                          GitHub - roottusk/vapi: vAPI is Vulnerable Adversely Programmed Interface which is Self-Hostable API that mimics OWASP API Top 10 scenarios through Exercises.
                                                                        • Dockerで安全にnode.jsウェブアプリをコンテナ化する - Qiita

                                                                          Happy New Year! 年末、年始があっという間に終わり、明日は成人の日。 来週からコーディングのオンラインクラスを受けることになった。4−6ヶ月になりそうであるが、無事乗り切れるのか、少々不安も。javascriptを習得するコースなため、最終的にnode.jsのサーバーサイドでのコーディングもできるようになるまでの知識を得られるよう頑張ろう。node.jsの環境構築に不可欠ともいえるdocker。 今回は、10 best practices to containerize Node.js web applications with Docker の翻訳記事のご紹介です。 今回は、特に翻訳に苦労しました。読みにくい部分もあると思いますが、どうぞ最後までお付き合いください。 Dockerでnode.jsウェブアプリケーションをコンテナ化するための10のベストプラクティス Liran

                                                                            Dockerで安全にnode.jsウェブアプリをコンテナ化する - Qiita
                                                                          • Dockerfileのベストプラクティス8選

                                                                            はじめに Dockerfileを書く上で、Docker社の推奨するベストプラクティスを8つにまとめました。 ベストプラクティスに従うことによって、簡単・安全・効率的な、Dockerfileの作成を目指します。 Dockerのガイドライン コンテナは、必要最小限(エフェメラル)であるべき。 Dockerfile で定義されたイメージを使って作成されるコンテナは、可能ならばエフェメラル(短命;ephemeral)にすべきです。私たちの「エフェメラル」とは、停止・破棄可能であり、明らかに最小のセットアップで構築して使えることを意味します。 Dockerfileベストプラクティス 1. Baseイメージは、公式の信頼できるものを使おう 特定の言語などを扱う場合は、公式が言語が入ったイメージを配布してくれている場合が多いので、そちらを使おう。

                                                                              Dockerfileのベストプラクティス8選
                                                                            • Docker のキャッシュを全力で使いこなそう

                                                                              tl;dr 依存パッケージのダウンロードは最初に実行しよう マルチステージビルドは必須と覚えておこう RUN --mount=type=cache を使おう(でも BuildKit を使えるかは確認して!) pnpm fetch も期待大 はじめに みなさん,Docker を使って開発するときに依存パッケージのダウンロードをずっと待ち続けた経験はありませんか?「依存パッケージの追加なんて頻繁に発生しないし,我慢しよう…」と妥協している方も多いでしょう. 頻繁に発生しない?本当にそうですか? 追加ではなくても依存パッケージの更新なんてよく発生するし,ベースイメージを更新することもあります.その度に全部ダウンロードし直しなんて堪ったもんじゃありません.モバイル回線だったら一瞬でギガがなくなっちゃいますよ! ということで,この記事ではキャッシュを活用して依存パッケージのダウンロードが何度も発生し

                                                                                Docker のキャッシュを全力で使いこなそう
                                                                              • Docker image(イメージ)の違い:alpine,bullseye, buster, slim, stretch, jessie, slim-buster, windowsservercore, latestどれを選ぶべきか?

                                                                                DockerでPythonやRubyなど各言語のイメージを選ぶときに、alpine, buster, slim, stretch, jessie, slim-buster, windowsservercore, latestなど選択肢がたくさんありすぎて、どれを選べばいいのか、、と迷うことがあると思います。 ここでは、alpine, buster, slim, stretch, jessie, slim-buster, windowsservercore, latestなど、それぞれの違いやメリット・デメリット、どういった場合にどれを選ぶべきかをまとめています。 例:docker hubに用意されているRubyのイメージ 各バージョンのイメージに対したくさんのタグが用意されています。 https://hub.docker.com/_/ruby alpine, bullseye, buste

                                                                                  Docker image(イメージ)の違い:alpine,bullseye, buster, slim, stretch, jessie, slim-buster, windowsservercore, latestどれを選ぶべきか?
                                                                                • Earthlyでコンテナ時代のビルド環境を味わう - Runner in the High

                                                                                  【これはUnipos Advent Calendar 2021の2日目の記事です】 つい最近、EarthlyというDockerコンテナベースのビルドツールで、自分の開発しているGoのアプリケーションのMakefile/Dockerfile/docker-compose.yamlを置き換えたのでそれを記事にしてみる。 Earthlyとは github.com めちゃくちゃ雑に言うとDockerイメージをベースにしたビルドツール。 できることとしてはGoogleが作っているBazelに近い*1が、書き味はMakefile+Dockerfileに近く*2、独特の文法が少ない雰囲気。当然、言語やフレームワークに依存しない。まるでローカル環境でビルドをしているかのようにシームレスにコンテナ環境でビルドを実行できる。 Earthlyは書き味こそDockerfileと似ているが、Dockerイメージを作

                                                                                    Earthlyでコンテナ時代のビルド環境を味わう - Runner in the High