Merge pull request #3 from stakater/migrate-docs

Migrate docs

.dockerignore

@@ -0,0 +1 @@
+.git*

.github/md_config.json

@@ -0,0 +1,17 @@
+{
+  "aliveStatusCodes": [429, 200, 520], 
+  "ignorePatterns": [
+    {
+      "pattern": "^(https://stakater).+"
+    },
+    {
+      "pattern": "^(http://nexus).+"
+    },
+    {
+      "pattern": "^(https://nexus).+"
+    },
+    {
+      "pattern": "^(https://docs.github.com).+"
+    }
+  ]
+}

.github/workflows/pull_request.yaml

@@ -0,0 +1,23 @@
+name: Pull Request
+
+on:
+  pull_request:
+    branches:
+      - 'main'
+
+jobs:
+  qa:
+    uses: stakater/.github/.github/workflows/[email protected]
+    with:
+      MD_CONFIG: .github/md_config.json
+      DOC_SRC: content
+      MD_LINT_CONFIG: .markdownlint.yaml
+  build:
+    uses: stakater/.github/.github/workflows/[email protected]
+    with:
+      DOCKER_FILE_PATH: Dockerfile
+    secrets:
+      CONTAINER_REGISTRY_URL: ${{ secrets.STAKATER_NEXUS_PREPROD_REGISTRY }}
+      CONTAINER_REGISTRY_USERNAME: ${{ secrets.STAKATER_NEXUS_PREPROD_USERNAME }}
+      CONTAINER_REGISTRY_PASSWORD: ${{ secrets.STAKATER_NEXUS_PREPROD_PASSWORD }}
+      SLACK_WEBHOOK_URL: ${{ secrets.STAKATER_DELIVERY_SLACK_WEBHOOK }}

.github/workflows/push.yaml

@@ -0,0 +1,19 @@
+name: Push
+
+on:
+  push:
+    branches:
+      - 'main'
+
+jobs:
+  push:
+    uses: stakater/.github/.github/workflows/[email protected]
+    with:
+      DOCKER_FILE_PATH: Dockerfile
+      RELEASE_BRANCH: main
+    secrets:
+      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 }}
+      GH_TOKEN: ${{ secrets.STAKATER_GITHUB_TOKEN }}

.github/workflows/release.yaml

@@ -0,0 +1,12 @@
+name: Release
+
+on:
+  push:
+    tags:
+      - "v*"
+
+jobs:
+  release:
+    uses: stakater/.github/.github/workflows/[email protected]
+    secrets:
+      SLACK_WEBHOOK_URL: ${{ secrets.STAKATER_DELIVERY_SLACK_WEBHOOK }}

.gitignore

@@ -0,0 +1,22 @@
+# Dist files
+dist/
+lib/
+
+# Test temp files
+**/__fixtures__/.temp/
+
+# Test coverage files
+coverage/
+
+# MacOS Desktop Services Store
+.DS_Store
+
+# Log files
+*.log
+
+# Typescript build info
+*.tsbuildinfo
+node_modules
+
+# Build files
+site/

.gitmodules

@@ -0,0 +1,3 @@
+[submodule "vocabulary"]
+	path = vocabulary
+	url = [email protected]:stakater/vocabulary.git

.markdownlint.yaml

@@ -0,0 +1,6 @@
+{
+  "MD007": { "indent": 4 },
+  "MD013": false,
+  "MD024": false,
+  "MD046": false,
+}

.vale.ini

@@ -0,0 +1,9 @@
+StylesPath = "vocabulary/styles"
+MinAlertLevel = warning
+
+Vocab = "Stakater"
+
+# Only check MarkDown files
+[*.md]
+
+BasedOnStyles = Vale

Dockerfile

@@ -0,0 +1,30 @@
+FROM python:3.11-alpine as builder
+
+RUN pip3 install mkdocs-material mkdocs-mermaid2-plugin
+
+# set workdir
+RUN mkdir -p $HOME/application
+WORKDIR $HOME/application
+
+# copy the entire application
+COPY --chown=1001:root . .
+
+# build the docs
+RUN mkdocs build
+
+FROM nginxinc/nginx-unprivileged:1.23-alpine as deploy
+COPY --from=builder $HOME/application/site/ /usr/share/nginx/html/
+COPY default.conf /etc/nginx/conf.d/
+
+# set non-root user
+USER 1001
+
+LABEL name="OpenShift as a Service" \
+      maintainer="Stakater <[email protected]>" \
+      vendor="Stakater" \
+      release="1" \
+      summary="Documentation for OpenShift as a Service"
+
+EXPOSE 8080:8080/tcp
+
+CMD ["nginx", "-g", "daemon off;"]

