From 62311a7caeab8e57d6fd2b471b9add19504c80e9 Mon Sep 17 00:00:00 2001 From: Kyriakos Akriotis Date: Mon, 5 Feb 2024 08:21:36 +0100 Subject: [PATCH] blueprints structure init, fix typos in cce vault article --- .../source/best-practices/computing/index.rst | 14 + .../best-practices/data-analytics/index.rst | 14 + .../source/best-practices/index.rst | 20 + .../source/best-practices/network/index.rst | 15 + .../best-practices/security/cce_vault.rst | 615 ++++++++++++++++++ .../source/best-practices/security/index.rst | 16 + .../source/best-practices/storage/index.rst | 12 + doc/blueprints/source/index.rst | 9 + .../source/industry/automotive/index.rst | 11 + .../source/industry/education/index.rst | 11 + .../source/industry/finance/index.rst | 9 + .../source/industry/government/index.rst | 10 + .../source/industry/healthcare/index.rst | 10 + doc/blueprints/source/industry/index.rst | 20 + .../source/industry/media/index.rst | 9 + .../source/industry/retail/index.rst | 10 + .../source/use-cases/analytics/index.rst | 12 + .../source/use-cases/hybrid/index.rst | 10 + doc/blueprints/source/use-cases/index.rst | 17 + .../source/use-cases/migration/index.rst | 10 + .../source/use-cases/networking/index.rst | 11 + .../source/use-cases/security/index.rst | 10 + doc/source/_templates/article_external.tpl | 124 ++++ doc/source/_templates/article_internal.tpl | 85 +++ doc/source/_templates/solution.tpl | 168 +++++ 25 files changed, 1252 insertions(+) create mode 100644 doc/blueprints/source/best-practices/computing/index.rst create mode 100644 doc/blueprints/source/best-practices/data-analytics/index.rst create mode 100644 doc/blueprints/source/best-practices/index.rst create mode 100644 doc/blueprints/source/best-practices/network/index.rst create mode 100644 doc/blueprints/source/best-practices/security/cce_vault.rst create mode 100644 doc/blueprints/source/best-practices/security/index.rst create mode 100644 doc/blueprints/source/best-practices/storage/index.rst create mode 100644 doc/blueprints/source/industry/automotive/index.rst create mode 100644 doc/blueprints/source/industry/education/index.rst create mode 100644 doc/blueprints/source/industry/finance/index.rst create mode 100644 doc/blueprints/source/industry/government/index.rst create mode 100644 doc/blueprints/source/industry/healthcare/index.rst create mode 100644 doc/blueprints/source/industry/index.rst create mode 100644 doc/blueprints/source/industry/media/index.rst create mode 100644 doc/blueprints/source/industry/retail/index.rst create mode 100644 doc/blueprints/source/use-cases/analytics/index.rst create mode 100644 doc/blueprints/source/use-cases/hybrid/index.rst create mode 100644 doc/blueprints/source/use-cases/index.rst create mode 100644 doc/blueprints/source/use-cases/migration/index.rst create mode 100644 doc/blueprints/source/use-cases/networking/index.rst create mode 100644 doc/blueprints/source/use-cases/security/index.rst create mode 100755 doc/source/_templates/article_external.tpl create mode 100755 doc/source/_templates/article_internal.tpl create mode 100755 doc/source/_templates/solution.tpl diff --git a/doc/blueprints/source/best-practices/computing/index.rst b/doc/blueprints/source/best-practices/computing/index.rst new file mode 100644 index 0000000..1503e6c --- /dev/null +++ b/doc/blueprints/source/best-practices/computing/index.rst @@ -0,0 +1,14 @@ +Computing +========= + +The Computing section offers essential insights for optimizing computing resources. Discover guidelines for selecting +appropriate instance types, managing virtual machines efficiently, and leveraging auto-scaling capabilities for dynamic +workloads. Learn best practices for designing resilient and high-performance computing architectures, ensuring optimal +utilization of resources while maintaining cost-effectiveness. This section serves as a comprehensive guide for architects +and developers to fine-tune their computing strategies, enhancing the overall efficiency and reliability of applications +in the Open Telekom Cloud environment. + +.. toctree:: + :maxdepth: 1 + + diff --git a/doc/blueprints/source/best-practices/data-analytics/index.rst b/doc/blueprints/source/best-practices/data-analytics/index.rst new file mode 100644 index 0000000..350b8d7 --- /dev/null +++ b/doc/blueprints/source/best-practices/data-analytics/index.rst @@ -0,0 +1,14 @@ +Data Analytics +============== + +Here you can find strategic guidance for optimizing data processing workflows. Explore recommendations for selecting +and configuring data analytics services, ensuring efficient and scalable processing of large datasets. Learn about best +practices for data storage, retrieval, and integration to enhance overall analytics performance. This section is a +valuable resource for architects and data professionals, offering insights into designing robust and cost-effective data +analytics architectures within the Open Telekom Cloud, fostering informed decision-making and actionable insights. + + +.. toctree:: + :maxdepth: 1 + + diff --git a/doc/blueprints/source/best-practices/index.rst b/doc/blueprints/source/best-practices/index.rst new file mode 100644 index 0000000..341aece --- /dev/null +++ b/doc/blueprints/source/best-practices/index.rst @@ -0,0 +1,20 @@ +============== +Best Practices +============== + +Welcome Open Telekom Cloud Architecture Center Best Practices. +Here we provides crucial guidelines for optimizing cloud-based solutions with emphasis to architectural principles that +enhance reliability, scalability, and security. Explore our recommended strategies for resource management, such as +efficient utilization of compute and storage resources. Gain insights into designing for high availability and fault tolerance +to ensure robust system performance. This section serves as a valuable resource for architects and developers +to implement cloud solutions that align with industry best practices and maximize the benefits of the public cloud +infrastructure. + +.. toctree:: + :maxdepth: 1 + + computing/index + data-analytics/index + network/index + security/index + storage/index diff --git a/doc/blueprints/source/best-practices/network/index.rst b/doc/blueprints/source/best-practices/network/index.rst new file mode 100644 index 0000000..13ad2c9 --- /dev/null +++ b/doc/blueprints/source/best-practices/network/index.rst @@ -0,0 +1,15 @@ +Network +======= + +Network Best Practices outline key strategies for optimizing network configurations. Explore guidelines for designing +resilient and high-performance network architectures, including considerations for security and scalability. +Learn about best practices for leveraging Virtual Private Clouds (VPCs), network segmentation, and load balancing to +enhance overall network efficiency. This section serves as a valuable resource for architects and network administrators, +providing insights into building robust and secure network infrastructures within the Open Telekom Cloud environment, +ensuring reliable and seamless connectivity for applications and services. + + +.. toctree:: + :maxdepth: 1 + + diff --git a/doc/blueprints/source/best-practices/security/cce_vault.rst b/doc/blueprints/source/best-practices/security/cce_vault.rst new file mode 100644 index 0000000..4b2a95c --- /dev/null +++ b/doc/blueprints/source/best-practices/security/cce_vault.rst @@ -0,0 +1,615 @@ +=============================================== +Secrets management with CCE and Hashicorp Vault +=============================================== + +Most modern IT setups are composed of several subsystems like databases, object +stores, master controller, node access, and more. To access one component from +another, some form of credentials are required. Configuring and storing these +secrets directly in the components is considered as an anti-pattern, since a +vulnerability of one component may iteratively affect the security of the whole +setup. + +With centralized secret management it becomes unnecessary to keep secrets used +by various applications spread across DevOps environments. This helps to close +some security attack vectors (like `secret sprawl +`_, +`security islands `_), but +usually introduces a problem of the so-called `Secret Zero +`_ +as a key to the key storage. + +Vault is an open-source software, provided and maintained by Hashicorp, that +addresses this very problem. It is considered one of the reference solutions +for it. This article demonstrates how to utilize infrastructure authorization +with Hashicorp Vault in an CCE-powered setup. As an example workload, we deploy +a Zookeeper cluster with enabled TLS protection. Certificates for Zookeeper are +stored in Vault, and they oblige required practices like rotations or audits. +Zookeeper can easily be replaced by any other component that requires access to +internal credentials. + +Overview +======== + +TLS secrets are kept in the Vault. They are being read by Vault Agent component +running as a sidecar in Zookeeper service pod and writes certificates onto the +file system. Zookeeper services reads certificates populated by Agent. Vault +Agent is configured to use password-less access to Vault. Further in the +document it is explained how exactly this is implemented. + +Establishing trust between CCE and Vault +======================================== + +Before any application managed by the CCE is able to login to Vault relying on +infrastructure based authentication it is required to do some steps on the +Vault side. Kubernetes auth plugin is enabled and configured to only access +requests from specific Kubernetes cluster by providing its Certificate +Authority. To allow several multiple different CCE clusters to use Vault, a +dedicated auth path is going to be used. + +.. code-block:: shell + + $ vault auth enable -path kubernetes_cce1 kubernetes + $ vault write auth/kubernetes_cce1/config \ + kubernetes_host="$K8S_HOST" \ + kubernetes_ca_cert="$SA_CA_CRT" + +Since in our example a dedicated service account with token is being +periodically rotated using `client JWT as reviewer JWT +`_ +can be used. + +Access rules for Vault +====================== + +Having Auth plugin enabled, as described above, CCE workloads are able to +authenticate to Vault, but they can do nothing. It is now necessary to +establish further level of authorization and let particular service accounts of +CCE to get access to secrets in Vault. + +For the scope of the use case, we grant the Zookeeper service account from its +namespace access to the TLS secrets stored in Vault's key-value store. For that +a policy providing a read-only access to the /tls/zk* and /tls/ca paths is +created. + +.. code-block:: shell + + $ vault policy write tls-zk-ro - <`_ + +* Use `PKI secrets engine `_ to + issue certificates + +Vault enables users not only to store TLS certificates data in the key-value store, +but also to create and revoke them. To keep this tutorial simple enough we are +not going to do this and just upload generated certificates into the KV store. +For production setups this example can be easily extended with extra actions. + +.. code-block:: shell + + $ vault kv put secret/tls/ca certificate=@ca.crt + $ vault kv put secret/tls/zk_server certificate=@zk_server.crt private_key=@zk_server.key + $ vault kv put secret/tls/zk_client certificate=@zk_client.crt private_key=@zk_client.key + +Certificate paths and property names used here are referenced by the Zookeeper installation. + +Deploying Zookeeper +=================== + +Now that the secrets are stored safely in Vault and only allowed applications +can fetch them it is time to look how exactly the application accesses the +secrets. Generally, utilizing Vault requires modification of the application. +`Vault agent `_ is a tool that was +created to simplify secrets delivery for applications when it is hard or +difficult to change the application itself. The Agent is taking care of reading +secrets from Vault and can deliver them to the file system. + +There are many way how to properly implement Zookeeper service on the +Kubernetes. The scope of the blueprint is not Zookeeper itself, but +demonstrating how an application can be supplied by required certificates. The +reference architecture described here bases on the best practices gathered from +various sources and extended by HashiCorp Vault. It overrides default Zookeeper +start scripts in order to allow better control of the runtime settings and +properly fill all required configuration options for TLS to work. Other methods +of deploying Zookeeper can be easily used here instead. + +1. Create a Kubernetes namespace named `zookeeper`. + +.. code-block:: shell + + $ kubectl create namespace zookeeper + +2. Create a Kubernetes service account named `zookeeper`. + +.. code-block:: shell + + $ kubectl create serviceaccount zookeeper + +3. In Kubernetes a *service account* provides an identity for the services + running in the pod so that the process can access Kubernetes API. The same + identity can be used to access Vault, but require one special permission - + access to the token review API of the Kubernetes. When instead a dedicated + reviewer JWT is used, this step is not necessary, but it also means + long-living sensitive data is used and frequently transferred over the + network. More details on various ways to use Kubernetes tokens to authorize + to Vault `can be found here + `_. + +.. code-block:: shell + + $ kubectl create clusterrolebinding vault-client-auth-delegator \ + --clusterrole=system:auth-delegator \ + --serviceaccount=zookeeper:zookeeper + +4. Create a Kubernetes ConfigMap with all required configurations. One possible + approach is to define dedicated health and readiness check scripts and to + override automatically created Zookeeper start script. This is especially + useful when TLS protection is enabled, but default container scripts do not + support this. + +.. code-block:: yaml + :caption: zookeeper-cm.yaml + + --- + apiVersion: v1 + kind: ConfigMap + metadata: + name: zookeeper-config + namespace: "zookeeper" + data: + ok: | + #!/bin/sh + # This sript is used by live-check of Kubernetes pod + if [ -f /tls/ca.pem ]; then + echo "srvr" | openssl s_client -CAfile /tls/ca.pem -cert /tls/client/tls.crt \ + -key /tls/client/tls.key -connect 127.0.0.1:${1:-2281} -quiet -ign_eof 2>/dev/null | grep Mode + + else + zkServer.sh status + fi + + ready: | + #!/bin/sh + # This sript is used by readiness-check of Kubernetes pod + if [ -f /tls/ca.pem ]; then + echo "ruok" | openssl s_client -CAfile /tls/ca.pem -cert /tls/client/tls.crt \ + -key /tls/client/tls.key -connect 127.0.0.1:${1:-2281} -quiet -ign_eof 2>/dev/null + else + echo ruok | nc 127.0.0.1 ${1:-2181} + fi + + run: | + #!/bin/bash + # This is the main starting script + set -a + ROOT=$(echo /apache-zookeeper-*) + ZK_USER=${ZK_USER:-"zookeeper"} + ZK_LOG_LEVEL=${ZK_LOG_LEVEL:-"INFO"} + ZK_DATA_DIR=${ZK_DATA_DIR:-"/data"} + ZK_DATA_LOG_DIR=${ZK_DATA_LOG_DIR:-"/data/log"} + ZK_CONF_DIR=${ZK_CONF_DIR:-"/conf"} + ZK_CLIENT_PORT=${ZK_CLIENT_PORT:-2181} + ZK_SSL_CLIENT_PORT=${ZK_SSL_CLIENT_PORT:-2281} + ZK_SERVER_PORT=${ZK_SERVER_PORT:-2888} + ZK_ELECTION_PORT=${ZK_ELECTION_PORT:-3888} + ID_FILE="$ZK_DATA_DIR/myid" + ZK_CONFIG_FILE="$ZK_CONF_DIR/zoo.cfg" + LOG4J_PROPERTIES="$ZK_CONF_DIR/log4j.properties" + HOST=$(hostname) + DOMAIN=`hostname -d` + APPJAR=$(echo $ROOT/*jar) + CLASSPATH="${ROOT}/lib/*:${APPJAR}:${ZK_CONF_DIR}:" + if [[ $HOST =~ (.*)-([0-9]+)$ ]]; then + NAME=${BASH_REMATCH[1]} + ORD=${BASH_REMATCH[2]} + MY_ID=$((ORD+1)) + else + echo "Failed to extract ordinal from hostname $HOST" + exit 1 + fi + mkdir -p $ZK_DATA_DIR + mkdir -p $ZK_DATA_LOG_DIR + echo $MY_ID >> $ID_FILE + + echo "dataDir=$ZK_DATA_DIR" >> $ZK_CONFIG_FILE + echo "dataLogDir=$ZK_DATA_LOG_DIR" >> $ZK_CONFIG_FILE + echo "4lw.commands.whitelist=*" >> $ZK_CONFIG_FILE + # Client TLS configuration + if [[ -f /tls/ca.pem ]]; then + echo "secureClientPort=$ZK_SSL_CLIENT_PORT" >> $ZK_CONFIG_FILE + echo "ssl.keyStore.location=/tls/client/client.pem" >> $ZK_CONFIG_FILE + echo "ssl.trustStore.location=/tls/ca.pem" >> $ZK_CONFIG_FILE + else + echo "clientPort=$ZK_CLIENT_PORT" >> $ZK_CONFIG_FILE + fi + # Server TLS configuration + if [[ -f /tls/ca.pem ]]; then + echo "serverCnxnFactory=org.apache.zookeeper.server.NettyServerCnxnFactory" >> $ZK_CONFIG_FILE + echo "sslQuorum=true" >> $ZK_CONFIG_FILE + echo "ssl.quorum.keyStore.location=/tls/server/server.pem" >> $ZK_CONFIG_FILE + echo "ssl.quorum.trustStore.location=/tls/ca.pem" >> $ZK_CONFIG_FILE + fi + for (( i=1; i<=$ZK_REPLICAS; i++ )) + do + echo "server.$i=$NAME-$((i-1)).$DOMAIN:$ZK_SERVER_PORT:$ZK_ELECTION_PORT" >> $ZK_CONFIG_FILE + done + rm -f $LOG4J_PROPERTIES + echo "zookeeper.root.logger=$ZK_LOG_LEVEL, CONSOLE" >> $LOG4J_PROPERTIES + echo "zookeeper.console.threshold=$ZK_LOG_LEVEL" >> $LOG4J_PROPERTIES + echo "zookeeper.log.threshold=$ZK_LOG_LEVEL" >> $LOG4J_PROPERTIES + echo "zookeeper.log.dir=$ZK_DATA_LOG_DIR" >> $LOG4J_PROPERTIES + echo "zookeeper.log.file=zookeeper.log" >> $LOG4J_PROPERTIES + echo "zookeeper.log.maxfilesize=256MB" >> $LOG4J_PROPERTIES + echo "zookeeper.log.maxbackupindex=10" >> $LOG4J_PROPERTIES + echo "zookeeper.tracelog.dir=$ZK_DATA_LOG_DIR" >> $LOG4J_PROPERTIES + echo "zookeeper.tracelog.file=zookeeper_trace.log" >> $LOG4J_PROPERTIES + echo "log4j.rootLogger=\${zookeeper.root.logger}" >> $LOG4J_PROPERTIES + echo "log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender" >> $LOG4J_PROPERTIES + echo "log4j.appender.CONSOLE.Threshold=\${zookeeper.console.threshold}" >> $LOG4J_PROPERTIES + echo "log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout" >> $LOG4J_PROPERTIES + echo "log4j.appender.CONSOLE.layout.ConversionPattern=\ + %d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n" >> $LOG4J_PROPERTIES + if [ -n "$JMXDISABLE" ] + then + MAIN=org.apache.zookeeper.server.quorum.QuorumPeerMain + else + MAIN="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=$JMXPORT \ + -Dcom.sun.management.jmxremote.authenticate=$JMXAUTH \ + -Dcom.sun.management.jmxremote.ssl=$JMXSSL \ + -Dzookeeper.jmx.log4j.disable=$JMXLOG4J \ + org.apache.zookeeper.server.quorum.QuorumPeerMain" + fi + set -x + exec java -cp "$CLASSPATH" $JVMFLAGS $MAIN $ZK_CONFIG_FILE + + vault-agent-config.hcl: | + exit_after_auth = true + pid_file = "/home/vault/pidfile" + auto_auth { + method "kubernetes" { + mount_path = "auth/kubernetes_cce1" + config = { + role = "zookeeper" + token_path = "/run/secrets/tokens/vault-token" + } + } + sink "file" { + config = { + path = "/home/vault/.vault-token" + } + } + } + + cache { + use_auto_auth_token = true + } + + # ZK is neat-picky on cert file extensions + template { + destination = "/tls/ca.pem" + contents = <` with the address of the + Vault server. This includes a pod with Vault Agent side container as an init + container, Vault Agent side container used continuously in the run cycle of + the pod and Zookeeper main container. + +.. code-block:: yaml + :caption: zookeeper-ss.yaml + + apiVersion: apps/v1 + kind: StatefulSet + spec: + podManagementPolicy: Parallel + replicas: 3 + selector: + matchLabels: + app: zookeeper + component: server + serviceName: zookeeper-headless + template: + metadata: + labels: + app: zookeeper + component: server + spec: + containers: + + - args: + - agent + - -config=/etc/vault/vault-agent-config.hcl + - -log-level=debug + - -exit-after-auth=false + env: + - name: VAULT_ADDR + value: + image: vault:1.9.0 + name: vault-agent-sidecar + volumeMounts: + - mountPath: /etc/vault + name: vault-agent-config + - mountPath: /tls + name: cert-data + - mountPath: /var/run/secrets/tokens + name: k8-tokens + + - command: + - /bin/bash + - -xec + - /config-scripts/run + env: + - name: ZK_REPLICAS + value: "3" + - name: ZOO_PORT + value: "2181" + - name: ZOO_STANDALONE_ENABLED + value: "false" + - name: ZOO_TICK_TIME + value: "2000" + image: zookeeper:3.7.0 + livenessProbe: + exec: + command: + - sh + - /config-scripts/ok + failureThreshold: 2 + initialDelaySeconds: 20 + periodSeconds: 30 + successThreshold: 1 + timeoutSeconds: 5 + name: zookeeper + ports: + - containerPort: 2281 + name: client + protocol: TCP + - containerPort: 2888 + name: server + protocol: TCP + - containerPort: 3888 + name: election + protocol: TCP + readinessProbe: + exec: + command: + - sh + - /config-scripts/ready + failureThreshold: 2 + initialDelaySeconds: 20 + periodSeconds: 30 + successThreshold: 1 + timeoutSeconds: 5 + securityContext: + runAsUser: 1000 + volumeMounts: + - mountPath: /data + name: datadir + - mountPath: /tls + name: cert-data + - mountPath: /config-scripts + name: zookeeper-config + dnsPolicy: ClusterFirst + + initContainers: + - args: + - agent + - -config=/etc/vault/vault-agent-config.hcl + - -log-level=debug + - -exit-after-auth=true + env: + - name: VAULT_ADDR + value: + image: vault:1.9.0 + name: vault-agent + volumeMounts: + - mountPath: /etc/vault + name: vault-agent-config + - mountPath: /tls + name: cert-data + - mountPath: /var/run/secrets/tokens + name: k8-tokens + restartPolicy: Always + serviceAccount: zookeeper + serviceAccountName: zookeeper + terminationGracePeriodSeconds: 1800 + volumes: + - configMap: + defaultMode: 420 + items: + - key: vault-agent-config.hcl + path: vault-agent-config.hcl + name: zookeeper-config + name: vault-agent-config + - configMap: + defaultMode: 365 + name: zookeeper-config + name: zookeeper-config + - emptyDir: {} + name: cert-data + - name: k8-tokens + projected: + defaultMode: 420 + sources: + - serviceAccountToken: + expirationSeconds: 7200 + path: vault-token + + updateStrategy: + type: RollingUpdate + volumeClaimTemplates: + - apiVersion: v1 + kind: PersistentVolumeClaim + metadata: + name: datadir + spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 5Gi + storageClassName: csi-disk + volumeMode: Filesystem + +.. code-block:: bash + + $ kubectl apply -f zookeeper-ss.yaml + +With this a production-ready Zookeeper service with enabled TLS has been +deployed successfully to the CCE. The Vault Agent takes care of authorizing to +HashiCorp Vault using a Kubernetes service account with a short time to live +token and fetches required secrets to the file system. In the entire Kubernetes +deployment there are no secrets for the application, neither the key to the +Vault, nor TLS certificates themselves. Not even using Kubernetes secrets is +necessary. + +References +========== + +.. seealso:: + + `Vault Agent with Kubernetes `_ + + `Kubernetes auth method `_ diff --git a/doc/blueprints/source/best-practices/security/index.rst b/doc/blueprints/source/best-practices/security/index.rst new file mode 100644 index 0000000..e4fc5bb --- /dev/null +++ b/doc/blueprints/source/best-practices/security/index.rst @@ -0,0 +1,16 @@ +Security +======== + +The security best practices offer comprehensive guidance on fortifying cloud environments. Explore recommendations for +implementing robust identity and access management, encryption protocols, and network security measures. Learn how to +secure data at rest and in transit, as well as strategies for monitoring and responding to +security incidents. This section is a crucial resource for architects and cybersecurity professionals, providing +insights into designing and maintaining resilient security postures within the Open Telekom Cloud, ensuring the +confidentiality, integrity, and availability of sensitive information. + +.. toctree:: + :maxdepth: 1 + + cce_vault + + diff --git a/doc/blueprints/source/best-practices/storage/index.rst b/doc/blueprints/source/best-practices/storage/index.rst new file mode 100644 index 0000000..f0076ae --- /dev/null +++ b/doc/blueprints/source/best-practices/storage/index.rst @@ -0,0 +1,12 @@ +Storage +======= + +Storage best practices offer key insights into optimizing storage solutions. Explore guidelines for selecting +appropriate storage types, managing data lifecycle, and implementing redundancy for enhanced durability. Learn about +best practices for achieving optimal performance and cost-effectiveness in storage configurations. This section is a +valuable resource for architects and storage administrators, providing essential strategies to design resilient and +scalable storage architectures within the Open Telekom Cloud environment, ensuring efficient data management and retrieval. + +.. toctree:: + :maxdepth: 1 + diff --git a/doc/blueprints/source/index.rst b/doc/blueprints/source/index.rst index 9bb7bac..3ede24a 100644 --- a/doc/blueprints/source/index.rst +++ b/doc/blueprints/source/index.rst @@ -1,3 +1,12 @@ ========== Blueprints ========== + + + +.. toctree:: + :maxdepth: 1 + + best-practices/index + use-cases/index + industry/index diff --git a/doc/blueprints/source/industry/automotive/index.rst b/doc/blueprints/source/industry/automotive/index.rst new file mode 100644 index 0000000..736efe5 --- /dev/null +++ b/doc/blueprints/source/industry/automotive/index.rst @@ -0,0 +1,11 @@ +Automotive +========== + +Explore practical examples demonstrating how the platform can supports the automotive industry's unique requirements, +from connected car technologies to manufacturing processes. This section provides architects with insights into designing +scalable and secure cloud architectures to enhance innovation and efficiency in the automotive domain. Discover recommended +best practices, empowering users to leverage Open Telekom Cloud for optimized performance and transformative capabilities +within the automotive industry's dynamic landscape. + +.. toctree:: + :maxdepth: 1 diff --git a/doc/blueprints/source/industry/education/index.rst b/doc/blueprints/source/industry/education/index.rst new file mode 100644 index 0000000..6b5c238 --- /dev/null +++ b/doc/blueprints/source/industry/education/index.rst @@ -0,0 +1,11 @@ +Education +========= + +Explore practical examples showcasing how the platform supports e-learning applications, research initiatives, and +administrative processes. This section provides architects with insights into designing scalable and cost-effective +cloud architectures to meet the diverse needs of educational institutions. Discover recommended best practices, +empowering users and educational institutions to leverage Open Telekom Cloud for enhanced collaboration, resource +efficiency, and innovation. + +.. toctree:: + :maxdepth: 1 diff --git a/doc/blueprints/source/industry/finance/index.rst b/doc/blueprints/source/industry/finance/index.rst new file mode 100644 index 0000000..68b068f --- /dev/null +++ b/doc/blueprints/source/industry/finance/index.rst @@ -0,0 +1,9 @@ +Finance +======= + +Explore practical examples demonstrating how the platform supports secure and compliant financial applications, +from digital banking to risk management. This section provides architects with insights into designing robust, scalable, +and regulatory-compliant cloud architectures tailored to financial industry requirements. + +.. toctree:: + :maxdepth: 1 diff --git a/doc/blueprints/source/industry/government/index.rst b/doc/blueprints/source/industry/government/index.rst new file mode 100644 index 0000000..c3a5ff4 --- /dev/null +++ b/doc/blueprints/source/industry/government/index.rst @@ -0,0 +1,10 @@ +Government +========== + +The Government section focuses on tailored cloud solutions for the public sector. Here you can find showcases +how the platform can support secure and compliant government applications, from citizen services to data management. This +section provides architects with insights into designing resilient, scalable, and regulatory-compliant cloud +architectures tailored to public administration requirements. + +.. toctree:: + :maxdepth: 1 diff --git a/doc/blueprints/source/industry/healthcare/index.rst b/doc/blueprints/source/industry/healthcare/index.rst new file mode 100644 index 0000000..1f2f24a --- /dev/null +++ b/doc/blueprints/source/industry/healthcare/index.rst @@ -0,0 +1,10 @@ +Healthcare +========== + +Explore practical examples illustrating how the platform supports secure and compliant healthcare applications, from +electronic health records to medical research. This section provides architects with insights into designing robust, +scalable, and regulatory-compliant cloud architectures that can meet the unique needs of the healthcare industry. + +.. toctree:: + :maxdepth: 1 + diff --git a/doc/blueprints/source/industry/index.rst b/doc/blueprints/source/industry/index.rst new file mode 100644 index 0000000..fbf1e06 --- /dev/null +++ b/doc/blueprints/source/industry/index.rst @@ -0,0 +1,20 @@ +Industry Solutions +================== + +This section provides tailored solutions for diverse sectors, including healthcare, finance, +automotive, media, education, retail and government. Explore industry-specific scenarios showcasing the platform's adaptability +to unique requirements and challenges. This section offers architects valuable insights into designing cloud solutions +that align with the specific needs and compliance standards of their respective industries. Discover best practices and +recommended architectures, empowering users to leverage Open Telekom Cloud effectively for industry-specific use cases, +ensuring optimal performance and regulatory adherence. + +.. toctree:: + :maxdepth: 1 + + government/index + media/index + automotive/index + education/index + finance/index + healthcare/index + retail/index diff --git a/doc/blueprints/source/industry/media/index.rst b/doc/blueprints/source/industry/media/index.rst new file mode 100644 index 0000000..38de7fd --- /dev/null +++ b/doc/blueprints/source/industry/media/index.rst @@ -0,0 +1,9 @@ +Media +===== + +Explore practical examples showcasing how the platform supports content delivery, media processing, and collaborative +production workflows. This section provides architects with insights into designing scalable and cost-effective cloud +architectures to match the dynamic demands of the media industry. + +.. toctree:: + :maxdepth: 1 diff --git a/doc/blueprints/source/industry/retail/index.rst b/doc/blueprints/source/industry/retail/index.rst new file mode 100644 index 0000000..329ac81 --- /dev/null +++ b/doc/blueprints/source/industry/retail/index.rst @@ -0,0 +1,10 @@ +Retail +====== + +Explore practical examples showcasing how the platform supports e-commerce applications, supply chain management, and +customer engagement solutions. This section provides architects with insights into designing scalable and customer-focused +cloud architectures to meet the evolving needs of the retail industry. + +.. toctree:: + :maxdepth: 1 + diff --git a/doc/blueprints/source/use-cases/analytics/index.rst b/doc/blueprints/source/use-cases/analytics/index.rst new file mode 100644 index 0000000..bd4f482 --- /dev/null +++ b/doc/blueprints/source/use-cases/analytics/index.rst @@ -0,0 +1,12 @@ +Data Analytics & AI +=================== + +Explore real-world scenarios demonstrating the platform's capabilities in processing and deriving insights from large +datasets. From business intelligence to predictive analytics, this section is the necessary starting point for architects +and data professionals. Discover how Open Telekom Cloud's analytics services can empower organizations to extract meaningful +information, optimize decision-making processes, and drive innovation through advanced data analysis. + +.. toctree:: + :maxdepth: 1 + + diff --git a/doc/blueprints/source/use-cases/hybrid/index.rst b/doc/blueprints/source/use-cases/hybrid/index.rst new file mode 100644 index 0000000..c1a1f03 --- /dev/null +++ b/doc/blueprints/source/use-cases/hybrid/index.rst @@ -0,0 +1,10 @@ +Hybrid +====== + +Explore practical examples showcasing seamless integration between on-premises infrastructure and the Open Telekom Cloud +platform. This section provides insights for architects on optimizing hybrid architectures, ensuring flexibility, +scalability, and streamlined management. Learn how organizations can leverage the hybrid model to balance performance +and compliance requirements, fostering a dynamic and efficient IT environment tailored to specific business needs. + +.. toctree:: + :maxdepth: 1 diff --git a/doc/blueprints/source/use-cases/index.rst b/doc/blueprints/source/use-cases/index.rst new file mode 100644 index 0000000..7e6277b --- /dev/null +++ b/doc/blueprints/source/use-cases/index.rst @@ -0,0 +1,17 @@ +Use Cases +========= + +Welcome Open Telekom Cloud Architecture Center Use Cases. Here you can find tailored solutions and +practical implementations for a range of scenarios. Explore real-world examples demonstrating the versatility and optimal +application and infrastructure design using our cloud services. This section serves as a comprehensive +resource for architects, offering insights into how to adapt and optimize cloud solutions for specific business needs. +Discover architecture recommendations and ready solutions for diverse use cases. + +.. toctree:: + :maxdepth: 1 + + hybrid/index + security/index + networking/index + migration/index + analytics/index diff --git a/doc/blueprints/source/use-cases/migration/index.rst b/doc/blueprints/source/use-cases/migration/index.rst new file mode 100644 index 0000000..e9e074d --- /dev/null +++ b/doc/blueprints/source/use-cases/migration/index.rst @@ -0,0 +1,10 @@ +Migration +========= + +Explore real-world scenarios demonstrating how organizations can efficiently move their applications and data to Open Telekom Cloud. +This section provides architects with migration battle-tested techniques to ensure a smooth transition while minimizing downtime and +optimizing resource utilization. Discover insights into planning, executing, and validating successful migrations, +empowering users to harness the benefits of the cloud environment effectively. + +.. toctree:: + :maxdepth: 1 diff --git a/doc/blueprints/source/use-cases/networking/index.rst b/doc/blueprints/source/use-cases/networking/index.rst new file mode 100644 index 0000000..1a20d7c --- /dev/null +++ b/doc/blueprints/source/use-cases/networking/index.rst @@ -0,0 +1,11 @@ +Networking +========== + +Explore practical examples showcasing the flexibility and scalability of networking solutions within +Open Telekom Cloud. This section provides architects with insights into designing resilient and high-performance +networks, addressing specific use cases such as multi-tier applications or distributed architectures. +Discover recommended best practices for network security, load balancing, and connectivity, empowering users to tailor +their networking strategies to meet the unique requirements of their applications and workloads. + +.. toctree:: + :maxdepth: 1 diff --git a/doc/blueprints/source/use-cases/security/index.rst b/doc/blueprints/source/use-cases/security/index.rst new file mode 100644 index 0000000..12880c2 --- /dev/null +++ b/doc/blueprints/source/use-cases/security/index.rst @@ -0,0 +1,10 @@ +Security & Compliance +===================== + +Explore practical examples demonstrating how the platform addresses security and compliance challenges across industries. +This section provides architects with insights into implementing robust identity and access management, encryption +protocols, and compliance controls. Discover recommended best practices for securing sensitive data and ensuring +regulatory adherence, empowering users to design and deploy secure, compliant solutions in Open Telekom Cloud. + +.. toctree:: + :maxdepth: 1 diff --git a/doc/source/_templates/article_external.tpl b/doc/source/_templates/article_external.tpl new file mode 100755 index 0000000..cdaf1fd --- /dev/null +++ b/doc/source/_templates/article_external.tpl @@ -0,0 +1,124 @@ +. meta:: + :description: add a SEO description here + :keywords: add SEO keywords here, and list additionally all OTC services used + +================== +Article (External) +================== + +.. Introduction + +Introduction +============ + +| > *There are no further requirements for an article except to include the following sections at the **end**, and to follow all general Open Telekom Cloud Architecture Center content requirements.* +| > *An Open Telekom Cloud Architecture Center article template, for **external** creators, requires the following sections at the end of the article:* + +.. topic:: TL;DR + + | >> Make a brief summary of what is the article about + +.. Main Article + +.. Components + +| > *No header required here* +| > *(Expected to list all the Open Telekom Cloud components used, but it could be optional if it just an architectural paradigm.* + +.. Sections 1..n + +| > You can name the Section titles as it seems fit to the workflow of the article. + +Section 1 +========= + +Section 2 +========= + +Section n +========= + + +.. Authors and Contributors + +Contributors +============ + +| > *(Expected, but it could be optional if all the contributors would prefer not to be mentioned)* +| > *Start with the explanation text (same for every article), in italics.* +| > *Then include the "Principal authors" list and the "Additional contributors" list (if there are additional contributors) (all in plain text, not italics or bold).* +| > *Link each contributor's name to the person's LinkedIn profile.* +| > *After the name, place a pipe symbol ("|") with spaces, and then enter the person's title.* +| > *Do not include any additional links except the LinkedIn profile URL.* + +*It was originally written by the following contributors:* + +Principal authors: + +.. admonition:: Authors + + `(Author 1 Name) | (Title, such as "Cloud Engineer") `_ + + `(Author 2 Name) | (Title, such as "Cloud Architect") `_ + +| > *Only the primary authors.* +| > *List them alphabetically, by last name.* +| > *Use this format: **Fname Lname**.* +| > *If the article gets rewritten, keep the original authors and add in the new one(s).* + +Other contributors: + +| > *Include contributing (but not **primary**) authors, major editors (not minor edits), and technical reviewers.* +| > *List them alphabetically, by last name. Use this format: **Fname Lname**.* + +.. admonition:: Contributors + + `(Author 1 Name) | (Title, such as "Cloud Engineer") `_ + + `(Author 2 Name) | (Title, such as "Cloud Architect") `_ + + +.. Next steps & Related Resources + +Next Steps +========== + +| > *(Expected, but it could be optional if you don't want the article stops here and doesn't connect with other resources)* +| > *Add site-relative links to Architecture Center related articles but NOT to external or third-party resources* +| > *If there are additional resources like Cloud Topology Designer solution or Github repos, list them first with the aforementioned order* + +.. seealso:: + + `Link1 `_ + + `Link2 `_ + +Resources +========= + +.. Resources + +| > *If there are additional deployable resources like Cloud Topology Designer solution or Github repos, list them first with the aforementioned order* + +.. seealso:: + + `Link1 `_ + + `Link2 `_ + + +.. References + +References +========== + +| > *Add site-relative links to Architecture Center articles* +| > *Add links to external or third-party resources* + +.. seealso:: + + `Link1 `_ + + `Link2 `_ + +| > **REMOVE ALL THE LINES THAT START WITH "| >"** diff --git a/doc/source/_templates/article_internal.tpl b/doc/source/_templates/article_internal.tpl new file mode 100755 index 0000000..c5eef08 --- /dev/null +++ b/doc/source/_templates/article_internal.tpl @@ -0,0 +1,85 @@ +. meta:: + :description: add a SEO description here + :keywords: add SEO keywords here, and list additionally all OTC services used + +================== +Article (Internal) +================== + +.. Introduction + +Introduction +============ + +| > *There are no further requirements for an article except to include the following sections at the **end**, and to follow all general Open Telekom Architecture Center content requirements.* +| > *An Open Telekom Cloud Architecture Center article template, for **external** creators, requires the following sections at the end of the article:* + +.. topic:: TL;DR + + | >> Make a brief summary of what is the article about + +.. Main Article + +.. Components + +| > *No header required here* +| > *(Expected to list all the Open Telekom Cloud components used, but it could be optional if it just an architectural paradigm.* + +.. Sections 1..n + +| > *You can name the Section titles as it seems fit to the workflow of the article.* + +Section 1 +========= + +Section 2 +========= + +Section n +========= + + +.. Next steps & Related Resources + +Next Steps +========== + +| > *(Expected, but it could be optional if you don't want the article stops here and doesn't connect with other resources)* +| > *Add site-relative links to Architecture Center related articles but NOT to external or third-party resources* +| > *If there are additional resources like Cloud Topology Designer solution or Github repos, list them first with the aforementioned order* + +.. seealso:: + + `Link1 `_ + + `Link2 `_ + +Resources +========= + +.. Resources + +| > *If there are additional deployable resources like Cloud Topology Designer solution or Github repos, list them first with the aformentioned order* + +.. seealso:: + + `Link1 `_ + + `Link2 `_ + + +.. References + +References +========== + +| > *Add site-relative links to Architecture Center articles* +| > *Add links to external or third-party resources* + +.. seealso:: + + `Link1 `_ + + `Link2 `_ + +| > **REMOVE ALL THE LINES THAT START WITH "| >"** diff --git a/doc/source/_templates/solution.tpl b/doc/source/_templates/solution.tpl new file mode 100755 index 0000000..7bf0c94 --- /dev/null +++ b/doc/source/_templates/solution.tpl @@ -0,0 +1,168 @@ +. meta:: + :description: add a SEO description here + :keywords: add SEO keywords here, and list additionally all OTC services used + +======== +Solution +======== + +.. Introduction + +Introduction +============ + +| > *In this section, include 1-2 sentences to briefly explain this architecture.* +| > *The full scenario info will go in the "Scenario details" section* +| > *Include a TL;DR;* + +.. topic:: TL;DR + + | >> Make a brief summary of the scenario details and what are going to achieve with this solution. INSIDE THIS BOX + +.. Architecture + +Architecture +============ + +| > *Architecture diagram goes here. Use the following format:* + +.. image:: https://docs.otc.t-systems.com/cloud-container-engine/umn/_images/en-us_image_0000001172392670.png + +| > *Note: if there is a PowerPoint or a Visio attachment for the Architecture Diagram include it in the Resources section for download* + +.. Scenario + +Scenario +======== + +| > *In this section, include a numbered list that annotates/describes the scenario steps of the solution. Explain what each step does.* +| > *Start from the user or external data source, and then follow the flow through the rest of the solution* + +| > Examples: + + #. Admin 1 adds, updates, or deletes an entry in Open Telekom Cloud console. + #. Admin 1 commits and syncs the code changes to forked repository. + #. Admin 1 creates a pull request (PR) to merge the changes to the main repository. + #. The build pipeline runs on the PR. + #. Check the status in Open Telekom Cloud console. + +.. Components + +| > *No header required here* +| > *(Expected to list all the Open Telekom Cloud components used, but it could be optional if it just an architectural paradigm.* + +.. Scenario details + +| > *Scenario details* +| > *This should be an explanation of the business problem and why this scenario was built to solve it.* +| > *What prompted them to solve the problem?* +| > *What services were used in building out this solution?* +| > *What does this example scenario show? What are the customer's goals?* +| > *What were the benefits of implementing the solution?* + +.. Sections 1..n + +| > *You can name the Section titles as it seems fit to the workflow of the article.* + +Section 1 +========= + +Section 2 +========= + +Section n +========= + +.. Potential use cases + +Potential Use Cases +=================== + +| > *What industry is the customer in? Use the following industry keywords, when possible,* +| > *to get the article into the proper search and filter results: retail, finance, manufacturing, healthcare, government, energy, telecommunications, education, automotive, nonprofit, game, media (media and entertainment), travel (includes hospitality, like restaurants), facilities (includes real estate), aircraft (includes aerospace and satellites), agriculture, and sports.* +| > *Are there any other use cases or industries where this would be a fit?* +| > *How similar or different are they to what's in this article?* + +.. Authors and Contributors + +Contributors +============ + +| > *(Expected, but it could be optional if all the contributors would prefer not to be mentioned)* +| > *Start with the explanation text (same for every article), in italics.* +| > *Then include the "Principal authors" list and the "Additional contributors" list (if there are additional contributors) (all in plain text, not italics or bold).* +| > *Link each contributor's name to the person's LinkedIn profile.* +| > *After the name, place a pipe symbol ("|") with spaces, and then enter the person's title.* +| > *Do not include any additional links except the LinkedIn profile URL.* + +*It was originally written by the following contributors:* + +Principal authors: + +.. admonition:: Authors + + `(Author 1 Name) | (Title, such as "Cloud Engineer") `_ + + `(Author 2 Name) | (Title, such as "Cloud Architect") `_ + +| > *Only the primary authors.* +| > *List them alphabetically, by last name.* +| > *Use this format: **Fname Lname**.* +| > *If the article gets rewritten, keep the original authors and add in the new one(s).* + +Other contributors: + +| > *Include contributing (but not **primary**) authors, major editors (not minor edits), and technical reviewers.* +| > *List them alphabetically, by last name. Use this format: **Fname Lname**.* + +.. admonition:: Contributors + + `(Author 1 Name) | (Title, such as "Cloud Engineer") `_ + + `(Author 2 Name) | (Title, such as "Cloud Architect") `_ + + +.. Next steps & Related Resources + +Next Steps +========== + +| > *(Expected, but it could be optional if you don't want the article stops here and doesn't connect with other resources)* +| > *Add site-relative links to Architecture Center related articles but NOT to external or third-party resources* +| > *If there are additional resources like Cloud Topology Designer solution or Github repos, list them first with the aforementioned order* + +.. seealso:: + + `Link1 `_ + + `Link2 `_ + +Resources +========= + +.. Resources + +| > *If there are additional deployable resources like Cloud Topology Designer solution or Github repos, list them first with the aformentioned order* + +.. seealso:: + + `Link1 `_ + + `Link2 `_ + + +.. References + +References +========== + +| > *Add site-relative links to Architecture Center articles* +| > *Add links to external or third-party resources* + +.. seealso:: + + `Link1 `_ + + `Link2 `_ + +| > **REMOVE ALL THE LINES THAT START WITH "| >"**