https://github.com/anddd7/diagrams-patterns
:art: Cloud architecture patterns with Diagrams
https://github.com/anddd7/diagrams-patterns
architecture aws cloud diagrams-as-code patterns tool
Last synced: 5 months ago
JSON representation
:art: Cloud architecture patterns with Diagrams
- Host: GitHub
- URL: https://github.com/anddd7/diagrams-patterns
- Owner: Anddd7
- License: mit
- Created: 2023-12-16T08:59:21.000Z (over 2 years ago)
- Default Branch: main
- Last Pushed: 2024-01-12T08:26:28.000Z (over 2 years ago)
- Last Synced: 2024-09-11T20:54:57.764Z (almost 2 years ago)
- Topics: architecture, aws, cloud, diagrams-as-code, patterns, tool
- Language: Python
- Homepage:
- Size: 60.5 KB
- Stars: 2
- Watchers: 2
- Forks: 0
- Open Issues: 2
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# diagrams-patterns
- diagrams should only used for managing the basic shapes of the cloud components
- but there are standard patterns usually used in cloud architecture, we don't need to draw them from scratch
- e.g. VPC with public/private subnets, NAT gateway, etc.
**diagrams-patterns** is a collection of patterns for diagrams that can be reused in different projects.
## Features
- [x] aws vpc, subnets with styles
- 
- [x] aws overlapping az on subnets
- calculate the position based on the number of az and subnets
- store and reuse the calculated position
- 
- [x] aws grid subnets with az
- ~~use 'anchor', a hidden node, to align the subnets~~
- not really work
- 
- [ ] dsl investigate
- dsl 2 py 2 diagrams (refer to d2)
## Roadmap
Currently, the **diagrams-patterns** and diagrams-exporters are built as 'diagrams'-extensions. But since the diagrams is inactive, introducing new tools is a necessary step, e.g. d2.
At that time, the **diagrams-patterns** should be a standalone tool, which provide a standard DSL to describe the common patterns in cloud architecture (or other kinds of diagrams). Then, you can translate the DSL to different tools, e.g. diagrams, d2, etc.
The **diagrams-exporters** plays another role to facilitate with productive tools, e.g. terraform, aws cli, etc. It read the metadata, convert to DSL, then generate the diagrams.
A possible structure is:
```mermaid
flowchart BT
subgraph diagram-exporters
terraform-exporter
awscli-exporter
kubectl-exporter
end
subgraph diagrams-patterns
subgraph common-patterns
c4-pattern
layer-arch-pattern
end
subgraph cloud-patterns
aws-pattern
azure-pattern
end
subgraph dsl
dsl-parser
dsl-to-diagrams
dsl-to-d2
dsl-to-mermaid
end
end
diagrams-patterns --> diagram-exporters
diagrams --> diagrams-patterns
d2 --> diagrams-patterns
plantuml --> diagrams-patterns
graphviz --> diagrams
graphviz --> d2
plantuml
```
## Reference
- graphviz & dot
-
- d2
-
-
- read tfstate and generate graph
-
-
- read aws cli and generate graph
-
- other terraform interesting tools
-
-