content/business-hours.md

@@ -0,0 +1,7 @@
+# Regular Business Hours of Stakater
+
+`Version: 30 Jan 2023`
+
+Regular business hours of Stakater refers to 07:00 (7 AM) to 15:00 (3 PM) (UTC) Monday through Friday except on legal holidays of the country of residence for Stakater employees.
+
+Non-business hours of Stakater refers to all the time that is outside regular business hours.

content/cost.md

@@ -0,0 +1,13 @@
+# Cost of the Service and Settlement Procedure
+
+`Version: 30 Jan 2023`
+
+A. The reporting period for the Service is one calendar month.
+
+B. The cost of the Services provided in the reporting period is calculated in accordance with the rules and conditions specified in these Terms of Service, as well as in the Order, in proportion to the number of months included in the reporting period.
+
+C. The payment of 100% of the cost of the Service provided shall be made at the end of the concerned reporting period no later than thirty (30) banking days from the end of the reporting period based on the invoice issued and sent by Stakater by email.
+
+D. The procedure for delivery and acceptance of the Service is set out in the Agreement.
+
+E. All prices are shown without VAT. The amount of VAT is paid by the Customer in addition to the cost of the Services. The VAT rate is determined by the current Tax Code of the country of residence from which Stakater will provide the Service.

content/general-provisions.md

@@ -0,0 +1,17 @@
+# General Provisions
+
+`Version: 30 Jan 2023`
+
+These Terms of the Managed OpenShift Service (elsewhere referred to as the Terms of Service, Terms) define the essence and composition of the "Managed OpenShift" Service (elsewhere referred to as the Service) — a set of technical subscription-based services continuously rendered by Stakater.
+
+Stakater is entitled to amend the Terms of Service unilaterally by approving a new version of the Terms.
+
+The new edition of the Terms of Service shall come into force on the thirtieth (30th) calendar day after the notice of amendment was sent to the Customer. The period from the date of Stakater's notification of changes to the Terms until the date on which the new version of the Terms takes effect is called the transition period.
+
+Stakater shall send notice of amendment of the Terms to the email address specified in the Service Agreement. The Customer is responsible for familiarizing themselves with the new edition of the Terms of Service.
+
+Refusal of the Customer to accept the new edition of the Terms and Conditions shall result in sending by the Customer to Stakater a notice of refusal to accept the new edition of the Terms during the transition period. The aforementioned notice shall be sent to the email address of Stakater specified in the Service Agreement.
+
+Notification of the Customer's refusal to accept the new edition of the Terms shall simultaneously be deemed to be a notice of early termination of the Agreement in respect of the relevant Order at the Customer's initiative by the unilateral refusal of the Customer to fulfill it. The Contract shall terminate in respect to the relevant Order on the last day of the transition period unless the Parties agree on an earlier date.
+
+Failure of the Customer to submit a refusal to accept the new edition of the Terms within the transition period and continued use of the Service by the Customer after the entry into force of the new edition of the Terms shall be deemed the Customer's acceptance of the new edition of the Terms in full.

content/index.md

@@ -0,0 +1,15 @@
+# Offer
+
+`Version: 30 Jan 2023`
+
+In addition to the `Stakater App Agility Platform`, Stakater offers operational and maintenance support for existing OpenShift clusters for flexible time periods. The Stakater Global SRE Team will be responsible for the operational efforts. Contact [`[email protected]`](mailto:[email protected]) for more info.
+
+Here are the terms of the service:
+
+1. [General Provisions](./general-provisions.md)
+1. [Composition of the Service](./service-composition.md)
+1. [Regular Business Hours of Stakater](./business-hours.md)
+1. [Technical Support](./technical-support.md)
+1. [Updating Clusters](./updating-clusters.md)
+1. [Service Level Agreement (SLA)](./sla.md)
+1. [Cost of the Service and Settlement Procedure](./cost.md)

content/service-composition.md

