Merge pull request #3728 from uselagoon/docs/docker-compose-v2

docs: replace all docker-compose v1 references

docs/applications/drupal/drush-9.md

@@ -25,7 +25,7 @@ In order to be able to use `drush site:alias-convert` , you need to do the follo
 You can now convert your Drush aliases by running the following command in your project using the `cli` container:
 
 ```bash title="Generate Site Aliases"
-docker-compose exec cli drush site:alias-convert /app/drush/sites --yes
+docker compose exec cli drush site:alias-convert /app/drush/sites --yes
 ```
 
 It's good practice to commit the resulting YAML files into your Git repository, so that they are in place for your fellow developers.

docs/applications/drupal/phpunit-and-phpstorm.md

@@ -38,7 +38,7 @@
    * Server: `<DOCKER>`
    * Configuration file\(s\): `./docker-compose.yml`
    * Service: `cli`
-   * Lifecycle: `Connect to existing container ('docker-compose exec')`
+   * Lifecycle: `Connect to existing container ('docker compose exec')`
 5. Path mappings:
    * Local path: `<ROOT_PATH>`
    * Remote path\*: `/app`
@@ -79,7 +79,7 @@
 
 ### Some final checks to run before you run a test
 
-1. You have the project up and running:  `$ docker-compose up -d`
+1. You have the project up and running:  `$ docker compose up -d`
 2. The project is working without any errors, visit the site just to make sure it all works as expected - this is not 100% necessary, but nice to know it is working normally.
 3. We should be ready to run some tests!
 

docs/applications/drupal/services/mariadb.md

@@ -37,10 +37,10 @@ $ docker port drupal_example_mariadb_1
 
 Or via `docker-compose` inside a Drupal repository:
 
-Run: `docker-compose port [service_name] [interal_port]`.
+Run: `docker compose port [service_name] [interal_port]`.
 
 ```bash title="Set ports"
-docker-compose port mariab 3306
+docker compose port mariab 3306
 0.0.0.0:32797
 ```
 

docs/applications/drupal/services/varnish.md

@@ -85,7 +85,7 @@ To test Varnish locally, change the following in `docker-compose.yml`:
 
 * Set `VARNISH_BYPASS` to `false` in the Varnish service section.
 * Set `LAGOON_ENVIRONMENT_TYPE` to `production` in the `x-environment` section.
-* Run `docker-compose up -d` , which restarts all services with the new environment variables.
+* Run `docker compose up -d` , which restarts all services with the new environment variables.
 
 Now you should be able to test Varnish!
 <!-- markdown-link-check-disable -->
