Merge pull request #1 from stakater/migrate-docs

Update workflow and docs
stakater · Mar 23, 2023 · d5ccf15 · d5ccf15
2 parents fd4e4b7 + 589bcb4
commit d5ccf15
Show file tree

Hide file tree

Showing 53 changed files with 87 additions and 83 deletions.
diff --git a/.github/md_config.json b/.github/md_config.json
@@ -1,7 +1,17 @@
 {
+  "aliveStatusCodes": [429, 200, 520], 
   "ignorePatterns": [
     {
-      "pattern": "^(?!http).+"
+      "pattern": "^(https://stakater).+"
+    },
+    {
+      "pattern": "^(http://nexus).+"
+    },
+    {
+      "pattern": "^(https://nexus).+"
+    },
+    {
+      "pattern": "^(https://docs.github.com).+"
     }
   ]
 }
diff --git a/.github/workflows/pull_request.yaml b/.github/workflows/pull_request.yaml
@@ -7,13 +7,13 @@ on:
 
 jobs:
   qa:
-    uses: stakater/.github/.github/workflows/[email protected].13
+    uses: stakater/.github/.github/workflows/[email protected].23
     with:
       MD_CONFIG: .github/md_config.json
       DOC_SRC: content
-      MD_LINT_CONFIG: markdownlint.yaml
+      MD_LINT_CONFIG: .markdownlint.yaml
   build:
-    uses: stakater/.github/.github/workflows/[email protected].13
+    uses: stakater/.github/.github/workflows/[email protected].23
     with:
       DOCKER_FILE_PATH: Dockerfile
     secrets:

diff --git a/.github/workflows/push.yaml b/.github/workflows/push.yaml
@@ -7,12 +7,12 @@ on:
 
 jobs:
   push:
-    uses: stakater/.github/.github/workflows/[email protected].13
+    uses: stakater/.github/.github/workflows/[email protected].23
     with:
       DOCKER_FILE_PATH: Dockerfile
       RELEASE_BRANCH: main
     secrets:
-      CONTAINER_REGISTRY_URL: ${{ secrets.STAKATER_NEXUS_PREPROD_REGISTRY }}
+      CONTAINER_REGISTRY_URL: ${{ secrets.STAKATER_NEXUS_PREPROD_REGISTRY }}/stakater
       CONTAINER_REGISTRY_USERNAME: ${{ secrets.STAKATER_NEXUS_PREPROD_USERNAME }}
       CONTAINER_REGISTRY_PASSWORD: ${{ secrets.STAKATER_NEXUS_PREPROD_PASSWORD }}
       SLACK_WEBHOOK_URL: ${{ secrets.STAKATER_DELIVERY_SLACK_WEBHOOK }}

diff --git a/.github/workflows/release.yaml b/.github/workflows/release.yaml
@@ -7,6 +7,6 @@ on:
 
 jobs:
   release:
-    uses: stakater/.github/.github/workflows/[email protected].13
+    uses: stakater/.github/.github/workflows/[email protected].23
     secrets:
       SLACK_WEBHOOK_URL: ${{ secrets.STAKATER_DELIVERY_SLACK_WEBHOOK }}
diff --git a/markdownlint.yaml → .markdownlint.yaml b/markdownlint.yaml → .markdownlint.yaml
@@ -2,4 +2,5 @@
   "MD007": { "indent": 4 },
   "MD013": false,
   "MD024": false,
+  "MD046": false,
 }
diff --git a/Dockerfile b/Dockerfile
@@ -1,6 +1,6 @@
-FROM python:3.11-alpine as builder
+FROM python:3.11 as builder
 
-RUN pip3 install mkdocs-material mkdocs-mermaid2-plugin
+RUN pip3 install mkdocs-material mkdocs-mermaid2-plugin mkdocs-table-reader-plugin
 
 # set workdir
 RUN mkdir -p $HOME/application
@@ -19,11 +19,11 @@ COPY default.conf /etc/nginx/conf.d/
 # set non-root user
 USER 1001
 
-LABEL name="Multi Tenant Operator Documentation" \
+LABEL name="SAAP Documentation" \
       maintainer="Stakater <[email protected]>" \
       vendor="Stakater" \
       release="1" \
-      summary="Documentation for Multi Tenant Operator"
+      summary="Documentation for SAAP"
 
 EXPOSE 8080:8080/tcp
 

diff --git a/README.md b/README.md
@@ -1,4 +1,3 @@
 # saap-docs
 
 Stakater App Agility Platform (SAAP) Documentation