@@ -0,0 +1,21 @@
+# Composition of the Service
+
+`Version: 30 Jan 2023`
+
+The Managed OpenShift service includes, but is not limited to, the following services:
+
+* The post-installation technical support of the OpenShift clusters, and auxiliary software components, including regular updates using the latest versions of clusters and auxiliary components developed by Stakater along with monitoring systems and components for aggregating operating parameters of the cluster.
+
+* Consulting assistance to the Customer representatives: software developers, system administrators, engineers, and other technical specialists interacting with Stakater on behalf of the Customer (elsewhere referred to as the Contact persons), carried out as part of the post-installation technical support of the Customer to the extent and following the rules stipulated in these Terms of Service.
+
+* Monitoring of the health of the OpenShift clusters, responding to failures and errors in their operation in accordance with the rules defined in the Regulations.
+
+* Correcting errors promptly, developing, upgrading, and adapting auxiliary components of
+OpenShift clusters carried out by engineers of Stakater in accordance with their own
+production plans and internal technical regulations or as agreed upon by the Parties.
+
+Stakater does not guarantee the Service will meet the requirements and expectations of the Customer. The Customer agrees that the Service is carried out using Stakater's software tools that operate on an "as is" basis.
+
+The Customer undertakes to take into account the recommendations of Stakater concerning the operation of OpenShift clusters maintained by Stakater. These recommendations are aimed at preventing possible failures of the OpenShift clusters maintained by Stakater. The Customer shall be responsible for any risks arising due to ignoring such recommendations.
+
+The liability of Stakater is limited to fines and penalties imposed on Stakater under these Terms of Service. Stakater shall not be held liable for losses incurred by the Customer in connection with the provision of the Service.

content/sla.md

