From 71a90c527d484a8be59e48602b3a74168a70ae4e Mon Sep 17 00:00:00 2001 From: Lars Francke Date: Wed, 8 Apr 2020 14:46:59 +0200 Subject: [PATCH] Update examples and include readme --- README.adoc | 7 +++++ common-example.yaml | 12 +-------- hdfs-example.yml => hdfs-example.yaml | 39 +++++++++++++-------------- 3 files changed, 27 insertions(+), 31 deletions(-) create mode 100644 README.adoc rename hdfs-example.yml => hdfs-example.yaml (55%) diff --git a/README.adoc b/README.adoc new file mode 100644 index 0000000..7ff2b99 --- /dev/null +++ b/README.adoc @@ -0,0 +1,7 @@ += Orchestration System + +This repository contains a few examples on how to declaratively define services in an Orchestration System. The syntax should be compatible to the Kubernetes syntax. + +* link:hdfs-example.yaml[hdfs-example.yaml] +* link:hdfs-crd.yaml[hdfs-crd.yaml] +* link:kafka-example.yaml[kafka-example.yaml] diff --git a/common-example.yaml b/common-example.yaml index 29e65bd..7c65163 100644 --- a/common-example.yaml +++ b/common-example.yaml @@ -33,7 +33,7 @@ spec: --- apiVersion: stable.opencore.com/v1 -kind: ExternalLogStorage # Evtl. wird es ein spezialisierter ElasticsearchLogStorage +kind: ExternalLogStorage # TODO: Do we need an "ElasticsearchExternalLogStorage"? Check with K8S best-practices metadata: name: prod-elk spec: @@ -57,7 +57,6 @@ spec: - prod-eng-policies - prod-hr-policies - --- apiVersion: stable.opencore.com/v1 kind: Node @@ -67,17 +66,8 @@ metadata: hostName: server-01.opencore.io network: 10GBit - --- apiVersion: stable.opencore.com/v1 kind: ExternalKafkaCluster ... name: edge-kafka-unmanaged - - - - - - - -POST /api/v1/stable.opencore.com/v1/HDFS/rebalanceHDFS diff --git a/hdfs-example.yml b/hdfs-example.yaml similarity index 55% rename from hdfs-example.yml rename to hdfs-example.yaml index d3693ce..2e7c720 100644 --- a/hdfs-example.yml +++ b/hdfs-example.yaml @@ -9,15 +9,15 @@ metadata: paidForBy: HR spec: config: - # Globale Konfigurationen hier + # Global configuration for all HDFS things go here configMapRef: - # Globale ConfigMaps hier + # Global ConfigMaps go here - # TODO: Weitere Ranger Properties angeben, gibt es HDFS Properties, die wir bei Ranger injecten müssen? + # TODO: Further Ranger properties. Are there any properties that we need to "inject" into Ranger as well? How'd that work? rangerServiceRef: ... - rangerPolicySetRef: prod-policies # Möglicherweise mehrere erlauben + rangerPolicySetRef: prod-policies # Potentially allow more than one - # Nur bei HA benötigt + # Only needed when HA is enabled zooKeeperRef: ... roleConfig: @@ -32,7 +32,7 @@ spec: configMapRef: - nameNode: # Failover Controller muss hier auch laufen falls HA + nameNode: # This also needs a Failover controller when HA is enabled minNodeCount: 1 maxNodeCount: 3 highAvailable: true @@ -45,9 +45,9 @@ spec: hostName: server-0[1-3].opencore.io jvmOptions: ... config: - dfs.namenode.disks: /foo/01, /foo/02 # TODO: Können kommaseparierte Werte irgendwie strukturierter abgelegt werden? + dfs.namenode.disks: /foo/01, /foo/02 # TODO: Can commaseparated values be provided in a more structured way? dfs.namenode.http.principal: HTTP - configMapRef: # TODO: Brauchen wir hier mehrere? Wenn ja, wie mergen die? Vorschlag: Priorität vorgeben + configMapRef: # TODO: Do we need more than one? How do we deal with priorities/conflicts? name: special-config priority: 1 roleConfig: @@ -59,23 +59,23 @@ spec: - selector: hostName: server-03.opencore.io config: - dfs.datanode.disks:/foo/01,/foo/03 # /foo/02 ist kaputt + dfs.datanode.disks:/foo/01,/foo/03 # /foo/02 is broken ... configMapRef: - secondaryNameNode: # Optional falls HA an ist nicht benötigt + secondaryNameNode: # Optional if HA is not needed ... - journalNode: # TODO: Optional falls nameNodeCount = 1 + journalNode: # TODO: Optional if HA is disabled minNodeCount: 2 maxNodeCount: 3 nodeSelector: env: production type: master config: - dfs.namenode.disks: /foo/01, /foo/02 # TODO: Können kommaseparierte Werte irgendwie strukturierter abgelegt werden? - configMapRef: # TODO: Brauchen wir hier mehrere? Wenn ja, wie mergen die? Vorschlag: Priorität vorgeben + dfs.namenode.disks: /foo/01, /foo/02 + configMapRef: name: special-config priority: 1 @@ -86,18 +86,18 @@ spec: env: production type: master config: - dfs.namenode.disks: /foo/01, /foo/02 # TODO: Können kommaseparierte Werte irgendwie strukturierter abgelegt werden? - configMapRef: # TODO: Brauchen wir hier mehrere? Wenn ja, wie mergen die? Vorschlag: Priorität vorgeben + dfs.namenode.disks: /foo/01, /foo/02 + configMapRef: name: special-config priority: 1 kerberos: enabled: true customKeytabScript: /opt/distro/keytabs.sh - nodeSelector: # Selektiert den Rechner auf dem es läuft + nodeSelector: # Selects the machine where we can find the Keytab Script ... - # TODO: In secrets auslagern + # TODO: Move to Secrets or separate Object? adRef: centalAd adHost: adPassword: @@ -111,12 +111,11 @@ spec: certExtendedKeyUsage: clientAuth, serverAuth certProviderRef: foobar - # Überschreibbar pro Logfiletyp logging: retention: ... rollingInterval: ... defaultExternalLogStorageRef: prod-elk - # TODO: Evtl. auch diese Sachen in eigene Objekte auslagern damit sie wiederverwendbar sind + # TODO: Potentially introduce a new object for this as well to make it reusable nameNodeAuditLog: collect: true externalLogStorageRef: prod-audit-elk @@ -129,4 +128,4 @@ spec: whitelist: ... -# TODO: HttpFS, NFS Gateway als eigener Service oder hier rein? +# TODO: Should HttpFS, NFS Gateway be their own services or part of this one?