update docs docker-compose -> docker compose (#4463)

Co-authored-by: Imran Rahman <imranrahman.ix@gmail.com>

.github/ISSUE_TEMPLATE/bug.md

@@ -42,7 +42,7 @@ labels: bug
 
   - Python version, run `python3 -V`:
   - Docker version (if using Docker), run `docker --version`:
-  - docker-compose version (if using Docker), run `docker-compose --version`:
+  - docker compose version (if using Docker), run `docker compose --version`:
   - ...
 
 - Options selected and/or [replay file](https://cookiecutter.readthedocs.io/en/latest/advanced/replay.html):

docs/deployment-with-docker.rst

@@ -1,7 +1,7 @@
 Deployment with Docker
 ======================
 
-.. index:: deployment, docker, docker-compose, compose
+.. index:: deployment, docker, docker compose, compose
 
 
 Prerequisites
@@ -89,7 +89,7 @@ You can read more about this feature and how to configure it, at `Automatic HTTP
 Webpack without Whitenoise limitation
 -------------------------------------
 
-If you opt for Webpack without Whitenoise, Webpack needs to know the static URL at build time, when running ``docker-compose build`` (See ``webpack/prod.config.js``). Depending on your setup, this URL may come from the following environment variables:
+If you opt for Webpack without Whitenoise, Webpack needs to know the static URL at build time, when running ``docker compose build`` (See ``webpack/prod.config.js``). Depending on your setup, this URL may come from the following environment variables:
 
 - ``AWS_STORAGE_BUCKET_NAME``
 - ``DJANGO_AWS_S3_CUSTOM_DOMAIN``
@@ -107,7 +107,7 @@ To solve this, you can either:
 2. create a ``.env`` file in the root of the project with just variables you need. You'll need to also define them in ``.envs/.production/.django`` (hence duplicating them).
 3. set these variables when running the build command::
 
-     DJANGO_AWS_S3_CUSTOM_DOMAIN=example.com docker-compose -f production.yml build``.
+     DJANGO_AWS_S3_CUSTOM_DOMAIN=example.com docker compose -f production.yml build``.
 
 None of these options are ideal, we're open to suggestions on how to improve this. If you think you have one, please open an issue or a pull request.
 
@@ -122,42 +122,42 @@ Building & Running Production Stack
 
 You will need to build the stack first. To do that, run::
 
-    docker-compose -f production.yml build
+    docker compose -f production.yml build
 
 Once this is ready, you can run it with::
 
-    docker-compose -f production.yml up
+    docker compose -f production.yml up
 
 To run the stack and detach the containers, run::
 
-    docker-compose -f production.yml up -d
+    docker compose -f production.yml up -d
 
 To run a migration, open up a second terminal and run::
 
-   docker-compose -f production.yml run --rm django python manage.py migrate
+   docker compose -f production.yml run --rm django python manage.py migrate
 
 To create a superuser, run::
 
-   docker-compose -f production.yml run --rm django python manage.py createsuperuser
+   docker compose -f production.yml run --rm django python manage.py createsuperuser
 
 If you need a shell, run::
 
-   docker-compose -f production.yml run --rm django python manage.py shell
+   docker compose -f production.yml run --rm django python manage.py shell
 
 To check the logs out, run::
 
-   docker-compose -f production.yml logs
+   docker compose -f production.yml logs
 
 If you want to scale your application, run::
 
-   docker-compose -f production.yml up --scale django=4
-   docker-compose -f production.yml up --scale celeryworker=2
+   docker compose -f production.yml up --scale django=4
+   docker compose -f production.yml up --scale celeryworker=2
 
 .. warning:: don't try to scale ``postgres``, ``celerybeat``, or ``traefik``.
 
 To see how your containers are doing run::
 
-    docker-compose -f production.yml ps
+    docker compose -f production.yml ps
 
 
 Example: Supervisor
@@ -165,12 +165,12 @@ Example: Supervisor
 
 Once you are ready with your initial setup, you want to make sure that your application is run by a process manager to
 survive reboots and auto restarts in case of an error. You can use the process manager you are most familiar with. All
-it needs to do is to run ``docker-compose -f production.yml up`` in your projects root directory.
+it needs to do is to run ``docker compose -f production.yml up`` in your projects root directory.
 
 If you are using ``supervisor``, you can use this file as a starting point::
 
     [program:{{cookiecutter.project_slug}}]
-    command=docker-compose -f production.yml up
+    command=docker compose -f production.yml up
     directory=/path/to/{{cookiecutter.project_slug}}
     redirect_stderr=true
     autostart=true

docs/developing-locally-docker.rst

@@ -32,7 +32,7 @@ Build the Stack
 
 This can take a while, especially the first time you run this particular command on your development system::
 
-    $ docker-compose -f local.yml build
+    $ docker compose -f local.yml build
 
 Generally, if you want to emulate production environment use ``production.yml`` instead. And this is true for any other actions you might need to perform: whenever a switch is required, just do it!
 
@@ -51,7 +51,7 @@ This brings up both Django and PostgreSQL. The first time it is run it might tak
 
 Open a terminal at the project root and run the following for local development::
 
-    $ docker-compose -f local.yml up
+    $ docker compose -f local.yml up
 
 You can also set the environment variable ``COMPOSE_FILE`` pointing to ``local.yml`` like this::
 
@@ -59,11 +59,11 @@ You can also set the environment variable ``COMPOSE_FILE`` pointing to ``local.y
 
 And then run::
 
-    $ docker-compose up
+    $ docker compose up
 
 To run in a detached (background) mode, just::
 
-    $ docker-compose up -d
+    $ docker compose up -d
 
 
 The site should start and be accessible at http://localhost:3000 if you selected Webpack or Gulp as frontend pipeline and http://localhost:8000 otherwise.
@@ -71,10 +71,10 @@ The site should start and be accessible at http://localhost:3000 if you selected
 Execute Management Commands
 ---------------------------
 
-As with any shell command that we wish to run in our container, this is done using the ``docker-compose -f local.yml run --rm`` command: ::
+As with any shell command that we wish to run in our container, this is done using the ``docker compose -f local.yml run --rm`` command: ::
 
-    $ docker-compose -f local.yml run --rm django python manage.py migrate
-    $ docker-compose -f local.yml run --rm django python manage.py createsuperuser
+    $ docker compose -f local.yml run --rm django python manage.py migrate
+    $ docker compose -f local.yml run --rm django python manage.py createsuperuser
 
 Here, ``django`` is the target service we are executing the commands against.
 
@@ -156,8 +156,8 @@ You have to modify the relevant requirement file: base, local or production by a
 
 To get this change picked up, you'll need to rebuild the image(s) and restart the running container: ::
 
-    docker-compose -f local.yml build
-    docker-compose -f local.yml up
+    docker compose -f local.yml build
+    docker compose -f local.yml up
 
 Debugging
 ~~~~~~~~~
@@ -171,7 +171,7 @@ If you are using the following within your code to debug: ::
 
 Then you may need to run the following for it to work as desired: ::
 
-    $ docker-compose -f local.yml run --rm --service-ports django
+    $ docker compose -f local.yml run --rm --service-ports django
 
 
 django-debug-toolbar
@@ -316,7 +316,7 @@ You should allow the new hostname. ::
 
 Rebuild your ``docker`` application. ::
 
-  $ docker-compose -f local.yml up -d --build
+  $ docker compose -f local.yml up -d --build
 
 Go to your browser and type in your URL bar ``https://my-dev-env.local``
 

docs/docker-postgres-backups.rst

@@ -8,7 +8,7 @@ Prerequisites
 -------------
 
 #. the project was generated with ``use_docker`` set to ``y``;
-#. the stack is up and running: ``docker-compose -f local.yml up -d postgres``.
+#. the stack is up and running: ``docker compose -f local.yml up -d postgres``.
 
 
 Creating a Backup
@@ -16,7 +16,7 @@ Creating a Backup
 
 To create a backup, run::
 
-    $ docker-compose -f local.yml exec postgres backup
+    $ docker compose -f local.yml exec postgres backup
 
 Assuming your project's database is named ``my_project`` here is what you will see: ::
 
@@ -31,7 +31,7 @@ Viewing the Existing Backups
 
 To list existing backups, ::
 
-    $ docker-compose -f local.yml exec postgres backups
+    $ docker compose -f local.yml exec postgres backups
 
 These are the sample contents of ``/backups``: ::
 
@@ -55,9 +55,9 @@ With a single backup file copied to ``.`` that would be ::
 
     $ docker cp 9c5c3f055843:/backups/backup_2018_03_13T09_05_07.sql.gz .
 
-You can also get the container ID using ``docker-compose -f local.yml ps -q postgres`` so if you want to automate your backups, you don't have to check the container ID manually every time. Here is the full command ::
+You can also get the container ID using ``docker compose -f local.yml ps -q postgres`` so if you want to automate your backups, you don't have to check the container ID manually every time. Here is the full command ::
 
-    $ docker cp $(docker-compose -f local.yml ps -q postgres):/backups ./backups
+    $ docker cp $(docker compose -f local.yml ps -q postgres):/backups ./backups
 
 .. _`command`: https://docs.docker.com/engine/reference/commandline/cp/
 
@@ -66,7 +66,7 @@ Restoring from the Existing Backup
 
 To restore from one of the backups you have already got (take the ``backup_2018_03_13T09_05_07.sql.gz`` for example), ::
 
-    $ docker-compose -f local.yml exec postgres restore backup_2018_03_13T09_05_07.sql.gz
+    $ docker compose -f local.yml exec postgres restore backup_2018_03_13T09_05_07.sql.gz
 
 You will see something like ::
 
@@ -94,5 +94,5 @@ Backup to Amazon S3
 ----------------------------------
 For uploading your backups to Amazon S3 you can use the aws cli container. There is an upload command for uploading the postgres /backups directory recursively and there is a download command for downloading a specific backup. The default S3 environment variables are used. ::
 
-    $ docker-compose -f production.yml run --rm awscli upload
-    $ docker-compose -f production.yml run --rm awscli download backup_2018_03_13T09_05_07.sql.gz
+    $ docker compose -f production.yml run --rm awscli upload
+    $ docker compose -f production.yml run --rm awscli download backup_2018_03_13T09_05_07.sql.gz

docs/document.rst

@@ -11,7 +11,7 @@ After you have set up to `develop locally`_, run the following command from the
 
 If you set up your project to `develop locally with docker`_, run the following command: ::
 
-    $ docker-compose -f local.yml up docs
+    $ docker compose -f local.yml up docs
 
 Navigate to port 9000 on your host to see the documentation. This will be opened automatically at `localhost`_ for local, non-docker development.
 

docs/testing.rst

@@ -19,7 +19,7 @@ You will get a readout of the `users` app that has already been set up with test
 
 If you set up your project to `develop locally with docker`_, run the following command: ::
 
-   $ docker-compose -f local.yml run --rm django pytest
+   $ docker compose -f local.yml run --rm django pytest
 
 Targeting particular apps for testing in ``docker`` follows a similar pattern as previously shown above.
 
@@ -36,8 +36,8 @@ Once the tests are complete, in order to see the code coverage, run the followin
 
 If you're running the project locally with Docker, use these commands instead: ::
 
-   $ docker-compose -f local.yml run --rm django coverage run -m pytest
-   $ docker-compose -f local.yml run --rm django coverage report
+   $ docker compose -f local.yml run --rm django coverage run -m pytest
+   $ docker compose -f local.yml run --rm django coverage report
 
 .. note::
 

docs/troubleshooting.rst

@@ -24,13 +24,13 @@ Examples of logs::
 If you recreate the project multiple times with the same name, Docker would preserve the volumes for the postgres container between projects. Here is what happens:
 
 #. You generate the project the first time. The .env postgres file is populated with the random password
-#. You run the docker-compose and the containers are created. The postgres container creates the database based on the .env file credentials
+#. You run the docker compose and the containers are created. The postgres container creates the database based on the .env file credentials
 #. You "regenerate" the project with the same name, so the postgres .env file is populated with a new random password
-#. You run docker-compose. Since the names of the containers are the same, docker will try to start them (not create them from scratch i.e. it won't execute the Dockerfile to recreate the database). When this happens, it tries to start the database based on the new credentials which do not match the ones that the database was created with, and you get the error message above.
+#. You run docker compose. Since the names of the containers are the same, docker will try to start them (not create them from scratch i.e. it won't execute the Dockerfile to recreate the database). When this happens, it tries to start the database based on the new credentials which do not match the ones that the database was created with, and you get the error message above.
 
 To fix this, you can either:
 
-- Clear your project-related Docker cache with ``docker-compose -f local.yml down --volumes --rmi all``.
+- Clear your project-related Docker cache with ``docker compose -f local.yml down --volumes --rmi all``.
 - Use the Docker volume sub-commands to find volumes (`ls`_) and remove them (`rm`_).
 - Use the `prune`_ command to clear system-wide (use with care!).
 

tests/test_cookiecutter_generation.py

@@ -271,7 +271,7 @@ def test_djlint_check_passes(cookies, context_override):
     ["use_docker", "expected_test_script"],
     [
         ("n", "pytest"),
-        ("y", "docker-compose -f local.yml run django pytest"),
+        ("y", "docker compose -f local.yml run django pytest"),
     ],
 )
 def test_travis_invokes_pytest(cookies, context, use_docker, expected_test_script):
@@ -296,7 +296,7 @@ def test_travis_invokes_pytest(cookies, context, use_docker, expected_test_scrip
     ["use_docker", "expected_test_script"],
     [
         ("n", "pytest"),
-        ("y", "docker-compose -f local.yml run django pytest"),
+        ("y", "docker compose -f local.yml run django pytest"),
     ],
 )
 def test_gitlab_invokes_precommit_and_pytest(cookies, context, use_docker, expected_test_script):
@@ -323,7 +323,7 @@ def test_gitlab_invokes_precommit_and_pytest(cookies, context, use_docker, expec
     ["use_docker", "expected_test_script"],
     [
         ("n", "pytest"),
-        ("y", "docker-compose -f local.yml run django pytest"),
+        ("y", "docker compose -f local.yml run django pytest"),
     ],
 )
 def test_github_invokes_linter_and_pytest(cookies, context, use_docker, expected_test_script):

tests/test_docker.sh

@@ -15,28 +15,28 @@ cookiecutter ../../ --no-input --overwrite-if-exists use_docker=y "$@"
 cd my_awesome_project
 
 # make sure all images build
-docker-compose -f local.yml build
+docker compose -f local.yml build
 
 # run the project's type checks
-docker-compose -f local.yml run django mypy my_awesome_project
+docker compose -f local.yml run django mypy my_awesome_project
 
 # run the project's tests
-docker-compose -f local.yml run django pytest
+docker compose -f local.yml run django pytest
 
 # return non-zero status code if there are migrations that have not been created
-docker-compose -f local.yml run django python manage.py makemigrations --dry-run --check || { echo "ERROR: there were changes in the models, but migration listed above have not been created and are not saved in version control"; exit 1; }
+docker compose -f local.yml run django python manage.py makemigrations --dry-run --check || { echo "ERROR: there were changes in the models, but migration listed above have not been created and are not saved in version control"; exit 1; }
 
 # Test support for translations
-docker-compose -f local.yml run django python manage.py makemessages --all
+docker compose -f local.yml run django python manage.py makemessages --all
 
 # Make sure the check doesn't raise any warnings
-docker-compose -f local.yml run django python manage.py check --fail-level WARNING
+docker compose -f local.yml run django python manage.py check --fail-level WARNING
 
 # Generate the HTML for the documentation
-docker-compose -f local.yml run docs make html
+docker compose -f local.yml run docs make html
 
 # Run npm build script if package.json is present
 if [ -f "package.json" ]
 then
-    docker-compose -f local.yml run node npm run build
+    docker compose -f local.yml run node npm run build
 fi

{{cookiecutter.project_slug}}/.github/workflows/ci.yml

@@ -69,16 +69,16 @@ jobs:
       {%- if cookiecutter.use_docker == 'y' %}
 
       - name: Build the Stack
-        run: docker-compose -f local.yml build
+        run: docker compose -f local.yml build
 
       - name: Run DB Migrations
-        run: docker-compose -f local.yml run --rm django python manage.py migrate
+        run: docker compose -f local.yml run --rm django python manage.py migrate
 
       - name: Run Django Tests
-        run: docker-compose -f local.yml run django pytest
+        run: docker compose -f local.yml run django pytest
 
       - name: Tear down the Stack
-        run: docker-compose -f local.yml down
+        run: docker compose -f local.yml down
       {%- else %}
 
       - name: Set up Python

{{cookiecutter.project_slug}}/.gitlab-ci.yml

@@ -33,12 +33,12 @@ pytest:
   services:
     - docker:dind
   before_script:
-    - docker-compose -f local.yml build
+    - docker compose -f local.yml build
     # Ensure celerybeat does not crash due to non-existent tables
-    - docker-compose -f local.yml run --rm django python manage.py migrate
-    - docker-compose -f local.yml up -d
+    - docker compose -f local.yml run --rm django python manage.py migrate
+    - docker compose -f local.yml up -d
   script:
-    - docker-compose -f local.yml run django pytest
+    - docker compose -f local.yml run django pytest
   {%- else %}
   image: python:3.11
   tags:

{{cookiecutter.project_slug}}/.travis.yml

@@ -17,16 +17,16 @@ jobs:
     - name: "Django Test"
     {%- if cookiecutter.use_docker == 'y' %}
       before_script:
-        - docker-compose -v
+        - docker compose -v
         - docker -v
-        - docker-compose -f local.yml build
+        - docker compose -f local.yml build
         # Ensure celerybeat does not crash due to non-existent tables
-        - docker-compose -f local.yml run --rm django python manage.py migrate
-        - docker-compose -f local.yml up -d
+        - docker compose -f local.yml run --rm django python manage.py migrate
+        - docker compose -f local.yml up -d
       script:
-        - "docker-compose -f local.yml run django pytest"
+        - "docker compose -f local.yml run django pytest"
       after_failure:
-        - docker-compose -f local.yml logs
+        - docker compose -f local.yml logs
     {%- else %}
       before_install:
         - sudo apt-get update -qq

{{cookiecutter.project_slug}}/compose/production/aws/maintenance/download

@@ -3,7 +3,7 @@
 ### Download a file from your Amazon S3 bucket to the postgres /backups folder
 ###
 ### Usage:
-###     $ docker-compose -f production.yml run --rm awscli <1>
+###     $ docker compose -f production.yml run --rm awscli <1>
 
 set -o errexit
 set -o pipefail

{{cookiecutter.project_slug}}/compose/production/aws/maintenance/upload

@@ -3,7 +3,7 @@
 ### Upload the /backups folder to Amazon S3
 ###
 ### Usage:
-###     $ docker-compose -f production.yml run --rm awscli upload
+###     $ docker compose -f production.yml run --rm awscli upload
 
 set -o errexit
 set -o pipefail

{{cookiecutter.project_slug}}/compose/production/postgres/maintenance/backup

@@ -4,7 +4,7 @@
 ### Create a database backup.
 ###
 ### Usage:
-###     $ docker-compose -f <environment>.yml (exec |run --rm) postgres backup
+###     $ docker compose -f <environment>.yml (exec |run --rm) postgres backup
 
 
 set -o errexit

{{cookiecutter.project_slug}}/compose/production/postgres/maintenance/backups

@@ -4,7 +4,7 @@
 ### View backups.
 ###
 ### Usage:
-###     $ docker-compose -f <environment>.yml (exec |run --rm) postgres backups
+###     $ docker compose -f <environment>.yml (exec |run --rm) postgres backups
 
 
 set -o errexit

{{cookiecutter.project_slug}}/compose/production/postgres/maintenance/restore

@@ -7,7 +7,7 @@
 ###     <1> filename of an existing backup.
 ###
 ### Usage:
-###     $ docker-compose -f <environment>.yml (exec |run --rm) postgres restore <1>
+###     $ docker compose -f <environment>.yml (exec |run --rm) postgres restore <1>
 
 
 set -o errexit

{{cookiecutter.project_slug}}/docs/howto.rst

@@ -8,14 +8,14 @@ Documentation can be written as rst files in `{{cookiecutter.project_slug}}/docs
 
 {% if cookiecutter.use_docker == 'n' %}
 To build and serve docs, use the command::
-    
-    make livehtml 
-    
-from inside the `{{cookiecutter.project_slug}}/docs` directory. 
+
+    make livehtml
+
+from inside the `{{cookiecutter.project_slug}}/docs` directory.
 {% else %}
 To build and serve docs, use the commands::
-    
-    docker-compose -f local.yml up docs
+
+    docker compose -f local.yml up docs
 
 {% endif %}
 
@@ -34,12 +34,12 @@ For an in-use example, see the `page source <_sources/users.rst.txt>`_ for :ref:
 
 To compile all docstrings automatically into documentation source files, use the command:
     ::
-    
+
         make apidocs
 
 {% if cookiecutter.use_docker == 'y' %}
 This can be done in the docker container:
-    :: 
-        
+    ::
+
         docker run --rm docs make apidocs
 {% endif -%}

{{cookiecutter.project_slug}}/locale/README.md

@@ -3,7 +3,7 @@
 Start by configuring the `LANGUAGES` settings in `base.py`, by uncommenting languages you are willing to support. Then, translations strings will be placed in this folder when running:
 
 ```bash
-{% if cookiecutter.use_docker == 'y' %}docker-compose -f local.yml run --rm django {% endif %}python manage.py makemessages -all --no-location
+{% if cookiecutter.use_docker == 'y' %}docker compose -f local.yml run --rm django {% endif %}python manage.py makemessages -all --no-location
 ```
 
 This should generate `django.po` (stands for Portable Object) files under each locale `<locale name>/LC_MESSAGES/django.po`. Each translatable string in the codebase is collected with its `msgid` and need to be translated as `msgstr`, for example:
@@ -16,7 +16,7 @@ msgstr "utilisateurs"
 Once all translations are done, they need to be compiled into `.mo` files (stands for Machine Object), which are the actual binary files used by the application:
 
 ```bash
-{% if cookiecutter.use_docker == 'y' %}docker-compose -f local.yml run --rm django {% endif %}python manage.py compilemessages
+{% if cookiecutter.use_docker == 'y' %}docker compose -f local.yml run --rm django {% endif %}python manage.py compilemessages
 ```
 
 Note that the `.po` files are NOT used by the application directly, so if the `.mo` files are out of dates, the content won't appear as translated even if the `.po` files are up-to-date.