@@ -0,0 +1,134 @@
+# Service Level Agreement (SLA)
+
+`Version: 30 Jan 2023`
+
+This SLA establishes conditions and a method for measuring the level of service at a given time, defines the guaranteed level of service, and sets out penalties for violating the guaranteed level of service.
+
+The level of service is measured based on monitoring data for individual cluster components grouped into availability types. Some availability types require enabling a special high availability mode of operation of components of the OpenShift cluster (elsewhere referred to as the High Availability mode, HA) to ensure a guaranteed level of service.
+
+Specifications and operating conditions of components running in the High Availability mode:
+
+* The component is run in two or more instances to preserve availability in the case of a failure of a single instance
+* Enabling this mode requires additional computing resources
+* If there is more than one master node in the cluster, the High Availability mode is activated for all components by default
+* The HA mode can be turned off for individual components, such as authentication and monitoring, to reduce the cost of computing resources. However, we cannot guarantee the Service Level (SL) for such subsystems.
+* Control Plane — the cluster core — is considered running in the HA mode if it has at least three instances
+
+## Availability Types
+
+To accurately identify types of degradations and the degree of their impact on the performance of services, we define several types of unavailability for which it is possible to set the parameters under the SLA.
+
+### Synthetic Availability
+
+Synthetic availability is the availability of running applications in the cluster and cluster components that are not related to the availability of the cluster's Control Plane.
+
+The SLA for Synthetic Availability is valid only if these basic conditions are met:
+
+* Cluster nodes continue to be available
+* There is network connectivity between nodes
+* The application continues to operate correctly
+
+At the same time, applications keep on running that meet the following conditions:
+
+* The application itself caches DNS data
+* The application can operate with no scheduler or autoscaler running as well as with no ability to add/edit service endpoints
+* No `kube-apiserver` availability is required for the application to operate
+
+This availability type does not require enabling the HA mode for components.
+
+### Router Availability
+
+Router availability is the availability of ingress router and its components - incoming HTTP requests are delivered to end applications.
+
+The router availability SLA does not cover the network availability that depends on the infrastructure.
+
+This availability type requires enabling the HA mode for components.
+
+### Node Group Availability
+
+In managed OpenShift, nodes are grouped together based on a purpose and managed as an integrated entity. All nodes in the group have the same metadata defined in the parameters of a `NodeGroup` resource based on labels, annotations, or taint fields. Such a group of nodes is called the Node Group.
+
+Node Group Availability indicates that each Node Group has at least `N-1` correctly functioning nodes, where `N` is the minimum number of nodes in NodeGroup as defined in the configuration.
+
+The Node Group Availability SLA does not apply to cases when a node fails due to improper operation of an application installed by the customer.
+
+This availability type does not require enabling the HA mode for components.
+
+### Control Plane Availability
+
+Control plane availability indicates that the deployment process in the cluster is working, and self-healing processes are running. It formulates the availability level of the main control OpenShift components:
+
+* `console`
+* `etcd`
+* `ingress`
+* `kube-apiserver`
+* `kube-controller-manager`
+* `kube-dns`
+* `kube-scheduler`
+* `oauth-server`
+* `openshift-apiserver`
+* `openshift-cluster-csi-drivers`
+* `openshift-cluster-node-tuning-operator`
+* `openshift-image-registry`
+* `openshift-kube-scheduler`
+* `openshift-multus`
+* `openshift-operator-lifecycle-manager`
+* `openshift-sdn`
+* `openshift-storage-operator`
+* other components that the API depends on, such as Vertical Pod Autoscaler's admission controller
+
+This availability type requires enabling the HA mode for components.
+
+### Monitoring and Autoscaling Availability
+
+Monitoring and autoscaling availability means that monitoring and autoscaling are operating correctly. It defines the Prometheus availability level and auto-scaling capabilities of components and data sources:
+
+* Prometheus
+* Vertical Pod Autoscaler
+* Horizontal Pod Autoscaler
+
+This availability type requires enabling the HA mode for components.
+
+### Extensions Availability
+
+Extensions availability means that additional Kubernetes components could be available. It sets out the availability level of components not directly involved in delivering applications to the runtime environment and their operation in the cluster, such as addons from Stakater listed on [Managed AddOns](https://docs.stakater.com/content/sre/addons/introduction.html).
+
+This availability type requires enabling the HA mode for components.
+
+### Common SLA Conditions for all Availability Types
+
+Availability types do not apply to situations of complete lack of network connectivity between nodes or total inaccessibility of the cluster infrastructure.
+
+The availability of each cluster component individually and of the availability type as a whole is determined by the best value obtained from multiple probing agents.
+
+## Guaranteed Level of Service
+
+Availability Type | Non-Prod | Prod
+--- | --- | ---
+Synthetic | 99.0% | 99.5%
+Router | 99.0% | 99.5%
+Node Group | 99.0% | 99.5%
+Control Plane | 99.0% | 99.5%
+Monitoring and Autoscaling | 99.0% | 99.5%
+Extensions | 99.0% | 99.5%
+
+## Penalties for Violating the Service Level
+
+Stakater shall pay the penalty at the Customer's request for violation of the SLA conditions. The amount of the penalty is determined as follows:
+
+Penalty | Non-Prod | Prod
+--- | --- | ---
+The maximum amount of penalty per month of service for violating the SLA | No more than 10% of the monthly cost of service | No more than 20% of the monthly cost of service
+
+Stakater shall not be considered to have violated the SLA and shall not be deemed liable if the service level cannot be guaranteed for reasons beyond Stakater's control.
+
+If the SLA is violated for multiple availability types for the same cluster simultaneously, only the highest penalty for the availability type shall be subject to payment.
+
+## Additional Sections
+
+The following sections from the `SAAP` SLA also applies to the `Managed OpenShift Service` SLA:
+
+* [Excused Downtime](https://docs.stakater.com/content/saap-sla/saap-sla.html#6-excused-downtime)
+* [Monthly Uptime Percentage](https://docs.stakater.com/content/saap-sla/saap-sla.html#7-monthly-uptime-percentage)
+* [Limitations](https://docs.stakater.com/content/saap-sla/saap-sla.html#10-limitations)
+* [SLA Exclusions](https://docs.stakater.com/content/saap-sla/saap-sla.html#13-sla-exclusions)

content/technical-support.md

@@ -0,0 +1,13 @@
+# Technical Support
+
+`Version: 30 Jan 2023`
+
+Service Type | Non-Prod | Prod
+--- | --- | ---
+Incident response time | Up to 30 min | Up to 15 min
+24x7x365 monitoring and handling cluster incidents | No | Yes
+Technical advice on cluster architecture and applications during regular business hours | Yes, billed separately | Yes, billed separately
+Voice consultations with lead engineers during regular business hours | No | Yes, billed separately
+Dedicated technical contact | No | Yes
+Delivery of the Service when Stakater does not have direct SSH access to the cluster. Direct SSH access means access via a public IP address or access via a site-to-site VPN. | No | Yes
+Audit by the Information Security Service (ISS) involving conference calls with the Customer's ISS specialists, discussing the system design and practices used, and evaluating results of the audit conducted by the Customer's ISS. | No | Yes, up to 5 h