Update docs for Docker Compose v2 (#384)

docs/agents/barebones.rst

@@ -27,7 +27,7 @@ available arguments::
 Docker Compose
 ``````````````
 
-An example docker-compose configuration::
+An example docker compose configuration::
 
     ocs-barebones-1:
         image: simonsobs/ocs:latest

docs/agents/fake_data.rst

@@ -36,7 +36,7 @@ Docker Compose
 ``````````````
 
 The Fake Data Agent can also be run in a Docker container. An example
-docker-compose service configuration is shown here::
+docker compose service configuration is shown here::
 
     fake-data1:
         image: simonsobs/ocs:latest

docs/agents/influxdb_publisher.rst

@@ -39,7 +39,7 @@ Add an InfluxDBAgent to your OCS configuration file::
 Docker Compose
 ``````````````
 
-Add the InfluxDB Publisher Agent container to your docker-compose file::
+Add the InfluxDB Publisher Agent container to your docker compose file::
 
   ocs-influxdb-publisher:
     image: simonsobs/ocs:latest
@@ -50,7 +50,7 @@ Add the InfluxDB Publisher Agent container to your docker-compose file::
       - ${OCS_CONFIG_DIR}:/config:ro
 
 You will also need an instance of InfluxDB running somewhere on your network.
-This likely should go in a separate docker-compose file so that it remains
+This likely should go in a separate docker compose file so that it remains
 online at all times. An example compose file would look like::
 
   version: '3.7'
@@ -72,9 +72,9 @@ online at all times. An example compose file would look like::
         name: ocs-net
 
 .. note::
-    This separate docker-compose file setup depends on having a docker network
-    that connects your various docker-compose files. On a single-node setup
-    this can be accomplished with the network settings above in each docker-compose
+    This separate docker compose file setup depends on having a docker network
+    that connects your various docker compose files. On a single-node setup
+    this can be accomplished with the network settings above in each docker compose
     file.
 
     You then need to create the docker network with::

docs/agents/registry.rst

@@ -35,7 +35,7 @@ An example site-config-file block::
 Docker Compose
 ``````````````
 
-An example docker-compose configuration::
+An example docker compose configuration::
 
     ocs-registry:
         image: simonsobs/ocs:latest

docs/developer/agent_references/documentation.rst

@@ -125,7 +125,7 @@ separate `.rst` file.  Each Agent reference page must contain:
 
 * Brief description of the Agent
 * Example ocs-site-config configuration block
-* Example docker-compose configuration block (if Agent is dockerized)
+* Example docker compose configuration block (if Agent is dockerized)
 * Agent API reference
 
 Reference pages can also include:

docs/developer/agent_references/logging.rst

@@ -53,7 +53,7 @@ this to your Agent use::
         # Start logging
         txaio.start_logging(level=environ.get("LOGLEVEL", "info"))
 
-Then, in your docker-compose configuration file you can set the log level by
+Then, in your docker compose configuration file you can set the log level by
 adding the environment block to your Agent's configuration::
 
     environment:

docs/developer/writing_an_agent/docker.rst

@@ -98,7 +98,7 @@ the BarbonesAgent config to the ``ocs-docker`` host.:
         ]
       }
 
-We also need to add a configuration block to our docker-compose file:
+We also need to add a configuration block to our docker compose file:
 
 .. code-block:: yaml
 
@@ -120,11 +120,11 @@ current directory (``./``) outside of the container to ``/config`` within the
 container, and do so read-only. Lastly, "environment" sets environment
 variables within the container, in this case the instance-id and log level.
 
-Now we can run the Agent with ``docker-compose``:
+Now we can run the Agent with ``docker compose``:
 
 .. code-block:: bash
 
-    $ docker-compose up -d
+    $ docker compose up -d
 
 Once the containers have started, you can see the running containers with:
 

docs/user/centralized_management.rst

@@ -33,7 +33,7 @@ fully configured, the system provides the following functionality:
     processes so that it can monitor their states more easily.  For
     Agents running in docker containers, HostManager takes charge of
     the implicated containers and there will be conflicts if users
-    also try to use ``docker-compose`` to restart containers.
+    also try to use ``docker compose`` to restart containers.
 
 The main components of this system are:
 
