2024年版のDockerfileの考え方＆書き方 | フューチャー技術ブログ
最近はお客さんとの勉強会でDockerのドキュメントをつまみ食いして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 本エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基本的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整
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
Dockerfileのベストプラクティス Top 20
本文の内容は、2021年3月9日にÁlvaro Iradierが投稿したブログ(https://sysdig.com/blog/dockerfile-best-practices/)を元に日本語に翻訳・再構成した内容となっております。 Dockerfileのベストプラクティスのクイックセットをイメージビルドに適用することで、セキュリティ問題を防ぎ、コンテナ化されたアプリケーションを最適化する方法を学びます。 コンテナ化されたアプリケーションやマイクロサービスに精通している人なら、自分のサービスがマイクロサービスであることに気づいているかもしれません。しかし、脆弱性の検出、セキュリティ問題の調査、デプロイ後の報告や修正など、管理のオーバーヘッドがマクロな問題になっています。 このオーバーヘッドの多くは、セキュリティをシフトレフトし、開発ワークフローの中で可能な限り早く潜在的な問題に取り組むこ
Dockerfile をベースイメージの更新に自動で追従させる - 詩と創作・思索のひろば
前回のエントリで作った 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を書くためのベストプラクティス【参考訳】v18.09 - Qiita
概要 Docker Documentation にある、Best practices for writing Dockerfiles の参考日本語訳です。ドキュメントは、2019年5月31日現在のカレントである Docker v18.09 (current) です。 背景 ―― 以前の翻訳から時間が経過し、全体的に手直ししたいものの、差分が大きすぎる状況です。そのため、リファレンスや重要性の高いものから優先的に着手することにしました。 スライド資料 背景やヒント、図解などを追加した補足用スライドを作成しました Dockerfile を書くためのベストプラクティス解説編 BuildKitなどの最新機能や Dockerfile の記述例については、こちらのスライドをご覧ください。 Dockerfileを改善するためのBest Practice 2019年版 Dockerfile を書くためのベ
Docker入門して機械学習環境構築 - karaage. [からあげ]
最新版にアップデートしました。 古くなっていたところなど多数あったので、アップデートして所属のテックブログとして投稿しました。よろしければこちらをまずは参照ください。 このページは、残しておきます。 機械学習の環境構築のために今更ながらDocker入門 最初に、この記事の対象者は、私のように趣味で機械学習しているエンジョイ勢や学生さん、初心者が対象です。インフラなど本職での運用などは全く想定しておりませんので、ご承知おき下さい。詳しい方は色々教えていただけると嬉しいです、それか生暖かく見守っておいて下さい。 というわけで、今更ながら機械学習の仮想環境としてDockerがとても優秀であることに気づいたので、Dockerに入門してみました。Dockerは何か？という基礎的な解説は、以下のさくらインターネットさんの記事が非常に分かりやすかったので、以下参照下さい。 仮想環境に関しては、Virtu
![Docker入門して機械学習環境構築 - karaage. [からあげ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/7b11ffcf9f4021aa000a4e241f26e517441fe138/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fk%2Fkaraage%2F20190516%2F20190516000848.png)
dockerfileの静的解析ツールが便利すぎた - Qiita
背景 Dockerfileを静的解析したいと思い便利なツールがないかと探していたら発見しました。 DockerfileのLintツール ◆ hadolint/hadolint エラーが出るDockerfileをビルド前に検知してくれます。 ちなみにHaskellで書かれているようです。 現時点での最新バージョンはv1.15.0でmac等にも対応している。 GitHubのスター数は1000程である。 lintとは wikiより引用 lint とは、主にC言語のソースコードに対し、コンパイラよりも詳細かつ厳密なチェックを行うプログラムである。 型の一致しない関数呼び出し 初期化されていない変数の参照 宣言されているが使われていない変数 同じ関数を参照しているが、戻り値を使う場合と使わない場合がある[疑問点 – ノート] 関数が戻り値を返す場合と返さない場合がある など、コンパイラではチェックさ
2018年なぜ私達はコンテナ/Dockerを使うのか | iret.media
2017年にもうコンテナの未来・一つのカタチはもう確定したと言え、今更感があるものの、改めてDockerとコンテナについて。 今更こんなことを書くのは、情報が溢れてくる今こそ、正しく理解し、正しい順序で学習することが重要だと切に思うから。 内容についてのお断り How Toはかきません あくまでも2018年時点の私見 目新しい情報はない、2016年頃に書けたレベル Dockerをこう使えとか、こうするのがいいとかの話ではなく、コンテナとDockerに関して大きな視点で現時点で私の考えを書きます。また、私自身はかなりのコンテナ推進派です。 Dockerをよくわかっている人には意味のない記事となります。 コンテナ(Docker)のメリット 何故コンテナがいいのか、コンテナをある程度の学習コストを払ってでもやる理由 コンテナとDocker コンテナ技術はDockerが生まれる前から存在する技術で
Dockerfileを書くときに気をつけていること10選 - Qiita
この文章では、私が個人開発で使用しているDockerサーバの管理や、業務でプロジェクトメンバーに開発環境を配布する際に、Dockerfileを書く上で気をつけていることを整理します。 1. Dockerファイルのフォルダには不要なファイルを置かない docker buildは開始時にコンテクスト(現在のフォルダの状態)をDockerデーモンに転送します。具体的には、Dockerfileのあるディレクトリの内容をtarで圧縮し送ります。そのため、Dockerfileのディレクトリに不要なファイルがあるとビルドに余計な時間がかかりよくありません。 とはいえ、プロジェクトフォルダでビルドした成果物をイメージ化するためにDockerfileを含める運用はよくあると思いますので、その場合は.dockerignoreファイルを記述して余計なファイルが転送対象にならないようにします。 .dockerig
DockerfileのADD/COPYに--chownオプションができた - Got Some \W+ech?
11/10: 追記。CI/CDでの制限について書いてなかった。 Dockerのベストプラクティスに、サービスをnon-rootユーザーで走らせなさい、というのがある。 docs.docker.com そうすること自体は簡単なのだけれども、当然ながらユーザー権限にあわせてコンテナ内のファイル等の権限を設定しなきゃいけない。仮にUSER指定した後にCOPYしてもroot:rootの権限になるので、別途chownをしてやらなければならなかった。 USER app COPY . $APP_DIR # $APP_DIRの権限はroot:root RUN chown -R app:app $APP_DIR RAILSなど関連ファイル数が結構な量になるサービスの場合、すべての権限が変わるまで10min~15minとか余裕でかかってた。このせいで、dockerのベスプラに従ってなかった人は多いと思う。僕も
Dockerfileはなぜ複雑になるのか - Qiita
はじめに Dockerfileとは docker imageを作成する際のコマンドをコード化したもの 公式ドキュメント Dockerfileは「コンテナを動かす」ためだけなら簡単に作成することが出来るが、工夫せずに書くと運用上いろいろな問題が発生する。 それらの問題点のほとんどは書き方のテクニックによって回避することが出来るが、それらのテクニックを駆使すると、今度はDockerfileの中が複雑になっていく。 Dockerfileはなぜ複雑にならざるを得ないのか 発生する問題とそれに対するテクニックを例を上げて説明していくことで理解してもらう。 rails5.1 hello world projectを例に説明する。 簡単なDockerfileの例 重要なのはFROMとRUNとCOPYのみ FROM ベースとなるimageの指定 https://docs.docker.com/engine
DockerfileをLintするにはhadolintが良さそう
Haskellで書かれたDockerfileのLintツールのようです。 インストール Macならhomebrewでできます。 $ brew install hadolint Lintしてみる サンプルとして提示されていたDockerfileを使ってみます。内容は以下のようなDockerfile。エラー吐きそうなのが一目瞭然ですね。 FROM debian RUN export node_version="0.10" \ && apt-get update && apt-get -y install nodejs="$node_verion" COPY package.json usr/src/app RUN cd /usr/src/app \ && npm install node-static EXPOSE 80000 CMD ["npm
Docker Multi-Stage Builds
One of the most anticipated features of Docker’s recent 17.05 release is multi-stage builds. Even those familiar with Docker may find themselves asking what a multi-stage Docker build is. Before we learn about multi-stage Docker builds, lets examine a single-stage build and the process by which Docker uses Dockerfile instructions to create an image. Codefresh supports multi-stage builds as part of
Docker multi stage buildで変わるDockerfileの常識 - Qiita
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を読んでみる(elasticsearch-docker) - Qiita
dockerとは コンテナという仮想的な空間を提供して、その中でアプリケーションを実行できる docker公式 Dockerfileとは Dockerコンテナーの構成内容を書くみたい Makefileみたいなイメージ なんで読んだ？ Dockerはなんとなく使えていたが、どんな構成になっているかわかっていなかった そのうちカスタムするんじゃね？知ってなきゃやばくね？って思った どのように構成を指定しているかをちゃんと理解したほうが良いと思った 対象 elastic公式の、Elasticsearchコンテナ ちょっと使うことがあったので elastic/elasticsearch-docker ざっと見る だめだ・・ １行ずつ愚直に調べながら読むしかねぇ・・・ FROMは元となるDockerイメージを指定する命令文 elasticsearch-alpine-baseはAlpin Linuxを
Packer + itamaeでDockerfileのないDockerライフ - Qiita
Dockerは Dockerfile という独自のDSLで記載されたファイルからDockerイメージを作成するのだが、 普段かいてるitamae使えないかなと思ったらどうやら Packerというものと組み合わえるといけるらしい Packerを使ってChef/Puppet/AnsibleでDockerのイメージをつくる ただ僕が普段使っているのはItamae。。。Packerでは現状対応してないという。 Packerとは？ VagrantとかTerafformとかを作っているHashicorp社製のソフトウェア 複数のプラットフォームのマシン、コンテナイメージを1つの設定ファイルから作成できる。 身近な例でいうと AMIの作成をコマンド一発で作れるようになる。 他にもbuild先を切り替えるとGCEとかVMwareとかのイメージが作れるようになる お題 rubyの2.3.1が動いていてrai
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ten simple rules for writing Dockerfiles for reproducible data science
Cloud Native Buildpackで めんどうなコンテナイメージ作成を�自動化しよう
Dockerfile を書くためのベストプラクティス解説編
hadolint/README.md at master · hadolint/hadolint
