diff --git a/.markdownlint.yaml b/.markdownlint.yaml index d633a47..d137915 100644 --- a/.markdownlint.yaml +++ b/.markdownlint.yaml @@ -1,4 +1,5 @@ MD013: false MD024: false MD033: false +MD045: false MD046: false diff --git a/docs/concepts.md b/docs/concepts.md index 5040ce7..106010f 100644 --- a/docs/concepts.md +++ b/docs/concepts.md @@ -1,7 +1,8 @@ # Concepts -We’ll start with brief descriptions of KubeFox constituents and gradually drop -deeper into detail. +The following are brief descriptions of KubeFox constituents. For more details +and tutorials on their use checkout additional documentation under +[topics](../topics). ## Event diff --git a/docs/topics/deployment_distillation.md b/docs/topics/deployment_distillation.md index 254fa91..6a38c38 100644 --- a/docs/topics/deployment_distillation.md +++ b/docs/topics/deployment_distillation.md @@ -52,8 +52,8 @@ When the Order System is initially deployed (we'll call this the 'a' deployment), it will look like this in KubeFox (Figure 1):
- - + +
Figure 1 - Initial Deployment [a]
@@ -69,8 +69,8 @@ Let's say that the user needs to make a change to the order-ui component. When System b is deployed, it will look as shown in Figure 2:
- - + +
Figure 2 - Deployment [b] to change the order-ui component
@@ -85,8 +85,8 @@ component. Again, KubeFox checks the state of the System and deploys only api-srv[c]:
- - + +
Figure 3 - Deployment [c] to change the api-srv component
@@ -103,8 +103,8 @@ In our final deployment [d], the user does a couple of things: When the System is deployed, it looks as shown in Figure 4:
- - + +
Figure 4 - Deployment [d] to add a component and modify order-ui
diff --git a/docs/topics/index.md b/docs/topics/index.md new file mode 100644 index 0000000..47d78dd --- /dev/null +++ b/docs/topics/index.md @@ -0,0 +1,3 @@ +# Overview + +TODO provide overview of what topics documents are trying to achieve. diff --git a/docs/topics/telemetry.md b/docs/topics/telemetry.md index d6d1494..4b72acf 100644 --- a/docs/topics/telemetry.md +++ b/docs/topics/telemetry.md @@ -14,7 +14,7 @@ You can visualize the behavior of the entire System (all applications composing the Retail System) as shown in Figure 1:
- +
Figure 1 - Span-based telemetry for the entire System
@@ -22,13 +22,13 @@ You can visualize behavior by Application (Figure 2) - for instance for the Fulfillment app:
- +
Figure 2 - Span-based telemetry for the Fulfillment App
And you can visualize behavior by individual Component (Figure 3):
- +
Figure 3 - Span-based telemetry for the Web UI component of the Web UI App
diff --git a/docs/topics/versioned_deployments.md b/docs/topics/versioned_deployments.md index 2ab3862..acba12f 100644 --- a/docs/topics/versioned_deployments.md +++ b/docs/topics/versioned_deployments.md @@ -12,8 +12,8 @@ Let’s start with a Retail System composed of 3 applications, a Web UI app, a Catalog app and a fulfillment app, as shown in Figure 1:
- - + +
Figure 1 - Composition of Version 1 of the Retail System
@@ -23,7 +23,7 @@ Service and Member Service components. When the Retail System is deployed by KubeFox, the cluster will look like the diagram in Figure 2.
- +
Figure 2 - First Deployment of the Retail System
@@ -42,8 +42,8 @@ current example, if we update the Catalog Query component in the Catalog app, our Retail System will be composed of the components shown in Figure 3.
- - + +
Figure 3 - Composition of Version 2 of the Retail System
@@ -52,7 +52,7 @@ change within a System - whether an updated to a component, or addition of a component - will yield a new version of that System.
- +
Figure 4 - Version 2 of the Retail System with the modified Catalog Query component
@@ -80,13 +80,13 @@ version 1 of the Retail System, so we only need version 2 of the Catalog Query component. The component building blocks will be those shown in Figure 5.
- - + +
Figure 5 - Composition of Version 3 of the Retail System
- +
Figure 6 - Version 3 of the Retail System
@@ -99,7 +99,7 @@ component (thereby creating Version 4 of the Retail System), we can choose to deprecate the v1 version of Vendor Services (Figure 7).
- +
Figure 7 - Version 4 of the Retail System
@@ -116,7 +116,7 @@ Now is a good time to review KubeFox deployments and releases. diff --git a/docs/topics/virtual_environments.md b/docs/topics/virtual_environments.md index 646b75d..37fe95b 100644 --- a/docs/topics/virtual_environments.md +++ b/docs/topics/virtual_environments.md @@ -19,7 +19,7 @@ critical in prod etc. Environments enable us to build policy controls supporting these tenets. Figure 1 shows a typical dev environment.
- +
Figure 1 - A typical Dev environment
@@ -81,7 +81,7 @@ Polina can test her new code in Environment A, which is unique to her (Figure 2):
- +
Figure 2 - Polina testing in environment A
@@ -89,7 +89,7 @@ and then shift instantly to Environment B (Figure 3), perhaps to compare her changes with the prior version of software:
- +
Figure 3 - Polina testing in environment B
@@ -117,7 +117,7 @@ component of the Web UI app. But KubeFox has distilled the deployment to only those unique versions of the Web UI component.
- +
Figure 4 - KubeFox Distilled Dev Environment
@@ -126,7 +126,7 @@ appear to be independent sandboxes with dedicated resources. For instance, to Polina, the system appears as in Figure 5.
- +
Figure 5 - Polina's Dev Environment