Updates for docker compose plugin.

changes/191.fixed

@@ -0,0 +1 @@
+Updated docker-compose to docker compose within the tasks.py file.

docs/dev/dev_environment.md

@@ -24,6 +24,9 @@ Using **Invoke** these configuration options can be overridden using [several me
 
 ### Docker Development Environment
 
+!!! tip
+    As of 1.11.1 the Docker Compose environment has moved from the standalone docker-compose to the plugin execution of `docker compose`. Be sure that your version of Docker has the plugin installed. If the docker compose plugin is installed, no other changes to the invoke methodology is required.
+
 !!! tip
     This is the recommended option for development.
 
@@ -136,15 +139,14 @@ Each command can be executed with `invoke <command>`. All commands support the a
   unittest         Run Django unit tests for the plugin.
 ```
 
-
 ## Project Overview
 
-This project provides the ability to develop and manage the Nautobot server locally (with supporting services being *Dockerized*) or by using only Docker containers to manage Nautobot. The main difference between the two environments is the ability to debug and use **pdb** when developing locally. Debugging with **pdb** within the Docker container is more complicated, but can still be accomplished by either entering into the container (via `docker exec`) or attaching your IDE to the container and running the Nautobot service manually within the container.
+This project provides the ability to develop and manage the Nautobot server locally (with supporting services being _Dockerized_) or by using only Docker containers to manage Nautobot. The main difference between the two environments is the ability to debug and use **pdb** when developing locally. Debugging with **pdb** within the Docker container is more complicated, but can still be accomplished by either entering into the container (via `docker exec`) or attaching your IDE to the container and running the Nautobot service manually within the container.
 
 The upside to having the Nautobot service handled by Docker rather than locally is that you do not have to manage the Nautobot server. The [Docker logs](#docker-logs) provide the majority of the information you will need to help troubleshoot, while getting started quickly and not requiring you to perform several manual steps and remembering to have the Nautobot server running in a separate terminal while you develop.
 
 !!! note
-	The local environment still uses Docker containers for the supporting services (Postgres, Redis, and RQ Worker), but the Nautobot server is handled locally by you, the developer.
+    The local environment still uses Docker containers for the supporting services (Postgres, Redis, and RQ Worker), but the Nautobot server is handled locally by you, the developer.
 
 Follow the directions below for the specific development environment that you choose.
 
@@ -229,7 +231,7 @@ Once the containers are fully up, you should be able to open up a web browser, a
 - A live version of the documentation at [http://localhost:8001](http://localhost:8001)
 
 !!! note
-	Sometimes the containers take a minute to fully spin up. If the page doesn't load right away, wait a minute and try again.
+    Sometimes the containers take a minute to fully spin up. If the page doesn't load right away, wait a minute and try again.
 
 ### Invoke - Creating a Superuser
 
@@ -240,7 +242,7 @@ The Nautobot development image will automatically provision a super user when sp
 - `NAUTOBOT_SUPERUSER_PASSWORD=admin`
 
 !!! note
-	The default username is **admin**, but can be overridden by specifying **NAUTOBOT_SUPERUSER_USERNAME**.
+    The default username is **admin**, but can be overridden by specifying **NAUTOBOT_SUPERUSER_USERNAME**.
 
 If you need to create additional superusers, run the follow commands.
 
@@ -290,7 +292,7 @@ Removing network nautobot_chatops_default
 This will safely shut down all of your running Docker containers for this project. When you are ready to spin containers back up, it is as simple as running `invoke start` again [as seen previously](#invoke-starting-the-development-environment).
 
 !!! warning
-	If you're wanting to reset the database and configuration settings, you can use the `invoke destroy` command, but **you will lose any data stored in those containers**, so make sure that is what you want to do.
+    If you're wanting to reset the database and configuration settings, you can use the `invoke destroy` command, but **you will lose any data stored in those containers**, so make sure that is what you want to do.
 
 ### Real-Time Updates? How Cool!
 
@@ -301,12 +303,12 @@ Now you can start developing your plugin in the project folder!
 The magic here is the root directory is mounted inside your Docker containers when built and ran, so **any** changes made to the files in here are directly updated to the Nautobot plugin code running in Docker. This means that as you modify the code in your plugin folder, the changes will be instantly updated in Nautobot.
 
 !!! warning
-	There are a few exceptions to this, as outlined in the section [To Rebuild or Not To Rebuild](#to-rebuild-or-not-to-rebuild).
+    There are a few exceptions to this, as outlined in the section [To Rebuild or Not To Rebuild](#to-rebuild-or-not-to-rebuild).
 
 The back-end Django process is setup to automatically reload itself (it only takes a couple of seconds) every time a file is updated (saved). So for example, if you were to update one of the files like `tables.py`, then save it, the changes will be visible right away in the web browser!
 
 !!! note
-	You may get connection refused while Django reloads, but it should be refreshed fairly quickly.
+    You may get connection refused while Django reloads, but it should be refreshed fairly quickly.
 
 ### Docker Logs
 
@@ -317,7 +319,7 @@ When trying to debug an issue, one helpful thing you can look at are the logs wi
 ```
 
 !!! note
-	The `-f` tag will keep the logs open, and output them in realtime as they are generated.
+    The `-f` tag will keep the logs open, and output them in realtime as they are generated.
 
 So for example, our plugin is named `nautobot-chatops`, the command would most likely be `docker logs nautobot_chatops_nautobot_1 -f`. You can find the name of all running containers via `docker ps`.
 

pyproject.toml

@@ -1,6 +1,6 @@
 [tool.poetry]
 name = "nautobot-chatops"
-version = "1.11.0"
+version = "1.11.1"
 description = "A plugin providing chatbot capabilities for Nautobot"
 authors = ["Network to Code, LLC <[email protected]>"]
 readme = "README.md"

tasks.py

@@ -99,6 +99,8 @@ def docker_compose(context, command, **kwargs):
         "PYTHON_VER": context.nautobot_chatops.python_ver,
         **kwargs.pop("env", {}),
     }
+
+    compose_command = f'docker compose --project-name {context.nautobot_chatops.project_name} --project-directory "{context.nautobot_chatops.compose_dir}"'
     compose_command_tokens = [
         "docker compose",
         f"--project-name {context.nautobot_chatops.project_name}",
@@ -119,6 +121,8 @@ def docker_compose(context, command, **kwargs):
     print(f'Running docker compose command "{command}"')
     compose_command = " ".join(compose_command_tokens)
 
+    print(f'Running docker compose command "{command}"')
+
     return context.run(compose_command, env=build_env, **kwargs)