Category: docker

docker

リファレンス  オフィシャル Dockerfile の見直す時に参考にする場所 Dockerfile のベストプラクティス その 1 ) 下記以外にもあるが私が忘れやすいポイントだけ .dockerignore ファイルを使う レイヤの数を最小に 複数行の引数 <= 引数はアルファベット順に 構築キャッシュ <= docker build で –no-cache=true とすると既存キャッシュを使わない CMD <= 常に CMD [“executable”, “param1”, “param2”…] のような形式で使うべきです。 WORKDIR <= 明確さと信頼性のため、常に WORKDIR からの絶対パスを使うべきです。 Distroless が使えないか検討する その 2 LABEL <= ロジェクト内でのイメージ管理をしやすくしたり、ライセンス情報の記録や自動化の助けとするなど、さまざまな目的があります。 参考 マルチステージビルドの利用 現実に効果的な Dockerfile を書くためには、 いつもながらトリッキーなシェルのテクニックや、 レイヤーができる限り小さくなるようなロジックを考えたりすることが必要でした。 つまり各レイヤーは、それ以前のレイヤーから受け継ぐべき生成物のみを持ち、 他のものは一切持たないようにすることが必要であったわけです。 本来 2 つあるRUNコマンドを Bash の&&オペレーターによって連結しています。 これを行うことで、イメージ内に不要なレイヤーが生成されることを防いでいます。 ただこれでは間違いを起こしやすく、保守もやりづらくなります。 保守がやりづらくなる、という認識は docker にもあるようだ。 Read more...

docker-compose

ログ設定 2021/07/26 ログ設定をしないと起動時からのログを全て保存するので、サイズ設定を行う。 選べる出力先(driver)は json-file, syslog, awslogs, gcplogs などが選択可能 デフォルトは json-file。 ロギングドライバーのオプション json-file でサイズを設定した services: server: logging: driver: json-file options: max-file: '1' max-size: 3m syslog EC2 上で docker-compose で起動するようなケース logging: driver: syslog options: syslog-facility: daemon tag: redash/{{.Name}}/{{.ID}} 下記のような出力になる Jul 26 08:10:07 ip-172-30-1-46 redash/redash_scheduler_1/e4dbe49ee058[1067]: [2021-07-26 08:10:07,916][PID:19][INFO][ForkPoolWorker-2] task_name=redash.tasks.refresh_queries task_id=aecf0215-9884-4254-82d2-1d08f8eb58f9 Refreshing queries... Jul 26 08:10:07 ip-172-30-1-46 redash/redash_scheduler_1/e4dbe49ee058[1067]: [2021-07-26 08:10:07,986][PID:19][INFO][ForkPoolWorker-2] task_name=redash.tasks.refresh_queries task_id=aecf0215-9884-4254-82d2-1d08f8eb58f9 Done refreshing queries. Found 0 outdated queries: [] Jul 26 08:10:07 ip-172-30-1-46 redash/redash_scheduler_1/e4dbe49ee058[1067]: [2021-07-26 08:10:07,998][PID:19][INFO][ForkPoolWorker-2] Task redash. Read more...

docker-compose/セキュリティ関連

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. Read more...