-
diff --git a/content/about/cloud-providers/aws.md b/content/about/cloud-providers/aws.md
@@ -27,4 +27,4 @@ TODO
 
 ## Cloud network configuration
 
-TODO
+TODO
diff --git a/content/about/cloud-providers/overview.md b/content/about/cloud-providers/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/about/high-availability.md b/content/about/high-availability.md
@@ -1,24 +1,24 @@
 # High availability
 
-## About high availability 
+## About high availability
 
-High availability (HA) is a core discipline in an IT infrastructure to keep your apps up and running, even after a partial or full site failure. The main purpose of high availability is to eliminate potential points of failures in an IT infrastructure. For example, you can prepare for the failure of one system by adding redundancy and setting up failover mechanisms.
+High availability (HA) is a core discipline in an IT infrastructure to keep your apps up and running, even after a partial or full site failure. The main purpose of high availability is to eliminate potential points of failures in an IT infrastructure. For example, you can prepare for the failure of one system by adding redundancy and setting up fail-over mechanisms.
 
-Availability and disaster avoidance are extremely important aspects of any application platform. SAAP provides many protections against failures at several levels, but customer-deployed applications must be appropriately configured for high availability. In addition, to account for cloud provider outages that might occur, other options are available, such as deploying a cluster across multiple availability zones or maintaining multiple clusters with failover mechanisms.
+Availability and disaster avoidance are extremely important aspects of any application platform. SAAP provides many protections against failures at several levels, but customer-deployed applications must be appropriately configured for high availability. In addition, to account for cloud provider outages that might occur, other options are available, such as deploying a cluster across multiple availability zones or maintaining multiple clusters with fail-over mechanisms.
 
 ### What level of availability is best?
 
 You can achieve high availability on different levels in your IT infrastructure and within different components of your cluster. The level of availability that is correct for you depends on several factors, such as your business requirements, the Service Level Agreements that you have with your customers, and the resources that you want to expend.
 
 ## Potential points of failure
 
-SAAP provides many features and options for protecting your workloads against downtime, but applications must be architected appropriately to take advantage of these features.
+SAAP provides many features and options for protecting your workloads against downtime, but applications must have proper architecture to take advantage of these features.
 
 SAAP can help further protect you against many common Kubernetes issues by adding Stakater Site Reliability Engineer (SRE) support and the option to deploy a multi-zone cluster, but there are a number of ways in which a container or infrastructure can still fail. By understanding potential points of failure, you can understand risks and appropriately architect both your applications and your clusters to be as resilient as necessary at each specific level.
 
 !!! note "NOTE"
 
-	An outage can occur at several different levels of infrastructure and cluster components.
+ An outage can occur at several different levels of infrastructure and cluster components.
 
 SAAP provides several approaches to add more availability to your cluster by adding redundancy and anti-affinity. Review the following image to learn about potential points of failure and how to eliminate them.
 
@@ -40,7 +40,7 @@ Worker nodes are the virtual machines that contain your application pods. By def
 
 !!! note "NOTE"
 
-	When accounting for possible node failures, it is also important to understand how storage is affected.
+ When accounting for possible node failures, it is also important to understand how storage is affected.
 
 ### Potential failure point 3: Cluster availability
 
@@ -50,7 +50,7 @@ In the event of a complete control plane node outage, the OpenShift APIs will no
 
 All services running on infrastructure nodes are configured by Stakater to be highly available and distributed across infrastructure nodes. In the event of a complete infrastructure outage, these services will be unavailable until these nodes have been recovered.
 
-The Kubernetes master is the main component that keeps your cluster up and running. The master stores cluster resources and their configurations in the etcd database that serves as the single point of truth for your cluster. The Kubernetes API server is the main entry point for all cluster management requests from the worker nodes to the master, or when you want to interact with your cluster resources. To protect your cluster master from a zone failure: create a cluster in a multizone location, which spreads the master across zones or consider setting up a second cluster in another zone.
+The Kubernetes master is the main component that keeps your cluster up and running. The master stores cluster resources and their configurations in the etcd database that serves as the single point of truth for your cluster. The Kubernetes API server is the main entry point for all cluster management requests from the worker nodes to the master, or when you want to interact with your cluster resources. To protect your cluster master from a zone failure: create a cluster in a multi-zone location, which spreads the master across zones or consider setting up a second cluster in another zone.
 
 ### Potential failure point 4: Zone availability
 
