Open Riduidel opened 3 days ago
A first integration has been attempted by simply calling terraform-docs through Docker and including the generated asciidoc file.
Docker call is done the following way
<plugin>
<groupId>io.fabric8</groupId>
<artifactId>docker-maven-plugin</artifactId>
<version>0.44.0</version>
<executions>
<execution>
<id>Generate terraform docs</id>
<phase>process-resources</phase>
<goals>
<goal>start</goal>
</goals>
<configuration>
<containerNamePattern>terraform-docs</containerNamePattern>
<images>
<image>
<name>
quay.io/terraform-docs/terraform-docs:0.18.0</name>
<run>
<autoRemove>true</autoRemove>
<cmd>
<arg>asciidoc</arg>
<arg>document</arg>
<arg>/terraform-source</arg>
<arg>--output-file</arg>
<arg><![CDATA[/terraform-doc/documentation.adoc]]></arg>
</cmd>
<volumes>
<bind>
<volume><![CDATA[${terraform.module}:/terraform-source]]></volume>
<volume><![CDATA[${terraform.doc}:/terraform-doc]]></volume>
</bind>
</volumes>
</run>
</image>
</images>
<showLogs>true</showLogs>
</configuration>
</execution>
</executions>
</plugin>
Unfortunatly, the generated document is hardly readable :
In fact, with our current terraform sample (which may not have been optimized for documentation), it's quite useless. Furthermore, no link is made between these deployment objects and the architecture elements exposed in the "abstract" architecture.
As a consequence, a good solution be to load all Terrraform objects as Java code, then augment the architecture description with these elements, and produce diagrams exposing elements of the right complexity level.
Instead of focusing about cloud providers, it may be a better idea to interface with terraform-docs as terraform looks like a common ground for all DevOps/cloud native deployments.