Dockerは公式にDockerfileのベストプラクティスを表明しています。 が、このベストプラクティスに沿っているかどうか？を人間がいちいちレビューしていくのは正直しんどい、というか現実的ではない… そこで「せや！静的解析したろ！」という時に便利なのがhadolintというライブラリです。 使ってみる 今回はVSCode拡張機能とGHAのCI時に静的解析してもらいたいと思います。 今回はちょうどメンテナンスしていない自分のリポジトリがあるので、これに対して静的解析をかけていきます。 まずはVSCode拡張機能で利用するための下準備として、hadolint本体をOSにインストールします。 Macの場合はこちら。 docker/php/Dockerfile:8 DL3008 warning: Pin versions in apt get install. Instead of `apt-

最近はお客さんとの勉強会でDockerのドキュメントをつまみ食いして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 本エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基本的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整

Dockerfileを解析、最適化やベストプラクティスをガイドしてくれる「Docker Buildチェック」機能が正式版に Docker社は、Dockerfileを解析して最適化とベストプラクティスをガイドしてくれるツール「Docker Buildチェック」機能の正式版をリリースしました。 Docker Buildチェックは、WindowsやMacなどのデスクトップ環境にDockerコンテナ環境を簡単に導入できるDocker Desktopの最新版として7月29日にリリースされた「Docker Desktop 4.33」の機能として提供されます。 Dockerfileとは、Dockerコンテナを構成するさまざまなファイルを取得し、ビルドを実行してDockerコンテナイメージを作成する際の手順書といえます。 そのため、Dockerfileはビルドが正常に実行されるようにバグがないように手順を

本記事は「珠玉のアドベントカレンダー記事をリバイバル公開します」企画のために、以前Qiitaに投稿した記事を一部ブラッシュアップしたものになります。 はじめにみなさん、docker composeを利用しているでしょうか？ 複数のdockerコンテナをまとめて立ち上げたり、環境変数を定義できたり便利ですよね。 この記事ではある程度docker composeを利用している方向けに私が便利、便利そうと感じたdocker composeの機能を挙げてみました。 docker compose cli v2を利用docker-composeではなく docker composeコマンドも利用可能になっています。 Docker Desktopでは v3.4.0から利用可能で、基本的にはコマンドの互換性あります。 ファイル監視による自動更新docker compose 2.20.0からCompose

はじめに VSCode + Python + Poetry + Docker(docker-compose)でdev-containerを作成して開発を行っていました。 Dockerを勉強し、イメージの軽量化に関する記事を読んでいると、自分が使っているコンテナイメージのサイズが気になりました。 docker images > REPOSITORY TAG IMAGE ID CREATED SIZE > dev-container latest a9b8e3df9087 2.31GB 2.31GB！？ サーバとしてアプリを動かしていないのにここまで大きいなんて… というわけで勉強も兼ねて、イメージの軽量化に取り組みました。 イメージが軽量であるメリット ストレージの節約 これは言わずもがなだと思います。 限られたリソースを有効に使うことができます。 ビルド時間の短縮 Dockerは環境を作っ

エンジニアの岡村です。 自分はサーバーがメインではなく、あまり業務でガッツリ触るわけでもないのですが、最近それなりに活用するようになってきました。しかし、ネット上の日本語情報を読んでいるだけではこれの書き方が正しいのかよく分からない、と悩むことが結構あったため、色々情報を漁ってみました。 この記事は、特に自分が気になった部分の調べた結果を記事に纏めてみたものです。対象読者はdocker-composeを雰囲気でupやdownは叩けるけどComposeファイルの書き方がよく分からんとなってる人です。 Docker Composeの概要とcompose.yaml、Compose Specの関係 compose.yamlの書き方は Compose Specに準拠すればOK Compose Specの場所 推奨のファイル名はcompose.yaml compose.yaml内にバージョンを記述する

初心者むけK8sハンズオンの補助資料です https://qiita.com/minorun365/items/0441e4878f0984a9fc0a

Dockerfileを作る時、最初は以下の方法でやってました。 Dockerfile書く ビルドする（動かしたいアプリ含め） 起動してみる 動かなかったらDockerfile修正する またビルドして試す こんな感じでしたが、これは非常に効率が悪いです。修正して検証を行う度にビルドが発生してしまい、待ちが発生してしまいます。 どうするか？ ベースイメージにアタッチ 動かしたいアプリの実行に必要なコマンドを入れて、成功したらコマンドをメモっていく アプリが動くまで「コマンド実行→成功したらメモ」を繰り返す アプリが動いたらメモったコマンドでDockerfileを作る つまり、いきなりDockerfileを作るのではなく、ベースイメージに入ってコマンドを実行して動作確認をしながらDockerfileに記述する内容を固めていき、最後に1回だけビルドします。 なぜ？ Dockerfileに記述するの

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

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

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

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

------------------------------------------------------ 2024 年 1 月更新 本書がきっかけで「なんとか Docker を使えるようになりたい」というプログラマの方向けの入門書を秀和システム様から出版させていただけることになりました 開発系エンジニアのためのDocker絵とき入門 https://www.amazon.co.jp/dp/4798071501 紙書籍と電子書籍、どちらもございます この書籍と執筆経験は、みなさまからの驚くほどの高評価があればこそ得られた機会でした いつも本当にありがとうございます 書籍化に際しまして、この場で次のとおり説明させていただきます 1️⃣ 本書 ( Zenn ) は有料化しません 2️⃣ 本書 ( Zenn ) は今後更新しません 3️⃣ 本書 ( Zenn ) と出版される絵とき入門の違い

downコマンドの特性としては、upコマンドと真逆のことをするコマンドということになる。つまり、upコマンドで作られうるもの(イメージ、コンテナ、ボリューム、ネットワーク)をすべて削除する。 --rmiオプションは、削除するイメージの種類を指定する。allはすべてのイメージ。localはフィールドにカスタムタグのないイメージのみを削除する。--rmiオプションを省略すると、イメージは消されない。 --volumesオプションは、docker-compose.ymlのvolumesセクションに書かれた名前付きボリュームとコンテナにアタッチされたanonymous volumeが削除される。 --remove-orphansオプションは、docker-compose.ymlで定義から削除されたサービス用の未定義コンテナも削除される。 これら3つのオプションをつけないと、削除されるのはコンテナと

概要 Docker コンテナの原則として「1コンテナ1プロセス」1というものがありますが、あえてこの原則を破りたいときがあるかもしれません。 公式: Run multiple services in a container 有志翻訳: コンテナー内での複数サービス起動 上記ドキュメントのラッパースクリプトを利用する方法には重大な問題があり、本番環境で使用するべきではありません。 (よりによって「本番環境でのアプリ運用」の項目にある) 公式ドキュメントに書かれているのに、死ぬというのはおかしいじゃないか それが罠だという証拠 ちなみに supervisord を利用する方法は問題ありません。 また、コンテナ向けに最適化された s6-overlay2 を利用する方法もあります。 ラッパースクリプトの問題点 プロセスの graceful shutdown が実行されない(プロセスに SIGKIL

Hey, welcome back. This article is part of the Dockerize series, make sure to checkout the Introduction where I go over some concepts we are going to use. Today we'll dockerize our React application by taking advantage of builder pattern with multi stage builds for optimization! I've also made a video, if you'd like to follow along Project setup I've initialized a pretty standard react project usi

業務やプライベートでのハンズオンを通して得た知見を元に、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

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

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

初めて知ったときは感動したけど 自分の中で知ってて当然になってしまった小技をまとめました まだこの小技を知らない人に届いてくれるとうれしい Dockerfile RUNを1つにまとめる