収録問題 50問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
開発中のNode.jsアプリで、依存関係のインストール結果をイメージに固定しつつ、ソース変更時の再ビルドを速くしたい。Dockerfileで先にコピーするべきものはどれですか？
答え：package.json とロックファイル
依存関係定義だけを先にコピーしてインストールすると、そのレイヤーをキャッシュしやすくなります。ソース変更だけなら依存関係の再インストールを避けやすくなります。
開発環境でホスト上のソース変更をすぐコンテナに反映したい。最も自然な方法はどれですか？
答え：バインドマウントでソースディレクトリをマウントする
バインドマウントはホストのファイルをコンテナへ直接見せられるため、ローカル開発でよく使います。
開発用Composeで、アプリの待受ポート3000をホストの3000番から確認したい。設定として適切なのはどれですか？
答え：ports: ["3000:3000"]
ports はホスト側ポートとコンテナ側ポートの公開に使います。3000:3000 はホスト3000からコンテナ3000へ転送します。
コンテナ内でアプリがlocalhostに接続しても、ホスト側DBへつながらない。理由として最も適切なのはどれですか？
答え：コンテナ内のlocalhostはコンテナ自身を指すため
コンテナは独自のネットワーク名前空間を持つため、コンテナ内のlocalhostはホストではなくコンテナ自身です。
開発用と本番用で起動コマンドやマウントだけを変えたい。Composeで分ける方法として適切なのはどれですか？
答え：ベースComposeに開発用overrideファイルを重ねる
Composeは複数ファイルをマージできます。共通定義を保ち、開発固有のマウントやコマンドだけをoverrideする形が扱いやすいです。
コンテナ内で作った依存キャッシュをビルド間で再利用し、最終イメージには含めたくない。BuildKitで適切なのはどれですか？
答え：RUN --mount=type=cache
BuildKitのcache mountは、パッケージマネージャのキャッシュなどをビルド間で再利用しつつ、イメージレイヤーには直接含めない用途に向きます。
ホットリロード用の開発コンテナで、依存関係ディレクトリだけはコンテナ側のものを使いたい。よく使う構成はどれですか？
答え：ソースをバインドマウントし、依存ディレクトリは名前付きボリュームで分離する
ホストのソースを見せつつ、node_modulesなどOS差が出やすい依存ディレクトリは名前付きボリュームでコンテナ内管理にする構成があります。
開発チームでDockerfileを共有するとき、OSパッケージのインストールを安定させる観点で避けたい書き方はどれですか？
答え：apt-get upgrade -y を通常のアプリイメージビルドに入れる
アプリ用イメージでは必要パッケージを絞って入れるのが基本です。広範なupgradeはビルド結果の予測を難しくし、ベースイメージ管理との責務も曖昧になります。
コンテナ内アプリの設定値を開発環境ごとに変えたいが、イメージは共通にしたい。適切なのはどれですか？
答え：環境変数や外部設定として実行時に渡す
設定はイメージに固定しすぎず、環境変数や設定ファイル、Secret管理などで実行時に注入すると、同じイメージを複数環境で使いやすくなります。
ローカル開発で複数サービスをまとめて起動し、サービス名で通信したい。最も向いているものはどれですか？
答え：Docker Compose
Composeは複数コンテナのサービス、ネットワーク、ボリューム、環境変数などをファイルで定義して一括起動できます。
ローカルにあるイメージ一覧を確認したい。使うコマンドはどれですか？
答え：docker image ls
docker image ls はローカルのイメージ一覧を表示します。タグ、イメージID、サイズなどを確認できます。
バックグラウンドでコンテナを起動し、不要になったら停止時に自動削除したい。適切な組み合わせはどれですか？
答え：docker run -d --rm ...
-d はデタッチ実行、--rm は停止後のコンテナ自動削除です。一時的な検証用コンテナで便利です。
停止中も含めてコンテナ一覧を確認したい。適切なコマンドはどれですか？
答え：docker ps -a
docker ps は実行中コンテナ一覧、-a を付けると停止済みを含めた一覧になります。
稼働中コンテナの標準出力ログを追いかけながら確認したい。使うコマンドはどれですか？
答え：docker logs -f <container>
docker logs -f はコンテナのログを追跡表示します。アプリログを標準出力へ出す設計と相性がよいです。
稼働中コンテナの中で一時的にシェルを開いて調査したい。適切なのはどれですか？
答え：docker exec -it <container> sh
docker exec は稼働中コンテナ内で追加コマンドを実行します。-it を付けると対話的なシェル調査に使えます。
Dockerfileからmyapp:devという名前でイメージを作りたい。適切なコマンドはどれですか？
答え：docker build -t myapp:dev .
docker build -t 名前:タグ ビルドコンテキスト でDockerfileからイメージをビルドし、タグを付けます。
未使用の停止コンテナ、ネットワーク、danglingイメージ、ビルドキャッシュをまとめて掃除したい。候補として適切なのはどれですか？
答え：docker system prune
docker system prune は未使用リソースの整理に使います。削除対象を確認し、必要なボリュームやイメージを消さないよう注意します。
Composeで定義したサービスをバックグラウンド起動したい。適切なのはどれですか？
答え：docker compose up -d
docker compose up -d はComposeサービスを作成・起動し、デタッチ状態で実行します。
コンテナやイメージの詳細なJSONメタデータを確認したい。使うコマンドはどれですか？
答え：docker inspect
docker inspect はIPアドレス、マウント、環境変数、設定などの詳細メタデータをJSONで確認できます。
コンテナからホストへ設定ファイルを取り出したい。適切なコマンドはどれですか？
答え：docker cp <container>:/path/file ./file
docker cp はホストとコンテナ間のファイルコピーに使います。調査時の設定ファイル取得などに便利です。
本番用イメージを小さくし、ビルド用ツールを含めない設計として最も適切なのはどれですか？
答え：マルチステージビルドでビルド成果物だけを最終ステージへコピーする
マルチステージビルドでは、ビルド用ステージと実行用ステージを分け、最終イメージに必要な成果物だけを含められます。
コンテナイメージ設計で、1つのコンテナに複数の独立した長時間プロセスを詰め込みすぎない主な理由はどれですか？
答え：監視、再起動、スケール、ログ分離が難しくなるため
コンテナは責務を絞ると運用しやすくなります。複数責務を入れすぎると障害切り分けやスケール単位が曖昧になります。
本番で同じイメージを確実に再利用したい。タグ設計としてより安全なのはどれですか？
答え：バージョンタグやイメージダイジェストをデプロイに使う
可変なlatestだけに頼ると、同じ指定でも別内容になる可能性があります。バージョンタグやダイジェストを使うと追跡しやすくなります。
DockerfileでCOPY . .する前に.dockerignoreを整える主な目的はどれですか？
答え：不要・機密ファイルをビルドコンテキストから除外するため
.dockerignore はビルドコンテキストへ送るファイルを減らし、秘密情報や不要な巨大ファイルの混入を防ぎます。
コンテナのデータ永続化設計で、DBデータをコンテナの書き込みレイヤーだけに置くのを避ける理由はどれですか？
答え：コンテナ削除や再作成でデータを失いやすいため
コンテナの書き込みレイヤーはコンテナ寿命に強く依存します。DBデータはボリュームや外部DBなどで永続化する設計が基本です。
Webアプリイメージ設計で、EXPOSE 8080 の意味として正しいものはどれですか？
答え：コンテナが8080番で待ち受ける意図をメタデータとして示す
EXPOSE は公開意図のメタデータであり、ホスト公開にはdocker run -pやComposeのportsなどが必要です。
アプリ設定をDockerfileのARGだけで本番実行時に切り替えようとして失敗した。理由として適切なのはどれですか？
答え：ARGは主にビルド時変数で、実行時設定にはENVや外部注入を使うため
ARGはビルド中の値として扱うのが基本です。実行時に変えたい値は環境変数、設定ファイル、Secret管理などで渡します。
イメージレイヤー設計で、頻繁に変わるファイルをDockerfileの後半でコピーする利点はどれですか？
答え：前半の安定したレイヤーキャッシュを再利用しやすくなる
Dockerfileは命令順にキャッシュが効きます。変化しにくい依存関係処理を前に、変化しやすいソースコピーを後ろに置くと効率的です。
本番コンテナでアプリログをファイルだけに書く設計より、標準出力へ出す設計が好まれやすい理由はどれですか？
答え：コンテナランタイムやログ基盤が収集しやすいため
コンテナのログは標準出力・標準エラーへ出すと、Dockerやクラウドのログ収集と連携しやすくなります。
イメージにビルド時の秘密情報を残さない設計として適切なのはどれですか？
答え：BuildKitのsecret mountなど、レイヤーに残しにくい仕組みを使う
DockerfileのENVやCOPYで秘密情報を扱うとレイヤー履歴などに残る危険があります。BuildKit secret mountなどを使うと露出を減らせます。
本番でコンテナが異常終了したとき自動再起動したい。単体Docker実行で使う設定として適切なのはどれですか？
答え：--restart=unless-stopped などの再起動ポリシー
再起動ポリシーはDockerデーモンがコンテナ終了時の扱いを判断するための設定です。--rmとは併用目的が異なります。
コンテナのCPUやメモリ使用量をリアルタイムに確認したい。適切なコマンドはどれですか？
答え：docker stats
docker stats はコンテナごとのCPU、メモリ、ネットワーク、ブロックI/Oなどを表示します。
本番運用でコンテナの状態を外部監視から判断しやすくしたい。イメージ側に用意するとよいものはどれですか？
答え：HEALTHCHECK または監視しやすいヘルスエンドポイント
ヘルスチェックはプロセス生存だけでなく、アプリとして正常に応答できるかを判断する材料になります。
運用中コンテナの設定やマウント、ネットワークを後から調べたい。最初に使いやすいコマンドはどれですか？
答え：docker inspect <container>
docker inspect はコンテナの詳細情報をJSONで返すため、マウントやネットワーク、環境変数の確認に向いています。
ホストのディスク容量が逼迫し、Dockerの使用量内訳を確認したい。使うコマンドはどれですか？
答え：docker system df
docker system df はイメージ、コンテナ、ボリューム、ビルドキャッシュの使用量概要を確認できます。
本番に近い検証で、コンテナにメモリ上限を設定したい。単体Docker実行で使う代表的な指定はどれですか？
答え：docker run --memory 512m ...
--memory はコンテナのメモリ使用量に上限を設定する代表的なオプションです。
本番障害時、コンテナ内へ入って手で直す対応が根本対策になりにくい理由はどれですか？
答え：変更が再現されず、再作成や再デプロイで失われるため
コンテナは再作成される前提で扱います。修正はDockerfile、設定、デプロイ定義へ反映して再現可能にするのが基本です。
Composeサービスのログをサービス横断で確認したい。適切なコマンドはどれですか？
答え：docker compose logs
docker compose logs はComposeプロジェクト内サービスのログ確認に使います。-fで追跡表示もできます。
イメージを別環境へファイルとして渡したいが、レジストリは使えない。適切な組み合わせはどれですか？
答え：docker save と docker load
docker save はイメージをtarに保存し、docker load はそれを読み込みます。タグやレイヤーを保った移送に使います。
運用で不要リソースを削除する前に、特に注意すべきものはどれですか？
答え：名前付きボリュームに必要な永続データが残っていないか
ボリュームにはDBやアップロードファイルなど重要データが入ることがあります。削除前に用途とバックアップを確認します。
Dockerfileでアプリをrootユーザーのまま実行しないために使う代表的な命令はどれですか？
答え：USER
USER は以降の命令や実行時プロセスのユーザーを指定します。非root実行は権限を絞る基本対策です。
ビルド時にプライベートリポジトリへアクセスする秘密鍵を使いたいが、イメージには残したくない。適切なのはどれですか？
答え：BuildKitのSSH mountやsecret mountを使う
BuildKitのSSH/secret mountは、ビルド中だけ秘密情報を参照し、レイヤーに残すリスクを下げるために使います。
イメージの脆弱性リスクを下げるため、ベースイメージ選定で特に意識することはどれですか？
答え：必要最小限で、更新されている信頼できるベースを使う
小さく保守されている信頼元のベースは、不要パッケージや既知脆弱性の混入を減らしやすくなります。
コンテナへホストのDockerソケット/var/run/docker.sockをマウントする場合の主なリスクはどれですか？
答え：コンテナからホスト上のDockerを強力に操作できる可能性がある
DockerソケットはホストDockerデーモンへの操作口です。マウントするとコンテナ脱出に近い強い権限につながるため慎重に扱います。
コンテナに不要なLinux capabilityを与えない目的として適切なのはどれですか？
答え：侵害時に使える権限を減らすため
capabilityはroot権限の一部を細分化したものです。不要なものを落とすと、侵害時の被害範囲を狭めやすくなります。
コンテナのファイルシステム改ざんリスクを下げたい。実行時設定として候補になるものはどれですか？
答え：--read-only
--read-only はコンテナのルートファイルシステムを読み取り専用にします。書き込みが必要な場所はtmpfsやボリュームで明示します。
DockerイメージをCIで扱う際、脆弱性確認として追加したい工程はどれですか？
答え：イメージスキャンを実行し、重大度に応じてリリース判定する
CIでイメージスキャンを行うと、ベースイメージや依存パッケージの既知脆弱性をリリース前に検出しやすくなります。
コンテナに機密情報を渡す設計で避けたいものはどれですか？
答え：秘密情報をDockerfileへ直接書く
Dockerfileへ秘密情報を書くと、イメージ履歴やレジストリ経由で漏れる危険があります。実行時のSecret管理を使うのが基本です。
本番コンテナに--privilegedを安易に付けるべきでない理由はどれですか？
答え：ホストに近い強い権限を与え、隔離を弱めるため
--privileged は多くの権限やデバイスアクセスを与えます。必要なcapabilityやデバイスだけを個別に許可する設計を検討します。
Docker Engine自体をroot権限なしで動かし、デーモン侵害時の影響を抑える選択肢として知られるものはどれですか？
答え：Rootless mode
Rootless modeはDockerデーモンとコンテナを非rootユーザーで動かす選択肢です。制約もあるため要件に合わせて検討します。