@@ -127,6 +127,6 @@ Varnish doesn't cache? Or something else not working? Here a couple of ways to d
 <!-- markdown-link-check-disable -->
 * Run `drush p-debug-en` to enable debug logging of the purge module. This should show you debugging in the Drupal log under `admin/reports/dblog`.
 * Make sure that Drupal sends proper cache headers. To best test this, use the URL that Lagoon generates for bypassing the Varnish cache, \(locally in our Drupal example this is [http://nginx-drupal-example.docker.amazee.io](http://nginx-drupal-example.docker.amazee.io)\). Check for the `Cache-Control: max-age=900, public` header, where the `900` is what you configured in `$config['system.performance']['cache']['page']['max_age']`.
-* Make sure that the environment variable `VARNISH_BYPASS` is **not** set to `true` \(see `docker-compose.yml` and run `docker-compose up -d varnish` to make sure the environment variable is configured correctly\).
+* Make sure that the environment variable `VARNISH_BYPASS` is **not** set to `true` \(see `docker-compose.yml` and run `docker compose up -d varnish` to make sure the environment variable is configured correctly\).
 * If all fails, and before you flip your table \(╯°□°）╯︵ ┻━┻, talk to the Lagoon team, we're happy to help.
-<!-- markdown-link-check-enable -->
+<!-- markdown-link-check-enable -->

docs/applications/drupal/step-by-step-getting-drupal-ready-to-run-on-lagoon.md

@@ -45,29 +45,29 @@ x-environment:
 First, we need to build the defined images:
 
 ```bash title="Build images"
-docker-compose build
+docker compose build
 ```
 
 This will tell `docker-compose` to build the Docker images for all containers that have a `build:` definition in the `docker-compose.yml`. Usually for Drupal this is the case for the `cli`, `nginx` and `php` images. We do this because we want to run specific **build** commands \(like `composer install`\) or inject specific environment variables \(like `WEBROOT`\) into the images.
 
-Usually, building is not necessary every time you edit your Drupal code \(as the code is mounted into the containers from your host\), but rebuilding does not hurt. Plus, Lagoon will build the exact same Docker images during a deploy, so you can check that your build will also work during a deployment by just running `docker-compose build` again.
+Usually, building is not necessary every time you edit your Drupal code \(as the code is mounted into the containers from your host\), but rebuilding does not hurt. Plus, Lagoon will build the exact same Docker images during a deploy, so you can check that your build will also work during a deployment by just running `docker compose build` again.
 
 ## 4. Start Containers
 
 Now that the images are built, we can start the containers:
 
 ```bash title="Start containers"
-docker-compose up -d
+docker compose up -d
 ```
 
-This will bring up all containers. After the command is done, you can check with `docker-compose ps` to ensure that they are all fully up and have not crashed. If there is a problem, check the logs with `docker-compose logs -f [servicename]`.
+This will bring up all containers. After the command is done, you can check with `docker compose ps` to ensure that they are all fully up and have not crashed. If there is a problem, check the logs with `docker compose logs -f [servicename]`.
 
 ## 5. Rerun `composer install` \(for Composer projects only\)
 
 In a local development environment, you probably want all dependencies downloaded and installed, so connect to the `cli` container and run `composer install`:
 
 ```bash title="Run composer install in CLI"
-docker-compose exec cli bash
+docker compose exec cli bash
 composer install
 ```
 
@@ -85,7 +85,7 @@ If you get a 500 or similar error, make sure everything loaded properly with Com
 Finally it's time to install Drupal, but just before that we want to make sure everything works. We suggest using Drush for that:
 
 ```bash title="Drush status"
-docker-compose exec cli bash
+docker compose exec cli bash
 drush status
 ```
 

docs/concepts-advanced/base-images.md

@@ -122,7 +122,7 @@ There are several steps to the build process. Most of these are shared among the
 1. **Docker Login** - The Docker username, password, and URL for Harbor are passed to the Docker client.
 2. **Docker Build** - The `make images_build` step is run now, which will:
    1. Ensure that all environment variables are prepared for the build.
-   2. Run a `docker-compose build`. This will produce several new Docker images from the current Git branch.
+   2. Run a `docker compose build`. This will produce several new Docker images from the current Git branch.
 3. **Images Test** - This will run the `make images_test` target, which will differ depending on the images being tested. In most cases this is a very straightforward test to ensure that the images can be started and interacted with in some way \(installing Drupal, listing files, etc.\)
 4. **Docker Push** - This step runs the logic \(contained in the make target `images_publish`\) that will tag the images resulting from the **Docker Build** in Step 2 and push them to Harbor. This is described in more detail [elsewhere](base-images.md#step-4-building-the-new-base-images) in this guide.
 5. **Docker Clean Images** - Runs the make target `images_remove`, which simply deletes the newly built images from the Docker host now that they are in Harbor.

docs/concepts-basics/docker-compose-yml.md

@@ -35,7 +35,7 @@ x-environment:
     LAGOON_ROUTE: http://drupal-example.docker.amazee.io
     # Uncomment if you want to have the system behave as it will in production
     #LAGOON_ENVIRONMENT_TYPE: production
-    # Uncomment to enable Xdebug and then restart via `docker-compose up -d`
+    # Uncomment to enable Xdebug and then restart via `docker compose up -d`
     #XDEBUG_ENABLE: "true"
 
 x-user:
@@ -244,7 +244,7 @@ no such service: container:amazeeio-ssh-agent
 
 BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner.
 
-With the release of Lagoon v2.11.0, Lagoon now provides support for more advanced BuildKit-based docker-compose builds. To enable BuildKit for your Project or Environment, add `DOCKER_BUILDKIT=1` as a build-time variable to your Lagoon project or environment.
+With the release of Lagoon v2.11.0, Lagoon now provides support for more advanced BuildKit-based docker compose builds. To enable BuildKit for your Project or Environment, add `DOCKER_BUILDKIT=1` as a build-time variable to your Lagoon project or environment.
 
 ## Docker Compose Errors in Lagoon Builds
 

docs/contributing-to-lagoon/api-debugging.md

@@ -52,7 +52,7 @@ node --inspect=0.0.0.0:9229
 4 . Rebuild/restart the containers:
 
 ```bash title="Restart containers"
-rm build/api && make build/api && docker-compose restart api
+rm build/api && make build/api && docker compose restart api
 ```
 
 5 . Restart VScode.

docs/docker-images/mariadb.md

@@ -34,7 +34,7 @@ This image is prepared to be used on Lagoon. There are therefore some things alr
 		# tells Lagoon this is a MariaDB database
 			lagoon.type: mariadb
 		ports:
-			# exposes the port 3306 with a random local port, find it with `docker-compose port mariadb 3306`
+			# exposes the port 3306 with a random local port, find it with `docker compose port mariadb 3306`
 			- "3306"
 		volumes:
 			# mounts a named volume at the default path for MariaDB

docs/docker-images/nodejs.md

@@ -46,7 +46,7 @@ Use the following labels in your `docker-compose.yml` file to configure it:
         ports:
         # local development only
             # this exposes the port 3000 with a random local port
-            # find it with `docker-compose port node 3000`
+            # find it with `docker compose port node 3000`
             - "3000"
         volumes:
         # local development only

docs/docker-images/postgres.md

@@ -30,7 +30,7 @@ postgres:
     lagoon.type: postgres
   ports:
     # exposes the port 5432 with a random local port
-    # find it with `docker-compose port postgres 5432`
+    # find it with `docker compose port postgres 5432`
     - "5432"
   volumes:
    	# mounts a named volume at the default path for Postgres

docs/docker-images/python.md

@@ -44,7 +44,7 @@ python:
     ports:
     # local development only
           # this exposes the port 8800 with a random local port
-          # find it with `docker-compose port python 8800`
+          # find it with `docker compose port python 8800`
         - "8800"
     volumes:
     # local development only

docs/docker-images/ruby.md

@@ -32,6 +32,6 @@ ruby:
         ports:
         # local development only
         # this exposes the port 3000 with a random local port
-        # find it with `docker-compose port ruby 3000`
+        # find it with `docker compose port ruby 3000`
             - "3000"
 ```

docs/lagoonizing/index.md

@@ -82,7 +82,7 @@ x-environment:
     LAGOON_ROUTE: http://drupal-example.docker.amazee.io
     # Uncomment if you would like to have the system behave like in production
     #LAGOON_ENVIRONMENT_TYPE: production
-    # Uncomment to enable xdebug and then restart via `docker-compose up -d`
+    # Uncomment to enable xdebug and then restart via `docker compose up -d`
     #XDEBUG_ENABLE: "true"
 
 x-user:
@@ -543,27 +543,27 @@ Unfortunately the Drupal community has not decided on a standardized webroot fol
 First, we need to build the defined images:
 
 ```bash title="build your images"
-docker-compose build
+docker compose build
 ```
 
 This may take several minutes and you’ll get a long response, [which should look something like this](https://gist.github.com/AlannaBurke/1bdad6aab977b0994c245834e61b6b50).
 
 This will tell `docker-compose` to build the Docker images for all containers that have a `build:` definition in `docker-compose.yml`. Usually for Drupal this includes `cli`, `nginx` and `php`. We do this because we want to run specific build commands (like `composer install`) or inject specific environment variables (like `WEBROOT`) into the images.
 
-Usually building is not needed every time you edit your Drupal code (as the code is mounted into the containers from your host), but rebuilding does not hurt. Plus Lagoon will build the exact same Docker images during a deployment, so you check that your build will also work during a deployment by just running `docker-compose build` again.
+Usually building is not needed every time you edit your Drupal code (as the code is mounted into the containers from your host), but rebuilding does not hurt. Plus Lagoon will build the exact same Docker images during a deployment, so you check that your build will also work during a deployment by just running `docker compose build` again.
 
 ### Start Containers
 
 Now that the images are built, we can start the containers:
 
 ```bash title="start the containers"
-docker-compose up -d
+docker compose up -d
 ```
 
 You will get a response something like this:
 
 ```bash title="containers started"
-➜  lagoon-test git:(main) docker-compose up -d
+➜  lagoon-test git:(main) docker compose up -d
 Recreating lagoon-test_cli_1   ... done
 Starting lagoon-test_redis_1   ... done
 Starting lagoon-test_solr_1    ... done
@@ -573,10 +573,10 @@ Recreating lagoon-test_nginx_1 ... done
 Recreating lagoon-test_varnish_1 ... done
 ```
 
-This will bring up all containers. After the command is done, you can check with `docker-compose ps` to ensure that they are all fully up and have not crashed. That response should look something like this:
+This will bring up all containers. After the command is done, you can check with `docker compose ps` to ensure that they are all fully up and have not crashed. That response should look something like this:
 
 ```bash title="view running containers"
-➜  lagoon-test git:(main) docker-compose ps
+➜  lagoon-test git:(main) docker compose ps
 Name                       Command               State            Ports
 ----------------------------------------------------------------------------------------
 lagoon-test_cli_1       /sbin/tini -- /lagoon/entr ...   Up      9000/tcp
@@ -588,14 +588,14 @@ lagoon-test_solr_1      /sbin/tini -- /lagoon/entr ...   Up      0.0.0.0:32769->
 lagoon-test_varnish_1   /sbin/tini -- /lagoon/entr ...   Up      8080/tcp
 ```
 
-If there is a problem, check the logs with `docker-compose logs -f [servicename]`.
+If there is a problem, check the logs with `docker compose logs -f [servicename]`.
 
 ### Re-Run `composer install`` (for Composer projects only)
 
 If you’re running a Drupal 8+ project, you should be using Composer, and you’ll need to get all dependencies downloaded and installed. Connect into the cli container and run composer install:
 
 ```bash title="re-run composer install"
-docker-compose exec cli bash
+docker compose exec cli bash
 [drupal-example]cli-drupal:/app$ composer install
 ```
 
@@ -613,7 +613,7 @@ If you get a 500 or similar error, make sure that everything is loaded properly
 Finally it's time to install Drupal, but just before that we want to make sure everything works. We suggest using Drush for that with `drush status`:
 
 ```bash title="run drush status"
-docker-compose exec cli bash
+docker compose exec cli bash
 [drupal-example]cli-drupal:/app$ drush status
 ```
 
@@ -675,7 +675,7 @@ Now you have a `dump.sql` file that contains your whole database.
 Copy this file into your local Git repository and connect to the CLI, you should see the file in there:
 
 ```bash title="here's our dump file"
-[drupal-example] docker-compose exec cli bash
+[drupal-example] docker compose exec cli bash
 [drupal-example]cli-drupal:/app$ ls -l dump.sql
 -rw-r--r--    1 root     root          5281 Dec 19 12:46 dump.sql
 ```

docs/resources/faq.md

@@ -169,7 +169,7 @@ If you have a build that has been running for a long time, and want to stop it,
 
 ## We installed the Elasticsearch\Solr service on our website. How can we get access to the UI (port 9200/8983) from a browser?
 <!-- markdown-link-check-disable-next-line -->
-We suggest only exposing web services (NGINX/Varnish/Node.js) in your deployed environments. Locally, you can get the ports mapped for these services by checking `docker-compose ps`, and then load [`http://localhost`](http://localhost/)`:<port>` in your browser.
+We suggest only exposing web services (NGINX/Varnish/Node.js) in your deployed environments. Locally, you can get the ports mapped for these services by checking `docker compose ps`, and then load [`http://localhost`](http://localhost/)`:<port>` in your browser.
 
 ## I have a question that isn't answered here
 

docs/using-lagoon-advanced/blackfire.md

@@ -40,6 +40,6 @@ In order to use Blackfire in deployed Lagoon environments the same enviornment v
 
 ## Debugging
 
-The Blackfire Agent running in the PHP containers outputs logs as normal container logs, which can be seen via `docker-compose logs` or via the Lagoon Logging Infrastructure for remote environments.
+The Blackfire Agent running in the PHP containers outputs logs as normal container logs, which can be seen via `docker compose logs` or via the Lagoon Logging Infrastructure for remote environments.
 
 By default the Logs are set to Level `3` (info), via the environment variable `BLACKFIRE_LOG_LEVEL` the level can be increased to `4` (debug) to generate more debugging ouput.

docs/using-lagoon-advanced/setting-up-xdebug-with-lagoon.md

@@ -107,7 +107,7 @@ debugging.
   `nc -l 9003`, then in a new terminal window, run:
 
   ```bash title="Verify Docker for Mac networking"
-  docker-compose run cli nc -zv host.docker.internal 9003
+  docker compose run cli nc -zv host.docker.internal 9003
   ```
 
   You should see a message like:

services/api-db/Makefile

@@ -12,7 +12,7 @@
 # Changing one sql file after initial load will sync the sql scripts.
 
 rerun-initdb:
-		docker-compose exec -u root api-db bash /legacy_rerun_initdb.sh
+		docker compose exec -u root api-db bash /legacy_rerun_initdb.sh
 
 watch:
 		watchman-make -p '/legacy-migration-scripts/*.sql' 'Makefile' -t -legacy-rerun-initdb

services/api/src/index.ts

@@ -36,7 +36,7 @@ const makeGracefulShutdown = (server: Server) => {
       const server = await createServer();
       const gracefulShutdown = makeGracefulShutdown(server);
 
-      // Shutdown on tsc-watch restart, docker-compose restart/kill, and k8s pod kills
+      // Shutdown on tsc-watch restart, docker compose restart/kill, and k8s pod kills
       process.once('SIGTERM', gracefulShutdown);
       // Shutdown on ctrl-c
       process.once('SIGINT', gracefulShutdown);