Flesh out docker-compose Cookiecutter template
This commit is contained in:
parent
e379cdafe0
commit
e6be888b91
53
README.md
53
README.md
@ -1,3 +1,54 @@
|
||||
# py-cookiecutter-templates
|
||||
|
||||
Project directory structure templates for the Python Cookiecutter module
|
||||
Project directory structure templates for the Python Cookiecutter module.
|
||||
|
||||
## What's Cookiecutter?
|
||||
|
||||
The Python package [Cookiecutter](https://github.com/cookiecutter/cookiecutter) assists in creating directory structure for whatever purpose you need such as for example a new Python project, an Ansible role or a `docker-compose` project. If you've ever wanted to put project structure best practices into version control Cookiecutter's here to help.
|
||||
|
||||
Cookiecutter is governed by so-called Cookiecutter templates. Most of its magic inside Cookiecutter templates happens via the [Jinja2 template engine](https://palletsprojects.com/p/jinja/) so if you're familiar with Ansible you'll feel right at home.
|
||||
|
||||
## Get started
|
||||
|
||||
Get Cookiecutter like so:
|
||||
```
|
||||
pip install cookiecutter
|
||||
```
|
||||
|
||||
Execute a template like so, `docker-compose` as an example:
|
||||
```
|
||||
cookiecutter https://quico.space/Quico/py-cookiecutter-templates.git --directory 'docker-compose'
|
||||
```
|
||||
|
||||
Cookiecutter prompts you for whatever info the template needs then generates files and directories.
|
||||
|
||||
This is Cookiecutter prompting for info:
|
||||
```
|
||||
info
|
||||
```
|
||||
|
||||
The end result is a directory structure that has everything you need to hit the ground running.
|
||||
```
|
||||
.
|
||||
└── grafana
|
||||
├── build-context
|
||||
│ ├── grafana
|
||||
│ │ ├── docker-data
|
||||
│ │ │ └── .gitkeep
|
||||
│ │ ├── Dockerfile
|
||||
│ │ └── extras
|
||||
│ │ └── .gitkeep
|
||||
│ └── nginx
|
||||
│ ├── docker-data
|
||||
│ │ └── .gitkeep
|
||||
│ ├── Dockerfile
|
||||
│ └── extras
|
||||
│ └── .gitkeep
|
||||
├── common-settings.yml
|
||||
├── docker-compose.override.yml
|
||||
├── docker-compose.yml
|
||||
└── env
|
||||
└── fully.qualified.domain.name.example
|
||||
```
|
||||
|
||||
Each subdirectory in this repo is a Cookiecutter template, you'll recognize them from their telltale `cookiecutter.json` files. Directories usually have a readme file explaining a bit more about each individual template.
|
||||
|
83
docker-compose/README.md
Normal file
83
docker-compose/README.md
Normal file
@ -0,0 +1,83 @@
|
||||
# Cookiecutter docker-compose template
|
||||
|
||||
## Get started
|
||||
|
||||
Get Cookiecutter like so:
|
||||
```
|
||||
pip install cookiecutter
|
||||
```
|
||||
|
||||
Execute this template like so:
|
||||
```
|
||||
cookiecutter https://quico.space/Quico/py-cookiecutter-templates.git --directory 'docker-compose'
|
||||
```
|
||||
|
||||
Cookiecutter interactively prompts you for the following info, here with example answers:
|
||||
```
|
||||
service []: grafana
|
||||
component_list [grafana]: grafana,nginx
|
||||
context []: cncf
|
||||
```
|
||||
|
||||
Done, directory structure and files for your next `docker-compose` project are ready for you to hit the ground running.
|
||||
|
||||
## Explanation and terminology
|
||||
|
||||
Each `docker-compose` project forms a *__service__* that may consist of either a single or multiple *__components__*.
|
||||
|
||||
The `service` variable by default is empty. In this example we've chosen to name the service `grafana`. We want `grafana` to consist of two components, namely Grafana itself and Nginx.
|
||||
|
||||
Syntax for a multi-component `component_list` is a comma-separated list without spaces. The string `grafana,nginx` will be treated as a list of two components. Capitalization doesn't matter, we're lowercasing all strings automatically.
|
||||
|
||||
The template prefills `component_list` with whatever you previously entered as the `service` name. To create directory structure for a _single-component service_ confirm the default. If `component_list` and `service` are identical directory structure will be that for a _single-component service_.
|
||||
|
||||
The last prompt for a *__context__* is a generic string to help you distinguish deployments. It can be whatever you want such as for example a team name, here `cncf`.
|
||||
|
||||
## Result
|
||||
|
||||
### Multi-component service
|
||||
|
||||
Above example of a multi-component (two in this case) `grafana` service will give you this directory structure:
|
||||
```
|
||||
.
|
||||
└── grafana
|
||||
├── build-context
|
||||
│ ├── grafana
|
||||
│ │ ├── docker-data
|
||||
│ │ │ └── .gitkeep
|
||||
│ │ ├── Dockerfile
|
||||
│ │ └── extras
|
||||
│ │ └── .gitkeep
|
||||
│ └── nginx
|
||||
│ ├── docker-data
|
||||
│ │ └── .gitkeep
|
||||
│ ├── Dockerfile
|
||||
│ └── extras
|
||||
│ └── .gitkeep
|
||||
├── common-settings.yml
|
||||
├── docker-compose.override.yml
|
||||
├── docker-compose.yml
|
||||
└── env
|
||||
└── fully.qualified.domain.name.example
|
||||
```
|
||||
Check out file contents over in the [examples/grafana subdir](/examples/grafana).
|
||||
|
||||
### Single-component
|
||||
|
||||
With an alternative single-component `hashicorpvault` service the result may look like this:
|
||||
```
|
||||
.
|
||||
└── hashicorpvault
|
||||
├── build-context
|
||||
│ ├── docker-data
|
||||
│ │ └── .gitkeep
|
||||
│ ├── Dockerfile
|
||||
│ └── extras
|
||||
│ └── .gitkeep
|
||||
├── common-settings.yml
|
||||
├── docker-compose.override.yml
|
||||
├── docker-compose.yml
|
||||
└── env
|
||||
└── fully.qualified.domain.name.example
|
||||
```
|
||||
Check out file contents over in the [examples/hashicorpvault subdir](/examples/hashicorpvault).
|
Loading…
x
Reference in New Issue
Block a user