mirror of https://github.com/docker/docs.git
Replace docker-compose calls (#17881)
* use 'docker compose' instead of 'docker-compose' in Swarm documentation Signed-off-by: Guillaume Lours <705411+glours@users.noreply.github.com> * replace old usages of 'docker-compose' by 'docker compose' Signed-off-by: Guillaume Lours <705411+glours@users.noreply.github.com> --------- Signed-off-by: Guillaume Lours <705411+glours@users.noreply.github.com>
This commit is contained in:
parent
84c255bcf7
commit
b92ebe5fbf
|
@ -122,7 +122,7 @@ COPY --from=generate /out /
|
|||
# When the image is run, it starts Nginx and serves the docs at port 4000:
|
||||
# > make deploy
|
||||
# or
|
||||
# > docker-compose up --build
|
||||
# > docker compose up --build
|
||||
FROM nginx:alpine AS deploy
|
||||
COPY --from=release / /usr/share/nginx/html
|
||||
COPY _deploy/nginx/default.conf /etc/nginx/conf.d/default.conf
|
||||
|
|
|
@ -43,7 +43,7 @@ We support these broad categories of callouts:
|
|||
> Removing Volumes
|
||||
>
|
||||
> By default, named volumes in your compose file are NOT removed when running
|
||||
> `docker-compose down`. If you want to remove the volumes, you will need to add
|
||||
> `docker compose down`. If you want to remove the volumes, you will need to add
|
||||
> the `--volumes` flag.
|
||||
>
|
||||
> The Docker Dashboard does not remove volumes when you delete the app stack.
|
||||
|
@ -91,7 +91,7 @@ For both of the following callouts, consult [the Docker release lifecycle](/rele
|
|||
> Removing Volumes
|
||||
>
|
||||
> By default, named volumes in your compose file are NOT removed when running
|
||||
> `docker-compose down`. If you want to remove the volumes, you will need to add
|
||||
> `docker compose down`. If you want to remove the volumes, you will need to add
|
||||
> the `--volumes` flag.
|
||||
>
|
||||
> The Docker Dashboard does _not_ remove volumes when you delete the app stack.
|
||||
|
|
|
@ -12,7 +12,7 @@ The easiest way to deploy Notary Server is by using Docker Compose. To follow th
|
|||
|
||||
2. Build and start Notary Server with the sample certificates.
|
||||
|
||||
docker-compose up -d
|
||||
docker compose up -d
|
||||
|
||||
|
||||
For more detailed documentation about how to deploy Notary Server, see the [instructions to run a Notary service](https://github.com/theupdateframework/notary/blob/master/docs/running_a_service.md){:target="_blank" rel="noopener" class="_"} as well as [the Notary repository](https://github.com/theupdateframework/notary){:target="_blank" rel="noopener" class="_"} for more information.
|
||||
|
|
|
@ -115,7 +115,7 @@ the `trustsandbox` container, the Notary server, and the Registry server.
|
|||
|
||||
5. Run the containers on your local system.
|
||||
|
||||
$ docker-compose up -d
|
||||
$ docker compose up -d
|
||||
|
||||
The first time you run this, the docker-in-docker, Notary server, and registry
|
||||
images are downloaded from Docker Hub.
|
||||
|
@ -289,4 +289,4 @@ When you are done, and want to clean up all the services you've started and any
|
|||
anonymous volumes that have been created, just run the following command in the
|
||||
directory where you've created your Docker Compose file:
|
||||
|
||||
$ docker-compose down -v
|
||||
$ docker compose down -v
|
||||
|
|
|
@ -136,7 +136,7 @@ counter whenever you visit it.
|
|||
|
||||
## Test the app with Compose
|
||||
|
||||
1. Start the app with `docker-compose up`. This builds the web app image,
|
||||
1. Start the app with `docker compose up`. This builds the web app image,
|
||||
pulls the Redis image if you don't already have it, and creates two
|
||||
containers.
|
||||
|
||||
|
@ -145,7 +145,7 @@ counter whenever you visit it.
|
|||
single node. You can safely ignore this.
|
||||
|
||||
```none
|
||||
$ docker-compose up -d
|
||||
$ docker compose up -d
|
||||
|
||||
WARNING: The Docker Engine you're using is running in swarm mode.
|
||||
|
||||
|
@ -161,10 +161,10 @@ counter whenever you visit it.
|
|||
Creating stackdemo_web_1
|
||||
```
|
||||
|
||||
2. Check that the app is running with `docker-compose ps`:
|
||||
2. Check that the app is running with `docker compose ps`:
|
||||
|
||||
```console
|
||||
$ docker-compose ps
|
||||
$ docker compose ps
|
||||
|
||||
Name Command State Ports
|
||||
-----------------------------------------------------------------------------------
|
||||
|
@ -188,7 +188,7 @@ counter whenever you visit it.
|
|||
3. Bring the app down:
|
||||
|
||||
```console
|
||||
$ docker-compose down --volumes
|
||||
$ docker compose down --volumes
|
||||
|
||||
Stopping stackdemo_web_1 ... done
|
||||
Stopping stackdemo_redis_1 ... done
|
||||
|
@ -204,7 +204,7 @@ To distribute the web app's image across the swarm, it needs to be pushed to the
|
|||
registry you set up earlier. With Compose, this is very simple:
|
||||
|
||||
```console
|
||||
$ docker-compose push
|
||||
$ docker compose push
|
||||
|
||||
Pushing web (127.0.0.1:5000/stackdemo:latest)...
|
||||
The push refers to a repository [127.0.0.1:5000/stackdemo]
|
||||
|
|
|
@ -15,7 +15,7 @@ from the swarm manager. It also means the manager stops tasks running on the
|
|||
node and launches replica tasks on a node with `ACTIVE` availability.
|
||||
|
||||
> **Important**: Setting a node to `DRAIN` does not remove standalone containers from that node,
|
||||
> such as those created with `docker run`, `docker-compose up`, or the Docker Engine
|
||||
> such as those created with `docker run`, `docker compose up`, or the Docker Engine
|
||||
> API. A node's status, including `DRAIN`, only affects the node's ability to schedule
|
||||
> swarm service workloads.
|
||||
{:.important}
|
||||
|
|
|
@ -10,7 +10,7 @@ We're not going to go deep-dive here, but here are a few other areas to look at
|
|||
## Container orchestration
|
||||
|
||||
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
|
||||
`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.
|
||||
|
||||
|
|
|
@ -381,7 +381,7 @@ Another really cool feature of using a Compose file is that we have service reso
|
|||
Now, to start our application and to confirm that it is running properly, run the following command:
|
||||
|
||||
```console
|
||||
$ docker-compose up --build
|
||||
$ docker compose up --build
|
||||
```
|
||||
|
||||
We pass the `--build` flag so Docker will compile our image and then start the containers.
|
||||
|
@ -390,19 +390,19 @@ Now let’s test our application. Using a web browser, access `http://localhost:
|
|||
|
||||
## Shutting down
|
||||
|
||||
To stop the containers started by Docker Compose, press Ctrl+C in the terminal where we ran `docker-compose up`. To remove those containers after they have been stopped, run `docker-compose down`.
|
||||
To stop the containers started by Docker Compose, press Ctrl+C in the terminal where we ran `docker compose up`. To remove those containers after they have been stopped, run `docker compose down`.
|
||||
|
||||
## Detached mode
|
||||
|
||||
You can run containers started by the `docker-compose` command in detached mode, just as you would with the docker command, by using the `-d` flag.
|
||||
You can run containers started by the `docker compose` command in detached mode, just as you would with the docker command, by using the `-d` flag.
|
||||
|
||||
To start the stack, defined by the Compose file in detached mode, run:
|
||||
|
||||
```console
|
||||
docker-compose up --build -d
|
||||
docker compose up --build -d
|
||||
```
|
||||
|
||||
Then, you can use `docker-compose stop` to stop the containers and `docker-compose down` to remove them.
|
||||
Then, you can use `docker compose stop` to stop the containers and `docker compose down` to remove them.
|
||||
|
||||
## The `.env` file
|
||||
|
||||
|
@ -444,7 +444,7 @@ volumes:
|
|||
Build and run your application to confirm the changes are applied properly.
|
||||
|
||||
```console
|
||||
$ docker-compose up --build -d
|
||||
$ docker compose up --build -d
|
||||
```
|
||||
|
||||
Now let’s test our application. Using a web browser, access `http://localhost:5000` to view the page.
|
||||
|
|
|
@ -588,7 +588,7 @@ The exact value does not really matter for our example, because we run Cockroach
|
|||
|
||||
### Merging Compose files
|
||||
|
||||
The file name `docker-compose.yml` is the default file name which `docker-compose` command recognises if no `-f` flag is provided. This means you can have multiple Docker Compose files if your environment has such requirements. Furthermore, Docker Compose files are... composable (pun intended), so multiple files can be specified on the command line to merge parts of the configuration together. The following list is just a few examples of scenarios where such a feature would be very useful:
|
||||
The file name `docker-compose.yml` is the default file name which `docker compose` command recognises if no `-f` flag is provided. This means you can have multiple Docker Compose files if your environment has such requirements. Furthermore, Docker Compose files are... composable (pun intended), so multiple files can be specified on the command line to merge parts of the configuration together. The following list is just a few examples of scenarios where such a feature would be very useful:
|
||||
|
||||
* Using a bind mount for the source code for local development but not when running the CI tests;
|
||||
* Switching between using a pre-built image for the frontend for some API application vs creating a bind mount for source code;
|
||||
|
@ -611,7 +611,7 @@ Other ways of dealing with undefined or empty values exist, as documented in the
|
|||
Before you apply changes made to a Compose configuration file, there is an opportunity to validate the content of the configuration file with the following command:
|
||||
|
||||
```console
|
||||
$ docker-compose config
|
||||
$ docker compose config
|
||||
```
|
||||
|
||||
When this command is run, Docker Compose would read the file `docker-compose.yml`, parse it into a data structure in memory, validate where possible, and print back the _reconstruction_ of that configuration file from its internal representation. If this is not possible due to errors, it would print an error message instead.
|
||||
|
@ -621,14 +621,14 @@ When this command is run, Docker Compose would read the file `docker-compose.yml
|
|||
Let’s start our application and confirm that it is running properly.
|
||||
|
||||
```console
|
||||
$ docker-compose up --build
|
||||
$ docker compose up --build
|
||||
```
|
||||
|
||||
We pass the `--build` flag so Docker will compile our image and then starts it.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Docker Compose is a useful tool, but it has its own quirks. For example, no rebuild is triggered on the update to the source code unless the `--build` flag is provided. It is a very common pitfall to edit one's source code, and forget to use the `--build` flag when running `docker-compose up`.
|
||||
> Docker Compose is a useful tool, but it has its own quirks. For example, no rebuild is triggered on the update to the source code unless the `--build` flag is provided. It is a very common pitfall to edit one's source code, and forget to use the `--build` flag when running `docker compose up`.
|
||||
|
||||
Since our set-up is now run by Docker Compose, it has assigned it a "project name", so we got a new volume for our CockroachDB instance. This means that our application would fail to connect to the database, because the database does not exist in this new volume. The terminal would display an authentication error for the database:
|
||||
|
||||
|
@ -693,23 +693,23 @@ Hello, Docker! (0)
|
|||
|
||||
### Shutting down
|
||||
|
||||
To _stop_ the containers started by Docker Compose, press ctrl+c in the terminal where we run `docker-compose up`. To _remove_ those containers after they had been stopped, run `docker-compose down`.
|
||||
To _stop_ the containers started by Docker Compose, press ctrl+c in the terminal where we run `docker compose up`. To _remove_ those containers after they had been stopped, run `docker compose down`.
|
||||
|
||||
### Detached mode
|
||||
|
||||
You can run containers started by the `docker-compose` command in detached mode, just as you would with the `docker` command, by using the `-d` flag.
|
||||
You can run containers started by the `docker compose` command in detached mode, just as you would with the `docker` command, by using the `-d` flag.
|
||||
|
||||
To start the stack, defined by the Compose file in detached mode, run:
|
||||
|
||||
```console
|
||||
$ docker-compose up --build -d
|
||||
$ docker compose up --build -d
|
||||
```
|
||||
|
||||
Then, you can use `docker-compose stop` to stop the containers and `docker-compose down` to remove them.
|
||||
Then, you can use `docker compose stop` to stop the containers and `docker compose down` to remove them.
|
||||
|
||||
## Further exploration
|
||||
|
||||
We would suggest running `docker-compose` to see what other commands are available.
|
||||
We would suggest running `docker compose` to see what other commands are available.
|
||||
|
||||
## Wrap up
|
||||
|
||||
|
|
|
@ -168,7 +168,7 @@ Another really cool feature of using a Compose file is that we have service reso
|
|||
Now, to start our application and to confirm that it is running properly.
|
||||
|
||||
```console
|
||||
$ docker-compose -f docker-compose.dev.yml up --build
|
||||
$ docker compose -f docker-compose.dev.yml up --build
|
||||
```
|
||||
|
||||
We pass the `--build` flag so Docker will compile our image and then starts the containers. You should see similar output if it runs successfully:
|
||||
|
|
|
@ -213,7 +213,7 @@ We expose port 8000 so that we can reach the dev web server inside the container
|
|||
|
||||
Another really cool feature of using a Compose file is that we have service resolution set up to use the service names. Therefore, we are now able to use “mysqldb” in our connection string. The reason we use “mysqldb” is because that is what we've named our MySQL service as in the Compose file.
|
||||
|
||||
Note that we did not specify a network for those 2 services. When we use docker-compose it automatically creates a network and connect the services to it. For more information see [Networking in Compose](../../compose/networking.md)
|
||||
Note that we did not specify a network for those 2 services. When we use Docker Compose it automatically creates a network and connect the services to it. For more information see [Networking in Compose](../../compose/networking.md)
|
||||
|
||||
If you have any containers running from the previous sections, [stop](./run-containers.md/#stop-start-and-name-containers) them now.
|
||||
|
||||
|
|
|
@ -509,7 +509,7 @@ Start your registry by issuing the following command in the directory containing
|
|||
the `docker-compose.yml` file:
|
||||
|
||||
```console
|
||||
$ docker-compose up -d
|
||||
$ docker compose up -d
|
||||
```
|
||||
|
||||
## Considerations for air-gapped registries
|
||||
|
|
|
@ -193,7 +193,7 @@ EOF
|
|||
|
||||
Now, start your stack:
|
||||
|
||||
docker-compose up -d
|
||||
docker compose up -d
|
||||
|
||||
Log in with a "push" authorized user (using `testuserpush` and `testpasswordpush`), then tag and push your first image:
|
||||
|
||||
|
|
|
@ -193,7 +193,7 @@ Review the [requirements](index.md#requirements), then follow these steps.
|
|||
|
||||
Now, start your stack:
|
||||
|
||||
docker-compose up -d
|
||||
docker compose up -d
|
||||
|
||||
Login with a "push" authorized user (using `testuser` and `testpassword`), then
|
||||
tag and push your first image:
|
||||
|
|
Loading…
Reference in New Issue