@@ -62,4 +62,4 @@ Every region is set up with a highly available load balancer that is accessible
 
 ### Potential failure point 6: Storage availability
 
-If you have deployed a stateful application, then storage is a critical component and must be accounted for when thinking about high availability. A single block storage PV is unable to withstand outages even at the pod level. The best ways to maintain availability of storage are to use replicated storage solutions, shared storage that is unaffected by outages, or a database service that is independent of the cluster.
+If you have deployed a stateful application, then storage is a critical component and must be accounted for when thinking about high availability. A single block storage PV is unable to withstand outages even at the pod level. The best ways to maintain availability of storage are to use replicated storage solutions, shared storage that is unaffected by outages, or a database service that is independent of the cluster.
diff --git a/content/about/overview.md b/content/about/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/about/responsibility-matrix/applications-data.md b/content/about/responsibility-matrix/applications-data.md
@@ -2,4 +2,4 @@
 
 You are completely responsible for the applications, workloads, and data that you deploy to SAAP. However, SAAP provides various tools to help you set up, manage, secure, integrate and optimize your apps as described in the following table.
 
-{{ read_csv('applications-data.csv') }}
+{{ read_csv('applications-data.csv') }}
diff --git a/content/about/responsibility-matrix/disaster-recovery.md b/content/about/responsibility-matrix/disaster-recovery.md
@@ -1,4 +1,3 @@
 # Disaster Recovery
 
 Stakater is responsible for the recovery of Red Hat OpenShift in case of disaster. You are responsible for the recovery of the workloads that run the cluster and your applications data. If you integrate with other cloud services such as file, block, object, cloud database, logging, or audit event services, consult those services' disaster recovery information.
-
diff --git a/content/about/service-definition/account-management.md b/content/about/service-definition/account-management.md
@@ -2,7 +2,6 @@
 
 ## Billing
 
-
 ## Cloud Providers
 
 SAAP is available as a managed service on the following cloud providers:
@@ -14,4 +13,3 @@ SAAP is available as a managed service on the following cloud providers:
 - UpCloud
 
 ## Cluster Provisioning
-
diff --git a/content/about/service-definition/logging.md b/content/about/service-definition/logging.md
@@ -1 +1 @@
-# Logging
+# Logging
diff --git a/content/about/service-definition/monitoring.md b/content/about/service-definition/monitoring.md
@@ -1 +1 @@
-# Monitoring
+# Monitoring
diff --git a/content/about/service-definition/networking.md b/content/about/service-definition/networking.md
@@ -12,15 +12,10 @@ Custom domains and subdomains are not available for the platform service routes,
 
 SAAP includes TLS security certificates needed for both internal and external services on the cluster. For external routes, there are two, separate TLS wildcard certificates that are provided and installed on each cluster, one for the web console and route default hostnames and the second for the API endpoint. Let’s Encrypt is the certificate authority used for certificates. Routes within the cluster, for example, the internal API endpoint, use TLS certificates signed by the cluster’s built-in certificate authority and require the CA bundle available in every pod for trusting the TLS certificate.
 
-## Loadbalancers
-
+## Load-balancers
 
 ## Network usage
 
-
 ## Cluster ingress
 
-
 ## Cluster egress
-
-
diff --git a/content/about/service-definition/overview.md b/content/about/service-definition/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/about/service-definition/platform.md b/content/about/service-definition/platform.md
@@ -1 +1 @@
-# Platform
+# Platform
diff --git a/content/about/service-definition/security.md b/content/about/service-definition/security.md
@@ -12,7 +12,7 @@ Authentication for the cluster is configured as part of cluster creation process
 
 ## Privileged containers
 
-Privileged containers are not available by default on SAAP. The anyuid and nonroot Security Context Constraints (SCC) are available for members of the sca group, and should address many use cases. Privileged containers are only available for cluster-admin users.
+Privileged containers are not available by default on SAAP. The `anyuid` and `nonroot` Security Context Constraints (SCC) are available for members of the `sca` group, and should address many use cases. Privileged containers are only available for cluster-admin users.
 
 ## Customer administrator user
 

diff --git a/content/about/service-definition/storage.md b/content/about/service-definition/storage.md
@@ -1 +1 @@
-# Storage
+# Storage
diff --git a/content/about/sla.md b/content/about/sla.md
@@ -1 +1 @@
-# SLAs
+# SLAs
diff --git a/content/about/support/support.md b/content/about/support/support.md
@@ -29,7 +29,8 @@ New users can sign up using their official email address by following this proce
     ![image](./images/signup-support-5.png)
 
 ## Request Support
