業務やプライベートでのハンズオンを通して得た知見を元にこの記事を作成いたしました。 「Dockerfileのベストプラクティス」というタイトルで強気に出ましたが、場合によっては当てはまらないこともあるかと思います笑。 基本的なことを書いたつもりですが、なにか付け足す点などあればコメントいただければと思います。 軽量なimageをbuildのために 軽量なimageを使用する Dockerfileでimageを指定する際に、軽量なimageを使用することが進めれている。 FROM golang:1.16-alpine AS build 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 size (currently under 5 MB), while still being a full Linux distribution. 注意 軽量なimageを使用するのを基本とするのは良いが、軽量なimageだと入っているもともと入っているバイナリやライブラリが少ない。 そのため大量のライブラリをinstallすることになると逆にbuildに時間がかかってしまう。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編 パッケージダウンロードは逐次処理なので遅く、処理系が入ったイメージのダウンロードの方が高速です。並列で処理されるし、一度イメージをダウンロードしてしまえば、なんどもビルドして試すときに効率が良いです。また、多くのケースでネイティブのライブラリも最初から入っており、ビルドでトラブルに遭遇することはかなり減るでしょう。 そのため、 パッケージのinstallが多く必要な場合はパッケージの確保がされたimageを使用してMulti stage buildをするのが良い。 最近ではdistrolessというshellのないimageを採用する場合もある。 #comment-3d0c9055614ed5b61bea 軽量Dockerイメージに安易にAlpineを使うのはやめたほうがいいという話 使用するimageのpackageのlistをcacheさせない Dokcerfile内でapk updateなどのコマンドでpackageのリストを更新すると、 packageのリストを/var/cache/apk/などにcacheとして残すようになっている。 Alpine Linux package management cacheが残る方法 RUN apk update && apk add \ package-bar \ package-baz \ package-foo=1.3.* このpackageのlistをcacheさせると多少imageが大きくなるので、cacheが残らないようにする cacheが残らない方法 RUN apk add --update-cache --no-cache package-bar \ package-baz \ package-foo=1.3.* Multi stage buildを行う multi stage buildとはimageを複数つくり、片方のimageを、もう片方のimageのディレクトリをCOPYして作成する方法。 imageを2こ作成しているので、FROMが2回出てきている。 Goのimageであるbuildの/bin/projectを、scratchのimageの/bin/projectにCOPYをして使用している。 # syntax=docker/dockerfile:1 FROM golang:1.16-alpine AS build # Install tools required for project # Run `docker build --no-cache .` to update dependencies RUN apk add --no-cache git RUN go get github.com/golang/dep/cmd/dep # List project dependencies with Gopkg.toml and Gopkg.lock # These layers are only re-built when Gopkg files are updated COPY Gopkg.lock Gopkg.toml /go/src/project/ WORKDIR /go/src/project/ # Install library dependencies RUN dep ensure -vendor-only # Copy the entire project and build it # This layer is rebuilt when a file changes in the project directory COPY . /go/src/project/ RUN go build -o /bin/project # This results in a single layer image FROM scratch COPY --from=build /bin/project /bin/project ENTRYPOINT ["/bin/project"] CMD ["--help"] Goのimageを容量がおおきいので、必要なディレクトリをGoのimageで作成して、 軽量なimageのscratchにディレクトリをコピーしている。 つまりmulti stage buildをすることで、使用しないfileやlibraryなどが減り作成されるimageの容量が小さくなる。 docker docsでもmulti stage buildをおすすめしている。 Multi-stage builds allow you to drastically reduce the size of your final image, without struggling to reduce the number of intermediate layers and files. "RUN command1 RUN command2"よりRUN command1 && command2"を使用する dockerfileでimageを作成する際に、できるだけ容量を小さくするようにすることが大事である。 しかしRUNやCOPYやADDという命令はdocker imageのLayerを増やすことになり、最終的にできるimageの容量がおおきくなってしまう。 docker docsにも「Layerを最小限にしよう」と記載されている Minimize the number of layers In older versions of Docker, it was important that you minimized the number of layers in your images to ensure they were performant. The following features were added to reduce this limitation: Only the instructions RUN, COPY, ADD create layers. Other instructions create temporary intermediate images, and do not increase the size of the build. "RUN command1 RUN command2"の場合 コマンドを毎回、RUNで呼び出している場合、最終的にできるimageのサイズは153MBになる RUN npm ci RUN npm cache clean --force RUN mv /app/node_modules /node_modules $ docker build -t run_command1_run_command2 REPOSITORY TAG IMAGE ID CREATED SIZE run_command1_run_command2 latest 2f66932a5335 10 seconds ago 153MB "RUN command1 && command2"の場合 コマンドを&&で数珠つなぎにした場合、最終的にできるimageのサイズは146MBになる RUN npm ci \ && npm cache clean --force \ && mv /app/node_modules /node_modules $ docker build -t run_command1_&&_command2 REPOSITORY TAG IMAGE ID CREATED SIZE run_command1_&&_command2 latest a6627748ccc8 10 seconds ago 146MB つまりRUNを多用すると最終的にできるimageの容量が大きくなってしまうので、できるだけ数珠つなぎで実行するのが良い。 補足 dockerのimageを一度buildすると作成されたLayerはdocker cacheという場所に配置される。 そして再度imageのbuildを行った際に、RUNのcommandの内容が、前回のbuildのRUNのcommandの内容と同じ場合、 前回のimageのbuildで作成されたLayerを使用する。 docker docsにもそのように記載されている After building the image, all layers are in the Docker cache. Docker sees the initial and modified instructions as identical and reuses the cache from previous steps. つまり中間のLayerがあったほうがdocker cacheを利用して、 差分buildを行うことができるので早くbuildのトライアンドエラーができる。 そのため開発環境で最初は開発効率を損なわないようにするために、すべてのステップでRUNでcommandを呼び出し、 build内容が決まってきたら、RUNの回数を減らすために&&を使用するようにするのが良い。 RUN chown && chmodは避けて、COPY --chown=を使用する RUN chown && chmodを使用すると作成されるimageの容量が大きくなるので、 COPY --chown=を使用する。 RUN chown && chmodを使用した場合 RUN chown && chmodでLayerが5.84MB大きくなっている。 COPY . . RUN chown -R node:node /app && \ chmod -R 744 /app && \ chown -R node:node /node_modules && \ chmod -R 777 /node_modules && \ $ docker history run_chown_&&_chmod IMAGE CREATED CREATED BY SIZE COMMENT . . . 4fc46c072028 2 weeks ago /bin/sh -c chown -R node:node /app && ch… 5.84MB COPY --chown=を使用した場合 COPY --chown=node:node . .の場合Layerは474kBしか大きくなっていない。 COPY --chown=node:node . . $ docker history run_chown_&&_chmod IMAGE CREATED CREATED BY SIZE COMMENT . . . 32c46c083921 2 weeks ago /bin/sh -c COPY --chown=node:nodedir:… 474kB COPYを一度に行わず、分けて行う package管理ファイルのcopyとアプリケーションコードのCOPYを分けて行う。 COPY requirements.txt /tmp/ RUN pip install --requirement /tmp/requirements.txt COPY . /tmp/ これにより、特に必要なファイルが変更された場合にのみ各ステップのビルドキャッシュが無効になる。 package管理ファイルは頻繁に変更されることは少ないので、アプリケーションコードのCOPYと分けて行っている。 package管理ファイルが変更されていない場合のbuildではdocker cacheのLayerを使用するためbuildが早くなる。 .dockerigonoreを使用する COPYやADDの対象にしたくないfileを設定する。 .gitigonoreのように、buildに必要ないfileをimageに配置しないようにする。 docker docsでも.dockerigonoreの使用をおすすめしている。 To exclude files not relevant to the build (without restructuring your source repository) use a .dockerignore file. This file supports exclusion patterns similar to .gitignore files. For information on creating one, see the .dockerignore file. 注意 .dockerignoreによるbuildの速度低下が発生することがある。 原因としては、.dockerignoreで、指定するファイルをワイルドカードで指定しすぎてパースに時間がかかってしまうため。 .dockerignore(良くないパターン) # archives *.zip *.lzh *.tar.gz *.tgz *.bz2 *.dmg # OSX .DS_Store #<= 汎用的なものは記載しない .Spotlight-V100 .Trashes .AppleDB .AppleDesktop .apdisk # Rails .rspec log tmp db/*.sqlite3 db/*.sqlite3-journal vendor/assets # Node node_modules .dockerignoreでは最低限のfileの記載、ワイルドカードの多用をしないことを意識する。 .dockerignore(良いパターン) .rspec log tmp db/*.sqlite3 db/*.sqlite3-journal vendor/assets node_modules .dockerignore アンチパターン セキュリティーのために rootユーザーでimageを作成しない dockerfileでUSERの指定を行い、non-rootユーザーの権限を与えるようにする。 USER node USERの指定がないdockerfileから作られたコンテナに入ると、root権限をもつ状態になる。 そのようになった場合万が一コンテナに侵入された場合にroot権限を与えてしまうことになる。 またそのような自体になった場合に、コンテナを載せいているホストにも侵入される可能性も高まるので、コンテナはnon-rootなuserで起動させなければいけない。 Run Docker as a non-root user ADDではなく、基本的にCOPYを使用する ADDはローカルファイルのCOPYに加えて、インターネットに公開されているURLからコード取得できる機能のついている。 docker docs The ADD instruction copies new files, directories or remote file URLs from and adds them to the filesystem of the image at the path . 外部のインターネットにアクセスすると悪意のあるURLからfileを取得しかねないので、基本的にはCOPYを使用する。 参考資料 メイン Best practices for writing Dockerfiles Docker/Kubernetes 実践コンテナ開発入門 米シリコンバレーDevOps監修！超Docker完全入門(2020)【優しい図解説とハンズオンLab付き】 サブ .dockerignore アンチパターン Run Docker as a non-root user 軽量Dockerイメージに安易にAlpineを使うのはやめたほうがいいという話 DockerでRUNをまとめた方が良いとは限らない 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編 仕事でPythonコンテナをデプロイする人向けのDockerfile (2): distroless編

