diff --git a/README.md b/README.md index beb4a1cec..5fe713268 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ http://docs.docker.jp -Here is a translated documents of Docker Version v23.0. +Here is a translated documents of Docker Version v24.0. Original (English) version is here; https://docs.docker.com/ # Pull Request について diff --git a/assets/images/architecture.png b/assets/images/architecture.png new file mode 100644 index 000000000..294b2b9ba Binary files /dev/null and b/assets/images/architecture.png differ diff --git a/assets/images/arrow-up.png b/assets/images/arrow-up.png new file mode 100644 index 000000000..c3ad6e21b Binary files /dev/null and b/assets/images/arrow-up.png differ diff --git a/assets/images/build-frontends.png b/assets/images/build-frontends.png new file mode 100644 index 000000000..f25a3f753 Binary files /dev/null and b/assets/images/build-frontends.png differ diff --git a/assets/images/build-multi-platform.png b/assets/images/build-multi-platform.png new file mode 100644 index 000000000..c50209c1f Binary files /dev/null and b/assets/images/build-multi-platform.png differ diff --git a/assets/images/help.png b/assets/images/help.png new file mode 100644 index 000000000..4efa5dfc8 Binary files /dev/null and b/assets/images/help.png differ diff --git a/develop/develop-images/baseimages.rst b/build/building/base-images.rst similarity index 100% rename from develop/develop-images/baseimages.rst rename to build/building/base-images.rst diff --git a/develop/develop-images/multistage-build.rst b/build/building/multi-stage.rst similarity index 100% rename from develop/develop-images/multistage-build.rst rename to build/building/multi-stage.rst diff --git a/build/guide/images/cache-bust.png b/build/guide/images/cache-bust.png new file mode 100644 index 000000000..b3cd38e4f Binary files /dev/null and b/build/guide/images/cache-bust.png differ diff --git a/build/guide/images/layers.png b/build/guide/images/layers.png new file mode 100644 index 000000000..7ee997343 Binary files /dev/null and b/build/guide/images/layers.png differ diff --git a/build/guide/images/parallelism.gif b/build/guide/images/parallelism.gif new file mode 100644 index 000000000..fef29596b Binary files /dev/null and b/build/guide/images/parallelism.gif differ diff --git a/build/guide/images/reordered-layers.png b/build/guide/images/reordered-layers.png new file mode 100644 index 000000000..1b4e36dff Binary files /dev/null and b/build/guide/images/reordered-layers.png differ diff --git a/build/guide/index.rst b/build/guide/index.rst new file mode 100644 index 000000000..d18b8e5df --- /dev/null +++ b/build/guide/index.rst @@ -0,0 +1,72 @@ +.. -*- coding: utf-8 -*- +.. URL: https://docs.docker.com/build/guide/ + doc version: 24.0 + https://github.com/docker/docs/blob/main/build/guide/index.md +.. check date: 2023/07/25 +.. Commits on Apr 25, 2023 da6586c498f34c0edac3171a48468a0f26aa0182 +.. ----------------------------------------------------------------------------- + +.. Build with Docker +.. _build with Docker: + +======================================== +Docker で構築 +======================================== + +.. sidebar:: 目次 + + .. contents:: + :depth: 2 + :local:　 + +.. Welcome! This guide is an introduction and deep-dive into building software with Docker. + +ようこそ！ このガイドは Docker でソフトウェアを構築するための手引きと深い掘り下げです。 + +.. Whether you’re just getting started, or you’re already an advanced Docker user, this guide aims to provide useful pointers into the possibilities and best practices of Docker’s build features. + +ちょうどこれから始めようとしている方だけでなく、既に高度な Docker ユーザだとしても、 Docker の構築機能についての可能性やベストプラクティスについて役立つ指針を、このガイドでは提供します。 + +.. Topics covered in this guide include: + +このガイドで扱うトピックには、以下の項目が含まれます。 + +.. Introduction to build concepts + Image size optimization + Build speed performance improvements + Building and exporting binaries + Cache mounts and bind mounts + Software testing + Multi-platform builds + +* 構築（ビルド）概念の導入 +* イメージ容量の最適化 +* 構築スピード性能の改善 +* バイナリの構築と出力 +* キャッシュマウントとバインドマウント +* ソフトウェアの試験 +* マルチプラットフォーム構築 + +.. Throughout this guide, an example application written in Go is used to illustrate how the build features work. You don’t need to know the Go programming language to follow this guide. + +このガイドを通し、Go 言語で書かれたアプリケーション例を使い、構築機能がどのように動作するかを説明します。このガイドを読み進めるために Go 言語の知識は不要です。 + +.. The guide starts off with a simple Dockerfile example, and builds from there. Some of the later sections in this guide describe advanced concepts and workflows. You don’t need to complete this entire guide from start to finish. Follow the sections that seem relevant to you, and save the advanced sections at the end for later, when you need them. + +このガイドはシンプルな Dockerfile 例から始まり、次に、それを使って構築します。このガイドは後半の幾つかで、概念とワークフローの詳細を扱います。このガイドを始めから最後まで完全に学ぶ必要はありません。自分に関係ありそうなセクションを読み進めてください。そして、途中から最後までの高度なセクションは、いつか必要になったときのために残しておきます。 + +.. raw:: html + +
+ 始めましょう +
+ + +---- + +.. seealso:: + + Build with Docker | Docker Documentation + https://docs.docker.com/build/guide/ + + diff --git a/build/guide/intro.rst b/build/guide/intro.rst new file mode 100644 index 000000000..0b2329d84 --- /dev/null +++ b/build/guide/intro.rst @@ -0,0 +1,262 @@ +.. -*- coding: utf-8 -*- +.. URL: https://docs.docker.com/build/intro/ + doc version: 24.0 + https://github.com/docker/docs/blob/main/build/guide/intro.md +.. check date: 2023/07/25 +.. Commits on Apr 25, 2023 da6586c498f34c0edac3171a48468a0f26aa0182 +.. ----------------------------------------------------------------------------- + +.. Build with Docker +.. _build with Docker: + +======================================== +Docker で構築 +======================================== + +.. sidebar:: 目次 + + .. contents:: + :depth: 2 + :local:　 + +.. The starting resources for this guide includes a simple Go project and a Dockerfile. From this starting point, the guide illustrates various ways that you can improve how you build the application with Docker. + +このガイドでは、シンプルな Go 言語のプロジェクトと Dockerfile を含むリソースから始めます。このガイドの開始時点から、Docker でアプリケーションを構築する方法を改善するための、様々な方法を紹介します。 + +.. Environment setup +.. _build-environment-setup: + +環境のセットアップ +==================== + +.. To follow this guide: + +以下のガイドを終えてください。 + +.. Install Docker Desktop or Docker Engine + Clone or create a new repository from the application example on GitHub + +1. :doc:`Docker Desktop か Docker Engine ` をインストールします。 +2. `GitHub 上からサンプルアプリケーションを `_ クローン（複製）するか、新しいリポジトリを作成します。 + +.. The application +.. _build-the-application: + +アプリケーション +==================== + +.. The example project for this guide is a client-server application for translating messages to a fictional language. + +このガイドのサンプルプロジェクトは、架空の言語に対して翻訳したメッセージを送信するための、クライアント・サーバ型アプリケーションです。 + +.. Here’s an overview of the files included in the project: + +こちらはプロジェクト内に含まれるファイルの一覧です。 + +.. code-block:: bash + + . + ├── Dockerfile + ├── cmd + │   ├── client + │   │   ├── main.go + │   │   ├── request.go + │   │   └── ui.go + │   └── server + │   ├── main.go + │   └── translate.go + ├── go.mod + └── go.sum + + +.. The cmd/ directory contains the code for the two application components: client and server. The client is a user interface for writing, sending, and receiving messages. The server receives messages from clients, translates them, and sends them back to the client. + +``cmd/`` ディレクトリに含まれるコードは、クライアントとサーバの2つのアプリケーション要素です。クライアントは、メッセージの書き込み、送信、受信のためのユーザインターフェイスです。サーバはクライアントからのメッセージを受け取り、それらを翻訳し、クライアントに送り返します。 + +.. The Dockerfile +.. _build-the-dockerfile: + +Dockerifle +========== + +.. A Dockerfile is a text document in which you define the build steps for your application. You write the Dockerfile in a domain-specific language, called the Dockerfile syntax. + +Dockerfile はテキスト形式のドキュメントであり、この中にアプリケーションの構築手順を定義します。 Dockerfile には Dockerfile :ruby:`構文 ` と呼ばれる :ruby:`ドメイン固有言語 ` を書きます。 + +.. Here’s the Dockerfile used as the starting point for this guide: + +以下は、このガイドで使う現時点の Dockerfile です。 + +.. code-block:: dockerfile + + # syntax=docker/dockerfile:1 + FROM golang:1.20-alpine + WORKDIR /src + COPY . . + RUN go mod download + RUN go build -o /bin/client ./cmd/client + RUN go build -o /bin/server ./cmd/server + ENTRYPOINT [ "/bin/server" ] + +.. Here’s what this Dockerfile does: + +以下は、この Dockerfile が何かの説明です。 + +.. This comment is a Dockerfile parser directive. It specifies which version of the Dockerfile syntax to use. This file uses the dockerfile:1 syntax which is best practice: it ensures that you have access to the latest Docker build features. + +1. ``# syntax=docker/dockerfile:1`` + + このコメント文は :ref:`Dockerfile パーサ ディレクティブ ` です。これで使用する Dockerfile 構文のバージョンを指定します。このファイルはベストプラクティスである ``dockerfile:1`` 構文を使います。つまり、最新の Docker 構築機能を必ず利用するようにします。 + +.. The FROM instruction uses version 1.20-alpine of the golang official image. + +2. ``FROM golang:1.20-alpine`` + + ``FROM`` 命令は、 ``golang`` 公式イメージのバージョン ``1.20-alpine`` を使います。 + +.. Creates the /src working directory inside the container. + +3. ``WORKDIR /src`` + + コンテナ内に :ruby:`作業ディレクトリ ` ``/src`` を作成します。 + +.. Copies the files in the build context to the working directory in the container. + +4. ``COPY . .`` + + :ruby:`構築コンテキスト ` 内のファイルを、コンテナ内の作業ディレクトリにコピーします。 + +.. Downloads the necessary Go modules to the container. Go modules is the dependency management tool for the Go programming language, similar to npm install for JavaScript, or pip install for Python. + +5. ``RUN go mod download`` + + 必要な Go モジュールをコンテナにダウンロードします。Go モジュールとは Go プログラミング言語用の依存関係管理ツールであり、 JavaScript 用の ``npm install`` や Python 用の ``pip install`` と似ています。 + +.. Builds the client binary, used to send messages to be translated, into the /bin directory. + +6. ``RUN go build -o /bin/client ./cmd/client`` + + ``/bin`` ディレクトリ内に ``client`` バイナリを構築し、これを翻訳されたメッセージの送信用に使います。 + +.. Builds the server binary, which listens for client translation requests, into the /bin directory. + +7. ``RUN go build -o /bin/server ./cmd/server`` + + ``/bin`` ディレクトリ内に ``server`` バイナリを構築し、これをクライアントが翻訳したリクエストの受信に使います。 + +.. Specifies a command to run when the container starts. Starts the server process. + +8. ``ENTRYPOINT [ "/bin/server" ]`` + + コンテナを起動時に実行するコマンドを指定します。サーバのプロセスを起動します。 + +.. Build the image +.. _build-build-the-image: + +イメージの構築 +==================== + +.. To build an image using a Dockerfile, you use the docker command-line tool. The command for building an image is docker build. + +Dockerfile を使ってイメージを構築するには、 ``docker`` コマンドラインツールを使います。イメージを構築するコマンドは ``docker build`` です。 + +.. Run the following command to build the image. + +イメージを構築するには以下のコマンドを実行します。 + +.. code-block:: bash + + $ docker build --tag=buildme . + +.. This creates an image with the tag buildme. An image tag is the name of the image. + +この作成されたイメージには :ruby:`タグ ` ``buildme`` があります。イメージのタグがイメージ名にあたります。 + + +.. Run the container +.. _build-run-the-container: + +コンテナの実行 +==================== + +.. The image you just built contains two binaries, one for the server and one for the client. To see the translation service in action, run a container that hosts the server component, and then run another container that invokes the client. + +今構築したイメージには2つのバイナリが入っています。1つはサーバで、もう1つはクライアントです。翻訳サービスが動作するの確認するには、サーバ部分をホスト（保持）するコンテナの起動と、次にクライアントを呼び出す別のコンテナを起動します。 + +.. To run a container, you use the docker run command. + +コンテナを実行するには ``docker run`` コマンドを使います。 + +.. Run a container from the image in detached mode. + +1. コンテナをイメージから :ruby:`デタッチドモード ` で起動します。 + + .. code-block:: bash + + $ docker run --name=buildme --rm --detach buildme + + .. This starts a container named buildme. + + これは ``buildme`` という名前のコンテナを起動します。 + +.. Run a new command in the buildme container that invokes the client binary. + +2. この ``buildme`` コンテナ内で、クライアントバイナリを呼び出すための新しいコマンドを実行します。 + + .. code-block:: bash + + $ docker exec -it buildme /bin/client + +.. The docker exec command opens a terminal user interface where you can submit messages for the backend (server) process to translate. + +翻訳用のバックエンド（サーバ）プロセスにメッセージを送信できる場所として、ターミナルのユーザインターフェイスを ``docker exec`` コマンドで開きます。 + +.. When you’re done testing, you can stop the container: + +.. code-block:: bash + + $ docker stop buildme + +.. Summary + +まとめ +========== + +.. This section gave you an overview of the example application used in this guide, an introduction to Dockerfiles and building. You’ve successfully built a container image and created a container from it. + +このセクションでは、本ガイドで使うサンプルアプリケーションの概要、Dockerfile と構築の導入を示しました。コンテナイメージを構築し、そのイメージからコンテナを作成するのに成功しました。 + +.. Related information: + +関連情報： + +.. Dockerfile reference + docker build CLI reference + docker run CLI reference + +* :doc:`Dockerfile リファレンス ` +* :doc:`docker build コマンドリファレンス ` +* :doc:`docker run コマンドリファレンス ` + +次のステップ +==================== + +.. The next section explores how you can use layer cache to improve build speed. + +次のセクションでは、構築速度を改善するために、レイヤのキャッシュをどのようにして使うかを探ります。 + +.. raw:: html + + + + +---- + +.. seealso:: + + Introduction + https://docs.docker.com/build/guide/intro/ + + diff --git a/build/guide/layers.rst b/build/guide/layers.rst new file mode 100644 index 000000000..dc469d61e --- /dev/null +++ b/build/guide/layers.rst @@ -0,0 +1,130 @@ +.. -*- coding: utf-8 -*- +.. URL: https://docs.docker.com/build/layers/ + doc version: 24.0 + https://github.com/docker/docs/blob/main/build/guide/layers.md +.. check date: 2023/07/26 +.. Commits on Apr 25, 2023 da6586c498f34c0edac3171a48468a0f26aa0182 +.. ----------------------------------------------------------------------------- + +.. Build with Docker +.. _build with Docker: + +======================================== +レイヤ +======================================== + +.. sidebar:: 目次 + + .. contents:: + :depth: 2 + :local:　 + + +.. The order of Dockerfile instructions matter. A Docker build consists of a series of ordered build instructions. Each instruction in a Dockerfile roughly translates to an image layer. The following diagram illustrates how a Dockerfile translates into a stack of layers in a container image. + +Dockerfile 命令の順番は重要です。Docker は構築命令の順番に従い、構築を構成します。Dockerfile 内の各命令は、 :ruby:`イメージ レイヤ ` に大ざっぱに相当します。以下の図が示すのは、Dockerfile がどのようにしてコンテナ内のレイヤ層の積み重なりに変換されるかです。 + +.. image:: ./images/layers.png + :width: 100% + :alt: Dockerfile からレイヤへ + +.. Cached layers +.. _cached-layers: + +キャッシュされたレイヤ +============================== + +.. When you run a build, the builder attempts to reuse layers from earlier builds. If a layer of an image is unchanged, then the builder picks it up from the build cache. If a layer has changed since the last build, that layer, and all layers that follow, must be rebuilt. + +構築を実行するとき、 :ruby:`ビルダ ` は以前に構築したレイヤを再利用しようとします。イメージのレイヤが変更されていない場合は、ビルダは :ruby:`構築キャッシュ ` からキャッシュを取り出します。最後の構築からレイヤに変更がある場合は、対象レイヤと以降のレイヤをすべて再構築されます。 + +.. The Dockerfile from the previous section copies all project files to the container (COPY . .) and then downloads application dependencies in the following step (RUN go mod download). If you were to change any of the project files, that would invalidate the cache for the COPY layer. It also invalidates the cache for all of the layers that follow. + +前のセクションにある Dockerfile は、全てのプロジェクトファイルをコンテナにコピーします（ ``COPY . .`` ）。それから、続くステップでアプリケーションの依存関係をダウンロードします（ ``RUN go mod download`` ）。プロジェクトのファイルに変更があれば、 ``COPY`` レイヤのキャッシュが無効になります。また、以降に続く、全てのレイヤに対するキャッシュも無効になります。 + +.. image:: ./images/cache-bust.png + :width: 70% + :alt: レイヤキャッシュのバースト + +.. The current order of the Dockerfile instruction make it so that the builder must download the Go modules again, despite none of the packages having changed since last time. + +現在の Dockerfile にある命令の順番では、ビルダは Go モジュールをダウンロードする必要があります。前回の構築時からパッケージは何も変わっていないのにもかかわらずです。 + + +.. Update the instruction order +.. _update-the-instruction-order: + +命令の順番を変える +==================== + +.. You can avoid this redundancy by reordering the instructions in the Dockerfile. Change the order of the instructions so that downloading and installing dependencies occurs before you copy the source code over to the container. That way, the builder can reuse the “dependencies” layer from the cache, even when you make changes to your source code. + +Dockerfile 内の命令の順番を変えれば、この余計な冗長性を避けられます。ソースコードをコンテナへと渡す前に、ダウンロードと依存関係のインストールをするように命令の順番を変えます。この方法により、ソースコードに変更があったとしても、ビルダがキャッシュから「依存関係」のレイヤを再利用できるようになります。 + +.. Go uses two files, called go.mod and go.sum, to track dependencies for a project. These files are to Go, what package.json and package-lock.json are to JavaScript. For Go to know which dependencies to download, you need to copy the go.mod and go.sum files to the container. Add another COPY instruction before RUN go mod download, this time copying only the go.mod and go.sum files. + +Go は ``go.mod`` と ``go.sum`` と呼ばれる2つのファイルを使い、プロジェクトの依存関係を追跡します。これらのファイルは Go にとって、JavaScript における ``package.json`` と ``package-lock.json`` にあたります。Go がダウンロードすべき依存関係を分かるようにするには、 ``go.mod`` と ``go.sum`` ファイルをコンテナ内にコピーする必要があります。 ``RUN go mod download`` の前に、今回は ``go.mod`` と ``go.sum`` ファイルのみコピーする別の ``COPY`` 命令を追加します。 + +.. code-block:: diff + + # syntax=docker/dockerfile:1 + FROM golang:{{site.example_go_version}}-alpine + WORKDIR /src + - COPY . . + + COPY go.mod go.sum . + RUN go mod download + + COPY . . + RUN go build -o /bin/client ./cmd/client + RUN go build -o /bin/server ./cmd/server + ENTRYPOINT [ "/bin/server" ] + +.. Now if you edit the application code, building the image won’t cause the builder to download the dependencies each time. The COPY . . instruction appears after the package management instructions, so the builder can reuse the RUN go mod download layer. + +これでアプリケーションのコードを変更したとしても、イメージの構築時に毎回ビルダが依存関係をダウンロードしなくなります。 ``COPY . .`` 命令はパッケージ管理命令の後にあるため、ビルダは ``RUN go mod download`` レイヤを再利用できます。 + +.. image:: ./images/reordered-layers.png + :width: 70% + :alt: 並び替え + +.. Summary + +まとめ +========== + +.. Ordering your Dockerfile instructions appropriately helps you avoid unnecessary work at build time. + +Dockerfile に書く命令の順番を適切にしておけば、構築時に不要な処理を防ぐのに役立ちます。 + +.. Related information: + +関連情報： + +.. Optimizing builds with cache + Dockerfile best practices + + +* :doc:`キャッシュで構築を最適化 ` +* :doc:`Dickerfile ベストプラクティス ` + +次のステップ +==================== + +.. The next section shows how you can make the build run faster, and make the resulting output smaller, using multi-stage builds. + +次のセクションでは、構築を速くし、最終出力を小さくするため、マルチステージビルドを使う方法を見ていきます。 + +.. raw:: html + + + + +---- + +.. seealso:: + + Layers + https://docs.docker.com/build/guide/layers/ + + diff --git a/build/guide/mounts.rst b/build/guide/mounts.rst new file mode 100644 index 000000000..4119f0e13 --- /dev/null +++ b/build/guide/mounts.rst @@ -0,0 +1,271 @@ +.. -*- coding: utf-8 -*- +.. URL: https://docs.docker.com/build/guide/mounts/ + doc version: 24.0 + https://github.com/docker/docs/blob/main/build/guide/mounts.md +.. check date: 2023/08/18 +.. Commits on Apr 25, 2023 da6586c498f34c0edac3171a48468a0f26aa0182 +.. ----------------------------------------------------------------------------- + +.. Mounts +.. _build-guide-mounts: + +======================================== +マウント +======================================== + +.. sidebar:: 目次 + + .. contents:: + :depth: 2 + :local:　 + +.. This section describes how to use cache mounts and bind mounts with Docker builds. + +このセクションでは、Docker の構築（ docker build ）で :ruby:`キャッシュ マウント ` と :ruby:`バインド マウント ` を使う方法を説明します。 + +.. Cache mounts let you specify a persistent package cache to be used during builds. The persistent cache helps speed up build steps, especially steps that involve installing packages using a package manager. Having a persistent cache for packages means that even if you rebuild a layer, you only download new or changed packages. + +キャッシュマウントでは、構築中に使用する固定されたパッケージのキャッシュを指定できます。 :ruby:`固定されたキャッシュ ` は構築ステップの速度向上に役立ちます。特に、パッケージマネージャーを使い、パッケージのインストールが発生するステップに役立ちます。パッケージに対する固定されたキャッシュを持つのが意味するのは、レイヤを再構築したとしても、新しいまたは変更されたパッケージしかダウンロードしません。 + +.. Cache mounts are created using the --mount flag together with the RUN instruction in the Dockerfile. To use a cache mount, the format for the flag is --mount=type=cache,target=, where is the location of the cache directory that you wish to mount into the container. + +キャッシュマウントを作成するには、Dockerfile 内の ``RUN`` 命令で ``--mount`` フラグと一緒に使います。キャッシュマウントを使うには、フラグの書式は ``--mount=type=cache,target=`` であり、 ```` にはコンテナ内にマウントしたいキャッシュディレクトリの場所です。 + +.. Add a cache mount +.. _add-a-cache-mount: + +キャッシュマウントの追加 +============================== + +.. The target path to use for the cache mount depends on the package manager you’re using. The application example in this guide uses Go modules. That means that the target directory for the cache mount is the directory where the Go module cache gets written to. According to the Go modules reference, the default location for the module cache is $GOPATH/pkg/mod, and the default value for $GOPATH is /go. + +キャッシュマウントの対象として使用するパスは、使用するパッケージマネージャに依存します。このガイドのアプリケーション例では Go モジュールを使います。つまり、キャッシュマウント対象のディレクトリとは、Go モジュールキャッシュが書き込む場所です。 `Go モジュール リファレンス `_ に従うと、モジュールキャッシュに使うデフォルトの場所は ``$GOPATH/pkg/mod`` であり、 ``$GOPATH`` 用のデフォルト値は ``/go`` です。 + +.. Update the build steps for downloading packages and compiling the program to mount the /go/pkg/mod directory as a cache mount: + +パッケージのダウンロードとプログラムをコンパイルする構築ステップを書き換え、キャッシュマウントとして ``/go/pkg/mod`` ディレクトリをマウントします。 + +.. code-block:: dockerfile + + # syntax=docker/dockerfile:1 + FROM golang:{{site.example_go_version}}-alpine AS base + WORKDIR /src + COPY go.mod go.sum . + - RUN go mod download + + RUN --mount=type=cache,target=/go/pkg/mod/ \ + + go mod download -x + COPY . . + + FROM base AS build-client + - RUN go build -o /bin/client ./cmd/client + + RUN --mount=type=cache,target=/go/pkg/mod/ \ + + go build -o /bin/client ./cmd/client + + FROM base AS build-server + - RUN go build -o /bin/server ./cmd/server + + RUN --mount=type=cache,target=/go/pkg/mod/ \ + + go build -o /bin/server ./cmd/server + + FROM scratch AS client + COPY --from=build-client /bin/client /bin/ + ENTRYPOINT [ "/bin/client" ] + + FROM scratch AS server + COPY --from=build-server /bin/server /bin/ + ENTRYPOINT [ "/bin/server" ] + +.. The -x flag added to the go mod download command prints the download executions that take place. Adding this flag lets you see how the cache mount is being used in the next step. + +``go mod download`` コマンドに ``-x`` フラグを付け、ダウンロード処理を表示します。このフラグの追加により、次のステップでキャッシュマウントがどのように使われているのか分かるでしょう。 + +.. Rebuild the image +.. _rebuild-the-image: + +イメージの再構築 +==================== + +.. Before you rebuild the image, clear your build cache. This ensures that you’re starting from a clean slate, making it easier to see exactly what the build is doing. + +イメージを再構築する前に、 :ruby:`構築キャッシュ ` を片付けます。これにより、白紙状態から始められるようにし、構築で何をしているのか確実に見えるようにします。 + +.. code-block:: bash + + $ docker builder prune -af + +.. Now it’s time to rebuild the image. Invoke the build command, this time together with the --progress=plain flag, while also redirecting the output to a log file. + +次はイメージを再構築する時です。今回は構築コマンドで ``--progress=plain`` フラグを付けて実行し、出力をログファイルにリダイレクトします。 + +.. code-block:: bash + + $ docker build --target=client --progress=plain . 2> log1.txt + +.. When the build has finished, inspect the log1.txt file. The logs show how the Go modules were downloaded as part of the build. + +構築が完了すると、 ``log1.txt`` を調べます。ログからは、構築パートで Go モジュールがダウンロードされているのが分かります。 + +.. code-block:: bash + + $ awk '/proxy.golang.org/' log1.txt + #11 0.168 # get https://proxy.golang.org/github.com/charmbracelet/lipgloss/@v/v0.6.0.mod + #11 0.168 # get https://proxy.golang.org/github.com/aymanbagabas/go-osc52/@v/v1.0.3.mod + #11 0.168 # get https://proxy.golang.org/github.com/atotto/clipboard/@v/v0.1.4.mod + #11 0.168 # get https://proxy.golang.org/github.com/charmbracelet/bubbletea/@v/v0.23.1.mod + #11 0.169 # get https://proxy.golang.org/github.com/charmbracelet/bubbles/@v/v0.14.0.mod + #11 0.218 # get https://proxy.golang.org/github.com/charmbracelet/bubbles/@v/v0.14.0.mod: 200 OK (0.049s) + #11 0.218 # get https://proxy.golang.org/github.com/aymanbagabas/go-osc52/@v/v1.0.3.mod: 200 OK (0.049s) + #11 0.218 # get https://proxy.golang.org/github.com/containerd/console/@v/v1.0.3.mod + #11 0.218 # get https://proxy.golang.org/github.com/go-chi/chi/v5/@v/v5.0.0.mod + #11 0.219 # get https://proxy.golang.org/github.com/charmbracelet/bubbletea/@v/v0.23.1.mod: 200 OK (0.050s) + #11 0.219 # get https://proxy.golang.org/github.com/atotto/clipboard/@v/v0.1.4.mod: 200 OK (0.051s) + #11 0.219 # get https://proxy.golang.org/github.com/charmbracelet/lipgloss/@v/v0.6.0.mod: 200 OK (0.051s) + ... + +.. Now, in order to see that the cache mount is being used, change the version of one of the Go modules that your program imports. By changing the module version, you’re forcing Go to download the new version of the dependency the next time you build. If you weren’t using cache mounts, your system would re-download all modules. But because you’ve added a cache mount, Go can reuse most of the modules and only download the package versions that doesn’t already exist in the /go/pkg/mod directory. + +次はキャッシュマウントが使われているのを確認するため、プログラムが読み込む Go モジュールのバージョンを変えます。モジュールのバージョンを変更するには、次回構築時に、Go に対して依存関係の新しいバージョンを強制的にダウンロードさせます。ですが、キャッシュマウントを追加していますので、Go は大部分のモジュールを再利用でき、 ``/go/pkg/mod`` ディレクトリ内にまだ存在していないパッケージのバージョンのみダウンロードします。 + +.. Update the version of the chi package that the server component of the application uses: + +アプリケーションが使うサーバコンポーネントである ``chi`` パッケージのバージョンを更新します。 + +.. code-block:: bash + + $ docker run -v $PWD:$PWD -w $PWD golang:{{site.example_go_version}}-alpine \ + go get github.com/go-chi/chi/v5@v5.0.8 + +.. Now, run another build, and again redirect the build logs to a log file: + +次は別の構築を行い、再び構築ログをログファイルにリダイレクトします。 + +.. code-block:: bash + + $ docker build --target=client --progress=plain . 2> log2.txt + +.. Now if you inspect the log2.txt file, you’ll find that only the chi package that was changed has been downloaded: + +次は ``log2.txt`` ファイルを調査しますと、 ``chi`` パッケージのみがダウンロードされ、更新されたのが分かるでしょう。 + +.. code-block:: bash + + $ awk '/proxy.golang.org/' log2.txt + #10 0.143 # get https://proxy.golang.org/github.com/go-chi/chi/v5/@v/v5.0.8.mod + #10 0.190 # get https://proxy.golang.org/github.com/go-chi/chi/v5/@v/v5.0.8.mod: 200 OK (0.047s) + #10 0.190 # get https://proxy.golang.org/github.com/go-chi/chi/v5/@v/v5.0.8.info + #10 0.199 # get https://proxy.golang.org/github.com/go-chi/chi/v5/@v/v5.0.8.info: 200 OK (0.008s) + #10 0.201 # get https://proxy.golang.org/github.com/go-chi/chi/v5/@v/v5.0.8.zip + #10 0.209 # get https://proxy.golang.org/github.com/go-chi/chi/v5/@v/v5.0.8.zip: 200 OK (0.008s) + +.. Add bind mounts +.. _add-bind-mounts: + +バインドマウントの追加 +============================== + +.. There are a few more small optimizations that you can implement to improve the Dockerfile. Currently, it’s using the COPY instruction to pull in the go.mod and go.sum files before downloading modules. Instead of copying those files over to the container’s filesystem, you can use a bind mount. A bind mount makes the files available to the container directly from the host. This change removes the need for the additional COPY instruction (and layer) entirely. + +いくつかの小さな最適化により、Dockerfile を改善できます。現時点では、モジュールをダウンロードする前に、 ``COPY`` 命令を使って ``go.mod`` と ``go.sum`` ファイルを取得します。これらのファイルをコンテナのファイルシステムを通してコピーするのではなく、バインドマウントが利用できます。バインドマウントはホストから直接コンテナでファイルを利用できるようにします。この変更は ``COPY`` 命令（とレイヤ）を追加する必要を完全に除去します。 + +.. code-block:: dockerfile + + # syntax=docker/dockerfile:1 + FROM golang:{{site.example_go_version}}-alpine AS base + WORKDIR /src + - COPY go.mod go.sum . + RUN --mount=type=cache,target=/go/pkg/mod/ \ + + --mount=type=bind,source=go.sum,target=go.sum \ + + --mount=type=bind,source=go.mod,target=go.mod \ + go mod download -x + COPY . . + + FROM base AS build-client + RUN --mount=type=cache,target=/go/pkg/mod/ \ + go build -o /bin/client ./cmd/client + + FROM base AS build-server + RUN --mount=type=cache,target=/go/pkg/mod/ \ + go build -o /bin/server ./cmd/server + + FROM scratch AS client + COPY --from=build-client /bin/client /bin/ + ENTRYPOINT [ "/bin/client" ] + + FROM scratch AS server + COPY --from=build-server /bin/server /bin/ + ENTRYPOINT [ "/bin/server" ] + +.. Similarly, you can use the same technique to remove the need for the second COPY instruction as well. Specify bind mounts in the build-client and build-server stages for mounting the current working directory. + +同様に、同じテクニックを使い2つめの ``COPY`` 命令も同じく不要にできます。 ``build-client`` と ``build-server`` ステージ内で、現在の作業ディレクトリをバインドマウントとして指定します。 + +.. code-block:: dockerfile + + # syntax=docker/dockerfile:1 + FROM golang:{{site.example_go_version}}-alpine AS base + WORKDIR /src + RUN --mount=type=cache,target=/go/pkg/mod/ \ + --mount=type=bind,source=go.sum,target=go.sum \ + --mount=type=bind,source=go.mod,target=go.mod \ + go mod download -x + - COPY . . + + FROM base AS build-client + RUN --mount=type=cache,target=/go/pkg/mod/ \ + + --mount=type=bind,target=. \ + go build -o /bin/client ./cmd/client + + FROM base AS build-server + RUN --mount=type=cache,target=/go/pkg/mod/ \ + + --mount=type=bind,target=. \ + go build -o /bin/server ./cmd/server + + FROM scratch AS client + COPY --from=build-client /bin/client /bin/ + ENTRYPOINT [ "/bin/client" ] + + FROM scratch AS server + COPY --from=build-server /bin/server /bin/ + ENTRYPOINT [ "/bin/server" ] + +.. Summary + +まとめ +========== + +.. This section has shown how you can improve your build speed using cache and bind mounts. + +このセクションでは、キャッシュとバインドマウントを使って構築速度を改善できる方法を学びました。 + +.. Related information: + +関連情報： + +.. Dockerfile reference + Bind mounts + + +* :ref:`Dockerfile リファレンス ` +* :doc:`バインドマウント ` + +次のステップ +==================== + +.. The next section of this guide is an introduction to making your builds configurable, using build arguments. + +次セクションでは構築引数を使い、調整可能な構築をする方法をを紹介します。 + +.. raw:: html + + + + +---- + +.. seealso:: + + Mounts + https://docs.docker.com/build/guide/mounts/ + + diff --git a/build/guide/multi-stage.rst b/build/guide/multi-stage.rst new file mode 100644 index 000000000..80315eb08 --- /dev/null +++ b/build/guide/multi-stage.rst @@ -0,0 +1,248 @@ +.. -*- coding: utf-8 -*- +.. URL: https://docs.docker.com/build/guide/multi-stage/ + doc version: 24.0 + https://github.com/docker/docs/blob/main/build/guide/multi-stage.md +.. check date: 2023/08/10 +.. Commits on Apr 25, 2023 da6586c498f34c0edac3171a48468a0f26aa0182 +.. ----------------------------------------------------------------------------- + +.. Multi-stage +.. _build-guide-multi-stage: + +======================================== +マルチステージ +======================================== + +.. sidebar:: 目次 + + .. contents:: + :depth: 2 + :local:　 + +.. This section explores multi-stage builds. There are two main reasons for why you’d want to use multi-stage builds: + +このセクションは :ruby:`マルチステージビルド ` を見ていきます。マルチステージビルドを使う理由は、主に2つあります。 + +.. They allow you to run build steps in parallel, making your build pipeline faster and more efficient. + They allow you to create a final image with a smaller footprint, containing only what’s needed to run your program. + +* 構築ステップを並列に実行できるため、構築パイプラインをより速くより効率的にできる。 +* プログラムを実行するために必要なものだけを含む、形跡が最小の最終イメージを作成できる。 + +.. In a Dockerfile, a build stage is represented by a FROM instruction. The Dockerfile from the previous section doesn’t leverage multi-stage builds. It’s all one build stage. That means that the final image is bloated with resources used to compile the program. + +Dockerfile 内では ``FROM`` 命令によって :ruby:`構築ステージ ` を表します。前のセクションにある Dockerfile では、マルチステージビルドを活用していませんでした。先ほどは、すべて1つの構築ステージでした。つまり、最終イメージはプログラムのコンパイルに使われたリソースで膨れあがっています。 + +.. code-block:: bash + + $ docker build --tag=buildme . + $ docker images buildme + REPOSITORY TAG IMAGE ID CREATED SIZE + buildme latest c021c8a7051f 5 seconds ago 150MB + +.. The program compiles to executable binaries, so you don’t need Go language utilities to exist in the final image. + +プログラムは実行可能なバイナリにコンパイルされているため、最終イメージ内に Go 言語ユーティリティは不要になります。 + +.. Add stages +.. _build-add-stages: + +ステージの追加 +==================== + +.. Using multi-stage builds, you can choose to use different base images for your build and runtime environments. You can copy build artifacts from the build stage over to the runtime stage. + +マルチステージビルドの使用により、構築用と実行環境用で、異なるベースイメージが選べます。 :ruby:`構築の成果物 ` を構築用ステージから実行用ステージにコピーできます。 + +.. Modify the Dockerfile as follows. This change creates another stage using a minimal scratch image as a base. In the final scratch stage, the binaries built in the previous stage are copied over to the filesystem of the new stage. + +以下のように Dockerfile を編集します。この変更により、最小の ``scratch`` イメージをベースとして使う別のステージを作成します。最終の ``scratch`` ステージでは、前のステージで構築されたバイナリを、新しいステージのファイルシステムへとコピーしています。 + + +.. code-block:: diff + + # syntax=docker/dockerfile:1 + FROM golang:{{site.example_go_version}}-alpine + WORKDIR /src + COPY go.mod go.sum . + RUN go mod download + COPY . . + RUN go build -o /bin/client ./cmd/client + RUN go build -o /bin/server ./cmd/server + + + + FROM scratch + + COPY --from=0 /bin/client /bin/server /bin/ + ENTRYPOINT [ "/bin/server" ] + +.. Now if you build the image and inspect it, you should see a significantly smaller number: + +これで、イメージを構築して調査したら、値が著しく小さくなったと分かるでしょう。 + +.. code-block:: bash + + $ docker build --tag=buildme . + $ docker images buildme + REPOSITORY TAG IMAGE ID CREATED SIZE + buildme latest 436032454dd8 7 seconds ago 8.45MB + +.. The image went from 150MB to only just 8.45MB in size. That’s because the resulting image only contains the binaries, and nothing else. + +150MB だったイメージは、ほんの 8.45MB になりました。最終的なイメージに含まれるのはバイナリだけであり、他になにもないからです。 + +.. Parallelism +.. _multi-stage-parallelism: + +並列処理 +========== + +.. You’ve reduced the footprint of the image. The following step shows how you can improve build speed with multi-stage builds, using parallelism. The build currently produces the binaries one after the other. There is no reason why you need to build the client before building the server, or vice versa. + +これまでは、イメージの形跡を減らしました。以下の手順では、マルチステージビルドの並列処理を使い、構築速度を改善できる方法を見ていきます。現時点の構築は、次々にバイナリを作成します。しかし、サーバの前にクライアントを作成する必要はなく、その逆の場合も同じです。 + +.. You can split the binary-building steps into separate stages. In the final scratch stage, copy the binaries from each corresponding build stage. By segmenting these builds into separate stages, Docker can run them in parallel. + +バイナリの構築ステップを、個々のステージに分割できます。最後の ``scratch`` ステージでは、それぞれの適切な構築ステージからバイナリをコピーします。それぞれの構築をステージに分ければ、 Docker は並列でそれらを実行できます。 + +.. The stages for building each binary both require the Go compilation tools and application dependencies. Define these common steps as a reusable base stage. You can do that by assigning a name to the stage using the pattern FROM image AS stage_name. This allows you to reference the stage name in a FROM instruction of another stage (FROM stage_name). + +構築用のステージでは、Go コンパイルツールとアプリケーション依存関係の、それぞれのバイナリが必要です。これらに共通するステップを、再利用可能な :ruby:`ベースステージ ` として定義できます。これを可能とするには、 ``FROM イメージ AS ステージ名`` のパターンを使い、ステージに対して名前を割り当てます。これでそのステージ名は、他のステージの ``FROM`` 命令内で参照できるようになります（ ``FROM ステージ名`` ）。 + +.. You can also assign a name to the binary-building stages, and reference the stage name in the COPY --from=stage_name instruction when copying the binaries to the final scratch image. + +また、バイナリ構築ステージでも名前を割り当て可能なため、バイナリを最終 ``scratch`` イメージにコピーするには ``COPY --from=ステージ名`` としてステージ名を参照します。 + +.. code-block:: diff + + # syntax=docker/dockerfile:1 + - FROM golang:{{site.example_go_version}}-alpine + + FROM golang:{{site.example_go_version}}-alpine AS base + WORKDIR /src + COPY go.mod go.sum . + RUN go mod download + COPY . . + + + + FROM base AS build-client + RUN go build -o /bin/client ./cmd/client + + + + FROM base AS build-server + RUN go build -o /bin/server ./cmd/server + + FROM scratch + - COPY --from=0 /bin/client /bin/server /bin/ + + COPY --from=build-client /bin/client /bin/ + + COPY --from=build-server /bin/server /bin/ + ENTRYPOINT [ "/bin/server" ] + +.. Now, instead of first building the binaries one after the other, the build-client and build-server stages are executed simultaneously. + +これで、最初のバイナリを次々に構築する方法に替わり、 ``build-client`` と ``build-server`` ステージが同時に処理されます。 + +.. image:: ./images/parallelism.gif + :width: 70% + :alt: 並列にステージを実行 + + +.. Build targets +.. _build-targets: + +構築ターゲット +==================== + +.. The final image is now small, and you’re building it efficiently using parallelism. But this image is slightly strange, in that it contains both the client and the server binary in the same image. Shouldn’t these be two different images? + +最終イメージは小さくなり、並列処理を使って構築できるようになりました。しかし、このイメージは少し変わってて、同じイメージ内にクライアントとサーバ両方のイメージが入っています。これらは2つのイメージに分けるべきではないでしょうか。 + +.. It’s possible to create multiple different images using a single Dockerfile. You can specify a target stage of a build using the --target flag. Replace the unnamed FROM scratch stage with two separate stages named client and server. + +1つの Dockerfile を使って、複数のイメージの作成が可能です。 ``--target`` フラグを使い、構築の :ruby:`対象となるステージ ` を指定できます。名前の付いていない ``FROM scratch`` ステージの名前を書き換え、 ``client`` と ``server`` の異なる2つのステージにします。 + +.. code-block:: diff + + # syntax=docker/dockerfile:1 + FROM golang:{{site.example_go_version}}-alpine AS base + WORKDIR /src + COPY go.mod go.sum . + RUN go mod download + COPY . . + + FROM base AS build-client + RUN go build -o /bin/client ./cmd/client + + FROM base AS build-server + RUN go build -o /bin/server ./cmd/server + + - FROM scratch + - COPY --from=build-client /bin/client /bin/ + - COPY --from=build-server /bin/server /bin/ + - ENTRYPOINT [ "/bin/server" ] + + + FROM scratch AS client + + COPY --from=build-client /bin/client /bin/ + + ENTRYPOINT [ "/bin/client" ] + + + FROM scratch AS server + + COPY --from=build-server /bin/server /bin/ + + ENTRYPOINT [ "/bin/server" ] + +.. And now you can build the client and server programs as separate Docker images (tags): + +これで、クライアントとサーバのプログラムが分けられた Docker イメージ（タグ）を構築できます。 + + +.. code-block:: bash + + $ docker build --tag=buildme-client --target=client . + $ docker build --tag=buildme-server --target=server . + $ docker images buildme + REPOSITORY TAG IMAGE ID CREATED SIZE + buildme-client latest 659105f8e6d7 20 seconds ago 4.25MB + buildme-server latest 666d492d9f13 5 seconds ago 4.2MB + +.. The images are now even smaller, about 4 MB each. + +イメージは更に小さくなり、それぞれ 4 MB です。 + +.. This change also avoids having to build both binaries each time. When selecting to build the client target, Docker only builds the stages leading up to that target. The build-server and server stages are skipped if they’re not needed. Likewise, building the server target skips the build-client and client stages. + +この変更は、バイナリをそれぞれ構築する必要もありません。 ``client`` ターゲットの構築を選ぶ場合、 Docker は対象となるターゲットが必要なステージのみ構築します。 ``build-server`` と ``server`` ステージは必要がなければ飛ばします。同様に、 ``server`` ターゲットの構築では、 ``build-client`` と ``client`` ステージを飛ばします。 + +.. Summary + +まとめ +========== + +.. Multi-stage builds are useful for creating images with less bloat and a smaller footprint, and also helps to make builds run faster. + +マルチステージビルドは肥大化しないイメージの構築に役立ち、形跡をより小さくし、構築を速くするのにも役立ちます。 + +.. Related information: + +関連情報： + +.. Multi-stage builds + Base images + +* :doc:`マルチステージビルド ` +* :doc:`ベースイメージ ` + +次のステップ +==================== + +.. The next section describes how you can use file mounts to further improve build speeds. + +次のセクションでは、構築速度を更に改善するため、ファイルマウントの使い方を説明します。 + +.. raw:: html + + + + +---- + +.. seealso:: + + Multi-stage + https://docs.docker.com/build/guide/multi-stage/ + diff --git a/build/guide/toc.rst b/build/guide/toc.rst new file mode 100644 index 000000000..7269cc340 --- /dev/null +++ b/build/guide/toc.rst @@ -0,0 +1,25 @@ +.. -*- coding: utf-8 -*- +.. +.. doc version: 24.0 +.. check date: 2023/07/25 +.. ----------------------------------------------------------------------------- + +.. _build-with-docker-toc: + +======================================== +Docker で構築 +======================================== + +.. toctree:: + :maxdepth: 2 + + 概要 + 1. はじめに + 2. レイヤ + 3. マルチステージ + 4. マウント + 5. 構築オプション + 6. バイナリの出力 + 7. テスト + 8. マルチプラットフォーム + 次のステップ \ No newline at end of file diff --git a/ci-cd/best-practices.rst b/ci-cd/best-practices.rst index 284a2725d..d0321498c 100644 --- a/ci-cd/best-practices.rst +++ b/ci-cd/best-practices.rst @@ -38,7 +38,7 @@ CI/CD のために Docker Hub を使うベストプラクティス 始めるにあたり、CI でテストが必要な場合や、CI をローカルでする場合に、Docker とあらゆる CI/CD とが、どのようにして動作するかの理解が最も重要です。Docker では、 :ruby:`内部ループ ` の視点（コードを書き、構築し、実行し、テストする）と :ruby:`外部ループ ` の視点（変更を push 、 CI で構築し、 CI でテストし、デプロイする）で、開発者がどのようにして働くかを考えました。 .. image:: ./images/inner-outer-loop.png - :scale: 60% + :width: 60% :alt: CI/CD の内部ループと外部ループ .. Before you think about optimizing your CI/CD, it is important to think about your inner loop and how it relates to the outer loop (the CI). We know that most users don’t prefer ‘debugging through the CI’. Therefore, it is better if your inner loop and outer loop are as similar as possible. We recommend that you run unit tests as part of your docker build command by adding a target for them in your Dockerfile. This way, as you are making changes and rebuilding locally, you can run the same unit tests you would run in the CI on your local machine using a simple command. diff --git a/ci-cd/github-actions.rst b/ci-cd/github-actions.rst index 025ed74f4..1a72d1a6c 100644 --- a/ci-cd/github-actions.rst +++ b/ci-cd/github-actions.rst @@ -47,7 +47,7 @@ Docker プロジェクトのセットアップ それでは始めましょう。このガイドでは例としてシンプルな Docker プロジェクトを使います。 `SimpleWhaleDemo `_ リポジトリには、 Nginx alpine イメージを含みます。このリポジトリをクローンするか、自分の Docker プロジェクトを使います。 .. image:: ./images/simplewhaledemo.png - :scale: 60% + :width: 60% :alt: SimpleWhaleDemo .. Before we start, ensure you can access Docker Hub from any workflows you create. To do this: diff --git a/compose/django.rst b/compose/django.rst index 301d6e279..6057244a8 100644 --- a/compose/django.rst +++ b/compose/django.rst @@ -396,7 +396,7 @@ Django プロジェクトの生成 .. ![Django example](images/django-it-worked.png) .. image:: /compose/images/django-it-worked.png - :scale: 60% + :width: 60% :alt: Django の例 .. > Note: diff --git a/compose/gettingstarted.rst b/compose/gettingstarted.rst index d6cb64db3..56d2eb8bc 100644 --- a/compose/gettingstarted.rst +++ b/compose/gettingstarted.rst @@ -257,7 +257,7 @@ redis サービス Hello World! I have been seen 1 times. .. image:: images/quick-hello-world-1.png - :scale: 60% + :width: 60% :alt: ブラウザで hello world .. Refresh the page. @@ -273,7 +273,7 @@ redis サービス Hello World! I have been seen 2 times. .. image:: images/quick-hello-world-2.png - :scale: 60% + :width: 60% :alt: ブラウザで hello world .. Switch to another terminal window, and type docker image ls to list local images. @@ -391,7 +391,7 @@ redis サービス ブラウザでアプリを再読み込みします。挨拶が更新され、さらにカウンタも増え続けます。 .. image:: images/quick-hello-world-2.png - :scale: 60% + :width: 60% :alt: ブラウザで hello world .. Step 8: Experiment with some other commands diff --git a/compose/rails.rst b/compose/rails.rst index 411d8038d..e2e4b3e5c 100644 --- a/compose/rails.rst +++ b/compose/rails.rst @@ -402,7 +402,7 @@ Docker Desktop for Mac や Docker Desktop for Windows の場合は、ウェブ .. ![Rails example](./images/rails-welcome.png) .. image:: ./images/rails-welcome.png - :scale: 60% + :width: 60% :alt: Rails の例 .. ### Stop the application diff --git a/compose/wordpress.rst b/compose/wordpress.rst index 93689a3b4..48a75bd87 100644 --- a/compose/wordpress.rst +++ b/compose/wordpress.rst @@ -266,13 +266,13 @@ Docker Desktop for Mac や Docker Desktop for Windows を利用している場 .. ![Choose language for WordPress install](images/wordpress-lang.png) .. image:: ./images/wordpress-lang.png - :scale: 60% + :width: 60% :alt: WordPress 言語選択 .. ![WordPress Welcome](images/wordpress-welcome.png) .. image:: ./images/wordpress-welcome.png - :scale: 60% + :width: 60% :alt: WordPress ようこそ画面 .. ### Shutdown and cleanup diff --git a/conf.py b/conf.py index c0826ef69..a95734bc5 100644 --- a/conf.py +++ b/conf.py @@ -63,9 +63,9 @@ # built documents. # # The short X.Y version. -version = '23.0' +version = '24.0' # The full version, including alpha/beta/rc tags. -release = '23.0' +release = '24.0' # The language for content autogenerated by Sphinx. Refer to documentation # for a list of supported languages. @@ -141,7 +141,7 @@ "display_github": True, "github_user": "zembutsu", "github_repo": "docs.docker.jp", - "github_version": "v23.0", + "github_version": "v24.0", "conf_py_path": "/", } diff --git a/desktop/containerd/index.rst b/desktop/containerd/index.rst index 4e6e17cd1..09c6db19e 100644 --- a/desktop/containerd/index.rst +++ b/desktop/containerd/index.rst @@ -60,7 +60,7 @@ Containerd Image Store ベータ機能は、デフォルトでは無効化され .. image:: ../images/containerd_feature_activation.png - :scale: 60% + :width: 60% :alt: Contaienrd 機能 .. Simple usage examples @@ -199,7 +199,7 @@ NGINX コンテナの実行状況を確認します： ブラウザからも NGINX の実行状況を確認できます。 .. image:: ../images/containerd_feature_nginx.png - :scale: 60% + :width: 60% :alt: Contaienrd 機能 nginx .. Building multi-platform images @@ -275,7 +275,7 @@ Dockerfile のサンプル： Docker Hub でマルチプラットフォーム対応のタグを確認： .. image:: ../images/containerd_feature_tags.png - :scale: 60% + :width: 60% :alt: Contaienrd 機能 タグ .. Containerd Image Store Release Notes diff --git a/desktop/dev-environments/index.rst b/desktop/dev-environments/index.rst index 9c271f13e..236d98631 100644 --- a/desktop/dev-environments/index.rst +++ b/desktop/dev-environments/index.rst @@ -42,7 +42,7 @@ Dev Environmens はコードエディタ内蔵ツールを使います。これ Dev Environments 機能は現時点では `ベータ `_ です。プロダクション環境での利用を推奨しません。 .. image:: ../images/dev-env.png - :scale: 60% + :width: 60% :alt: Docker Desktop .. Prerequisites @@ -90,7 +90,7 @@ GIt をインストール済みの場合で、適切な状態か分からなけ 有効なコマンドとして Git を確認できなければ、Git の再インストールが必要です。さらに、 **Adjusting your PATH environment** のステップで、 **Git from the command line..** や **Use Git and optional Unix tools...** オプションを選ぶ必要があります。 .. image:: ../images/dev-env-gitbash.png - :scale: 60% + :width: 60% :alt: Windows のパスに Git を追加 .. Note diff --git a/desktop/dev-environments/share.rst b/desktop/dev-environments/share.rst index 2dc5f8209..f1f414b20 100644 --- a/desktop/dev-environments/share.rst +++ b/desktop/dev-environments/share.rst @@ -51,7 +51,7 @@ Environment の共有準備が整ったら、 Dev Environment の上にマウス .. Dev environment shared .. image:: ../images/dev-share.png - :scale: 60% + :width: 60% :alt: Dev Environment の共有 .. Open a Dev Environment that has been shared with you diff --git a/desktop/extentions/index.rst b/desktop/extentions/index.rst index d345fcfe3..8a12841eb 100644 --- a/desktop/extentions/index.rst +++ b/desktop/extentions/index.rst @@ -43,7 +43,7 @@ Docker Extensions は誰でも利用でき、インストール可能な拡張 .. extenstions .. image:: ../images/extensions-marketplace.png - :scale: 60% + :width: 60% :alt: extensions diff --git a/desktop/get-started.rst b/desktop/get-started.rst index b25ed454a..1c8e93d36 100644 --- a/desktop/get-started.rst +++ b/desktop/get-started.rst @@ -7,7 +7,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: ./images/whale-x.png - :scale: 50% + :width: 50% .. Sign in and get started .. _sign-in-and-get-started: @@ -33,7 +33,7 @@ Docker Desktop をインストールしたら、クイックスタートガイドが起動します。これには簡単な練習が入っており、 Docker イメージ例の構築、コンテナとしてイメージの実行、そしてイメージを保存して Docker Hub に送信します。 .. image:: ./images/docker-tutorial-linux.png - :scale: 60% + :width: 60% :alt: Docker クイックスタート チュートリアル .. To run the Quick Start Guide on demand, select whale menu and then choose Quick Start Guide. diff --git a/desktop/install/archlinux.rst b/desktop/install/archlinux.rst index d239f3f4f..0504aa932 100644 --- a/desktop/install/archlinux.rst +++ b/desktop/install/archlinux.rst @@ -7,7 +7,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: ./images/whale-x.png - :scale: 50% + :width: 50% .. Install Docker Desktop on Arch-based distributions .. _install-docker-desktop-on-arch-based-distributions: diff --git a/desktop/install/debian.rst b/desktop/install/debian.rst index 7512a2eb3..a02104029 100644 --- a/desktop/install/debian.rst +++ b/desktop/install/debian.rst @@ -7,7 +7,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: ./images/whale-x.png - :scale: 50% + :width: 50% .. Install Docker Desktop on Debian .. _install-docker-desktop-on-debian: @@ -92,7 +92,7 @@ Debian に Docker Desktop をインストールするため、推奨する手順 Install the package with apt as follows: 1. :ref:`Docker のパッケージ リポジトリをセットアップ ` -2. 最新の `DEB パッケージ `_ をダウンロード +2. 最新の `DEB パッケージ `_ をダウンロード 3. 以下のように apt でパッケージをインストール： .. code-block:: bash diff --git a/desktop/install/fedora.rst b/desktop/install/fedora.rst index c33dba513..bcfba42e2 100644 --- a/desktop/install/fedora.rst +++ b/desktop/install/fedora.rst @@ -7,7 +7,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: ./images/whale-x.png - :scale: 50% + :width: 50% .. Install Docker Desktop on Fedora .. _install-docker-desktop-on-fedora: @@ -69,7 +69,7 @@ Debian に Docker Desktop をインストールするため、推奨する手順 Install the package with dnf as follows: 1. :ref:`Docker のパッケージ リポジトリをセットアップ ` -2. 最新の `RPM パッケージ `_ をダウンロード +2. 最新の `RPM パッケージ `_ をダウンロード 3. 以下のように dnf でパッケージをインストール： .. code-block:: bash diff --git a/desktop/install/linux-install.rst b/desktop/install/linux-install.rst index f6307919f..b7771c3e7 100644 --- a/desktop/install/linux-install.rst +++ b/desktop/install/linux-install.rst @@ -7,7 +7,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: ./images/whale-x.png - :scale: 50% + :width: 50% .. Install Docker Desktop on Linux .. _install-docker-desktop-on-linux: @@ -44,9 +44,9 @@ Linux に Docker Desktop をインストール ---- - * `RPM パッケージ `_ - * `DEB パッケージ `_ - * `Arch パッケージ（実験的） `_ + * `RPM パッケージ `_ + * `DEB パッケージ `_ + * `Arch パッケージ（実験的） `_ .. System requirements @@ -236,7 +236,7 @@ kvm デバイスに対してアクセスするには、ユーザを kvm グル .. Docker app in Hockeyapp .. image:: ./images/docker-app-in-apps.png - :scale: 60% + :width: 60% :alt: アプリ一覧での Docker .. Select Docker Desktop to start Docker. diff --git a/desktop/install/mac-install.rst b/desktop/install/mac-install.rst index cf93479bb..6807e4b85 100644 --- a/desktop/install/mac-install.rst +++ b/desktop/install/mac-install.rst @@ -9,7 +9,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: ./images/whale-x.png - :scale: 50% + :width: 50% .. Install Docker Desktop on Mac .. _install-docker-desktop-on-mac: @@ -118,7 +118,7 @@ Mac に Docker Desktop をインストールして動かす .. Install Docker app .. image:: ./images/docker-app-drag-mac.png - :scale: 60% + :width: 60% :alt: Docker app のインストール .. Double-click Docker.app in the Applications folder to start Docker. (In the example below, the Applications folder is in “grid” view mode.) @@ -128,7 +128,7 @@ Mac に Docker Desktop をインストールして動かす .. Docker app in Hockeyapp .. image:: ./images/docker-app-in-apps-mac.png - :scale: 60% + :width: 60% :alt: アプリ一覧での Docker .. The Docker menu (whale menu) displays the Docker Subscription Service Agreement window. It includes a change to the terms of use for Docker Desktop. diff --git a/desktop/install/ubuntu.rst b/desktop/install/ubuntu.rst index da1669fd4..54e2dd99c 100644 --- a/desktop/install/ubuntu.rst +++ b/desktop/install/ubuntu.rst @@ -7,7 +7,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: ./images/whale-x.png - :scale: 50% + :width: 50% .. Install Docker Desktop on Ubuntu .. _install-docker-desktop-on-ubuntu: @@ -93,7 +93,7 @@ Debian に Docker Desktop をインストールするため、推奨する手順 Install the package with apt as follows: 1. :ref:`Docker のパッケージ リポジトリをセットアップ ` -2. 最新の `DEB パッケージ `_ をダウンロード +2. 最新の `DEB パッケージ `_ をダウンロード 3. 以下のように apt でパッケージをインストール： .. code-block:: bash diff --git a/desktop/install/windows-install.rst b/desktop/install/windows-install.rst index f10f0144e..1200c5e17 100644 --- a/desktop/install/windows-install.rst +++ b/desktop/install/windows-install.rst @@ -9,7 +9,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: ./images/whale-x.png - :scale: 50% + :width: 50% .. Install Docker Desktop on Windows @@ -241,7 +241,7 @@ Docker Desktop のスタート インストール後の Docker Desktop は、自動的に起動できません。Docker Desktop を開始するには、以下の手順を進めます。 .. image:: ./images/docker-app-search.png - :scale: 60% + :width: 60% :alt: Docker アプリを探す .. The Docker menu (whale menu) displays the Docker Subscription Service Agreement window. It includes a change to the terms of use for Docker Desktop. diff --git a/desktop/mac/index.rst b/desktop/mac/index.rst index 03446ff79..b5ab1f20e 100644 --- a/desktop/mac/index.rst +++ b/desktop/mac/index.rst @@ -9,7 +9,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: ./images/whale-x.png - :scale: 50% + :width: 50% .. Docker Desktop for Mac user manual .. _docker-desktop-for-mac-user-manual: @@ -53,7 +53,7 @@ General（一般的な設定） ------------------------------ .. image:: ./images/prefs-genral.png - :scale: 60% + :width: 60% :alt: 設定 .. On the General tab, you can configure when to start Docker and specify other settings: @@ -107,7 +107,7 @@ ADVANCED（高度な設定） **Advanced** タブでは、 Docker が利用できるリソースを制限します。 .. image:: ./images/prefs-advanced.png - :scale: 60% + :width: 60% :alt: 高度な設定 @@ -621,7 +621,7 @@ Docker Desktopで Docker Hub アカウントでサインインする前に、 Do 3. サインインに成功すると、 Docker Desktop は authentication code（認証コード）の入力を求めてきます。電話に送られた６ケタのコードを入力し、 **Verify** をクリックします。 .. image:: ./images/desktop-mac-2fa.png - :scale: 60% + :width: 60% :alt: Docker Desktop 二要素認証 .. After you have successfully authenticated, you can access your organizations and repositories directly from the Docker Desktop menu. @@ -641,7 +641,7 @@ Docker Desktop 4.2 リリースから、Docker Desktop をアクティブに使 Docker メニュー ( |whale| ) から、 **Pause** を選択して Docker Desktop を一時停止します。 .. image:: ./images/menu/prefs.png - :scale: 60% + :width: 60% :alt: Docker のメニュー項目 .. Docker Desktop now displays the paused status on the Docker menu and on the Containers / Apps, Images, Volumes, and Dev Environment screens on the Docker Dashboard. You can still access the Preferences and the Troubleshoot menu from the Dashboard when you’ve paused Docker Desktop. diff --git a/desktop/settings/linux.rst b/desktop/settings/linux.rst index cca760423..d5db0f0ab 100644 --- a/desktop/settings/linux.rst +++ b/desktop/settings/linux.rst @@ -7,7 +7,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: /desktop/install/images/whale-x.png - :scale: 50% + :width: 50% .. Change Docker Desktop preferences on Linux .. _change-docker-desktop-preferences-on-linux: diff --git a/desktop/settings/mac.rst b/desktop/settings/mac.rst index 984c3dc2a..42b041fee 100644 --- a/desktop/settings/mac.rst +++ b/desktop/settings/mac.rst @@ -7,7 +7,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: /desktop/install/images/whale-x.png - :scale: 50% + :width: 50% .. Change Docker Desktop preferences on Mac .. _change-docker-desktop-preferences-on-mac: diff --git a/desktop/settings/windows.rst b/desktop/settings/windows.rst index ca497c871..1f9c77ef8 100644 --- a/desktop/settings/windows.rst +++ b/desktop/settings/windows.rst @@ -7,7 +7,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: /desktop/install/images/whale-x.png - :scale: 50% + :width: 50% .. Change Docker Desktop preferences on Windows .. _change-docker-desktop-preferences-on-windows: diff --git a/desktop/troubleshoot/known-issues.rst b/desktop/troubleshoot/known-issues.rst index 7261146b3..456b92be0 100644 --- a/desktop/troubleshoot/known-issues.rst +++ b/desktop/troubleshoot/known-issues.rst @@ -7,7 +7,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: /desktop/install/images/whale-x.png - :scale: 50% + :width: 50% .. Known issues for Docker Desktop on Mac .. _desktop-known-issues-for-docker-desktop-on-mac: diff --git a/desktop/troubleshoot/overview.rst b/desktop/troubleshoot/overview.rst index dcb9e949f..660004254 100644 --- a/desktop/troubleshoot/overview.rst +++ b/desktop/troubleshoot/overview.rst @@ -7,7 +7,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: /desktop/install/images/whale-x.png - :scale: 50% + :width: 50% .. Overview .. _desktop-troubleshoot-overview: @@ -53,7 +53,7 @@ * Docker ダッシュボードから **Troubleshoot** アイコンを選ぶ .. image:: ../images/troubleshoot.png - :scale: 60% + :width: 60% :alt: Docker Desktop のトラブルシュート @@ -106,7 +106,7 @@ Mac ユーザの場合、Docker Desktop をシステム上から **Uninstall** 1. **Troubleshoot** から **Get support** を選びます。これはアプリ内の **Support** ページを開き、診断情報の収集を開始します。 .. image:: ../images/diagnose-support.png - :scale: 60% + :width: 60% :alt: 診断とフィードバック .. When the diagnostics collection process is complete, click Upload to get a Diagnostic ID. diff --git a/desktop/troubleshoot/topics.rst b/desktop/troubleshoot/topics.rst index 7fe8878e2..8eb02dd66 100644 --- a/desktop/troubleshoot/topics.rst +++ b/desktop/troubleshoot/topics.rst @@ -7,7 +7,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: /desktop/install/images/whale-x.png - :scale: 50% + :width: 50% .. Troubleshoot topics .. _desktop-troubleshoot-topics: @@ -224,7 +224,7 @@ Docker Desktop でも適切な形式で Unix 風のパスを指定できます $ docker run --rm -ti -v /c/Users/user/work:/work alpine ls /work .. Working with Git Bash -.. _.. _desktop-topics-windows-working-with-git-bash: +.. _desktop-topics-windows-working-with-git-bash: Git Bash で動かす ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -347,7 +347,7 @@ Windows 10 Pro や Enterprise では、以下の機能を有効にして Hyper-V 3. Windows 起動時にハイパーバイザーを有効化 .. image:: ../images/hyperv-enabled.png - :scale: 60% + :width: 60% :alt: Windows 機能の Hyper-V .. Docker Desktop requires Hyper-V as well as the Hyper-V Module for Windows Powershell to be installed and enabled. The Docker Desktop installer enables it for you. @@ -377,7 +377,7 @@ Hyper-V を手動でインストールするには、 `Windows 10 上に Hyper-V :ref:`Hyper-V ` や :doc:`WSL 2 ` を追加するには、仮想化の有効化が必要です。タスクマネージャー上のパフォーマンス タブをクリックします。 .. image:: ../images/virtualization-enabled.png - :scale: 60% + :width: 60% :alt: タスクマネージャー .. If you manually uninstall Hyper-V, WSL 2 or disable virtualization, Docker Desktop cannot start. See Unable to run Docker for Windows on Windows 10 Enterprise. diff --git a/desktop/troubleshoot/workarounds.rst b/desktop/troubleshoot/workarounds.rst index 46dd026f7..b371abcae 100644 --- a/desktop/troubleshoot/workarounds.rst +++ b/desktop/troubleshoot/workarounds.rst @@ -7,7 +7,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: /desktop/install/images/whale-x.png - :scale: 50% + :width: 50% .. Workarounds for common problems .. _desktop-workarounds-for-common-problems: diff --git a/desktop/use-desktop/container.rst b/desktop/use-desktop/container.rst index 2db2a5d07..33bd58eb9 100644 --- a/desktop/use-desktop/container.rst +++ b/desktop/use-desktop/container.rst @@ -7,7 +7,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: /desktop/install/images/whale-x.png - :scale: 50% + :width: 50% .. Explore Containers .. _explore-containers: diff --git a/desktop/use-desktop/images.rst b/desktop/use-desktop/images.rst index 74c15c4ef..1618faf67 100644 --- a/desktop/use-desktop/images.rst +++ b/desktop/use-desktop/images.rst @@ -7,7 +7,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: /desktop/install/images/whale-x.png - :scale: 50% + :width: 50% .. Explore Images .. _explore-images: diff --git a/desktop/use-desktop/index.rst b/desktop/use-desktop/index.rst index 956125636..f1c1cb0a6 100644 --- a/desktop/use-desktop/index.rst +++ b/desktop/use-desktop/index.rst @@ -7,7 +7,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: /desktop/install/images/whale-x.png - :scale: 50% + :width: 50% .. Overview .. _docker-desktop-overview: @@ -27,7 +27,7 @@ Docker Desktop を開くと、 Docker ダッシュボードが表示されます。 .. image:: ../images/dashboard.png - :scale: 60% + :width: 60% :alt: Docker Desktop ダッシュボード .. The Containers view provides a runtime view of all your containers and applications. It allows you to interact with containers and applications, and manage the lifecycle of your applications directly from your machine. This view also provides an intuitive interface to perform common actions to inspect, interact with, and manage your Docker objects including containers and Docker Compose-based applications. For more information, see Explore running containers and applications. diff --git a/desktop/use-desktop/pause.rst b/desktop/use-desktop/pause.rst index 7fb310c44..a47669582 100644 --- a/desktop/use-desktop/pause.rst +++ b/desktop/use-desktop/pause.rst @@ -7,7 +7,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: /desktop/install/images/whale-x.png - :scale: 50% + :width: 50% .. Pause Docker Desktop .. _pause-docker-desktop: diff --git a/desktop/use-desktop/volumes.rst b/desktop/use-desktop/volumes.rst index 2d8635c03..ed7875ebf 100644 --- a/desktop/use-desktop/volumes.rst +++ b/desktop/use-desktop/volumes.rst @@ -7,7 +7,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: /desktop/install/images/whale-x.png - :scale: 50% + :width: 50% .. Explore Volumes .. _explore-volumes: diff --git a/desktop/windows/index.rst b/desktop/windows/index.rst index 1c3d6f01b..eaf86e914 100644 --- a/desktop/windows/index.rst +++ b/desktop/windows/index.rst @@ -9,7 +9,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: ./images/whale-x.png - :scale: 50% + :width: 50% .. Docker Desktop for Windows user manual .. _docker-desktop-for-windows-user-manual: @@ -55,7 +55,7 @@ Settings （設定） 1.　Docker Desktop のメニューを開くには、通知エリア（又はシステムトレイ）にある Docker アイコンをクリックします。 .. image:: ./images/whale-icon-systray-hidden.png - :scale: 60% + :width: 60% :alt: タスクバー内に隠れているアプリを表示 .. Showing hidden apps in the taskbar @@ -65,7 +65,7 @@ Settings （設定） .. Select Settings to open the Settings dialog: .. image:: ./images/docker-menu-settings.png - :scale: 60% + :width: 60% :alt: タスクバー内に隠れているアプリを表示 .. General @@ -78,7 +78,7 @@ General（一般的な設定） 設定画面の **General** タブでは、Docker の起動や他の設定を調整できます。 .. image:: ./images/settings-general.png - :scale: 60% + :width: 60% :alt: 設定 .. Start Docker when you log in: Select this option to automatically start Docker Desktop when you log into your Windows machine. @@ -604,7 +604,7 @@ Docker Desktop を :ruby:`一時停止 ` するには、通知エリア .. image:: ./images/docker-menu-pause.png - :scale: 60% + :width: 60% :alt: Docker のメニュー項目 .. Docker Desktop now displays the paused status on the Docker menu and on the Containers / Apps, Images, Volumes, and Dev Environment screens on the Docker Dashboard. You can still access the Preferences and the Troubleshoot menu from the Dashboard when you’ve paused Docker Desktop. diff --git a/desktop/windows/troubleshoot.rst b/desktop/windows/troubleshoot.rst index ec727b306..4dfca829d 100644 --- a/desktop/windows/troubleshoot.rst +++ b/desktop/windows/troubleshoot.rst @@ -9,7 +9,7 @@ .. ----------------------------------------------------------------------------- .. |whale| image:: ./images/whale-x.png - :scale: 50% + :width: 50% .. Logs and troubleshooting .. _win-logs-and-troubleshooting: @@ -47,7 +47,7 @@ メニューバーにある Docker のアイコン |whale| > **Troubleshoot** を選択し、トラブルシュートのオプションを表示します。 .. image:: ./images/troubleshoot.png - :scale: 60% + :width: 60% :alt: Docker Desktop のトラブルシュート @@ -106,7 +106,7 @@ 3. **Get support** をクリック。これはアプリ内の **Support** ページを開き、診断情報の収集を開始します。 .. image:: ./images/diagnose-support.png - :scale: 60% + :width: 60% :alt: 診断とフィードバック .. When the diagnostics collection process is complete, click Upload to get a Diagnostic ID. @@ -456,7 +456,7 @@ Windows 10 Pro や Enterprise では、以下の機能を有効にして Hyper-V 3. Windows 起動時にハイパーバイザーを有効化 .. image:: ./images/hyperv-enabled.png - :scale: 60% + :width: 60% :alt: Windows 機能の Hyper-V .. Docker Desktop requires Hyper-V as well as the Hyper-V Module for Windows Powershell to be installed and enabled. The Docker Desktop installer enables it for you. @@ -486,7 +486,7 @@ Hyper-V を手動でインストールするには、 `Windows 10 上に Hyper-V :ref:`Hyper-V ` や :doc:`WSL 2 ` を追加するには、仮想化の有効化が必要です。タスクマネージャー上のパフォーマンス タブをクリックします。 .. image:: ./images/virtualization-enabled.png - :scale: 60% + :width: 60% :alt: タスクマネージャー .. If you manually uninstall Hyper-V, WSL 2 or disable virtualization, Docker Desktop cannot start. See Unable to run Docker for Windows on Windows 10 Enterprise. diff --git a/desktop/windows/wsl.rst b/desktop/windows/wsl.rst index 33447f19c..8884002d0 100644 --- a/desktop/windows/wsl.rst +++ b/desktop/windows/wsl.rst @@ -87,7 +87,7 @@ Docker Desktop をインストールする **前に** 、動作条件のセク .. Enable WSL 2 .. image:: ./images/wsl2-enable.png - :scale: 60% + :width: 60% :alt: WSL 2 の有効化 .. Select the Use WSL 2 based engine check box. @@ -174,7 +174,7 @@ Docker Desktop では何らかの Linux ディストリビューションをイ .. WSL 2 Choose Linux distro .. image:: ./images/wsl2-choose-distro.png - :scale: 60% + :width: 60% :alt: WSL 2 で Linux ディストリビューションを選択 .. Click Apply & Restart. diff --git a/develop/dev-best-practices.rst b/develop/dev-best-practices.rst index 7b9a93a86..881130920 100644 --- a/develop/dev-best-practices.rst +++ b/develop/dev-best-practices.rst @@ -1,9 +1,9 @@ .. -*- coding: utf-8 -*- .. URL: https://docs.docker.com/develop/dev-best-practices/ - doc version: 19.03 + doc version: 24.0 https://github.com/docker/docker.github.io/blob/master/develop/dev-best-practices.md -.. check date: 2022/09/20 -.. Commits on Nov 7, 2020 5b6824c105c37510a635f820c6c50fef16a0aedb +.. check date: 2023/07/22 +.. Commits on Jul 4, 2023 b6f5256248bd77fcec2f9d44e6a1123d0ebc4ab0 .. ----------------------------------------------------------------------------- .. Docker development best practices @@ -35,29 +35,27 @@ Docker 開発ベストプラクティス .. Start with an appropriate base image. For instance, if you need a JDK, consider basing your image on the official openjdk image, rather than starting with a generic ubuntu image and installing openjdk as part of the Dockerfile. -* 適切なベースイメージで始めましょう。たとえば、 JDK が必要なら、一般的な ``ubuntu`` イメージに ``openjdk`` をインストールするのではなく、公式 ``openjdk`` イメージをベースにするのを検討します。 +* 適切なベースイメージで始めましょう。例えば、 JDK が必要なら、一般的な ``ubuntu`` イメージに ``openjdk`` をインストールするのではなく、公式 ``openjdk`` イメージをベースにするのを検討します。 .. Use multistage builds. For instance, you can use the maven image to build your Java application, then reset to the tomcat image and copy the Java artifacts into the correct location to deploy your app, all in the same Dockerfile. This means that your final image doesn’t include all of the libraries and dependencies pulled in by the build, but only the artifacts and the environment needed to run them. - -* :doc:`マルチステージ・ビルドを使います ` 。たとえば、 Java アプリケーションを構築するにあたり ``maven`` イメージを使えるとします。その時、アプリをデプロイするためには、 ``tomcat`` イメージをリセットし、Java アーティファクトを適切な場所にコピーします。これらすべてが、同じ Dockerfile 中の命令としてあります。これが意味するのは、最終イメージには構築時に取得した全てのライブラリや依存関係は含みませんが、アーティファクトと実行に必要な環境変数のみが入っています。 - .. If you need to use a version of Docker that does not include multistage builds, try to reduce the number of layers in your image by minimizing the number of separate RUN commands in your Dockerfile. You can do this by consolidating multiple commands into a single RUN line and using your shell’s mechanisms to combine them together. Consider the following two fragments. The first creates two layers in the image, while the second only creates one. +* :doc:`マルチステージ・ビルドを使います ` 。例えば、 Java アプリケーションを構築するにあたり ``maven`` イメージを使えるとします。その時、アプリをデプロイするためには、 ``tomcat`` イメージをリセットし、Java アーティファクトを適切な場所にコピーします。これらすべてが、同じ Dockerfile 中の命令としてあります。これが意味するのは、最終イメージには構築時に取得した全てのライブラリや依存関係は含みませんが、アーティファクトと実行に必要な環境変数のみが入っています。 * もしも使用中の Docker がマルチステージ・ビルドに対応していないバージョンであれば、イメージのレイヤ数を減らすため、Dockerfile 中でバラバラの ``RUN`` 命令の数を最小化します。この作業時に、シェルの仕組みを使って複数の ``RUN`` 命令を1つにまとめられます。以下にある1つめのイメージには２つのレイヤがありますが、2つめのイメージは１つのレイヤしかありません。 - .. code-block:: bash - - RUN apt-get -y update - RUN apt-get install -y python - - .. code-block:: bash - - RUN apt-get -y update && apt-get install -y python + .. code-block:: bash + + RUN apt-get -y update + RUN apt-get install -y python + + .. code-block:: bash + + RUN apt-get -y update && apt-get install -y python .. If you have multiple images with a lot in common, consider creating your own base image with the shared components, and basing your unique images on that. Docker only needs to load the common layers once, and they are cached. This means that your derivative images use memory on the Docker host more efficiently and load more quickly. -* もしも、複数のイメージで共通している箇所が多いようであれば、共通コンポーネントが入った :doc:`ベース・イメージ ` を作成し、それを自分が使う独自イメージのベースにするように検討します。Docker は共通のレイヤを一度読み込む必要がありますが、それらのレイヤはキャッシュされます。つまり、Docker ホスト上で派生するイメージが使うメモリは効率的になり、かつ処理が素早くなります。 +* もしも、複数のイメージで共通している箇所が多いようであれば、共通コンポーネントが入った :doc:`ベース・イメージ ` を作成し、それを自分が使う独自イメージのベースにするように検討します。Docker は共通のレイヤを一度読み込む必要がありますが、それらのレイヤはキャッシュされます。つまり、Docker ホスト上で派生するイメージが使うメモリは効率的になり、かつ処理が素早くなります。 .. To keep your production image lean but allow for debugging, consider using the production image as the base image for the debug image. Additional testing or debugging tooling can be added on top of the production image. @@ -65,7 +63,7 @@ Docker 開発ベストプラクティス .. When building images, always tag them with useful tags which codify version information, intended destination (prod or test, for instance), stability, or other information that is useful when deploying the application in different environments. Do not rely on the automatically-created latest tag. -* イメージの構築時、常に分かりやすいタグを付けます。タグには、バージョン情報の明示、展開先の対象（たとえば ``prod`` や ``test`` ）、安定性、あるいはその他の情報が、様々なアプリケーションをデプロイする時に役立ちます。 +* イメージの構築時、常に分かりやすいタグを付けます。タグには、バージョン情報の明示、展開先の対象（例えば ``prod`` や ``test`` ）、安定性、あるいはその他の情報が、様々なアプリケーションをデプロイするときに役立ちます。自動的に作成される ``latest`` タグに頼らないでください。 .. Where and how to persist application data @@ -79,6 +77,14 @@ Docker 開発ベストプラクティス One case where it is appropriate to use bind mounts is during development, when you may want to mount your source directory or a binary you just built into your container. For production, use a volume instead, mounting it into the same location as you mounted a bind mount during development. For production, use secrets to store sensitive application data used by services, and use configs for non-sensitive data such as configuration files. If you currently use standalone containers, consider migrating to use single-replica services, so that you can take advantage of these service-only features. +* :doc:`ストレージドライバ ` を使うコンテナの書き込み可能なレイヤ内に、アプリケーションのデータを保存 **しないでください** 。これにより、コンテナの容量が増えます。さらに、ボリュームやバインドマウントの利用に比べ、 I/O 観点から効率が良くありません。 + +* その代わり、データの保存には :doc:`ボリューム ` を使います。 + +* :doc:`バインドマウント ` の使用がふさわしい場面は、ソースディレクトリやバイナリをそのままコンテナ内にマウントしたい開発段階です。プロダクションでは、代わりにボリュームを使い、開発段階でバインドマウントしたのと同じ場所へマウントします。 + +* プロダクションでは、サービスによって使われる機微なアプリケーションデータを保管するのに :doc:`シークレット ` を使います。また機微ではないデータのためには :doc:`コンフィグ ` を使います。現時点でスタンドアロンなコンテナを使っている場合、 :ruby:`単一から複数 ` のサービスへの移行を検討すると、サービスのみが利用できる機能を活用できるようになります。 + .. Use CI/CD for testing and deployment .. _use ci/cd for testing and deployment: @@ -88,11 +94,11 @@ Docker 開発ベストプラクティス .. When you check in a change to source control or create a pull request, use Docker Hub or another CI/CD pipeline to automatically build and tag a Docker image and test it. -* ソースコントロールに対する変更処理、あるいはプルリクエスト作成を処理する時、 `Docker Hub `_ や他の CI/CD パイプラインを使い、Docker イメージの自動構築やタグ付け、テストを行えます。 +* ソースコントロールに対する変更処理、あるいはプルリクエスト作成を処理するとき、 :doc:`Docker Hub ` や他の CI/CD パイプラインを使い、Docker イメージの自動構築やタグ付け、テストを行えます。 .. Take this even further by requiring your development, testing, and security teams to sign images before they are deployed into production. This way, before an image is deployed into production, it has been tested and signed off by, for instance, development, quality, and security teams. -* プロダクションにデプロイする前に、開発、テスト、セキュリティチームが :doc:`イメージへの署名 ` が必要となるでしょう。その場合は、イメージをプロダクションにデプロイする前に、たとえば開発、品質およびセキュリティチームによって、イメージのテストを署名をします。 +* プロダクションにデプロイする前に、開発、テスト、セキュリティチームが :doc:`イメージへの署名 ` が必要となるでしょう。その場合は、イメージをプロダクションにデプロイする前に、例えば開発、品質及びセキュリティチームによって、イメージのテストを署名をします。 .. Differences in development and production environments diff --git a/develop/develop-images/dockerfile_best-practices.rst b/develop/develop-images/dockerfile_best-practices.rst index dd07bf96a..42f5eb284 100644 --- a/develop/develop-images/dockerfile_best-practices.rst +++ b/develop/develop-images/dockerfile_best-practices.rst @@ -1,16 +1,16 @@ .. -*- coding: utf-8 -*- .. URL: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/ - doc version: 20.10 + doc version: 24.0 https://github.com/docker/docker.github.io/blob/master/develop/develop-images/dockerfile_best-practices.md -.. check date: 2022/09/20 -.. Commits on Jun 24, 2022 67e9850c776071d486d811c52f1095dd87c00f29 +.. check date: 2023/07/22 +.. Commits on Jun 22, 2023 a1c30d0af927f7f4e90f5d2d426d99846c7221a0 .. ----------------------------------------------------------------------------- .. Best practices for writing Dockerfile .. _best-practices-for-writing-dockerfile: ======================================= -Dockerfile のベスト・プラクティス +Dockerfile を書くベストプラクティス ======================================= .. sidebar:: 目次 @@ -19,22 +19,22 @@ Dockerfile のベスト・プラクティス :depth: 3 :local: -.. This document covers recommended best practices and methods for building efficient images. +.. This topic covers recommended best practices and methods for building efficient images. -このドキュメントで扱うのは、効率的なイメージ構築を目的とした、ベストプラクティスと手法のアドバイスです。 +このトピックでは、効率的なイメージ構築を目的とした、ベストプラクティスと手法についてのアドバイスを扱います。 .. Docker builds images automatically by reading the instructions from a Dockerfile -- a text file that contains all commands, in order, needed to build a given image. A Dockerfile adheres to a specific format and set of instructions which you can find at Dockerfile reference. -Docker は ``Dockerfile`` に書かれた命令を読み込み、自動的にイメージを :ruby:`構築 ` します。この ``Dockerfile`` とはテキスト形式のファイルであり、イメージを構築するために必要となる、全ての命令を順番通りに記述します。 ``Dockerfile`` は特定の書式と命令群に忠実であり、それらは :doc:`Dockerfile リファレンス ` で確認できます。 +Docker は Dockerfile に書かれた命令を読み込み、自動的にイメージを :ruby:`構築 ` します。この Dockerfile とはテキスト形式のファイルであり、イメージを構築するために必要となる、全ての命令を順番通りに記述します。 ``Dockerfile`` は特定の書式と命令群に忠実であり、それらは :doc:`Dockerfile リファレンス ` で確認できます。 -.. A Docker image consists of read-only layers each of which represents a Dockerfile instruction. The layers are stacked and each one is a delta of the changes from the previous layer. Consider this Dockerfile: +.. A Docker image consists of read-only layers each of which represents a Dockerfile instruction. The layers are stacked and each one is a delta of the changes from the previous layer. The following is the contents of an example Dockerfile: -Docker イメージを構成するのは、 Dockerfile の各命令に相当する、読み込み専用のレイヤ群です。それぞれのレイヤは直前のレイヤから変更した差分であり、これらのレイヤが積み重なっています。次の ``Dockerfile`` を見ましょう。 +Docker イメージを構成するのは、 Dockerfile の各命令に相当する、読み込み専用のレイヤ群です。それぞれのレイヤは直前のレイヤから変更した差分であり、これらのレイヤが積み重なっています。以下は Dockerfile 例の内容です。 .. code-block:: bash # syntax=docker/dockerfile:1 - FROM ubuntu:18.04 + FROM ubuntu:22.04 COPY . /app RUN make /app CMD python /app/app.py @@ -43,23 +43,23 @@ Docker イメージを構成するのは、 Dockerfile の各命令に相当す 命令ごとに１つのレイヤを作成します。 -.. FROM creates a layer from the ubuntu:18.04 Docker image. +.. FROM creates a layer from the ubuntu:22.04 Docker image. COPY adds files from your Docker client’s current directory. RUN builds your application with make. CMD specifies what command to run within the container. -* ``FROM`` は ``ubuntu:18.04`` の Docker イメージからレイヤを作成 +* ``FROM`` は ``ubuntu:22.04`` の Docker イメージからレイヤを作成 * ``COPY`` は Docker クライアントで操作しているディレクトリから、ファイルを（コンテナのレイヤに）追加 * ``RUN`` はアプリケーションを ``make`` で構築 * ``CMD`` はコンテナ内で何のコマンドを実行するか指定 -.. When you run an image and generate a container, you add a new writable layer (the “container layer”) on top of the underlying layers. All changes made to the running container, such as writing new files, modifying existing files, and deleting files, are written to this writable container layer. +.. When you run an image and generate a container, you add a new writable layer, also called the container layer, on top of the underlying layers. All changes made to the running container, such as writing new files, modifying existing files, and deleting files, are written to this writable container layer. -イメージを実行し、コンテナを生成すると、元のレイヤ上に新しい *書き込み可能なレイヤ（writable layer）* （これが「 :ruby:`コンテナ・レイヤ ` 」です）を追加します。実行中のコンテナに対する全ての変更、たとえば新しいファイル書き込み、既存ファイルの編集、ファイルの削除などは、この書き込み可能なコンテナ・レイヤ内に記述されます。 +イメージを実行してコンテナを生成するとき、元から存在するレイヤ上に新しい :ruby:`書き込み可能なレイヤ ` を追加します。これは :ruby:`コンテナ・レイヤ ` とも呼ばれます。実行中のコンテナに対する全ての変更、例えば新しいファイル書き込み、既存ファイルの編集、ファイルの削除などは、この書き込み可能なコンテナ・レイヤ内に記述されます。 -.. For more on image layers (and how Docker builds and stores images), see About storage drivers. +.. For more on image layers and how Docker builds and stores images, see About storage drivers. -イメージ・レイヤに関する詳しい情報（さらに Docker のイメージ構築と保存の仕方について）は、 :doc:`ストレージ・ドライバについて ` をご覧ください。 +イメージ・レイヤに関する詳しい情報や、 Docker のイメージ構築と保存の仕方は、 :doc:`ストレージ・ドライバについて ` を御覧ください。 .. General guidelines and recommendations @@ -75,9 +75,9 @@ Docker イメージを構成するのは、 Dockerfile の各命令に相当す 一時的なコンテナを作成 ------------------------------ -.. The image defined by your Dockerfile should generate containers that are as ephemeral as possible. By “ephemeral”, we mean that the container can be stopped and destroyed, then rebuilt and replaced with an absolute minimum set up and configuration. +.. The image defined by your Dockerfile should generate containers that are as ephemeral as possible. Ephemeral means that the container can be stopped and destroyed, then rebuilt and replaced with an absolute minimum set up and configuration. -``Dockerfile`` で定義したイメージによって生成するコンテナは、可能な限り一時的（ephemeral）であるべきです。「一時的」が意味するのは、コンテナは停止および破棄可能であり、その後も極めて最小限のセットアップと設定により、再構築や置き換えが可能だからです。 +Dockerfile で定義したイメージによって生成するコンテナは、可能な限り一時的（ :ruby:`エフェメラル ` ）であるべきです。一時的が意味するのは、コンテナとは停止および破棄可能であり、その後も極めて最小限のセットアップと設定により、再構築や置き換えが可能だからです。 .. Refer to Processes under The Twelve-factor App methodology to get a feel for the motivations of running containers in such a stateless fashion. @@ -87,54 +87,24 @@ Docker イメージを構成するのは、 Dockerfile の各命令に相当す .. _understand-build-context: -ビルド・コンテクストの理解 +ビルド コンテクストの理解 ------------------------------ -.. When you issue a docker build command, the current working directory is called the build context. By default, the Dockerfile is assumed to be located here, but you can specify a different location with the file flag (-f). Regardless of where the Dockerfile actually lives, all recursive contents of files and directories in the current directory are sent to the Docker daemon as the build context. +.. See Build context for more information. -``docker build`` コマンドを実行するとき、 :ruby:`現在作業しているディレクトリ ` を *ビルド・コンテクスト（buid context）* と呼びます。デフォルトでは、コマンドを実行した場所に Dockerfile がある想定です。ただし、フラグ（ ``-f`` ）の指定によって違う場所も指定できます。 ``Dockerfile`` がどこにあるかに関係なく、現在のディレクトリ以下にある再帰的なファイルとディレクトリを、すべて Docker デーモンに対してビルド・コンテクストとして送信します。 +詳しい情報は :doc:`ビルド コンテクスト ` を御覧ください。 -.. Build context example -.. Create a directory for the build context and cd into it. Write “hello” into a text file named hello and create a Dockerfile that runs cat on it. Build the image from within the build context (.): -.. Move Dockerfile and hello into separate directories and build a second version of the image (without relying on cache from the last build). Use -f to point to the Dockerfile and specify the directory of the build context: - -.. note:: **ビルド・コンテクストの例** - - ビルド・コンテクスト用のディレクトリを作成し、 ``cd`` で中に移動します。文字「hello」を ``hello`` という名前のテキストファイルに書き込み、それから、そのファイルを ``cat`` で実行する ``Dockerfile`` を作成します。そして、ビルド・コンテクスト（ ``.`` ）内からイメージを構築します。 - - .. code-block:: bash - - $ mkdir myproject && cd myproject - $ echo "hello" > hello - $ echo -e "FROM busybox\nCOPY /hello /\nRUN cat /hello" > Dockerfile - $ docker build -t helloapp:v1 . - - ``Dockerfile`` と ``hello`` を離れたディレクトリに移動し、第2バージョンのイメージを構築します（先ほどのイメージ構築による、キャッシュに依存しないようにするためです）。 Dockerfile の場所とビルド・コンテクストのディレクトリを指定には ``-f`` を使います。 - - .. code-block:: bash - - $ mkdir -p dockerfiles context - $ mv Dockerfile dockerfiles && mv hello context - $ docker build --no-cache -t helloapp:v2 -f dockerfiles/Dockerfile context - -.. Inadvertently including files that are not necessary for building an image results in a larger build context and larger image size. This can increase the time to build the image, time to pull and push it, and the container runtime size. To see how big your build context is, look for a message like this when building your Dockerfile: - -イメージ構築に不要なファイルをうっかり含んでしまうと、ビルド・コンテクストが肥大化し、イメージの容量が大きくなってしまいます。これによりイメージの構築時間が増えるだけでなく、 pull や push の時間が延び、コンテナランタイムの容量も大きくなります。ビルド・コンテクストの容量を調べるには、 ``Dockerfile`` を構築時に表示される次のようなメッセージで確認します： - -.. code-block:: bash - - Sending build context to Docker daemon 187.8MB .. Pipe Dockerfile through stdin .. _pipe-dockerfile-through-stdin: -``stdin`` を通して Dockerfile をパイプ +標準入力を通して Dockerfile をパイプ ---------------------------------------- -.. Docker has the ability to build images by piping Dockerfile through stdin with a local or remote build context. Piping a Dockerfile through stdin can be useful to perform one-off builds without writing a Dockerfile to disk, or in situations where the Dockerfile is generated, and should not persist afterwards. +.. Docker has the ability to build images by piping a Dockerfile through stdin with a local or remote build context. Piping a Dockerfile through stdin can be useful to perform one-off builds without writing a Dockerfile to disk, or in situations where the Dockerfile is generated, and should not persist afterwards. -ローカルもしくはリモートのビルド・コンテクストを使い、 ``stdin`` （標準入力）を通して ``Dockerfile`` をパイプすると、イメージを構築する機能が Docker にはあります。 ``stdin`` を通して ``Dockerfile`` をパイプすると、Dockerfile をディスクに書き込まないため、一回限りの構築を行いたい時に役立ちます。あるいは、 ``Dockerfile`` が生成された場所が、後で残らない状況でも役立つでしょう。 +ローカル若しくはリモートのビルド・コンテクストを使い、標準入力（stdin）を通した Dockerfile のパイプにより、イメージを構築する機能が Docker にはあります。標準入力を通して Dockerfile をパイプすると、Dockerfile をディスクに書き込まないため、一回限りの構築を行いたい時に役立ちます。あるいは、 Dockerfile が生成された場所が、後で残らない状況でも役立つでしょう。 .. The examples in this section use here documents for convenience, but any method to provide the Dockerfile on stdin can be used. .. For example, the following commands are equivalent: @@ -145,7 +115,7 @@ Docker イメージを構成するのは、 Dockerfile の各命令に相当す **このセクションで扱う例は、便宜上** `ヒア・ドキュメント `_ **を扱いますが、** ``Dockerfile`` **には** ``stdin`` **を使う様々な手法が利用できます** 。 - たとえば、以下のコマンドは、どちらも同じ処理をします。 + 例えば、以下のコマンドは、どちらも同じ処理をします。 .. code-block:: bash @@ -167,7 +137,9 @@ Docker イメージを構成するのは、 Dockerfile の各命令に相当す ビルド・コンテクストを送信せず、stdin からの Dockerfile を使ってイメージ構築 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -以下の構文を使うと、 ``stdin`` からの ``Dockerfile`` を使ってイメージを構築するため、ビルド・コンテクストとして送信するために、ファイルの追加が不要です。ハイフン（ ``-`` ）が意味するのは ``PATH`` に替わるもので、ディレクトリの代わりに ``stdin`` からのビルド・コンテクスト（ ``Dockerfile`` だけを含みます ）を読み込むよう、 Docker に命令します。 +.. Use this syntax to build an image using a Dockerfile from stdin, without sending additional files as build context. The hyphen (-) takes the position of the PATH, and instructs Docker to read the build context, which only contains a Dockerfile, from stdin instead of a directory: + +以下の構文を使えば、標準入力から Dockerfile を使ってイメージを構築するため、ビルド・コンテクストとして送信するファイルの追加が不要です。ハイフン（ ``-`` ）が意味するのは ``PATH`` に替わるもので、ディレクトリの代わりに標準入力から Dockerfile だけを含むビルド・コンテクストを読み込むよう、 Docker に命令します。 .. code-block:: bash @@ -175,7 +147,7 @@ Docker イメージを構成するのは、 Dockerfile の各命令に相当す .. The following example builds an image using a Dockerfile that is passed through stdin. No files are sent as build context to the daemon. -以下のイメージ構築例は、 ``stdin`` を通して渡された ``Dockerfile`` を使います。ビルド・コンテクストとしては、デーモンには一切ファイルを送信しません。 +以下のイメージ構築例は、標準入力を通して渡された Dockerfile を使います。ビルド・コンテクストとしては、デーモンには一切ファイルを送信しません。 .. code-block:: bash @@ -184,19 +156,19 @@ Docker イメージを構成するのは、 Dockerfile の各命令に相当す RUN echo "hello world" EOF -.. Omitting the build context can be useful in situations where your Dockerfile does not require files to be copied into the image, and improves the build-speed, as no files are sent to the daemon. +.. Omitting the build context can be useful in situations where your Dockerfile doesn’t require files to be copied into the image, and improves the build-speed, as no files are sent to the daemon. -デーモンに対してファイルを一切送信しないため、``Dockerfile`` をイメージの中にコピーする必要がない状況や、構築速度を改善するために、このようなビルド・コンテクストの省略が役立ちます。 +デーモンに対してファイルを一切送信しないため、Dockerfileをイメージの中にコピーする必要がない状況や、構築速度を改善するために、このようなビルド・コンテクストの省略が役立ちます。 .. If you want to improve the build-speed by excluding some files from the build- context, refer to exclude with .dockerignore. ビルド・コンテクストから不要なファイルを除外し、構築速度の改善をしたければ、 :ref:`.dockerignore で除外 ` を参照ください。 -.. Note: Attempting to build a Dockerfile that uses COPY or ADD will fail if this syntax is used. The following example illustrates this: +.. If you attempt build an image using a Dockerfile from stdin, without sending build context, then the build will fail if you use COPY or ADD. The following example illustrates this: .. note:: - 標準入力の Dockerfile で ``COPY`` や ``ADD`` 構文を使おうとしても、構築できません。以下の例は失敗します。 + イメージの構築にあたり、ビルド・コンテクストを送信しない標準入力の Dockerfile で ``COPY`` や ``ADD`` 構文を使おうとしても、構築できません。以下の例は失敗します。 .. code-block:: bash @@ -225,9 +197,9 @@ Docker イメージを構成するのは、 Dockerfile の各命令に相当す ローカルのビルド・コンテクストとして、stdin からの Dockerfile を読み込んで構築 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -.. Use this syntax to build an image using files on your local filesystem, but using a Dockerfile from stdin. The syntax uses the -f (or --file) option to specify the Dockerfile to use, using a hyphen (-) as filename to instruct Docker to read the Dockerfile from stdin: +.. Use this syntax to build an image using files on your local filesystem, but using a Dockerfile from stdin. The syntax uses the -f (or --file) option to specify the Dockerfile to use, and it uses a hyphen (-) as filename to instruct Docker to read the Dockerfile from stdin: -ローカル・ファイルシステム上ファイルを使って構築する構文には、 ``stdin`` からの ``Dockerfile`` を使います。この構文では、 ``-f`` （あるいは ``--file`` ）オプションで、使用する ``Dockerfile`` を指定します。そして、ファイル名としてハイフン（ ``-`` ）を使い、Docker には ``stdin`` から ``Dockerfile`` を読み込むように命令します。 +ローカル・ファイルシステム上ファイルを使って構築する構文には、標準入力から Dockerfile を使います。この構文では、 ``-f`` （あるいは ``--file`` ）オプションで、使用する Dockerfile を指定します。そして、ファイル名としてハイフン（ ``-`` ）を使い、Docker には標準入力から Dockerfile を読み込むように命令します。 .. code-block:: bash @@ -235,7 +207,7 @@ Docker イメージを構成するのは、 Dockerfile の各命令に相当す .. The example below uses the current directory (.) as the build context, and builds an image using a Dockerfile that is passed through stdin using a here document. -以下の例は、現在のディレクトリ（ ``.`` ）をビルド・コンテクストとして使います。また、イメージの構築には、 ``stdin`` の ` ヒア・ドキュメント `_ を経由する ``Dockerfile`` を使います。 +以下の例は、現在のディレクトリ（ ``.`` ）をビルド・コンテクストとして使います。また、イメージの構築には、標準入力の ` ヒア・ドキュメント `_ を経由する Dockerfile を使います。 .. code-block:: bash @@ -259,12 +231,12 @@ Docker イメージを構成するのは、 Dockerfile の各命令に相当す .. _build-from-a-remote-build-context,-using-a-dockerfile-from-stdin: -stdin から読み込む Dockerfile を使い、リモートのビルド・コンテクストから構築 -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +リモートのビルド・コンテクストから構築するため標準入力から読み込む Dockerfile を使う +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -.. Use this syntax to build an image using files from a remote git repository, using a Dockerfile from stdin. The syntax uses the -f (or --file) option to specify the Dockerfile to use, using a hyphen (-) as filename to instruct Docker to read the Dockerfile from stdin: +.. Use this syntax to build an image using files from a remote Git repository, using a Dockerfile from stdin. The syntax uses the -f (or --file) option to specify the Dockerfile to use, using a hyphen (-) as filename to instruct Docker to read the Dockerfile from stdin: -リモート ``git`` リポジトリにあるファイルを使って構築する構文には、 ``stdin`` からの読む込む ``Dockerfile`` を使います。この構文では、 ``-f`` （あるいは ``--file`` ）オプションで、使用する ``Dockerfile`` を指定します。そして、ファイル名としてハイフン（ ``-`` ）を使い、Docker には ``stdin`` から ``Dockerfile`` を読み込むように命令します。 +リモート Git リポジトリにあるファイルを使って構築する構文には、標準入力から読む込む Dockerfile を使います。この構文では、 ``-f`` （あるいは ``--file`` ）オプションで、使用する Dockerfile を指定します。そして、ファイル名としてハイフン（ ``-`` ）を使い、Docker には標準入力から Dockerfile を読み込むように命令します。 .. code-block:: bash @@ -274,9 +246,10 @@ stdin から読み込む Dockerfile を使い、リモートのビルド・コ この構文が役立つ状況は、 ``Dockerfile`` を含まないリポジトリにあるイメージを構築したい場合や、自分でフォークしたリポジトリを保持することなく、任意の ``Dockerfile`` でビルドしたい場合です。 -.. The example below builds an image using a Dockerfile from stdin, and adds the hello.c file from the “hello-world” Git repository on GitHub. +.. The example below builds an image using a Dockerfile from stdin, and adds the hello.c file from the hello-world repository on GitHub. + -以下のイメージ構築例は ``stdin`` から読み込む ``Dockerfile`` を使い、 `GitHub 上の "hello-wolrd" Git リポジトリ `_ にあるファイル ``hello.c`` を追加します。 +以下のイメージ構築例は、標準入力から読み込む Dockerfile を使い、 `GitHub 上の "hello-wolrd" リポジトリ `_ にあるファイル ``hello.c`` を追加します。 .. code-block:: bash @@ -285,13 +258,12 @@ stdin から読み込む Dockerfile を使い、リモートのビルド・コ COPY hello.c ./ EOF -.. Under the hood -.. When building an image using a remote Git repository as build context, Docker performs a git clone of the repository on the local machine, and sends those files as build context to the daemon. This feature requires git to be installed on the host where you run the docker build command. +.. When building an image using a remote Git repository as build context, Docker performs a git clone of the repository on the local machine, and sends those files as build context to the daemon. This feature requires you to install Git on the host where you run the docker build command. -.. note:: 中の仕組み +.. note:: - リモートの Git リポジトリをビルド・コンテクストに使ってイメージを構築する時に、 Docker はリポジトリの ``git clone`` をローカルマシン上で処理し、これらの取得したファイルをビルド・コンテクストとしてデーモンに送信します。この機能を使うには、 ``docker build`` コマンドを実行するホスト上に ``git`` をインストールする必要があります。 + リモートの Git リポジトリをビルド・コンテクストに使ってイメージを構築する時に、 Docker はリポジトリの ``git clone`` をローカルマシン上で処理し、これらの取得したファイルをビルド・コンテクストとしてデーモンに送信します。この機能を使うには、 ``docker build`` コマンドを実行するホスト上に Git のインストールが必要です。 .. Exclude with .dockerignore @@ -301,9 +273,10 @@ stdin から読み込む Dockerfile を使い、リモートのビルド・コ .dockerignore で除外 ------------------------------ -.. 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. +.. 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 .dockerignore file. + +ソース・リポジトリを再構築しないで、イメージの構築と無関係のファイルを除外するには、 ``.dockerignore`` ファイルを使います。このファイルは ``.gitignore`` と似たような除外パターンをサポートします。ファイルの作成に関する情報は :ref:`.dockerignore ファイル ` を参照してください。 -（ソース・リポジトリを再構築することなく）イメージの構築と無関係のファイルを除外するには、 ``.dockerignore`` ファイルを使います。このファイルは ``.gitignore`` と似たような除外パターンをサポートします。ファイルの作成に関する情報は :ref:`.dockerignore ファイル ` を参照してください。 .. Use multi-stage builds @@ -314,23 +287,23 @@ stdin から読み込む Dockerfile を使い、リモートのビルド・コ .. 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. -:doc:`マルチステージ・ビルド ` は、中間レイヤとイメージの数を減らすのに苦労しなくても、最終イメージの容量を大幅に減少できます。 +:doc:`マルチステージ・ビルド ` は、中間レイヤとイメージの数を減らすのに苦労しなくても、最終イメージの容量を大幅に減少できます。 .. Because an image is built during the final stage of the build process, you can minimize image layers by leveraging build cache. 構築プロセスの最終段階のビルドを元にイメージを作成するため、 :ref:`ビルド・キャッシュの活用 ` によってイメージ・レイヤを最小化できます。 -.. For example, if your build contains several layers, you can order them from the less frequently changed (to ensure the build cache is reusable) to the more frequently changed: +.. For example, if your build contains several layers and you want to ensure the build cache is reusable, you can order them from the less frequently changed to the more frequently changed. The following list is an example of the order of instructions: -たとえば、複数のレイヤが入った構築をする時には、（ビルド・キャッシュを再利用可能にしている場合）頻繁に変更しないものから順番に、より頻繁に変更するものへと並べます。 +例えば、複数のレイヤを含む構築を行おうとしていて、ビルド・キャッシュを確実に再利用可能にしたい場合は、余り頻繁に変更しないものから、より頻繁に変更するものへと順番を並べます。以下のリストは命令の順番例です。 .. Install tools you need to build your application Install or update library dependencies Generate your application -* アプリケーションの構築に必要なツールをインストール -* ライブラリの依存関係をインストールまたは更新 -* アプリケーションを生成 +1. アプリケーションの構築に必要なツールをインストール +2. ライブラリの依存関係をインストール又は更新 +3. アプリケーションを生成 .. A Dockerfile for a Go application could look like: @@ -372,9 +345,13 @@ Go アプリケーションに対する Dockerfile は、以下のようにな 不要なパッケージのインストール禁止 ---------------------------------------- -.. To reduce complexity, dependencies, file sizes, and build times, avoid installing extra or unnecessary packages just because they might be “nice to have.” For example, you don’t need to include a text editor in a database image. +.. Avoid installing extra or unnecessary packages just because they might be nice to have. For example, you don’t need to include a text editor in a database image. + +余分な、又は、あったほうが良いだろうという程度の必須はないパッケージのインストールを避けてください。例えば、データベースのイメージであれば、テキストエディタは不要です。 + +.. When you avoid installing extra or unnecessary packages, you images will have reduced complexity, reduced dependencies, reduced file sizes, and reduced build times. -複雑さ、依存関係、ファイルサイズ、構築時間をそれぞれ減らすためには、余分な、または必須ではない「あった方が良いだろう」程度のパッケージをインストールすべきではありません。例えば、データベース・イメージであればテキストエディタは不要でしょう。 +余分な又は不要なパッケージのインストールを避ければ、イメージの複雑さ、依存関係、ファイルサイズ、構築時間をそれぞれ減らせます。 .. Decouple applications @@ -385,15 +362,15 @@ Go アプリケーションに対する Dockerfile は、以下のようにな .. Each container should have only one concern. Decoupling applications into multiple containers makes it easier to scale horizontally and reuse containers. For instance, a web application stack might consist of three separate containers, each with its own unique image, to manage the web application, database, and an in-memory cache in a decoupled manner. -各コンテナはただ１つだけの用途を持つべきです。アプリケーションを複数のコンテナに切り離すことで、水平スケールやコンテナの再利用がより簡単になります。たとえば、ウェブアプリケーションのスタックであれば、３つのコンテナに分割できるでしょう。切り離す方法にすると、ウェブアプリケーションの管理、データベース、メモリ内のキャッシュ、それぞれが独自のイメージを持ちます。 +各コンテナはただ１つだけの用途を持つべきです。アプリケーションを複数のコンテナに切り離すことで、水平スケールやコンテナの再利用がより簡単になります。例えば、ウェブアプリケーションのスタックであれば、３つのコンテナに分割できるでしょう。切り離す方法にしますと、ウェブアプリケーションの管理、データベース、メモリ内のキャッシュ、それぞれが独自のイメージを持ちます。 -.. Limiting each container to one process is a good rule of thumb, but it is not a hard and fast rule. For example, not only can containers be spawned with an init process, some programs might spawn additional processes of their own accord. For instance, Celery can spawn multiple worker processes, and Apache can create one process per request. +.. Limiting each container to one process is a good rule of thumb, but it's not a hard and fast rule. For example, not only can containers be spawned with an init process, some programs might spawn additional processes of their own accord. For instance, Celery can spawn multiple worker processes, and Apache can create one process per request. -各コンテナに１つのプロセスに制限するのは、経験的には良い方針です。しかしながら、これは大変かつ厳しいルールです。たとえば、コンテナで :ref:`init プロセスを生成 ` する時、プログラムによっては、そのプロセスが許容する追加プロセスも生成するでしょう。他にもたとえば、 `Celery `_ は複数のワーカ・プロセスを生成しますし、 `Apache `_ はリクエストごとに１つのプロセスを作成します。 +各コンテナに１つのプロセスに制限するのは、経験的には良い方針です。しかし、これは大変かつ厳しいルールです。例えば、コンテナで :ref:`init プロセスを生成 ` する時、プログラムによっては、そのプロセスが許容する追加プロセスも生成するでしょう。他にも例えば、 `Celery `_ は複数のワーカ・プロセスを生成しますし、 `Apache `_ はリクエストごとに１つのプロセスを作成します。 .. Use your best judgment to keep containers as clean and modular as possible. If containers depend on each other, you can use Docker container networks to ensure that these containers can communicate. -ベストな判断のためには、コンテナを綺麗（クリーン）に保ち、可能であればモジュール化します。コンテナがお互いに依存する場合は、 :doc:`Docker コンテナ・ネットワーク ` を使い、それぞれのコンテナが通信できるようにします。 +ベストな判断のためには、コンテナを綺麗（クリーン）に保ち、可能であればモジュール化します。コンテナがお互いに依存する場合は、 :doc:`Docker コンテナ・ネットワーク ` を使い、それぞれのコンテナを通信可能にします。 レイヤの数を最小に -------------------- @@ -402,13 +379,13 @@ Go アプリケーションに対する Dockerfile は、以下のようにな Docker の古いバージョンでは、性能を確保するために、イメージ・レイヤ数の最小化が重要でした。以下の機能は、この制限を減らすために追加されたものです。 -.. Only the instructions RUN, COPY, ADD create layers. Other instructions create temporary intermediate images, and do not increase the size of the build. +.. Only the instructions RUN, COPY, ADD create layers. Other instructions create temporary intermediate images, and don't increase the size of the build. * ``RUN`` 、 ``COPY`` 、 ``ADD`` 命令のみレイヤを作成します。他の命令では、一時的な中間イメージ（temporary intermediate images）を作成し、構築時の容量は増えません。 .. Where possible, use multi-stage builds, and only copy the artifacts you need into the final image. This allows you to include tools and debug information in your intermediate build stages without increasing the size of the final image. -* 可能であれば、 :doc:`マルチステージ・ビルド ` を使い、必要な最終成果物（アーティファクト）のみ最終イメージにコピーします。これにより、中間構築ステージではツールやデバッグ情報を入れられますし、最終イメージの容量も増えません。 +* 可能であれば、 :doc:`マルチステージ・ビルド ` を使い、必要な最終成果物（アーティファクト）のみ最終イメージにコピーします。これにより、中間構築ステージではツールやデバッグ情報を入れられますし、最終イメージの容量も増えません。 .. Sort multi-line arguments @@ -421,11 +398,11 @@ Docker の古いバージョンでは、性能を確保するために、イメ .. Whenever possible, ease later changes by sorting multi-line arguments alphanumerically. This helps to avoid duplication of packages and make the list much easier to update. This also makes PRs a lot easier to read and review. Adding a space before a backslash (\) helps as well. -可能であれば常に、後々の変更を簡単にするため、複数行にわたる引数はアルファベット順にします。これにより、パッケージの重複指定を防ぎ、パッケージ一覧の変更も簡単になります。プルリクエストを読んだりレビューしたりが、さらに楽になります。バックスラッシュ（ ``\`` ） の前に空白を含めるのも同様です。 +可能であれば常に、後々の変更を簡単にするため、複数行にわたる引数はアルファベット順にします。これにより、パッケージの重複指定を防ぎ、パッケージ一覧の変更も簡単になります。プルリクエストを読んだりレビューしたりが、更に楽になります。バックスラッシュ（ ``\`` ） の前に空白を含めるのも同様です。 .. Here’s an example from the buildpack-deps image: -以下は ``buildpack-deps`` `イメージ `_ の記述例です。 +以下は `buildpack-deps イメージ `_ の記述例です。 .. code-block:: bash @@ -444,33 +421,33 @@ Docker の古いバージョンでは、性能を確保するために、イメ ビルド・キャッシュの活用 ------------------------------ -.. When building an image, Docker steps through the instructions in your Dockerfile, executing each in the order specified. As each instruction is examined, Docker looks for an existing image in its cache that it can reuse, rather than creating a new (duplicate) image. +.. When building an image, Docker steps through the instructions in your Dockerfile, executing each in the order specified. As each instruction is examined, Docker looks for an existing image in its cache that it can reuse, rather than creating a new, duplicate image. -イメージの構築時、Docker は ``Dockerfile`` に記述された命令を順番に実行します。それぞれの命令のチェック時、Docker は新しい（重複した）イメージを作成するのではなく、キャッシュされた既存のイメージを再利用できるかどうか調べます。 +イメージの構築時、Docker は Dockerfile に記述された命令を順番に実行します。それぞれの命令のチェック時、Docker は新しい重複したイメージを作成するのではなく、キャッシュされた既存のイメージを再利用できるかどうか調べます。 -.. If you do not want to use the cache at all, you can use the --no-cache=true option on the docker build command. However, if you do let Docker use its cache, it is important to understand when it can, and cannot, find a matching image. The basic rules that Docker follows are outlined below: +.. If you don’t want to use the cache at all, you can use the --no-cache=true option on the docker build command. However, if you do let Docker use its cache, it’s important to understand when it can, and can’t, find a matching image. The basic rules that Docker follows are outlined below: キャッシュを一切使いたくない場合は ``docker build`` コマンドに ``--no-cache=true`` オプションをつけて実行します。一方で Docker のキャッシュを利用する場合、Docker が適切なイメージを見つけた上で、どのようなときにキャッシュを利用し、どのようなときに利用しないのかの理解が必要です。Docker が従っている規則は以下のとおりです。 -.. Starting with a parent image that is already in the cache, the next instruction is compared against all child images derived from that base image to see if one of them was built using the exact same instruction. If not, the cache is invalidated. +.. Starting with a parent image that's already in the cache, the next instruction is compared against all child images derived from that base image to see if one of them was built using the exact same instruction. If not, the cache is invalidated. -* キャッシュ内にすでに存在している親イメージから処理を始めます。そのベースとなるイメージから派生した子イメージに対して、次の命令が合致するかどうかを比較し、子イメージのいずれかが同一の命令によって構築されているかを確認します。そのようなものが存在しなければ、キャッシュは無効になります。 +* キャッシュ内に既に存在している親イメージから処理を始めます。そのベースとなるイメージから派生した子イメージに対して、次の命令が合致するかどうかを比較し、子イメージのいずれかが同一の命令によって構築されているかを確認します。そのようなものが存在しなければ、キャッシュは無効になります。 .. In most cases, simply comparing the instruction in the Dockerfile with one of the child images is sufficient. However, certain instructions require more examination and explanation. -* ほとんどの場合、 ``Dockerfile`` 内の命令と子イメージのどれかを単純に比較するだけで十分です。しかし命令によっては、多少の検査や解釈が必要となるものもあります。 +* ほとんどの場合、 Dockerfile 内の命令と子イメージのどれかを単純に比較するだけで十分です。しかし命令によっては、多少の検査や解釈が必要となるものもあります。 -.. For the ADD and COPY instructions, the contents of the file(s) in the image are examined and a checksum is calculated for each file. The last-modified and last-accessed times of the file(s) are not considered in these checksums. During the cache lookup, the checksum is compared against the checksum in the existing images. If anything has changed in the file(s), such as the contents and metadata, then the cache is invalidated. +.. For the ADD and COPY instructions, the contents of each file in the image are examined and a checksum is calculated for each file. The last-modified and last-accessed times of each file aren’t considered in these checksums. During the cache lookup, the checksum is compared against the checksum in the existing images. If anything has changed in any file, such as the contents and metadata, then the cache is invalidated. -* ``ADD`` 命令や ``COPY`` 命令では、イメージに含まれるファイルの内容が検査され、個々のファイルについてチェックサムが計算されます。この計算において、ファイルの最終更新時刻、最終アクセス時刻は考慮されません。キャッシュを探す際に、このチェックサムと既存イメージのチェックサムが比較されます。ファイル内の何かが変更になったとき、たとえばファイル内容やメタデータが変わっていれば、キャッシュは無効になります。 +* ``ADD`` 命令や ``COPY`` 命令では、イメージに含まれるファイルの内容が検査され、個々のファイルについてチェックサムが計算されます。この計算において、ファイルの最終更新時刻、最終アクセス時刻は考慮されません。キャッシュを探す際に、このチェックサムと既存イメージのチェックサムが比較されます。ファイル内の何かが変更になったとき、例えばファイル内容やメタデータが変わっていれば、キャッシュは無効になります。 -.. Aside from the ADD and COPY commands, cache checking does not look at the files in the container to determine a cache match. For example, when processing a RUN apt-get -y update command the files updated in the container are not examined to determine if a cache hit exists. In that case just the command string itself is used to find a match. +.. Aside from the ADD and COPY commands, cache checking doesn’t look at the files in the container to determine a cache match. For example, when processing a RUN apt-get -y update command the files updated in the container aren’t examined to determine if a cache hit exists. In that case just the command string itself is used to find a match. -* ``ADD`` と ``COPY`` 以外の命令の場合、キャッシュのチェックは、コンテナ内のファイル内容を見ることはなく、それによってキャッシュと一致しているかどうかが決定されません。たとえば ``RUN apt-get -y update`` コマンドの処理が行われる際には、コンテナ内にて更新されたファイルは、キャッシュが一致するかどうかの判断のために用いられません。この場合にはコマンド文字列そのものが、キャッシュの一致判断に用いられます。 +* ``ADD`` と ``COPY`` 以外の命令の場合、キャッシュのチェックは、コンテナ内のファイル内容を見ることはなく、それによってキャッシュと一致しているかどうかが決定されません。例えば ``RUN apt-get -y update`` コマンドの処理が行われる際には、コンテナ内にて更新されたファイルは、キャッシュが一致するかどうかの判断のために用いられません。この場合にはコマンド文字列そのものが、キャッシュの一致判断に用いられます。 .. Once the cache is invalidated, all subsequent Dockerfile commands generate new images and the cache is not used. -キャッシュが無効になると、次に続く ``Dockerfile`` コマンドは新たなイメージを生成し、キャッシュを使いません。 +キャッシュが無効になれば、次に続く ``Dockerfile`` コマンドは新たなイメージを生成し、キャッシュを使いません。 .. Dockerfile instructions @@ -481,7 +458,7 @@ Dockerfile 命令 .. These recommendations are designed to help you create an efficient and maintainable Dockerfile. -以下にある推奨項目のねらいは、効率的かつメンテナンス可能な ``Dockerfile`` の作成に役立つことです。 +以下にある推奨項目は、効率的かつメンテナンス可能な Dockerfile の作成に役立つのを意図しています。 .. FROM @@ -489,34 +466,29 @@ Dockerfile 命令 FROM ---------- -.. [Dockerfile reference for the FROM instruction](../../reference/builder.md#from) +.. Whenever possible, use current official images as the basis for your images. Docker recommends the Alpine image as it is tightly controlled and small in size (currently under 6 MB), while still being a full Linux distribution. -:ref:`Dockerfile リファレンスの FROM コマンド ` +可能なら常に、イメージの基礎として最新の公式イメージを利用します。Docker の推奨は `Alpine イメージ `_ です。これはしっかりと管理されながら、容量が小さい（現時点で 6 MB 以下） Linux ディストリビューションです。 -.. 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 6 MB), while still being a full Linux distribution. +.. For more information about the FROM instruction, see Dockerfile reference for the FROM instruction. + +``FROM`` 命令についての詳しい情報は、 :ref:`Dockerfile リファレンスの FROM 命令 ` を御覧ください。 -可能なら常に、イメージの土台には最新の公式イメージを利用します。私たちの推奨は `Alpine イメージ `_ です。これはしっかりと管理されながら、容量が小さい（現時点で 6 MB 以下） Linux ディストリビューションです。 .. LABEL LABEL ---------- -:doc:`オブジェクト・ラベルの理解 ` - .. You can add labels to your image to help organize images by project, record licensing information, to aid in automation, or for other reasons. For each label, add a line beginning with LABEL and with one or more key-value pairs. The following examples show the different acceptable formats. Explanatory comments are included inline. -イメージにラベルを追加するのは、プロジェクト内でのイメージ管理をしやすくしたり、ライセンス情報の記録や自動化の助けとするなど、さまざまな目的があります。ラベルを指定するには、 ``LABEL`` で始まる行を追加して、そこにキーと値のペア（key-value pair）をいくつか設定します。以下に示す例は、いずれも正しい構文です。説明をコメントとしてつけています。 +イメージにラベルを追加するのは、プロジェクト内でのイメージ管理をしやすくする、あるいは、ライセンス情報の記録や自動化の助けとするなど、様々な目的があります。ラベルを指定するには、 ``LABEL`` で始まる行を追加して、そこにキーと値のペア（key-value pair）を幾つか設定します。以下に示す例は、いずれも正しい構文です。説明をコメントとしてつけています。 -.. Strings with spaces must be quoted or the spaces must be escaped. Inner quote characters ("), must also be escaped. +.. Strings with spaces must be quoted or the spaces must be escaped. Inner quote characters ("), must also be escaped. For example: - must be escaped. If your string contains inner quote characters (`"`), escape - them as well. +文字列に空白が含まれる場合は、引用符で囲むか **あるいは** エスケープする必要があります。文字列内に引用符（ ``"`` ）がある場合も、同様にエスケープが必要です。 -.. note:: - - 文字列に空白が含まれる場合は、引用符でくくるか **あるいは** エスケープする必要があります。文字列内に引用符（ ``"`` ）がある場合も、同様にエスケープが必要です。 -:: +.. code-block:: dockerfile # 個別のラベルを設定 LABEL com.example.version="0.0.1-beta" @@ -525,18 +497,18 @@ LABEL LABEL com.example.release-date="2015-02-12" LABEL com.example.version.is-production="" -.. An image can have more than one label. Prior to Docker 1.10, it was recommended to combine all labels into a single LABEL instruction, to prevent extra layers from being created. This is no longer necessary, but combining labels is still supported. +.. An image can have more than one label. Prior to Docker 1.10, it was recommended to combine all labels into a single LABEL instruction, to prevent extra layers from being created. This is no longer necessary, but combining labels is still supported. For example: イメージには複数のラベルを設定できます。Docker 1.10 未満では、余分なレイヤが追加されるのを防ぐため、１つの ``LABEL`` 命令中に複数のラベルをまとめる手法が推奨されていました。もはやラベルをまとめる必要はありませんが、今もなおラベルの連結をサポートしています。 -:: +.. code-block:: dockerfile # 1行でラベルを設定 LABEL com.example.version="0.0.1-beta" com.example.release-date="2015-02-12" 上の例は以下のように書き換えられます。 -:: +.. code-block:: dockerfile # 複数のラベルを一度に設定、ただし行継続の文字を使い、長い文字列を改行する LABEL vendor=ACME\ Incorporated \ @@ -547,37 +519,34 @@ LABEL .. See Understanding object labels for guidelines about acceptable label keys and values. For information about querying labels, refer to the items related to filtering in Managing labels on objects. See also LABEL in the Dockerfile reference. -ラベルにおける利用可能なキーと値のガイドラインとしては :doc:`オブジェクトラベルを理解する ` を参照してください。またラベルの検索に関する情報は :doc:`オブジェクト上のラベルの管理 ` のフィルタリングに関する項目を参照してください。 +ラベルにおける利用可能なキーと値のガイドラインとしては :doc:`オブジェクトラベルを理解する ` を参照してください。またラベルの検索に関する情報は :ref:`オブジェクト上のラベル管理 ` のフィルタリングに関する項目を参照してください。また、 Dockerfile リファレンスの :ref:`LABEL ` も御覧ください。 .. RUN RUN ---------- -.. [Dockerfile reference for the RUN instruction](../../reference/builder.md#run) - -:ref:`Dockerfile リファレンスの RUN コマンド ` - .. Split long or complex RUN statements on multiple lines separated with backslashes to make your Dockerfile more readable, understandable, and maintainable. ``Dockerfile`` をより読みやすく、理解しやすく、メンテナンスしやすくするためには、長く複雑な ``RUN`` 命令を、バックスラッシュで複数行に分けてください。 +.. For more information about RUN, see Dockerfile reference for the RUN instruction. + +``RUN`` 命令についての詳しい情報は、 :ref:`Dockerfile リファレンスの RUN 命令 ` を御覧ください。 + + .. apt-get apt-get ^^^^^^^^^^ -.. Probably the most common use-case for RUN is an application of apt-get. Because it installs packages, the RUN apt-get command has several gotchas to look out for. - -おそらく ``RUN`` において一番利用する使い方が ``apt-get`` アプリケーションの実行です。``RUN apt-get`` はパッケージをインストールするものであるため、注意点がいくつかあります。 - -.. Avoid RUN apt-get upgrade and dist-upgrade, as many of the “essential” packages from the parent images cannot upgrade inside an unprivileged container. If a package contained in the parent image is out-of-date, contact its maintainers. If you know there is a particular package, foo, that needs to be updated, use apt-get install -y foo to update automatically. +.. Probably the most common use-case for RUN is an application of apt-get. Because it installs packages, the RUN apt-get command has several counter-intuitive behaviors to look out for. -.. ``RUN apt-get upgrade`` や ``dist-upgrade`` の実行は避けてください。ベース・イメージに含まれる重要パッケージは、権限が与えられていないコンテナ内ではほとんど更新できないからです。ベース・イメージ内のパッケージが古くなっていたら、開発者に連絡をとってください。``foo`` というパッケージを更新する必要があれば、 ``apt-get install -y foo`` を利用してください。これによってパッケージは自動的に更新されます。 +恐らく ``RUN`` において一番利用する使い方が ``apt-get`` アプリケーションの実行です。これはパッケージをインストールするものですが、 ``RUN apt-get`` は直感的に分かるものではないため、注意点が幾つかあります。 .. Always combine RUN apt-get update with apt-get install in the same RUN statement. For example: -``RUN apt-get update`` と ``apt-get install`` は、同一の ``RUN`` 命令内にて同時実行するようにしてください。たとえば以下のようにします。 +``RUN apt-get update`` と ``apt-get install`` は、同一の ``RUN`` 命令内にて同時実行するようにしてください。例えば以下のようにします。 .. code-block:: bash @@ -587,35 +556,35 @@ apt-get package-foo \ && rm -rf /var/lib/apt/lists/* -.. Using apt-get update alone in a RUN statement causes caching issues and subsequent apt-get install instructions fail. For example, say you have a Dockerfile: +.. Using apt-get update alone in a RUN statement causes caching issues and subsequent apt-get install instructions fail. For example, the issue will occur in the following Dockerfile: -１つの ``RUN`` 命令内で ``apt-get update`` だけを使うとキャッシュに問題が発生し、その後の ``apt-get install`` コマンドが失敗します。たとえば Dockerfile を以下のように記述したとします。 +１つの ``RUN`` 命令内で ``apt-get update`` だけを使うとキャッシュに問題が発生し、その後の ``apt-get install`` コマンドが失敗します。例えば Dockerfile を以下のように記述したとします。 .. code-block:: bash # syntax=docker/dockerfile:1 - FROM ubuntu:18.04 + FROM ubuntu:22.04 RUN apt-get update RUN apt-get install -y curl -.. After building the image, all layers are in the Docker cache. Suppose you later modify apt-get install by adding extra package: +.. After building the image, all layers are in the Docker cache. Suppose you later modify apt-get install by adding an extra package as shown in the following Dockerfile: -イメージが構築されると、レイヤーがすべて Docker のキャッシュに入ります。この次に ``apt-get install`` を編集して別のパッケージを追加したとします。 +イメージの構築後、すべてのレイヤは Docker のキャッシュに入ります。この次に、 ``apt-get install`` を編集して、以下のように別のパッケージを追加したとします。 .. code-block:: bash # syntax=docker/dockerfile:1 - FROM ubuntu:18.04 + FROM ubuntu:22.04 RUN apt-get update RUN apt-get install -y curl nginx -.. Docker sees the initial and modified instructions as identical and reuses the cache from previous steps. As a result the apt-get update is not executed because the build uses the cached version. Because the apt-get update is not run, your build can potentially get an outdated version of the curl and nginx packages. +.. Docker sees the initial and modified instructions as identical and reuses the cache from previous steps. As a result the apt-get update isn’t executed because the build uses the cached version. Because the apt-get update isn’t run, your build can potentially get an outdated version of the curl and nginx packages. -Docker は当初の命令と修正後の命令を見て、同一のコマンドであると判断するので、前回の処理において作られたキャッシュを再利用します。キャッシュされたものを利用して処理を行うため、結果として ``apt-get update`` は実行 **されません** 。``apt-get update`` を実行しないとは、つまり ``curl`` にしても ``nginx`` にしても、古いバージョンのまま利用する可能性が出てきます。 +Docker は当初の命令と修正後の命令を見て、同一のコマンドであると判断するため、前回の処理において作られたキャッシュを再利用します。キャッシュされたものを利用して処理を行うため、結果として ``apt-get update`` は実行 **されません** 。``apt-get update`` を実行しないとは、つまり ``curl`` にしても ``nginx`` にしても、古いバージョンのまま利用する可能性が出てきます。 -.. Using RUN apt-get update && apt-get install -y ensures your Dockerfile installs the latest package versions with no further coding or manual intervention. This technique is known as “cache busting”. You can also achieve cache-busting by specifying a package version. This is known as version pinning, for example: +.. Using RUN apt-get update && apt-get install -y ensures your Dockerfile installs the latest package versions with no further coding or manual intervention. This technique is known as cache busting. You can also achieve cache busting by specifying a package version. This is known as version pinning. For example: -``RUN apt-get update && apt-get install -y`` コマンドを使えば、 Dockerfile が確実に最新バージョンをインストールし、さらにコードを書いたり手作業を加えたりする必要がなくなります。これは「キャッシュ・バスティング（cache busting）」と呼ばれる技術です。この技術は、パッケージのバージョン指定にも利用できます。これはバージョン・ピニング（version pinning）です。以下に例を示します。 +``RUN apt-get update && apt-get install -y`` コマンドを使えば、 Dockerfile が確実に最新バージョンをインストールし、更にコードを書いたり手作業を加えたりする必要がなくなります。これはキャッシュ・バスティング（cache busting）と呼ばれる技術です。この技術は、パッケージのバージョン指定にも利用できます。これはバージョン・ピニング（version pinning）よ呼ばれています。以下に例を示します。 .. code-block:: bash @@ -626,7 +595,7 @@ Docker は当初の命令と修正後の命令を見て、同一のコマンド .. Version pinning forces the build to retrieve a particular version regardless of what’s in the cache. This technique can also reduce failures due to unanticipated changes in required packages. -バージョン・ピニングでは、キャッシュにどのようなイメージがあろうとも、指定されたバージョンを使って構築します。この手法を使えば、そのパッケージの最新版に、思いもよらない変更が加わっていたとしても、ビルド失敗を回避できることもあります。 +バージョン・ピニングでは、キャッシュにどのようなイメージがあったとしても、指定されたバージョンを使って構築します。この手法を使えば、そのパッケージの最新版に、思いもよらない変更が加わっていたとしても、ビルド失敗を回避できることもあります。 .. Below is a well-formed RUN instruction that demonstrates all the apt-get recommendations. @@ -653,15 +622,15 @@ Docker は当初の命令と修正後の命令を見て、同一のコマンド ``s3cmd`` の引数は、バージョン ``1.1.*`` を指定しています。以前に作られたイメージが古いバージョンを使っていたとしても、新たなバージョンの指定により ``apt-get update`` のキャッシュ・バスティングが働いて、確実に新バージョンをインストールします。パッケージを各行に分けて記述しているのは、パッケージを重複して書くようなミスを防ぐためです。 -.. In addition, when you clean up the apt cache by removing /var/lib/apt/lists it reduces the image size, since the apt cache is not stored in a layer. Since the RUN statement starts with apt-get update, the package cache is always refreshed prior to apt-get install. +.. In addition, when you clean up the apt cache by removing /var/lib/apt/lists it reduces the image size, since the apt cache isn’t stored in a layer. Since the RUN statement starts with apt-get update, the package cache is always refreshed prior to apt-get install. -apt キャッシュをクリーンアップし ``/var/lib/apt/lists`` を削除するのは、イメージ容量を小さくするためです。そもそも apt キャッシュはレイヤー内に保存されません。``RUN`` 命令は ``apt-get update`` から始めているので、 ``apt-get install`` の前に必ずパッケージのキャッシュが更新されます。 +apt キャッシュをクリーンアップし ``/var/lib/apt/lists`` を削除するのは、イメージ容量を小さくするためです。そもそも apt キャッシュはレイヤー内に保存されません。``RUN`` 命令は ``apt-get update`` から始めていますので、 ``apt-get install`` の前に必ずパッケージのキャッシュが更新されます。 .. Official Debian and Ubuntu images automatically run apt-get clean, so explicit invocation is not required. -.. note:: +公式の Debian と Ubuntu のイメージは `自動的に apt-get clean を実行する `_ ので、明示的にこのコマンドを実行する必要はありません。 + - 公式の Debian と Ubuntu のイメージは `自動的に apt-get clean を実行する `_ ので、明示的にこのコマンドを実行する必要はありません。 .. Using pipes @@ -670,19 +639,20 @@ apt キャッシュをクリーンアップし ``/var/lib/apt/lists`` を削除 .. Some RUN commands depend on the ability to pipe the output of one command into another, using the pipe character (|), as in the following example: -``RUN`` 命令の中には、その出力をパイプを使って他のコマンドへの受け渡しを前提としています。そのときには、以下の例のように、パイプを行う文字（ ``|`` ）を使います。 +``RUN`` 命令の中には、その出力をパイプし、他のコマンドへと受け渡すのを前提としているものもあります。そのときには、以下の例のように、パイプを行う文字（ ``|`` ）を使います。 :: RUN wget -O - https://some.site | wc -l > /number -.. Docker executes these commands using the /bin/sh -c interpreter, which only evaluates the exit code of the last operation in the pipe to determine success. In the example above this build step succeeds and produces a new image so long as the wc -l command succeeds, even if the wget command fails. -Docker はこういったコマンドを ``/bin/sh -c`` というインタープリタで処理します。正常処理されたかどうかは、パイプの最後の処理の終了コードにより評価します。上の例では、この構築処理が成功して新たなイメージが生成されるかどうかは、``wc -l`` コマンドの成功にかかっています。つまり ``wget`` コマンドが成功するかどうかは関係がありません。 +.. Docker executes these commands using the /bin/sh -c interpreter, which only evaluates the exit code of the last operation in the pipe to determine success. In the example above, this build step succeeds and produces a new image so long as the wc -l command succeeds, even if the wget command fails. + +Docker はこういったコマンドを ``/bin/sh -c`` というインタープリタで処理します。正常に処理されたかどうかは、最後のパイプ処理における終了コードで評価します。上の例では、この構築処理が成功して新たなイメージが生成されるかどうかは、``wc -l`` コマンドの成功にかかっています。つまり ``wget`` コマンドが成功するかどうかは関係がありません。 .. If you want the command to fail due to an error at any stage in the pipe, prepend set -o pipefail && to ensure that an unexpected error prevents the build from inadvertently succeeding. For example: -パイプ内のどの段階でも、エラーが発生したらコマンド失敗としたい場合は、頭に ``set -o pipefail &&`` をつけて実行します。こうしておくと、予期しないエラーが発生しても、それに気づかずに構築されてしまうことはなくなります。以下は例です。 +パイプ内のどの段階でも、エラーが発生したらコマンド失敗としたい場合は、頭に ``set -o pipefail &&`` をつけて実行します。こうしますと、予期しないエラーが発生しても、それに気づかずに構築されてしまうことはなくなります。以下は例です。 :: @@ -707,55 +677,53 @@ Docker はこういったコマンドを ``/bin/sh -c`` というインタープ CMD ---------- -.. Dockerfile reference for the CMD instruction - -:ref:`Dockerfile リファレンスの CMD コマンド ` - .. The CMD instruction should be used to run the software contained in your image, along with any arguments. CMD should almost always be used in the form of CMD ["executable", "param1", "param2"…]. Thus, if the image is for a service, such as Apache and Rails, you would run something like CMD ["apache2","-DFOREGROUND"]. Indeed, this form of the instruction is recommended for any service-based image. -``CMD`` 命令は、イメージ内に含まれるソフトウェアを実行するために用いるもので、引数を指定して実行します。``CMD`` はほぼ、``CMD ["実行モジュール名", "引数1", "引数2" …]`` の形式をとります。Apache や Rails のようなサービス用途のイメージに対しては、たとえば ``CMD ["apache2","-DFOREGROUND"]`` といったコマンド実行になります。サービスの土台となるイメージに対しては、この実行形式を推奨します。 +``CMD`` 命令は、イメージ内に含まれるソフトウェアを実行するために用いるもので、引数を指定して実行します。``CMD`` はほぼ、``CMD ["実行モジュール名", "引数1", "引数2" …]`` の形式をとります。Apache や Rails のようなサービス用途のイメージに対しては、例えば ``CMD ["apache2","-DFOREGROUND"]`` といったコマンド実行になります。サービスの土台となるイメージに対しては、この実行形式を推奨します。 .. In most other cases, CMD should be given an interactive shell, such as bash, python and perl. For example, CMD ["perl", "-de0"], CMD ["python"], or CMD ["php", "-a"]. Using this form means that when you execute something like docker run -it python, you’ll get dropped into a usable shell, ready to go. CMD should rarely be used in the manner of CMD ["param", "param"] in conjunction with ENTRYPOINT, unless you and your expected users are already quite familiar with how ENTRYPOINT works. -ほとんどのケースでは、 ``CMD`` に対して bash、python、perl など双方向のシェルがあります。たとえば ``CMD ["perl", "-de0"]`` 、 ``CMD ["python"]`` 、 ``CMD ["php", "-a"]`` といった具合です。この実行形式の利用とは、たとえば ``docker run -it python`` というコマンドを実行したときに、指定したシェルの中に入り込んで、処理の進行を意味します。``CMD`` と ``ENTRYPOINT`` を組み合わせて用いる ``CMD ["引数", "引数"]`` という実行形式がありますが、これを利用するのはまれです。開発者自身や利用者にとって ``ENTRYPOINT`` がどのように動作するのかを十分に理解していないなら、使うべきではありません。 +ほとんどのケースでは、 ``CMD`` に対して bash、python、perl など双方向のシェルがあります。例えば ``CMD ["perl", "-de0"]`` 、 ``CMD ["python"]`` 、 ``CMD ["php", "-a"]`` といった具合です。この実行形式の利用とは、例えば ``docker run -it python`` というコマンドを実行したときに、指定したシェルの中に入り込んで、処理の進行を意味します。``CMD`` と ``ENTRYPOINT`` を組み合わせて用いる ``CMD ["引数", "引数"]`` という実行形式がありますが、これを利用するのは稀です。開発者自身や利用者にとって ``ENTRYPOINT`` がどのように動作するのかを十分に理解していないなら、使うべきではありません。 + +.. For more information about CMD, see Dockerfile reference for the CMD instruction. + +``CMD`` 命令についての詳しい情報は、 :ref:`Dockerfile リファレンスの CMD 命令 ` を御覧ください。 + .. EXPOSE EXPOSE ---------- -.. Dockerfile reference for the EXPOSE instruction - -:ref:`Dockerfile リファレンスの EXPOSE 命令 ` - .. The EXPOSE instruction indicates the ports on which a container listens for connections. Consequently, you should use the common, traditional port for your application. For example, an image containing the Apache web server would use EXPOSE 80, while an image containing MongoDB would use EXPOSE 27017 and so on. -``EXPOSE`` 命令は、コンテナが接続のためにリッスンするポートを指定します。当然ながら、アプリケーションは標準的なポートを試用すべきです。たとえば Apache ウェブ・サーバを含んでいるイメージに対しては ``EXPOSE 80`` を使います。また MongoDB を含んでいれば ``EXPOSE 27017`` を使います。 +``EXPOSE`` 命令は、コンテナが接続のためにリッスンするポートを指定します。当然ながら、アプリケーションは標準的なポートを試用すべきです。例えば Apache ウェブ・サーバを含んでいるイメージに対しては ``EXPOSE 80`` を使います。また MongoDB を含んでいれば ``EXPOSE 27017`` を使います。 .. For external access, your users can execute docker run with a flag indicating how to map the specified port to the port of their choice. For container linking, Docker provides environment variables for the path from the recipient container back to the source (ie, MYSQL_PORT_3306_TCP). -外部からアクセスできるようにするには、 ``docker run`` にフラグをつけて実行します。そのフラグとは、指定されているポートを、自分が取り決めるどのようなポートに割り当てるかを指示するものです。Docker のリンク機能においては環境変数が利用できます。受け側のコンテナが提供元をたどれるようにするものです（例: ``MYSQL_PORT_3306_TCP`` ）。 +外部からアクセスできるようにするには、 ``docker run`` にフラグをつけて実行します。そのフラグとは、指定されているポートを、自分が取り決めるどのようなポートに割り当てるかを指示するものです。Docker のリンク機能では環境変数が利用できます。受け側のコンテナが提供元をたどれるようにするものです（例: ``MYSQL_PORT_3306_TCP`` ）。 + +.. For more information about EXPOSE, see Dockerfile reference for the EXPOSE instruction. + +``EXPOSE`` 命令についての詳しい情報は、 :ref:`Dockerfile リファレンスの EXPOSE 命令 ` を御覧ください。 + .. ENV ENV ---------- -.. Dockerfile reference for the ENV instruction - -:ref:`Dockerfile リファレンスの ENV コマンド ` - .. To make new software easier to run, you can use ENV to update the PATH environment variable for the software your container installs. For example, ENV PATH=/usr/local/nginx/bin:$PATH ensures that CMD ["nginx"] just works. -新しいソフトウェアに対しては ``ENV`` を用いれば簡単にそのソフトウェアを実行できます。コンテナがインストールするソフトウェアに必要な環境変数 ``PATH`` を、この ``ENV`` を使って更新します。たとえば ``ENV PATH=/usr/local/nginx/bin:$PATH`` を実行すれば、 ``CMD ["nginx"]`` が確実に動作するようになります。 +新しいソフトウェアに対しては ``ENV`` を用いれば簡単にそのソフトウェアを実行できます。コンテナがインストールするソフトウェアに必要な環境変数 ``PATH`` を、この ``ENV`` を使って更新します。例えば ``ENV PATH=/usr/local/nginx/bin:$PATH`` を実行すれば、 ``CMD ["nginx"]`` が確実に動作するようになります。 .. The ENV instruction is also useful for providing required environment variables specific to services you wish to containerize, such as Postgres’s PGDATA. -``ENV`` 命令は、必要となる環境変数を設定するときにも利用します。たとえば Postgres の ``PGDATA`` のように、コンテナ化したいサービスに固有の環境変数が設定できます。 +``ENV`` 命令は、必要となる環境変数を設定するときにも利用します。例えば Postgres の ``PGDATA`` のように、コンテナ化したいサービスに固有の環境変数が設定できます。 .. Lastly, ENV can also be used to set commonly used version numbers so that version bumps are easier to maintain, as seen in the following example: -また ``ENV`` は普段利用している各種バージョン番号を設定しておくときにも利用されます。これによってバージョンを混同することなく、管理が容易になります。たとえば以下がその例です。 +また ``ENV`` にはふだん利用している各種バージョン番号を設定しておくときにも利用されます。これによってバージョンを混同することなく、管理が容易になります。以下がその例です。 .. code-block:: bash @@ -764,9 +732,9 @@ ENV RUN curl -SL https://example.com/postgres-$PG_VERSION.tar.xz | tar -xJC /usr/src/postgres && … ENV PATH=/usr/local/postgres-$PG_MAJOR/bin:$PATH -.. Similar to having constant variables in a program (as opposed to hard-coding values), this approach lets you change a single ENV instruction to auto-magically bump the version of the software in your container. +.. Similar to having constant variables in a program, as opposed to hard-coding values, this approach lets you change a single ENV instruction to automatically bump the version of the software in your container. -プログラムにおける（ハードコーディングではない）定数の定義と同じように、この方法を使うのが便利です。ただ１つの ``ENV`` 命令を変更するだけで、コンテナ内のソフトウェアバージョンも、いとも簡単に変えられるからです。 +この方法は、プログラムにおけるハードコーディングではない定数を定義するのと同じように使うのが便利です。ただ１つの ``ENV`` 命令を変更するだけで、コンテナ内のソフトウェアバージョンも、いとも簡単に変えられるからです。 .. Each ENV line creates a new intermediate layer, just like RUN commands. This means that even if you unset the environment variable in a future layer, it still persists in this layer and its value can be dumped. You can test this by creating a Dockerfile like the following, and then building it. @@ -788,7 +756,7 @@ ENV .. To prevent this, and really unset the environment variable, use a RUN command with shell commands, to set, use, and unset the variable all in a single layer. You can separate your commands with ; or &&. If you use the second method, and one of the commands fails, the docker build also fails. This is usually a good idea. Using \ as a line continuation character for Linux Dockerfiles improves readability. You could also put all of the commands into a shell script and have the RUN command just run that shell script. -この挙動を避けるには、 ``RUN`` 命令でシェルのコマンドを使い、環境変数を実際にアンセットします。ただし、レイヤ内の環境変数の指定とアンセットを、１つのレイヤで指定する必要があります。コマンドは ``;`` や ``&`` で分割できます。ただし、 ``&`` を使う場合、どこかの行の１つでも失敗すると、 ``docker build`` そのものが失敗します。 ``\`` をライン継続文字として使う方が、 Linux Dockerfile の読み込みやすさを改善します。また、コマンドのすべてをシェルスクリプトにし、そのスクリプトを ``RUN`` 命令として実行する方法もあります。 +この挙動を避けるには、 ``RUN`` 命令でシェルのコマンドを使い、環境変数を実際にアンセットします。ただし、レイヤ内の環境変数の指定とアンセットを、１つのレイヤで指定する必要があります。コマンドは ``;`` や ``&`` で分割できます。ただし、 ``&`` を使う場合、どこかの行の１つでも失敗したら、 ``docker build`` そのものが失敗します。 ``\`` をライン継続文字として使う方が、 Linux Dockerfile の読み込みやすさを改善します。また、コマンドのすべてをシェルスクリプトにし、そのスクリプトを ``RUN`` 命令として実行する方法もあります。 .. code-block:: bash @@ -803,24 +771,23 @@ ENV $ docker run --rm test sh -c 'echo $ADMIN_USER' +.. For more information about ENV, see Dockerfile reference for the ENV instruction. + +``ENV`` 命令についての詳しい情報は、 :ref:`Dockerfile リファレンスの ENV 命令 ` を御覧ください。 + + .. ADD or COPY ADD と COPY -------------------- -.. Dockerfile reference for the ADD instruction - Dockerfile reference for the COPY instruction - -:ref:`Dockerfile リファレンスの ADD コマンド ` -:ref:`Dockerfile リファレンスの COPY コマンド ` - .. Although ADD and COPY are functionally similar, generally speaking, COPY is preferred. That’s because it’s more transparent than ADD. COPY only supports the basic copying of local files into the container, while ADD has some features (like local-only tar extraction and remote URL support) that are not immediately obvious. Consequently, the best use for ADD is local tar file auto-extraction into the image, as in ADD rootfs.tar.xz /. -``ADD`` と ``COPY`` の機能は似ていますが、一般的には ``COPY`` を優先します。それは ``ADD`` よりも機能が明確だからです。``COPY`` は単に、基本的なコピー機能を使ってローカルファイルをコンテナにコピーするだけです。一方 ``ADD`` には特定の機能（ローカルでの tar 展開やリモート URL サポート）があり、これはすぐにわかるものではありません。結局 ``ADD`` の最も適切な利用場面は、ローカルの tar ファイルを自動的に展開してイメージに書き込むときです。たとえば ``ADD rootfs.tar.xz /`` といったコマンドです。 +``ADD`` と ``COPY`` の機能は似ていますが、一般的には ``COPY`` を優先します。それは ``ADD`` よりも機能が明確だからです。``COPY`` は単に、基本的なコピー機能を使ってローカルファイルをコンテナにコピーするだけです。一方 ``ADD`` には特定の機能（ローカル環境での tar 展開やリモート URL サポート）がありますが、これはすぐにわかるものではありません。結局 ``ADD`` の最も適切な利用場面は、ローカルの tar ファイルを自動的に展開してイメージに書き込むときです。例えば ``ADD rootfs.tar.xz /`` といったコマンドです。 -.. If you have multiple Dockerfile steps that use different files from your context, COPY them individually, rather than all at once. This ensures that each step’s build cache is only invalidated (forcing the step to be re-run) if the specifically required files change. +.. If you have multiple Dockerfile steps that use different files from your context, COPY them individually, rather than all at once. This ensures that each step’s build cache is only invalidated, forcing the step to be re-run if the specifically required files change. -``Dockerfile`` 内の複数ステップで異なるファイルをコピーするには、一度にすべてをコピーするのではなく、 ``COPY`` を使って個別にコピーしてください。こうしておくと、個々のステップに対するキャッシュのビルドは最低限に抑えられます。つまり指定されているファイルが変更になったときのみ、キャッシュが無効化されます（そのステップは再実行されます）。 +Dockerfile 内の複数ステップで異なるファイルをコピーするには、一度にすべてをコピーするのではなく、 ``COPY`` を使って個別にコピーしてください。こうしておけば、個々のステップに対するキャッシュのビルドは最低限に抑えられます。つまり指定されているファイルが変更になったときのみ、キャッシュが無効化されます（そのステップは再実行されます）。 .. For example: @@ -838,7 +805,7 @@ ADD と COPY .. Because image size matters, using ADD to fetch packages from remote URLs is strongly discouraged; you should use curl or wget instead. That way you can delete the files you no longer need after they’ve been extracted and you don’t have to add another layer in your image. For example, you should avoid doing things like: -イメージ容量の問題があるので、 ``ADD`` を用いてリモート URL からのパッケージ取得をやめてください。かわりに ``curl`` や ``wget`` を使ってください。こうすると、ファイルを取得し展開した後や、イメージ内の他のレイヤにファイルを加える必要がないのであれば、その後にファイルを削除できます。たとえば以下に示すのは、望ましくない例です。 +イメージ容量の問題があるため、 ``ADD`` を用いてリモート URL からのパッケージ取得をやめてください。かわりに ``curl`` や ``wget`` を使ってください。こうしますと、ファイルを取得し展開した後や、イメージ内の他のレイヤにファイルを加える必要がないのであれば、その後にファイルを削除できます。例えば以下に示すのは、望ましくない例です。 .. code-block:: bash @@ -861,31 +828,35 @@ ADD と COPY ``ADD`` の自動展開機能を必要としないもの（ファイルやディレクトリ）に対しては、常に ``COPY`` を使うべきです。 +.. For more information about ADD or COPY, see the following: + +``ADD`` と ``COPY`` についての詳しい情報は以下を御覧ください： + +* :ref:`Dockerfile リファレンスの ADD 命令 ` +* :ref:`Dockerfile リファレンスの COPY コマンド ` + + .. ENTRYPOINT ENTRYPOINT ---------- -.. Dockerfile reference for the ENTRYPOINT instruction - -:ref:`Dockerfile リファレンスの ENTRYPOINT コマンド ` - -.. The best use for ENTRYPOINT is to set the image’s main command, allowing that image to be run as though it was that command (and then use CMD as the default flags). +.. The best use for ENTRYPOINT is to set the image’s main command, allowing that image to be run as though it was that command, and then use CMD as the default flags. -``ENTRYPOINT`` の最適な利用方法は、イメージに対してメインとなるコマンドの設定です。これを設定すると、イメージをそのコマンドそのものであるかのようにして実行できます（その次に ``CMD`` を使えば、デフォルトのフラグを指定します）。 +``ENTRYPOINT`` の最適な利用方法は、イメージに対してメインとなるコマンドの設定です。これを設定しますと、イメージをそのコマンドそのものであるかのようにして実行できます。また、続いて ``CMD`` を使えば、デフォルトのフラグを指定します。 -.. Let's start with an example of an image for the command line tool `s3cmd`: +.. The following is an example of an image for the command line tool s3cmd: -コマンドライン・ツール ``s3cmd`` のイメージ例から始めます。 +以下は、コマンドライン・ツール ``s3cmd`` のイメージ例です。 .. code-block:: bash ENTRYPOINT ["s3cmd"] CMD ["--help"] -.. Now the image can be run like this to show the command's help: +.. You can use the following command to run the image and show the command’s help: -このイメージが実行されると、コマンドのヘルプが表示されます。 +以下のコマンドを実行してこのイメージを実行したら、コマンドのヘルプが表示されます。 .. code-block:: bash @@ -909,7 +880,7 @@ ENTRYPOINT .. For example, the Postgres Official Image uses the following script as its ENTRYPOINT: -たとえば `Postgres 公式イメージ `_ は次のスクリプトを ``ENTRYPOINT`` として使っています。 +例えば `Postgres 公式イメージ `_ は次のスクリプトを ``ENTRYPOINT`` として使っています。 .. code-block:: bash @@ -928,18 +899,13 @@ ENTRYPOINT exec "$@" -.. Configure app as PID 1 - This script uses the exec Bash command so that the final running application becomes the container’s PID 1. This allows the application to receive any Unix signals sent to the container. For more, see the ENTRYPOINT reference. - -.. note:: - - **PID 1 としてアプリを設定** +.. This script uses the exec Bash command so that the final running application becomes the container’s PID 1. This allows the application to receive any Unix signals sent to the container. For more information, see the ENTRYPOINT reference. - このスクリプトは `Bash コマンドの exec `_ を用います。 このため最終的に実行されたアプリケーションが、コンテナの PID として 1 を持つことになります。 こうなるとそのアプリケーションは、コンテナに送信された Unix シグナルをすべて受信できます。 詳細は :ref:`ENTRYPOINT ` を参照してください。 +このスクリプトは `Bash コマンドの exec `_ を用います。 このため最終的に実行されたアプリケーションが、コンテナの PID として 1 を持つことになります。 こうなるとそのアプリケーションは、コンテナに送信された Unix シグナルをすべて受信できます。 詳細は :ref:`ENTRYPOINT ` を参照してください。 -.. The helper script is copied into the container and run via ENTRYPOINT on container start: +.. In the following example, helper script is copied into the container and run via ENTRYPOINT on container start: -ヘルパースクリプトはコンテナの中にコピーされ、コンテナ開始時に ``ENTRYPOINT`` から実行されます。 +以下の例では、ヘルパースクリプトはコンテナの中にコピーされ、コンテナ開始時に ``ENTRYPOINT`` から実行されます。 .. code-block:: bash @@ -949,7 +915,7 @@ ENTRYPOINT .. This script allows the user to interact with Postgres in several ways. -このスクリプトを用いると、Postgres との間で、ユーザがいろいろな方法でやり取りできるようになります。 +このスクリプトを使うと、Postgres との間で、ユーザがいろいろな方法でやり取りできるようになります。 .. It can simply start Postgres: @@ -969,37 +935,42 @@ ENTRYPOINT .. Lastly, it could also be used to start a totally different tool, such as Bash: -または Bash のような全く異なるツールを起動するための利用もできます。 +又は Bash のような全く異なるツールを起動するための利用もできます。 .. code-block:: bash $ docker run --rm -it postgres bash + +.. For more information about ENTRYPOINT, see Dockerfile reference for the ENTRYPOINT instruction. + +``ENTRYPOINT`` 命令についての詳しい情報は、 :ref:`Dockerfile リファレンスの ENTRYPOINT 命令 ` を御覧ください。 + + .. VOLUME VOLUME ---------- -.. Dockerfile reference for the VOLUME instruction - -:ref:`Dockerfile リファレンスの VOLUME コマンド ` +.. The VOLUME instruction should be used to expose any database storage area, configuration storage, or files and folders created by your Docker container. You are strongly encouraged to use VOLUME for any combination of mutable or user-serviceable parts of your image. .. The VOLUME instruction should be used to expose any database storage area, configuration storage, or files/folders created by your docker container. You are strongly encouraged to use VOLUME for any mutable and/or user-serviceable parts of your image. -``VOLUME`` コマンドは、データベース・ストレージ領域、設定用ストレージ、Docker コンテナによって作成されるファイルやフォルダの公開に使います。イメージの可変的な部分、あるいはユーザが設定可能な部分については VOLUME の利用が強く推奨されます。 +``VOLUME`` コマンドは、データベース・ストレージ領域、設定用ストレージ、Docker コンテナによって作成されるファイルやフォルダの公開に使います。イメージ内であらゆる可変的な部分、あるいはユーザが設定可能な部分では、 VOLUME の利用が強く推奨されます。 + +.. For more information about VOLUME, see Dockerfile reference for the VOLUME instruction. + +``VOLUME`` 命令についての詳しい情報は、 :ref:`Dockerfile リファレンスの VOLUME 命令 ` を御覧ください。 + .. USER USER ---------- -.. Dockerfile reference for the USER instruction +.. If a service can run without privileges, use USER to change to a non-root user. Start by creating the user and group in the Dockerfile with something like the following example: -:ref:`Dockerfile リファレンスの USER コマンド ` - -.. If a service can run without privileges, use USER to change to a non-root user. Start by creating the user and group in the Dockerfile with something like - -サービスが特権ユーザでなくても実行できる場合は、 ``USER`` を用いて非 root ユーザに変更します。ユーザとグループを生成するところから始めてください。``Dockerfile`` 内で、たとえば次のように入力します。 +サービスが特権ユーザでなくても実行できる場合は、 ``USER`` を用いて非 root ユーザに変更します。ユーザとグループを生成するところから始めてください。``Dockerfile`` 内で、例えば次のように入力します。 .. code-block:: bash @@ -1013,57 +984,69 @@ USER イメージ内のユーザとグループに割り当てられる UID、GID は確定的なものではありません。イメージが再構築されるかどうかには関係なく、「次の」値が UID、GID に割り当てられます。これが問題となる場合は、UID、GID を明示的に割り当ててください。 - Go 言語の archive/tar パッケージが取り扱うスパースファイルにおいて `未解決のバグ `_ があります。これは Docker コンテナ内にて非常に大きな値の UID を使ってユーザを生成しようとするため、ディスクを異常に消費します。コンテナ・レイヤ内の ``/var/log/faillog`` が NUL (\\0) キャラクタにより埋められてしまいます。useradd に対して ``--no-log-init`` フラグをつけると、とりあえずこの問題は回避できます。ただし Debian/Ubuntu の ``adduser`` ラッパーは ``--no-log-init`` フラグをサポートしていないため、利用できません。 + +.. note:: + + Go 言語の archive/tar パッケージが取り扱うスパースファイルにおいて `未解決のバグ `_ があります。これは Docker コンテナ内で非常に大きな値の UID を使ってユーザを生成しようとするため、ディスクを異常に消費します。コンテナ・レイヤ内の ``/var/log/faillog`` が NUL (\\0) キャラクタにより埋められてしまいます。useradd に対して ``--no-log-init`` フラグを付けますと、とりあえずこの問題は回避できます。ただし Debian/Ubuntu の ``adduser`` ラッパーは ``--no-log-init`` フラグをサポートしていないため、利用出来ません。 .. Avoid installing or using sudo as it has unpredictable TTY and signal-forwarding behavior that can cause problems. If you absolutely need functionality similar to sudo, such as initializing the daemon as root but running it as non-root, consider using “gosu”. -``sudo`` のインストールとその利用は避けてください。TTY やシグナル送信が予期しない動作をするため、多くの問題を引き起こす可能性があります。 ``sudo`` と同様の機能（たとえばデーモンの初期化を root により行い、起動は root 以外で行うなど）を実現する必要がある場合は、 `gosu `_ を検討ください。 +``sudo`` のインストールとその利用は避けてください。TTY やシグナル送信が予期しない動作をするため、多くの問題を引き起こす可能性があります。 ``sudo`` と同様の機能（例えばデーモンの初期化を root により行い、起動は root 以外で行うなど）を実現する必要がある場合は、 `gosu `_ を検討ください。 .. Lastly, to reduce layers and complexity, avoid switching USER back and forth frequently. -レイヤ数を減らしたり複雑にならないようにするためには、 ``USER`` の設定を何度も繰り返すのは避けてください。 +レイヤ数を減らしたり複雑さを減らしたりするには、 ``USER`` の設定を何度も繰り返すのは避けてください。 + +.. For more information about USER, see Dockerfile reference for the USER instruction. + +``USER`` 命令についての詳しい情報は、 :ref:`Dockerfile リファレンスの USER 命令 ` を御覧ください。 + + .. WORKDIR WORKDIR ---------- -.. Dockerfile reference for the WORKDIR instruction +.. For clarity and reliability, you should always use absolute paths for your WORKDIR. Also, you should use WORKDIR instead of proliferating instructions like RUN cd … && do-something, which are hard to read, troubleshoot, and maintain. -:ref:`Dockerfile リファレンスの WORKDIR コマンド ` +``WORKDIR`` に設定するパスは、分かりやすく確実なものとするために、絶対パス指定としてください。また ``RUN cd … && do-something`` といった長くなる一方のコマンドを書くくらいなら、 ``WORKDIR`` を利用してください。そのような書き方は読みにくく、トラブル発生時には解決しにくく保守が困難になるためです。 -.. For clarity and reliability, you should always use absolute paths for your WORKDIR. Also, you should use WORKDIR instead of proliferating instructions like RUN cd … && do-something, which are hard to read, troubleshoot, and maintain. +.. For more information about WORKDIR, see Dockerfile reference for the WORKDIR instruction. + +``WORKDIR`` 命令についての詳しい情報は、 :ref:`Dockerfile リファレンスの WORKDIR 命令 ` を御覧ください。 -``WORKDIR`` に設定するパスは、分かり易く確実なものとするために、絶対パス指定としてください。また ``RUN cd … && do-something`` といった長くなる一方のコマンドを書くくらいなら、 ``WORKDIR`` を利用してください。そのような書き方は読みにくく、トラブル発生時には解決しにくく保守が困難になるためです。 .. ONBUILD ONBUILD ---------- -.. Dockerfile reference for the ONBUILD instruction - -:ref:`Dockerfile リファレンスの ONBUILD コマンド ` - -.. An ONBUILD command executes after the current Dockerfile build completes. ONBUILD executes in any child image derived FROM the current image. Think of the ONBUILD command as an instruction the parent Dockerfile gives to the child Dockerfile. +.. An ONBUILD command executes after the current Dockerfile build completes. ONBUILD executes in any child image derived FROM the current image. Think of the ONBUILD command as an instruction that the parent Dockerfile gives to the child Dockerfile. -``ONBUILD`` 命令は、 ``Dockerfile`` によるビルドが完了した後に実行されます。``ONBUILD`` は、現在のイメージから ``FROM`` によって派生した子イメージで実行されます。つまり ``ONBUILD`` とは、親の ``Dockerfile`` から子どもの ``Dockerfile`` へ与える命令であると言えます。 +``ONBUILD`` 命令は、Dockerfileによるビルドが完了した後に実行されます。``ONBUILD`` は、現在のイメージから ``FROM`` によって派生した子イメージで実行されます。つまり ``ONBUILD`` とは、親の Dockerfile が子どもの Dockerfile へ与える命令であると言えます。 .. A Docker build executes ONBUILD commands before any command in a child Dockerfile. -Docker によるビルドにおいては ``ONBUILD`` の実行が済んでから、子イメージのコマンド実行が行われます。 +Docker によるビルドは、 子 Dockerfile 内のどの命令よりも先に ``ONBUILD`` 命令を実行します。 .. ONBUILD is useful for images that are going to be built FROM a given image. For example, you would use ONBUILD for a language stack image that builds arbitrary user software written in that language within the Dockerfile, as you can see in Ruby’s ONBUILD variants. -``ONBUILD`` は、所定のイメージから ``FROM`` を使ってのイメージ構築時に利用できます。たとえば特定言語のスタックイメージは ``ONBUILD`` を利用します。``Dockerfile`` 内にて、その言語で書かれたどのようなユーザ・ソフトウェアであっても構築できます。その例として `Ruby's ONBUILD variants `_ があります。 +``ONBUILD`` は、所定のイメージから ``FROM`` を使ってのイメージ構築時に利用できます。例えば特定言語のスタックイメージは ``ONBUILD`` を利用します。``Dockerfile`` 内にて、その言語で書かれたどのようなユーザ・ソフトウェアであっても構築できます。その例として `Ruby's ONBUILD variants `_ があります。 .. Images built with ONBUILD should get a separate tag, for example: ruby:1.9-onbuild or ruby:2.0-onbuild. -``ONBUILD`` によって構築するイメージは、異なったタグを指定してください。たとえば ``ruby:1.9-onbuild`` と ``ruby:2.0-onbuild`` などです。 +``ONBUILD`` によって構築するイメージは、異なったタグを指定してください。例えば ``ruby:1.9-onbuild`` と ``ruby:2.0-onbuild`` などです。 + +.. Be careful when putting ADD or COPY in ONBUILD. The onbuild image fails catastrophically if the new build’s context is missing the resource being added. Adding a separate tag, as recommended above, helps mitigate this by allowing the Dockerfile author to make a choice. + +``ONBUILD`` において ``ADD`` や ``COPY`` を用いるときは注意してください。onbuild イメージで新たに構築する際に、追加しようとしているリソースが見つからなかったとしたら、このイメージは復旧できない状態になります。上に示したように個別にタグをつけておけば、 Dockerfile の開発者にとっても判断ができるようになりますので、不測の事態は軽減されます。 + +.. For more information about ONBUILD, see Dockerfile reference for the ONBUILD instruction. + +``ONBUILD`` 命令についての詳しい情報は、 :ref:`Dockerfile リファレンスの ONBUILD 命令 ` を御覧ください。 -.. Be careful when putting ADD or COPY in ONBUILD. The “onbuild” image fails catastrophically if the new build’s context is missing the resource being added. Adding a separate tag, as recommended above, helps mitigate this by allowing the Dockerfile author to make a choice. -``ONBUILD`` において ``ADD`` や ``COPY`` を用いるときは注意してください。"onbuild" イメージが新たに構築すれる際に、追加しようとしているリソースが見つからなかったとしたら、このイメージは復旧できない状態になります。上に示したように個別にタグをつけておけば、 ``Dockerfile`` の開発者にとっても判断ができるようになるので、不測の事態は軽減されます。 .. Examples of Docker Official Images .. _examples-of-docker-official-images: @@ -1071,9 +1054,9 @@ Docker によるビルドにおいては ``ONBUILD`` の実行が済んでから Docker 公式リポジトリの例 ============================== -.. These Official Repositories have exemplary `Dockerfile`s: +.. These Official Repositories have exemplary `Dockerfiles: -以下に示すのは代表的な ``Dockerfile`` の例です。 +以下に示すのは代表的な Dockerfile の例です。 .. Go Perl @@ -1096,10 +1079,11 @@ Docker 公式リポジトリの例 Guidelines for Creating Docker Official Repositories * :doc:`Dockerfile リファレンス ` -* :doc:`ベース・イメージの詳細 ` * :doc:`自動構築の詳細 ` * :doc:`Docker 公式イメージ作成のガイドライン ` * `Best practices to containerize Node.js web applications with Docker `_ +* :doc:`ベースイメージについての詳細 ` + .. seealso:: diff --git a/develop/images/hub-official-images.png b/develop/images/hub-official-images.png new file mode 100644 index 000000000..8d6fa108c Binary files /dev/null and b/develop/images/hub-official-images.png differ diff --git a/develop/images/telepresence-architecture.png b/develop/images/telepresence-architecture.png new file mode 100644 index 000000000..2fd5950c5 Binary files /dev/null and b/develop/images/telepresence-architecture.png differ diff --git a/develop/index.rst b/develop/index.rst index b64b1ec25..e5b4b91aa 100644 --- a/develop/index.rst +++ b/develop/index.rst @@ -1,9 +1,9 @@ .. -*- coding: utf-8 -*- .. URL: https://docs.docker.com/develop/ - doc version: 20.10 + doc version: 24.0 https://github.com/docker/docker.github.io/blob/master/develop/index.md -.. check date: 2022/04/23 -.. Commits on Apr 22, 2022 75adef65ddf2547319451495e1ca3b8a4ce174a9 +.. check date: 2023/07/21 +.. Commits on Dec 20, 2022 21105dd888590c42ac6a9f7a9bfbd0921dadd6b3 .. ----------------------------------------------------------------------------- .. Develop with Docker @@ -42,7 +42,7 @@ Docker で新しいアプリを開発 .. If you’re just getting started developing a brand new app on Docker, check out these resources to understand some of the most common patterns for getting the most benefits from Docker. -まさにこれから Docker 上で真っ新なアプリケーションの開発を始めようとしているのであれば、Docker を最も活用するための共通パターンを理解するため、以下のリソースをご確認ください。 +ちょうどこれから Docker 上で真新しいアプリケーションの開発を始めようとしているのであれば、Docker を最も活用するための共通パターンを理解するため、以下のリソースを御覧ください。 .. Learn how to build an image using a Dockerfile Use multi-stage builds to keep your images lean @@ -52,7 +52,7 @@ Docker で新しいアプリを開発 General application development best practices * Dockerfile を使って :doc:`イメージ構築 ` の仕方を学ぶ -* * イメージをスリムにし続けるため、 :doc:`マルチステージ・ビルド ` を使う +* イメージをスリムにし続けるため、 :doc:`マルチステージ・ビルド ` を使う * :doc:`ボリューム ` と :doc:`バインド マウント ` を使いアプリケーションのデータを管理 * :doc:`Kubernetes でサービスをスケールする ` * :doc:`Swarm サービスとしてアプリケーションをスケールする ` @@ -73,8 +73,8 @@ Docker で言語特有のアプリケーション開発を学ぶ * `Docker for Java developers lab `_ * `Port a node.js app to Docker lab `_ * `Ruby on Rails app on Docker lab `_ -* `Dockerize a .Net Core application `_ -* Docker Compose を使う `Dockerize an ASP.NET Core application with SQL Server on Linux `_ +* `Dockerize a .Net Core application `_ +* Docker Compose を使う `Dockerize an ASP.NET Core application with SQL Server on Linux `_ .. Advanced development with the SDK or API .. _advanced-development-with-the-sdk-or-api: @@ -84,7 +84,7 @@ SDK や API で高度な開発 .. After you can write Dockerfiles or Compose files and use Docker CLI, take it to the next level by using Docker Engine SDK for Go/Python or use the HTTP API directly. Visit the Develop with Docker Engine API section to learn more about developing with the Engine API, where to find SDKs for your programming language of choice, and to see some examples. -Dockerfile や Composefile を書けるようになり、Docker CLI を使えるようになったあとは、Docker Engine SDK for Go/Python や HTTP API を直接使い、次のレベルへと進みましょう。 :doc:`Deocker Engine API で開発 ` のセクションを開き、自分が選んだプログラミング言語の SDK を見つけ、Engine API の開発を学んだり、使用例を見ましょう。 +Dockerfile や Composefile を書けるようになり、Docker CLI を使えるようになったあとは、Docker Engine SDK for Go/Python や HTTP API を直接使い、次のレベルへと進みましょう。 :doc:`Deocker Engine API で開発 ` のセクションを開き、自分が選んだプログラミング言語の SDK を見つけ、Engine API の開発を学び、使用例を見ましょう。 .. seealso:: diff --git a/develop/remote-development.rst b/develop/remote-development.rst new file mode 100644 index 000000000..550d9fe5b --- /dev/null +++ b/develop/remote-development.rst @@ -0,0 +1,149 @@ +.. -*- coding: utf-8 -*- +.. URL: https://docs.docker.com/develop/remote-development/ + doc version: 24.0 + https://github.com/docker/docker.github.io/blob/master/develop/remote-development.md +.. check date: 2023/07/23 +.. Commits on Jul 18, 2023 3f082722a41cbcb2e83c528b60ffeeb0c6d100cd +.. ----------------------------------------------------------------------------- + +.. Using Kubernetes for remote development +.. _using-kubernetes-for-remote-development: + +======================================== +リモート開発に Kubernetes を使う +======================================== + +.. sidebar:: 目次 + + .. contents:: + :depth: 2 + :local: + +.. Teams developing large, cloud-native applications might find themselves in a situation where it’s not possible to run the entire application locally on a development machine. There are several reasons why running an application locally is sometimes not feasible: + +クラウドネイティブなアプリケーションの大規模チーム開発では、ローカルな開発マシン上でアプリケーション全体を実行するのが困難な状況が起こり得るでしょう。アプリケーションをローカルで実行できないのは、幾つかの理由があります。 + +.. It requires more resources than your local machine can provide + There are dependencies to cloud services, APIs, or networking configurations that can’t be emulated + Testing and validating requires large amounts of data or network traffic + +* アプリケーションがローカルマシンが提供する以上のリソースを必要とする +* アプリケーションがクラウドサービス、API、ネットワーク設定と、エミュレートできない依存関係がある +* テストや検証に大規模データやネットワークトラフィックが必要となる + +.. Often, this means you need to rely on continuous integration pipelines or staging environments to verify code changes. This introduces a time-consuming and cumbersome workflow where you must commit, push, build, test, and deploy your code in order to see them running. + +度々、これらが意味するところ、コードの変更を確認するには、継続的インテグレーションのパイプラインやステージング環境に依存する必要があります。これらにより、コードが動くところを見るためには、コミット、プッシュ、構築、テスト、デプロイするたびに時間を浪費して、かつ、厄介なワークフローになっています。 + +.. Combining local and remote +.. _combining-local-and-remote: + +ローカルとリモートの組み合わせ +============================== + +.. One solution to this problem is to integrate local services with a remote development cluster. In practice, this means starting a service on your development machine using docker run, and allowing that local service to communicate with the development cluster over the network. The remote development cluster hosts workloads that represent the production environment. + +この問題に対する解決策の1つが、リモートデプロイ用のクラスタとローカルサービスとの統合です。実際の所これが意味するのは、自分の開発マシン上で ``docker run`` を使ってサービスを開始し、ローカルのサービスがネットワークを通して開発クラスタと通信できるようになります。リモート開発クラスタは、プロダクション環境に相当するワークロードを負担（ホスト）します。 + +.. A development environment that lets you combine containers running locally with remote resources helps simplify and speed up the inner loop. There are several tools available, commercial and open-source, that you can use to enable a hybrid local-and-remote development environment. For example: + +開発環境は、ローカルで実行しているコンテナとリモートでのリソースを連結できるので、内部ループの簡素化とスピードアップに役立ちます。それには商用やオープンソースで複数のツールが利用可能です。それらを使い、ローカルとリモート間でハイブリッドな開発環境に使えるでしょう。以下は例です。 + +.. Telepresence + CodeZero + Gefyra + kubefwd + ktunnel + +* `Telepresence `_ +* `CodeZero `_ +* `Gefyra `_ +* `kubefwd `_ +* `ktunnel `_ + +.. Telepresence +.. _telepresence: + +Telepresence +===================== + +.. Telepresence is an open-source CNCF project that helps you integrate local services with a remote Kubernetes cluster. Telepresence works by running a traffic manager pod in Kubernetes, and Telepresence client daemons on developer workstations. The traffic manager acts as a two-way network proxy that can intercept connections and route traffic between the cluster and containers running on developer machines. + +Telepresence はオープンソースの CNCF プロジェクトであり、リモートの Kubernetes クラスタとローカルサービスを統合するのに役立ちます。Telepresence は Kubernetes 内でトラフィックマネージャ（traffic manager）ポッドとして機能し、Telepresence クライアントは開発ワークステーション上のデーモンです。トラフィックマネージャは2種類のネットワークプロキシとして機能します。開発ワークステーション上で実行しているコンテナとクラスタとの間で、接続を受け付けたりトラフィックを経路付けしたりします。 + + .. image:: ./images/telepresence-architecture.png + :width: 90% + :alt: Telepresence のハイレベルアーキテクチャ + + +.. You have a few options for how the local containers can integrate with the cluster: + +ローカルコンテナをクラスタと統合するには、複数のオプションがあります。 + +.. No intercepts + The most basic integration involves no intercepts at all. Simply establishing a connection between the container and the cluster. This enables the container to access cluster resources, such as APIs and databases. + +* :ruby:`傍受 ` （捕捉）なし + + * 最も基本的な統合では、一切傍受しません。コンテナとクラスタ間の通信をシンプルに確立するだけです。これにより、コンテナは API やデータベースといったクラスタリソースにアクセスできるようになります。 + +.. Global intercepts + You can set up global intercepts for a service. This means all traffic for a service will be re-routed from Kubernetes to your local container. + +* :ruby:`グローバル傍受 ` + + * サービスに対してグローバル傍受をセットアップできます。これが意味するのは、サービスに対する全てのトラフィックが、ローカルコンテナから Kubernetes へと :ruby:`再経路付け ` されます。 + +.. Personal intercepts + The more advanced alternative to global intercepts is personal intercepts. Personal intercepts let you define conditions for when a request should be routed to your local container. The conditions could be anything from only routing requests that include a specific HTTP header, to requests targeting a specific route of an API. + +* :ruby:`パーソナル傍受 ` + + * グローバル傍受よりも更に高度な方法がパーソナル傍受です。パーソナル傍受により、ローカルのコンテナに対するリクエストがあるとき、経路付けをすべきとする条件を定義できるようにします。条件として設定できるのは経路付けリクエストのみであり、これには特定の HTTP ヘッダ、特定の API への経路に対するリクエストが含まれます。 + +.. Telepresence seamlessly integrates with Docker and it’s available for you to try today. Check out the following docs to learn more: + +Telepresence は Docker とシームレスに統合しており、今日から試せます。更に学ぶには以下のドキュメントを御覧ください。 + +.. Telepresence extension for Docker Desktop + Telepresence in Docker mode + Telepresence for Docker Compose + + +* `Telepresence extension for Docker Desktop `_ +* `Telepresence in Docker mode `_ +* `Telepresence for Docker Compose `_ + + +.. Docker × Ambassador + +Docker × Ambassador +------------------------------ + +.. Sharing a development cluster with a large team can be both a blessing and a curse. Because your teammates are connected to the cluster, you’re able to see what they’re working on. But they can also accidentally step on your intercepts of shared services. Ambassador Labs, creators of Telepresence, run a subscription platform that helps teams share the cluster. You can identify all the intercepts you have running on a service. Each developer can generate an authenticated preview URL to share during code review. + +大規模チームとの開発クラスタの共有は、恵みにも呪いにもなります。あなたのチームメイトがクラスタに接続すると、あなたは彼らが何をしているのか見えるようになるからです。しかし、彼らも意図せずあなたの共有サービスを傍受する可能性があります。Telepresence の開発者が作った Ambassador Labs は、チームがクラスタを共有するのに役立つサブスクリプションプラットフォームを運営しています。サービス上で実行している全ての傍受を識別できます。各開発者はコードレビュー中に共有できる、認証されたプレビュー URL を生成できます。 + +.. Docker and Ambassador Labs are working together to make running a hybrid local-remote development environment easy and seamless. You can now connect your Docker ID to Ambassador Cloud to sign in and use Telepresence. To get started: + +Docker と Ambassador Labs はローカルとリモートのハイブリッドな開発環境を、簡単かつシームレスにできるようにするため協働しています。Ambassador Cloud にサインインして Telepresence を使うには、自分の Docker ID で接続できます。始めるには： + +.. Go to the Docker × Ambassador page. + Sign in using your Docker ID. + Authorize the Ambassador Cloud app. + +1. `Docker × Ambassador page `_ ページに移動します。 +2. 自分の Docker ID にサインインします。 +3. Ambassador Cloud アプリを認証します。 + +.. This takes you to a step-by-step guide on setting up Telepresence, connecting to a development cluster, and creating intercepts. + +Telepresence のセットアップ、開発クラスタに接続し、それから傍受の作成について、手順を追って説明します。 + + +.. seealso:: + + Using Kubernetes for remote development + https://docs.docker.com/develop/remote-development/ + + diff --git a/develop/scan-images/index.rst b/develop/scan-images/index.rst index d1f2681dd..2c602046f 100644 --- a/develop/scan-images/index.rst +++ b/develop/scan-images/index.rst @@ -51,7 +51,7 @@ 既存の Docker プラットフォームを拡張し、脆弱性検査のオプションを導入すると、脆弱性検出の手順に慣れ、かつ、開発プロセスの初期で脆弱性の修正を可能にします。手順はシンプルで継続的に確認します。たとえば、バックグラウンドで `Snyk Advisor `_ を使ってイメージをチェックすると、Docker Hub 上にあるいくつかの脆弱性も確認できます。この結果、CI サイクルを短くし、開発から本番環境への信頼性を高めます。 .. image:: ./images/dev-security-journey.png - :scale: 60% + :width: 60% :alt: 開発者のセキュリティ ジャーニー .. Scanning images @@ -82,7 +82,7 @@ CLI を使って検査 イメージを構築したら、 Docker Hub にイメージを送る前に、 ``docker scan`` コマンドを実行します。CLI を使ったイメージ検査の手順詳細は、 :doc:`docker scan ` をご覧ください。 .. image:: ./images/docker-scan-cli.png - :scale: 60% + :width: 60% :alt: 脆弱性検査 .. Scan using Docker Hub @@ -101,7 +101,7 @@ Docker Hub を通した脆弱性検査、表示、調査のトリガを設定で Docker Hub 脆弱性検査が利用可能なのは、 Docker Pro、Team、Business を契約している開発者のみです。料金プランに関する詳しい情報は `Docker Pricing `_ をご覧ください。 .. image:: ./images/hvs-scan-summary.png - :scale: 60% + :width: 60% :alt: 脆弱性検査のサマリ .. View the scan summary in Docker Desktop @@ -151,7 +151,7 @@ Docker Desktop では、 Docker ダッシュボード上で脆弱性の状態に Docker Hub には 830 万以上のリポジトリがあります。この中のイメージのいくつかが Docker によって提供されている :doc:`公式イメージ（Official Image） ` であり、これは、Docker が企画したオープンソースのソリューションを集めたリポジトリです。また、 Docker は :doc:`Verified Publisher（認定パブリッシャー） ` が公開するイメージも提供します。これらの高品質なイメージは、 Docker と提携した組織によってメンテナンスされており、Docker が各リポジトリの信頼性を検証しているものです。ベースイメージを選ぶには、 **Official Image** （公式イメージ）と **Verified Publisher** （認定パブリッシャー）のバッジが付いているものを探してください。 .. image:: ./images/hub-official-images.png - :scale: 60% + :width: 60% :alt: Docker Hub 公式イメージ .. When building your own image from a Dockerfile, ensure you choose a minimal base image that matches your requirements. A smaller base image not just offers portability and fast downloads, but also shrinks the size of your image and minimizes the number of vulnerabilities introduced through the dependencies. diff --git a/develop/security-best-practices.rst b/develop/security-best-practices.rst new file mode 100644 index 000000000..65c8677ad --- /dev/null +++ b/develop/security-best-practices.rst @@ -0,0 +1,212 @@ +.. -*- coding: utf-8 -*- +.. URL: https://docs.docker.com/develop/security-best-practices/ + doc version: 24.0 + https://github.com/docker/docker.github.io/blob/master/develop/security-best-practices.md +.. check date: 2023/07/23 +.. Commits on May 31, 2023 0e376632a4cfa1c641528d238c766845e8196004 +.. ----------------------------------------------------------------------------- + +.. Security best practices +.. _security-best-practices: + +======================================== +セキュリティのベストプラクティス +======================================== + +.. sidebar:: 目次 + + .. contents:: + :depth: 2 + :local: + +.. You can take a few steps to improve the security of your container. This includes: + +いくつかの手順を経ますと、コンテナのセキュリティを改善できます。手順には以下が含まれます。 + +.. Choosing the right base image from a trusted source and keeping it small + Using multi-stage builds + Rebuilding images + Check your image for vulnerabilities + +1. 信頼できる場所から :ref:`choose-the-right-base-image` をし、小ささを維持 +2. :ref:`use-multi-stage-builds` +3. :ref:`rebuild-images` +4. :ref:`check-your-image-for-vulnerabilities` + +.. Choose the right base image +.. _choose-the-right-base-image: + +正しいベースイメージの選択 +============================== + +.. The first step towards achieving a secure image is to choose the right base image. When choosing an image, ensure it’s built from a trusted source and keep it small. + +安全なイメージを確保するための第一歩は、正しいベースイメージの選択です。イメージを選択するときは、信頼できる場所で構築されたものかを確認し、小ささを維持し続けます。 + +.. Docker Hub has more than 8.3 million repositories. Some of these images are Official Images, which are published by Docker as a curated set of Docker open source and drop-in solution repositories. Docker also offers images that are published by Verified Publishers. These high-quality images are published and maintained by the organizations partnering with Docker, with Docker verifying the authenticity of the content in their repositories. When you pick your base image, look out for the Official Image and Verified Publisher badges. + +Docker Hub には 830 万以上のリポジトリがあります。これらのいくつかは :doc:`公式イメージ（Official Images） ` と呼ばれ、Docker のオープンソースと手軽に導入できるソリューションのリポジトリが、 Docker によって選抜された集まりとして公開されているものです。また、 Docker は :doc:`認定パブリッシャー（Verified Publishers） ` によって作成されているイメージも提供しています。これらは高品質なイメージとして公開されており、Docker のパートナー組織によってメンテナンスされ、各リポジトリ内容の信頼性を Docker が検証しています。ベースイメージの選択時には、 **Official Image** と **Verified Publisher** バッジを探してください。 + +.. image:: ./images/hub-official-images.png + :width: 70% + :alt: Docker Hub 公式イメージ + +.. When building your own image from a Dockerfile, ensure you choose a minimal base image that matches your requirements. A smaller base image not just offers portability and fast downloads, but also shrinks the size of your image and minimizes the number of vulnerabilities introduced through the dependencies. + +Dockerfile から自分のイメージを構築するときは、要件に一致する最小のベースイメージを選択します。より小さなベースイメージはポータビリティ（移植性）や素早いダウンロードをもたらさないかもしれませんが、イメージの容量を減らし、依存関係をと通してもたらされる数々の脆弱性を最小化します。 + +.. You should also consider using two types of base images: the first image for development and unit testing and the second for testing during the latest stages of development and production. In the later stages of development, your image may not require some build tools such as compilers, build systems, or any debugging tools. A small image with minimal dependencies can considerably lower the attack surface. + +また、2種類のベースイメージを利用するのを検討した方が良いでしょう。1つ目のイメージは開発やユニットテスト用で、2つ目は開発の最終段階やプロダクション用です。開発の後半段階では、コンパイラ、構築システム、あるいはデバッギング・ツールなどの構築ツールが不要になるでしょう。依存関係が最小の小さなイメージにより、攻撃となりうる対象を大幅に減少できます。 + +.. Use multi-stage builds +.. _use-multi-stage-builds: + +マルチステージ ビルドを使う +============================== + +.. Multi-stage builds are designed to create an optimized Dockerfile that is easy to read and maintain. With a multi-stage build, you can use multiple images and selectively copy only the artifacts needed from a particular image. + +読みやすく保守しやすいように最適化された Dockerfile を作成するために、:ruby:`マルチステージ ビルド ` は設計されています。マルチステージ ビルドがあれば、複数のイメージを使って、ある特定のイメージから必要なアーティファクト（成果物）だけを選択してコピーできます。 + +.. You can use multiple FROM statements in your Dockerfile, and you can use a different base image for each FROM. You can also selectively copy artifacts from one stage to another, leaving behind things you don’t need in the final image. This can result in a concise final image. + +Dockerfile 内で複数の ``FROM`` を記述できるため、 ``FROM`` ごとに異なるベースイメージを利用できます。また、あるステージから別のステージにアーティファクトを選んでコピーできるため、最終イメージでは不要なものを除去できます。この結果、最終イメージは簡素にできます。 + +.. This method of creating a tiny image doesn’t only significantly reduce complexity, but also the change of implementing vulnerable artifacts in your image. Therefore, instead of images that are built on images, that again are built on other images, multi-stage builds allow you to ‘cherry pick’ your artifacts without inheriting the vulnerabilities from the base images on which they rely on. + +この手法で作られた小さなイメージは、複雑さを著しく減らすだけではありません。イメージ内に、脆弱性がある部分を組み込む流れも変わります。つまり、あるイメージから構築されたイメージを元にして、更にイメージを構築するという方法にかわり、マルチステージビルドであればベースイメージ上の脆弱性を継承することなく、必要なアーティファクトを選択して取り込めます。 + +.. For detailed information on how to configure multi-stage builds, see multi-stage builds. + +マルチステージビルドの設定方法についての詳しい情報は :doc:`マルチステージビルド ` を御覧ください。 + +.. Rebuild images +.. _rebuild-images: + +イメージの再構築 +==================== + +.. A Docker image is built from a Dockerfile. A Dockerfile contains a set of instructions which allows you to automate the steps you would normally (manually) take to create an image. Additionally, it can include some imported libraries and install custom software. These appear as instructions in the Dockerfile. + +Docker イメージは Dockerfile から構築します。Dockerfile に含まれるのは命令の集まりであり、これにより、通常の（手動で）イメージを作成する手順を自動化できるようになります。さらに、ライブラリの組み込みや、任意のソフトウェアのインストールが可能になります。これらが Dockerfile 内での命令として表されます。 + +.. Building your image is a snapshot of that image, at that moment in time. When you depend on a base image without a tag, you’ll get a different base image every time you rebuild. Also, when you install packages using a package installer, rebuilding can change the image drastically. For example, a Dockerfile containing the following entries can potentially have a different binary with every rebuild. + +自分用に構築するイメージとは、対象となるイメージの、該当時点におけるスナップショットです。タグを使わないベースイメージに依存する場合は、再構築時に毎回異なるベースイメージを入手します。また、パッケージのインストーラを使ってパッケージをインストールする場合は、再構築によってイメージが大幅に変わる可能性があります。例えば、以下にある内容の Dockerfile では、毎回再構築するたびに異なるバイナリを得る可能性があります。 + +.. code-block:: dockerfile + + # syntax=docker/dockerfile:1 + FROM ubuntu:latest + RUN apt-get -y update && apt-get install -y python + +.. We recommend that you rebuild your Docker image regularly to prevent known vulnerabilities that have been addressed. When rebuilding, use the option --no-cache to avoid cache hits and to ensure a fresh download. + +対応された既知の脆弱性を防ぐため、定期的な Docker イメージの再構築を推奨します。再構築時には、確実に新しいものをダウンロードし、キャッシュの適用を無効化するために ``--no-cache`` オプションを使います。 + +.. For example: + +例： + +.. code-block:: dockerfile + + $ docker build --no-cache -t myImage:myTag myPath/ + +.. Consider the following best practices when rebuilding an image: + +イメージの再構築時、以下のベストプラクティスに従うのを考えます。 + +.. Each container should have only one responsibility. + Containers should be immutable, lightweight, and fast. + Don’t store data in your container. Use a shared data store instead. + Containers should be easy to destroy and rebuild. + Use a small base image (such as Linux Alpine). Smaller images are easier to distribute. + Avoid installing unnecessary packages. This keeps the image clean and safe. + Avoid cache hits when building. + Auto-scan your image before deploying to avoid pushing vulnerable containers to production. + Analyze your images daily both during development and production for vulnerabilities. Based on that, automate the rebuild of images if necessary. + +* 各コンテナは、1つの役割のみ持たせるべき。 +* コンテナはイミュータブル（不変）、軽量、速くあるべき。 +* コンテナ内にデータを保管しない。代わりに共有データストアを使う。 +* コンテナは簡単に破棄と再構築できるべき。 +* （Alpine Linux のような）小さなベースイメージを使う。小さなイメージは配布も簡単。 +* 不要なパッケージのインストールを避ける。これにより、イメージをクリーンかつ安全に保つ。 +* 構築時はキャッシュのヒットを避ける。 +* 脆弱性のあるコンテナをプロダクションに送信するのを避けるため、デプロイ前にイメージの自動スキャンをする。 +* 開発中とプロダクションの両方で、日々イメージの脆弱性を分析する。その上で、必要があればイメージ再構築を自動化する。 + +.. For detailed best practices and methods for building efficient images, see Dockerfile best practices. + +効率的なイメージの構築関するベストプラクティスや手法の詳細は :doc:`Dockerfile ベストプラクティス ` を御覧ください。 + +.. Check your image for vulnerabilities +.. _check-your-image-for-vulnerabilities: + +イメージの脆弱性を確認するには +======================================== + +.. In addition to following the best practices outlined on this page when developing images, it’s also important to continuously analyze and evaluate the security posture of your images using vulnerability detection tools. + +このページでこれまで取り上げたイメージ構築のベストプラクティスに加え、脆弱性検出ツールを使い、イメージのセキュリティ状況の継続的な分析と評価も重要です。 + +.. Docker tools come with features helps you stay up to date about vulnerabilities that affect images that you build or use. + +Docker ツールには、イメージの構築や使用にあたり、日々脆弱性について更新し続けるために役立つ機能があります。 + +.. Docker Hub supports an automatic vulnerability scanning feature, which when enabled, automatically scans images when you push them to a Docker Hub repository. Requires a Docker subscription. + +* Docker Hub は自動的な :doc:`脆弱性スキャン ` 機能をサポートしています。これを有効にすると、Docker Hub リポジトリへイメージの送信時に自動的にスキャンします。 `Docker サブスクリプション `_ が必要です。 + +.. Docker Hub also supports an early-access advanced image analysis feature, which extends the “core” vulnerability scanning solution with enhanced capabilities and more detailed and actionable insights. + +* 早期アクセスの :doc:`高度なイメージ解析（advanced image analysis） ` 機能もサポートしています。これは「コア」となる脆弱性検査ソリューションを拡張したもので、能力の拡張や、より詳しく実用的な洞察を行います。 + +.. For the CLI, there’s the docker scout CLI plugin which lets you explore vulnerabilities for images using the terminal. + +* CLI 用としては :doc:`docker scout CLI プラグイン ` があります。これはターミナルを使ってイメージの脆弱性を探せます。 + +.. Docker Desktop sports a detailed image view for images in your local image store, that visualizes all of the known vulnerabilities affecting an image. + +* Docker Desktop はローカルに保存しているイメージの詳細を表示し、既知の脆弱性による影響をうけるイメージ情報を視覚的に全て表示します。 + +.. All of these security features are powered by the same technology: Docker Scout. These features help you achieve a holistic view of your supply chain security, and to provide actionable suggestions for what you can do to remediate those vulnerabilities. + +これらの機能はすべて :doc:`Docker Scout（ドッカー スカウト） ` の技術を備えています。これら機能により、セキュリティに関する供給網（サプライチェーン）の全体像を表示するのに役立つでしょう。また、各脆弱性に対応できるようにするため、対処可能な提案も提供します。 + +.. Conclusion + +まとめ +========== + +.. Building secure images is a continuous process. Consider the recommendations and best practices highlighted in this guide to plan and build efficient, scalable, and secure images. + +安全なイメージの構築とは、継続的なプロセスです。このガイドにおける推奨やベストプラクティスを、計画、効率的な構築、スケーラブル、安全なイメージのために検討ください。 + +.. To summarize the topics covered in this guide: + +このガイドで扱った話題を要約すると： + +.. Start with a base image that you trust. Pay attention to the Official image and Verified Publisher badges when you choose your base images. + Secure your code and its dependencies. + Select a minimal base image which contains only the required packages. + Use multi-stage builds to optimize your image. + Ensure you carefully monitor and manage the tools and dependencies you add to your image. + Ensure you scan images at multiple stages during your development lifecycle. + Check your images frequently for vulnerabilities. + +* 信頼できるベースイメージから始めます。ベースイメージの選択時、公式イメージ（Official image）と認定パブリッシャー（Verified Publisher）バッジに注目します。 +* コードと依存関係を安全に保ちます。 +* 最小限必要なパッケージがある最小のベースイメージのみ選択します。 +* イメージを最適化するため、マルチステージビルドを使います。 +* イメージにツールや依存関係を追加するときは、確実に注意深く観察・管理します。 +* イメージに対する脆弱性を定期的に確認します。 + + +.. seealso:: + + Security best practices | Docker Documentation + https://docs.docker.com/develop/security-best-practices/ + + diff --git a/develop/toc.rst b/develop/toc.rst index 62178db27..949e08060 100644 --- a/develop/toc.rst +++ b/develop/toc.rst @@ -1,7 +1,7 @@ .. -*- coding: utf-8 -*- .. -.. doc version: -.. check date: 2020/06/18 +.. doc version: 24.0 +.. check date: 2023/07/20 .. ----------------------------------------------------------------------------- .. Develop with Docker -toc: @@ -15,7 +15,8 @@ Docker で開発 :titlesonly: 概要 - ベストプラクティス - イメージ構築 - イメージ検査 + 開発ベストプラクティス + Dockerfile ベストプラクティス + セキュリティのベストプラクティス + リモート開発 diff --git a/docker-hub/accounts.rst b/docker-hub/accounts.rst index ae698b65c..65dd26caa 100644 --- a/docker-hub/accounts.rst +++ b/docker-hub/accounts.rst @@ -75,7 +75,7 @@ Docker Hub アカウントを作成する別の方法は、コマンドライン .. Login using the web console .. image:: ./images/login-web.png - :scale: 60% + :width: 60% :alt: ウェブ・コンソールでログイン .. Or via the command line with the docker login command: diff --git a/docker-hub/bitbucket.rst b/docker-hub/bitbucket.rst index b9e52011f..d58c72f27 100644 --- a/docker-hub/bitbucket.rst +++ b/docker-hub/bitbucket.rst @@ -35,7 +35,7 @@ Bitbucket 上のリポジトリに対する自動構築をセットアップす .. authorized-services .. image:: ./images/linked-acct.png - :scale: 60% + :width: 60% :alt: リンクされたアカウント .. Then follow the onscreen instructions to authorize and link your Bitbucket account to Docker Hub. Once it is linked, you’ll be able to create a Docker Hub repository from which to create the Automatic Build. @@ -83,7 +83,7 @@ Bitbucket のサービス・フック・ログを確認・変更するには、 .. bitbucket-hooks .. image:: ./images/bitbucket-hook.png - :scale: 60% + :width: 60% :alt: bitbucket の hook diff --git a/docker-hub/builds.rst b/docker-hub/builds.rst index c9d25e29c..0dc590bf5 100644 --- a/docker-hub/builds.rst +++ b/docker-hub/builds.rst @@ -70,7 +70,7 @@ Docker Hub の自動構築 システムがログインのためサービス（Bitbucket か GitHub）の委任を要求してきます。次の例は Bitbucket のプロンプト例です。 .. image:: ./images/bitbucket-creds.png - :scale: 60% + :width: 60% :alt: Bitbucket .. After you grant access to your code repository, the system returns you to Docker Hub and the link is complete. @@ -80,7 +80,7 @@ Docker Hub の自動構築 .. Linked account .. image:: ./images/linked-acct.png - :scale: 45% + :width: 45% :alt: リンク済みアカウント .. Create an automated build @@ -121,7 +121,7 @@ Docker Hub の自動構築 .. Create dialog .. image:: ./images/create-dialog1.png - :scale: 60% + :width: 60% :alt: 作成ダイアログ .. The dialog assumes some defaults which you can customize. By default, Docker builds images for each branch in your repository. It assumes the Dockerfile lives at the root of your source. When it builds an image, Docker tags it with the branch name. @@ -135,7 +135,7 @@ Docker Hub の自動構築 .. Create dialog .. image:: ./images/create-dialog1.png - :scale: 60% + :width: 60% :alt: 作成ダイアログ .. Specify which code branches or tags to build from. You can add new configurations by clicking the + (plus sign). The dialog accepts regular expressions. @@ -145,7 +145,7 @@ Docker Hub の自動構築 .. Create dialog .. image:: ./images/regex-help.png - :scale: 60% + :width: 60% :alt: 作成ダイアログ .. Click Create. @@ -159,7 +159,7 @@ Docker Hub の自動構築 .. Home page .. image:: ./images/home-page.png - :scale: 45% + :width: 45% :alt: 自動構築ホームページ .. Within GitHub, a Docker integration appears in your repositories Settings > Webhooks & services page. @@ -169,7 +169,7 @@ GitHub を使っている場合、リポジトリの Settings > Webhooks & Servi .. GitHub .. image:: ./images/docker-integration.png - :scale: 60% + :width: 60% :alt: GitHub .. A similar page appears in Bitbucket if you use that code repository.Be careful to leave the Docker integration in place. Removing it causes your automated builds to stop. @@ -190,7 +190,7 @@ Bitbucket のコード・リポジトリを使っている場合も、同様に .. Pending .. image:: ./images/first-pending.png - :scale: 45% + :width: 45% :alt: 構築のログ .. During the build process, Docker copies the contents of your Dockerfile to Docker Hub. The Docker community (for public repositories) or approved team members/orgs (for private repositories) can then view the Dockerfile on your repository page. @@ -219,7 +219,7 @@ Build Setting ページでは、既存の自動構築設定の管理や、新し .. Default checkbox .. image:: ./images/merge-buildings.png - :scale: 60% + :width: 60% :alt: チェックボックス .. Clear the checkbox to turn this behavior off. You can use the other settings on the page to configure and build images. @@ -263,7 +263,7 @@ Docker はコード・リポジトリに対して push で変更が加えられ .. Regexhelp .. image:: ./images/regex-help.png - :scale: 60% + :width: 60% :alt: 正規表現のヘルプ .. Enter a Dockerfile location. @@ -316,7 +316,7 @@ Docker はコード・リポジトリに対して push で変更が加えられ .. Links .. image:: ./images/repo-links.png - :scale: 60% + :width: 60% :alt: リポジトリへのリンク .. Remote Build triggers @@ -333,7 +333,7 @@ Docker はコード・リポジトリに対して push で変更が加えられ .. Build trigger screen .. image:: ./images/build-trigger.png - :scale: 60% + :width: 60% :alt: 構築トリガの画面 .. You can use curl to trigger a build: diff --git a/docker-hub/github.rst b/docker-hub/github.rst index 27cf23ef6..92db9233f 100644 --- a/docker-hub/github.rst +++ b/docker-hub/github.rst @@ -41,7 +41,7 @@ Bitbucket 上のリポジトリに対する自動構築をセットアップす .. authorized-services .. image:: ./images/linked-acct.png - :scale: 60% + :width: 60% :alt: リンクされたアカウント .. When linking to GitHub, you’ll need to select either “Public and Private”, or “Limited Access” linking. @@ -235,7 +235,7 @@ Docker Hub からリンクする GitHub アカウントが「Limited Access」 .. bitbucket-hooks .. image:: ./images/github-service-hook.png - :scale: 60% + :width: 60% :alt: GitHub サービスフック .. If you add the “Docker” service manually, make sure the “Active” checkbox is selected and click the “Update service” button to save your changes. diff --git a/docker-hub/official_repos.rst b/docker-hub/official_repos.rst index 69a8161b5..a92fc568c 100644 --- a/docker-hub/official_repos.rst +++ b/docker-hub/official_repos.rst @@ -156,7 +156,7 @@ Docker セキュリティ・スキャニングの結果を見るには、以下 .. ![](images/scan-drilldown.gif) .. image:: images/scan-drilldown.gif - :scale: 60% + :width: 60% .. You can click into a tag's detail page to see more information about which layers in the image and which components within the layer are vulnerable. diff --git a/docker-hub/orgs.rst b/docker-hub/orgs.rst index 253ec9d0a..e90864c27 100644 --- a/docker-hub/orgs.rst +++ b/docker-hub/orgs.rst @@ -43,7 +43,7 @@ Docker Hub の `組織 `_ （organization .. ![organizations](images/orgs.png) .. image:: ./images/orgs.png - :scale: 60% + :width: 60% :alt: organizations 画面 .. ### Organization teams @@ -65,7 +65,7 @@ Docker Hub の `組織 `_ （organization .. ![teams](images/groups.png) .. image:: ./images/groups.png - :scale: 60% + :width: 60% :alt: チーム .. ### Repository team permissions @@ -113,7 +113,7 @@ Docker Hub の `組織 `_ （organization .. ![Organization repository collaborators](images/org-repo-collaborators.png) .. image:: ./images/org-repo-collaborators.png - :scale: 60% + :width: 60% :alt: Organization リポジトリのコラボレータ diff --git a/docker-hub/overview.rst b/docker-hub/overview.rst index 1c2a074fa..880e159b4 100644 --- a/docker-hub/overview.rst +++ b/docker-hub/overview.rst @@ -18,7 +18,7 @@ Docker Hub 概要 `Docker Hub `__ はクラウド上のレジストリ・サービスであり、アプリケーションやサービス・コンテナの構築と配信を行います。コンテナ化されたイメージを見つけたり、配布したり、変更の管理、ユーザやチームのコラボレーション、開発パイプラインを通したワークフローの自動化といった集約されたリソースを提供します。 .. image:: ./images/getting-started.png - :scale: 60% + :width: 60% :alt: はじめましょう .. Specifically, Docker Hub provides the following major features and functions: diff --git a/docker-hub/repos.rst b/docker-hub/repos.rst index cb0988d79..124d05923 100644 --- a/docker-hub/repos.rst +++ b/docker-hub/repos.rst @@ -35,7 +35,7 @@ Docker Hub リポジトリは、共同作業者、顧客、Docker コミュニ .. ![repositories](/docker-hub/images/repos.png) .. image:: ./images/repos.png - :scale: 60% + :width: 60% :alt: リポジトリ .. ## Searching for images @@ -130,7 +130,7 @@ Docker Hub リポジトリ上の「タグ」（Tags）画面では、利用可 .. ![images/busybox-image-tags.png](/docker-hub/images/busybox-image-tags.png) .. image:: ./images/busybox-image-tags.png - :scale: 60% + :width: 60% :alt: タグの一覧 .. ## Creating a new repository on Docker Hub diff --git a/engine/article-img/architecture.png b/engine/article-img/architecture.png deleted file mode 100644 index 0dd6b63fc..000000000 Binary files a/engine/article-img/architecture.png and /dev/null differ diff --git a/engine/userguide/networking/dockernetworks.rst b/engine/userguide/networking/dockernetworks.rst index 1398b87c4..80053138d 100644 --- a/engine/userguide/networking/dockernetworks.rst +++ b/engine/userguide/networking/dockernetworks.rst @@ -417,14 +417,14 @@ Docker Engine は自動的にネットワークの ``Subnet`` と ``Gateway`` このネットワーク内で起動したコンテナは、Docker ホスト上の他のコンテナとは独立しています。ネットワーク内の各コンテナは速やかに通信が可能です。しかし、コンテナ自身が含まれるネットワークは外部のネットワークから独立しています。 .. image:: ./images/bridge_network.png - :scale: 60% + :width: 60% .. Within a user-defined bridge network, linking is not supported. You can expose and publish container ports on containers in this network. This is useful if you want to make a portion of the bridge network available to an outside network. ユーザ定義ブリッジ・ネットワークの内部では、リンク機能はサポートされません。ですが、このネットワーク上にあるコンテナのポートは公開可能です。 ``bridge`` ネットワークの一部を外のネットワークから使う時に便利でしょう。 .. image:: ./images/network_access.png - :scale: 60% + :width: 60% .. A bridge network is useful in cases where you want to run a relatively small network on a single host. You can, however, create significantly larger networks by creating an overlay network. @@ -446,14 +446,14 @@ Docker の ``overlay`` （オーバレイ）ネットワーク・ドライバは ``overlay`` ネットワークはキーバリュー・ストア・サービスが必要です。現時点で Docker の ``libkv`` がサポートしているのは、Consul、Etcd、Zookeeper（分散ストア）です。ネットワークを作成する前に、キーバリュー・ストア・サービスを選び、設定する必要があります。そして、Docker ホスト側では、ネットワークとサービスが通信できるようにします。 .. image:: ./images/key-value.png - :scale: 60% + :width: 60% .. Each host in the network must run a Docker Engine instance. The easiest way to provision the hosts are with Docker Machine. ネットワークの各ホストは、それぞれで Docker エンジンを動かす必要があります。最も簡単なのは Docker Machine を使ってホストをプロビジョンする方法です。 .. image:: ./images/engine-on-net.png - :scale: 60% + :width: 60% .. You should open the following ports between each of your hosts. @@ -511,7 +511,7 @@ Docker Machine でプロビジョンしたら、Docker Swarm を使うための この結果、複数のホストを横断する１つのネットワークができます。 ``overlay`` ネットワークはコンテナに対して、完全なる独立機能を提供します。 .. image:: ./images/overlay-network.png - :scale: 60% + :width: 60% .. Then, on each host, launch containers making sure to specify the network name. @@ -524,7 +524,7 @@ Docker Machine でプロビジョンしたら、Docker Swarm を使うための 接続したあと、ネットワーク内の各コンテナ全てにアクセス可能となります。この時、コンテナがどこのホスト上で起動しているか気にする必要はありません。 .. image:: ./images/overlay-network-final.png - :scale: 60% + :width: 60% .. If you would like to try this for yourself, see the Getting started for overlay. diff --git a/engine/userguide/networking/work-with-networks.rst b/engine/userguide/networking/work-with-networks.rst index d975a79ee..87418f0d3 100644 --- a/engine/userguide/networking/work-with-networks.rst +++ b/engine/userguide/networking/work-with-networks.rst @@ -343,7 +343,7 @@ Docker Engineが自動的に ``container2`` に IP アドレスを割り当て ``container2`` は２つのネットワークに所属しているのが分かります。 ``bridge`` ネットワークは起動時にデフォルトで参加したネットワークであり、 ``isolated_nw`` ネットワークは後から自分で接続したものです。 .. image:: ./images/working.png - :scale: 60% + :width: 60% :alt: Docker のネットワーク .. In the case of container3, you connected it through docker run to the isolated_nw so that container is not connected to bridge. diff --git a/get-docker.rst b/get-docker.rst index f15bcc7a6..6eece316e 100644 --- a/get-docker.rst +++ b/get-docker.rst @@ -1,10 +1,10 @@ .. -*- coding: utf-8 -*- .. URL: https://docs.docker.com/get-docker/ - doc version: 20.10 + doc version: 24.0 https://github.com/docker/docker.github.io/blob/master/get-docker.md -.. check date: 2022/09/20 +.. check date: 2023/07/15 +.. Commits on Feb 8, 2023 8e16fb93738964dfd03b0f579f433ec0456cc1bd .. Commits on Sep 5, 2022 cc0fc46783533fcd8e15e1d139ce2ae5e41f61b2 -.. Commits on Jan 18, 2022 fd943a6ab937adc65007fe654fcc9d8e58efd8fe .. ----------------------------------------------------------------------------- .. Get Docker @@ -14,14 +14,6 @@ Docker の入手 ======================================= -.. - Docker Desktop terms - Commercial use of Docker Desktop in larger enterprises (more than 250 employees OR more than $10 million USD in annual revenue) and in government entities requires a paid subscription. - -.. important:: **Docker Desktop の利用条件** - - 現在、大企業（従業員が 251 人以上、または、年間収入が 1,000 万米ドル以上 ）、政府機関における Docker Desktop の商用利用には、有料サブスクリプション契約が必要です。 - .. Docker is an open platform for developing, shipping, and running applications. Docker enables you to separate your applications from your infrastructure so you can deliver software quickly. With Docker, you can manage your infrastructure in the same ways you manage your applications. By taking advantage of Docker’s methodologies for shipping, testing, and deploying code quickly, you can significantly reduce the delay between writing code and running it in production. Docker はアプリケーションを開発、移動、実行するためのプラットフォームです。Docker によってインフラ上でアプリケーションを分離できるので、ソフトウェアを迅速に展開できます。Docker があれば、アプリケーションを自分で管理できるのと同じ手法で、インフラも管理できます。Docker の手法を移動、テスト、コードの迅速な開発に活かせるため、コードの記述とプロダクションでの実行までの間にかかる遅延を劇的に減少できます。 @@ -36,8 +28,20 @@ Docker はアプリケーションを開発、移動、実行するためのプ * :doc:`Docker Desktop for Windows ` * ネイティブな Windows アプリケーションで、Windows コンピュータ用に全ての Docker ツールを提供 +.. A native Linux application which delivers all Docker tools to your Linux computer. + * :doc:`Docker Desktop for Linux ` - * ネイティブな Windows アプリケーションで、Windows コンピュータ用に全ての Docker ツールを提供 + * ネイティブな Linux アプリケーションで、Linux コンピュータ用に全ての Docker ツールを提供 + + + +.. Note + If you’re looking for information on how to install Docker Engine, see Docker Engine installation overview. + + +.. note:: + + Docker Engine のインストール方法を探している場合は、 :doc:`Docker Engine インストール概要 ` をご覧ください。 .. seealso:: diff --git a/get-started/01_overview.rst b/get-started/01_overview.rst new file mode 100755 index 000000000..54dcc998c --- /dev/null +++ b/get-started/01_overview.rst @@ -0,0 +1,113 @@ +.. -*- coding: utf-8 -*- +.. URL: https://docs.docker.com/get-started/ + doc version: 24.0 + https://github.com/docker/docker.github.io/blob/master/get-started/index.md +.. check date: 2023/07/18 +.. Commits on Mar 1, 2023 5f613c757a31ffbe1585e63491d19093afbde7a2 +.. ----------------------------------------------------------------------------- + +.. Overview +.. _get-started-overview: + +======================================== +概要 +======================================== + +.. sidebar:: 目次 + + .. contents:: + :depth: 2 + :local: + +.. Welcome! We are excited that you want to learn Docker. + +ようこそ！ あなたが Docker を学ぼうとしているので、私たちはとてもうれしいです。 + +.. This guide contains step-by-step instructions on how to get started with Docker. Some of the things you’ll learn and do in this guide are: + +このガイドでは順を追った手順に従い、Docker の始め方を学びます。このガイドで学び、できるようになるのは以下の項目です。 + +.. + Build and run an image as a container + Share images using Docker Hub + Deploy Docker applications using multiple containers with a database + Run applications using Docker Compose + +* イメージをコンテナとして構築と実行 +* Docker Hub を使ったイメージ共有 +* データベースを持つ複数のコンテナを使う Docker アプリケーションのデプロイ +* Docker Compose を使ってアプリケーションを実行 + +.. Before you get to the hands on part of the guide, you should learn about containers and images. + +ガイドに進む前に、コンテナとイメージについて学ぶべきです。 + +.. What is a container? +.. _what-is-a-container: + +コンテナとは何？ +==================== + +.. Simply put, a container is a sandboxed process on your machine that is isolated from all other processes on the host machine. That isolation leverages kernel namespaces and cgroups, features that have been in Linux for a long time. Docker has worked to make these capabilities approachable and easy to use. To summarize, a container: + +簡単に言えば、 :ruby:`コンテナ ` とはマシン上でサンドボックス化したプロセスであり、ホストマシン上にある他すべてのプロセスから :ruby:`隔離 ` されています。この隔離とは `カーネルの名前空間と cgroup `_ の活用であり、長らく Linux に存在する機能です。Docker はこれらの :ruby:`能力 ` を、分かりやすく簡単に使えます。コンテナについてまとめますと、次のようになります： + +.. is a runnable instance of an image. You can create, start, stop, move, or delete a container using the DockerAPI or CLI. + can be run on local machines, virtual machines or deployed to the cloud. + is portable (can be run on any OS) + is isolated from other containers and runs its own software, binaries, and configurations. + +* イメージの実行可能な :ruby:`実体（インスタンス） ` 。Docker API や CLI を使い、コンテナの作成、開始、停止、移動、削除ができます。 +* ローカルマシン上や仮想マシン上で実行できるのに加え、クラウドにもデプロイできます。 +* :ruby:`可搬性（ポータビリティ） ` があります（多くの OS で実行できます）。 +* コンテナはお互いに隔離され、実行にはそれぞれが自身のソフトウェア、バイナリ、設定を使います。 + +.. What is a container image? +.. _what-is-a-container-image: + +コンテナ イメージとは何でしょうか？ +======================================== + +.. When running a container, it uses an isolated filesystem. This custom filesystem is provided by a container image. Since the image contains the container’s filesystem, it must contain everything needed to run an application - all dependencies, configurations, scripts, binaries, etc. The image also contains other configuration for the container, such as environment variables, a default command to run, and other metadata. + +コンテナを実行したら、コンテナは隔離されたファイルシステムを使います。この特別なファイルシステムは :ruby:`コンテナ イメージ ` によって提供されます。イメージにはコンテナのファイルシステムが含まれており、アプリケーションの実行に必要な全てを含む必要があります。例えば、全ての（アプリケーションを実行するために必要なパッケージ等の）依存関係、設定ファイル、スクリプト、バイナリ等です。また、このイメージには環境変数、デフォルトで実行するコマンド、メタデータのような他の設定も含みます。 + +.. We’ll dive deeper into images later on, covering topics such as layering, best practices, and more. + +イメージに関して、このガイドの後のレイヤ化、ベストプラクティス等のトピックで深掘りします。 + +.. Info + If you’re familiar with chroot, think of a container as an extended version of chroot. The filesystem is simply coming from the image. But, a container adds additional isolation not available when simply using chroot. + +.. note:: + + ``chroot`` を熟知していれば、コンテナとは ``chroot`` の拡張バージョンと考えてみましょう。ファイルシステムとは、単にイメージから由来します。ですが、コンテナの場合は、単純に chroot の使用ではできない付加的な隔離を追加します。 + + +.. Next steps +次のステップ +==================== + +.. In this section, you learned about containers and images. + +このセクションでは、コンテナとイメージについて学びました。 + +.. In the next section, you’ll containerize your first application. + +次のセクションでは、アプリケーションをコンテナ化しましょう。 + +.. raw:: html + + + + + + +.. seealso:: + + Orientation and setup + https://docs.docker.com/get-started/ + + diff --git a/get-started/02_our_app.rst b/get-started/02_our_app.rst index 662a7e287..4e8565615 100644 --- a/get-started/02_our_app.rst +++ b/get-started/02_our_app.rst @@ -1,16 +1,16 @@ .. -*- coding: utf-8 -*- .. URL: https://docs.docker.com/get-started/02_our_app/ - doc version: 20.10 + doc version: 24.0 https://github.com/docker/docker.github.io/blob/master/get-started/02_our_app.md -.. check date: 2022/09/20 -.. Commits on Jul 28, 2022 820366d4bfe722cc6f47847066214a48b56d66c5 +.. check date: 2023/07/16 +.. Commits on Jun 28, 2023 50ea31a03d158ce12466422856930e4666451a3d .. ----------------------------------------------------------------------------- -.. Sample application -.. _sample-application: +.. Containerize an application +.. _containerize-an-application: ======================================== -サンプル・アプリケーション +アプリケーションのコンテナ化 ======================================== .. sidebar:: 目次 @@ -19,17 +19,30 @@ :depth: 2 :local: -.. For the rest of this tutorial, we will be working with a simple todo list manager that is running in Node.js. If you’re not familiar with Node.js, don’t worry. No real JavaScript experience is needed. +.. For the rest of this guide, you’ll be working with a simple todo list manager that runs on Node.js. If you’re not familiar with Node.js, don’t worry. This guide doesn’t require any prior experience with JavaScript. -以降のチュートリアルでは、Node.js で動作するシンプルな Todo リスト・マネージャを扱います。Node.js に慣れていなくても、心配無用です。実際の JavaScript 経験を必要としません。 +以降のガイドでは、 Node.js で動作するシンプルな Todo リスト管理を扱います。Node.js に慣れていなくても、心配はいりません。このガイドでは JavaScript の事前経験は要りません。 -.. At this point, your development team is quite small and you’re simply building an app to prove out your MVP (minimum viable product). You want to show how it works and what it’s capable of doing without needing to think about how it will work for a large team, multiple developers, etc. +.. To complete this guide, you’ll need the following: -この段階では、あなたの開発チームは非常に小さく、MVP（ :ruby:`実用最小限の製品 ` ）を検証するためのアプリを構築したばかりです。このアプリが機能する所を見せたいので、この時点では、大きなチームや複数の開発者等が、どのようにして動作させるかを考慮する必要はありません。 +このガイドを終えるために、以下の項目が必要です： -.. image:: ./images/todo-list-sample.png - :scale: 60% - :alt: Todo List Manager のスクリーンショット +.. Docker running locally. Follow the instructions to download and install Docker. + A Git client. + Note + If you use Windows and want to use Git Bash to run Docker commands, see Working with Git Bash for syntax differences. + An IDE or a text editor to edit files. Docker recommends using Visual Studio Code. + A conceptual understanding of containers and images. + +* ローカルで動作する Docker。 :doc:`Docker のダウンロードとインストール ` の手順に従ってください。 +* `Git クライアント `_ 。 + + .. note:: + + Windows を利用中で、Git Bash を使って Docker コマンドを実行したい場合は、構文の違いについて :ref:`desktop-topics-windows-working-with-git-bash` を御覧ください。 + +* ファイルを編集するための IDE （統合開発環境）やテキストエディタ。Docker は `Visual Studio Code `_ の利用を推奨します。 +* :ref:`コンテナとイメージ ` の概念を理解。 .. Get the app .. _get-the-app: @@ -37,21 +50,25 @@ アプリの入手 ==================== -.. Before we can run the application, we need to get the application source code onto our machine. For real projects, you will typically clone the repo. But, for this tutorial, we have created a ZIP file containing the application. +.. Before you can run the application, you need to get the application source code onto your machine. -アプリケーションを実行する前に、マシン上にアプリケーションのソースコードを入手する必要があります。実際のプロジェクトでは、リポジトリのクローンが一般的でしょう。ですが、このチュートリアルでは、アプリケーションを含む ZIP ファイルを作成しました。 +アプリケーションを実行する前に、マシン上にアプリケーションのソースコードを入手する必要があります。 -.. Download the App contents from the getting-started repository. You can either pull the entire project or download it as a zip and extract the app folder out to get started with. +.. Clone the getting-started repository using the following command: + git clone https://github.com/docker/getting-started.git + View the contents of the cloned repository. Inside the getting-started/app directory you should see package.json and two subdirectories (src and spec). -.. Download the App contents. You can either pull the entire project or download it as a zip and extract the app folder out to get started with. - Once extracted, use your favorite code editor to open the project. If you’re in need of an editor, you can use Visual Studio Code. You should see the package.json and two subdirectories (src and spec). +1. 次のコマンドを使い、 `getting-started リポジトリ `_ をクローンします。 + + .. code-block:: bash + + $ git clone https://github.com/docker/getting-started.git -1. アプリの中身を `getting-started リポジトリ `_ からダウンロードします。 プロジェクト全体を pull するか、あるいは、 `リポジトリの zip ファイルをダウンロード `_ してアプリ用フォルダに展開してから始めましょう。 -2. 展開後は、好きなコードエディタでプロジェクトを開きます。エディタが必要であれば、 `Visual Studio Code `_ が使えます。開くと、 ``package.json`` と2つのサブディレクトリ（ ``src`` と ``spec`` ）が見えるでしょう。 +2. クローンしたリポジトリの内容を表示します。 ``getting-started/app`` ディレクトリ内に、 ``package.json`` と2つのサブディレクトリ（ ``src`` と ``spec`` ）が見えるでしょう。 -.. image:: ./images/ide-screenshot.png - :scale: 60% - :alt: Virusl Studio Code で 読み込んだアプリのスクリーンショット + .. image:: ./images/ide-screenshot.png + :width: 60% + :alt: Virusl Studio Code で 読み込んだアプリのスクリーンショット .. Build the app’s container image .. _build-the-apps-container-image: @@ -59,15 +76,55 @@ アプリのコンテナ イメージを :ruby:`構築 ` ================================================== -.. In order to build the application, we need to use a Dockerfile. A Dockerfile is simply a text-based script of instructions that is used to create a container image. If you’ve created Dockerfiles before, you might see a few flaws in the Dockerfile below. But, don’t worry. We’ll go over them. +.. To build the container image, you’ll need to use a Dockerfile. A Dockerfile is simply a text-based file with no file extension that contains a script of instructions. Docker uses this script to build a container image. -アプリケーションを :ruby:`構築 ` するには、 ``Dockerfile`` を使う必要があります。 Dockerfile とは、コンテナ イメージの作成で使う命令が、分かりやすい文字列で構成されるスクリプトです。これまでに Dockerfile の作成経験があれば、以下手順にある Dockerfile には問題があると気づくかもしれません。ですが、今は心配しないでください。後ほど説明します。 +:ref:`コンテナ イメージ ` を :ruby:`構築 ` するには、 ``Dockerfile`` を使う必要があります。Dockerfile とはシンプルな文字情報を主体とするファイルで、ファイルの拡張子がありません。このファイル内に命令のスクリプトが入っています。Docker はコンテナ イメージを構築するために、このスクリプトを使います。 -.. Create a file named Dockerfile in the same folder as the file package.json with the following contents. +.. In the app directory, the same location as the package.json file, create a file named Dockerfile. You can use the following commands below to create a Dockerfile based on your operating system. -1. ``package.json`` と同じフォルダ内に ``Dockerfile`` という名前のファイルを作成し、内容は以下のようにします - - .. code-block:: bash +1. 同じ場所に ``package.json`` ファイル等がある ``app`` ディレクトリ内で、 ``Dockerfile`` という名前のファイルを作成します。使っているオペレーティングシステムに応じた Dockerfile を作成するには、以下のコマンドが使えます。 + + **Mac / Linux** + + .. In the terminal, run the following commands listed below. + .. Change directory to the app directory. Replace /path/to/app with the path to your getting-started/app directory. + + ターミナル上で、以下に記載してあるコマンドを実行します。 + ディレクトリを ``app`` ディレクトリに変更します。 ``/path/to/app`` を ``getting-started/app`` ディレクトリのパスに置き換えます。 + + .. code-block:: bash + + $ cd /path/to/app + + ``Dockerfile`` という名前の空ファイルを作成します。 + + .. code-block:: bash + + $ touch Dockerfile + + **Windows** + + .. In the Windows Command Prompt, run the following commands listed below. + + Windows コマンドプロンプト上で、以下に記載してあるコマンドを実行します。 + ディレクトリを ``app`` ディレクトリに変更します。 ``\path\to\app`` を ``getting-started\app`` ディレクトリのパスに置き換えます。 + + .. code-block:: bash + + $ cd \path\to\app + + ``Dockerfile`` という名前の空ファイルを作成します。 + + .. code-block:: bash + + $ type nul > Dockerfile + + +.. Using a text editor or code editor, add the following contents to the Dockerfile: + +2. テキストエディタかコードエディタを使い、Dockerfile に以下の内容を追加します。 + + .. code-block:: Dockerfile # syntax=docker/dockerfile:1 FROM node:18-alpine @@ -77,33 +134,43 @@ CMD ["node", "src/index.js"] EXPOSE 3000 -.. Please check that the file Dockerfile has no file extension like .txt. Some editors may append this file extension automatically and this would result in an error in the next step. - -``Dockerfile`` には ``.txt`` のようなファイル拡張子が無いのをご確認ください。エディタによってはファイル拡張子を自動的に付けるため、次の手順でエラーになる場合があります。 - -.. If you haven’t already done so, open a terminal and go to the app directory with the Dockerfile. Now build the container image using the docker build command. - -2. まだ終わっていなければ、ターミナルを開き、 ``app`` ディレクトリで ``Dockerfile`` を開きます。それから ``docker build`` コマンドを使ってコンテナ イメージを :ruby:`構築 ` します。 - -.. code-block:: bash - $ docker build -t getting-started . +.. Build the container image using the following commands: -.. This command used the Dockerfile to build a new container image. You might have noticed that a lot of “layers” were downloaded. This is because we instructed the builder that we wanted to start from the node:12-alpine image. But, since we didn’t have that on our machine, that image needed to be downloaded. +3. 以下のコマンドを使い、コンテナイメージを構築します。 -このコマンドは、先ほどの Dockerfile を使い、新しいコンテナ イメージを :ruby:`構築 ` します。実行すると、多くの「 :ruby:`レイヤー ` 」がダウンロードされるのが分かるでしょう。これは ``node:18-alpine`` イメージから起動したいと :ruby:`構築用プログラム ` に対して命令したからです。ですが、マシン上にはイメージがないため、ダウンロードする必要があります。 + .. In the terminal, change directory to the getting-started/app directory. Replace /path/to/app with the path to your getting-started/app directory. -.. After the image was downloaded, we copied in our application and used yarn to install our application’s dependencies. The CMD directive specifies the default command to run when starting a container from this image. - -イメージをダウンロードしたら、アプリケーションをコピーし、 ``yarn`` を使ってアプリケーションの :ruby:`依存関係 ` をインストールします。 ``CMD`` 命令は、このイメージでコンテナを起動する時に、デフォルトで実行するコマンドを指定します。 + ターミナル上で、ディレクトリを ``getting-started/app`` ディレクトリに変更します。 ``/path/to/app`` のパスは、自分の ``getting-started/app`` ディレクトリに置き換えます。 + + .. code-block:: bash + + $ cd /path/to/app + + + .. Build the container image. + + コンテナイメージを構築します。 + + .. code-block:: bash + + $ docker build -t getting-started . + + .. The docker build command uses the Dockerfile to build a new container image. You might have noticed that Docker downloaded a lot of “layers”. This is because you instructed the builder that you wanted to start from the node:18-alpine image. But, since you didn’t have that on your machine, Docker needed to download the image. + + ``docker build`` コマンドは Dockerfile を使い新しいコンテナイメージを構築します。Docker が多くの「 :ruby:`レイヤー ` 」をダウンロードするのが分かるでしょう。こうなるのは、 :ruby:`構築用プログラム ` に対して ``node:18-alpine`` イメージから始めると命令したからです。ですが、まだマシン上にイメージがないため、 Docker はイメージをダウンロードする必要があります。 -.. Finally, the -t flag tags our image. Think of this simply as a human-readable name for the final image. Since we named the image getting-started, we can refer to that image when we run a container. + .. After Docker downloaded the image, the instructions from the Dockerfile copied in your application and used yarn to install your application’s dependencies. The CMD directive specifies the default command to run when starting a container from this image. + + Docker がイメージをダウンロードした後は、 Dockerfile の命令によってアプリケーションをコピーし、それから、 ``yarn`` を使ってアプリケーションの依存関係をインストールします。 ``CMD`` 命令は、このイメージからコンテナを起動したとき、デフォルトで実行するコマンドを指定します。 -最後に ``-t`` フラグでイメージに :ruby:`タグ ` を付けます。タグとは、最後のイメージに対し、人間が読める名前を単に付けるためと考えてください。このイメージには `getting-started`` と名前を単に付けましたので、コンテナの実行時に、このイメージ名を示せます。 + .. Finally, the -t flag tags your image. Think of this simply as a human-readable name for the final image. Since you named the image getting-started, you can refer to that image when you run a container. + + 最後に ``-t`` フラグでイメージに :ruby:`タグ ` を付けます。タグとは、最終イメージに対して、人間が読める名前を単に付けるためと考えてください。このイメージには ``getting-started`` と名前を付けましたので、このイメージ名を示してコンテナを実行できます。 -.. The . at the end of the docker build command tells Docker that it should look for the Dockerfile in the current directory. + .. The . at the end of the docker build command tells Docker that it should look for the Dockerfile in the current directory. -``docker build`` コマンドの最後にある ``.`` は、Docker に対して、現在のディレクトリ内にある ``Dockerfile`` を探すべきと命令します。 + ``docker build`` コマンドの最後にある ``.`` は、Docker に対して、現在のディレクトリ内にある ``Dockerfile`` を探すべきと命令します。 .. Start an app container .. _start-an-app-container: @@ -111,64 +178,95 @@ アプリ コンテナの起動 ============================== -.. Now that we have an image, let’s run the application. To do so, we will use the docker run command (remember that from earlier?). +.. Now that you have an image, you can run the application in a container. To do so, you will use the docker run command. -これでイメージが手に入りましたので、アプリケーションを実行しましょう。そのためには、 ``docker run`` コマンドを使います（Part 1 を覚えていますか？）。 +イメージが手に入りましたので、コンテナ内でアプリケーションを実行できます。そのためには、 ``docker run`` コマンドを使います。 -.. Start your container using the docker run command and specify the name of the image we just created: +.. Start your container using the docker run command and specify the name of the image you just created: 1. コンテナを起動するには、 ``docker run`` コマンドを使い、先ほど作成したイメージ名を指定します。 .. code-block:: bash - $ docker run -dp 3000:3000 getting-started + $ docker run -dp 127.0.0.1:3000:3000 getting-started -.. Remember the -d and -p flags? We’re running the new container in “detached” mode (in the background) and creating a mapping between the host’s port 3000 to the container’s port 3000. Without the port mapping, we wouldn’t be able to access the application. - -この ``-d`` と ``-p`` フラグを覚えていますか？ ここでは「 :ruby:`デタッチド ` モード」（バックグランドで）新しいコンテナを実行し、ホスト側のポート 3000 をコンテナのポート 3000 間で関連付け（ :ruby:`マッピング ` ）をします。ポートの関連付け（ :ruby:`ポート マッピング ` ）をしなければ、アプリケーションに接続できません。 + .. The -d flag (short for --detach) runs the container in the background. The -p flag (short for --publish) creates a port mapping between the host and the container. The -p flag take a string value in the format of HOST:CONTAINER, where HOST is the address on the host, and CONTAINER is the port on the container. The command shown here publishes the container’s port 3000 to 127.0.0.1:3000 (localhost:3000) on the host. Without the port mapping, you wouldn’t be able to access the application from the host. + + ``--d`` フラグ（ ``--detach`` の省略）は、コンテナをバックグラウンドで実行します。 ``-p`` フラグ（ ``--publish`` の省略）は、ホストとコンテナ間でポートの関連付け（ :ruby:`ポート マッピング ` ）を作成します。 ``-p`` フラグは ``HOST:CONTAINER`` という書式の文字列値です。 ``HOST`` はホスト上のアドレスにあたり、 ``CONTAINER`` はコンテナ上で対象となるポートです。このコマンドが示すのは、コンテナのポート 3000 をホスト上の ``127.0.0.1:3000`` （ ``localhost:3000`` ）へ公開します。ポート割り当ての指定がなければ、ホスト上からアプリケーションに接続できません。 -.. After a few seconds, open your web browser to http://localhost:3000. You should see our app. +.. After a few seconds, open your web browser to http://localhost:3000. You should see your app. -2. 数秒後、自分のウェブ ブラウザで http://localhost:3000 を開きます。そうすると、私たちのアプリが見えるでしょう。 +2. 数秒後、自分のウェブ ブラウザで http://localhost:3000 を開きます。そうしたら、私たちのアプリが見えるでしょう。 .. image:: ./images/todo-list-empty.png - :scale: 60% + :width: 60% :alt: まだ何も入っていない ToDo List -.. Go ahead and add an item or two and see that it works as you expect. You can mark items as complete and remove items. Your frontend is successfully storing items in the backend. Pretty quick and easy, huh? +.. Go ahead and add an item or two and see that it works as you expect. You can mark items as complete and remove them. Your frontend is successfully storing items in the backend. + +3. あとはアイテムを1つ2つと追加したら、期待通りに動作するでしょう。完了したアイテムに印を付けると、アイテムを削除できます。このように、フロントエンドはバックエンドへのアイテム保存に成功しています。 + +.. At this point, you should have a running todo list manager with a few items, all built by you. -3. あとは１つ２つとアイテムを追加すると、期待通りに動作するでしょう。完了したアイテムに印を付けると、アイテムを削除できます。このように、フロントエンドはバックエンドへのアイテム保存に成功しています。とても素早く簡単ですよね？ +この時点で、全て自分で構築した todo リストマネージャは実行中で、複数のアイテムが入っています。 -.. At this point, you should have a running todo list manager with a few items, all built by you. Now, let’s make a few changes and learn about managing our containers. +.. If you take a quick look at your containers, you should see at least one container running that is using the getting-started image and on port 3000. To see your containers, you can use the CLI or Docker Desktop’s graphical interface. -この時点で、実行中の todo リスト マネージャには複数のアイテムが入っていて、これらは全て自分が構築したものです。それでは、変更を加えつつ、コンテナ管理の仕方を学びましょう。 +ここでコンテナをちょっと調べると、 ``getting-started`` イメージを使い、ポート ``3000`` を使っている実行中のコンテナが、少なくとも1つ見えるでしょう。コンテナを調べるには、 CLI か Docker Desktop のグラフィカルインターフェースが使えます。 +**CLI** -.. If you take a quick look at the Docker Dashboard, you should see your two containers running now (this tutorial and your freshly launched app container). + .. Run the following docker ps command in a terminal to list your containers. + コンテナ一覧を表示するには、ターミナル上で以下の ``docker ps`` コマンドを実行します。 + + .. code-block:: bash + + $ docker ps + + + .. Output similar to the following should appear. + 次のような出力が表示されます。 + + .. code-block:: bash + + CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES + df784548666d getting-started "docker-entrypoint.s…" 2 minutes ago Up 2 minutes 127.0.0.1:3000->3000/tcp priceless_mcclintock + + +**Docker Desktop** + + .. In Docker Desktop, select the Containers tab to see a list of your containers. + Docker Desktop では、コンテナ一覧を表示するには **Containers** タブを選びます。 -ここで Docker ダッシュボードを軽く見てみると、２つのコンテナが実行中だと分かるでしょう（このチュートリアルと、作成したばかりのアプリ用コンテナです）。 .. image:: ./images/dashboard-two-containers.png - :scale: 60% :alt: Docker ダッシュボードにはチュートリアルとアプリ用コンテナが実行中 -.. Recap -.. _part2-recap: +.. Next steps +.. _part2-next-steps: + +次のステップ +==================== + +.. In this short section, you learned the basics about creating a Dockerfile to build a container image. Once you built an image, you started a container and saw the running app. + +この短いセクションでは、コンテナ イメージを構築するための、 Dockerfile を作成する基本を学びました。イメージを構築した後、コンテナを実行し、アプリケーションが動作しているのが見えます。 -まとめ -========== +.. Next, you’re going to make a modification to your app and learn how to update your running application with a new image. Along the way, you’ll learn a few other useful commands. -.. In this short section, we learned the very basics about building a container image and created a Dockerfile to do so. Once we built an image, we started the container and saw the running app. +次はアプリに変更を加え、実行中のアプリケーションを新しいイメージに更新する方法を学びます。その途中で、幾つかの便利なコマンドも学びます。 -この短いセクションでは、基本中の基本として、コンテナ イメージの構築と、 Dockerfile の作成とイメージの構築を学びました。イメージを構築するだけでコンテナを実行でき、実行中のアプリを表示しています。 +.. raw:: html -.. Next, we’re going to make a modification to our app and learn how to update our running application with a new image. Along the way, we’ll learn a few other useful commands. + -次はアプリに変更を加え、実行中のアプリケーションを新しいイメージに更新する方法を学びます。その途中で、いくつかの便利なコマンドも学びます。 .. seealso:: - Sample application - https://docs.docker.com/get-started/02_our_app/ + Containerize an application + https://docs.docker.com/get-started/02_our_app + diff --git a/get-started/03_updating_app.rst b/get-started/03_updating_app.rst index 75d4e01fb..421470ac5 100644 --- a/get-started/03_updating_app.rst +++ b/get-started/03_updating_app.rst @@ -1,9 +1,9 @@ .. -*- coding: utf-8 -*- .. URL: https://docs.docker.com/get-started/03_updating_app/ - doc version: 20.10 + doc version: 24.0 https://github.com/docker/docker.github.io/blob/master/get-started/03_updating_app.md -.. check date: 2022/09/20 -.. Commits on Jan 11, 2022 5eb68faf22a12ff8144d5ee5c062024c4f543b1a +.. check date: 2023/07/17 +.. Commits on Jun 7, 2023 aee91fdaba9516d06db5b6b580e98f70a9a11c55 .. ----------------------------------------------------------------------------- .. Update the application @@ -19,74 +19,70 @@ :depth: 2 :local: +.. In part 2, you containerized a todo application. In this part, you will update the application and container image. You will also learn how to stop and remove a container. -.. As a small feature request, we’ve been asked by the product team to change the “empty text” when we don’t have any todo list items. They would like to change it to the following: - -プロダクション チームから、小さな機能リクエストがありました。todo リストにアイテムが何も無い場合に表示する、「アイテムが入っていない文字」の変更です。次のように変更して欲しいという依頼です。 - -.. You have no todo items yet! Add one above! - -:: - - You have no todo items yet! Add one above! - -.. Pretty simple, right? Let’s make the change. - -とてもシンプルですよね？ それでは変更しましょう。 +:doc:`Part 2 <02_our_app>` では Todo アプリケーションをコンテナ化しました。このパートでは、アプリケーションとコンテナイメージを更新します。また、コンテナの停止と削除する方法も学びます。 .. Update the source code .. _update-the-source-code: -ソースコードの変更 +ソースコードの更新 ==================== +.. In the steps below, you will change the “empty text” when you don’t have any todo list items to “You have no todo items yet! Add one above!” + +以下のステップでは、Todo リストにアイテムが一切なければ「何も表示しない」のではなく、「You have no todo items yet! Add one above!」（todo アイテムがありません！追加してください！）と表示します。 + + .. In the src/static/js/app.js file, update line 56 to use the new empty text. -1. ``src/static/js/app.js`` ファイル内の 56 行目で、何もない時に表示する新しいメッセージを変更します。 +1. ``src/static/js/app.js`` ファイル内で、何もない時に表示する文字を変更するため、56 行目を更新します。 .. code-block:: diff -

No items yet! Add one above!

+

You have no todo items yet! Add one above!

-.. Let’s build our updated version of the image, using the same command we used before. +.. Build your updated version of the image, using the same docker build command you used in part 2. -2. イメージの更新したバージョンを作成するため、先ほどと同じコマンドを使います。 +2. イメージの更新版を構築するため、 :doc:`Part 2 <02_our_app>` で使用した ``docker build`` コマンドを使います。 .. code-block:: bash $ docker build -t getting-started . -.. Let’s start a new container using the updated code. +.. Start a new container using the updated code. -3. 更新したコードを使う新しいコンテナを起動しましょう。 +3. 更新したコードを使う新しいコンテナを起動します。 .. code-block:: bash - $ docker run -dp 3000:3000 getting-started + $ docker run -dp 127.0.0.1:3000:3000 getting-started -.. Uh oh! You probably saw an error like this (the IDs will be different): +.. You probably saw an error like this (the IDs will be different): -**あれれ？** たぶん次のようなエラーが出ているでしょう（ID は違います）。 +おそらく次のようなエラーが出ているでしょう（ID は違います）： .. code-block:: bash docker: Error response from daemon: driver failed programming external connectivity on endpoint laughing_burnell (bb242b2ca4d67eba76e79474fb36bb5125708ebdabd7f45c8eaf16caaabde9dd): Bind for 0.0.0.0:3000 failed: port is already allocated. -.. So, what happened? We aren’t able to start the new container because our old container is still running. It is because the container is using the host’s port 3000 and only one process on the machine (containers included) can listen to a specific port. To fix this, we need to remove the old container. +.. The error occurred because you aren’t able to start the new container while your old container is still running. The reason is that the old container is already using the host’s port 3000 and only one process on the machine (containers included) can listen to a specific port. To fix this, you need to remove the old container. -何が起こったのでしょうか？ 新しいコンテナを起動できないのは、まだ古いコンテナを実行中だからです。コンテナはホスト側のポート 3000 を使用中で、マシン上の１つのプロセス（コンテナも含みます）しか、特定のポートをリッスンできないからです。これの対応には、古いコンテナの削除が必要です。 +このエラーが表示されたのは、古いコンテナがまだ実行中のため、新しいコンテナを起動できないからです。その理由は、古いコンテナが既にホスト側のポート 3000 を使用中であり、マシン上では1つのプロセス（コンテナも含みます）しか特定のポートをリッスンできないからです。これに対応するには、古いコンテナの削除が必要です。 -.. Replace the old container -.. _replace-the-old-container: +.. Remove a container using the CLI +.. _remove-a-container-using-the-cli: -古いコンテナを置き換える +古いコンテナの削除 ============================== -.. To remove a container, it first needs to be stopped. Once it has stopped, it can be removed. We have two ways that we can remove the old container. Feel free to choose the path that you’re most comfortable with. +.. To remove a container, you first need to stop it. Once it has stopped, you can remove it. You can remove the old container using the CLI or Docker Desktop’s graphical interface. Choose the option that you’re most comfortable with. + +コンテナを削除するには、まずコンテナの停止が必要です。停止した後に削除できます。古いコンテナの削除には CLI を削除する方法と Docker Desktop のグラフィカルインタフェースを使う方法があります。どちらでも、やりやすい方法を自由に選んでください。 -コンテナを削除するには、まずコンテナの停止が必要です。停止した後に削除できます。古いコンテナの削除には２つの方法があります。どちらでも、やりやすい方法を自由に選んでください。 +**CLI** .. Remove a container using the CLI .. _remove-a-container-using-the-cli: @@ -98,17 +94,16 @@ CLI でコンテナを削除 1. ``docker ps`` コマンドを使い、コンテナの ID を調べます。 -.. code-block:: bash - - $ docker ps + .. code-block:: bash + + $ docker ps -.. Use the docker stop command to stop the container. +.. Use the docker stop command to stop the container. Replace with the ID from docker ps. -2. ``docker stop`` コマンドでコンテナを停止します。 +2. ``docker stop`` コマンドでコンテナを停止します。 は ``docker ps`` で調べた ID に置き換えます。 .. code-block:: bash - # は docker ps の ID に置き換え $ docker stop .. Once the container has stopped, you can remove it by using the docker rm command. @@ -124,7 +119,12 @@ CLI でコンテナを削除 .. note:: - ``docker rm`` コマンドに「 :ruby:`強制 ` 」フラグを付ければ、１回のコマンドでコンテナの削除と停止ができます。例： ``docker rm -f `` + ``docker rm`` コマンドに「 :ruby:`強制 ` 」フラグを付ければ、１回のコマンドでコンテナの停止と削除ができます。例： ``docker rm -f `` + + +**Docker Desktop** + + .. Remove a container using the Docker Dashboard .. _remove-a-container-using-the-docker-dashboard: @@ -132,69 +132,67 @@ CLI でコンテナを削除 Docker ダッシュボードでコンテナを削除 ---------------------------------------- -.. If you open the Docker dashboard, you can remove a container with two clicks! It’s certainly much easier than having to look up the container ID and remove it. +.. Open Docker Desktop to the Containers view. -Docker ダッシュボードを開けば、２クリックでコンテナを削除できます！ コンテナ ID を調べて削除するよりも、遙かに簡単です。 +1. Docker Desktop を開き、 **Containers** を表示します。 -.. With the dashboard opened, hover over the app container and you’ll see a collection of action buttons appear on the right. +.. Select the trash can icon under the Actions column for the old, currently running container that you want to delete. -1. ダッシュボードを開き、アプリ用コンテナの上を（マウスのポインタで）示すと、右側に :ruby:`機能ボタン ` の集まりが見えます。 +2. 削除しようとしている、古くて実行しているコンテナの **Actions** 列の下にあるゴミ箱のアイコンをクリックします。 -.. Click on the trash can icon to delete the container. +.. In the confirmation dialog, select Delete forever. -2. ごみ箱のアイコンをクリックし、コンテナを削除します。 - -.. Confirm the removal and you’re done! - -3. 削除を確認すると、これで終わりです。 - -.. image:: ./images/dashboard-removing-container.png - :scale: 60% - :alt: Docker ダッシュボード - コンテナの削除 +3. 確認ダイアログでは **Delete forever** （完全に削除）を選びます。 .. Start the updated app container .. _start-the-updated-app-container: -更新したアプリ用コンテナを起動 +更新したアプリのコンテナを起動 ------------------------------ -.. Now, start your updated app. +.. Now, start your updated app using the docker run command. -1. 今度は、更新したアプリを起動します。 +1. 次は、 ``docker run`` コマンドを使い、更新したアプリを起動します。 .. code-block:: bash - $ docker run -dp 3000:3000 getting-started + $ docker run -dp 127.0.0.1:3000:3000 getting-started -.. Refresh your browser on http://localhost:3000 and you should see your updated help text! +.. Refresh your browser on http://localhost:3000 and you should see your updated help text. -2. ブラウザで http://localhost:3000 を再読み込みすると、説明の文字が更新されているでしょう！ +2. ブラウザで http://localhost:3000 を再読み込むと、説明の文字が更新されているでしょう。 .. Updated application with updated empty text .. image:: ./images/todo-list-updated-empty-text.png - :scale: 60% + :width: 60% :alt: Todo List Manager のスクリーンショット -.. Recap -.. _part3-recap: +.. Next steps +.. _part3-next-steps: -まとめ -========== +次のステップ +==================== .. While we were able to build an update, there were two things you might have noticed: -構築と更新をしましたが、注意点が２つあります。 +構築と更新を行いましたが、2つの注意点があります。 .. All of the existing items in our todo list are gone! That’s not a very good app! We’ll talk about that shortly. There were a lot of steps involved for such a small change. In an upcoming section, we’ll talk about how to see code updates without needing to rebuild and start a new container every time we make a change. -* todo リストに追加していたアイテムは、全て消えました！ あまり良くないアプリですね！ 近いうちに説明します。 +* todo リストに追加していたアイテムは、全て消えてしまいます！ 良いアプリではありませんね！ 近いうちに説明します。 * 小さな変更のように、実際には多くの改良ステップがあります。以降のセクションでは、再構築を必要としないコードの編集方法や、変更する度に新しくコンテナを起動する方法を説明します。 .. Before talking about persistence, we’ll quickly see how to share these images with others. -:ruby:`一貫性 ` を説明する前に、他人とイメージを共有する方法を見ていきます。 +:ruby:`永続性 ` （データの保持）を説明する前に、他人とイメージを共有する方法を見ます。 + +.. raw:: html + + .. seealso:: diff --git a/get-started/04_sharing_app.rst b/get-started/04_sharing_app.rst index 62db48fbb..55f2bbc96 100644 --- a/get-started/04_sharing_app.rst +++ b/get-started/04_sharing_app.rst @@ -1,9 +1,9 @@ .. -*- coding: utf-8 -*- .. URL: https://docs.docker.com/get-started/04_sharing_app/ - doc version: 20.10 + doc version: 24.0 https://github.com/docker/docker.github.io/blob/master/get-started/04_sharing_app.md -.. check date: 2022/09/20 -.. Commits on Sep 14, 2022 5e3c72815400353eac77781934e198074ddfc284 +.. check date: 2023/07/17 +.. Commits on Jun 15, 2023 6aa908c3b807b281072432ae095c2d45be3e3ce5 .. ----------------------------------------------------------------------------- .. Share the application @@ -19,9 +19,9 @@ :depth: 2 :local: -.. Now that we’ve built an image, let’s share it! To share Docker images, you have to use a Docker registry. The default registry is Docker Hub and is where all of the images we’ve used have come from. +.. Now that you’ve built an image, you can share it. To share Docker images, you have to use a Docker registry. The default registry is Docker Hub and is where all of the images you’ve used have come from. -イメージを構築したので、共有しましょう！ Docker イメージを共有するには、 Docker :ruby:`レジストリ ` を使う必要があります。デフォルトのレジストリは Docker Hub で、そこにこれまでに使った全てのイメージがあります。 +構築したイメージは共有できます。 Docker イメージを共有するには、 Docker :ruby:`レジストリ ` を使う必要があります。デフォルトのレジストリは Docker Hub です。そこには、これまでに使った全てのイメージがあります。 .. Docker ID A Docker ID allows you to access Docker Hub which is the world’s largest library and community for container images. Create a Docker ID for free if you don’t have one. @@ -42,7 +42,7 @@ .. Sign up or Sign in to Docker Hub. -1. `Docker Hub `_ に `サインアップ `_ またはサインインします。 +1. `Docker Hub `_ に `サインアップ `_ 又はサインインします。 .. Click the Create Repository button. @@ -52,22 +52,24 @@ 3. リポジトリ名には ``getting-started`` を使います。Visibility は ``Public`` （公開）を確認します。 -.. Private repositories + .. Private repositories Did you know that Docker offers private repositories which allows you to restrict content to specific users or teams? Check out the details on the Docker pricing page. .. note:: - 特定のユーザやチームに対して内容を制限するために、Docker は :ruby:`プライベート リポジトリ ` を提供していますが、ご存じですか？ 詳細は `Docker pricing `_ のページをご覧ください。 + **プライベート リポジトリ** + + 特定のユーザやチームに対してのみ内容を制限するために、Docker は :ruby:`プライベート リポジトリ ` を提供しています。御存じですか？ 詳細は `Docker pricing `_ のページを御覧ください。 .. Click the Create button! 4. **Create** （作成）ボタンをクリックします。 - .. If you look at the image below an example Docker command can be seen. This command will push to this repo. +下の図を見たら、 Docker コマンド例があります。このコマンドは、このリポジトリを送信します。 + .. image:: ./images/push-command.png - :scale: 60% :alt: Docker コマンドの push 例 .. Push the image @@ -78,11 +80,11 @@ .. hint:: - （訳者注）この日本語訳では、イメージの「push」を「送信」として訳しています（コマンドを示す以外）。本来の push は「何かを押し出す」「何かを遠ざける」という意味です。ですが、そのまま訳したり"プッシュ"とカタカナ表記しても、抽象的な表現は日本語での理解が困難なため、 Docker の機能を表す「送信」と訳しています。 + （訳者注）この日本語訳では、イメージの「push」を「送信」として訳しています（コマンドを示す以外）。本来の push は「何かを押し出す」「何かを遠ざける」という意味です。ですが、そのまま訳したり"プッシュ"とカタカナ表記したりしても、抽象的な表現は日本語での理解が困難なため、 Docker の機能を表す「送信」と訳しています。 .. In the command line, try running the push command you see on Docker Hub. Note that your command will be using your namespace, not “docker”. -1. コマンドラインから、先ほど Docker Hub で見た push （送信）コマンドを実行します。注意点として、入力するコマンドでは「docker」ではなく、自分の名前空間（Docker ユーザ ID）を指定する必要があります。 +1. コマンドラインから、先ほど Docker Hub で見た push （送信）コマンドを実行します。注意点として、入力するコマンドでは自分の名前空間（Docker ユーザ ID）を指定する必要があります。「docker」ではありません。 .. code-block:: bash @@ -90,11 +92,12 @@ The push refers to repository [docker.io/docker/getting-started] An image does not exist locally with the tag: docker/getting-started + .. Why did it fail? The push command was looking for an image named docker/getting-started, but didn’t find one. If you run docker image ls, you won’t see one either. 失敗しましたか？ push コマンドは docker/getting-started という名前のイメージを探しますが、見つからないからです。 ``docker image ls`` を実行しても、該当するイメージは見つからないでしょう。 - .. To fix this, we need to “tag” our existing image we’ve built to give it another name. + .. To fix this, you need to “tag” your existing image you’ve built to give it another name. 修正するには、現在の構築済みイメージに付いている「 :ruby:`タグ ` 」に、別の名前を付ける必要があります。 @@ -106,27 +109,50 @@ 3. ``docker tag`` コマンドを使い、 ``getting-started`` イメージに新しい名前を追加します。注意点として、 ``YOUR-USER-NAME`` は自分の Docker ID に置き換えます。 -.. code-block:: bash + .. code-block:: bash + + $ docker tag getting-started YOUR-USER-NAME/getting-started - $ docker tag getting-started YOUR-USER-NAME/getting-started + .. To learn more about the docker tag command, see docker tag. + + ``docker tag`` コマンドについて学ぶには :doc:`docker tag ` を御覧ください。 -.. Now try your push command again. If you’re copying the value from Docker Hub, you can drop the tagname portion, as we didn’t add a tag to the image name. If you don’t specify a tag, Docker will use a tag called latest. +.. Now try your push command again. If you’re copying the value from Docker Hub, you can drop the tagname portion, as you didn’t add a tag to the image name. If you don’t specify a tag, Docker will use a tag called latest. 4. これでもう一度 push コマンドを試します。Docker Hub から値をコピーしている場合でも、先ほどイメージにタグを付けていたように、 ``tagname`` の文字を省略できます。タグを指定しなければ、 Docker は ``latest`` （最新）と呼ばれるタグを使います。 -.. code-block:: bash - - $ docker push YOUR-USER-NAME/getting-started + .. code-block:: bash + + $ docker push YOUR-USER-NAME/getting-started .. Run the image on a new instance .. _run-the-image-on-a-new-instance: -新しいインスタンスでイメージを実行 +新しいイメージを実行 ======================================== -.. Now that our image has been built and pushed into a registry, let’s try running our app on a brand new instance that has never seen this container image! To do this, we will use Play with Docker. +.. Now that your image has been built and pushed into a registry, try running your app on a brand new instance that has never seen this container image. To do this, you will use Play with Docker. + +現在、イメージは構築が終わり、レジストリに送信しました。まだコンテナイメージを扱っていない、真っさらなインスタンス（訳者注：Play widh Docker 環境上の仮想マシン）を使ってアプリを実行しましょう！ ここでは、 Play with Docker を使います。 + +.. note:: + + .. Play with Docker uses the amd64 platform. If you are using an ARM based Mac with Apple Silicon, you will need to rebuild the image to be compatible with Play with Docker and push the new image to your repository. + + Play with Docker は amd64 プラットフォームを用いています。もしも Apple Silicon を使う ARM ベースの Mac を使う場合、 Play with Docker と互換性を持つイメージを再構築し、新しいイメージをリポジトリに送信する必要があります。 + + .. To build an image for the amd64 platform, use the --platform flag. + + amd64 プラットフォーム用のイメージを再構築するには、 ``--platform`` フラグを使います。 + + .. code-block:: bash + + $ docker build --platform linux/amd64 -t YOUR-USER-NAME/getting-started . + + .. Docker buildx also supports building multi-platform images. To learn more, see Multi-platform images. + + Docker buildx もマルチプラットフォームのイメージ構築をサポートしています。詳しく知るには :doc:`マルチプラットフォーム イメージ` を御覧ください。 -現在、イメージは構築が終わり、レジストリに送信しました。このコンテナ イメージを使っていない、真っ新なインスタンス上でアプリを実行しましょう！ それには、 Play with Docker を使います。 .. Open your browser to Play with Docker. @@ -142,41 +168,59 @@ .. Once you’re logged in, click on the ADD NEW INSTANCE option on the left side bar. If you don’t see it, make your browser a little wider. After a few seconds, a terminal window opens in your browser. -4. ログインしたら、左サイドバー上にある **ADD NEW INSTANCE** （新しいインスタンスの追加）をクリックします。もしも表示さなければ、ブラウザの表示幅を少し広くしてください。数秒すると、ブラウザ内にターミナル画面が開きます。 +4. ログインしたら、左サイドバー上にある **ADD NEW INSTANCE** （新しいインスタンスの追加）をクリックします。もしも表示さなければ、ブラウザの表示幅を少し広くしてください。数秒しますと、ブラウザ内にターミナル画面が開きます。 -.. image:: ./images/pwd-add-new-instance.png - :scale: 60% - :alt: Play with Docker と新しいインスタンス + .. image:: ./images/pwd-add-new-instance.png + :alt: Play with Docker と新しいインスタンス .. In the terminal, start your freshly pushed app. 5. ターミナル内で、先ほど送信したアプリを起動します。 -.. code-block:: bash + .. code-block:: bash + + $ docker run -dp 0.0.0.0:3000:3000 YOUR-USER-NAME/getting-started + + .. You should see the image get pulled down and eventually start up. - $ docker run -dp 3000:3000 YOUR-USER-NAME/getting-started + 画面ではイメージを取得して、最終的には起動するのが見えるでしょう！ - .. You should see the image get pulled down and eventually start up! +.. You may have noticed that this command binds the port mapping to a different IP address. Previous docker run commands published ports to 127.0.0.1:3000 on the host. This time, you’re using 0.0.0.0. + Binding to 127.0.0.1 only exposes a container’s ports to the loopback interface. Binding to 0.0.0.0, however, exposes the container’s port on all interfaces of the host, making it available to the outside world. + For more information about how port mapping works, see Networking. - イメージを取得し、最終的には起動するのが見えるでしょう！ +.. tip:: + + このコマンドでは、ポートを割り当てて（ポートマッピング）バインドする IP アドレスが異なるのに気づくでしょう。これまでの ``docker run`` コマンドではホスト上の ``127.0.0.1:3000`` に対してポートを公開していました。ここでは ``0.0.0.0`` を使っています。 + ``127.0.0.1`` へのバインドとは、ループバック インターフェースに対してのみコンテナのポートを公開します。一方で ``0.0.0.0`` のバインドとは、ホスト上すべてのインターフェース上でコンテナのポートを公開しますので、これにより外の世界で利用可能になります。 + ポート割り当て動作の仕組みに関する詳しい情報は :ref:`ネットワーク機能 ` を御覧ください。 + + +.. Select on the 3000 badge when it comes up and you should see the app with your modifications. If the 3000 badge doesn’t show up, you can select on the Open Port button and type in 3000. + +6. 起動したら 3000 バッジをクリックしたら、変更を加えたアプリが表示されるでしょう。 もし 3000 バッジが表示されなければ、「 **Open Port** 」（ポートを開く）ボタンをクリックし、 3000 と入力します。 + +.. Next steps +.. _part_4-next-steps: + +次のステップ +==================== -.. Click on the 3000 badge when it comes up and you should see the app with your modifications! Hooray! If the 3000 badge doesn’t show up, you can click on the “Open Port” button and type in 3000. +.. In this section, you learned how to share your images by pushing them to a registry. You then went to a brand new instance and were able to run the freshly pushed image. This is quite common in CI pipelines, where the pipeline will create the image and push it to a registry and then the production environment can use the latest version of the image. -6. 起動したら 3000 バッジをクリックすると、変更を加えたアプリが表示されるでしょう！ もし 3000 バッジが表示されなければ、「Open Port」（ポートを開く）ボタンをクリックし、 3000 と入力します。 +このセクションでは、イメージを共有するために、レジストリにイメージを送信する方法を学びました。それから真っさらなインスタンスに移動し、送信したばかりのイメージを実行できました。これが正に CI パイプラインと共通する部分です。パイプラインとはイメージを作成し、レジストリに送信し、プロダクション環境でイメージの最新版を利用できる場所です。 -.. Recap -.. _part_4-recap: +.. Now you can circle back around to what you noticed at the end of the last section. As a reminder, you noticed that when you restarted the app, you lost all of your todo list items. That’s obviously not a great user experience, so next you’ll learn how you can persist the data across restarts. -まとめ -========== +ここまで理解したところで、先ほどのセクションの最後で述べた部分に立ち戻りましょう。振り返れば、アプリの再起動時、todo リストのアイテムが全て消えました。これは明らかに良くないユーザ体験ですので、次は再起動してもデータが :ruby:`保持 ` できる方法を学びましょう。 -.. In this section, we learned how to share our images by pushing them to a registry. We then went to a brand new instance and were able to run the freshly pushed image. This is quite common in CI pipelines, where the pipeline will create the image and push it to a registry and then the production environment can use the latest version of the image. +.. raw:: html -このセクションでは、イメージを共有するために、レジストリにイメージを送信する方法を学びました。それから真っ新なインスタンスに移動し、送信したばかりのイメージを実行できました。これがまさに CI パイプラインと共通する部分です。パイプラインとはイメージを作成し、レジストリに送信し、プロダクション環境でイメージの最新版を利用できるところです。 + -.. Now that we have that figured out, let’s circle back around to what we noticed at the end of the last section. As a reminder, we noticed that when we restarted the app, we lost all of our todo list items. That’s obviously not a great user experience, so let’s learn how we can persist the data across restarts! -ここまで理解したところで、先ほどのセクションの最後で述べた部分に立ち戻りましょう。思い出してみると、アプリの再起動時、todo リストのアイテムが全て消えました。これは明らかに良くないユーザ体験ですので、再起動してもデータが :ruby:`保持 ` できる方法を学びましょう。 .. seealso:: diff --git a/get-started/05_persisting_data.rst b/get-started/05_persisting_data.rst index f6e356eb1..78d7894b5 100644 --- a/get-started/05_persisting_data.rst +++ b/get-started/05_persisting_data.rst @@ -1,16 +1,16 @@ .. -*- coding: utf-8 -*- .. URL: https://docs.docker.com/get-started/05_persisting_data/ - doc version: 20.10 + doc version: 24.0 https://github.com/docker/docker.github.io/blob/master/get-started/05_persisting_data.md -.. check date: 2022/09/20 -.. Commits on Sep 3, 2021 ac1df4d6a9d3175b4cf42c21cb98eedd60822657 +.. check date: 2023/07/17 +.. Commits on Jun 7, 2023 aee91fdaba9516d06db5b6b580e98f70a9a11c55 .. ----------------------------------------------------------------------------- .. Persist the DB .. _persist-the-db: ======================================== -DB の保持 +データベースの保持 ======================================== .. sidebar:: 目次 @@ -19,9 +19,9 @@ DB の保持 :depth: 2 :local: -.. In case you didn’t notice, our todo list is being wiped clean every single time we launch the container. Why is this? Let’s dive into how the container is working. +.. In case you didn’t notice, your todo list is empty every single time you launch the container. Why is this? In this part, you’ll dive into how the container is working. -気を付けないと、todo リストはコンテナを起動するたび、きれいに消去されます。どうしてでしょうか？ コンテナがどのように動作しているのか、深掘りしましょう。 +気を付けなければ、コンテナを起動するたび、todo リストは毎回きれいに消去されます。どうしてでしょうか？ このパートではコンテナがどのように動作しているのか、深掘りしましょう。 .. The container’s filesystem .. _the-containers-filesystem: @@ -31,7 +31,7 @@ DB の保持 .. When a container runs, it uses the various layers from an image for its filesystem. Each container also gets its own “scratch space” to create/update/remove files. Any changes won’t be seen in another container, even if they are using the same image. -コンテナの実行時、イメージの様々なレイヤーを、コンテナのファイルシステムに使います。また、各コンテナでは、ファイルを作成、更新、削除するための「 :ruby:`スクラッチ領域 ` 」もコンテナ自身が持ちます。たとえ同じイメージを使っていたとしても、（コンテナのファイルシステムに対する）あらゆる変更は、他のコンテナからは見えません。 +コンテナの実行時、イメージの様々なレイヤーを、コンテナの :ruby:`ファイルシステム ` に使います。また、各コンテナでは、ファイルを作成、更新、削除するための「 :ruby:`スクラッチ領域 ` 」もコンテナ自身が持ちます。たとえ同じイメージを使っていたとしても、（あるコンテナのファイルシステムに対する）あらゆる変更は、他のコンテナからは見えません。 .. See this in practice @@ -40,7 +40,7 @@ DB の保持 実行して確認 ------------------------------ -.. To see this in action, we’re going to start two containers and create a file in each. What you’ll see is that the files created in one container aren’t available in another. +.. To see this in action, you’re going to start two containers and create a file in each. What you’ll see is that the files created in one container aren’t available in another. この処理を見るために、２つのコンテナを起動し、それぞれにファイルを作成します。一方のコンテナで作成されたファイルは、もう一方のコンテナからは見えないと分かるでしょう。 @@ -58,44 +58,51 @@ DB の保持 .. Validate that we can see the output by execing into the container. To do so, open the Dashboard and click the first action of the container that is running the ubuntu image. -2. コンテナ内に ``exec`` すると、出力を確認できます。そのためには、ダッシュボードを開き、実行している ``ubuntu`` イメージのコンテナにある、１番目のアクション（ CLI と表示）をクリックします。 +.. Validate that you can see the output by accessing the terminal in the container. To do so, you can use the CLI or Docker Desktop’s graphical interface. +2. コンテナのターミナルにアクセスしたら、出力を確認できます。そのために CLI か Docker Desktop のグラフィカルインタフェースを使います。 - .. image:: ./images/dashboard-open-cli-ubuntu.png - :scale: 60% - :alt: Todo List Manager のスクリーンショット - - .. You will see a terminal that is running a shell in the ubuntu container. Run the following command to see the content of the /data.txt file. Close this terminal afterwards again. - - そうすると、ターミナルが開き、ubuntu コンテナ内で実行中のシェルが見えます。 ``/data.txt`` ファイルの内容を見るには、以下のコマンドを実行します。その後、このターミナルは以後使いませんので、閉じます。 - - .. code-block:: bash + **CLI** - $ cat /data.txt - - .. If you prefer the command line you can use the docker exec command to do the same. You need to get the container’s ID (use docker ps to get it) and get the content with the following command. - - ``docker exec`` コマンドを使う方が好きでしたら、同じようにできます。そのためにはコンテナ ID の確認が必要です。それから、以下のコマンドでファイル内容を表示します。 - - .. code-block:: bash + .. On the command line, use the docker exec command to access the container. You need to get the container’s ID (use docker ps to get it). In your Mac or Linux terminal, or in Windows Command Prompt or PowerShell, get the content with the following command. + + コマンドライン上からコンテナにアクセスするには ``docker exec`` コマンドを使います。コンテナ ID の取得が必要です（取得には ``docker ps`` を使います）。Mac や Linux のターミナルで、あるいは、 Windows コマンドプロンプトや PowerShell で以下のコマンドで実行し、内容を確認します。 + + .. code-block:: bash + + $ docker exec cat /data.txt + + .. You should see a random number. + + ランダムな数字が表示されるでしょう。 - $ docker exec cat /data.txt + **Docker Desktop** + + .. In Docker Desktop, go to Containers, hover over the container running the ubuntu image, and select the Show container actions menu. From the dropdown menu, select Open in terminal. + Docker Desktop では **Containers* に移動し、 **ubuntu** イメージを実行しているコンテナの上にマウスカーソルを移動し、 **Show container actions** メニューを選びます。下に展開したメニューから **Open in terminal** を選びます。 - .. You should see a random number! + .. You will see a terminal that is running a shell in the Ubuntu container. Run the following command to see the content of the /data.txt file. Close this terminal afterwards again. + ターミナルとして開いているのは、 Ubuntu コンテナ内で実行中のシェルです。 ``/data.txt`` ファイル内の内容を確認するには、次のコマンドを実行します。後ほど終わったら、このターミナルを閉じます。 - ランダムな数が見えるでしょう！ + .. code-block:: bash + + $ cat /data.txt + + .. You should see a random number. + + ランダムな数字が表示されるでしょう。 -.. Now, let’s start another ubuntu container (the same image) and we’ll see we don’t have the same file. +.. Now, start another ubuntu container (the same image) and you’ll see you don’t have the same file. In your Mac or Linux terminal, or in Windows Command Prompt or PowerShell, get the content with the following command. -3. 次に、他の ``ubuntu`` コンテナ（同じイメージ）を起動しても、同じファイルは見えないでしょう。 +3. 次に、他の ``ubuntu`` コンテナ（同じイメージ）を起動しても、同じファイルは見えないでしょう。Mac や Linux のターミナルで、あるいは、 Windows コマンドプロンプトや PowerShell で以下のコマンドで実行し、内容を確認します。 .. code-block:: bash $ docker run -it ubuntu ls / - .. And look! There’s no data.txt file there! That’s because it was written to the scratch space for only the first container. - - 見てください！ そこに ``data.txt`` はありません！ その理由とは、書き出したのは、１つめのコンテナのスクラッチ領域だけだからです。 + .. In this case the command lists the files in the root directory of the container. Look, there’s no data.txt file there! That’s because it was written to the scratch space for only the first container. + + このコマンドの場合、コンテナ内のルートディレクトリ以下のファイルを一覧表示します。確認してください、 ``data.txt`` ファイルは一覧にありません。その理由は、ファイルを書き出したのは、１つめのコンテナのスクラッチ領域だけだからです。 .. Go ahead and remove the first container using the docker rm -f command. @@ -109,88 +116,129 @@ DB の保持 .. With the previous experiment, we saw that each container starts from the image definition each time it starts. While containers can create, update, and delete files, those changes are lost when the container is removed and all changes are isolated to that container. With volumes, we can change all of this. -これまで試したように、各コンテナは、イメージの定義からコンテナが起動するのが分かりました。コンテナはファイルの作成、更新、削除ができますが、コンテナを削除すると、それらの変更は消失します。また、コンテナに対する全ての変更とは、 :ruby:`隔離された ` 対象のコンテナに対してのみです。ですが、 :ruby:`ボリューム ` を使えば、これら全てを変えられます。 +これまで試したように、各コンテナは、イメージの定義からコンテナが起動するのが分かりました。コンテナはファイルの作成、更新、削除ができますが、コンテナを削除したら、それらの変更は消失します。また、コンテナに対する全ての変更とは、 :ruby:`隔離された ` 対象のコンテナに対してのみです。ですが、 :ruby:`ボリューム ` を使えば、これら全てを変えられます。 .. Volumes provide the ability to connect specific filesystem paths of the container back to the host machine. If a directory in the container is mounted, changes in that directory are also seen on the host machine. If we mount that same directory across container restarts, we’d see the same files. :doc:`ボリューム ` は、コンテナ内で指定したファイルシステムのパスを、ホストマシン上へと接続できる機能を備えています。コンテナ内にディレクトリをマウントすると、ディレクトリに対する変更は、ホストマシン上からも見えます。コンテナを再起動する場合にも、同じディレクトリをマウントしていれば、再起動後も同じファイルが見えます。 -.. There are two main types of volumes. We will eventually use both, but we will start with named volumes. +.. There are two main types of volumes. You’ll eventually use both, but you’ll start with volume mounts. -ボリュームは主に２種類あります。ゆくゆくは両方を使いますが、まずは **名前付きボリューム （named volume）** から始めましょう。 +ボリュームは主に２種類あります。ゆくゆくは両方を使いますが、まずはボリュームのマウントから始めましょう。 .. Persist the todo data .. _persist-the-todo-data: -todo データの保持 -==================== +todo データを保持する +============================== -.. By default, the todo app stores its data in a SQLite Database at /etc/todos/todo.db in the container’s filesystem. If you’re not familiar with SQLite, no worries! It’s simply a relational database in which all of the data is stored in a single file. While this isn’t the best for large-scale applications, it works for small demos. We’ll talk about switching this to a different database engine later. +.. By default, the todo app stores its data in a SQLite database at /etc/todos/todo.db in the container’s filesystem. If you’re not familiar with SQLite, no worries! It’s simply a relational database that stores all the data in a single file. While this isn’t the best for large-scale applications, it works for small demos. You’ll learn how to switch this to a different database engine later. デフォルトでは、todo アプリが自身のデータを保存するのは、コンテナ用ファイルシステム内で ``/etc/todos/todo.db`` にある `SQLite Databese `_ の中です。SQLite に不慣れでも、心配は要りません！ これはシンプルなリレーショナル データベースで、１つのファイル内に全てのデータを保存します。大きくスケールするアプリケーションには最良ではありませんが、小さなデモには効果的です。これを他のデータベースエンジンに切り替える方法は、後ほどお伝えします。 -.. With the database being a single file, if we can persist that file on the host and make it available to the next container, it should be able to pick up where the last one left off. By creating a volume and attaching (often called “mounting”) it to the directory the data is stored in, we can persist the data. As our container writes to the todo.db file, it will be persisted to the host in the volume. +.. With the database being a single file, if you can persist that file on the host and make it available to the next container, it should be able to pick up where the last one left off. By creating a volume and attaching (often called “mounting”) it to the directory where you stored the data, you can persist the data. As your container writes to the todo.db file, it will persist the data to the host in the volume. + +データベースはたった１つのファイルです。そのため、ホスト上のファイルを次のコンテナで利用できるようにするだけで、データベースを保持できるため、最後に中断したところから継続できるでしょう。ボリュームを作成し、データを保管するディレクトリに :ruby:`取り付ける ` と（よく :ruby:`マウントする ` と言います）、データを :ruby:`保持 ` できます。つまり、私たちのコンテナが書き出す ``todo.db`` ファイルは、ホスト上のボリュームに置いておけば、保持できます。 + +.. As mentioned, you’re going to use a volume mount. Think of a volume mount as an opaque bucket of data. Docker fully manages the volume, including the storage location on disk. You only need to remember the name of the volume. -データベースがたった１つのファイルのため、ホスト上のファイルを次のコンテナで利用できるようにするだけで、データベースを保持できるため、最後に中断したところから続けられるでしょう。ボリュームを作成し、データを保管するディレクトリに :ruby:`取り付ける ` と（よく :ruby:`マウントする ` と言います）、データを :ruby:`保持 ` できます。つまり、私たちのコンテナが書き出す ``todo.db`` ファイルは、ホスト上のボリュームに置いておけば、保持できます。 +先述の通り、ここではボリュームのマウントを使おうとしています。ボリュームのマウントとは、中身が見えないデータの :ruby:`入れ物 ` と考えてください。Docker がディスク上で物理的な場所を確保するため、必要なのはボリュームの名前を覚えておくだけです。 -.. As mentioned, we are going to use a named volume. Think of a named volume as simply a bucket of data. Docker maintains the physical location on the disk and you only need to remember the name of the volume. Every time you use the volume, Docker will make sure the correct data is provided. +.. Create a volume and start the container +.. _create-a-volume-and-start-the-container: -先述の通り、ここでは **名前付きボリューム（named volume）** を使おうとしています。名前付きボリュームとは、単なるデータの :ruby:`入れ物 ` と考えてください。Docker がディスク上で物理的な場所を確保するので、必要なのはボリュームの名前を覚えておくだけです。ボリュームを使うたびに、Docker は正しいデータの提供を確認します。 +ボリュームの作成とコンテナの起動 +---------------------------------------- -.. Create a volume by using the docker volume create command. +.. You can create the volume and start the container using the CLI or Docker Desktop’s graphical interface. -1. ``docker volume create`` コマンドを使ってボリュームを作成します。 +CLI か Docker Desktop のグラフィカルインタフェースを使い、ボリュームの作成とコンテナの起動ができます。 +**CLI** + + .. Create a volume by using the docker volume create command. + + 1. ``docker volume create`` コマンドを使ってボリュームを作成します。 + + .. code-block:: bash + + $ docker volume create todo-db + + .. Stop and remove the todo app container once again with docker rm -f , as it is still running without using the persistent volume. + + 2. todo アプリのコンテナを再び作り直します。 :ruby:`保存するボリューム ` を使わずに起動しているため、 ``docker rm -f `` で停止と削除をします。 + + .. Start the todo app container, but add the --mount option to specify a volume mount. Give the volume a name, and mount it to /etc/todos in the container, which captures all files created at the path. In your Mac or Linux terminal, or in Windows Command Prompt or PowerShell, run the following command: + + 3. todo アプリのコンテナを起動しますが、ボリュームのマウントを指定する ``--mount`` オプションを追加します。ボリューム名を与え、そこをコンテナ内の ``/etc/todos`` にマウントすると、そのパスに作成された全てのファイルを（ボリューム内に）確保します。Mac や Linux のターミナルで、あるいは、 Windows コマンドプロンプトや PowerShell で以下のコマンドで実行します。 + .. code-block:: bash + + $ docker run -dp 127.0.0.1:3000:3000 --mount type=volume,src=todo-db,target=/etc/todos getting-started - $ docker volume create todo-db +**Docker Desktop** -.. Stop and remove the todo app container once again in the Dashboard (or with docker rm -f ), as it is still running without using the persistent volume. + 1. ボリュームを作成します。 + + a. Docker Desktop で **Volumes** を選びます。 + b. **Volumes** で **Create** を選びます。 + c. ボリューム名として ``todo-db`` を指定し、それから **Create** を選びます。 -2. ダッシュボードで（あるいは ``docker rm -f `` ）、もう一度 todo アプリのコンテナを停止および削除します。このコンテナでは、まだ :ruby:`存続するボリューム ` を使っていないからです。 + 2. アプリのコンテナを停止・削除します。 + + a. Docker Desktop で **Containers** を選びます。 + b. 対象コンテナの **Actions** 列にある **Delete** を選びます。 -.. Start the todo app container, but add the -v flag to specify a volume mount. We will use the named volume and mount it to /etc/todos, which will capture all files created at the path. + 3. ボリュームを待つのしてアプリコンテナを起動します。 + + a. Docker Desktop の一番上にある検索ボックスを選びます。 + b. 検索ウインドウで **Images** タブを選びます。 + c. 検索ボックスでコンテナ名を ``getting-started`` と指定します。 + + .. tip:: + + 検索でフィルタを使えば **local images** （ローカルイメージ）のみ表示できます。 -3. todo アプリのコンテナを起動しますが、ボリュームのマウントを指定する ``-v`` フラグを追加します。ここでは名前付きボリュームを使い、 ``/etc/todos`` にマウントします。そうすると、このパスに作成された全てのファイルを保存します。 + d. 自分が作ったイメージを選び、 **Run** （実行）を選びます。 + e. **Optional settings** を選びます。 + f. **Host path** （ホスト側パス）で、ボリューム名 ``todo-db`` を指定します + g. **Container path** （コンテナ側パス）で ``/etc/todos`` を指定します。 + h. **Run** （実行）を選びます。 - .. code-block:: bash - $ docker run -dp 3000:3000 -v todo-db:/etc/todos getting-started +.. Verify that the data persists +.. _verify-that-the-data-persists: + +データの保持を確認 +-------------------- .. Once the container starts up, open the app and add a few items to your todo list. -4. コンテナが起動したら、アプリを開き、todo リストに新しいアイテムを追加します。 +1. コンテナが起動したら、アプリを開き、todo リストに新しいアイテムを追加します。 -.. image:: ./images/items-added.png - :scale: 60% - :alt: Todo リストにアイテムを追加 + .. image:: ./images/items-added.png + :width: 60% + :alt: Todo リストにアイテムを追加 .. Stop and remove the container for the todo app. Use the Dashboard or docker ps to get the ID and then docker rm -f to remove it. -5. todo アプリ用のコンテナを停止・削除します。コンテナの ID をダッシュボードか ``docker ps`` コマンドで調べ、 ``docker rm -f `` で削除します。 +2. todo アプリ用のコンテナを停止・削除します。コンテナの ID をダッシュボードか ``docker ps`` コマンドで調べ、 ``docker rm -f `` で削除します。 .. Start a new container using the same command from above. -6. 先ほどと同じコマンドを使い、新しいコンテナを起動します。 +3. 先ほどと同じコマンドを使い、新しいコンテナを起動します。 .. Open the app. You should see your items still in your list! -7. アプリを開きます。そうすると、まだリストにアイテムが残っているのが見えるでしょう！ +4. アプリを開きます。そうすると、まだリストにアイテムが残っているのが見えるでしょう！ .. Go ahead and remove the container when you’re done checking out your list. -8. リストの挙動を確認できれば、次へ進むためにコンテナを削除します。 +5. リストの挙動を確認できれば、次へ進むためにコンテナを削除します。 -.. Hooray! You’ve now learned how to persist data! +.. You’ve now learned how to persist data. -できました！ これでデータを保持する方法を学びました。 - -.. Note - While named volumes and bind mounts (which we’ll talk about in a minute) are the two main types of volumes supported by a default Docker engine installation, there are many volume driver plugins available to support NFS, SFTP, NetApp, and more! This will be especially important once you start running containers on multiple hosts in a clustered environment with Swarm, Kubernetes, etc. - -.. note:: - - :ruby:`名前付きボリューム ` と :ruby:`バインド マウント ` （この後すぐ説明します）は、 Docker engine のインストールが、デフォルトでサポートしている２つの主なタイプです。他にも NFS、SFTP、NetApp 等々のサポートといった、多くのボリューム ドライバ プラグインがあります。これは Swarm や Kubernetes 等のクラスタ環境で、複数のホスト上にコンテナを実行しようとするのであれば、とても重要になります。 +これでデータを保持する方法を学びました。 .. Dive into the volume .. _dive-into-the-volume: @@ -198,9 +246,9 @@ todo データの保持 ボリュームを深掘り ==================== -.. A lot of people frequently ask “Where is Docker actually storing my data when I use a named volume?” If you want to know, you can use the docker volume inspect command. +.. A lot of people frequently ask “Where is Docker storing my data when I use a volume?” If you want to know, you can use the docker volume inspect command. -多くの人々が頻繁に「名前付きボリュームを使うと、私のデータを Docker が"実際に"保存するのはどこですか？」と尋ねます。知りたければ ``docker volume inspect`` コマンドが使えます。 +多くの人々が頻繁に尋ねるのは「ボリュームを使う時、 Docker が私のデータを"実際に"保存するのはどこですか？」です。知りたければ ``docker volume inspect`` コマンドで調べられます。 .. code-block:: bash @@ -219,7 +267,7 @@ todo データの保持 .. The Mountpoint is the actual location on the disk where the data is stored. Note that on most machines, you will need to have root access to access this directory from the host. But, that’s where it is! -この ``MountPoint`` こそが、ディスク上でデータを保管している本当の場所です。ほとんどのマシンでは、このディレクトにホスト上からアクセスするには root 権限が必要でしょう。ですが、そこにデータがあるのです！ +この ``MountPoint`` （マウントポイント）こそが、ディスク上に実際のデータを保管している場所です。ほとんどのマシンでは、このディレクトにホスト上からアクセスするには root 権限が必要なので注意してください。まさに、そこにデータがあります！ .. Accessing volume data directly on Docker Desktop While running in Docker Desktop, the Docker commands are actually running inside a small VM on your machine. If you wanted to look at the actual contents of the Mountpoint directory, you would need to first get inside of the VM. @@ -230,19 +278,27 @@ todo データの保持 Docker Desktop を実行中に、Docker コマンドが実際に動くのは、マシン上の小さな仮想マシン内です。マウントポイントのディレクトリ内で、実際の内容を見たい場合は、何よりもまず仮想マシン内に入る必要があります。 -.. Recap -.. _part5-recap: +.. Next steps +.. _part5-next-steps: + +次のステップ +==================== + +.. At this point, you have a functioning application that can survive restarts. + +ここまで、アプリケーションを再起動しても（テータを）保持できる機能を確認しました。 + +.. However, you saw earlier that rebuilding images for every change takes quite a bit of time. There’s got to be a better way to make changes, right? With bind mounts, there is a better way. -まとめ -========== +ところで一方、初期の頃から変更を加えるたびに、何度も何度も毎回イメージの再構築をしています。これを改善したいと思いますよね？ バインド マウントの使用こそが良い方法です。 -.. At this point, we have a functioning application that can survive restarts! We can show it off to our investors and hope they can catch our vision! -ここまで、アプリケーションを再起動しても（テータを）保持できる機能を確認しました！ これでアプリケーションを投資家に披露できますので、私たちのビジョンを把握してもらえるよう望みます。 +.. raw:: html -.. However, we saw earlier that rebuilding images for every change takes quite a bit of time. There’s got to be a better way to make changes, right? With bind mounts (which we hinted at earlier), there is a better way! Let’s take a look at that now! + -ところで一方、初期の頃から変更を加えるたびに、何度も何度も毎回イメージの再構築をしています。これを改善したいと思いますよね？ バインド マウントの使用（先ほど簡単に触れました）こそが良い方法です。詳しく見ていきましょう！ .. seealso:: diff --git a/get-started/06_bind_mounts.rst b/get-started/06_bind_mounts.rst index fda2dee24..d038ae2c0 100644 --- a/get-started/06_bind_mounts.rst +++ b/get-started/06_bind_mounts.rst @@ -1,9 +1,9 @@ .. -*- coding: utf-8 -*- .. URL: https://docs.docker.com/get-started/06_bind_mounts/ - doc version: 20.10 + doc version: 24.0 https://github.com/docker/docker.github.io/blob/master/get-started/06_bind_mounts.md -.. check date: 2022/09/20 -.. Commits on Jun 28, 2022 b0dc95cd626d1cd7f7582307d693fd72a27280ce +.. check date: 2023/07/17 +.. Commits on Jul 13, 2023 68450b02a56c95b2c8ef50f24d40dd57356343b7 .. ----------------------------------------------------------------------------- .. Use bind mounts @@ -19,40 +19,42 @@ :depth: 2 :local: -.. In the previous chapter, we talked about and used a named volume to persist the data in our database. Named volumes are great if we simply want to store data, as we don’t have to worry about where the data is stored. +.. In part 5, you used a volume mount to persist the data in your database. A volume mount is a great choice when you need somewhere persistent to store your application data. -前章では、データベース内のデータを保持するため、 **名前付きボリューム（named volume）** を使う方法を説明しました。シンプルにデータを保存したい場合には、名前付きボリュームは優れていますが、「どこ」にデータが保管されているか心配したくありません。 +:doc:`Part 5 <05_persisting_data>` ではデータベース内のデータを保持するため、ボリュームのマウントを使いました。アプリケーションのデータをどこかに保持する必要がある場合、ボリュームマウントは良い選択肢です。 -.. With bind mounts, we control the exact mountpoint on the host. We can use this to persist data, but it’s often used to provide additional data into containers. When working on an application, we can use a bind mount to mount our source code into the container to let it see code changes, respond, and let us see the changes right away. +.. A bind mount is another type of mount, which lets you share a directory from the host’s filesystem into the container. When working on an application, you can use a bind mount to mount source code into the container. The container sees the changes you make to the code immediately, as soon as you save a file. This means that you can run processes in the container that watch for filesystem changes and respond to them. -**バインド マウント（bind mount）** であれば、ホスト上の正確なマウントポイントを管理できます。バインド マウントはデータ保持に使えますが、使用時はコンテナに対する追加データの指定が度々必要です。アプリケーションの動作中でも、バインド マウントを使ってソースコードをコンテナ内にマウントすると、コードの変更が見えたり反映したりできるようになります。つまり、アプリケーションに対する変更は、直ちに見えるでしょう。 +:ruby:`バインド マウント ` は他のタイプのマウントであり、ホスト上のファイルシステムをコンテナ内と直接共有します。アプリケーションの動作中でも、バインド マウントを使ってソースコードをコンテナ内にマウントすると、コードの変更が見えたり反映できるようになります。つまり、アプリケーションに対する変更が、直ちに見えるでしょう。 -.. For Node-based applications, nodemon is a great tool to watch for file changes and then restart the application. There are equivalent tools in most other languages and frameworks. +.. In this chapter, you’ll see how you can use bind mounts and a tool called nodemon to watch for file changes, and then restart the application automatically. There are equivalent tools in most other languages and frameworks. + +本章で分かるのは、バインドマウントの使い方と、ファイル変更を監視してアプリケーションを自動的に再起動する `nodemon `_ と呼ばれるツールについてです。 -Node をベースとするアプリケーション `nodemon `_ は素晴らしいツールです。ファイルの変更を監視し、アプリケーションを再起動します。他の言語やフレームワークでも、同様なツールがあります。 .. Quick volume type comparisons -.. _quick-violume-type-comparisons: +.. _quick-volume-type-comparisons: ボリューム型の素早い比較 ============================== -.. Bind mounts and named volumes are the two main types of volumes that come with the Docker engine. However, additional volume drivers are available to support other uses cases (SFTP, Ceph, NetApp, S3, and more). +.. The following table outlines the main differences between volume mounts and bind mounts. + +以下の表が示すのは、ボリュームマウントとバインドマウントの主な違いです。 -バインド マウントと名前付きボリュームは、Docker Engine に組み込まれている２つの主なボリューム型です。しかしながら、他の利用例（ `SFTP `_ 、 `Ceph `_ 、 `NetApp `_ 、 `S3 `_ 、 等）をサポートする追加ボリュームドライバが利用可能です。 .. list-table:: :header-rows: 1 * - - - 名前付きボリューム - - バインド マウント + - :ruby:`名前付きボリューム ` + - :ruby:`バインド マウント ` * - ホスト上の場所 - Docker が選択 - - 自分で管理 - * - マウント例（ ``-v`` を使用） - - my-volume:/usr/local/data - - /path/to/data:/usr/local/data + - 自分で決める + * - マウント例（ ``--mount`` を使用） + - ``type=volume,src=my-volume,target=/usr/local/data`` + - ``type=bind,src=/path/to/data,target=/usr/local/data`` * - コンテナの内容に新しいボリュームを加える - はい - いいえ @@ -60,137 +62,307 @@ Node をベースとするアプリケーション `nodemon docker run -dp 3000:3000 ` - -w /app -v "$(pwd):/app" ` - node:18-alpine ` - sh -c "yarn install && yarn run dev" - .. If you are using an Apple silicon Mac or another ARM64 device, then use the following command. + root@ac1237fad8db:/src# touch myfile.txt + root@ac1237fad8db:/src# ls + Dockerfile myfile.txt node_modules package.json spec src yarn.lock - Apple silicon Mac や他の ARM64 デバイスを使っている場合は、以下のコマンドを実行します。 +.. Open the app directory on the host and observe that the myfile.txt file is in the directory. + +6. ホスト上の ``app`` ディレクトリを開き、ディレクトリ内に ``myfile.txt`` があるかどうか調べます。 .. code-block:: bash - - $ docker run -dp 3000:3000 \ - -w /app -v "$(pwd):/app" \ - node:18-alpine \ - sh -c "apk add --no-cache python2 g++ make && yarn install && yarn run dev" + ├── app/ + │ ├── Dockerfile + │ ├── myfile.txt + │ ├── node_modules/ + │ ├── pacakge.json + │ ├── spec/ + │ ├── src/ + │ └── yarn.lock - * ``-dp 3000:3000`` … 以前と同じです。 :ruby:`デタッチド ` （バックグラウンド）モードで実行し、 :ruby:`ポート割り当て ` を作成 - * ``-w /app`` … コマンドを実行する場所として、「 :ruby:`作業ディレクトリ ` 」またはカレント ディレクトリを指定 - * ``-v "$(pwd):/app"`` … ホスト上にある現在のディレクトリを、コンテナ内の ``/app`` ディレクトリにバインド マウント - * ``node:18-alpine`` … 使用するイメージ。これが Dockerfile から作成するアプリ用のベースイメージになるのを意味する - * ``sh -c "yarn install && yarn run dev"`` … （コンテナで）実行するコマンド。 ``sh`` を使って開始し（alpine には ``bash`` がないため）、全ての依存関係をインストールするため ``yarn install`` を実行し、それから ``yarn run dev`` を実行。 ``package.json`` があれば確認し、それから ``dev`` スクリプトが ``nodemon`` を開始する +.. From the host, delete the myfile.txt file. -.. You can watch the logs using docker logs. You’ll know you’re ready to go when you see this: +7. ホストから ``myfile.txt`` ファイルを削除します。 -3. ``docker logs`` を使ってログを表示できます。以下のような表示になれば、準備が調ったと分かります。 +.. In the container, list the contents of the app directory once more. Observe that the file is now gone. + +8. コンテナ内で、再び ``app`` ディレクトリ内の内容を一覧表示します。今度はファイルが消えてしまったと分かります。 .. code-block:: bash - $ docker logs -f - nodemon src/index.js - [nodemon] 2.0.20 - [nodemon] to restart at any time, enter `rs` - [nodemon] watching dir(s): *.* - [nodemon] starting `node src/index.js` - Using sqlite database at /etc/todos/todo.db - Listening on port 3000 + root@ac1237fad8db:/src# ls + Dockerfile node_modules package.json spec src yarn.lock + +.. Stop the interactive container session with Ctrl + D. + +9. 対話型のコンテナセッションを ``Ctrl`` + ``D`` で停止します。 + +.. That’s all for a brief introduction to bind mounts. This procedure demonstrated how files are shared between the host and the container, and how changes are immediately reflected on both sides. Now you can use bind mounts to develop software. + + +以上がバインドマウントの簡単な紹介のすべてです。この手順では、ホストとコンテナ間でどのようにファイルを共有しているのかと、どちらにも変更が直ちに反映されるのを示しました。これでソフトウェア開発にバインドマウントを利用できます。 + +.. Deployment containers +コンテナのデプロイ +==================== + +.. Using bind mounts is common for local development setups. The advantage is that the development machine doesn’t need to have all of the build tools and environments installed. With a single docker run command, Docker pulls dependencies and tools. + +ローカル開発環境のセットアップで、バインドマウントの利用は一般的です。利点は、開発マシン上に全ての構築ツールや環境をインストールする必要がありません。docker run コマンドを1回実行するだけで、Docker は依存関係とツールを取得します。 + +.. Run your app in a development container +.. _run-your-app-in-a-development-container: + +開発用のコンテナでアプリを実行 +------------------------------ + +.. The following steps describe how to run a development container with a bind mount that does the following: + +以下の手順で示すのは、バインドマウントがある開発用のコンテナを実行する手順です： + +.. + Mount our source code into the container + Install all dependencies + Start nodemon to watch for filesystem changes + + * ソースコードをコンテナ内にマウント + * 全ての依存関係をインストール + * ファイルシステムの変更を監視する ``nodemon`` を開始 + +.. You can use the CLI or Docker Desktop to run your container with a bind mount. + +バインドマウントしてコンテナを実行するには、 CLI か Docker Desktop を使えます。 + +**CLI** + + .. Make sure you don’t have any previous getting-started containers running. + + 1. これまでの ``getting-started`` コンテナが動作していないのを確認します。 + + .. Run the following command from the getting-started/app directory. + + 2. ``getting-started/app`` ディレクトリから以下のコマンドを実行します。 + + **Mac / Linux** + + .. code-block:: bash + + $ docker run -dp 127.0.0.1:3000:3000 \ + -w /app --mount type=bind,src="$(pwd)",target=/app \ + node:18-alpine \ + sh -c "yarn install && yarn run dev" + + **Windows** + + このコマンドを PowerShell で実行します。 + + $ docker run -dp 127.0.0.1:3000:3000 ` + -w /app --mount "type=bind,src=$pwd,target=/app" ` + node:18-alpine ` + sh -c "yarn install && yarn run dev" - ログの表示を終了するには、 ``Ctrl`` + ``C`` を実行します。 + .. The following is a breakdown of the command: + + 以下はコマンドの詳細です： + + * ``-dp 127.0.0.1:3000:3000`` … 以前と同じです。デタッチド（バックグラウンド）モードで実行し、ポート割り当てを作成します。 + * ``-w /app`` … 「 :ruby:`作業ディレクトリ ` 」 またはカレントディレクトリを指定します。 + * ``--mount "type=bind,src=$pwd,target=/app"`` … ホスト上のカレントディレクトリを、コンテナ内の ``/app`` ディレクトリにバインドマウントします。 + * ``node:18-alpine`` … 使用するイメージです。なお、これが Dockerfile からアプリを作成するベースイメージです。 + * ``sh -c "yarn install && yarn run dev"`` … シェルを開始するのに ``sh`` を使い（ alpine には ``bash`` はありません）、パッケージをインストールするため ``yarn install`` を実行し、開発用サーバを開始するために ``yarn run dev`` を実行します。 ``packagejson`` の中を見ると、 ``dev`` スクリプトが ``nodemon`` を起動しているのが分かります。 -.. Now, let’s make a change to the app. In the src/static/js/app.js file, let’s change the “Add Item” button to simply say “Add”. This change will be on line 109: + .. You can watch the logs using docker logs . You’ll know you’re ready to go when you see this: + + 3. ``docker logs `` を使いログを観察できます。準備が調えば、次のような表示になるでしょう： + + .. code-block:: bash + + $ docker logs -f + nodemon src/index.js + [nodemon] 2.0.20 + [nodemon] to restart at any time, enter `rs` + [nodemon] watching dir(s): *.* + [nodemon] starting `node src/index.js` + Using sqlite database at /etc/todos/todo.db + Listening on port 3000 + + .. When you’re done watching the logs, exit out by hitting Ctrl+C. + + ログの観察が終わったら、 ``Ctrl`` + ``C`` を入力して終了します。 + +**Docker Desktop** + + .. Make sure you don’t have any previous getting-started containers running. + + 1. これまでの ``getting-started`` コンテナが動作していないのを確認します。 + + .. Run the image with a bind mount. + + 2. バインドマウントしてイメージを起動します。 + + a. Docker Desktop の一番上にある検索ボックスを選びます。 + b. 検索ウインドウで **Images** タブを選びます。 + c. 検索ボックスでコンテナ名を ``getting-started`` と指定します。 + + .. tip:: + + 検索でフィルタを使えば **local images** （ローカルイメージ）のみ表示できます。 + + d. 自分が作ったイメージを選び、 **Run** （実行）を選びます。 + e. **Optional settings** を選びます。 + f. **Host path** （ホスト側パス）で、ホストマシン上の ``app`` ディレクトリのパスを指定します + g. **Container path** （コンテナ側パス）で ``/app`` を指定します。 + h. **Run** （実行）を選びます。 + + 3. Docker Desktop を使ってコンテナのログを観察できます。 + + a. Docker Desktop の **Containers** を選びます。 + b. コンテナ名を選びます。 + + 準備が調えば、次の様な表示になるでしょう： + + .. code-block:: bash + + $ docker logs -f + nodemon src/index.js + [nodemon] 2.0.20 + [nodemon] to restart at any time, enter `rs` + [nodemon] watching dir(s): *.* + [nodemon] starting `node src/index.js` + Using sqlite database at /etc/todos/todo.db + Listening on port 3000 -4. 次は、アプリを変更しましょう。 ``src/static/js/app.js`` ファイル内で、「Add Item」ボタンを、シンプルに「Add」と表示するように変えます。変更には 109 行目を変えるだけです。 + +.. Develop your app with the development container +.. _develop your app with the development container: +開発用コンテナにアプリをデプロイ +---------------------------------------- + +.. Update your app on your host machine and see the changes reflected in the container. + +ホストマシン上のアプリを更新し、コンテナ内に変更が反映されるのを確認します。 + +.. In the src/static/js/app.js file, on line 109, change the “Add Item” button to simply say “Add”: + +1. ``src/static/js/app.js`` ファイル内の 109 行目の、「Add Item」ボタンをシンプルに「Add」と表示するように変えます。 .. code-block:: diff - {submitting ? 'Adding...' : 'Add Item'} + {submitting ? 'Adding...' : 'Add'} -.. Simply refresh the page (or open it) and you should see the change reflected in the browser almost immediately. It might take a few seconds for the Node server to restart, so if you get an error, just try refreshing after a few seconds. + ファイルを保存します。 + +.. Refresh the page in your web browser, and you should see the change reflected almost immediately. It might take a few seconds for the Node server to restart. If you get an error, try refreshing after a few seconds. -5. ページを単に再読み込みすると（あるいは、ページを開きます）、ほぼ直ちにブラウザに変更が反映しているのが分かるでしょう。Node サーバの再起動には、数秒かかるかもしれず、もしエラーが出てしまった場合には、数秒後に再起動を試してください。 +2. ウェブブラウザでページを再読み込みしたら、ほぼ直ちに変更が反映しているのが分かるでしょう。Node サーバの再起動には、数秒かかるかもしれず、もしエラーが出てしまった場合には、数秒後に再読み込みを試してください。 .. image:: ./images/updated-add-button.png - :scale: 60% + :width: 60% :alt: Add ボタンのラベルを更新したスクリーンショット -.. Feel free to make any other changes you’d like to make. When you’re done, stop the container and build your new image using: +.. Feel free to make any other changes you’d like to make. Each time you make a change and save a file, the nodemon process restarts the app inside the container automatically. When you’re done, stop the container and build your new image using: -6. あとは作りたいように他にも自由に変更します。終わったら、コンテナを停止し、以下のコマンドを使って新しいイメージを構築します。 +3. あとは、他も自由気ままに変更します。変更後は毎回ファイルを保存しますと、 ``nodemon`` プロセスがコンテナ内のアプリを再起動します。終わったら、コンテナを停止し、以下のコマンドを使って新しいイメージを構築します。 .. code-block:: bash $ docker build -t getting-started . -.. Using bind mounts is very common for local development setups. The advantage is that the dev machine doesn’t need to have all of the build tools and environments installed. With a single docker run command, the dev environment is pulled and ready to go. We’ll talk about Docker Compose in a future step, as this will help simplify our commands (we’re already getting a lot of flags). +.. Next steps +.. _part6-next-steps: + +次のステップ +==================== + +.. At this point, you can persist your database and see changes in your app as you develop without rebuilding the image. -バインド マウントの使用は、ローカル開発のセットアップで「非常に」一般的です。この利点は、開発マシンに全ての構築ツールや環境を入れる必要がないからです。 ``docker run`` コマンド１つだけで、開発環境を持ってきて、すぐに始められます。後のステップで、（たくさんのフラグ指定が必要な）コマンド実行を簡単にするのに役立つ Docker Compose を説明します。 +現段階で、データベースを保持できるようになり、イメージを再構築しなくても、開発しているアプリを変更できるのが分かりました。 -.. Recap -.. _part6-recap: +.. In addition to volume mounts and bind mounts, Docker also supports other mount types and storage drivers for handling more complex and specialized use cases. To learn more about the advanced storage concepts, see Manage data in Docker. -まとめ -========== +ボリュームマウントとバインドマウントに加え、より複雑かつ専門的なユースケースに対応するため、Docker は他のマウントタイプやストレージドライバをサポートします。 -.. At this point, we can persist our database and respond rapidly to the needs and demands of our investors and founders. Hooray! But, guess what? We received great news! +.. In order to prepare your app for production, you need to migrate your database from working in SQLite to something that can scale a little better. For simplicity, you’ll keep using a relational database and switch your application to use MySQL. But, how should you run MySQL? How do you allow the containers to talk to each other? You’ll learn about that in the next section. -これで、データベースを保持し、必要に応じて素早く対応でき、投資家や創設者の要望に応えられるようになりました。やった！ 良いニュースが届きました！ +アプリの本番環境を準備するには、データベースを SQLite からスケール可能な何かに移行する必要があります。扱いやすさのため、関係データベースの採用にあたり、アプリケーションが MySQL を使うように切り替えます。ですが、どうやって MySQL を動かせばよいのでしょうか？ どのようにしてコンテナ間でお互いが通信できるのでしょうか？ これは次のセクションで学びます。 -.. Your project has been selected for future development! -**あなたのプロジェクトが今後の開発対象として選ばれました！** +.. raw:: html -.. In order to prepare for production, we need to migrate our database from working in SQLite to something that can scale a little better. For simplicity, we’ll keep with a relational database and switch our application to use MySQL. But, how should we run MySQL? How do we allow the containers to talk to each other? We’ll talk about that next! + -本番環境を準備するには、データベースを SQLite からスケール可能な何かへ以降する必要があります。扱いやすさのため、関係データベースを使い続け、アプリケーションが MySQL を使うように切り替えます。ですが、どうやって MySQL を動かせばよいのでしょうか？ どのようにしてコンテナ間がお互いに通信できるのでしょうか？ 次で解説します。 .. seealso:: diff --git a/get-started/07_multi_container.rst b/get-started/07_multi_container.rst index c6db83742..6b1d27b16 100644 --- a/get-started/07_multi_container.rst +++ b/get-started/07_multi_container.rst @@ -1,9 +1,9 @@ .. -*- coding: utf-8 -*- .. URL: https://docs.docker.com/get-started/07_multi_container/ - doc version: 20.10 + doc version: 24.0 https://github.com/docker/docker.github.io/blob/master/get-started/07_multi_container.md -.. check date: 2022/09/20 -.. Commits on May 12, 2022 9a1cb6561c89559d7b85f6714d0ddc4d4cc27e15 +.. check date: 2023/07/17 +.. Commits on Jun 7, 2023 aee91fdaba9516d06db5b6b580e98f70a9a11c55 .. ----------------------------------------------------------------------------- .. Multi container apps @@ -19,9 +19,9 @@ :depth: 2 :local: -.. Up to this point, we have been working with single container apps. But, we now want to add MySQL to the application stack. The following question often arises - “Where will MySQL run? Install it in the same container or run it separately?” In general, each container should do one thing and do it well. A few reasons: +.. Up to this point, you’ve been working with single container apps. But, now you will add MySQL to the application stack. The following question often arises - “Where will MySQL run? Install it in the same container or run it separately?” In general, each container should do one thing and do it well. The following are a few reasons to run the container separately: -これまでは１つのコンテナでアプリを動かしていました。しかし、これからはアプリケーション群に MySQL を追加しようとしています。そうすると、たいてい次の疑問が沸き上がります。「どこで MySQL を実行するの？ 同じコンテナにインストールするのかな、それとも別々に実行するの？」 通常、 **１つ１つのコンテナが、１つのことをしっかりと実行すべきです** 。いくつかの理由があります。 +これまでは１つのコンテナでアプリを動かしていました。しかし、これからはアプリケーション スタックに MySQL を追加しようとしています。そうすると、たいてい次の疑問が沸き上がります。「どこで MySQL を実行するのですか？ 同じコンテナにインストールするのかな、それとも別々に実行するの？」と。通常、１つ１つのコンテナが、１つのことをしっかりと実行すべきです 。以下はコンテナを分けて実行する理由です。 .. There’s a good chance you’d have to scale APIs and front-ends differently than databases Separate containers let you version and update versions in isolation @@ -31,7 +31,7 @@ * データベースとは別に、 API とフロントエンドをスケールする良い機会 * コンテナを分けると、現在のバージョンと更新したバージョンを分離できる * 今はローカルにあるデータベースをコンテナが使っているが、プロダクションではデータベースのマネージド サービスを利用したくなるかもしれない -* 複数プロセスの実行にはプロセスマネージャが必要であり（コンテナは１つのプロセスのみ起動するため）、コンテナの起動や停止が複雑になる +* 複数のプロセスを実行するにはプロセスマネージャが必要であり（コンテナは１つのプロセスのみ起動するため）、コンテナの起動や停止が複雑になる .. And there are more reasons. So, we will update our application to work like this: @@ -39,7 +39,6 @@ .. image:: ./images/multi-app-architecture.png - :scale: 60% :alt: Todo アプリは MySQL コンテナに接続 .. Container networking @@ -48,18 +47,9 @@ コンテナのネットワーク機能 ============================== -.. Remember that containers, by default, run in isolation and don’t know anything about other processes or containers on the same machine. So, how do we allow one container to talk to another? The answer is networking. Now, you don’t have to be a network engineer (hooray!). Simply remember this rule... - -コンテナについて思い出しましょう。デフォルトでは、 :ruby:`孤立した状態 ` で実行するため、同じマシン上の他のプロセスやコンテナを一切知りません。それでは、どのようにして他のコンテナと通信できるのでしょうか？ 答えは **ネットワーク機能（ networking ）** です。これであなたがネットワークエンジニアになる必要はありません（やったね！）。単純にこのルールを忘れないでください……。 - - -.. Note - If two containers are on the same network, they can talk to each other. If they aren’t, they can’t. - -.. note:: - - ２つのコンテナが同じネットワーク上にあれば、お互いに通信できます。そうでなければ、どちらも通信できません。 +.. Remember that containers, by default, run in isolation and don’t know anything about other processes or containers on the same machine. So, how do you allow one container to talk to another? The answer is networking. If you place the two containers on the same network, they can talk to each other. +コンテナについて思い出しましょう。デフォルトでは、 :ruby:`孤立した状態 ` で実行するため、同じマシン上の他のプロセスやコンテナを一切知りません。それでは、どのようにして他のコンテナと通信できるのでしょうか？ 答えは ネットワーク機能（ networking ）であり、お互いに通信可能になります。 .. Start MySQL .. _start-mysql: @@ -67,9 +57,19 @@ MySQL の起動 ==================== -.. There are two ways to put a container on a network: 1) Assign it at start or 2) connect an existing container. For now, we will create the network first and attach the MySQL container at startup. +.. There are two ways to put a container on a network: -コンテナをネットワークに加えるには、２つの方法があります。１つは、起動する前に割り当てるか、もう１つは、既存のコンテナに接続します。さしあたり、まずはネットワークを作成し、それから MySQL コンテナの起動時に接続します。 +コンテナをネットワークに加えるには2つの方法があります。 + +.. Assign the network when starting the container. + Connect an already running container to a network. + +* コンテナの起動時にネットワークを割り当てる +* 既に実行しているコンテナをネットワークに接続する + +.. In the following steps, you’ll create the network first and then attach the MySQL container at startup. + +以下の手順では、まずネットワークを作成し、それから MySQL コンテナの起動時に接続（アタッチ）します。 .. Create the network. @@ -79,58 +79,44 @@ MySQL の起動 $ docker network create todo-app -.. Start a MySQL container and attach it to the network. We’re also going to define a few environment variables that the database will use to initialize the database (see the “Environment Variables” section in the MySQL Docker Hub listing). +.. Start a MySQL container and attach it to the network. You’re also going to define a few environment variables that the database will use to initialize the database. To learn more about the MySQL environment variables, see the “Environment Variables” section in the MySQL Docker Hub listing. -2. MySQL コンテナを起動し、先ほどのネットワークに接続します。あわせて複数の環境変数を定義します。これは、データベースの初期化に使います（ `MySQL Docker Hub `_ にある「Environment Variables」セクションをご覧ください）。 +2. MySQL コンテナを起動し、先ほどのネットワークに接続します。あわせて複数の環境変数を定義します。これは、データベースの初期化に使います。MySQL の環境変数について学ぶには、 `MySQL Docker Hub `_ にある「Environment Variables」セクションをご覧ください。 - .. code-block:: bash - - $ docker run -d \ - --network todo-app --network-alias mysql \ - -v todo-mysql-data:/var/lib/mysql \ - -e MYSQL_ROOT_PASSWORD=secret \ - -e MYSQL_DATABASE=todos \ - mysql:5.7 - - .. If you are using an ARM based chip, e.g. Macbook M1 Chips / Apple Silicon, then use this command. - - Macbook M1 チップ / Apple Silicon のような ARM ベースのチップを使う場合は、こちらのコマンドを使います。 + **Mac / Linux** - .. code-block:: bash - - $ docker run -d \ - --network todo-app --network-alias mysql \ - --platform "linux/amd64" \ - -v todo-mysql-data:/var/lib/mysql \ - -e MYSQL_ROOT_PASSWORD=secret \ - -e MYSQL_DATABASE=todos \ - mysql:5.7 - - .. If you are using Windows then use this command in PowerShell. + .. code-block:: bash - Windows を使う場合は、 PowerShell でこちらのコマンドを使います。 + $ docker run -d \ + --network todo-app --network-alias mysql \ + -v todo-mysql-data:/var/lib/mysql \ + -e MYSQL_ROOT_PASSWORD=secret \ + -e MYSQL_DATABASE=todos \ + mysql:8.0 - .. code-block:: bash - - PS> docker run -d ` - --network todo-app --network-alias mysql ` - -v todo-mysql-data:/var/lib/mysql ` - -e MYSQL_ROOT_PASSWORD=secret ` - -e MYSQL_DATABASE=todos ` - mysql:5.7 + **Windows** - .. You’ll also see we specified the --network-alias flag. We’ll come back to that in just a moment. + Windows では PowerShell 上でコマンドを実行します。 + + .. code-block:: bash + - また、 ``--network-alias`` フラグも指定したのが見えるでしょう。こちらについては、後で触れます。 + $ docker run -d ` + --network todo-app --network-alias mysql ` + -v todo-mysql-data:/var/lib/mysql ` + -e MYSQL_ROOT_PASSWORD=secret ` + -e MYSQL_DATABASE=todos ` + mysql:8.0 - .. Tip - You’ll notice we’re using a volume named todo-mysql-data here and mounting it at /var/lib/mysql, which is where MySQL stores its data. However, we never ran a docker volume create command. Docker recognizes we want to use a named volume and creates one automatically for us. + .. In the command above, you’ll see the --network-alias flag. In a later section, you’ll learn more about this flag. + + 先ほどのコマンドでは、 ``--network-alias`` フラグも指定したのが見えるでしょう。こちらについては、後で触れます。 .. tip:: - ここでは ``todo-mysql-data`` という名前のボリュームを使い、 MySQL が自身のデータを保管する ``/var/lib/mysql`` をマウントしているのに気づくでしょう。しかしまだ、 ``docker volume create`` コマンドを実行していません。名前付きボリュームを使いたい時は、 Docker が認識し、自動的にボリュームを作成します。 + ここでは ``todo-mysql-data`` という名前のボリュームを使い、 MySQL が自身のデータを保管する ``/var/lib/mysql`` をマウントしているのに気づくでしょう。しかしまだ、 ``docker volume create`` コマンドを実行していません。名前付きボリュームを使おうとすると、 Docker が認識し、自動的にボリュームを作成します。 -.. To confirm we have the database up and running, connect to the database and verify it connects. +.. To confirm you have the database up and running, connect to the database and verify that it connects. 3. データベースが起動して実行中なのを確認するには、データベースに接続し、つながっているかを確認します。 @@ -165,15 +151,16 @@ MySQL の起動 .. Exit the MySQL shell to return to the shell on our machine. - MySQL シェルを終了し、マシン上のシェルに戻ります。 +4. MySQL シェルを終了し、マシン上のシェルに戻ります。 .. code-block:: bash - $ exit + mysql> exit - .. Hooray! We have our todos database and it’s ready for us to use! - やった！ ``todo`` データベースが手に入りましたので、使う準備が調いました！ +.. You now have a todos database and it’s ready for you to use. + +``todo`` データベースが手に入りましたので、いつでも使う準備が調いました。 .. Connect to MySQL .. _connet-to-mysql: @@ -181,13 +168,13 @@ MySQL の起動 MySQL に接続 ==================== -.. Now that we know MySQL is up and running, let’s use it! But, the question is... how? If we run another container on the same network, how do we find the container (remember each container has its own IP address)? +.. Now that you know MySQL is up and running, you can use it. But, how do you use it? If you run another container on the same network, how do you find the container? Remember that each container has its own IP address. - MySQL の起動と実行方法が分かりましたので、次は使いましょう！ ですが、問題があります……どうやって使うのでしょうか？ 同じネットワーク上で他のコンテナを実行したとして、どのようにして MySQL のコンテナを見つけられるのでしょうか？（各コンテナは自身の IP アドレスを持つのを思い出してください） +MySQL の起動と実行方法が分かりましたので、次は使います。しかし、どのように使うのでしょうか？ 同じネットワーク上に他のコンテナを実行したとして、どのようにして MySQL のコンテナを見つけられるのでしょうか？ 各コンテナは自身の IP アドレスを持つのを思い出してください。 -.. To figure it out, we’re going to make use of the nicolaka/netshoot container, which ships with a lot of tools that are useful for troubleshooting or debugging networking issues. +.. To answer the questions above and better understand container networking, you’re going to make use of the nicolaka/netshoot container, which ships with a lot of tools that are useful for troubleshooting or debugging networking issues. -答えを探すために、 `nicolaka/netshoot `_ コンテナを使います。これには、ネットワーク機能の問題に対するトラブルシューティング（問題解決）やデバッグ（修正）に便利なツールがたくさん入っています。 +この疑問に答え、コンテナのネットワーク機能について良く理解するため、 `nicolaka/netshoot `_ コンテナを使います。これにはネットワーク機能の問題に対するトラブルシューティング（問題解決）やデバッグ（修正）に役立つツールがたくさん入っています。 .. Start a new container using the nicolaka/netshoot image. Make sure to connect it to the same network. @@ -197,7 +184,7 @@ MySQL に接続 $ docker run -it --network todo-app nicolaka/netshoot -.. Inside the container, we’re going to use the dig command, which is a useful DNS tool. We’re going to look up the IP address for the hostname mysql. +.. Inside the container, you’re going to use the dig command, which is a useful DNS tool. You’re going to look up the IP address for the hostname mysql. 2. コンテナの中で、便利な DNS ツールの ``dig`` コマンドを使います。ホスト名 ``mysql`` の IP アドレスを調べましょう。 @@ -205,13 +192,13 @@ MySQL に接続 $ dig mysql - .. And you’ll get an output like this... + .. You should get output like the following. - そうすると、次のような出力があります。 + 次のような出力になります。 .. code-block:: bash - ; <<>> DiG 9.14.1 <<>> mysql + ; <<>> DiG 9.18.8 <<>> mysql ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32162 @@ -228,13 +215,13 @@ MySQL に接続 ;; WHEN: Tue Oct 01 23:47:24 UTC 2019 ;; MSG SIZE rcvd: 44 - .. In the “ANSWER SECTION”, you will see an A record for mysql that resolves to 172.23.0.2 (your IP address will most likely have a different value). While mysql isn’t normally a valid hostname, Docker was able to resolve it to the IP address of the container that had that network alias (remember the --network-alias flag we used earlier?). + .. In the “ANSWER SECTION”, you will see an A record for mysql that resolves to 172.23.0.2 (your IP address will most likely have a different value). While mysql isn’t normally a valid hostname, Docker was able to resolve it to the IP address of the container that had that network alias. Remember, you used the --network-alias earlier. - 「ANSWER SECTION」に、 ``mysql`` の ``A`` レコードがあり、 ``172.23.0.2`` （おそらく似たような値が表示されているでしょう）に解決されているのが分かります。 ``mysql`` は通常のホスト名としては有効ではありませんが、 Docker はコンテナの IP アドレスをネットワーク エイリアス（先ほど ``--network-alias`` フラグを使ったのを覚えていますか？）で調べられます。 + 「ANSWER SECTION」に、 ``mysql`` の ``A`` レコードがあり、 ``172.23.0.2`` （おそらく似たような値が表示されているでしょう）に解決されているのが分かります。 ``mysql`` は通常のホスト名としては有効ではありませんが、 Docker はコンテナの IP アドレスをネットワーク エイリアスで調べられます。先ほど ``--network-alias`` フラグを使ったのを思い出してください。 - .. What this means is... our app only simply needs to connect to a host named mysql and it’ll talk to the database! It doesn’t get much simpler than that! + .. What this means is that your app only simply needs to connect to a host named mysql and it’ll talk to the database. - これが意味するのは……アプリはシンプルにホスト名 ``mysql`` へ接続できればよいので、これでデータベースと通信できます！ これ以上にシンプルなことはありません！ + これが意味するのは、アプリはシンプルにホスト名 ``mysql`` へ接続できればよいので、これでデータベースと通信できます。 .. Run your app with MySQL .. run-your-app-with-mysql: @@ -244,7 +231,7 @@ MySQL とアプリを動かす .. The todo app supports the setting of a few environment variables to specify MySQL connection settings. They are: -todo アプリでは、 MySQL へ接続する設定を指定するため、いくつかの環境変数の設定をサポートしています。 +MySQL への接続する設定を指定するため、todo アプリは環境変数の設定をサポートしています。 .. MYSQL_HOST - the hostname for the running MySQL server @@ -258,74 +245,64 @@ todo アプリでは、 MySQL へ接続する設定を指定するため、い * ``MYSQL_DB`` - 接続先として使うデータベース .. - Setting Connection Settings via Env Vars While using env vars to set connection settings is generally ok for development, it is HIGHLY DISCOURAGED when running applications in production. Diogo Monica, the former lead of security at Docker, wrote a fantastic blog post explaining why. A more secure mechanism is to use the secret support provided by your container orchestration framework. In most cases, these secrets are mounted as files in the running container. You’ll see many apps (including the MySQL image and the todo app) also support env vars with a _FILE suffix to point to a file containing the variable. As an example, setting the MYSQL_PASSWORD_FILE var will cause the app to use the contents of the referenced file as the connection password. Docker doesn’t do anything to support these env vars. Your app will need to know to look for the variable and get the file contents. .. note:: - **環境変数を通した接続設定** - 環境変数を使った接続設定は、開発環境であれば通常は問題ありませんが、本番環境でアプリケーションの実行時は **極めて推奨されません** 。Docker の正式セキュリティ :ruby:`リード ` の Diogo Monica は、何故なのかを `素晴らしいブログ投稿を書き `_ 説明しています。 多くのセキュリティ機構は、コンテナ オーケストレーション フレームワークによって :ruby:`シークレット ` のサポートを提供しています。ほとんどの場合、これらシークレットは、実行中のコンテナ内にファイルとしてマウントされます。多くのアプリケーションは（ MySQL イメージと todo アプリも含みます）、変数を含むファイルを示すため、 ``_FILE`` が末尾に付く環境変数もサポートしています。 たとえば、 ``MYSQL_PASSWORD_FILE`` で設定した値は、アプリが接続用のパスワードとして、参照するファイルの内容を使いたいとします。ですが、Docker はこれらの環境変数を何らサポートしません。アプリ自身が変数を調べ、ファイル内容を取得する必要があります。 -.. With all of that explained, let’s start our dev-ready container! +.. You can now start your dev-ready container. -説明を全て終えたところで、開発に対応したコンテナを起動しましょう！ +それでは開発に対応したコンテナを起動します。 -.. Note: for MySQL versions 8.0 and higher, make sure to include the following commands in mysql. +.. Specify each of the environment variables above, as well as connect the container to your app network. Make sure that you are in the getting-started/app directory when you run this command. -1. **注意** : MySQL 8.0 以上では、 ``mysql`` の中で以下のコマンドを実行する必要があります。 +1. 先ほどの環境変数に加え、コンテナをアプリのネットワークに接続する指定をします。次のコマンドを実行する時は、 ``getting-started/app`` ディレクトリにいるのを確認します。 - .. code-block:: bash + **Mac / Linux** + + .. code-block:: bash + + $ docker run -dp 127.0.0.1:3000:3000 \ + -w /app -v "$(pwd):/app" \ + --network todo-app \ + -e MYSQL_HOST=mysql \ + -e MYSQL_USER=root \ + -e MYSQL_PASSWORD=secret \ + -e MYSQL_DB=todos \ + node:18-alpine \ + sh -c "yarn install && yarn run dev" - mysql> ALTER USER 'root' IDENTIFIED WITH mysql_native_password BY 'secret'; - mysql> flush privileges; + **Windows** -.. We’ll specify each of the environment variables above, as well as connect the container to our app network. + Windows では PowerShell 上コマンドを実行します。 -2. 先ほど環境変数をそれぞれ指定したのと同様に、コンテナをアプリのネットワークに接続します。 + .. code-block:: bash - .. code-block:: bash + $ docker run -dp 127.0.0.1:3000:3000 ` + -w /app -v "$(pwd):/app" ` + --network todo-app ` + -e MYSQL_HOST=mysql ` + -e MYSQL_USER=root ` + -e MYSQL_PASSWORD=secret ` + -e MYSQL_DB=todos ` + node:18-alpine ` + sh -c "yarn install && yarn run dev" - $ docker run -dp 3000:3000 \ - -w /app -v "$(pwd):/app" \ - --network todo-app \ - -e MYSQL_HOST=mysql \ - -e MYSQL_USER=root \ - -e MYSQL_PASSWORD=secret \ - -e MYSQL_DB=todos \ - node:18-alpine \ - sh -c "yarn install && yarn run dev" +.. If you look at the logs for the container (docker logs -f ), you should see a message similar to the following, which indicates it’s using the mysql database. - .. If you are using Windows then use this command in PowerShell. - - Windows を使っている場合は、PowerShell でこちらのコマンドを使います。 - - .. code-block:: bash - - PS> docker run -dp 3000:3000 ` - -w /app -v "$(pwd):/app" ` - --network todo-app ` - -e MYSQL_HOST=mysql ` - -e MYSQL_USER=root ` - -e MYSQL_PASSWORD=secret ` - -e MYSQL_DB=todos ` - node:18-alpine ` - sh -c "yarn install && yarn run dev" - -.. If we look at the logs for the container (docker logs ), we should see a message indicating it’s using the mysql database. - -3. コンテナのログを確認すると（ ``docker logs `` ）、mysql データベースの使用を示すメッセージが表示されるでしょう。 +2. コンテナのログを確認すると（ ``docker logs `` ）、次のような mysql データベースの使用を示すメッセージが表示されるでしょう。 .. code-block:: bash $ nodemon src/index.js - [nodemon] 1.19.2 + [nodemon] 2.0.20 [nodemon] to restart at any time, enter `rs` [nodemon] watching dir(s): *.* [nodemon] starting `node src/index.js` @@ -334,13 +311,14 @@ todo アプリでは、 MySQL へ接続する設定を指定するため、い .. Open the app in your browser and add a few items to your todo list. -4. ブラウザでアプリを開き、todo リストにいくつかのアイテムを追加します。 +3. ブラウザでアプリを開き、todo リストにいくつかのアイテムを追加します。 .. Connect to the mysql database and prove that the items are being written to the database. Remember, the password is secret. -5. mysql データベースに接続し、アイテムがデータベースに書き込まれているのを確認します。思い出してください、パスワードは **secret** です。 +4. mysql データベースに接続し、アイテムがデータベースに書き込まれているのを確認します。思い出してください、パスワードは ``secret`` です。 .. code-block:: bash + $ docker exec -it mysql -p todos .. And in the mysql shell, run the following: @@ -356,34 +334,36 @@ todo アプリでは、 MySQL へ接続する設定を指定するため、い | 2912a79e-8486-4bc3-a4c5-460793a575ab | Be awesome! | 0 | +--------------------------------------+--------------------+-----------+ - .. Obviously, your table will look different because it has your items. But, you should see them stored there! - おそらく、アイテムが異なるため、表の見た目は違うでしょう。ですが、そこに保管されているのが見えます！ - -.. If you take a quick look at the Docker Dashboard, you’ll see that we have two app containers running. But, there’s no real indication that they are grouped together in a single app. We’ll see how to make that better shortly! + .. Your table will look different because it has your items. But, you should see them stored there. -Docker ダッシュボードをさっと見ると、２つのアプリ用コンテナが動いているのが見えます。ですが、１つのアプリとして一緒のグループだとは分かりません。近いうちに改善する方法を見ていきます！ + おそらく、アイテムが異なるため、表の見た目は違うでしょう。ですが、そこに保管されているのが見えます。 -.. image:: ./images/dashboard-multi-container-app.png - :scale: 60% - :alt: ダッシュボードには、グループ化されていない２つのコンテナが表示 +.. Next steps +.. _part7-next-steps: -.. Recap -.. _part7-recap: - -まとめ -========== +次のステップ +==================== -.. At this point, we have an application that now stores its data in an external database running in a separate container. We learned a little bit about container networking and saw how service discovery can be performed using DNS. +.. At this point, you have an application that now stores its data in an external database running in a separate container. You learned a little bit about container networking and service discovery using DNS. -これで、別のコンテナで実行中の外部データベースに、アプリケーションは新しいデータを保管できるようになりました。コンテナのネットワーク機能を少々学び、それから、DNS を使った処理で、サービス ディスカバリをどのようにして行うのかを見てきました。 +これで、別のコンテナで実行中の外部データベースに、アプリケーションは新しいデータを保管できるようになりました。コンテナのネットワーク機能と DNS を使ったサービス ディスカバリを少々学びました。 .. But, there’s a good chance you are starting to feel a little overwhelmed with everything you need to do to start up this application. We have to create a network, start containers, specify all of the environment variables, expose ports, and more! That’s a lot to remember and it’s certainly making things harder to pass along to someone else. しかし、このアプリケーションを起動するための全てに対し、少々の圧倒を感じ始めているのではないでしょうか。行ったのは、ネットワークを作成し、コンテナを起動し、全ての環境変数を指定し、ポートを公開する等々です！ 覚えることが多すぎますし、誰かに正確に伝えるのは大変です。 -.. In the next section, we’ll talk about Docker Compose. With Docker Compose, we can share our application stacks in a much easier way and let others spin them up with a single (and simple) command! -次のセクションでは、 Docker Compose について説明します。 Docker Compose があれば、より簡単な方法でアプリケーション スタックを共有でき、他の人もコマンドを１つ（かつシンプルに）実行するだけで、アプリを速攻で立ち上げられます！ +.. In the next section, you’ll learn about Docker Compose. With Docker Compose, you can share your application stacks in a much easier way and let others spin them up with a single, simple command. + +次のセクションでは、 Docker Compose について説明します。 Docker Compose があれば、より簡単な方法でアプリケーション スタックを共有でき、他の人もコマンドを１つ、かつシンプルに実行するだけで、アプリを速攻で立ち上げられます。 + + +.. raw:: html + + + .. seealso:: diff --git a/get-started/08_using_compose.rst b/get-started/08_using_compose.rst index 0df51646d..da3411779 100644 --- a/get-started/08_using_compose.rst +++ b/get-started/08_using_compose.rst @@ -1,9 +1,9 @@ .. -*- coding: utf-8 -*- .. URL: https://docs.docker.com/get-started/08_using_compose/ - doc version: 20.10 + doc version: 24.0 https://github.com/docker/docker.github.io/blob/master/get-started/08_using_compose.md -.. check date: 2022/09/20 -.. Commits on Jun 28, 2022 fd9fe19061121287e75faebf973a3e1546f71190 +.. check date: 2023/07/17 +.. Commits on Jun 7, 2023 aee91fdaba9516d06db5b6b580e98f70a9a11c55 .. ----------------------------------------------------------------------------- .. Use Docker Compose @@ -21,11 +21,11 @@ Docker Compose を使う .. Docker Compose is a tool that was developed to help define and share multi-container applications. With Compose, we can create a YAML file to define the services and with a single command, can spin everything up or tear it all down. -:doc:`Docker Compose ` とは、複数コンテナのアプリケーションを定義・共有するために役立つように、開発されたツールです。Compose があれば、サービスを定義する YAML ファイルを作成し、コマンドを１つ実行するだけで、瞬時にすべて立ち上げたり、すべて解体できます。 +:doc:`Docker Compose ` とは、複数コンテナのアプリケーションを定義・共有するために役立つように、開発されたツールです。Compose があれば、サービスを定義する YAML ファイルを作成し、コマンドを１つ実行するだけで、瞬時にすべて立ち上げたり、すべてを削除したりできます。 .. The big advantage of using Compose is you can define your application stack in a file, keep it at the root of your project repo (it’s now version controlled), and easily enable someone else to contribute to your project. Someone would only need to clone your repo and start the compose app. In fact, you might see quite a few projects on GitHub/GitLab doing exactly this now. -Compose を使う「大きな」利点は、アプリケーション スタックをファイルに定義し、プロジェクト用リポジトリの一番上に置けるため（これでバージョン管理できます）、プロジェクトに貢献しようとしている誰もが簡単に利用できます。誰もが必要なのは、リポジトリをクローンし、それから :ruby:`構成された ` アプリを起動するだけです。実際、 GitHub や GitLab 上のプロジェクトで既に見かけているもしれません。 +Compose を使う「大きな」利点は、アプリケーション スタックをファイルに定義し、プロジェクト用リポジトリの一番上に置けるため（これでバージョン管理できます）、プロジェクトに貢献しようとしている誰もが簡単に利用できます。誰もが必要なのは、リポジトリを複製（クローン）し、それから :ruby:`構成された ` アプリを起動するだけです。実際、 GitHub や GitLab 上のプロジェクトで既に見かけているもしれません。 .. So, how do we get started? @@ -37,9 +37,13 @@ Compose を使う「大きな」利点は、アプリケーション スタッ Docker Compose のインストール ============================== -.. If you installed Docker Desktop/Toolbox for either Windows or Mac, you already have Docker Compose! Play-with-Docker instances already have Docker Compose installed as well. If you are on a Linux machine, you will need to install Docker Compose. +.. If you installed Docker Desktop for Windows, Mac, or Linux you already have Docker Compose! Play-with-Docker instances already have Docker Compose installed as well. -Window や Mac で、 Docker Desktop または Toolbox をインストール済みであれば、Docker Compose が入っています！ Play-wih-Docker インスタンスも、同様に Docker Compose がインストール済みです。Linux マシンを使う場合は、 :doc:`Docker Compose のインストール ` が必要です。 +Docker Desktop for Window や Mac や Linux をインストール済みであれば、Docker Compose が入っています！ Play-wih-Docker インスタンスも、同様に Docker Compose がインストール済みです。 + +.. Standalone installations of Docker Engine requires Docker Compose to be installed as a separate package, see Install the Compose plugin. + +Docker Engine を単体でインストールした場合は、別のパッケージとして Docker Compose のインストールが必要です。 :doc:`Compose プラグインのインストール ` を御覧ください。 .. After installation, you should be able to run the following and see version information. @@ -47,7 +51,7 @@ Window や Mac で、 Docker Desktop または Toolbox をインストール済 .. code-block:: bash - $ docker-compose version + $ docker compose version .. Create the Compose file .. _create-the-compose-file: @@ -55,26 +59,16 @@ Window や Mac で、 Docker Desktop または Toolbox をインストール済 Compose ファイルの作成 ============================== -.. At the root of the app project, create a file named docker-compose.yml. - -1. アプリプロジェクトのルートで、 ``docker-compose.yml`` という名前のファイルを作成します。 - -.. In the compose file, we’ll start off by defining the schema version. In most cases, it’s best to use the latest supported version. You can look at the Compose file reference for the current schema versions and the compatibility matrix. +.. At the root of the /getting-started/app folder, create a file named docker-compose.yml. -2. この compose ファイル内では、 :ruby:`スキーマ バージョン ` の定義から書き始めます。ほとんどの場合、サポートされている最新バージョンを使うのが一番良いでしょう。現時点のスキーマ バージョンと互換表については :doc:`Compose ファイル リファレンス ` をご覧ください。 +1. ``/getting-started/app`` フォルダのルートで ``docker-compose.yml`` という名前のファイルを作成します。 - .. code-block:: yaml - - version: "3.7" +.. In the compose file, we’ll start off by defining the list of services (or containers) we want to run as part of our application. -.. Next, we’ll define the list of services (or containers) we want to run as part of our application. - -3. 次に、アプリケーションの一部として実行したいサービス（またはコンテナ）一覧を定義します。 +2. compose ファイル内では、アプリケーションの一部として実行したいサービス（あるいはコンテナ）の一覧の定義から始めます。 .. code-block:: yaml - - version: "3.7" - + services: .. And now, we’ll start migrating a service at a time into the compose file. @@ -93,7 +87,7 @@ Compose ファイルの作成 .. code-block:: bash - $ docker run -dp 3000:3000 \ + $ docker run -dp 127.0.0.1:3000:3000 \ -w /app -v "$(pwd):/app" \ --network todo-app \ -e MYSQL_HOST=mysql \ @@ -103,28 +97,12 @@ Compose ファイルの作成 node:18-alpine \ sh -c "yarn install && yarn run dev" -PowerShell の場合は、こちらのコマンドを使っていました。 - -.. code-block:: bash - - PS> docker run -dp 3000:3000 ` - -w /app -v "$(pwd):/app" ` - --network todo-app ` - -e MYSQL_HOST=mysql ` - -e MYSQL_USER=root ` - -e MYSQL_PASSWORD=secret ` - -e MYSQL_DB=todos ` - node:18-alpine ` - sh -c "yarn install && yarn run dev" - .. First, let’s define the service entry and the image for the container. We can pick any name for the service. The name will automatically become a network alias, which will be useful when defining our MySQL service. -1. はじめに、サービスのエントリとコンテナ用のイメージを定義しましょう。サービスには様々な名前を選べます。この名前が、自動的にネットワーク エイリアスとなり、MySQL サービスの定義時に役立ちます。 +1. まずはじめに、サービスを記述し、コンテナ用のイメージを定義しましょう。サービスには様々な名前を選べます。この名前が、自動的にネットワーク エイリアス（別名）となり、MySQL サービスの定義時に役立ちます。 .. code-block:: yaml - version: "3.7" - services: app: image: node:18-alpine @@ -135,27 +113,23 @@ PowerShell の場合は、こちらのコマンドを使っていました。 .. code-block:: yaml - version: "3.7" - services: app: image: node:18-alpine command: sh -c "yarn install && yarn run dev" -.. Let’s migrate the -p 3000:3000 part of the command by defining the ports for the service. We will use the short syntax here, but there is also a more verbose long syntax available as well. +.. Let’s migrate the -p 127.0.0.1:3000:3000 part of the command by defining the ports for the service. We will use the short syntax here, but there is also a more verbose long syntax available as well. -3. コマンドの ``-p 3000:3000`` を移行するには、サービス用の ``ports`` を定義しましょう。ここでは :ref:`短い構文 ` を使いますが、より細かな :ref:`長い構文 ` も同様に使えます。 +3. コマンドの ``-p 127.0.0.1:3000:3000`` を移行するには、サービス用の ``ports`` を定義しましょう。ここでは :ref:`短い構文 ` を使いますが、より細かな :ref:`長い構文 ` も同様に使えます。 .. code-block:: bash - version: "3.7" - services: app: image: node:18-alpine command: sh -c "yarn install && yarn run dev" ports: - - 3000:3000 + - 127.0.0.1:3000:3000 .. Next, we’ll migrate both the working directory (-w /app) and the volume mapping (-v "$(pwd):/app") by using the working_dir and volumes definitions. Volumes also has a short and long syntax. @@ -165,42 +139,38 @@ PowerShell の場合は、こちらのコマンドを使っていました。 Docker Compose でボリューム定義を使う利点の１つは、現在のディレクトリからの相対パスが使える点です。 -.. code-block:: yaml - - version: "3.7" - - services: - app: - image: node:18-alpine - command: sh -c "yarn install && yarn run dev" - ports: - - 3000:3000 - working_dir: /app - volumes: - - ./:/app + .. code-block:: yaml + + services: + app: + image: node:18-alpine + command: sh -c "yarn install && yarn run dev" + ports: + - 127.0.0.1:3000:3000 + working_dir: /app + volumes: + - ./:/app .. Finally, we need to migrate the environment variable definitions using the environment key. 5. 最後は、 ``environment`` キーを使って環境変数の定義を移行する必要があります。 -.. code-block:: yaml - - version: "3.7" - - services: - app: - image: node:18-alpine - command: sh -c "yarn install && yarn run dev" - ports: - - 3000:3000 - working_dir: /app - volumes: - - ./:/app - environment: - MYSQL_HOST: mysql - MYSQL_USER: root - MYSQL_PASSWORD: secret - MYSQL_DB: todos + .. code-block:: yaml + + services: + app: + image: node:18-alpine + command: sh -c "yarn install && yarn run dev" + ports: + - 127.0.0.1:3000:3000 + working_dir: /app + volumes: + - ./:/app + environment: + MYSQL_HOST: mysql + MYSQL_USER: root + MYSQL_PASSWORD: secret + MYSQL_DB: todos .. Define the MySQL service .. _define-the-mysql-service: @@ -219,20 +189,7 @@ MySQL サービスの定義 -v todo-mysql-data:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD=secret \ -e MYSQL_DATABASE=todos \ - mysql:5.7 - -.. If you are using PowerShell then use this command: - -PowerShell の場合は、以下のコマンドを使います。 - -.. code-block:: bash - - PS> docker run -d ` - --network todo-app --network-alias mysql ` - -v todo-mysql-data:/var/lib/mysql ` - -e MYSQL_ROOT_PASSWORD=secret ` - -e MYSQL_DATABASE=todos ` - mysql:5.7 + mysql:8.0 .. We will first define the new service and name it mysql so it automatically gets the network alias. We’ll go ahead and specify the image to use as well. @@ -240,27 +197,23 @@ PowerShell の場合は、以下のコマンドを使います。 .. code-block:: bash - version: "3.7" - services: app: # The app service definition mysql: - image: mysql:5.7 + image: mysql:8.0 .. Next, we’ll define the volume mapping. When we ran the container with docker run, the named volume was created automatically. However, that doesn’t happen when running with Compose. We need to define the volume in the top-level volumes: section and then specify the mountpoint in the service config. By simply providing only the volume name, the default options are used. There are many more options available though. -2. 次に、ボリューム :ruby:`割り当て ` を定義します。 ``docker run`` でコンテナを実行した時は、 :ruby:`名前付きボリューム ` が自動的に作成されました。ですが、 Compose の実行時には、そのようになりません。トップレベルの ``volume:`` セクションでボリュームを定義する必要があり、さらに、サービス設定でもマウントポイントの指定が必要です。単にボリューム名だけを指定すると、デフォルトのオプションが使われます。他にもさらに :ruby:`多くの利用可能なオプション ` があります。 +2. 次に、ボリューム :ruby:`割り当て ` を定義します。 ``docker run`` でコンテナを実行した時は、 :ruby:`名前付きボリューム ` が自動的に作成されました。ですが、 Compose の実行時には、そのようになりません。トップレベルの ``volume:`` セクションでボリュームを定義する必要があり、さらに、サービス設定でもマウントポイントの指定が必要です。単にボリューム名だけを指定すると、デフォルトのオプションが使われます。他にも更に :ruby:`多くの利用可能なオプション ` があります。 .. code-block:: yalm - version: "3.7" - services: app: # The app service definition mysql: - image: mysql:5.7 + image: mysql:8.0 volumes: - todo-mysql-data:/var/lib/mysql @@ -273,13 +226,11 @@ PowerShell の場合は、以下のコマンドを使います。 .. code-block:: bash - version: "3.7" - services: app: # The app service definition mysql: - image: mysql:5.7 + image: mysql:8.0 volumes: - todo-mysql-data:/var/lib/mysql environment: @@ -295,14 +246,12 @@ PowerShell の場合は、以下のコマンドを使います。 .. code-block:: yaml - version: "3.7" - services: app: image: node:18-alpine command: sh -c "yarn install && yarn run dev" ports: - - 3000:3000 + - 127.0.0.1:3000:3000 working_dir: /app volumes: - ./:/app @@ -313,7 +262,7 @@ PowerShell の場合は、以下のコマンドを使います。 MYSQL_DB: todos mysql: - image: mysql:5.7 + image: mysql:8.0 volumes: - todo-mysql-data:/var/lib/mysql environment: @@ -338,17 +287,17 @@ PowerShell の場合は、以下のコマンドを使います。 1. まず、app や db のコピーが確実に停止しているのを確認します（ ``docker ps`` を実行してから、 ``docker rm -f `` を実行 ）。 -.. Start up the application stack using the docker-compose up command. We’ll add the -d flag to run everything in the background. +.. Start up the application stack using the docker compose up command. We’ll add the -d flag to run everything in the background. -2. アプリケーション スタックを起動するため、 ``docker-compose up`` コマンドを使います。バックグランドですべてを実行するため、 ``-d`` フラグを追加します。 +2. アプリケーション スタックを起動するため、 ``docker compose up`` コマンドを使います。バックグランドですべてを実行するため、 ``-d`` フラグを追加します。 .. code-block:: bash - $ docker-compose up -d + $ docker compose up -d .. When we run this, we should see output like this: - 実行すると、次のような出力が見えます。 + 実行したら、次のような出力が見えます。 .. code-block:: bash @@ -361,9 +310,9 @@ PowerShell の場合は、以下のコマンドを使います。 ボリュームと同時にネットワークも作成されたのが分かるでしょう！ デフォルトでは、 Docker Compose はアプリケーション スタックに指定したネットワークを自動的に作成します（そのため、 compose ファイル内にネットワークを定義しませんでした）。 -.. Let’s look at the logs using the docker-compose logs -f command. You’ll see the logs from each of the services interleaved into a single stream. This is incredibly useful when you want to watch for timing-related issues. The -f flag “follows” the log, so will give you live output as it’s generated. +.. Let’s look at the logs using the docker compose logs -f command. You’ll see the logs from each of the services interleaved into a single stream. This is incredibly useful when you want to watch for timing-related issues. The -f flag “follows” the log, so will give you live output as it’s generated. -3. ログを調べるため、 ``docker-compose logs -f`` コマンドを使います。１つの流れの中に、各サービスのログが相互に見えるでしょう。これは、タイミングに関連する問題を監視したい場合に、とても役立ちます。 ``-f`` フラグはログを「 :ruby:`フォロー ` 」（追跡）しますので、生成されたログはリアルタイムに表示され続けます。 +3. ログを調べるため、 ``docker compose logs -f`` コマンドを使います。１つの流れの中に、各サービスのログが相互に見えるでしょう。これは、タイミングに関連する問題を監視したい場合に、とても役立ちます。 ``-f`` フラグはログを「 :ruby:`フォロー ` 」（追跡）しますので、生成されたログはリアルタイムに表示され続けます。 .. If you have run the command already, you’ll see output that looks like this: @@ -372,22 +321,13 @@ PowerShell の場合は、以下のコマンドを使います。 .. code-block:: bash mysql_1 | 2019-10-03T03:07:16.083639Z 0 [Note] mysqld: ready for connections. - mysql_1 | Version: '5.7.27' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL) + mysql_1 | Version: '8.0.31' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL) app_1 | Connected to mysql db at host mysql app_1 | Listening on port 3000 - .. The service name is displayed at the beginning of the line (often colored) to help distinguish messages. If you want to view the logs for a specific service, you can add the service name to the end of the logs command (for example, docker-compose logs -f app). - - サービス名が行の始めに（たいてい色が付いて）表示されているため、メッセージの識別に役立ちます。特定のサービスに対するログを表示したい場合は、ログコマンドの最後にサービス名を追加できます（例： ``docker-compose logs -f app`` ）。 + .. The service name is displayed at the beginning of the line (often colored) to help distinguish messages. If you want to view the logs for a specific service, you can add the service name to the end of the logs command (for example, docker compose logs -f app). - .. Tip: Waiting for the DB before starting the app - When the app is starting up, it actually sits and waits for MySQL to be up and ready before trying to connect to it. Docker doesn’t have any built-in support to wait for another container to be fully up, running, and ready before starting another container. For Node-based projects, you can use the wait-port dependency. Similar projects exist for other languages/frameworks. - - .. tips:: - - **アプリが開始するまで DB は待機** - - アプリの起動時、MySQL が起動して接続する準備が調うまで、実際には待機します。Docker には、あるコンテナが起動する前に、他のコンテナが完全に起動し、実行中であり、待機中になるまで待つような機能を内蔵していません。Node ベースのプロジェクトでは、依存関係に `wait-port `_ が使えます。他の言語やフレームワークでも似たようなプロジェクトがあります。 + 行の始めにはサービス名が（大抵は色が付いて）表示されているため、メッセージの識別に役立ちます。特定のサービスに対するログを表示したい場合は、ログ表示コマンドの最後にサービス名を追加できます（例： ``docker compose logs -f app`` ）。 .. At this point, you should be able to open your app and see it running. And hey! We’re down to a single command! @@ -401,18 +341,16 @@ Docker ダッシュボードでアプリのスタックを表示 .. If we look at the Docker Dashboard, we’ll see that there is a group named app. This is the “project name” from Docker Compose and used to group the containers together. By default, the project name is simply the name of the directory that the docker-compose.yml was located in. -Docker ダッシュボードを見ると、 **app** という名前のグループが見えます。これは Docker Compose による「プロジェクト名」で、同じグループのコンテナに対して使われます。デフォルトでは、プロジェクト名はシンプルに ``docker-compose.yaml`` が置かれているディレクトリ名です。 +Docker ダッシュボードを見ますと、 **app** という名前のグループが見えます。これは Docker Compose による「プロジェクト名」で、同じグループのコンテナに対して使われます。デフォルトでは、プロジェクト名はシンプルに ``docker-compose.yaml`` が置かれているディレクトリ名です。 .. image:: ./images/dashboard-app-project-collapsed.png - :scale: 60% :alt: Docker ダッシュボードでのアプリのプロジェクト -.. If you twirl down the app, you will see the two containers we defined in the compose file. The names are also a little more descriptive, as they follow the pattern of -. So, it’s very easy to quickly see what container is our app and which container is the mysql database. +.. If you click the disclose arrow next to app, you will see the two containers we defined in the compose file. The names are also a little more descriptive, as they follow the pattern of -. So, it’s very easy to quickly see what container is our app and which container is the mysql database. -app の▶マークをクリックして展開すると、compose ファイルで定義した２つのコンテナが見えます。コンテナ名も説明的になり、 ``<サービス名>-<レプリカ数>`` のパターンに従います。そのため、どのコンテナがアプリで、どのコンテナが mysql データベースなのかを、素早く見つけるのが簡単になります。 +app の▶マークをクリックして展開しますと、compose ファイルで定義した２つのコンテナが見えます。コンテナ名も説明的になり、 ``<サービス名>-<レプリカ数>`` のパターンに従います。そのため、どのコンテナがアプリで、どのコンテナが mysql データベースなのかを、素早く見つけるのが簡単になります。 .. image:: ./images/dashboard-app-project-expanded.png - :scale: 60% :alt: Docker ダッシュボードでのアプリのプロジェクトを展開 @@ -422,9 +360,9 @@ app の▶マークをクリックして展開すると、compose ファイル 全てを削除 ========== -.. When you’re ready to tear it all down, simply run docker-compose down or hit the trash can on the Docker Dashboard for the entire app. The containers will stop and the network will be removed. +.. When you’re ready to tear it all down, simply run docker compose down or hit the trash can on the Docker Dashboard for the entire app. The containers will stop and the network will be removed. -すべてを解体（終了および削除）する準備が調えば、シンプルに ``docker-compose down`` を実行するか、Docker ダッシュボード上でアプリ全体のゴミ箱をクリックします。コンテナは停止され、ネットワークも削除されます。 +すべてを解体（終了および削除）する準備が調えば、シンプルに ``docker compose down`` を実行するか、Docker ダッシュボード上でアプリ全体のゴミ箱をクリックします。コンテナは停止され、ネットワークも削除されます。 .. Warning Removing Volumes @@ -435,27 +373,35 @@ app の▶マークをクリックして展開すると、compose ファイル **ボリュームの削除** - デフォルトでは、compose ファイルの名前付きボリュームは ``docker-compose down`` の実行では削除「されません」。ボリュームも削除したい場合は、 ``--volumes`` フラグも追加する必要があります。 + デフォルトでは、compose ファイルの名前付きボリュームは ``docker compose down`` の実行では削除「されません」。ボリュームも削除したい場合は、 ``--volumes`` フラグも追加する必要があります。 - Docker ダッシュボードではアプリのスタックを削除しても、ボリュームは削除「されません」。 + Docker ダッシュボードでは、アプリのスタックを削除してもボリュームは削除「されません」。 .. Once torn down, you can switch to another project, run docker-compose up and be ready to contribute to that project! It really doesn’t get much simpler than that! -解体が終われば、他のプロジェクトに切り替えができ、 ``docker-compose up`` を実行すると、そのプロジェクトに貢献する準備が調います！ これ以上、本当にシンプルなことはありません！ +解体が終われば、他のプロジェクトに切り替えができ、 ``docker compose up`` を実行したら、そのプロジェクトに貢献する準備が調います！ これ以上、本当にシンプルなことはありません！ -.. Recap -.. _part8-recap: +.. Next steps +.. _part8-next-steps: -まとめ -========== +次のステップ +==================== -.. In this section, we learned about Docker Compose and how it helps us dramatically simplify the defining and sharing of multi-service applications. We created a Compose file by translating the commands we were using into the appropriate compose format. +.. In this section, you learned about Docker Compose and how it helps you dramatically simplify the defining and sharing of multi-service applications. You created a Compose file by translating the commands you were using into the appropriate compose format. このセクションでは、 Docker Compose について学びました。 Docker Compose があれば、複数のサービスがあるアプリケーションの定義と共有が、劇的に簡単にするのに役立ちます。また、実行していたコマンドを適切な compose 形式へ変換し、 Compose ファイルを作成しました。 -.. At this point, we’re starting to wrap up the tutorial. However, there are a few best practices about image building we want to cover, as there is a big issue with the Dockerfile we’ve been using. So, let’s take a look! +.. At this point, you’re starting to wrap up the tutorial. However, there are a few best practices about image building you should cover, as there is a big issue with the Dockerfile you’ve been using. + +これで、チュートリアルの仕上げに入りましょう。その前に、イメージの構築に関するいくつかのベストプラクティスについて扱います。これまで使っていた Dockerfile には大きな問題があるためです。 + + +.. raw:: html + + -これで、チュートリアルの仕上げに入りましょう。その前に、イメージの構築に関するいくつかのベストプラクティスについて扱いたいと思います。これまで使っていた Dockerfile には大きな問題があるためです。それでは見てみましょう！ .. seealso:: diff --git a/get-started/09_image_best.rst b/get-started/09_image_best.rst index 289221c00..94e21585c 100644 --- a/get-started/09_image_best.rst +++ b/get-started/09_image_best.rst @@ -1,9 +1,9 @@ .. -*- coding: utf-8 -*- .. URL: https://docs.docker.com/get-started/09_image_best/ - doc version: 20.10 + doc version: 24.0 https://github.com/docker/docker.github.io/blob/master/get-started/09_image_best.md -.. check date: 2022/09/20 -.. Commits on Aug 17, 2022 f9ea6f2175eb7d693f2fbc8d32dcce4c82354958 +.. check date: 2023/07/17 +.. Commits on Feb 24, 2023 c0402932ca01a11eb663080191ba5f4b7e9194dd .. ----------------------------------------------------------------------------- .. Image-building best practices @@ -19,70 +19,6 @@ :depth: 2 :local: -.. Security scanning -.. _security-scanning: - -:ruby:`安全性の検査 ` -======================================== - -.. When you have built an image, it is a good practice to scan it for security vulnerabilities using the docker scan command. Docker has partnered with Snyk to provide the vulnerability scanning service. - -イメージの構築時、イメージのセキュリティ脆弱性を :ruby:`検査 ` するために ``docker scan`` コマンドを使うベストプラクティスがあります。Docker は脆弱性検査サービスを提供する `Snyk `_ と提携しています。 - -.. Note - You must be logged in to Docker Hub to scan your images. Run the command docker scan --login, and then scan your images using docker scan . - -.. note:: - - イメージの検査には Docker Hubへのログインが必要です。 ``docker scan --login`` コマンドを実行してから、 ``docker scan <イメージ名>`` を使ってイメージを検査します。 - -.. For example, to scan the getting-started image you created earlier in the tutorial, you can just type - -たとえば、これまでのチュートリアルの始めに作成した ``getting-started`` イメージを検査するには、次のコマンドを実行するだけです。 - -.. code-block:: dockerfile - - $ docker scan getting-started - -.. The scan uses a constantly updated database of vulnerabilities, so the output you see will vary as new vulnerabilities are discovered, but it might look something like this: - -検査には定期的に更新される脆弱性データベースを使いますので、様々な新しい脆弱性が発見されたと表示されるでしょう。表示されるのは、以下のようなものです。 - -.. code-block:: bash - - ✗ Low severity vulnerability found in freetype/freetype - Description: CVE-2020-15999 - Info: https://snyk.io/vuln/SNYK-ALPINE310-FREETYPE-1019641 - Introduced through: freetype/freetype@2.10.0-r0, gd/libgd@2.2.5-r2 - From: freetype/freetype@2.10.0-r0 - From: gd/libgd@2.2.5-r2 > freetype/freetype@2.10.0-r0 - Fixed in: 2.10.0-r1 - - ✗ Medium severity vulnerability found in libxml2/libxml2 - Description: Out-of-bounds Read - Info: https://snyk.io/vuln/SNYK-ALPINE310-LIBXML2-674791 - Introduced through: libxml2/libxml2@2.9.9-r3, libxslt/libxslt@1.1.33-r3, nginx-module-xslt/nginx-module-xslt@1.17.9-r1 - From: libxml2/libxml2@2.9.9-r3 - From: libxslt/libxslt@1.1.33-r3 > libxml2/libxml2@2.9.9-r3 - From: nginx-module-xslt/nginx-module-xslt@1.17.9-r1 > libxml2/libxml2@2.9.9-r3 - Fixed in: 2.9.9-r4 - -.. The output lists the type of vulnerability, a URL to learn more, and importantly which version of the relevant library fixes the vulnerability. - -出力の一覧には、脆弱性のタイプ、URL には詳細、そして重要な、脆弱性を修正するのに妥当なライブラリのバージョンがあります。 - -.. There are several other options, which you can read about in the docker scan documentation. - -他にもいくつかのオプションがあり、 :doc:`docker scan のドキュメント ` から確認できます。 - -.. As well as scanning your newly built image on the command line, you can also configure Docker Hub to scan all newly pushed images automatically, and you can then see the results in both Docker Hub and Docker Desktop. - -コマンドライン上で新しく構築するイメージを検査するのと同じように、 :doc:`Docker Hub の設定 ` でも、直近に送信したイメージすべてを自動的に検索できます。そして、その結果は Docker Hub と Docker Desktop の両方で確認できます。 - -.. image:: ./images/hvs.png - :scale: 60% - :alt: Dockre Hub 脆弱性検査 - .. Image layering .. _image-layering: @@ -158,8 +94,7 @@ .. code-block:: dockerfile # syntax=docker/dockerfile:1 - FROM node:12-alpine - RUN apk add --no-cache python2 g++ make + FROM node:18-alpine WORKDIR /app COPY . . RUN yarn install --production @@ -180,8 +115,7 @@ .. code-block:: dockerfile # syntax=docker/dockerfile:1 - FROM node:12-alpine - RUN apk add --no-cache python2 g++ make + FROM node:18-alpine WORKDIR /app COPY package.json yarn.lock ./ RUN yarn install --production @@ -198,7 +132,7 @@ .. .dockerignore files are an easy way to selectively copy only image relevant files. You can read more about this here. In this case, the node_modules folder should be omitted in the second COPY step because otherwise, it would possibly overwrite files which were created by the command in the RUN step. For further details on why this is recommended for Node.js applications and other best practices, have a look at their guide on Dockerizing a Node.js web app. - イメージに関係あるファイルだけ選んでコピーするには、 ``.dockerignore`` ファイルの利用が簡単です。 :ref:`こちら ` で詳しく読めます。今回の場合、２つめの ``COPY`` ステップで ``node_modulers`` フォルダは無視されます。これは、そうしなければ、 ``RUN`` ステップ中の命令で作成されるファイルにより、上書きされる可能性があるためです。どうして Node.js アプリケーションにこのような推奨をするのかや、他のベストプラクティスといった詳細は、Node.js のガイド `Dockerizing a Node.js web app `_ をご覧ください。 + イメージに関係あるファイルだけ選んでコピーするには、 ``.dockerignore`` ファイルの利用が簡単です。 :ref:`こちら ` で詳しく読めます。今回の場合、２つめの ``COPY`` ステップで ``node_modulers`` フォルダは無視されます。これは、そうしなければ、 ``RUN`` ステップ中の命令で作成されるファイルにより、上書きされる可能性があるためです。どうして Node.js アプリケーションにこのような推奨をするかや、他のベストプラクティスといった詳細は、Node.js のガイド `Dockerizing a Node.js web app `_ をご覧ください。 .. Build a new image using docker build. @@ -214,34 +148,23 @@ .. code-block:: bash - Sending build context to Docker daemon 219.1kB - Step 1/6 : FROM node:12-alpine - ---> b0dc3a5e5e9e - Step 2/6 : WORKDIR /app - ---> Using cache - ---> 9577ae713121 - Step 3/6 : COPY package.json yarn.lock ./ - ---> bd5306f49fc8 - Step 4/6 : RUN yarn install --production - ---> Running in d53a06c9e4c2 - yarn install v1.17.3 - [1/4] Resolving packages... - [2/4] Fetching packages... - info fsevents@1.2.9: The platform "linux" is incompatible with this module. - info "fsevents@1.2.9" is an optional dependency and failed compatibility check. Excluding it from installation. - [3/4] Linking dependencies... - [4/4] Building fresh packages... - Done in 10.89s. - Removing intermediate container d53a06c9e4c2 - ---> 4e68fbc2d704 - Step 5/6 : COPY . . - ---> a239a11f68d8 - Step 6/6 : CMD ["node", "src/index.js"] - ---> Running in 49999f68df8f - Removing intermediate container 49999f68df8f - ---> e709c03bc597 - Successfully built e709c03bc597 - Successfully tagged getting-started:latest + [+] Building 16.1s (10/10) FINISHED + => [internal] load build definition from Dockerfile + => => transferring dockerfile: 175B + => [internal] load .dockerignore + => => transferring context: 2B + => [internal] load metadata for docker.io/library/node:18-alpine + => [internal] load build context + => => transferring context: 53.37MB + => [1/5] FROM docker.io/library/node:18-alpine + => CACHED [2/5] WORKDIR /app + => [3/5] COPY package.json yarn.lock ./ + => [4/5] RUN yarn install --production + => [5/5] COPY . . + => exporting to image + => => exporting layers + => => writing image sha256:d6f819013566c54c50124ed94d5e66c452325327217f4f04399b45f94e37d25 + => => naming to docker.io/library/getting-started .. You’ll see that all layers were rebuilt. Perfectly fine since we changed the Dockerfile quite a bit. @@ -257,30 +180,27 @@ .. code-block:: bash - Sending build context to Docker daemon 219.1kB - Step 1/6 : FROM node:12-alpine - ---> b0dc3a5e5e9e - Step 2/6 : WORKDIR /app - ---> Using cache - ---> 9577ae713121 - Step 3/6 : COPY package.json yarn.lock ./ - ---> Using cache - ---> bd5306f49fc8 - Step 4/6 : RUN yarn install --production - ---> Using cache - ---> 4e68fbc2d704 - Step 5/6 : COPY . . - ---> cccde25a3d9a - Step 6/6 : CMD ["node", "src/index.js"] - ---> Running in 2be75662c150 - Removing intermediate container 2be75662c150 - ---> 458e5c6f080c - Successfully built 458e5c6f080c - Successfully tagged getting-started:latest - - .. First off, you should notice that the build was MUCH faster! And, you’ll see that steps 1-4 all have Using cache. So, hooray! We’re using the build cache. Pushing and pulling this image and updates to it will be much faster as well. Hooray! - - まず、かなり構築が早くなったのが分かるでしょう！ そして、ステップ１～４がすべて ``Using cache`` （キャッシュを使用中）になっています。やりました！ 構築キャッシュを使ったのです。このイメージを更新するための送信や取得が、より早くなりました！ やったね！ + [+] Building 1.2s (10/10) FINISHED + => [internal] load build definition from Dockerfile + => => transferring dockerfile: 37B + => [internal] load .dockerignore + => => transferring context: 2B + => [internal] load metadata for docker.io/library/node:18-alpine + => [internal] load build context + => => transferring context: 450.43kB + => [1/5] FROM docker.io/library/node:18-alpine + => CACHED [2/5] WORKDIR /app + => CACHED [3/5] COPY package.json yarn.lock ./ + => CACHED [4/5] RUN yarn install --production + => [5/5] COPY . . + => exporting to image + => => exporting layers + => => writing image sha256:91790c87bcb096a83c2bd4eb512bc8b134c757cda0bdee4038187f98148e2eda + => => naming to docker.io/library/getting-started + + .. First off, you should notice that the build was MUCH faster! And, you’ll see that several steps are using previously cached layers. So, hooray! We’re using the build cache. Pushing and pulling this image and updates to it will be much faster as well. Hooray! + + まず、かなり構築が早くなったのが分かるでしょう！ そして、複数のステップがすべて ``Using cache`` （キャッシュを使用中）になっています。やりました！ 構築キャッシュを使ったのです。このイメージを更新するための送信や取得が、より早くなりました！ やったね！ .. Multi-stage builds .. _get-started-multi-stage-build: @@ -336,7 +256,7 @@ React アプリケーションの構築時、 JS コード（通常は JSC）、 .. code-block:: dockerfile # syntax=docker/dockerfile:1 - FROM node:12 AS build + FROM node:18 AS build WORKDIR /app COPY package* yarn.lock ./ RUN yarn install @@ -347,20 +267,31 @@ React アプリケーションの構築時、 JS コード（通常は JSC）、 FROM nginx:alpine COPY --from=build /app/build /usr/share/nginx/html -.. Here, we are using a node:12 image to perform the build (maximizing layer caching) and then copying the output into an nginx container. Cool, huh? +.. Here, we are using a node:18 image to perform the build (maximizing layer caching) and then copying the output into an nginx container. Cool, huh? -ここでは、 ``node:12`` イメージを使って構築（レイヤーのキャッシュを最大限活用）を処理し、それから出力を nginx コンテナにコピーします。すごいでしょ？ +ここでは、 ``node:18`` イメージを使って構築（レイヤーのキャッシュを最大限活用）を処理し、それから出力を nginx コンテナにコピーします。すごいでしょ？ -.. Recap -.. _part9-recap: +.. Next steps +.. _part9-next-steps: -まとめ -========== +次のステップ +==================== .. By understanding a little bit about how images are structured, we can build images faster and ship fewer changes. Scanning images gives us confidence that the containers we are running and distributing are secure. Multi-stage builds also help us reduce overall image size and increase final container security by separating build-time dependencies from runtime dependencies. イメージがどのようにして構築されているかを少々学びましたので、ちょっとした変更でも、イメージを早く構築し、送り出せるようになります。イメージの検査によって、コンテナの実行や配布が安全だという信頼性をもたらします。また、マルチステージ ビルドによって、構築時の依存関係と実行時の依存関係を分けられるため、イメージ全体の容量を減らしたり、最終コンテナの安全を高められます。 +.. In the next section, you’ll learn about additional resources you can use to continue learning about containers + +次のセクションでは、コンテナを学び続けるのに役立つ追加リソースについて知りましょう。 + + +.. raw:: html + + + .. seealso:: diff --git a/get-started/11_what_next.rst b/get-started/11_what_next.rst index 12b6790c8..697ace1dd 100644 --- a/get-started/11_what_next.rst +++ b/get-started/11_what_next.rst @@ -1,9 +1,9 @@ .. -*- coding: utf-8 -*- .. URL: https://docs.docker.com/get-started/11_what_next/ - doc version: 20.10 + doc version: 24.0 https://github.com/docker/docker.github.io/blob/master/get-started/11_what_next.md -.. check date: 2022/09/20 -.. Commits on Feb 2, 2021 dc7352020eb1e19aa7319c895c01970dd011d0e0 +.. check date: 2023/07/17 +.. Commits on Mar 2, 2023 5f610a9961a77397bc756ed2a70e97f39215a3b8 .. ----------------------------------------------------------------------------- .. what next @@ -19,9 +19,9 @@ :depth: 2 :local: -.. Although we’re done with our workshop, there’s still a LOT more to learn about containers! We’re not going to go deep-dive here, but here are a few other areas to look at next! +.. Although we’re done with our get started guide, there’s still a LOT more to learn about containers! We’re not going to go deep-dive here, but here are a few other areas to look at next! -ワークショップが全て完了しましたが、コンテナについてはまだまだ学ぶことが多くあります！ ここでは深掘りをしませんでしたが、ここに次に見るべき場所があります。 +始め方のガイドは全て完了しましたが、コンテナについて学ぶことはまだまだ多くあります！ これまで深掘りをしませんでしたが、ここには次に見るべき場所があります。 .. Container orchestration .. _get-started-container-orchestration: @@ -31,7 +31,7 @@ .. Running containers in production is tough. You don’t want to log into a machine and simply run a docker run or docker-compose up. Why not? Well, what happens if the containers die? How do you scale across several machines? Container orchestration solves this problem. Tools like Kubernetes, Swarm, Nomad, and ECS all help solve this problem, all in slightly different ways. -本番環境でコンテナを実行するのは大変です。マシンへログインしたり、簡単な ``docker run`` や ``docker-compose up`` も実行したくはないでしょう。ちがいますか？ そうですね、もしコンテナが停止してしまったら？ 複数のマシンを横断してスケールするには？ この問題を解決するのが :ruby:`コンテナ オーケストレーション ` です。Kubernetes 、 Swarm 、 Nomad 、 ECS のようなツール、これらすべてが問題解決に役立ちますが、どれもわずかに手法が異なります。 +本番環境でコンテナを実行するのは大変です。マシンへログインしたり、簡単な ``docker run`` や ``docker compose up`` も実行したくはないでしょう。ちがいますか？ そうですね、もしコンテナが停止してしまったら？ 複数のマシンを横断してスケールするには？ この問題を解決するのが :ruby:`コンテナ オーケストレーション ` です。Kubernetes 、 Swarm 、 Nomad 、 ECS のようなツール、これらすべてが問題解決に役立ちますが、どれもわずかに手法が異なります。 .. The general idea is that you have “managers” who receive expected state. This state might be “I want to run two instances of my web app and expose port 80.” The managers then look at all of the machines in the cluster and delegate work to “worker” nodes. The managers watch for changes (such as a container quitting) and then work to make actual state reflect the expected state. @@ -51,6 +51,64 @@ CNCF とは、様々なオープンソース プロジェクトのためのベ ですから、コンテナの :ruby:`全体図 ` やクラウドネイティブ アプリケーション開発が初めてでも、歓迎します！ コミュニティとつながって、質問をして、学び続けましょう！ あなたがいるとワクワクします！ +.. Getting started video workshop +.. _getting-started-video-workshop: + +始め方ワークショップのビデオ +============================== + +.. We recommend the video workshop from DockerCon 2022. Watch the video below or use the links to open the video at a particular section. + +Dockercon 2022 のビデオワークショップを推奨します。以下の動画を再生するか、適切な動画セクションへのリンクを開きます。 + + +.. Docker overview and installation + Pull, run, and explore containers + Build a container image + Containerize an app + Connect a DB and set up a bind mount + Deploy a container to the cloud + +* `Docker 概要とインストール `_ +* `pull、run、コンテナを見渡す `_ +* `コンテナイメージ構築 `_ +* `アプリのコンテナ化 `_ +* `DB に接続し、バインド マウントの準備 `_ +* `コンテナをクラウドへデプロイ `_ + + +.. raw:: html + + +
 
 
  + + + +.. Creating a container from scratch +.. _creating-a-container-from-scratch: + +ゼロからコンテナを作成する +============================== + +.. If you’d like to see how containers are built from scratch, Liz Rice from Aqua Security has a fantastic talk in which she creates a container from scratch in Go. While the talk does not go into networking, using images for the filesystem, and other advanced topics, it gives a deep dive into how things are working. + +コンテナをゼロから作る方法に興味があれば、Aqua Security の Liz Rice による Go 言語でコンテナをゼロから作成する素敵なトークがあります。トークではネットワーク機能を扱いませんが、ファイルシステムのためにイメージを使い、他の高度なトピックも扱いますので、どのように動作しているかを深掘りするのに役立つでしょう。 + + +.. raw:: html + + +
 
 
  + + +.. Language-specific guides +言語別ガイド +==================== + +.. If you are looking for information on how to containerize an application using your favorite language, see Language-specific getting started guides. + +好きな言語を使ってアプリケーションをコンテナ化する情報をさがしている場合は、 :doc:`言語別導入ガイド ` を御覧ください。 + .. seealso:: What next diff --git a/get-started/hands-on-overview.rst b/get-started/hands-on-overview.rst new file mode 100644 index 000000000..6f36fb973 --- /dev/null +++ b/get-started/hands-on-overview.rst @@ -0,0 +1,39 @@ +.. -*- coding: utf-8 -*- +.. URL: https://docs.docker.com/get-started/hands-on-overview/ + doc version: 24.0 + https://github.com/docker/docs/blob/main/get-started/hands-on-overview.md +.. check date: 2023/07/18 +.. Commits on Mar 29, 2023 2bb51097108a4de4259828fc299d54b358a76baf +.. ----------------------------------------------------------------------------- + +.. Docker Desktop hands-on guides +.. _docker-desktop-hands-on-guides: + +======================================== +Docker Desktop ハンズオン ガイド +======================================== + +.. Use the resources in this section to learn Docker concepts by using Docker Desktop. + +このセクションの情報を活かし、 Docker の概念を Docker Desktop を使って学びましょう。 + + + +.. raw:: html + + +.. toctree:: + :maxdepth: 2 + + what-is-a-containe.rst + run-your-own-container.rst + run-docker-hub-images.rst + publish-your-own-image.rst + + +.. seealso:: + + Docker Desktop hands-on guides + https://docs.docker.com/get-started/hands-on-overview/ + + diff --git a/get-started/images/dashboard-two-containers.png b/get-started/images/dashboard-two-containers.png index baea0c5bc..193baa684 100644 Binary files a/get-started/images/dashboard-two-containers.png and b/get-started/images/dashboard-two-containers.png differ diff --git a/get-started/images/getting-started-container.png b/get-started/images/getting-started-container.png new file mode 100644 index 000000000..58b770091 Binary files /dev/null and b/get-started/images/getting-started-container.png differ diff --git a/get-started/images/getting-started-explore-container.gif b/get-started/images/getting-started-explore-container.gif new file mode 100644 index 000000000..bef3d01bb Binary files /dev/null and b/get-started/images/getting-started-explore-container.gif differ diff --git a/get-started/images/getting-started-frontend.png b/get-started/images/getting-started-frontend.png new file mode 100644 index 000000000..a3311defa Binary files /dev/null and b/get-started/images/getting-started-frontend.png differ diff --git a/get-started/images/getting-started-pull.gif b/get-started/images/getting-started-pull.gif new file mode 100644 index 000000000..333d165ed Binary files /dev/null and b/get-started/images/getting-started-pull.gif differ diff --git a/get-started/images/getting-started-push.gif b/get-started/images/getting-started-push.gif new file mode 100644 index 000000000..5f31fdcfd Binary files /dev/null and b/get-started/images/getting-started-push.gif differ diff --git a/get-started/images/getting-started-run-image.gif b/get-started/images/getting-started-run-image.gif new file mode 100644 index 000000000..4a4dddac1 Binary files /dev/null and b/get-started/images/getting-started-run-image.gif differ diff --git a/get-started/images/getting-started-run.gif b/get-started/images/getting-started-run.gif new file mode 100644 index 000000000..0321a7895 Binary files /dev/null and b/get-started/images/getting-started-run.gif differ diff --git a/get-started/images/getting-started-search.png b/get-started/images/getting-started-search.png new file mode 100644 index 000000000..12d104aec Binary files /dev/null and b/get-started/images/getting-started-search.png differ diff --git a/get-started/images/getting-started-sign-in.png b/get-started/images/getting-started-sign-in.png new file mode 100644 index 000000000..76f1347f0 Binary files /dev/null and b/get-started/images/getting-started-sign-in.png differ diff --git a/get-started/images/getting-started-stop.png b/get-started/images/getting-started-stop.png new file mode 100644 index 000000000..4ad50fd92 Binary files /dev/null and b/get-started/images/getting-started-stop.png differ diff --git a/get-started/images/getting-started-view.png b/get-started/images/getting-started-view.png new file mode 100644 index 000000000..fd3653073 Binary files /dev/null and b/get-started/images/getting-started-view.png differ diff --git a/get-started/index.rst b/get-started/index.rst deleted file mode 100755 index fe09b5438..000000000 --- a/get-started/index.rst +++ /dev/null @@ -1,236 +0,0 @@ -.. -*- coding: utf-8 -*- -.. URL: https://docs.docker.com/get-started/ - doc version: 20.10 - https://github.com/docker/docker.github.io/blob/master/get-started/index.md -.. check date: 2022/09/20 -.. Commits on Sep 4, 2022 079a03abf6bfc0fe162bc25191fef11c15371c65 -.. ----------------------------------------------------------------------------- - -.. Orientation and setup - -======================================== -概要説明とセットアップ -======================================== - -.. - Update to the Docker Desktop terms - Commercial use of Docker Desktop in larger enterprises (more than 250 employees OR more than $10 million USD in annual revenue) now requires a paid subscription. - -.. important:: **Docker Desktop の利用条件変更** - - 現在、大企業（従業員が 251 人以上、または、年間収入が 1,000 万米ドル以上 ）における Docker Desktop の商用利用には、有料サブスクリプション契約が必要です。 - -.. sidebar:: 目次 - - .. contents:: - :depth: 2 - :local: - -.. Welcome! We are excited that you want to learn Docker. - -ようこそ！ 皆さんが Docker を学ぼうとしており、私たちは嬉しく思います。 - -.. This page contains step-by-step instructions on how to get started with Docker. In this tutorial, you’ll learn how to: - -このページでは段階的な手順に従って、Docker の始め方を学びます。このチュートリアルで、以下の内容を学べます。 - -.. - Build and run an image as a container - Share images using Docker Hub - Deploy Docker applications using multiple containers with a database - Run applications using Docker Compose - -* コンテナとして、イメージの構築と実行 -* Docker Hub を使ったイメージ共有 -* データベースがある複数のコンテナを使う Docker アプリケーションをデプロイ -* Docker Compose を使ってアプリケーションを実行 - -.. In addition, you’ll also learn about the best practices for building images, including instructions on how to scan your images for security vulnerabilities. - -さらに、イメージ構築のベストプラクティスも学べます。これには、イメージのセキュリティ脆弱性を調べる（スキャンする）手順も含みます。 - -.. If you are looking for information on how to containerize an application using your favorite language, see Language-specific getting started guides. - -好きな言語を使用しているアプリケーションを、コンテナ化する方法の情報を探している場合は、 :doc:`言語ごとの導入ガイド ` をご覧ください。 - -.. We also recommend the video workshop from DockerCon 2022. Watch the video below or use the links to open the video at a particular section. - -.. We also recommend the video walkthrough from Dockercon 2020. - -また、 Dockercon 2022 の映像を見るのも推奨します。以下の動画を再生するか、適切な動画セクションへのリンクを開きます。 - -.. Docker overview and installation - Pull, run, and explore containers - Build a container image - Containerize an app - Connect a DB and set up a bind mount - Deploy a container to the cloud - -* `Docker 概要とインストール `_ -* `pull、run、コンテナを見渡す `_ -* `コンテナイメージ構築 `_ -* `アプリのコンテナ化 `_ -* `DB に接続し、バインド マウントの準備 `_ -* `コンテナをクラウドへデプロイ `_ - - -.. raw:: html - - - - -.. Download and install Docker -.. _download-and-install-docker: - -Docker のダウンロードとインストール -======================================== - -.. This tutorial assumes you have a current version of Docker installed on your machine. If you do not have Docker installed, choose your preferred operating system below to download Docker: - -このチュートリアルでは、みなさんのマシン上に Docker の現行バージョンをインストールしている状態を想定しています。もしも Docker をインストールしていなければ、以下から適切なオペレーティングシステムを選び、 Docker をダウンロードしてください。 - -* `Intel 製チップの Mac `_ -* `Apple 製チップの Mac `_ -* `Windows `_ -* :doc:`Linux ` - -.. For Docker Desktop installation instructions, see: - -Docker Desktop のインストール手順は、以下をご覧ください。 - -.. Install Docker Desktop on Mac - Install Docker Desktop on Windows - Install Docker Desktop on Linux - -* :doc:`Mac に Docker Desktop をインストール ` -* :doc:`Windows に Docker Desktop をインストール ` -* :doc:`Linux に Docker Desktop をインストール ` - - -.. Start the tutorial -.. _start-the-tutorial: - -チュートリアルの開始 -==================== - -.. If you’ve already run the command to get started with the tutorial, congratulations! If not, open a command prompt or bash window, and run the command: - -もう既にチュートリアルでコマンドを実行していたら、おめでとう！ そうでなければ、コマンドプロンプトか bash ウインドウを開き、コマンドを実行しましょう。 - -.. code-block:: bash - - $ docker run -d -p 80:80 docker/getting-started - -.. You’ll notice a few flags being used. Here’s some more info on them: - -いくつかのフラグが使われているのに気づくでしょう。それらの詳しい情報は、こちらです。 - -.. - -d - Run the container in detached mode (in the background) - -p 80:80 - Map port 80 of the host to port 80 in the container. To access the tutorial, open a web browser and navigate to http://localhost:80. If you already have a service listening on port 80 on your host machine, you can specify another port. For example, specify -p 3000:80 and then access the tutorial via a web browser at http://localhost:3000. - docker/getting-started - Specify the image to use - -* ``-d`` - コンテナを :ruby:`デタッチド・モード ` （バックグランドの処理）で :ruby:`実行 ` -* ``-p 80:80`` - コンテナ内のポート 80 に対し、ホスト上のポート 80 を割り当てる（ :ruby:`マップ ` する）。チュートリアルにアクセスするにはウェブブラウザを開き、 ``http://localhost:80`` に移動する。ホストマシン上で既にサービスがポート 80 をリッスンしている場合、他のポートの指定が必要です。たとえば、 ``-p 3000:80`` を指定すると、チュートリアルにアクセスするにはブラウザで ``http://localhost:3000`` を通します。 -* ``docker/getting-started`` - 使用するイメージの指定 - -.. Tip - You can combine single character flags to shorten the full command. As an example, the command above could be written as: - -.. tip:: - - コマンド全体を短くするために、1文字のフラグは連結できます。例として、先ほどのコマンドは、このように書き換えられます。 - - .. code-block:: bash - - $ docker run -dp 80:80 docker/getting-started - -.. The Docker Dashboard -.. _the-docker-dashboard: - -Docker ダッシュボード -============================== - -.. Before going too far, we want to highlight the Docker Dashboard, which gives you a quick view of the containers running on your machine. The Docker Dashboard is available for Mac, Windows, and Linux. It gives you quick access to container logs, lets you get a shell inside the container, and lets you easily manage container lifecycles (stop, remove, etc.). - -遠くへと進む前に、 Docker ダッシュボードに焦点をあて、マシン上でのコンテナ実行について素早く目を通したいと思います。Docker ダッシュボードは Mac 、 Windows 、 Linux で利用できます。これを使えばコンテナのログに素早くアクセスでき、コンテナ内でシェルが操作でき、コンテナのライフサイクル（停止、削除、等）の管理が簡単になります。 - -.. To access the dashboard, follow the instructions in the Docker Desktop manual. If you open the dashboard now, you will see this tutorial running! The container name (jolly_bouman below) is a randomly created name. So, you’ll most likely have a different name. - -ダッシュボードにアクセスするには、 :doc:`Docker デスクトップのマニュアル ` にある手順に従ってください。ダッシュボードを開いたら、このチュートリアルで実行しているように見えるでしょう。コンテナ名（ ``jolly_bouman`` ）はランダムに作成されます。そのため、以下の画像とは名前が異なるでしょう。 - -.. image:: ./images/tutorial-in-dashboard.png - :scale: 60% - -.. What is a container? -.. _what-is-a-container: - -コンテナとは何？ -==================== - -.. Now that you’ve run a container, what is a container? Simply put, a container is a sandboxed process on your machine that is isolated from all other processes on the host machine. That isolation leverages kernel namespaces and cgroups, features that have been in Linux for a long time. Docker has worked to make these capabilities approachable and easy to use. To summarize, a container: - -それでは、コンテナを実行するのですが、コンテナとは何でしょうか？ 簡単に言えば、コンテナとはマシン上でサンドボックス化したプロセスであり、ホストマシン上にある他すべてのプロセスから :ruby:`隔離 ` されています。この隔離とは `カーネルの名前空間と cgroup `_ の活用であり、長らく Linux に存在する機能です。Docker はこれらの :ruby:`能力 ` を、分かりやすく簡単に使えるようにします。まとめると、コンテナとは： - -.. is a runnable instance of an image. You can create, start, stop, move, or delete a container using the DockerAPI or CLI. - can be run on local machines, virtual machines or deployed to the cloud. - is portable (can be run on any OS) - is isolated from other containers and runs its own software, binaries, and configurations. - -* 実行可能なイメージの :ruby:`実体 ` 。Docker API や CLI を使ってコンテナの作成、開始、停止、移動、削除ができます。 -* ローカルマシン上や、仮想マシン上えも実行でき、クラウドにもデプロイできます。 -* :ruby:`可搬性 ` があります（多くの OS で実行可能です）。 -* コンテナはお互いに隔離され、それぞれが自身のソフトウェア、バイナリ、設定を使って実行します。 - -.. note:: **ゼロからコンテナを作成するには** - - コンテナをゼロから構築する方法を知りたければ、 Aqua Security の Liz Rice による素晴らしいトークがあります。彼女は go でゼロからコンテナを作成します。トークではネットワーク機能や、ファイルシステム用のイメージの使い方、その他の高度なトピックを扱いません。ですが、コンテナの作り方について、非常に素晴らしく深く掘り下げています。 - - .. image:: ./images/get-started2.png - :scale: 60% - :target: https://www.youtube.com/watch?v=8fi7uSYlOdc&t=1s - -.. What is a container image? -.. _what-is-a-container-image: - -コンテナ・イメージとは何でしょうか？ -======================================== - -.. When running a container, it uses an isolated filesystem. This custom filesystem is provided by a container image. Since the image contains the container’s filesystem, it must contain everything needed to run an application - all dependencies, configurations, scripts, binaries, etc. The image also contains other configuration for the container, such as environment variables, a default command to run, and other metadata. - -コンテナの実行時、コンテナは隔離されたファイルシステムを使います。この特別なファイルシステムは **コンテナ・イメージ** によって提供されます。イメージにはコンテナのファイルシステムも含みますので、アプリケーションを実行するために必要な全てを含む必要があります。たとえば、全ての依存関係、設定、スクリプト、バイナリ等です。また、このイメージには環境変数、デフォルトで実行するコマンド、メタデータのような、他の設定も含みます。 - -.. We’ll dive deeper into images later on, covering topics such as layering, best practices, and more. - -イメージに関する深掘りは、後のレイヤ化、ベストプラクティス等のトピックで扱います。 - -.. Info - If you’re familiar with chroot, think of a container as an extended version of chroot. The filesystem is simply coming from the image. But, a container adds additional isolation not available when simply using chroot. - -.. info:: - - ``chroot`` を熟知していれば、コンテナとは ``chroot`` の拡張バージョンと考えてみましょう。ファイルシステムとは、単にイメージから由来します。ですが、コンテナの場合は、単純に chroot の使用ではできない付加的な隔離を追加します。 - -.. CLI references - -CLI リファレンス -==================== - -.. Refer to the following topics for further documentation on all CLI commands used in this article: - -この節で扱う全ての CLI コマンドに関する詳しいドキュメントは、以下のトピックをご覧ください。 - -* :doc:`docker verion ` -* :doc:`docker run ` -* :doc:`docker image ` -* :doc:`docker container ` - - - - -.. seealso:: - - Orientation and setup - https://docs.docker.com/get-started/ - - diff --git a/get-started/overview.rst b/get-started/overview.rst index b989317ce..18923ef9b 100644 --- a/get-started/overview.rst +++ b/get-started/overview.rst @@ -1,9 +1,9 @@ .. -*- coding: utf-8 -*- .. URL: https://docs.docker.com/get-started/overview/ + doc version: 24.0 .. SOURCE: https://github.com/docker/docker.github.io/blob/master/get-started/overview.md -.. check date: 2022/09/20 -.. Commits on Aug 12, 2022 3393f95fa8ce5efb999f06aa6d1392e0f4557a9c -.. Commits on Feb 7, 2022 4fd778a3167596ff720cae99840d17a4ff604c8e +.. check date: 2023/07/15 +.. Commits on Mar 2, 2023 75a2468ce346d75a5ca380809e00219197d317f8 .. ----------------------------------------------------------------------------- .. Docker Overview @@ -103,9 +103,9 @@ Docker の可搬性と軽量な特性は、以下のようなことを容易に 同じハードウェア上で負荷の高い処理を実行 ---------------------------------------- -.. Docker is lightweight and fast. It provides a viable, cost-effective alternative to hypervisor-based virtual machines, so you can use more of your compute capacity to achieve your business goals. Docker is perfect for high density environments and for small and medium deployments where you need to do more with fewer resources. +.. Docker is lightweight and fast. It provides a viable, cost-effective alternative to hypervisor-based virtual machines, so you can use more of your server capacity to achieve your business goals. Docker is perfect for high density environments and for small and medium deployments where you need to do more with fewer resources. -Docker は軽量かつ高速です。ハイパーバイザ・ベースの仮想マシンに取って変わる、実用的で費用対効果の高いものです。したがってコンピュータ性能をフルに活用してビジネス目標を達成できます。Docker は高度に処理集中する環境に適しており、さらには中小規模の、より少ないリソースの中でのシステム構築にも適しています。 +Docker は軽量かつ高速です。ハイパーバイザ・ベースの仮想マシンに取って変わる、実用的で費用対効果の高いものです。したがってサーバ性能をフルに活用してビジネス目標を達成できます。Docker は高度に処理集中する環境に適しており、さらには中小規模の、より少ないリソースの中でのシステム構築にも適しています。 .. Docker architecture .. _docker-architecture: @@ -117,8 +117,7 @@ Docker のアーキテクチャ Docker はクライアント・サーバ型のアーキテクチャを採用しています。Docker *クライアント* は Docker デーモンに処理を依頼します。このデーモンは、Docker コンテナの構築、実行、配布という複雑な仕事をこなします。Docker クライアントとデーモンは同一システム上で動かすことも *可能* ですが、別のシステム上であっても、Docker クライアントからリモートにある Docker デーモンへのアクセスが可能です。Docker クライアントとデーモンの間の通信には REST API が利用され、UNIX ソケットまたはネット・ワークインターフェイスを介して行われます。他にも Docker クライアントには Docker Compose があり、コンテナ一式で構成されるアプリケーションを操作します。 -.. image:: /engine/article-img/architecture.png - :scale: 60% +.. image:: /assets/images/architecture.png :alt: Docker アーキテクチャ図 .. The Docker daemon @@ -268,7 +267,7 @@ Docker は `Go プログラミング言語 `_ で書かれ Get hands-on experience with the Getting started with Docker tutorial. * :doc:`/get-docker` を読む -* ハンズオンで :doc:`Docker を使い始める ` ためのチュートリアルを試す +* ハンズオンで :doc:`Docker を使い始める ` ためのチュートリアルを試す .. seealso:: diff --git a/get-started/publish-your-own-image.rst b/get-started/publish-your-own-image.rst new file mode 100644 index 000000000..7addca03c --- /dev/null +++ b/get-started/publish-your-own-image.rst @@ -0,0 +1,120 @@ +.. -*- coding: utf-8 -*- +.. URL: https://docs.docker.com/get-started/publish-your-own-image/ + doc version: 24.0 + https://github.com/docker/docs/blob/main/get-started/publish-your-own-image.md +.. check date: 2023/07/20 +.. Commits on Mar 29, 2023 2bb51097108a4de4259828fc299d54b358a76baf +.. ----------------------------------------------------------------------------- + +.. Run Docker Hub images +.. _run-docker-hub-images: + +======================================== +Docker Hub イメージの実行 +======================================== + +.. sidebar:: 目次 + + .. contents:: + :depth: 2 + :local: + +.. Follow this guide to learn how you can share your packaged application in an image using Docker Hub. + +以下のガイドでは、イメージ内にパッケージ化したアプリケーションを、Docker Hub を使って共有できる方法を学びます。 + +.. Step 1: Get an image +.. _Step-1-Get-an-image: + +ステップ1：イメージの取得 +============================== + +.. Before you publish your image, you need an image to publish. For this guide, use the welcome-to-docker image. + +イメージを公開する前に、公開するイメージが必要です。このガイドでは ``welcome-to-docker`` イメージを使います。 + +.. To get the image, use Docker Desktop to search for the welcome-to-docker image, and then select Pull. + +イメージを取得するには、 Docker Desktop で ``welcome-to-docker`` イメージを検索し、それから **Pull** を選びます。 + +.. image:: ./images/getting-started-pull.gif + :width: 100% + :alt: イメージの取得 + +.. Step 2: Sign in to Docker +.. _step-2-sign-in-to-docker: + +ステップ2：Docker にサインイン +============================== + +.. To publish images publicly on Docker Hub, you first need an account. Select Sign in on the top-right of Docker Desktop to either sign in or create a new account on Docker Hub. + +Docker Hub にイメージを公開するには、アカウントが必要です。Docker Desktop の右上にある **Sign in** を選び、Docker Hub にサインインするか新しいアカウントを作成します。 + +.. image:: ./images/getting-started-sign-in.png + :width: 100% + :alt: Docker にサインイン + + +.. Step 3: Rename your image +.. _Step-3-Rename-your-image: + +ステップ3：イメージの名前変更 +============================== + +.. Before you can publish your image to Docker Hub, you need to rename it so that Docker Hub knows that the image is yours. Run the following docker tag command in your terminal to rename your image. Replace YOUR-USERNAME with your Docker ID. + +イメージを Docker Hub に送信できるようにする前に、イメージの名前を変更する必要があります。これは Docker Hub にイメージが自分のものだと識別させるためです。ターミナル内で以下の ``docker tag`` コマンドを実行し、イメージの名前を変更します。 ``YOUR-USERNAME`` は自分の Docker ID に置き換えてください。 + +.. code-block:: bash + + $ docker tag docker/welcome-to-docker YOUR-USERNAME/welcome-to-docker + +.. Step 4: Push your image to Docker Hub +.. _Step-4-Push-your-image-to-Docker-Hub: + +ステップ4：Docker Hub にイメージを送信 +======================================== + +.. In Docker Desktop, go to the Images tab and find your image. In the Actions column, select the Show image actions icon and then select Push to Hub. Your image uploads to Docker Hub and is publicly available for anyone to use. + +Docker Desktop 上で **images** タブに移動して、自分のイメージを見つけます。 **Actions** 列で、**Show images action** アイコン（⋮）を選び、 **Push to Hub** を選びます。イメージが Docker Hub にアップロードされれば、誰でも使えるように公開状態となります。 + +.. image:: ./images/getting-started-push.gif + :width: 100% + :alt: イメージを Docker Hub に送信 + +.. Step 5: Verify the image is on Docker Hub +.. _step-5-verify-the-image-is-on-docker-hub: + +ステップ5：Docker Hub 上でイメージを確認 +======================================= + +.. That’s it! Your image is now shared on Docker Hub. In your browser, go to Docker Hub and verify that you see the welcome-to-docker repository. + +以上です！ イメージは Docker Hub 上で共有されています。ブラウザで `Docker Hub `_ を開き、 ``welcome-to-docker`` リポジトリが見えるのを確認します。 + + +.. What’s next + +次は何をしますか +============================== + +.. In this guide you learned how to publish your own image to Docker Hub. Continue to the following language-specific guides to learn more about creating images for applications in other languages: + +このガイドでは Docker Hub に自分のイメージを公開する方法を学びました。他の言語によるアプリケーションのイメージ構築について学ぶには、以下の言語別ガイドに進んでください。 + +* :doc:`Node.js ` +* :doc:`Python ` +* :doc:`Go ` +* :doc:`Java ` +* :doc:`C# (.NET) ` + + +.. seealso:: + + Publish your images + https://docs.docker.com/get-started/publish-your-own-image/ + + + diff --git a/get-started/run-docker-hub-images.rst b/get-started/run-docker-hub-images.rst new file mode 100644 index 000000000..e46055256 --- /dev/null +++ b/get-started/run-docker-hub-images.rst @@ -0,0 +1,92 @@ +.. -*- coding: utf-8 -*- +.. URL: https://docs.docker.com/get-started/run-docker-hub-images/ + doc version: 24.0 + https://github.com/docker/docs/blob/main/get-started/run-docker-hub-images.md +.. check date: 2023/07/20 +.. Commits on Mar 29, 2023 2bb51097108a4de4259828fc299d54b358a76baf +.. ----------------------------------------------------------------------------- + +.. Run Docker Hub images +.. _run-docker-hub-images: + +======================================== +Docker Hub イメージの実行 +======================================== + +.. sidebar:: 目次 + + .. contents:: + :depth: 2 + :local: + +.. You can share and store images in Docker Hub (http://hub.docker.com). Docker hub has over 100,000 images created by developers that you can run locally. You can search for Docker Hub images and run them directly from Docker Desktop. + +Docker Hub （ https://hub.docker.com ）でイメージの共有や保管ができます。Docker Hub では開発者によって作られた 100,000 以上のイメージがあり、それらをローカルで動かせます。Docker Desktop から直接 Docker Hub のイメージを探したり実行したりできます。 + +.. Step 1: Search for the image +.. _step-1-search-for-the-image: + +ステップ1：イメージの検索 +============================== + +.. You can search for Docker Hub images on Docker Desktop. Use the search bar, or use the shortcut ⌘K on Mac or Ctrl + K on Windows. In the search bar, specify welcome-to-docker to find the docker/welcome-to-docker image used in this guide. + +Docker Desktop 上で Docker Hub のイメージを検索できます。検索バーを使うか、Mac os ではショートカット ⌘K または Windows ではショートカット Ctrl + K を使います。このガイドで使うイメージ ``docker/welcome-to-docker`` を探すには、検索バーで ``welcome-to-docker`` と入力します。 + +.. image:: ./images/getting-started-search.png + :width: 100% + :alt: Docker Desktop で welcome-to-docker イメージを検索 + +.. Step 2: Run the image +.. _step-2-Run-the-image: + +ステップ2：イメージの実行 +============================== + +.. To run the docker/welcome-to-docker image, select Run. When the Optional settings appear, specify the Host port number 8090 and then select Run. + +``docker/welcome-to-docker`` イメージを実行するには、 **Run** を選びます。 **Optional settings** が表示されたら、 **Host port** 番号を ``8090`` にしてから **Run** を選びます。 + +.. image:: ./images/getting-started-run.gif + :width: 100% + :alt: Docker Desktop でイメージを実行 + +.. note:: + + .. Many images hosted on Docker Hub have a description that highlights what settings must be set in order to run them. You can read the description for the image on Docker Hub by selecting View on Hub or by searching for the image directly on https://hub.docker.com. + + Docker Hub 上にあるイメージの多くには、イメージを実行するために必要となる主な設定についての説明があります。 Docker Hub 上でイメージの説明を読むには、 **View on Hub** を選ぶか、 https://hub.docker.com 上で直接イメージを検索します。 + +.. Step 3: Explore the container +.. _Step-3-Explore-the-container: + +ステップ3：コンテナの調査 +============================== + +.. That’s it! The container is ready to use. Go to the Containers tab in Docker Desktop to view the container. + +これで終わりです！ コンテナを使う準備が調いました。Docker Desktop の **Containers** タブに移動し、コンテナを表示しましょう。 + +.. image:: ./images/getting-started-view.png + :width: 100% + :alt: Docker Desktop の Containers タブで表示 + +.. What’s next + +次は何をしますか +==================== + +.. In this guide, you ran someone else’s image from Docker Hub. Continue to the next guide to learn how you can publish your own image to Docker Hub. + +このガイドでは、Docker Hub 上にある他人のイメージを実行しました。続いてのガイドでは、自分のイメージを Docker Hub に送信する方法を学びます。 + +* :doc:`イメージの公開 ` + + +.. seealso:: + + Run Docker Hub images + https://docs.docker.com/get-started/run-docker-hub-images/ + + + diff --git a/get-started/run-your-own-container.rst b/get-started/run-your-own-container.rst new file mode 100644 index 000000000..2d6fec395 --- /dev/null +++ b/get-started/run-your-own-container.rst @@ -0,0 +1,164 @@ +.. -*- coding: utf-8 -*- +.. URL: https://docs.docker.com/get-started/run-your-own-container/ + doc version: 24.0 + https://github.com/docker/docs/blob/main/get-started/run-your-own-container.md +.. check date: 2023/07/19 +.. Commits on Apr 19, 2023 8515030b54e9857e52b45dba9064c50a40fa9226 +.. ----------------------------------------------------------------------------- + +.. How do I run a container? +.. _how-do-i-run-a-container: + +======================================== +どのようにしてコンテナを動かせますか？ +======================================== + +.. sidebar:: 目次 + + .. contents:: + :depth: 2 + :local: + + +.. Follow this guide to learn the basic steps of running a container from scratch. This guide uses a sample Node.js application, but it’s not necessary to know Node.js. + +ゼロからコンテナを実行するための基本な手順を学ぶには、こちらのガイドを読み進めてください。このガイドではサンプルとして Node.js アプリケーションを使いますが、 Node.js の知識は不要です。 + +.. Step 1: Get the sample application +.. _step-1-get-the-sample-application: + +ステップ1：サンプルアプリケーションの入手 +=================================================== + +.. If you have git, you can clone the repository for the sample application. Otherwise, you can download the sample application. Choose one of the following options. + +git を持っていれば、サンプルアプリケーション用のリポジトリを複製（クローン）できます。あるいは、サンプルアプリケーションのダウンロードもできます。以下どちらかを選んでください。 + +**git で複製** + + .. Use the following command in a terminal to clone the sample application repository. + 以下のコマンドをターミナル内で実行し、サンプルアプリケーションのリポジトリを複製します。 + + .. code-block:: bash + + $ git clone https://github.com/docker/welcome-to-docker + +**ダウンロード** + + .. If you don’t have git, download the source and extract it. + git を持っていなければ、ソースをダウンロードして展開します。 + + * `ソースのダウンロード `_ + +.. Step 2: Explore the Dockerfile +.. _step-2-explore-the-dockerfile: + +ステップ2：Dockerfile を調べる +============================== + +.. To run your code in a container, the most fundamental thing you need is a Dockerfile. A Dockerfile describes what goes into a container. Open the sample application in your IDE and then open the Dockerfile to explore its contents. Note that this project already has a Dockerfile, but for your own projects you need to create a Dockerfile. A Dockerfile is simply a text file named Dockerfile with no file extension. + +コンテナ内でコードを実行するにあたり、最も基本となるのが Dockerfile です。Dockerfile はコンテナ内に何を入れるか記述します。統合開発環境でサンプルアプリケーションを開き、 ``Dockerfile`` を開き、その内容を調べます。注意点として、このプロジェクトでは既に Dockerfile がありますが、自分自身のプロジェクトでは、自ら Dockerfile を作成する必要があります。Dockerfile は拡張子を持たない ``Dockerfile`` という名前の、シンプルなテキストファイルです。 + + +.. Step 3: Build your first image +.. _step-3-build-your-first-image: + +ステップ3：初めてのイメージを構築 +======================================== + +.. An image is like a static version of a container. You always need an image to run a container. Once you have a Dockerfile in your repository, run the following docker build command in the project folder to create an image. + +イメージとは固定されたコンテナのようなものです。コンテナを実行するには、常にイメージが必要です。イメージを構築するには、リポジトリ内に Dockerfile が既にあれば、プロジェクトのフォルダ内で以下の ``docker build`` コマンドを実行するだけです。 + +.. code-block:: bash + + $ docker build -t welcome-to-docker . + +.. Building the image may take some time. After your image is built, you can view your image in the Images tab in Docker Desktop. + +イメージの構築には少々時間がかかります。イメージの構築が終われば、Docker Desktop 内の **images** タブにイメージが表示されます。 + +.. Step 4: Run your container +.. _step-4-run-your-container: + +ステップ4：コンテナを実行 +============================== + +.. To run your image as a container, go to the Images tab, and then select Run in the Actions column of your image. When the Optional settings appear, specify the Host port number 8089 and then select Run. + +イメージをコンテナとして実行するには、 **Images** タブに移動し、それからイメージの **Actions** 列にある **Run** を選びます。 **Optional settings** が表示したら、 **Host port** 番号を ``8089`` に指定し、それから **Run** を選びます。 + +.. image:: ./images/getting-started-run-image.gif + :alt: Docker Desktop でイメージを実行 + +.. Step 5: Verify that your container is running +.. step-5-verify-that-your-container-is-running: + +ステップ5：コンテナが動作しているのを確認 +================================================== + +.. You can use Docker Desktop to view and access running containers. Go to the Containers tab to view your container and select the link in the Port(s) column or go to http://localhost:8089 to verify that the application is running. + +Docker Desktop を使い、実行中のコンテナを表示し、アクセスできます。 **Containers** タブで対象のコンテナを表示し、 **Port(s)** 列のリンクを選ぶか、 http://localhost:8089 を開けば、アプリケーションが実行中だと確認できます。 + +.. What’s next + +次は何をしますか +==================== + +.. In this guide, you built your own image. When running containers on Docker Desktop, you don’t need to build your own image from scratch. You can also run images created by others on Docker Hub. + +このガイドでは、自分のイメージを構築しました。Docker Desktop 上でコンテナを実行する時は、必ずしもゼロからイメージを構築する必要はありません。他の人によって作られた Docker Hub 上のイメージも実行できます。 + +.. Run Docker Hub images + +* :doc:`Docker Hub イメージの実行 ` + +.. Dive deeper +より深い理解 +==================== + +.. Language-specific guides + +言語別ガイド +-------------------- + +.. If you want to learn more about creating images for applications in other languages, check out the following language-specific guides: + +アプリケーション用イメージを他のプログラミング言語で作成する方法は、以下の言語別ガイドを御覧ください。 + +* :doc:`Node.js ` +* :doc:`Python ` +* :doc:`Go ` +* :doc:`Java ` +* :doc:`C# (.NET) ` + + +.. Breaking down the docker build command +.. _breaking-down-the-docker-build-command: + +``docker build`` コマンドの分解 +---------------------------------------- + +.. When you built the image, you used the docker build command. Here are what the different parts of the docker build command do: + +イメージの構築時に ``docker build`` コマンドを使いました。コマンドの各部分が何なのかを説明します。 + +.. docker build: This command builds the image. It needs one argument, the source folder for the Dockerfile that needs to be built. In this case, it’s the Dockerfile in the current folder, .. + -t welcome-to-docker: The -t flag tags the image with a unique name. In this case, welcome-to-docker. + +* ``docker build`` ： このコマンドはイメージを構築します。構築のためには1つの引数が必須で、 Dockerfile があるソースのフォルダを指定します。この例では、 Dockerfile は現在のフォルダのため ``.`` です。 +* ``-t welcome-to-docker`` ： ``-t`` フラグはユニークな名前でイメージにタグ付けします。この例では ``welcome-to-docker`` です。 + + + + + + +.. seealso:: + + How do I run a container? + https://docs.docker.com/get-started/run-your-own-container/ + + diff --git a/get-started/toc.rst b/get-started/toc.rst index 9d127d080..255d76049 100755 --- a/get-started/toc.rst +++ b/get-started/toc.rst @@ -1,23 +1,23 @@ .. -*- coding: utf-8 -*- .. -.. doc version: 20.10 -.. check date: 2022/09/20 +.. doc version: 24.0 +.. check date: 2023/07/16 .. ----------------------------------------------------------------------------- .. Get Started-toc: ======================================== -Get started - 始めましょう +始め方 - Get started ======================================== .. toctree:: :maxdepth: 2 - Part 1:始めましょう - Part 2:サンプル アプリケーション <02_our_app.rst> + Part 1:概要 <01_overview.rst> + Part 2:アプリケーションのコンテナ化 <02_our_app.rst> Part 3:アプリケーションの更新 <03_updating_app.rst> Part 4:アプリケーションの共有 <04_sharing_app.rst> - Part 5:DBの保持 <05_persisting_data.rst> + Part 5:データベースの保持 <05_persisting_data.rst> Part 6:バインド マウントを使う <06_bind_mounts.rst> Part 7:複数コンテナのアプリ <07_multi_container.rst> Part 8:Docker Composeを使う <08_using_compose.rst> diff --git a/get-started/what-is-a-containe.rst b/get-started/what-is-a-containe.rst new file mode 100644 index 000000000..790eae0aa --- /dev/null +++ b/get-started/what-is-a-containe.rst @@ -0,0 +1,147 @@ +.. -*- coding: utf-8 -*- +.. URL: https://docs.docker.com/get-started/what-is-a-container/ + doc version: 24.0 + https://github.com/docker/docs/blob/main/get-started/what-is-a-container.md +.. check date: 2023/07/18 +.. Commits on Mar 27, 2023 f4258c0c1e6f339ee37d8156877eb33bbcc81517 +.. ----------------------------------------------------------------------------- + +.. What is a container? +.. _what-is-a-container: + +======================================== +コンテナとは何ですか？ +======================================== + +.. sidebar:: 目次 + + .. contents:: + :depth: 2 + :local: + +.. A container is an isolated environment for your code. This means that a container has no knowledge of your operating system, or your files. It runs on the environment provided to you by Docker Desktop. This is why a container usually has everything that your code needs in order to run, down to a base operating system. You can use Docker Desktop to manage and explore your containers. + +:ruby:`コンテナ ` とは、コードのための :ruby:`隔離された ` 環境です。これが意味するのは、コンテナはオペレーティングシステムやファイルについての知識を持ちません。コンテナが動作するのは、Docker Desktop によって提供される環境上です。コンテナが通常あらゆるものが入っているとされる理由は、コードを実行するために必要なものや、ベースとなるオペレーティングシステムに至るまであるからです。Docker Desktop を使ってコンテナの管理や調査が行えます。 + +.. Continue with the following steps to view and explore an actual container in Docker Desktop. + +実際のコンテナを Docker Desktop で表示や調査するには、以下の手順を進めます。 + +.. Step 1: Set up the guide +.. _step-1-set-up-the-guide: + +ステップ1：セットアップガイド +============================== + +.. The first thing you need is a running container. For this guide, use the premade welcome-to-docker container. To get started, start Docker Desktop and then run the following command in your local terminal: + +最初にコンテナを実行する必要があります。このガイドでは、あらかじめ作られた ``welcome-to-docker`` コンテナを使います。始めるには、 Docker Desktop を起動し、自分のローカルターミナル上で以下のコマンドを実行します。 + +.. code-block:: bash + + $ docker run -p 8088:80 -d --name welcome-to-docker docker/welcome-to-docker + +.. Step 2: View containers on Docker Desktop +.. _step-2-view-containers-on-docker-desktop: + +ステップ2：Docker Desktop 上でコンテナを表示 +================================================== + +.. You just ran a container! Open Docker Desktop to take a look. This container runs a simple web server that displays HTML text. When working with more complex projects, you’ll run different parts in different containers. For example, a different container for the frontend, backend, and database. In this guide, you only have a simple frontend container. + +今しがたコンテナを実行しました！ Docker Desktop を開いて見てみます。このコンテナは、 HTML テキストを表示するシンプルなウェブサーバを実行しています。複雑なプロジェクトを扱うようになれば、異なるコンテナ内で異なるパーツを実行するでしょう。たとえば、フロントエンド、バックエンド、データベースに対する異なるコンテナです。このガイドでは、シンプルなフロントエンドのコンテナのみ扱います。 + +.. image:: ./images/getting-started-container.png + :width: 80% + :alt: Docker Desktop では get-started コンテナが実行中 + +.. Step 3: View the frontend +.. _step-3-view-the-frontend: + +ステップ3：フロントエンドの表示 +======================================== + +.. The frontend is accessible on port 8088 of your local host. Select the link in the Port(s) column of your container, or visit http://localhost:8088 in your browser to check it out. + +フロントエンドには、自分のローカルホスト上にあるポート 8088 からアクセスできます。確認をするには、コンテナの **Port(s)** 列内にあるリンクを選ぶか、ブラウザで http://localhost:8088 を開きます。 + +.. image:: ./images/getting-started-frontend.png + :width: 100% + :alt: Docker Desktop からコンテナのフロントエンドにアクセス + +.. Step 4: Explore your container +.. _step-4-explore-your-container: + +ステップ4：コンテナの調査 +============================== + +.. Docker Desktop allows you to easily view and interact with different aspects of your container. Try it out yourself. Select your container and then select Files to explore your container’s isolated file system. + +Docker Desktop により、コンテナを簡単に表示したり、様々な様子を簡単に調べられます。自分自身で試しましょう。コンテナの隔離されたファイルシステムを調べるには、コンテナを選択し、 **Files** を選びます。 + +.. image:: ./images/getting-started-explore-container.gif + :width: 100% + :alt: Docker Desktop でコンテナの詳細を表示 + + +.. Step 5: Stop your container +.. _step-5-stop-your-container: + +ステップ5：コンテナの停止 +============================== + +.. The welcome-to-docker container continues to run until you stop it. To stop the container in Docker Desktop, go to the Containers tab and select the Stop icon in the Actions column of your container. + +``welcome-to-docker`` コンテナは停止するまで実行し続けます。 Docker Desktop でコンテナを停止するには、 **Containers** タブに移動し、対象コンテナの **Actions** 列にある **Stop** アイコンを選びます。 + +.. image:: ./images/getting-started-stop.png + :width: 100% + :alt: Docker Desktop でコンテナを停止 + +.. What’s next +.. _container-whats-next: + +次は何をしますか +==================== + +.. In this guide, you explored what a container is. Continue to the next guide to learn what you need to create and run your own container. + +このガイドでは、コンテナとは何かを学びました。次のガイドでは、自分のコンテナを作成・実行するために必要なことを学びます。 + +* :doc:`自分のコンテナを実行 ` + +.. Dive deeper +より深い理解 +==================== + + +.. Breaking down the docker run command +.. _breaking-down-the-docker-run-command: + +``docker run`` コマンドの分解 +------------------------------ + +.. When setting up the container, you used the docker run command. Here are what the different parts of the command do: + +コンテナのセットアップ時に ``docker run`` コマンドを使いました。コマンドの各部分が何なのかを説明します。 + +.. docker run: This is used to run containers. It needs at least one argument, and that argument is the image you want to run. In this case, it’s docker/welcome-to-docker. + -p 8088:80: This lets Docker know that port 80 in the container needs to be accessible from port 8088 on your local host. + -d: This runs the container detached or in the background. + —-name welcome-to-docker: This sets the name for your container. If you don’t do so, Docker selects a random name for you. + +* ``docker run`` ： これはコンテナの実行に使います。少なくとも1つの引数が必要で、実行したいイメージを引数にします。今回のイメージは ``docker/welcome-to-docker`` です。 +* ``-p 8088:80`` ： これは Docker に対して、コンテナのポート 80 にアクセスするには、ローカルホスト上のポート 8088 からアクセスする必要があると伝えます。 +* ``-d`` ： コンテナを :ruby:`デタッチド ` 、あるいは、バックグラウンドで実行します。 +* ``--name welcome-to-docker`` ： これはコンテナ名を指定します。指定しなければ、Docker はランダムな名前を選びます。 + +.. Continue following What’s next to learn how to intuitively run an image using the Docker Desktop GUI. + +:ref:`container-whats-next` に戻り、 Docker Desktop GUI を使ってイメージを直感的に実行する方法を学びましょう。 + +.. seealso:: + + What is a container? + https://docs.docker.com/get-started/what-is-a-container/ + + diff --git a/index.rst b/index.rst index 41b27dccd..a2057c3d4 100644 --- a/index.rst +++ b/index.rst @@ -5,8 +5,8 @@ contain the root `toctree` directive. .. ----------------------------------------------------------------------------- .. URL: https://docs.docker.com/ - doc version: 23.0 (current) -.. check date: 2023/05/06 + doc version: 24.0 (current) +.. check date: 2023/07/15 .. ----------------------------------------------------------------------------- .. Welcome to Docker-docs-ja's documentation! @@ -23,7 +23,7 @@ Docker ドキュメント日本語化プロジェクト .. attention:: - * Docker `v23.0.x (current)` 向けにドキュメントの改訂作業中です(2023年7月現在)。一部古い場合がありますので、ご注意ください。 + * Docker `v24.0.x (current)` 向けにドキュメントの改訂作業中です(2023年7月現在)。一部古い場合がありますので、ご注意ください。 * Docker のドキュメントは常に変わり続けています。最新の情報については `公式ドキュメント `_ をご覧ください。 * 本プロジェクトは有志による翻訳プロジェクトです。お気づきの点がございましたら、 `issue `_ や `Pull Request `_ 、 `Docker 道場（日本語の Docker オンラインフォーラム） `_ でお知らせ願います。 @@ -54,7 +54,7 @@ Docker ドキュメント --- -Doc v23.0 目次 +Doc v24.0 目次 ==================== .. toctree:: @@ -64,10 +64,10 @@ Doc v23.0 目次 Docker 概要 get-docker.rst get-started/toc.rst + get-started/hands-on-overview.rst language/toc.rst develop/toc.rst - ci-cd/toc.rst - cloud/toc.rst + build/guide/toc.rst production.rst get-started/resources.rst opensource/toc.rst diff --git a/language/dotnet/toc.rst b/language/dotnet/toc.rst new file mode 100644 index 000000000..b056cd30b --- /dev/null +++ b/language/dotnet/toc.rst @@ -0,0 +1,25 @@ +.. -*- coding: utf-8 -*- +.. +.. doc version: 24 +.. check date: 2023/07/20 +.. ----------------------------------------------------------------------------- + +======================================== +C# (.NET) +======================================== + +(ToDo) + +https://docs.docker.com/language/dotnet/ + +.. toctree:: + :maxdepth: 2 + + 概要 + イメージ構築 + コンテナ実行 + アプリの開発 + テストの実行 + CI/CD 設定 + アプリのデプロイ + diff --git a/language/index.rst b/language/index.rst index 910b556d2..b9ae4a8e3 100644 --- a/language/index.rst +++ b/language/index.rst @@ -1,9 +1,9 @@ .. -*- coding: utf-8 -*- .. URL: https://docs.docker.com/language/ - doc version: 20.10 + doc version: 24.0 https://github.com/docker/docker.github.io/blob/master/language/index.md -.. check date: 2022/09/23 -.. Commits on Jul 14, 2022 2482f8ce04317b2c56301ea9885bb9a947b232d3 +.. check date: 2023/07/20 +.. Commits on Jun 30, 2023 4523221101c35de82a0d6f4263615dabe514c0a6 .. ----------------------------------------------------------------------------- .. Overview @@ -18,7 +18,7 @@ .. In addition to the language-specific modules, Docker documentation also provides guidelines to build and efficiently manage your development environment. You can find information on the best practices for writing Dockerfiles, building and managing images efficiently, gaining performance improvements by building images using BuildKit, etc. You can also find specific instructions on how to keep your images small, and how to persist application data, how to use multi-stage builds, etc. - Docker のドキュメントでは、言語別の章に加え、開発環境の構築とイメージの効率的な管理に関するガイドラインも提供しています。Dockerfile の書き方のベストプラクティス、イメージの効率的な構築と管理、BuildKit を使ったイメージ構築のパフォーマンス改善を得る方法等についての情報を得られます。また、イメージを小さく保つ方法、アプリケーションデータの保持、マルチステージ ビルドの使い方に関する情報も提供しています。 +Docker のドキュメントでは、言語別の章に加え、開発環境の構築とイメージの効率的な管理に関するガイドラインも提供しています。Dockerfile の書き方のベストプラクティス、イメージの効率的な構築と管理、BuildKit を使ったイメージ構築のパフォーマンス改善を得る方法等についての情報を得られます。また、イメージを小さく保つ方法、アプリケーションデータの保持、マルチステージ ビルドの使い方に関する情報も提供しています。 .. For more information, refer to the following topics: @@ -27,12 +27,10 @@ .. Best practices for writing Dockerfiles Docker development best practices Build images with BuildKit - Manage images * :doc:`/develop/develop-images/dockerfile_best-practices` * :doc:`/develop/dev-best-practices` -* :doc:`/develop/develop-images/build_enhancements` -* :doc:`/develop/develop-images/image_management` +* :doc:`/build/buidkit` .. Language-specific getting started guides .. _language-specific-getting-started-guides: @@ -48,6 +46,8 @@ Docker 環境の準備とアプリケーションのコンテナ化を始める * :doc:`Python ` * :doc:`Java ` * :doc:`Go ` +* :doc:`C# (.NET) ` +* :doc:`Rust ` .. seealso:: diff --git a/language/nodejs/configure-ci-cd.rst b/language/nodejs/configure-ci-cd.rst index 0c6f8cfbb..936a49fa4 100644 --- a/language/nodejs/configure-ci-cd.rst +++ b/language/nodejs/configure-ci-cd.rst @@ -42,7 +42,7 @@ Docker プロジェクトのセットアップ それでは始めましょう。このガイドでは例としてシンプルな Docker プロジェクトを使います。 `SimpleWhaleDemo `_ リポジトリは Nginx alpine イメージを含みます。このリポジトリを複製するか、自分の Docker プロジェクトを使います。 .. image:: /ci-cd/images/simplewhaledemo.png - :scale: 60% + :width: 60% :alt: SimpleWhaleDemo .. Before we start, ensure you can access Docker Hub from any workflows you create. To do this: @@ -66,13 +66,13 @@ Docker プロジェクトのセットアップ 4. このトークンを **simplewhaleci** と呼びましょう。 .. image:: /ci-cd/images/github-access-token.png - :scale: 60% + :width: 60% :alt: New access token 5. それから GitHub secrets UI で、この :ruby:`パーソナル アクセス トークン ` （PAT）を2番目のシークレットとして ``DOCKER_HUB_ACCESS_TOKEN`` という名前の値に追加します。 .. image:: /ci-cd/images/github-secrets.png - :scale: 60% + :width: 60% :alt: New access token .. Set up the GitHub Actions workflow @@ -181,7 +181,7 @@ GitHub Actions ワークフローのセットアップ .. CI to Docker Hub .. image:: /ci-cd/images/ci-to-hub.png - :scale: 60% + :width: 60% :alt: Docker Hub への CI .. Optimizing the workflow @@ -295,7 +295,7 @@ Docker Hub にタグ付けされたバージョンを送信 .. Push tagged version .. image:: /ci-cd/images/push-tagged-version.png - :scale: 60% + :width: 60% :alt: タグ付けされたバージョンを送信 .. Now, let’s set up a second GitHub action file to store our latest commit as an image in the GitHub registry. You may want to do this to: @@ -340,7 +340,7 @@ Docker Hub にタグ付けされたバージョンを送信 .. Update tagged images .. image:: /ci-cd/images/ghcr-logic.png - :scale: 60% + :width: 60% :alt: タグ付けされたイメージの更新 .. Now, we will have two different flows: one for our changes to master, and one for our pull requests. Next, we need to modify what we had before to ensure we are pushing our PRs to the GitHub registry rather than to Docker Hub. diff --git a/language/nodejs/develop.rst b/language/nodejs/develop.rst index 2d456404a..1aed12da4 100644 --- a/language/nodejs/develop.rst +++ b/language/nodejs/develop.rst @@ -244,7 +244,7 @@ Compose ファイルを使う上で、もう1つの素晴らしい機能は、 正常に動作すると、次のような画面が見えます。 .. image:: ./images/node-compile.png - :scale: 60% + :width: 60% :alt: node-compile .. Now let’s test our API endpoint. Run the following curl command: @@ -276,7 +276,7 @@ Compose ファイルを使う上で、もう1つの素晴らしい機能は、 .. It opens the following screen. .. image:: ./images/chrome-inspect.png - :scale: 60% + :width: 60% :alt: Chrome-inspect .. Click the Open dedicated DevTools for Node link. This opens the DevTools that are connected to the running Node.js process inside our container. @@ -302,7 +302,7 @@ Compose ファイルを使う上で、もう1つの素晴らしい機能は、 Compose アプリケーションを実行しているターミナルを見ると、nodemon が変更を検出し、アプリケーションを再読み込みします。 .. image:: ./images/nodemon.png - :scale: 60% + :width: 60% :alt: nodemon .. Navigate back to the Chrome DevTools and set a breakpoint on the line containing the return res.json({ "foo": "bar" }) statement, and then run the following curl command to trigger the breakpoint. diff --git a/language/python/configure-ci-cd.rst b/language/python/configure-ci-cd.rst index 1bfe51f34..588d4ef11 100644 --- a/language/python/configure-ci-cd.rst +++ b/language/python/configure-ci-cd.rst @@ -42,7 +42,7 @@ Docker プロジェクトのセットアップ それでは始めましょう。このガイドでは例としてシンプルな Docker プロジェクトを使います。 `SimpleWhaleDemo `_ リポジトリは Nginx alpine イメージを含みます。このリポジトリを複製するか、自分の Docker プロジェクトを使います。 .. image:: /ci-cd/images/simplewhaledemo.png - :scale: 60% + :width: 60% :alt: SimpleWhaleDemo .. Before we start, ensure you can access Docker Hub from any workflows you create. To do this: @@ -66,13 +66,13 @@ Docker プロジェクトのセットアップ 4. このトークンを **simplewhaleci** と呼びましょう。 .. image:: /ci-cd/images/github-access-token.png - :scale: 60% + :width: 60% :alt: New access token 5. それから GitHub secrets UI で、この :ruby:`パーソナル アクセス トークン ` （PAT）を2番目のシークレットとして ``DOCKER_HUB_ACCESS_TOKEN`` という名前の値に追加します。 .. image:: /ci-cd/images/github-secrets.png - :scale: 60% + :width: 60% :alt: New access token .. Set up the GitHub Actions workflow @@ -181,7 +181,7 @@ GitHub Actions ワークフローのセットアップ .. CI to Docker Hub .. image:: /ci-cd/images/ci-to-hub.png - :scale: 60% + :width: 60% :alt: Docker Hub への CI .. Optimizing the workflow @@ -295,7 +295,7 @@ Docker Hub にタグ付けされたバージョンを送信 .. Push tagged version .. image:: /ci-cd/images/push-tagged-version.png - :scale: 60% + :width: 60% :alt: タグ付けされたバージョンを送信 .. Now, let’s set up a second GitHub action file to store our latest commit as an image in the GitHub registry. You may want to do this to: @@ -340,7 +340,7 @@ Docker Hub にタグ付けされたバージョンを送信 .. Update tagged images .. image:: /ci-cd/images/ghcr-logic.png - :scale: 60% + :width: 60% :alt: タグ付けされたイメージの更新 .. Now, we will have two different flows: one for our changes to master, and one for our pull requests. Next, we need to modify what we had before to ensure we are pushing our PRs to the GitHub registry rather than to Docker Hub. diff --git a/language/rust/toc.rst b/language/rust/toc.rst new file mode 100644 index 000000000..35ca633cb --- /dev/null +++ b/language/rust/toc.rst @@ -0,0 +1,25 @@ +.. -*- coding: utf-8 -*- +.. +.. doc version: 24 +.. check date: 2023/07/20 +.. ----------------------------------------------------------------------------- + +======================================== +Rust +======================================== + +(ToDo) + +https://docs.docker.com/language/golang/build-images/ + +.. toctree:: + :maxdepth: 2 + + 概要 + イメージ構築 + コンテナ実行 + アプリの開発 + テストの実行 + CI/CD 設定 + アプリのデプロイ + diff --git a/language/toc.rst b/language/toc.rst index 036d875a9..418c819e2 100644 --- a/language/toc.rst +++ b/language/toc.rst @@ -1,7 +1,7 @@ .. -*- coding: utf-8 -*- .. -.. doc version: 20.10 -.. check date: 2022/09/23 +.. doc version: 24 +.. check date: 2023/07/20 .. ----------------------------------------------------------------------------- .. Language-specific guides @@ -18,4 +18,6 @@ Python <./python/toc.rst> Java <./java/toc.rst> Go <./golang/toc.rst> + C# (.NET) <./dotnet/toc.rst> + Rust <./rust/toc.rst> diff --git a/machine/overview.rst b/machine/overview.rst index 49cf35cbe..67645ee55 100644 --- a/machine/overview.rst +++ b/machine/overview.rst @@ -99,7 +99,7 @@ Docker Machine は主に２つの使い方があります。 .. ![Docker Machine on Mac and Windows](img/machine-mac-win.png){: .white-bg} .. image:: ./img/machine-mac-win.png - :scale: 60% + :width: 60% :alt: Mac と Windows 上の Docker Machine .. If you work primarily on an older Mac or Windows laptop or desktop that doesn't meet the requirements for the new [Docker Desktop for Mac](../docker-for-mac/index.md) and [Docker Desktop for Windows](../docker-for-windows/index.md) apps, then you need Docker Machine to run Docker Engine locally. Installing Docker Machine on a Mac or Windows box with the [Docker Toolbox](../toolbox/overview.md) installer provisions a local virtual machine with Docker Engine, gives you the ability to connect it, and run `docker` commands. @@ -116,7 +116,7 @@ Docker Machine は主に２つの使い方があります。 .. ![Docker Machine for provisioning multiple systems](img/provision-use-case.png){: .white-bg} .. image:: ./img/provision-use-case.png - :scale: 60% + :width: 60% :alt: 複数システムをプロビジョニングする Docker Machine .. Docker Engine runs natively on Linux systems. If you have a Linux box as your @@ -163,7 +163,7 @@ Docker Engine は CLI から ``docker`` コマンド、たとえば ``docker run .. Docker Engine .. image:: ./img/engine.png - :scale: 60% + :width: 60% :alt: Docker Engine .. **Docker Machine** is a tool for provisioning and managing your Dockerized hosts @@ -179,7 +179,7 @@ Docker Engine は CLI から ``docker`` コマンド、たとえば ``docker run **Docker Machine** は Docker ホスト（Docker Engine が動くホスト環境）のプロビジョニングと管理用のツールです。一般的には Docker Machine を自分のローカルシステム上にインストールします。Docker Machine には独自のコマンドライン・クライアント`docker-machine`と Docker Engine クライアント`docker`があります。Docker Machine を使えば仮想システム上に Docker Engine をインストールできます。仮想システムとはローカル（Machine を使い、Mac または Windows 上の VirtualBox に Docker Engine をインストール、実行します）でも、リモート（Machine を使い、クラウド・プロバイダ上に Docker をプロビジョン）でも構いません。Docker に対応したホストであれば、何でも常に 「 **マシン** 」として管理できるのです（訳者注：Docker Machine の管理対象のホストは、ローカルでもクラウド上でも「マシン」という概念で抽象化できる、という意味です）。 .. image:: ./img/machine.png - :scale: 60% + :width: 60% :alt: Docker Machine .. Where to go next diff --git a/network/default_network/ipv6.rst b/network/default_network/ipv6.rst index 80fa6d66b..e3d9990bc 100644 --- a/network/default_network/ipv6.rst +++ b/network/default_network/ipv6.rst @@ -76,7 +76,7 @@ IPv6 転送（IPv6 forwarding）は既存の IPv6 設定に干渉する場合が .. image:: ./images/ipv6-basic-host-config.png - :scale: 60% + :width: 60% :alt: IPv6基本設定 .. Every new container will get an IPv6 address from the defined subnet. Further a default route will be added on eth0 in the container via the address specified by the daemon option --default-gateway-v6 if present, otherwise via fe80::1: @@ -106,7 +106,7 @@ IPv6 転送（IPv6 forwarding）は既存の IPv6 設定に干渉する場合が サーバや仮想マシンは ``/64`` IPv4 サブネットを割り当てられます（例： ``2001:db8:23:42::/64`` ）。今回の例では、ホスト上の他のアプリケーションとの分離に ``/80`` サブネットが使いますが、 Docker の設定でサブネットを ``/80`` 以上にも分割できます。 .. image:: ./images/ipv6-slash64-subnet-config.png - :scale: 60% + :width: 60% :alt: IPv6基本設定 .. In this setup the subnet 2001:db8:23:42::/80 with a range from 2001:db8:23:42:0:0:0:0 to 2001:db8:23:42:0:ffff:ffff:ffff is attached to eth0, with the host listening at 2001:db8:23:42::1. The subnet 2001:db8:23:42:1::/80 with an address range from 2001:db8:23:42:1:0:0:0 to 2001:db8:23:42:1:ffff:ffff:ffff is attached to docker0 and will be used by containers. @@ -149,7 +149,7 @@ Docker ホストが IPv6 サブネットの範囲にありながら IPv6 サブ Docker サブネットには、 ``eth0`` に接続するルータが管理しているサブネットが含まれているのに気を付けてください。つまり、Docker サブネットで公開される全てのデバイス（コンテナ）のアドレスは、ルータ側のサブネットから見つけることができます。つまり、ルータはこれらのコンテナと直接通信できると考えられます。 .. image:: ./images/ipv6-ndp-proxying.png - :scale: 60% + :width: 60% :alt: IPv6 NDP Proxying .. As soon as the router wants to send an IPv6 packet to the first container it will transmit a neighbor solicitation request, asking, who has 2001:db8::c009? But it will get no answer because no one on this subnet has this address. The container with this address is hidden behind the Docker host. The Docker host has to listen to neighbor solicitation requests for the container address and send a response that itself is the device that is responsible for the address. This is done by a Kernel feature called NDP Proxy. You can enable it by executing @@ -201,7 +201,7 @@ Docker IPv6 クラスタ 到達可能な IPv6 アドレスを使い、異なったホスト上のコンテナ間での通信を可能にします。簡単な Docker IPv6 クラスタの例を見ていきましょう。 .. image:: ./images/ipv6-switched-network-example.png - :scale: 60% + :width: 60% :alt: IPv6 スイッチ・ネットワーク .. The Docker hosts are in the 2001:db8:0::/64 subnet. Host1 is configured to provide addresses from the 2001:db8:1::/64 subnet to its containers. It has three routes configured: @@ -260,7 +260,7 @@ Docker ホストは ``2001:db8:0::/64`` サブネットを持ちます。ホス ネットワーク環境の経路は、レイヤ２スイッチとレイヤ３ルータの関係に置き換えられます。ホストはデフォルト・ゲートウェイ（ルータ）を知っており、（Docker によって管理されている）個々のコンテナに対する経路を処理します。ルータは Docker サブネットに関する全ての経路情報も保持しています。この環境でホストの追加や削除時は、各ホストではなく、ルータ上のルーティング・テーブルを更新しなくてはいけません。 .. image:: ./images/ipv6-routed-network-example.png - :scale: 60% + :width: 60% :alt: IPv6 経路ネットワーク .. In this scenario containers of the same host can communicate directly with each other. The traffic between containers on different hosts will be routed via their hosts and the router. For example packet from Container1-1 to Container2-1 will be routed through Host1, Router and Host2 until it arrives at Container2-1. diff --git a/network/dockernetworks.rst b/network/dockernetworks.rst index 63b6260ec..96cc14932 100644 --- a/network/dockernetworks.rst +++ b/network/dockernetworks.rst @@ -417,14 +417,14 @@ Docker Engine は自動的にネットワークの ``Subnet`` と ``Gateway`` このネットワーク内で起動したコンテナは、Docker ホスト上の他のコンテナとは独立しています。ネットワーク内の各コンテナは速やかに通信が可能です。しかし、コンテナ自身が含まれるネットワークは外部のネットワークから独立しています。 .. image:: ./images/bridge_network.png - :scale: 60% + :width: 60% .. Within a user-defined bridge network, linking is not supported. You can expose and publish container ports on containers in this network. This is useful if you want to make a portion of the bridge network available to an outside network. ユーザ定義ブリッジ・ネットワークの内部では、リンク機能はサポートされません。ですが、このネットワーク上にあるコンテナのポートは公開可能です。 ``bridge`` ネットワークの一部を外のネットワークから使う時に便利でしょう。 .. image:: ./images/network_access.png - :scale: 60% + :width: 60% .. A bridge network is useful in cases where you want to run a relatively small network on a single host. You can, however, create significantly larger networks by creating an overlay network. @@ -446,14 +446,14 @@ Docker の ``overlay`` （オーバレイ）ネットワーク・ドライバは ``overlay`` ネットワークはキーバリュー・ストア・サービスが必要です。現時点で Docker の ``libkv`` がサポートしているのは、Consul、Etcd、Zookeeper（分散ストア）です。ネットワークを作成する前に、キーバリュー・ストア・サービスを選び、設定する必要があります。そして、Docker ホスト側では、ネットワークとサービスが通信できるようにします。 .. image:: ./images/key-value.png - :scale: 60% + :width: 60% .. Each host in the network must run a Docker Engine instance. The easiest way to provision the hosts are with Docker Machine. ネットワークの各ホストは、それぞれで Docker エンジンを動かす必要があります。最も簡単なのは Docker Machine を使ってホストをプロビジョンする方法です。 .. image:: ./images/engine-on-net.png - :scale: 60% + :width: 60% .. You should open the following ports between each of your hosts. @@ -511,7 +511,7 @@ Docker Machine でプロビジョンしたら、Docker Swarm を使うための この結果、複数のホストを横断する１つのネットワークができます。 ``overlay`` ネットワークはコンテナに対して、完全なる独立機能を提供します。 .. image:: ./images/overlay-network.png - :scale: 60% + :width: 60% .. Then, on each host, launch containers making sure to specify the network name. @@ -524,7 +524,7 @@ Docker Machine でプロビジョンしたら、Docker Swarm を使うための 接続したあと、ネットワーク内の各コンテナ全てにアクセス可能となります。この時、コンテナがどこのホスト上で起動しているか気にする必要はありません。 .. image:: ./images/overlay-network-final.png - :scale: 60% + :width: 60% .. If you would like to try this for yourself, see the Getting started for overlay. diff --git a/network/work-with-networks.rst b/network/work-with-networks.rst index aa66837bd..965a6f02b 100644 --- a/network/work-with-networks.rst +++ b/network/work-with-networks.rst @@ -343,7 +343,7 @@ Docker Engineが自動的に ``container2`` に IP アドレスを割り当て ``container2`` は２つのネットワークに所属しているのが分かります。 ``bridge`` ネットワークは起動時にデフォルトで参加したネットワークであり、 ``isolated_nw`` ネットワークは後から自分で接続したものです。 .. image:: ./images/working.png - :scale: 60% + :width: 60% :alt: Docker のネットワーク .. In the case of container3, you connected it through docker run to the isolated_nw so that container is not connected to bridge. diff --git a/storage/bind-mounts.rst b/storage/bind-mounts.rst index 6d76714ed..da8d7d323 100644 --- a/storage/bind-mounts.rst +++ b/storage/bind-mounts.rst @@ -28,7 +28,7 @@ ファイルやディレクトリは Docker ホスト上にあらかじめ存在している必要はありません。存在しなければ、必要に応じて作成されます。バインド マウントは高性能ですが、ホストマシンのファイルシステムで利用可能な、特定のディレクトリ構造に依存します。新しい Docker アプリケーションを開発する場合は、代わりに :doc:`名前付きボリューム ` の利用を検討してください。バインド マウントは Docker CLI コマンドを使って直接管理できません。 .. image:: ./images/types-of-mounts-bind.png - :scale: 60% + :width: 60% :alt: Docker ホスト上のバインド マウント .. Choose the -v or --mount flag diff --git a/storage/index.rst b/storage/index.rst index f231e859c..a68b0ddba 100644 --- a/storage/index.rst +++ b/storage/index.rst @@ -57,7 +57,7 @@ Docker でのデータ管理 データが Docker ホスト上のどこに存在しているかを考えるには、ボリューム、バインド マウント、 ``tmpfs`` マウントの違いを図にすると簡単です。 .. image:: ./images/types-of-mounts.png - :scale: 60% + :width: 60% :alt: マウント形式と、Docker ホスト上のどこにデータが存在するか .. Volumes are stored in a part of the host filesystem which is managed by Docker (/var/lib/docker/volumes/ on Linux). Non-Docker processes should not modify this part of the filesystem. Volumes are the best way to persist data in Docker. diff --git a/storage/storagedriver/aufs-driver.rst b/storage/storagedriver/aufs-driver.rst index 2e0d8101f..42d01d4f1 100644 --- a/storage/storagedriver/aufs-driver.rst +++ b/storage/storagedriver/aufs-driver.rst @@ -83,7 +83,7 @@ AUFS は複数のディレクトリの積み重ねであり、１つのマウン Docker 内部では、 AUFS ユニオン・マウントがイメージのレイヤ化を行います。AUFS ストレージ ドライバは、ユニオン・マウント・システムを使って Docker イメージを扱います。AUFS ブランチが Docker イメージ・レイヤに相当します。以下の図は ``ubuntu:latest`` イメージをベースとする Docker コンテナです。 .. image:: ./images/aufs-layers.png - :scale: 60% + :width: 60% :alt: イメージ層 .. This diagram shows that each image layer, and the container layer, is represented in the Docker hosts filesystem as a directory under /var/lib/docker/. The union mount point provides the unified view of all layers. As of Docker 1.10, image layer IDs do not correspond to the names of the directories that contain their data. @@ -125,7 +125,7 @@ AUFS ストレージ ドライバでのファイル削除 AUFS ストレージ ドライバでコンテナからファイルを削除したら、コンテナの一番上のレイヤに *ホワイトアウト・ファイル（whiteout file）* が置かれます。読み込み専用のイメージ・レイヤの下にあるファイルを、ホワイトアウト・ファイルが効果的に隠します。以下の単純化した図は、３つのイメージ・レイヤのイメージに基づくコンテナを表しています。 .. image:: ./images/aufs-delete.png - :scale: 60% + :width: 60% :alt: イメージ層 .. The file3 was deleted from the container. So, the AUFS storage driver placed a whiteout file in the container’s top layer. This whiteout file effectively “deletes” file3 from the container by obscuring any of the original file’s existence in the image’s read-only layers. This works the same no matter which of the image’s read-only layers the file exists in. @@ -211,7 +211,7 @@ AUFS ストレージ ドライバを使えるのは、AUFS がインストール ``/var/lib/docker/aufs/layers/`` ディレクトリに含まれるのは、どのようにイメージ・レイヤを重ねるかというメタデータです。このディレクトリには、Docker ホスト上のイメージかコンテナごとに１つのファイルがあります（ファイル名はイメージのレイヤ ID と一致しません）。各ファイルの中にはイメージ・レイヤの名前があります。次の図は１つのイメージが４つのレイヤを持つのを示しています。 .. image:: ./images/aufs-metadata.png - :scale: 60% + :width: 60% :alt: AUFS メタデータ .. Inspecting the contents of the file relating to the top layer of the image shows the three image layers below it. They are listed in the order they are stacked. diff --git a/storage/storagedriver/btrfs-driver.rst b/storage/storagedriver/btrfs-driver.rst index 32202227c..6251c46ec 100644 --- a/storage/storagedriver/btrfs-driver.rst +++ b/storage/storagedriver/btrfs-driver.rst @@ -82,7 +82,7 @@ Btrfs でイメージのレイヤ化と共有 サブボリュームはコピー・オン・ライトにネイティブに対応しており、必要があれば基礎をなすストレージ・プールから領域を割り当てます。また、領域はネスト（入れ子）にすることができ、スナップ化できます。次の図は４つのボリュームを表します。「サブボリューム４」は内部にディレクトリ・ツリーを持っているのに対し、「サブボリューム２」と「サブボリューム３」はネストされたものです。 .. image:: ./images/btrfs-subvolume.png - :scale: 60% + :width: 60% :alt: btrfs サブボリューム .. Snapshots are a point-in-time read-write copy of an entire subvolume. They exist directly below the subvolume they were created from. You can create snapshots of snapshots as shown in the diagram below. @@ -90,7 +90,7 @@ Btrfs でイメージのレイヤ化と共有 スナップショットとは、ある時点におけるサブボリューム全体の読み書きをコピーします。既存のディレクトリの下にサブボリュームを作成します。下図のように、スナップショットのスナップショットも作成できます。 .. image:: ./images/btrfs-snapshots.png - :scale: 60% + :width: 60% :alt: btrfs スナップショット .. Btfs allocates space to subvolumes and snapshots on demand from an underlying pool of storage. The unit of allocation is referred to as a chunk and chunks are normally ~1GB in size. @@ -102,7 +102,7 @@ Btrfs でイメージのレイヤ化と共有 スナップショットは Btrfs ファイルシステム上の優秀な機能です。つまり、通常のサブボリュームと同じ見た目と、感触、操作が可能です。ネイティブなコピー・オン・ライトの設計のおかげで、Btrfs ファイルシステム内のディレクトリにサブボリュームを構築する時、この技術が必要になります。つまり、Btrfs スナップショットは性能のオーバーヘッドが少ない、あるいは無いため、効率的に領域を使います。次の図はスナップショットが同じデータを共有しているサブボリュームです。 .. image:: ./images/btrfs-pool.png - :scale: 60% + :width: 60% :alt: btrfs プール .. Docker’s btrfs storage driver stores every image layer and container in its own Btrfs subvolume or snapshot. The base layer of an image is stored as a subvolume whereas child image layers and containers are stored as snapshots. This is shown in the diagram below. @@ -110,7 +110,7 @@ Btrfs でイメージのレイヤ化と共有 Docker の ``btrfs`` ストレージ・ドライバは、各イメージ・レイヤとコンテナを、自身の Btrfs サブボリュームかスナップショットに保管します。イメージのベース・レイヤはサブボリュームとして保管します。それに対して子イメージ・レイヤとコンテナは、スナップショットに保管します。これを説明したのが次の図です。 .. image:: ./images/btrfs-container-layer.png - :scale: 60% + :width: 60% :alt: btrfs コンテナ・レイヤ .. The high level process for creating images and containers on Docker hosts running the btrfs driver is as follows: @@ -134,7 +134,7 @@ Docker ホストが ``btrfs`` ドライバを使い、イメージとコンテ 以下の図は３つのイメージ・レイヤを表しています。ベース・レイヤはサブボリュームです。レイヤ１はベース・レイヤに対するサブボリュームのスナップショットです。レイヤ２はレイヤ１のスナップショットです。 .. image:: ./images/btrfs-constructs.png - :scale: 60% + :width: 60% :alt: ディスク構造上のイメージ .. As of Docker 1.10, image layer IDs no longer correspond to directory names under /var/lib/docker/. diff --git a/storage/storagedriver/device-mapper-driver.rst b/storage/storagedriver/device-mapper-driver.rst index 670562a32..08188315b 100644 --- a/storage/storagedriver/device-mapper-driver.rst +++ b/storage/storagedriver/device-mapper-driver.rst @@ -119,7 +119,7 @@ Device Mapper は Linux カーネルのバージョン 2.6.9 以降、メイン 以下のハイレベルな図は、ベース・デバイスのシン・プールと２つのイメージを表します。 .. image:: ./images/base-device.png - :scale: 60% + :width: 60% :alt: ベース・デバイス .. If you look closely at the diagram you’ll see that it’s snapshots all the way down. Each image layer is a snapshot of the layer below it. The lowest layer of each image is a snapshot of the base device that exists in the pool. This base device is a Device Mapper artifact and not a Docker image layer. @@ -131,7 +131,7 @@ Device Mapper は Linux カーネルのバージョン 2.6.9 以降、メイン コンテナとは、ここから作成したイメージのスナップショットです。下図は２つのコンテナです。一方は Ubuntu イメージをベースにし、もう一方は Busybox イメージをベースにしています。 .. image:: ./images/two-dm-container.png - :scale: 60% + :width: 60% :alt: ２つの Device Mapper 上のコンテナ @@ -147,7 +147,7 @@ devicemapper からの読み込み ``devicemapper`` ストレージ・ドライバが、どのように読み書きしているか見ていきましょう。下図は、サンプル・コンテナが単一のブロック（ ``0x44f`` ）を読み込むという、ハイレベルな手順です。 .. image:: ./images/dm-container.png - :scale: 60% + :width: 60% :alt: Device Mapper 上のコンテナ .. An application makes a read request for block 0x44f in the container. @@ -511,7 +511,7 @@ Docker Engine デーモンを起動したら、シン・プールとボリュー 下図は、先ほどの例で扱ったイメージの更新を、 ``lsblk`` コマンドの詳細とあわせて表しています。 .. image:: ./images/devicemapper-pool.png - :scale: 60% + :width: 60% :alt: ディスク構造上のイメージ .. In the diagram, the pool is named Docker-202:1-1032-pool and spans the data and metadata devices created earlier. The devicemapper constructs the pool name as follows: diff --git a/storage/storagedriver/index.rst b/storage/storagedriver/index.rst index c76b9ea49..e9c4165d9 100644 --- a/storage/storagedriver/index.rst +++ b/storage/storagedriver/index.rst @@ -72,7 +72,7 @@ Docker :ruby:`イメージ ` とは、積み重なる :ruby:`レイヤー レイヤーとは、各レイヤーの一番上に積み上げられます。新しいコンテナを作成すると、元のレイヤー上に新しい :ruby:`書き込み可能なレイヤー ` を追加します。このレイヤーは、たいてい「 :ruby:`コンテナ レイヤー ` 」と呼ばれます。新しいファイルの書き込み、既存ファイルの変更、ファイルの削除といった、実行中のコンテナに対する全ての変更は、この :ruby:`薄い ` 書き込み可能なコンテナ レイヤーに書き込まれます。下図は ``ubuntu:15.04`` イメージを元にするコンテナを表します。 .. image:: ./images/container-layers.png - :scale: 60% + :width: 60% :alt: Ubuntu イメージを元にするコンテナのレイヤー . . A storage driver handles the details about the way these layers interact with each other. Different storage drivers are available, which have advantages and disadvantages in different situations. @@ -94,7 +94,7 @@ Docker :ruby:`イメージ ` とは、積み重なる :ruby:`レイヤー それぞれのコンテナは、自身の書き込み可能なコンテナ レイヤーを持ちます。また、このコンテナ レイヤーに全ての変更が保存されます。そのため、複数のコンテナが同じ元イメージを共有しながらアクセスでき、さらに、それぞれが自身のデータ状態を持てます。下図は、複数のコンテナが同じ Ubuntu 15.04 イメージを共有するのを表します。 .. image:: ./images/sharing-layers.png - :scale: 60% + :width: 60% :alt: 複数のコンテナが同じイメージを共有 .. Note diff --git a/storage/storagedriver/overlayfs-driver.rst b/storage/storagedriver/overlayfs-driver.rst index 29240f74f..d22f68b81 100644 --- a/storage/storagedriver/overlayfs-driver.rst +++ b/storage/storagedriver/overlayfs-driver.rst @@ -75,7 +75,7 @@ OverlayFS は１つの Linux ホスト上で２つのディレクトリを扱い 下図は Docker イメージと Docker コンテナがレイヤ化されたものです。イメージ・レイヤは「下位ディレクトリ」であり、コンテナ・レイヤは「上位ディレクトリ」です。統一した表示は「マージされた」ディレクトリであり、これがコンテナに対する事実上のマウント・ポイントです。下図では Docker の構造が OverlayFS 構造にどのように割り当てられているか分かります。 .. image:: ./images/overlay-construct.png - :scale: 60% + :width: 60% :alt: OverlayFS の構造 .. Notice how the image layer and container layer can contain the same files. When this happens, the files in the container layer (“upperdir”) are dominant and obscure the existence of the same files in the image layer (“lowerdir”). The container mount (“merged”) presents the unified view. diff --git a/storage/storagedriver/zfs-driver.rst b/storage/storagedriver/zfs-driver.rst index dfcf573f0..cd60db5c5 100644 --- a/storage/storagedriver/zfs-driver.rst +++ b/storage/storagedriver/zfs-driver.rst @@ -74,7 +74,7 @@ Docker ``zfs`` ストレージ・ドライバは、３種類の豊富な ZFS デ ZFS ファイルシステムはシン・プロビジョニング（訳者注：データ書き込みの領域が、初期環境では薄く構築される）であり、ZFS プール（zpool）から要求処理があるごとに、領域を割り当てます。スナップショットとクローンは、その時々で ZFS ファイルシステムのコピーをするため、領域を効率的に使います。スナップショットは読み込み専用です。クローンは読み書きできます。クローンはスナップショットからのみ作成可能です。以下の図は、これらの関係性を簡単にしたものです。 .. image:: ./images/zfs-clones.png - :scale: 60% + :width: 60% :alt: ZFS のクローン .. The solid line in the diagram shows the process flow for creating a clone. Step 1 creates a snapshot of the filesystem, and step two creates the clone from the snapshot. The dashed line shows the relationship between the clone and the filesystem, via the snapshot. All three ZFS datasets draw space form the same underlying zpool. @@ -86,7 +86,7 @@ ZFS ファイルシステムはシン・プロビジョニング（訳者注： Docker ホストで ``zfs`` ストレージ・ドライバを使えば、イメージのベース・レイヤは ZFS ファイルシステムになります。それぞれの子レイヤとは、下にあるレイヤの ZFS スナップショットをベースとした ZFS クローンです。コンテナとは、作成するにあたってイメージの最上位レイヤの ZFS スナップショットをベースとした ZFS クローンです。全ての ZFS データセットは、共通の zpool から領域を取り込みます。以下の図は２つのレイヤ・イメージをベースにまとめたもので、コンテナを実行しています。 .. image:: ./images/zfs-pool.png - :scale: 60% + :width: 60% :alt: ZFS pool .. The following process explains how images are layered and containers created. The process is based on the diagram above. @@ -137,7 +137,7 @@ Docker ホストで ``zfs`` ストレージ・ドライバを使えば、イメ コンテナが ``zfs`` ストレージ・ドライバから読み込むのは、非常にシンプルです。直近で起動したコンテナは、ZFS クローンを元にしています。このクローンは作成時、まず全てのデータセットを共有します。つまり、 ``zfs`` ストレージ・ドライバの読み込み処理が高速なことを意味します。これは、読み込み対象のデータがコンテナ内にコピーされていなくてもです。データブロックの共有は、次のような図になります。 .. image:: ./images/zpool-blocks.png - :scale: 60% + :width: 60% :alt: ZFS zpool ブロック .. Writing new data to a container is accomplished via an allocate-on-demand operation. Every time a new area of the container needs writing to, a new block is allocated from the zpool. This means that containers consume additional space as new data is written to them. New space is allocated to the container (ZFS Clone) from the underlying zpool. diff --git a/storage/tmpfs.rst b/storage/tmpfs.rst index d8953999a..cc9668ac9 100644 --- a/storage/tmpfs.rst +++ b/storage/tmpfs.rst @@ -31,7 +31,7 @@ Linux 上で Docker を動かしている場合は、3つめのオプション ` ボリュームやバインドマウントとは違い、 ``tmpfs`` マウントは一時的なもので、ホストメモリ上にのみ保持します。コンテナを停止すると、 ``tmpfs`` マウントは削除され、また、書き込まれたデータは保持されません。 .. image:: ./images/types-of-mounts-tmpfs.png - :scale: 60% + :width: 60% :alt: Docker ホスト上の tmpfs .. This is useful to temporarily store sensitive files that you don’t want to persist in either the host or the container writable layer. diff --git a/storage/volumes.rst b/storage/volumes.rst index 0a3de192c..11ea6dea6 100644 --- a/storage/volumes.rst +++ b/storage/volumes.rst @@ -44,7 +44,7 @@ Docker コンテナによって作成され、かつ、使われるデータを 加えて、コンテナの書き込み可能なレイヤーにデータを保持するためには、ボリュームがより良い選択です。これは、ボリュームによってコンテナが使用する容量が増えませんし、対象となるコンテナのライフサイクル外でボリュームの内容が存在し続けます。 .. image:: ./images/todo-list-sample.png - :scale: 60% + :width: 60% :alt: Docker ホスト上のボリューム .. If your container generates non-persistent state data, consider using a tmpfs mount to avoid storing the data anywhere permanently, and to increase the container’s performance by avoiding writing into the container’s writable layer. @@ -466,7 +466,7 @@ compose でボリュームを使うための詳しい情報は、 :ref:`compose :ruby:`耐障害性 ` のアプリケーションを構築する場合は、同じファイルにアクセスするために、同じサービスにタイして複数のレプリカの設定が必要になるでしょう。 .. image:: ./images/volumes-shared-storage.png - :scale: 60% + :width: 60% :alt: 共有ストレージ .. There are several ways to achieve this when developing your applications. One is to add logic to your application to store files on a cloud object storage system like Amazon S3. Another is to create volumes with a driver that supports writing files to an external storage system like NFS or Amazon S3. diff --git a/swarm/configure-tls.rst b/swarm/configure-tls.rst index 9935fa3ca..1588ef28a 100644 --- a/swarm/configure-tls.rst +++ b/swarm/configure-tls.rst @@ -26,7 +26,7 @@ Docker Swarm の TLS 設定 この手順では下図のように、 Swarm クラスタにSwarm マネージャと認証局（CA）の２つのノードを作成します。全ての Docker Engine ホスト（ ``client`` 、 ``swarm`` 、 ``node1`` 、 ``node2`` ）は、認証局の証明書のコピーと、自分自身で認証局の署名をしたキーペアのコピーも持ちます。 .. image:: ./images/tls-1.png - :scale: 60% + :width: 60% 以下の手順で作業を進めていきます。 @@ -461,7 +461,7 @@ Docker Swarm の TLS 設定 コピーが完了したら、各マシンは以下の鍵を持ちます。 .. image:: ./images/tls-2.png - :scale: 60% + :width: 60% .. Each node in your infrastructure should have the following files in the /home/ubuntu/.certs/ directory: diff --git a/swarm/plan-for-production.rst b/swarm/plan-for-production.rst index 04061bcc4..56efb4947 100644 --- a/swarm/plan-for-production.rst +++ b/swarm/plan-for-production.rst @@ -179,7 +179,7 @@ Swarm のセカンダリ・マネージャは *ウォーム・スタンバイ* HA Swarm マネージャの作成時は、 *障害範囲 (failure domains)* の影響を受けないよう、可能な限り分散するよう注意を払う必要があります。障害範囲とは、デバイスまたはサービスに対する致命的な問題が発生すると影響があるネットワーク区分です。仮にクラスタが Amazon Web Services のアイルランド・リージョン（eu-west-1）で動いているとします。３つの Swarm マネージャを設定するにあたり（１つはプライマリ、２つはセカンダリ）、次の図のように各アベイラビリティ・ゾーンに置くべきでしょう。 .. image:: ./images/swarm-ha-cluster-aws.png - :scale: 60% + :width: 60% .. In this configuration, the Swarm cluster can survive the loss of any two availability zones. For your applications to survive such failures, they must be architected across as many failure domains as well. @@ -229,7 +229,7 @@ Consul 、 etcd 、 Zookeeper はどれもプロダクションにふさわし 次の図は HA を設定した Swarm クラスタ設定を表しています。３つの Swarm マネージャと３つのディスカバリ・サービス・インスタンスが３つの障害領域（アベイラビリティ・ゾーン）に展開してます。また、 Swarm ノードは３つの障害領域を横断しています。２つのアベイラビリティ・ゾーンで障害が発生したとしても、Swarm クラスタは停止しない設定を表しています。 .. image:: ./images/swarm-ha-cluster-discovery-aws.png - :scale: 60% + :width: 60% .. It is possible to share the same Consul, etcd, or Zookeeper containers between the Swarm discovery and Engine container networks. However, for best performance and availability you should deploy dedicated instances -- a discovery instance for Swarm and another for your container networks. @@ -247,7 +247,7 @@ Consul 、 etcd 、 Zookeeper はどれもプロダクションにふさわし Swarm クラスタを複数のクラウド・プロバイダを横断するよう設計・構築できます。これはパブリック・クラウドでも、オンプレミスの基盤でもです。次の図は Swarm クラスタを AWS と Azure に横断しています。 .. image:: ./images/swarm-across-aws-and-azure.png - :scale: 60% + :width: 60% .. While such architectures may appear to provide the ultimate in availability, there are several factors to consider. Network latency can be problematic, as can partitioning. As such, you should seriously consider technologies that provide reliable, high speed, low latency connections into these cloud platforms -- technologies such as AWS Direct Connect and Azure ExpressRoute. diff --git a/swarm/secure-swarm-tls.rst b/swarm/secure-swarm-tls.rst index 5b8d2d8a4..b17c13dc7 100644 --- a/swarm/secure-swarm-tls.rst +++ b/swarm/secure-swarm-tls.rst @@ -108,7 +108,7 @@ TLS 認証を使うためには、 Docker Engine CLI と Docker Engine デーモ また、Docker Engine デーモンも Docker Engine CLI が使う証明証を信頼する必要があります。信頼とは、通常は第三者の信頼機関によって担保されます。下図は Docker Engine CLI とデーモンが TLS 通信に必要となる設定です。 .. image:: ./images/trust-diagram.png - :scale: 60% + :width: 60% .. The trusted third party in this diagram is the the Certificate Authority (CA) server. Like the country in the passport example, a CA creates, signs, issues, revokes certificates. Trust is established by installing the CA’s root certificate on the host running the Docker Engine daemon. The Engine CLI then requests its own certificate from the CA server, which the CA server signs and issues to the client. diff --git a/swarm/swarm_at_scale/about.rst b/swarm/swarm_at_scale/about.rst index 5c9808b2b..458ce43a8 100644 --- a/swarm/swarm_at_scale/about.rst +++ b/swarm/swarm_at_scale/about.rst @@ -50,7 +50,7 @@ 投票アプリケーションは複数のマイクロサービスで構成されます。並列なウェブ・フロントエンドを使い、ジョブを非同期のバックグラウンド・ワーカに送ります。アプリケーションは任意に大きくスケール可能な設計です。次の図はアプリケーションのハイレベルなアーキテクチャです。 .. image:: ../images/app-architecture.png - :scale: 60% + :width: 60% .. All the servers are running Docker Engine. The entire application is fully “Dockerized” in that all services are running inside of containers. @@ -99,7 +99,7 @@ Swarm クラスタのアーキテクチャ アプリケーションをサポートするのは、次の図のように、１つの Swarm マネージャと４つのノードで構成する設計の Swarm クラスタです。 .. image:: ../images/swarm-cluster-arch.png - :scale: 60% + :width: 60% .. All four nodes in the cluster are running the Docker daemon, as is the Swarm manager and the load balancer. The Swarm manager is part of the cluster and is considered out of band for the application. A single host running the Consul server acts as a keystore for both Swarm discovery and for the container network. The load balancer could be placed inside of the cluster, but for this demonstration it is not. @@ -110,7 +110,7 @@ Swarm クラスタのアーキテクチャ サンプルとアプリケーションのデプロイを完了したら、皆さんの環境は下図のようになります。 .. image:: ../images/final-result.png - :scale: 60% + :width: 60% .. As the previous diagram shows, each node in the cluster runs the following containers: diff --git a/swarm/swarm_at_scale/deploy-app.rst b/swarm/swarm_at_scale/deploy-app.rst index d7d29c6ed..885a4d23a 100644 --- a/swarm/swarm_at_scale/deploy-app.rst +++ b/swarm/swarm_at_scale/deploy-app.rst @@ -30,7 +30,7 @@ 次の図は最終的なアプリケーション設定であり、 ``voteapp`` オーバレイ・コンテナ・ネットワークも含みます。 .. image:: ../images/final-result.png - :scale: 60% + :width: 60% .. In this procedure you will connect containers to this network. The voteapp network is available to all Docker hosts using the Consul discovery backend. Notice that the interlock, nginx, consul, and swarm manager containers on are not part of the voteapp overlay container network. diff --git a/swarm/swarm_at_scale/troubleshoot.rst b/swarm/swarm_at_scale/troubleshoot.rst index 6ff673d10..11d27d678 100644 --- a/swarm/swarm_at_scale/troubleshoot.rst +++ b/swarm/swarm_at_scale/troubleshoot.rst @@ -224,7 +224,7 @@ Swarm クラスタのアベイラビリティ・ゾーンを増やすには： この設定を反映したものが、次の図です。 .. image:: ../images/infrastructure-failures.png - :scale: 60% + :width: 60% .. This will allow us to lose an entire AZ and still have our cluster and application operate. @@ -239,7 +239,7 @@ Swarm クラスタのアベイラビリティ・ゾーンを増やすには： 以下の図はアプリケーションとインフラを AWS と Microsoft Azure にデプロイしたものです。ですが、クラウドプロバイダはデータセンタにあるオンプレミスに置き換えても構いません。これらのシナリオでは、ネットワークのレイテンシと信頼性がスムーズに動作させるための鍵となります。 .. image:: ../images/deployed-across.png - :scale: 60% + :width: 60% .. Related information diff --git a/toolbox/overview.rst b/toolbox/overview.rst index 16ea995dd..9d14d9c43 100644 --- a/toolbox/overview.rst +++ b/toolbox/overview.rst @@ -22,7 +22,7 @@ Docker Toolbox 概要 Docker Toolbox は Mac と Windows システム上に Docker 環境を迅速にインストールして起動します。 .. image:: ./images/toolbox-installer.png - :scale: 60% + :width: 60% :alt: Toolbox インストーラ .. What’s in the box