-As a registered user you can go to the [Service Desk Portal](https://stakater-cloud.atlassian.net/servicedesk/customer/portals) to raise a support request. 
+
+As a registered user you can go to the [Service Desk Portal](https://stakater-cloud.atlassian.net/servicedesk/customer/portals) to raise a support request.
 
 ![image](./images/signup-support-6.png)
 

diff --git a/content/about/update-lifecycle.md b/content/about/update-lifecycle.md
@@ -1 +1 @@
-# Update Lifecycle
+# Update Lifecycle
diff --git a/content/for-administrators/overview.md b/content/for-administrators/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/for-cisos/overview.md b/content/for-cisos/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/for-delivery-engineers/overview.md b/content/for-delivery-engineers/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/for-developers/overview.md b/content/for-developers/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/for-partners/overview.md b/content/for-partners/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/help/k8s-concepts/container-anatomy.md b/content/help/k8s-concepts/container-anatomy.md
@@ -4,10 +4,10 @@
 
 ## Container Image Format
 
-## Containerfile
+## Container-file
 
 ## Container Identification
 
 ## Container Runtime
 
-## Container Tools
+## Container Tools
diff --git a/content/managed-addons/argocd/overview.md b/content/managed-addons/argocd/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/managed-addons/cert-manager/overview.md b/content/managed-addons/cert-manager/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/managed-addons/external-secrets-operator/overview.md b/content/managed-addons/external-secrets-operator/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/managed-addons/forecastle/overview.md b/content/managed-addons/forecastle/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/managed-addons/imc/overview.md b/content/managed-addons/imc/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/managed-addons/konfigurator/overview.md b/content/managed-addons/konfigurator/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/managed-addons/logging-stack/overview.md b/content/managed-addons/logging-stack/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/managed-addons/monitoring-stack/overview.md b/content/managed-addons/monitoring-stack/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/managed-addons/mto/overview.md b/content/managed-addons/mto/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/managed-addons/nexus/about/benefits.md b/content/managed-addons/nexus/about/benefits.md
@@ -1 +1 @@
-# Benefits
+# Benefits
diff --git a/content/managed-addons/nexus/about/overview.md b/content/managed-addons/nexus/about/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/managed-addons/nexus/about/release-notes.md b/content/managed-addons/nexus/about/release-notes.md
@@ -1 +1 @@
-# Release Notes
+# Release Notes
diff --git a/content/managed-addons/nexus/about/slas.md b/content/managed-addons/nexus/about/slas.md
@@ -1 +1 @@
-# SLAs
+# SLAs
diff --git a/content/managed-addons/nexus/overview.md b/content/managed-addons/nexus/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/managed-addons/overview.md b/content/managed-addons/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/managed-addons/reloader/overview.md b/content/managed-addons/reloader/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/managed-addons/sonarqube/overview.md b/content/managed-addons/sonarqube/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/managed-addons/tekton/overview.md b/content/managed-addons/tekton/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/managed-addons/tronador/overview.md b/content/managed-addons/tronador/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/managed-addons/vault/overview.md b/content/managed-addons/vault/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
diff --git a/content/managed-addons/velero/overview.md b/content/managed-addons/velero/overview.md
@@ -1 +1 @@
-# Overview
+# Overview
Original file line number	Diff line number	Diff line change
		@@ -1,4 +1,3 @@
		# saap-docs

		Stakater App Agility Platform (SAAP) Documentation
Original file line number	Diff line number	Diff line change
Expand Up		@@ -27,4 +27,4 @@ TODO

		## Cloud network configuration

		TODO
		TODO
Original file line number	Diff line number	Diff line change
Expand Up		@@ -2,4 +2,4 @@

		You are completely responsible for the applications, workloads, and data that you deploy to SAAP. However, SAAP provides various tools to help you set up, manage, secure, integrate and optimize your apps as described in the following table.

		{{ read_csv('applications-data.csv') }}
		{{ read_csv('applications-data.csv') }}
Original file line number	Diff line number	Diff line change
		@@ -1,4 +1,3 @@
		# Disaster Recovery

		Stakater is responsible for the recovery of Red Hat OpenShift in case of disaster. You are responsible for the recovery of the workloads that run the cluster and your applications data. If you integrate with other cloud services such as file, block, object, cloud database, logging, or audit event services, consult those services' disaster recovery information.