下準備 WSLをインストールする WSLのバージョンを2にアップグレードする Microsoft StoreからDebian系OSをダウンロードし、インストールする Docker Desktopのインストーラをダウンロードし、それを使ってDocker Desktopをインストールする 下準備が終わったら 下準備が終わったらディストリビューションを開きます 1. myappディレクトリを作成して、そこに移動する cd ~ mkdir myapp cd myapp 2. エディタとDockerをインストールする 好みのエディタを使いましょう sudo apt update sudo apt install -y nano docker-compose 3. Dockerfileを作成する まず、Dockerfileを開きます sudo nano Dockerfile 以下のコードをコピペして保存し、終了します FROM ruby:3.0.0 RUN apt-get update && apt-get install -y curl apt-transport-https wget && \ curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - && \ echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list && \ apt-get update && apt-get install -y yarn RUN curl -sL https://deb.nodesource.com/setup_12.x | bash - && \ apt-get install -y nodejs RUN mkdir /myapp WORKDIR /myapp COPY Gemfile /myapp/Gemfile COPY Gemfile.lock /myapp/Gemfile.lock RUN bundle install COPY . /myapp # Add a script to be executed every time the container starts. COPY entrypoint.sh /usr/bin/ RUN chmod +x /usr/bin/entrypoint.sh ENTRYPOINT ["entrypoint.sh"] 4. GemfileとGemfile.lockを作成する まず、Gemfileを開きます sudo nano Gemfile 以下のコードをコピペして保存し、終了します source 'https://rubygems.org' gem 'rails' gem 'mysql2' 次に、空のGemfile.lockを作成します touch Gemfile.lock 5. entrypoint.shを作成する プロセスを管理するためのシェルスクリプトを作成します #!/bin/bash set -e # Remove a potentially pre-existing server.pid for Rails. rm -f /myapp/tmp/pids/server.pid # Then exec the container's main process (what's set as CMD in the Dockerfile). exec "$@" 6. docker-compose.ymlを作成する まず、docker-compose.ymlを開きます sudo nano docker-compose.yml 以下のコードをコピペして保存し、終了します version: "3.7" services: web: build: . container_name: web volumes: - .:/myapp command: rails s -b 0.0.0.0 ports: - "3000:3000" networks: - myapp depends_on: - mysql mysql: image: mysql container_name: mysql command: --default-authentication-plugin=mysql_native_password environment: MYSQL_ROOT_PASSWORD: password ports: - "3306:3306" volumes: - mysql-data:/var/lib/mysql - ./mysql-files:/var/lib/mysql-files networks: - myapp networks: myapp: external: true volumes: mysql-data: 7. mysql-filesディレクトリを作成する mkdir mysql-files 8. Dockerのネットワークを作成する sudo docker network create myapp 9. Railsのプロジェクトを作成する sudo docker-compose run web rails new . -d mysql --skip-bundle --force --no-deps 10. コンテナを作成する sudo docker-compose build 11. DBに接続する際の設定を変更する まず、config/database.ymlを開きます sudo nano config/database.yml 以下のコードで上書きして保存し、終了します default: &default adapter: mysql2 encoding: utf8 pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> host: mysql username: root passowrd: password development: <<: *default database: myapp_development test: <<: *default database: myapp_test production: <<: *default database: myapp_production username: myapp password: <%= ENV['MYAPP_DATABASE_PASSWORD'] %> 12. Webpackerをインストールする sudo docker-compose run web rails webpacker:install 13. DBを作成する sudo docker-compose run web rails db:create 14. RailsとMySQLを起動する sudo docker-compose up Railsが起動した旨のメッセージが表示されたら、ブラウザでlocalhost:3000にアクセスします ここまでの手順が上手くいっていれば、Yay! You're on Rails!という言葉が表示されます その言葉が表示されれば、Dockerを使ったRailsの環境構築は終了です、お疲れ様でした！