@@ -134,7 +134,7 @@ Config for docker pseudo-hosts
 
 Considering the Example Config from :ref:`ocs_site_config_file`, the
 host ``host-1-docker`` describes agents that are launched in
-containers using ``docker-compose``.  For HostManager to best manage
+containers using ``docker compose``.  For HostManager to best manage
 these agents, a HostManager should be described in this same host
 config block.  The HostManager won't run in a docker container -- it
 will run on the host system.  In this case the HostManager should have
@@ -179,7 +179,7 @@ of the host-1 block.)
 .. note::
 
    The HostManager process must be running as a user with sufficient
-   privileges to run ``docker`` and ``docker-compose``.  Usually that
+   privileges to run ``docker`` and ``docker compose``.  Usually that
    means that the user must be root, or must be in the "docker" user
    group.  The recommendation is that you add the :ref:`OCS user
    <create_ocs_user>` to the docker group (see
@@ -336,7 +336,7 @@ that HostManager will try to achieve for that Agent.  So if
 restarting the Agent if it crashes or otherwise terminates.  If
 ``target=down`` then the HostManager will stop the Agent and not
 restart it.  (Note that in the case of Agents in docker containers,
-the HostManager will use docker and docker-compose to monitor the
+the HostManager will use docker and docker compose to monitor the
 state of containers, and request start or stop in order to match the
 target state.)
 

docs/user/crossbar_config.rst

@@ -67,7 +67,7 @@ starts up:
 - OCS_CROSSBAR_PORT (default 8001): the port on which crossbar will
   accept requests.
 
-Here is an example of a docker-compose entry that overrides the
+Here is an example of a docker compose entry that overrides the
 OCS_ADDRESS_ROOT::
 
       crossbar:
@@ -82,7 +82,7 @@ Bind Mounting the Configuration
 -------------------------------
 To instead mount a new configuration into the pre-built image, first chown
 your file to be owned by user and group 242 (the default crossbar UID/GID),
-then mount it appropriately in your docker-compose file. Here we assume you
+then mount it appropriately in your docker compose file. Here we assume you
 put the configuration in the directory ``./dot_crossbar/``::
 
     $ chown -R 242:242 dot_crossbar/
@@ -91,7 +91,7 @@ put the configuration in the directory ``./dot_crossbar/``::
     If you do not already have a configuration file to modify and use, see the
     next section on generating one.
 
-Your docker-compose service should then be configured like::
+Your docker compose service should then be configured like::
 
     crossbar:
       image: simonsobs/ocs-crossbar

docs/user/dependencies.rst

@@ -29,7 +29,7 @@ Other Dependencies
 * `crossbar.io`_ - An implementation of a WAMP router.
 * Docker_ - Containerization software used for deploying several SO written
   packages.
-* `Docker Compose`_ - CLI tool for running multi-container Docker
+* `Docker Compose`_ - Docker plugin for running multi-container Docker
   applications.
 
 Crossbar may be installed via pip if it will be used without Docker; if it

docs/user/docker_config.rst

@@ -17,7 +17,7 @@ Docker Compose configuration file defines the containers that we will control.
 
 .. note::
     The filename is important here, as the `docker-compose.yaml` path is the
-    default one parsed by the docker-compose tool. A configuration file can be
+    default one parsed by the docker compose tool. A configuration file can be
     specified with the `-f` flag.
 
 Details about configuring individual Agents can be found in the Agent Reference
@@ -110,7 +110,7 @@ format of the file, for details on syntax you are encouraged to check the
 official documentation.
 
 In the remainder of this section we will go over our example. The first line
-defines the version of the docker-compose file format, which corresponds to the
+defines the version of the docker compose file format, which corresponds to the
 Docker Engine version you are running. You likely do not have to change this,
 unless you need a new feature available in a more recent version.
 
@@ -138,7 +138,7 @@ other container configurations::
       - "database"
 
 The top line, ``example-container-name``, defines the name of the service to
-docker-compose. These must be unique. ``image`` defines the docker image used
+docker compose. These must be unique. ``image`` defines the docker image used
 for the container. Associated with the image is the image tag, in this case
 "latest". This defines the version of the image. A container can be thought of
 as a copy of an image. The container is what actually runs when you startup
@@ -173,14 +173,14 @@ start before starting this container. This does not mean the services will be
 ready, but the container will be started.
 
 .. note::
-    Environment variables can be used within a docker-compose configuration
+    Environment variables can be used within a docker compose configuration
     file. This is done for the `OCS_CONFIG_DIR` mount for the OCS agents in the
     default template.  For more information see the `docker compose
     documentation`_.
 
     If you use this functionality, be aware that environment variables must be
     explicitly passed to sudo via the ``-E`` flag, for example: ``$ sudo -E
-    docker-compose up -d``
+    docker compose up -d``
 
 For more details on configurations for individual containers, see the service
 documentation pages, for instance in the Agent Reference section.

docs/user/installation.rst

@@ -45,8 +45,8 @@ install see the `Docker Compose`_ documentation.
 
 When complete you should be able to run::
 
-    $ docker-compose --version
-    docker-compose version 1.22.0, build 1719ceb
+    $ docker compose version
+    Docker Compose version v2.25.0
 
 .. note::
 

docs/user/intro.rst

@@ -50,7 +50,7 @@ OCS components are available on `Dockerhub <https://hub.docker.com/u/simonsobs>`
 For more information about Docker we refer here to the Docker documentation:
 
 * `Docker Documentation <https://docs.docker.com/>`_ - General Docker documentation.
-* `docker-compose Documentation <https://docs.docker.com/compose/>`_ - docker-compose, for running multi-container applications like OCS.
+* `Docker Compose Documentation <https://docs.docker.com/compose/>`_ - Docker Compose, for running multi-container applications like OCS.
 
 We will cover basic use of docker and associated commands in the context of
 running OCS throughout the guide, but for more details on these and additional

docs/user/logging.rst

@@ -86,7 +86,7 @@ the logging driver in the Docker daemon configuration. For more details see the
 .. note::
     Once the loki logging driver is installed and configured access to logs
     should still be accessible via ``docker logs``, however it is no longer
-    available via ``docker-compose logs``. You will instead see a warning::
+    available via ``docker compose logs``. You will instead see a warning::
 
         WARNING: no logs are available with the 'loki' log driver
 

docs/user/network.rst

@@ -91,7 +91,7 @@ Once you have created the bridge network, in each of your
         external:
           name: ocs-net
 
-After restarting your various docker-compose services containers that are split
+After restarting your various docker compose services containers that are split
 among multiple compose files should now be able to communicate using the names
 given to each service within each compose file, i.e. all services should be
 able to resolve "crossbar" instead of requiring an explicit IP address for the

docs/user/quickstart.rst

@@ -158,9 +158,9 @@ Running
 -------
 
 Now that the system is configured, we can start it with a single
-``docker-compose`` command::
+``docker compose`` command::
 
-    $ sudo -E docker-compose up -d
+    $ sudo -E docker compose up -d
     Creating network "ocs-site-configs_default" with the default driver
     Creating ocs-site-configs_ocs-influx-publisher_1 ... done
     Creating ocs-site-configs_grafana_1              ... done
@@ -226,7 +226,7 @@ Shutdown
 --------
 If you'd just like to shutdown the example you can run::
 
-    $ sudo docker-compose down
+    $ sudo docker compose down
 
 This will shutdown and remove all the containers.
 
@@ -247,4 +247,4 @@ And remove them with::
 If you would like to totally remove all trace of your OCS instance, including
 the storage volumes, run::
 
-    $ sudo docker-compose down --volumes
+    $ sudo docker compose down --volumes

example/docs/agent_template.rst

@@ -39,7 +39,7 @@ An example site-config-file block::
 Docker Compose
 ``````````````
 
-An example docker-compose configuration::
+An example docker compose configuration::
 
     ocs-template:
         image: simonsobs/ocs-template-agent:latest

tests/README.rst

@@ -75,13 +75,13 @@ Since the integration tests depend on docker containers you need to have the
 docker images built prior to running the tests. You can build all of the docker
 images from the root of the ocs repo::
 
-  $ docker-compose build
+  $ docker compose build
 
 However, if you're making changes to the core of OCS, having to rebuild all
 images with every change prior to running the tests quickly becomes time
 consuming. To avoid having to do the rebuild, you can mount the local copy of
 ocs over the one in the container, located at ``/app/ocs/``. To do this, add a
-new volume to the docker-compose file in this tests directory for the
+new volume to the docker compose file in this tests directory for the
 Agent/container you are working on. For example, in the fake-data-agent::
 
   fake-data1: