diff --git a/docs/modules/zookeeper/pages/getting_started/installation.adoc b/docs/modules/zookeeper/pages/getting_started/installation.adoc index 86b61243..27c91d48 100644 --- a/docs/modules/zookeeper/pages/getting_started/installation.adoc +++ b/docs/modules/zookeeper/pages/getting_started/installation.adoc @@ -6,16 +6,15 @@ On this page you will install the Stackable ZooKeeper Operator. There are 2 ways to run Stackable Operators -1. Using xref:stackablectl::index.adoc[] (recommended) - -2. Using Helm +. Using xref:management:stackablectl:index.adoc[] (recommended) +. Using Helm === stackablectl -stackablectl is the command line tool to interact with Stackable operators and our recommended way to install Operators. -Follow the xref:stackablectl::installation.adoc[installation steps] for your platform. +`stackablectl` is the command line tool to interact with Stackable operators and our recommended way to install +Operators. Follow the xref:management:stackablectl:installation.adoc[installation steps] for your platform. -After you have installed stackablectl, use it to install the ZooKeeper Operator and its dependencies: +After you have installed `stackablectl`, use it to install the ZooKeeper Operator and its dependencies: [source,bash] ---- @@ -27,7 +26,8 @@ The tool will show [source] include::example$getting_started/code/install_output.txt[] -TIP: Consult the xref:stackablectl::quickstart.adoc[] to learn more about how to use stackablectl. For example, you can use the `-k` flag to create a Kubernetes cluster with link:https://kind.sigs.k8s.io/[kind]. +TIP: Consult the xref:management:stackablectl:quickstart.adoc[] to learn more about how to use `stackablectl`. For +example, you can use the `--cluster kind` flag to create a Kubernetes cluster with link:https://kind.sigs.k8s.io/[kind]. === Helm @@ -43,7 +43,8 @@ Then install the Stackable Operators: include::example$getting_started/code/getting_started.sh[tag=helm-install-operators] ---- -Helm will deploy the Operators in a Kubernetes Deployment and apply the CRDs for the ZooKeeper cluster. You are now ready to deploy Apache ZooKeeper in Kubernetes. +Helm will deploy the Operators in a Kubernetes Deployment and apply the CRDs for the ZooKeeper cluster. You are now +ready to deploy Apache ZooKeeper in Kubernetes. == What's next diff --git a/docs/modules/zookeeper/pages/index.adoc b/docs/modules/zookeeper/pages/index.adoc index f6cc658c..b7181ca3 100644 --- a/docs/modules/zookeeper/pages/index.adoc +++ b/docs/modules/zookeeper/pages/index.adoc @@ -5,6 +5,7 @@ This is an operator for Kubernetes that can manage https://zookeeper.apache.org/ WARNING: This operator is part of Stackable Data Platform and only works with images from the https://repo.stackable.tech/#browse/browse:docker:v2%2Fstackable%2Fzookeeper[Stackable] repository + == Supported Versions The Stackable Operator for Apache ZooKeeper currently supports the following versions of ZooKeeper: diff --git a/docs/modules/zookeeper/pages/usage_guide/authentication.adoc b/docs/modules/zookeeper/pages/usage_guide/authentication.adoc index 952231f1..96d92b2c 100644 --- a/docs/modules/zookeeper/pages/usage_guide/authentication.adoc +++ b/docs/modules/zookeeper/pages/usage_guide/authentication.adoc @@ -1,8 +1,12 @@ = Authentication -The communication between nodes (server to server) is encrypted TLS by default. In order to enforce TLS authentication for client-to-server communication, you can set an `AuthenticationClass` reference in the custom resource provided by the xref:commons-operator::index.adoc[Commons Operator]. +The communication between nodes (server to server) is encrypted TLS by default. In order to enforce TLS authentication +for client-to-server communication, you can set an `AuthenticationClass` reference in the custom resource provided by +the xref:commons-operator:index.adoc[Commons Operator]. -Currently it is possible to configure a single form of authentication (of type TLS) by adding one (and only one) entry in the `authentication` sequence as shown in the example below. Additional authentication methods, such as Kerberos, are not yet supported. +Currently it is possible to configure a single form of authentication (of type TLS) by adding one (and only one) entry +in the `authentication` sequence as shown in the example below. Additional authentication methods, such as Kerberos, are +not yet supported. [source,yaml] ---- @@ -15,6 +19,10 @@ include::example$usage_guide/example-cluster-tls-authentication-secret.yaml[] <3> The reference to a `SecretClass`. <4> The `SecretClass` that is referenced by the `AuthenticationClass` in order to provide certificates. -If both `spec.clusterConfig.tls.server.secretClass` and `spec.clusterConfig.authentication.authenticationClass` are set, the authentication class will take precedence over the secret class. The cluster will be encrypted and authenticate only against the authentication class. +If both `spec.clusterConfig.tls.server.secretClass` and `spec.clusterConfig.authentication.authenticationClass` are set, +the authentication class will take precedence over the secret class. The cluster will be encrypted and authenticate only +against the authentication class. -WARNING: Due to a https://issues.apache.org/jira/browse/ZOOKEEPER-4276[bug] in ZooKeeper, the `clientPort` property in combination with `client.portUnification=true` is used instead of the `secureClientPort`. This means that unencrypted and unauthenticated access to the ZooKeeper cluster is still possible. +WARNING: Due to a https://issues.apache.org/jira/browse/ZOOKEEPER-4276[bug] in ZooKeeper, the `clientPort` property in +combination with `client.portUnification=true` is used instead of the `secureClientPort`. This means that unencrypted +and unauthenticated access to the ZooKeeper cluster is still possible. diff --git a/docs/modules/zookeeper/pages/usage_guide/encryption.adoc b/docs/modules/zookeeper/pages/usage_guide/encryption.adoc index 1f0428c7..2268b4dd 100644 --- a/docs/modules/zookeeper/pages/usage_guide/encryption.adoc +++ b/docs/modules/zookeeper/pages/usage_guide/encryption.adoc @@ -1,6 +1,8 @@ = Encryption -The quorum and client communication are encrypted by default via TLS. This requires the xref:secret-operator::index.adoc[Secret Operator] to be present in order to provide certificates. The utilized certificates can be changed in a top-level config. +The quorum and client communication are encrypted by default via TLS. This requires the +xref:secret-operator:index.adoc[Secret Operator] to be present in order to provide certificates. The utilized +certificates can be changed in a top-level config. [source,yaml] ---- @@ -9,7 +11,7 @@ include::example$usage_guide/example-cluster-tls-encryption.yaml[] <1> The `tls.server.secretClass` refers to the client-to-server encryption. Defaults to the `tls` secret. <2> The `tls.quorum.secretClass` refers to the server-to-server quorum encryption. Defaults to the `tls` secret. -The `tls` secret is deployed from the xref:secret-operator::index.adoc[Secret Operator] and looks like this: +The `tls` secret is deployed from the xref:secret-operator:index.adoc[Secret Operator] and looks like this: [source,yaml] ----