こんにちは、まゆみです。 Dockerについての記事をシリーズで書いています 前回の記事では、簡単なWebアプリを作りつつWORKDIR とCOPYについて解説させていただきました。 ただ、ディフォルトのままでは、 あなたのローカルホスト(パソコン)からは、Container の方に関連付けられていません。 今回の記事では、ローカルホストとContainerのポートをつなぐ(publishという)にはどうしたらいいのかということについて書いていこうと思います ではさっそく始めていきますね。(前回の記事からの続きの内容になります。) 『-p』を使ってポートマッピングする ローカルホストのポート番号も、Container のポート番号も8080なので(Docker hostのデフォルトのポート番号は8080になります) 引用元：docker docs docker run -p 8080:8080 <imageID> を実行してみます 今回の記事で分かった事 では、今回の記事で分かった事をまとめておきます Dockerから『外の世界に対して』アクセスするには制限はない(Dockerfileを作るさい、『RUN npm install』と書いて、外の世界にアクセスして、npm をインストールしていますが問題なくできています) Dockerの『中に』アクセスする場合は、デフォルトのままではアクセスできない Containerの中にアクセスするには『-p』を使って、ローカルホストとContainerのポートをつなぐ必要がある

docker build時、pip installの際に no space left によるエラーが発生していた。 コンテナに入り、ボリュームを確認した際、overlayおよび/dev/vda1のAvailが0になっていた（下記は解消後のボリューム）。 $ df -h Filesystem Size Used Avail Use% Mounted on overlay 59G 5.3G 51G 10% / tmpfs 64M 0 64M 0% /dev tmpfs 2.5G 0 2.5G 0% /sys/fs/cgroup grpcfuse 234G 109G 95G 54% /workspace /dev/vda1 59G 5.3G 51G 10% /etc/hosts shm 2.5G 0 2.5G 0% /dev/shm tmpfs 2.5G 0 2.5G 0% /proc/acpi tmpfs 2.5G 0 2.5G 0% /sys/firmware 色々と原因を探ってみたが、結果的にはdockerのキャッシュファイルによる圧迫であった。 下記は解消後の確認結果だが、Build Cacheによって容量が圧迫されていた。 $ docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 1 0 3.526GB 3.526GB (100%) Containers 0 0 0B 0B Local Volumes 2 0 240.6MB 240.6MB (100%) Build Cache 36 0 3.324kB 3.324kB 下記コマンドにより、キャッシュ削除することにより対応。 $ docker builder prune

