Posted:
| Categories:
docker
| Tags:
docker,
Dockerfile,
Ubuntu
前提
cli-tool-docker は日常作業用の CLI をまとめたコンテナなので、単純なアプリ実行用イメージより大きくなる。
ただし Dockerfile の構造上、builder から成果物以外をコピーしてしまうと、マルチステージビルドの利点を失いやすい。
調査対象は Ubuntu 26.04 版のローカルビルド。
docker build --progress=plain -t cli-tool-docker:ubuntu-26.04-test .
実測値
削減前:
content size: 4.58GB
Docker 29 local disk usage: 18.1GB
削減後:
image id: 83cff82c6680
inspect Size: 2921887630 bytes
rootfs layer count: 30
content size: 2.92GB
Docker 29 local disk usage: 11.9GB
低リスクな layer 数削減後:
image id: d5d9b0068ed3
rootfs layer count: 25
Docker 29 local disk usage: 11.9GB
artifacts stage 集約後:
Read more...Posted:
| Categories:
docker
| Tags:
docker,
network
Rancher Desktopのネットワーク確認コマンド:
1. 基本的なネットワーク確認
Docker context確認(現在defaultを使用)
docker context ls
NAME DESCRIPTION DOCKER ENDPOINT ERROR
default * Current DOCKER_HOST based configuration unix:///var/run/docker.sock
rancher-desktop Rancher Desktop moby context unix:///Users/<username>/.rd/docker.sock
macOSの場合は unix:///Users/<username>/.rd/docker.sock になる。
Rancher Desktopコンテキストに切り替え
docker context use rancher-desktop
ネットワーク一覧
2. Rancher Desktop特有のネットワーク情報
IPルーティング確認(rd0, rd1がRancher Desktop関連)
# Linux (Rancher DesktopのVM内で実行)
ip route show
ネットワークインターフェース確認
# Linux (Rancher DesktopのVM内で実行)
ip addr show
Rancher Desktopのネットワーク詳細
docker network inspect bridge
3. Lima VM情報(Rancher DesktopがLimaを使用している場合)
Lima VM一覧(利用可能な場合)
Lima VM内からの確認(例: lima0の場合)
limactl shell lima0 -- nerdctl network ls
確認する事項としては:
Read more...Posted:
| Categories:
docker
| Tags:
docker,
Dockerfile
リファレンス
オフィシャル
Dockerfile の見直す時に参考にする場所
Dockerfile のベストプラクティス
その 1
)
下記以外にもあるが私が忘れやすいポイントだけ
- .dockerignore ファイルを使う
- レイヤの数を最小に
- 複数行の引数 <= 引数はアルファベット順に
- 構築キャッシュ <= docker build で –no-cache=true とすると既存キャッシュを使わない
- CMD <= 常に CMD [“executable”, “param1”, “param2”…] のような形式で使うべきです。
- WORKDIR <= 明確さと信頼性のため、常に WORKDIR からの絶対パスを使うべきです。
- Distroless が使えないか検討する
その 2
- LABEL <= ロジェクト内でのイメージ管理をしやすくしたり、ライセンス情報の記録や自動化の助けとするなど、さまざまな目的があります。
レイヤー削減の考え方
Dockerfile の layer を減らす時は、単純に RUN や COPY を結合すればよい、という話ではない。
layer 数を減らすと見た目はきれいになるが、巨大な layer にまとまると push/pull 時の差分再利用や、docker history での原因調査が悪くなることがある。
特に日常利用の CLI image のように、apt package、language runtime、npm global tool、クラウド CLI などを大量に含む image では、layer 数と image size は別の問題として扱う。
Read more...Posted:
| Categories:
docker
| Tags:
docker,
security
Privileged(特権)ではない方法で、必要な分だけセキュリティを緩める
背景
Privileged(特権)を持った Docker コンテナは root 権限を備えたコンテナであり、
2021 年の Docker では Linux のセキュリティコンピューティングモード(secure computing mode; seccomp)と呼ばれる機構で制限がかけられている。
現在は 300 以上あるシステムコールのうち 44 が制限されている。
どのように制限をかけるか簡単に確認してみた。
環境
docker-compose の実行は Ubuntu Studio 21.04
コンテナは gentoo/stage3-amd64
docker-compose.yml に追加
- 制限する profile.json の雛形をダウンロード
- 雛形を修正
- docker-compose.yml 修正
- docker-compose を起動し直し
手順
wget https://raw.githubusercontent.com/moby/moby/master/profiles/seccomp/default.json
default.json を確認する。このリストはホワイトリストで、このリストに含まれていない場合、ブロックされる。
つまり「何か権限が足りない場合」、「このリストに追加」したい。
ただ 2021/08/04 に確認した所、 CAP_SYS_PTRACE に process_vm_readv は追加されていたので、
一旦、修正は加えず、 profile.json を持ちいて起動するように docker-compose.yml を修正して起動する。
docker-compose の修正
version: "3"
services:
distcc:
build:
context: ./
container_name: 'distcc'
security_opt: # <= security_opt を追加
- seccomp:default.json # <= docker-compose.ymlと同じディレクトリにjsonファイルを置いた
command: >
bash -c "/bin/bash"
volumes:
- ./make.conf:/etc/portage/make.conf
発生していたエラー
/var/tmp/portage/sys-libs/glibc-2.33-r1/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/sln /var/tmp/portage/sys-libs/glibc-2.33-r1/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/symlink.list
* /var/tmp/portage/sys-apps/sandbox-2.18/work/sandbox-2.18/libsandbox/trace.c:do_peekstr():134: failure (Operation not permitted):
* ISE:do_peekstr:process_vm_readv(104259, 0x00007ffe29debd20{0x00007fd68a110010, 0x535}, 1, 0x00007ffe29debd30{0x00000000ff9a1acb, 0x535}, 1, 0) failed: Operation not permitted
/bin/sh: line 1: 89178 Aborted make -r PARALLELMFLAGS="" -C /var/tmp/portage/sys-libs/glibc-2.33-r1/work/glibc-2.33 objdir=`pwd` install
↑ この ↓ の部分が気になる
Read more...