Dockerfileのベストプラクティス Top 20
本文の内容は、2021年3月9日にÁlvaro Iradierが投稿したブログ(https://sysdig.com/blog/dockerfile-best-practices/)を元に日本語に翻訳・再構成した内容となっております。 Dockerfileのベストプラクティスのクイックセットをイメージビルドに適用することで、セキュリティ問題を防ぎ、コンテナ化されたアプリケーションを最適化する方法を学びます。 コンテナ化されたアプリケーションやマイクロサービスに精通している人なら、自分のサービスがマイクロサービスであることに気づいているかもしれません。しかし、脆弱性の検出、セキュリティ問題の調査、デプロイ後の報告や修正など、管理のオーバーヘッドがマクロな問題になっています。 このオーバーヘッドの多くは、セキュリティをシフトレフトし、開発ワークフローの中で可能な限り早く潜在的な問題に取り組むこ
今からでも間に合うDockerの基礎。コンテナとは何か、Dockerfileとは何か。Docker Meetup Tokyo #2
今からでも間に合うDockerの基礎。コンテナとは何か、Dockerfileとは何か。Docker Meetup Tokyo #2 コンテナ型仮想化の技術として注目されているDockerの勉強会「Docker Meetup Tokyo #2」が4月11日にグーグル東京オフィスで開催されました。 この勉強会には定員100名のところへ400名を超える申し込みがあり、参加できなかった方も多かったと思います。本記事では、最初のセッションとして行われた森和之氏による「今からでも間に合うDocker基礎+Docker 0.9概要」をダイジェストで紹介しましょう。 参考記事 2013年のDocker登場から現在（2018年）までを振り返り、その次の段階を展望した記事もご参照ください。 Dockerコンテナ時代の第一章の終わり、そして第二章の展望など 今からでも間に合うDocker基礎 株式会社トップゲー
Explaining “Best practices for writing Dockerfiles” Dockerfileを書くためのベストプラクティス【参考訳】v18.09 - Qiita https://qiita.com/zembutsu/items/a96b68277d699f79418d こちらをベースにした解説スライドです。Read less
今時のアプリ開発において、コンテナは避けて通れないものになっています。そして数多くあるコンテナ実行環境の中でも、デファクトスタンダードと言えるのがDockerです。そんなDockerのイメージですが、皆さんは正しくビルドできていますか? そのコンテナは無駄に太っていませんか? 効率よく最短時間でビルドできていますか? セキュリティは大丈夫ですか? 今回はDockerfileの書き方をテーマに、「今さら聞けない」Docker入門をお届けします。
概要 Docker Documentation にある、Best practices for writing Dockerfiles の参考日本語訳です。ドキュメントは、2019年5月31日現在のカレントである Docker v18.09 (current) です。 背景 ―― 以前の翻訳から時間が経過し、全体的に手直ししたいものの、差分が大きすぎる状況です。そのため、リファレンスや重要性の高いものから優先的に着手することにしました。 スライド資料 背景やヒント、図解などを追加した補足用スライドを作成しました Dockerfile を書くためのベストプラクティス解説編 BuildKitなどの最新機能や Dockerfile の記述例については、こちらのスライドをご覧ください。 Dockerfileを改善するためのBest Practice 2019年版 Dockerfile を書くためのベ
作業環境をDockerfileにまとめて、macOSでもLinuxでもWSL2でも快適に過ごせるようになった話
こんにちは、CLI生活至上主義？の、 ひのしば です。 まぁ、至上主義というのは、ちょっと言い過ぎかもしれませんが、screen, vim, mutt, newsboat, pass, あとは、gitやssh 辺りを使う生活をしており、1日の作業がこれだけで完結するような事もあるような生活を送っています。 さて、そんな私が、ワークステーションサーバに、macOSや、Windows, Linuxから接続して操作するといった構成から、 作業環境をDockerfileにまとめ、手元で上がる環境をdockerコンテナへ統一し作業する構成とした話を紹介します。 この環境は、ここ数ヶ月、不自由なく使えている事もあり、自身の整理のためにも、どのような点が気になって対応したのかを挙げていきます。 詳細は下部に記載する通りですが、 例えば、dockerfile上のuidの問題に気をつける点、Linuxとma
Dockerfileのベストプラクティス８選
はじめに Dockerfileを書く上で、Docker社の推奨するベストプラクティスを８つにまとめました。 ベストプラクティスに従うことによって、簡単・安全・効率的な、Dockerfileの作成を目指します。 Dockerのガイドライン コンテナは、必要最小限（エフェメラル）であるべき。 Dockerfile で定義されたイメージを使って作成されるコンテナは、可能ならばエフェメラル（短命；ephemeral）にすべきです。私たちの「エフェメラル」とは、停止・破棄可能であり、明らかに最小のセットアップで構築して使えることを意味します。 Dockerfileベストプラクティス 1. Baseイメージは、公式の信頼できるものを使おう 特定の言語などを扱う場合は、公式が言語が入ったイメージを配布してくれている場合が多いので、そちらを使おう。
こんにちは、主に検索周りを担当しているエンジニアの伊藤です。 この記事は Enigmo Advent Calendar 2020 の 17 日目の記事です。 みなさんは適切なDockerfileを書けていますか？とりあえずイメージのビルドが出来ればいいやとなっていませんか？ 今回は自戒の意味も込めて、改めてDockefileのベストプラクティスについて触れつつ、 そもそもDockerfileを書かずにコンテナイメージをビルドする方法とコンテナセキュリティに関する内容についてまとめてみました。 Dockerfileのベストプラクティス イメージサイズは極力小さくしよう ビルドキャッシュを活用しよう Dockerfileに関する悩みどころ Dockerfileを書かないという選択肢 Buildpack Cloud Native Buildpacks CNBの仕組み デモ CNBのメリット セキ
概要 Dockerfileを書くためのベストプラクティスを読んで、ベストプラクティスなDockerfileを作った/作りたい人が対象です。 そのDockerfileで大丈夫かを3分でチェックできるツールをつくりました。Hadolintのような、単なるDockerfileのLinterではなく、ビルドしたイメージの中身まで細かく分析します。 通常のLinterでは原理的に不可能な、ベースイメージに存在している危険性も含めて調べることができます。 ←GitHubのStarもらえると嬉しいです。 Dockleの内部で使われているツールはTrivy, Vulsなどと同じなので、そのあたりを踏まえて、動作原理を別記事にまとめました。 人を震えさせるツール｢Dockle｣の仕組みを解説 なお、DockerHubで人気のコンテナに対して試した結果をサイトにして公開しています。操作方法もふくめて、別記事に
あなたのDockerfileはベストプラクティスに従っていますか？(ベストプラクティスとチェックツール) - Qiita
Dockerfileのベストプラクティス ベースイメージには公式のレポジトリを使用する FROM命令において、使用するベースイメージは公式のリポジトリのものを使用し、軽量なものが推奨されている。 例えば、Debian イメージなど。 FROM [--platform=<プラットフォーム>] <イメージ名> [AS <名前>] FROM [--platform=<プラットフォーム>] <イメージ名>[:<タグ>] [AS <名前>] FROM [--platform=<プラットフォーム>] <イメージ名>[@<ダイジェスト>] [AS <名前>]
Dockerイメージのサイズを1バイトでも削りたい皆さんに朗報です。 もうすぐリリースされるDocker 17.05でmulti stage buildという機能が導入される予定です。 こいつはこれまでのDockerfileの常識を覆す革新的な機能なのです。 Docker 17.05は本稿執筆時点では2017/05/03リリース予定となっており、現在はRC版が出てるので、気になる新機能を一足早くで試してみた。(2017/05/07追記:最終的に2017/05/04に正式リリースされました) とりあえずこの新しいシンタックスのDockerfileを見てほしい。 FROM golang:alpine AS build-env ADD . /work WORKDIR /work RUN go build -o hello main.go FROM busybox COPY --from=buil
はじめに Dockerfileとは docker imageを作成する際のコマンドをコード化したもの 公式ドキュメント Dockerfileは「コンテナを動かす」ためだけなら簡単に作成することが出来るが、工夫せずに書くと運用上いろいろな問題が発生する。 それらの問題点のほとんどは書き方のテクニックによって回避することが出来るが、それらのテクニックを駆使すると、今度はDockerfileの中が複雑になっていく。 Dockerfileはなぜ複雑にならざるを得ないのか 発生する問題とそれに対するテクニックを例を上げて説明していくことで理解してもらう。 rails5.1 hello world projectを例に説明する。 簡単なDockerfileの例 重要なのはFROMとRUNとCOPYのみ FROM ベースとなるimageの指定 https://docs.docker.com/engine
Terraform, Dockerfile, KubernetesなどIaCの脆弱な設定をCI/CDで検知する - knqyf263's blog
概要 自分の所属企業であるAqua SecurityがTFsecというOSSを買収しました。 blog.aquasec.com TFsecはどういうツールかというとTerraformの静的解析スキャナーです。Terraformの設定ファイルを渡すことでセキュリティに関する設定ミスを主に検知してくれます。 github.com そのアナウンスに伴い、TFsecは自分が開発している脆弱性スキャナーであるTrivyに統合されました。TrivyではTerraformに加えDockerfileやKubernetesなど、いわゆるInfrastructure as Code（IaC）の設定ミスを検知するマネージドポリシーも提供しています。他にもJSONやYAMLなど一般的なファイルフォーマットに対応しているため自分でポリシーを書くことでそれらの検知にも使えます。CloudFormationやAnsib
このドキュメントは、効率的なイメージ構築のために推奨するベストプラクティスを扱います。 Docker は Dockerfile に書かれた命令を読み込み、自動的にイメージを構築します。 Dockerfile はイメージを構築するために必要な全ての命令を、順番通りに記述したテキストファイルです。 Dockerfile は特定の書式と命令群に忠実であり、それらは Dockerfile リファレンス で確認できます。 Dockerfile の命令に相当する読み込み専用のレイヤによって、 Docker イメージは構成されます。それぞれのレイヤは直前のレイヤから変更した差分であり、これらのレイヤは積み重なっています。次の Dockerfile を見ましょう。 命令ごとに１つのレイヤを作成します。 FROM は ubuntu:18.04 の Docker イメージからレイヤを作成 COPY は現在のデ
業務やプライベートでのハンズオンを通して得た知見を元に、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
CloudNative Days Kansai 2019前夜祭のLTで発表した資料です。 発表の大筋は@makingの『Pack to the Future - SpringOne Platform 2019報告会』 https://docs.google.com/presentation/d/1rzaxReQ92WaWI24v-GsTwjtLCMq2YaFSTl9t6SEjPxQ/mobilepresent?slide=id.g6ad6e2f668_0_5 およびその元ネタの『Pack to the Future: Cloud-Native Buildpacks on k8s』 https://www.slideshare.net/SpringCentral/pack-to-the-future-cloudnative-buildpacks-on-k8s をベースにしています。 Clou
インストール Docker エンジンのインストール Mac OS X Windows Ubuntu Red Hat Enterprise Linux CentOS Fedora Debian Arch Linux CRUX Linux FrugalWare Gentoo Oracle Linux openSUSE and SUSE Linux Enterprise Amazon EC2 Google Cloud Platform IBM SoftLayer Microsoft Azure Rackspace Cloud Joyent Triton バイナリをインストール Kitematic のインストール Docker Machine のインストール Docker Compose のインストール Docker Swarm のインストール Docker 基礎 コンテナのクイックスタート Do
結論 以下の手順で作るのが効率的です。 ベースにする Docker イメージを決める docker run -it <docker-image> sh でコンテナ内部で作業 1行ずつ、うまくいったらどこかにメモ 失敗したらいったん exit して再度 docker run ファイルの取り込みやポートの外部公開が必要ならオプション付きで docker run 全部うまくいったら Dockerfile にする ネットで見たことはないですが、もし docker build で試行錯誤しながら Dockerfile を作るとしたら、それはさすがに苦行です。 遅い デバッグしにくい！コンテナ爆発しろ！！って気持ちになります。 これが原因で「Docker 使えない 便利じゃない 」と思っていたのならそれは勘違いです。 手順詳説 試しに ip-api.com にリバースプロキシするだけの Nginx イ
Dockerfile自信持って書けてますか？おすすめlintツール 「hadolint」について紹介 - Qiita
はじめに Dockerfile、サッと書こうと思ったのに、書き始めたら意外と時間かかったりしますよね。 突き詰めるとすごく奥が深いなと思います。 公式のドキュメントでも、Dockerfileのベスト・プラクティスという形で公開してくれていますが、 これを毎回意識するのは大変です。 また、意識できていたとしても、複数人で管理していると、各個人のスキルレベルによって差が出てしまいます。 そんなときにおすすめのツールを見つけたので紹介します。 hadolintというツールです。 Haskell Dockerfile Linterの略だそうで、Dockerfileの静的解析を行ってくれるlintツールです。 hadolintを使うとこんな利点があります。 build前にシンタックスエラーなどに気付ける (地味にトライアンドエラーしてると時間食うんですよね...) 自然とベストプラクティスに則ったD
Google、最適化されたコンテナイメージを生成する「buildpacks」をオープンソースで公開。Dockerfile不要でJavaやGo、Node.jsをコンテナへビルド
Google、最適化されたコンテナイメージを生成する「buildpacks」をオープンソースで公開。Dockerfile不要でJavaやGo、Node.jsをコンテナへビルド Googleは、アプリケーションのコードから最適なコンテナイメージを生成するツール群「buildpacks」（ビルドパック）をオープンソースで公開すると同時に、Google CloudのCloud Run、Anthos、Google Kubernetes Engine (GKE)がこのbuildpakcsに対応したことを発表しました。 We’re launching broad support across @googlecloud for buildpacks, an open-source technology that makes it fast & easy to create secure, product
この文章では、私が個人開発で使用しているDockerサーバの管理や、業務でプロジェクトメンバーに開発環境を配布する際に、Dockerfileを書く上で気をつけていることを整理します。 1. Dockerファイルのフォルダには不要なファイルを置かない docker buildは開始時にコンテクスト(現在のフォルダの状態)をDockerデーモンに転送します。具体的には、Dockerfileのあるディレクトリの内容をtarで圧縮し送ります。そのため、Dockerfileのディレクトリに不要なファイルがあるとビルドに余計な時間がかかりよくありません。 とはいえ、プロジェクトフォルダでビルドした成果物をイメージ化するためにDockerfileを含める運用はよくあると思いますので、その場合は.dockerignoreファイルを記述して余計なファイルが転送対象にならないようにします。 .dockerig
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
前回のエントリで作った Docker イメージ motemen/datastore-emulator は、google/cloud-sdk をベースにしているが、このベースイメージがけっこうな頻度で更新される。とうぜん自分はその追従に手を煩わせる気はなくて、全部自動でやってほしい。 やりたかったこと google/cloud-sdk:x.y.z がリリースされたら、 リポジトリ中の ./Dockerfile と ./alpine/Dockerfile の FROM を google/cloud-sdk:x.y.z(-alpine) に更新し、 x.y.z タグを打って git push することで、 Docker Hub に x.y.z(-alpine) タグとしてリリースする これを自動かつ無料で実現したい。 採用しなかった案: 自分でなんか作る はじめは適当な GitHub Actio
目次 なぜDockerfileを使うのか？ ADDとDockerfileにおいてのコンテキストを理解する CMDでコンテナをバイナリのように扱う CMDとENTRYPOINTの違い exec format error ビルド時のキャッシュについて: キャッシュが有効なときと無効なとき ある一行でキャッシュが使われなかったらそれ以降のすべての行でキャッシュは使われない 何もしないコマンドを追加してもキャッシュは無効になる コマンドと引数の間に意味のないスペースの入れてもキャッシュは無効となる Dockerfileの行に意味のないスペースを入れてもキャッシュは有効 冪等ではない命令でもキャッシュは効いてしまう ADD以降にある命令はキャッシュされない (ただし、0.7.3以前のバージョンを使っている場合のみ) コンテナをバックグラウンドで動かすハック なぜDockerfileを使うのか？ Do
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
1つのDockerfileだけでGoの開発環境(ホットリロード)と本番環境(マルチステージビルド)を記述する - Qiita
こんにちは。po3rinです。今回はDocker Meetup Tokyo #29 (Docker Bday #6)で少し話題になった小ネタです。タイトル通りDockerfile1つでGoの開発環境(ホットリロード)と本番環境(マルチステージビルド)を記述する方法を紹介します。今回は「この方法をおすすめします！」というよりかは「こういう方法もあるよー」という紹介なので、開発の状況に合わせて方法を選んでいくと良いでしょう。 イントロ 開発環境用と本番環境でイメージビルド過程を分けるモチベーションとしては、開発環境用はホットリロードしたいけど、本番はビルドしたバイナリだけを使いたいという思いなどがあります。 これらを２つのDockerfileに分ける場合、同じディレクトリ階層に「Dockerfile」という名前のファイルを２つ置けません。これに関して、下記の記事のようにdocker build
GitHub - hexops/dockerfile: Dockerfile best-practices for writing production-worthy Docker images.
Writing production-worthy Dockerfiles is, unfortunately, not as simple as you would imagine. Most Docker images in the wild fail here, and even professionals often[1] get[2] this[3] wrong[4]. This repository has best-practices for writing Dockerfiles that I (@slimsag) have quite painfully learned over the years both from my personal projects and from my work @sourcegraph. This is all guidance, not
2019年5月24日(金)の発表資料をベースに解説等を加えたバージョンです。 Docker Meetup Kansai #3 https://dockerkansai.connpass.com/event/129089/Read less
機械学習なdockerfileを書くときに気をつけとくと良いこと - nykergoto’s blog
みなさん機械学習系の環境構築はどうやってますか? 僕は最近は Docker を使った管理を行っています。 特に師匠も居なかったので、ぐぐったり人のイメージを見たり手探りで docker をつかいつかいしている中で、最初からやっとけばよかったなーということがいくつかあるのでメモとして残しておきます。 大きく2つです。 キャッシュは消す テストを書く キャッシュは消す ライブラリをいろいろと install すると大抵の場合ダウンロードしたファイルを保存されている場合が多いです。何かのタイミングで再びそのライブラリをインストールする際にはダウンロードしたファイルを使って、素早くインストールすることができます (この仕組みがキャッシュです)。 キャッシュがあると容量が重くなるという欠点があります。重たいイメージは pull に単に時間がかかりますから、システムとしてデプロイする時にトラフィックが
Railsアプリの開発環境向けDockerfile + docker-compose.yml - アジャイルSEの憂鬱
人に説明するときに記事あると便利なので、開発環境向けのDockerfileとdocker-compose.ymlを書いておく。 Dockerfile FROM ruby:3.0.0 WORKDIR /app # Using Node.js v14.x(LTS) RUN curl -fsSL https://deb.nodesource.com/setup_14.x | bash - # Add packages RUN apt-get update && apt-get install -y \ git \ nodejs \ vim # Add yarnpkg for assets:precompile RUN npm install -g yarn # Add Chrome RUN curl -sO https://dl.google.com/linux/direct/google-ch
Docker Compose | Docker Compose Tutorial | Docker Tutorial For Beginners | De...
Dockerfiles provide a simple syntax for building images. The following are a few tips and tricks to help you get the most out of Dockerfiles. 1: Use the cache Each instruction in a Dockerfile commits the change into a new image which will then be used as the base of the next instruction. If an image exists with the same parent and instruction ( except for ADD ) docker will use the image instead of
前提 コンテナを用いてアプリケーションのワークロードを構築することにはいくつかの利点があります。 なかでも、下記に上げられるポータビリティと環境の再現性は非常に強力です。 ポータビリティ コンテナは、アプリケーションとその依存関係をコンテナ内にパッケージ化します。 これにより、開発環境で構築したコンテナを本番環境にデプロイする際にも、一貫した動作が期待できます。 異なる環境間でアプリケーションを移行する際に、互換性の問題や依存関係の不一致が生じるリスクが低減され、ポータビリティが高まります。 環境の再現性 コンテナは環境に依存しないため、開発者が特定の環境でアプリケーションを構築した場合でも、他の開発者や運用チームが同じ環境を再現することが容易です。 コンテナイメージにはアプリケーションのコードとその実行環境が含まれており、イメージを共有することで他の人が同じ環境でアプリケーションを実行で
仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編 | フューチャー技術ブログ
BusterとかStretchという名前が見慣れない方もいるかもしれませんが、これはLinuxディストリビューションとしてシェアの大きなDebianのコードネームです。 Debianバージョンが少し古いStretchの方がちょびっとサイズが小さかったりはしますが、まあ実用的にはサポートが長い方がいいですよね。slimを使ってGCCとかのコンパイラを自前でダウンロードしている記事とかもたまに見かける気がしますが、マルチステージビルドであれば、そんなにケチケチしなくていいのと、パッケージダウンロードは逐次処理なので遅く、処理系が入ったイメージのダウンロードの方が高速です。並列で処理されるし、一度イメージをダウンロードしてしまえば、なんどもビルドして試すときに効率が良いです。また、多くのケースでネイティブのライブラリも最初から入っており、ビルドでトラブルに遭遇することはかなり減るでしょう。 Py
Dockerfileを作る時、最初は以下の方法でやってました。 Dockerfile書く ビルドする（動かしたいアプリ含め） 起動してみる 動かなかったらDockerfile修正する またビルドして試す こんな感じでしたが、これは非常に効率が悪いです。修正して検証を行う度にビルドが発生してしまい、待ちが発生してしまいます。 どうするか？ ベースイメージにアタッチ 動かしたいアプリの実行に必要なコマンドを入れて、成功したらコマンドをメモっていく アプリが動くまで「コマンド実行→成功したらメモ」を繰り返す アプリが動いたらメモったコマンドでDockerfileを作る つまり、いきなりDockerfileを作るのではなく、ベースイメージに入ってコマンドを実行して動作確認をしながらDockerfileに記述する内容を固めていき、最後に1回だけビルドします。 なぜ？ Dockerfileに記述するの
microscannerは、CVEベースでDockerイメージの脆弱性検査をするツールです。簡単に導入できかつ有用なので、導入方法と利用上の注意事項などをまとめました。 先日レポートした「Docker漬けの一日を共に〜Docker Meetup Tokyo #23」は、情報量がてんこ盛りで、学び多くて楽しくてワッセロイだったんですが、その中で、とく(@CS_Toku)さんがLT発表されていた「KubeCon報告とmicroscanner試してみた」のmicroscannerが、面白そうだったので早速触ってみました。 Dockerfileに4行追加するだけで、CVEベースの脆弱性検査が無料で利用でき、既存のイメージビルドに組むこむのもお手軽そうなので、これからコンテナ導入しようと思っている人も、既に本番でガンガンコンテナ使っている人も、一度導入を検討してみてはいかがでしょうか。 __ （祭）
前回の「ついに1.0がリリース！ Dockerのインストールと主なコマンドの使い方」では、Docker EngineのインストールからDockerコンテナーを作成し、Dockerイメージに保存するところまでを紹介しました。 Dockerは開発のスピードが速く、7月3日にはバージョン1.1.0がリリースされています。詳細はブログ「ANNOUNCING DOCKER 1.1.0」を参照してください。 今回は、Dockerコンテナーの構成とDockerイメージの作成を一括で行う、「Dockerfile」ファイルと「docker build」コマンドの利用方法を紹介します。 docker run／docker commitコマンドによるコンテナー作成の限界 前回はDockerコンテナーを「docker run」コマンドで起動し、コンテナー内でソフトウェアのインストールやサービス起動など自由に構成で
Amazon ECSで動かすRailsアプリのDockerfileとGitHub Actionsのビルド設定 - メドピア開発者ブログ
CTO室SREの@sinsokuです。 Dockerイメージのビルドを高速化するため、試行錯誤して分かった知見などをまとめて紹介します。 AWSのインフラ構成 assetsもECSから配信し、CloudFrontで /assets と /packs をキャッシュする構成になっています。 Rails on ECS デプロイ時にassetsが404になる問題 以前の記事に詳細が書かれているため、ここでは問題の紹介だけしておきます。 Rails等のassetsファイルをハッシュ付きで生成し配信するWebアプリケーションの場合、ローリングアップデートを行うと、アップデート時に404エラーが確立で発生してしまいます。 引用: メドピアのECSデプロイ方法の変遷 Dockerfile 実際のDockerfileには業務上のコード、歴史的な残骸などが含まれていたので、綺麗なDockerfileを用意しま
この記事について Dockerfile Best Practices を独学用にまとめたものです。理解を深めるために、順序を入れ替えたり、元の記事にない記述を足したり、逆に削ったりしています。まとめていて感じたのは、レイヤがどのようにできるか、どのような条件でキャッシュを使うかの理解が重要だと感じました。 [元記事はこちら] https://docs.docker.com/develop/develop-images/dockerfile_best-practices/ レイヤの考え方について Docker イメージは read オンリーのレイヤーから構成されています。個々のレイヤは Dockerfile の各行に該当します。レイヤは前のレイヤからの差分としてスタックされ積み重なっていきます。例えば、次の Dockerfile を考えます。 各行のコマンドは一つのレイヤを作ります。 イメー
Dockerレジストリ は、今やあふれんばかりの状況です。これを書いている時点で、”node”と検索すれば、1000件弱の結果がヒットします。どうやって選べばいいのでしょうか？ いいDockerイメージを構成するもの いい悪いは主観ではありますが、私がいいと考えるDockerイメージには、いくつかの基準があります。 実用的： 以下に例を挙げます。 最初にコンテナにアップデートを適用しなくても、Android SDKのイメージがプロジェクトをコンパイルできる。 MySQLのコンテナが、データベースとユーザを使用してサーバをブートする方法を明示する。 最小限： コンテナの利点は、アプリケーションをサンドボックスできること（セキュリティがない場合には、ホストファイルシステム上で混乱を避けられること）です。ホストシステムにnode.jsをインストールしたり、JDK（Java開発キット）でシステムを
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Dockerfile を書くためのベストプラクティス解説編
今さら聞けないDocker入門 〜 Dockerfileのベストプラクティス編
Dockerfileを書くためのベストプラクティス【参考訳】v18.09 - Qiita
Dockerfileのベストプラクティスとセキュリティについて - エニグモ開発者ブログ
3分でできる！最高のDockerfileを書いたあとにやるべき1つのこと - Qiita
Docker multi stage buildで変わるDockerfileの常識 - Qiita
Dockerfileはなぜ複雑になるのか - Qiita
Dockerfile のベスト・プラクティス — Docker-docs-ja 19.03 ドキュメント
Dockerfileのベストプラクティス - Qiita
Dockerfile書きたくないでござる
Dockerfile のベストプラクティス — Docker-docs-ja 1.9.0b ドキュメント
効率的に安全な Dockerfile を作るには - Qiita
Dockerfileを書くときに気をつけていること10選 - Qiita
Dockerfile をベースイメージの更新に自動で追従させる - 詩と創作・思索のひろば
Dockerfileを書く時の注意とかコツとかハックとか | Kim's Tech Blog
私家版 Dockerfile Pattern
Dockerfileを改善するためのBest Practice 2019年版
DCSF19 Dockerfile Best Practices
Dockerfile Best Practices
複数の環境でDockerfileを共通化するために使えるtips
Dockerfileの作り方を考え直したらすごく効率が上がった
無料で脆弱性検査！Dockerfileに4行追加で導入できるmicroscannerを試してみた
Dockerfileとdocker buildコマンドでDockerイメージの作成
Dockerfile のベストプラクティスを自分なりに整理してみた - Qiita
【翻訳】いいDockerイメージを構築するには？ ーDockerfileのベストプラクティス | POSTD