こんにちは、まゆみです。 Dockerについての記事をシリーズで書いています。 今回の記事では、 DockerのWORKDIR COPY に焦点を置いて書いていこうと思います では、さっそく始めていきますね。 今回の記事の注意点 今回は『あえて』エラーを出すようにコードを書き、そのエラーを解消するにはどうしたら良いのか？を説明することで、Docker のCOPY とWORKDIRの役割について解説していきます。 なので、コードを実行してエラーが出た時も、続けて記事を読んでエラーを解決しつつ、COPYとWORKDIRの役割について理解してくだされば嬉しいです。 Dockerfile の他に２つファイルをビルドコンテキストに作る まず、build context (ビルドコンテキスト=Dockerfile が格納されているディレクトリ―のこと)に、『package.json』『index.js』『Dockerfile』の3つのファイルを用意します。 下記のイラストのような状態を作ってください。 Dockerfile、index.js、package.json の中身はそれぞれ下記のようになります。(コードの中身の詳しい説明はここでは割愛させていただきます) Dockerfile index.js package.json Dockerfile からImageを作る では、いまあなたがいるディレクトリー内に、先ほど作った３つのファイルがちゃんとあることを確かめてから docker build . を実行してみましょう すると、下記のようなエラーが出ました。 step 2(RUN npm install)を実行する中でエラーが出ています エラーの原因はその前プロセスの、ベースのイメージの選択にありそうです。 alpine はわずか、5Mであり、それゆえあなたがどのようにそのベースイメージを使いたいのかによっては必要なプログラムが入っていない場合も多いのです。 このエラーを修正するにはいくつかの方法が考えられると思いますが、今回はnode やNPM がプリインストールされているイメージを選びなおしてみましょう nodeのImage をベースイメージとして使う Docker hubにアクセスして、ベースイメージを選びなおします。 検索バーにnodeと入れてみましょう ある特定のイメージの中にも、それぞれ様々なバージョンがありまして、イメージのバージョンを指定したい時は、 Repository名：version と:(コロン)以下にversion名を書きます。 無駄をそぎ落として必要な物だけを入れたイメージは『alpine』とバージョン名が付けられています。 FROM node:alpine はalpine のイメージを使っているのではなく、 『node イメージの中のミニマルなバージョンの物を使っていますよ』という意味になります では、Dockerfile のベースイメージを書き換えたところで、再度 docker build . をしてみましょう すると次は、下記のようなエラーが出ました。 エラーの原因を調べてみると、stackoverflowで次のような解決策が見つかりました。 解答は下のスクショになります どうやら、node.jsのバージョンが15になってから、このようなエラーが出始めたようです。 赤線の引いてあるところを翻訳すると WORKDIRを特に指定しない時、Containerのルートにて、npmのインストールが実行されます では、stackoverflowに載っているコードの例を参考に、Dockerfileを再度書き換え、もう一度buildし直してみます。 すると、実行結果は下のようになりました。 Successfully built と表示され、Imageが作られたようなので、 docker run -it <Image ID> sh で、そのImageからContainerを作り、Container 内でターミナルを開いてみます。 そしてディレクトリーにどんなファイルがあるのか見てみました。 するとContainer の中には、『index.js』がなく、Containerはindex.jsファイルなしで作られたことが分かります。 また、package.json の中身も何も入っていません。 なぜ、Dockerfile 以外の2つのファイルがContainer のなかに存在しないのか、次に書いていきますね。 docker build .する時に起こっていること 前回の記事で、『docker build .』する時に起こっていることを詳しく解説させていただきました。 今回、node:alpine イメージをベースのイメージとして使うためにDockerfileの最初にFROM node:alpine と書きました。 ただ、その段階で作られる『一時的なContainer』は、node:alpine イメージのみから作られるもので、あなたが書いた package.json indes.js を無視してContainerが作られます。 そこでもし、Containerを作る時、一緒に使いたいファイルがbuild context 内にあるのなら、その旨が分かるような指示を出さなければいけません。 その時に使うのが COPY <コピーしたいファイルまでのパス> <Containerのどこにコピーしたいか> になります COPYの役割は あなたのローカルファイルシステムから、一時的に作られるContainer内のファイルシステムへ、複製したファイルやフォルダーを持っていくこと です。 では、下のようにDockerfile を書き換えて再度buildしてみます Successfully built ... と表示されたので、Image IDをコピーして、Containerを起動させてみました。 成功しているようですが、localhost:8080にアクセスしてみましょう なにが問題だったのでしょうか？ まとめ 今回の記事はここで締めくくらせていただきます。 次回の記事は、今回の記事で疑問を残している localhostでアクセスできなかった原因 について書いていきます

