# README

### Style Guide

I like consistency and readability/understandability. As such, I've defined myself a Boilerplate Style Guide for when creating new docker compose files. On a case by case basis, I may go against this template if it makes sense. 

The official documentation for how the Docker Compose specification works can be found [here](https://docs.docker.com/compose/compose-file/).

Note that, [starting with Docker Compose 1.27.0+](https://docs.docker.com/compose/compose-file/compose-versioning/), it is no longer necessary to specify the Docker Compose version (i.e. `version: "3.1`) as this option has been deprecated.

The order of operations for how the `cap_add` and `cap_drop` options can be found [here](https://stackoverflow.com/questions/63162665/docker-compose-order-of-cap-drop-and-cap-add/63219871#63219871) or reference the image below:

![cap_add and cap_drop matrix](https://i.imgur.com/rDhRS4U.jpg)

You can name Docker Compose files hower you like as long as it has a .yml or .yaml extension. However, if you name it anything other than `docker-compose.yml` or `docker-compose.yaml`, you must pass the filename in the docker compose command. i.e. `docker compose <DOCKER_COMPOSE_FILE> up -d`

I've left the default host side ports in these boilerplates. Which means several of them would conflict with each other. Please update accordingly to your setup.

I use [custom networks](https://docs.docker.com/compose/networking/#specify-custom-networks) for all of my containers that are able to utilize them. Feel free to adjust to your own setup.

```yaml
# <FILE_NAME>.yml
# Docker Hub: <LINK_TO_IMAGE(S)_HUB_PAGE(S)>
# Documentation: <LINK_TO_DOCUMENTATION_IF_NEEDED>
# <ANY_EXTRA_NOTES>

volumes:

networks:

services:
  <LIST_SERVICES_AS_MAKES_SENSE>:
    <LIST_RUNTIME_ARGUEMENTS_ALPHABETICALLY>
```