はじめに 以前書いた funannotateを遺伝研スパコンで動かす という記事の続きです. condaでインストールするとめちゃくちゃ面倒だったので、DockerHubで配布されているdockerイメージをsingularityイメージに変換して、遺伝研スパコンで使えるかどうか試してみました. Singularityを使うメリットとデメリット メリット インストールが楽 $HOMEを自動でマウントしてくれる ヘルプメッセージを確認する程度ならインタラクティブノード（qloginで入れるノード）で実行可能 最新版をcatch upできる デメリット 作者さんのGitHubで配布されているfunannotate-dockerという簡単実行スクリプトが（そのままでは）使えない やりかた ゲートウェイノードにログインしてから, $ qlogin -l mem_req=20G,s_vmem=20G # memoryを多めにしてqlogin $ cd /your/tools/dir/ # 任意のディレクトリに移動 # dockerイメージをsingularityイメージに変換 $ singularity build funannotate.sif docker://nextgenusfs/funannotate INFO: Starting build... (途中略) INFO: Creating SIF file... INFO: Build complete: funannotate.sif funannotate testコマンドで実行テストをします. #$で始まる行はスパコンの計算ノードに投入するためのコマンドです. test_funannotate.sh #$ -S /bin/bash #$ -pe def_slot 10 #$ -cwd #$ -l medium #$ -l mem_req=15G,s_vmem=15G #$ -l d_rt=192:00:00 #$ -l s_rt=192:00:00 singularity exec /your/tools/path/funannotate-1.8.7.sif funannotate test \ -t predict \ --cpus 10 10 core, メモリ合計150GB確保して投入しました. なお, 80GBでは途中でコアダンプしました. 20分くらいで終了します. 標準出力ログに以下が出力されていれば, たぶん本番データでも動くんじゃないかな... (本番データではまだ試していないので,うまく動けば追記します) ######################################################### SUCCESS: `funannotate predict` test complete. ######################################################### ちなみに,このテストコマンドでpredictされるゲノム配列の大きさは約3Mでした. Saccharomyces属のゲノムの一部だけを取り出しているようです. 小さめの真核生物ゲノム（~500MBくらい？)だとストレスなく動くと思います. 余談 実行テストにfunannotateのデフォルトではなく, SARS-CoV2ゲノムを使おうとして撃沈. 0 valid BUSCO predictions found, validating protein sequences こんなエラーメッセージが出てきました.　まあそうだよね, 真核生物じゃないもの. E.coliでテストしてみるつもり.

はじめに Docker上でReactとTypeScriptと使って開発をしている時に、ファイル保存時に自動的にブラウザに反映(hot reload)されなくなったので、その解決策をここに備忘録として書き残します。 開発環境 Windows10 Docker for windows React 17.0.2 TypeScript 4.3.2 解決策 create-react-app/Trouble shootingに書かれている通りに、.envファイルを作成し、polling modeをtrueと記述しました。が直りませんでした。おそらくDockerに何かありそうです。 If the project runs inside a virtual machine such as (a Vagrant provisioned) >VirtualBox, create an .env file in your project directory if it doesn’t exist, and >add CHOKIDAR_USEPOLLING=true to it. This ensures that the next time you run npm >start, the watcher uses the polling mode, as necessary inside a VM. React-create-app/Trouble shooting Dockerにも追加 docker-compose.ymlに.envと同様の記述しました。そしたら、ちゃんとhot relodeが効くようになりました。 docker-compose.yml environment: - CHOKIDAR_USEPOLLING=true あとがき 普段macで開発をしているので、windowsで何かあるとwindowsのせいにすることをやめようと思います。しっかりと問題の本質を見極める必要がありそうですね。