From e095287bfd592bf53d580b448c505063c57d9833 Mon Sep 17 00:00:00 2001 From: jyunmitch Date: Wed, 29 Mar 2023 15:51:57 -0500 Subject: [PATCH] ENDOC-660 make same edits for redis on 7.1 --- vuepress/docs/.vuepress/v71.js | 6 +- .../tutorials/consume/high-avail-tutorial.md | 4 +- vuepress/docs/v7.1/docs/README.md | 2 +- ...lustering.md => high-avail-application.md} | 30 ++- .../docs/v7.1/docs/reference/entandoapp-cr.md | 4 +- vuepress/docs/v7.1/tutorials/README.md | 2 +- .../consume/caching-and-clustering.md | 184 ------------------ .../tutorials/consume/high-avail-tutorial.md | 136 +++++++++++++ .../v7.1/tutorials/devops/manage-nginx.md | 6 +- 9 files changed, 160 insertions(+), 214 deletions(-) rename vuepress/docs/v7.1/docs/consume/{caching-and-clustering.md => high-avail-application.md} (63%) delete mode 100644 vuepress/docs/v7.1/tutorials/consume/caching-and-clustering.md create mode 100644 vuepress/docs/v7.1/tutorials/consume/high-avail-tutorial.md diff --git a/vuepress/docs/.vuepress/v71.js b/vuepress/docs/.vuepress/v71.js index 7e2977be8b..7f5057a619 100644 --- a/vuepress/docs/.vuepress/v71.js +++ b/vuepress/docs/.vuepress/v71.js @@ -145,8 +145,8 @@ module.exports = { path: path + 'consume/accessibility.md' }, { - title: 'Caching and Clustering', - path: path + 'consume/caching-and-clustering.md' + title: 'High Availability', + path: path + 'consume/high-avail-application.md' }, { title: 'Cluster Resource Limits', @@ -426,7 +426,7 @@ module.exports = { { title: 'Consume an Application', children: [ - path + 'consume/caching-and-clustering.md', + path + 'consume/high-avail-tutorial.md', path + 'consume/external-id-management.md', path + 'consume/entando-operator.md', path + 'consume/invoking-api.md' diff --git a/vuepress/docs/next/tutorials/consume/high-avail-tutorial.md b/vuepress/docs/next/tutorials/consume/high-avail-tutorial.md index 83e66a0de0..b45b11d480 100644 --- a/vuepress/docs/next/tutorials/consume/high-avail-tutorial.md +++ b/vuepress/docs/next/tutorials/consume/high-avail-tutorial.md @@ -52,8 +52,8 @@ kubectl get ingress -n YOUR-NAMESPACE ``` kubectl delete YOUR-POD-NAME -n YOUR-NAMESPACE ``` - - There are other ways to do this. You could also shell into the server-container and manually kill the running app process with `kill -9 357`. - - If you want to test at the hardware level, you could manually terminate a node in your cluster (ensuring that the pods are scheduled to different nodes). + - There are other ways to do this. You could also shell into the server-container and manually kill the running app process with `kill -9 357`. + - If you want to test at the hardware level, you could manually terminate a node in your cluster (ensuring that the pods are scheduled to different nodes). 6. In your private/incognito browser window, open the URL to your `entando-de-app`. 7. Check that the application continues to render while the pod you deleted is no longer present. 8. Wait for Kubernetes to restore your deleted pod. diff --git a/vuepress/docs/v7.1/docs/README.md b/vuepress/docs/v7.1/docs/README.md index c6f78748e0..1e1937b2fb 100644 --- a/vuepress/docs/v7.1/docs/README.md +++ b/vuepress/docs/v7.1/docs/README.md @@ -48,7 +48,7 @@ In the development lifecycle of an application, Consume is the execution stage w | Documentation | Tutorials | | :------------ | :-------- | -| [Accessibility](./consume/accessibility.md) | [Caching and Clustering](../tutorials/consume/caching-and-clustering.md) | +| [Accessibility](./consume/accessibility.md) | [High Availability on Entando](../tutorials/consume/high-avail-tutorial.md) | | [Entando Operator](./consume/operator-intro.md) | [Add API Claim](../tutorials/create/ms/add-api-claim.md) | | [Entando APIs](./consume/entando-apis.md) | [Invoke Entando core APIs](../tutorials/consume/invoking-api.md) | | [Entando Identity Management System](./consume/identity-management.md) | [External Identity Management System](../tutorials/consume/external-id-management.md) | diff --git a/vuepress/docs/v7.1/docs/consume/caching-and-clustering.md b/vuepress/docs/v7.1/docs/consume/high-avail-application.md similarity index 63% rename from vuepress/docs/v7.1/docs/consume/caching-and-clustering.md rename to vuepress/docs/v7.1/docs/consume/high-avail-application.md index 94a738e012..b9a4ad77b7 100644 --- a/vuepress/docs/v7.1/docs/consume/caching-and-clustering.md +++ b/vuepress/docs/v7.1/docs/consume/high-avail-application.md @@ -1,25 +1,16 @@ -# Caching and Clustering in an Entando Application +--- +sidebarDepth: 2 +--- +# High Availability in an Entando Application ## App Engine Clustering and High Availability -The Entando App Engine can be deployed as a clustered set of instances using the clustering and replication ability of Kubernetes. It is backed by a shared cache with two default choices for implementation. +The Entando App Engine can be deployed as a clustered set of instances using the clustering and replication ability of Kubernetes. It is backed by a shared cache with two default choices for implementation. -This guide demonstrates how to configure and test a clustered instance of the Entando App Engine. +This document examines the issues to consider when creating highly availailable clusters of the Entando App Engine. -Microservices clustering that adds functionality to an Entando Application is different from clustering used by the Entando App Engine. Microservices rely on a custom clustering configuration and setup based on implementation and selections made during their creation. Refer to documentation addressing [clustered microservices and caching implementation](../../tutorials/consume/caching-and-clustering.md) for configuration and deployment details. +Microservices clustering that adds functionality to an Entando Application is different from clustering used by the Entando App Engine. Microservices rely on a custom clustering configuration and setup based on implementation and selections made during their creation. Refer to documentation addressing [clustered microservices and caching implementation](../../tutorials/consume/high-avail-tutorial.md) for configuration and deployment details. -## Storage Requirements for Clustered Entando Applications - -To scale an Entando Application across multiple nodes, a storage class that supports a `ReadWriteMany` access policy must be created. There are a number of ways to accomplish this, inclusive of dedicated storage providers such as GlusterFS. Cloud Kubernetes providers also offer clustered storage options specific to their implementation, such as Google Cloud File in GKE or Azure Files in AKS. - -Two different storage classes can be used for clustered vs. non-clustered storage if the default class doesn't support `ReadWriteMany`. Add the following properties to the operator ConfigMap: - -``` -entando.k8s.operator.default.clustered.storage.class: "[clustered RWX storage class]" -entando.k8s.operator.default.non.clustered.storage.class: "[RWO storage class]" -``` - -Set both values to the storage class appropriate to the configuration. ::: tip To scale an Entando Application without the use of clustered storage assumes all instances are scheduled to a single node and requires a `ReadWriteOnce (RWO)` policy in conjunction with taints on other nodes. Understanding the pros and cons of same-node scheduling is critical for node resource optimization and application recovery should the instance become unreachable. Note that if the node quits or is shut down, the application will be unavailable until Kubernetes reschedules the pods to an alternate node. @@ -29,7 +20,7 @@ To scale an Entando Application without the use of clustered storage assumes all ### Data Management -At startup, the Entando App Engine will load all database data into the shared cache. Applicable content will be served from the cache when a page is rendered or content is fetched. In the event of a write to the cache, both the cache and database will be updated. +At startup, the Entando App Engine loads all database data into the shared cache. Applicable content is served from the cache when a page is rendered or content is fetched. In the event of a write to the cache, both the cache and database will be updated. The following objects are cached in the base implementation of the Entando App Engine: @@ -48,13 +39,13 @@ The following objects are cached in the base implementation of the Entando App E ## Redis Implementation -An Entando Application can be configured to utilize an external [Redis](https://redis.io/) cache. In a Redis implementation of an Entando Application, the cache is deployed independently of the Entando App Engine and the Entando App Engine is configured to connect to the deployed instance. +An Entando Application can be configured to utilize an external [Redis](https://redis.io/) cache. In a Redis implementation of an Entando Application, the cache is deployed independently of the Entando App Engine and the App Engine is configured to connect to the deployed instance. ![Redis Caching](./img/redis-caching.png) The Redis cache is not deployed by the Entando Operator and must be managed by a DevOps team member or Kubernetes cluster administrator. -[Check out the Caching and Clustering tutorial](../../tutorials/consume/caching-and-clustering.md#configuring-and-deploying-with-redis) for more information and step-by-step instructions to use a Redis cache in an Entando Application. +Check out the [High Availability on Entando tutorial](../../tutorials/consume/high-avail-tutorial.md#configuring-and-deploying-with-redis) for more information and step-by-step instructions to use a Redis cache in an Entando Application. ## Performance @@ -69,3 +60,4 @@ It is generally recommended that performance testing on clustered instances corr ### Cache Management When a new replica of an Entando Application joins a cluster of applications, the cache is replicated to that node. If the cache is relatively large or the network is slow, this may add to the total startup time of the new instance. Existing instances will continue to function. + diff --git a/vuepress/docs/v7.1/docs/reference/entandoapp-cr.md b/vuepress/docs/v7.1/docs/reference/entandoapp-cr.md index 396038a10e..23d7809af1 100644 --- a/vuepress/docs/v7.1/docs/reference/entandoapp-cr.md +++ b/vuepress/docs/v7.1/docs/reference/entandoapp-cr.md @@ -5,7 +5,7 @@ sidebarDepth: 2 # EntandoApp Custom Resource The EntandoApp CR is the deployment of a Docker image that hosts the Entando and Java-based web application. Server-side components include the Entando App Engine, Entando Component Manager, Entando App Builder, and the user-facing application. -Entando offers standard WildFly or EAP images for the definition, but typically customers provide their own CRD. +Entando offers standard WildFly, EAP, or Tomcat images for the definition, but typically, customers provide their own CRD ## Example EntandoApp @@ -38,6 +38,6 @@ spec: |`spec.replicas`| The number of replicas to be made available on the deployment.| |`spec.resourceRequirements`| The minimum and maximum [resource allocation](../reference/custom-resources.md#general-resourcerequirements-specifications) for the Entando App Engine container.| |`spec.serviceAccountToUse`| The Kubernetes service account in the namespace of the EntandoApp used for the pods hosting the EntandoApps. The default is 'default'.| -|`spec.standardServerImage`| Either a `wildfly` or `eap` image. This property and the `spec.customServerImage` are mutually exclusive. Refer to the [Docker image section](https://github.com/entando-k8s/entando-k8s-controller-coordinator/blob/master/charts/entando-k8s-controller-coordinator/README.md#how-it-resolves-docker-images) to determine how the Docker registry and versions are calculated.| +|`spec.standardServerImage`| Either a `wildfly`,`eap`, or `tomcat` image. This property and the `spec.customServerImage` are mutually exclusive. Refer to the [Docker image section](https://github.com/entando-k8s/entando-k8s-controller-coordinator/blob/master/charts/entando-k8s-controller-coordinator/README.md#how-it-resolves-docker-images) to see how the Docker registry and versions are calculated.| |`spec.storageClass` | Name of the StorageClass to use for PersistentVolumeClaims created for this EntandoApp. For more information, go to [Kubernetes explanation of storage classes](https://kubernetes.io/docs/concepts/storage/storage-classes/).| |`spec.tlsSecretName` | The name of a standard Kubernetes [TLS Secret](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls) that will be used for the resulting ingress. This is only required if the [globally configured TLS Secret](https://github.com/entando-k8s/entando-k8s-controller-coordinator/blob/master/charts/entando-k8s-controller-coordinator/README.md#tls) for the operator is absent. | \ No newline at end of file diff --git a/vuepress/docs/v7.1/tutorials/README.md b/vuepress/docs/v7.1/tutorials/README.md index 36a4e0114e..c872281bfe 100644 --- a/vuepress/docs/v7.1/tutorials/README.md +++ b/vuepress/docs/v7.1/tutorials/README.md @@ -46,7 +46,7 @@ table th:nth-of-type(3) { | [Set Up Entando on Amazon Elastic Kubernetes Service (EKS)](./getting-started/eks-install.md) | [Connect Your Entando Application to an External Database](./devops/external-db.md) | [Install Bundle Microservices from a Private Registry](./curate/ms-private-images.md) | [Set Up Entando on Azure Kubernetes Service (AKS)](./getting-started/azure-install.md) | [Install the Standard Demo Application](./solution/install-standard-demo.md) | [Add a GitHub Actions CI Workflow](./create/pb/github-actions-workflow.md) | [Set Up Entando on Google Kubernetes Engine (GKE)](./getting-started/gke-install.md) | [Configure the Entando Operator](./consume/entando-operator.md) | [Manage NGINX](./devops/manage-nginx.md) -| [Set Up Entando on Red Hat OpenShift](./getting-started/openshift-install.md) | | [Set Up Plugin Profiles](./devops/plugin-configuration.md) | +| [Set Up Entando on Red Hat OpenShift](./getting-started/openshift-install.md) | [High Availability on Entando](./consume/high-avail-tutorial.md) | [Set Up Plugin Profiles](./devops/plugin-configuration.md) | | [Entando Installation on Kubernetes](./getting-started/kubernetes-install.md) | | | | [Entando CLI Reference](../docs/getting-started/entando-cli.md) | | diff --git a/vuepress/docs/v7.1/tutorials/consume/caching-and-clustering.md b/vuepress/docs/v7.1/tutorials/consume/caching-and-clustering.md deleted file mode 100644 index a47b937c99..0000000000 --- a/vuepress/docs/v7.1/tutorials/consume/caching-and-clustering.md +++ /dev/null @@ -1,184 +0,0 @@ -# Caching and Clustering - -The tutorial below covers the basic steps to setup and validate a clustered instance of the Entando App Engine. - -::: tip NOTE -When building your deployment architecture, it is important to review your goals, hardware, networking and application-specific setup. You must also optimize App Engine deployment for your environment. The configurations and tests below do not address every type of application or deployment, but they can be used as building blocks to create a deployment architecture that works for your application. -::: - -## Storage Requirements for Clustered Entando Apps - -In order to scale an Entando Application across multiple nodes, you must provide a storage class that supports -a `ReadWriteMany` access policy. There are many ways to accomplish this, including using dedicated storage providers like GlusterFS. Cloud Kubernetes providers also offer clustered storage options specific to their implementation, such as Google Cloud File in GKE or Azure Files in AKS. - - -You can use two different storage classes for your clustered vs. non-clustered storage if your default class doesn't support `ReadWriteMany`. Add the following properties to your ConfigMap for the operator: - -``` -entando.k8s.operator.default.clustered.storage.class: [your clustered RWX storage class] -entando.k8s.operator.default.non.clustered.storage.class: [your RWO storage class] -``` - -Set both values to the appropriate storage class for your configuration. - -::: tip -A `ReadWriteOnce (RWO)` policy that ensures instances are all scheduled to the same node will scale an Entando Application without clustered storage and is accomplished via taints on other nodes. Be aware of the pros and cons of scheduling instances to the same node so you can maximize utilization of node resources and recover from an unreachable application instance. If the node terminates or is shutdown, your application will be down while Kubernetes reschedules the pods to a different node. -::: - -## Clustering - -This tutorial reviews setting up a clustered Entando App Engine in `entando-de-app`. The goal is to deploy a clustered instance of the App Engine and verify the high availability and scalable deployment of the application. - -### Prerequisites -- An existing deployment of an Entando App or the ability to create one. - - If you haven't created a deployment or don't have a YAML file for an Entando deployment, follow the [Quickstart instructions](../../../docs/getting-started/). -- The Entando deployment must use a Relational Database Management System (RDBMS) to organize data in a table structure. Clustered instances will not work correctly with in-memory databases. -- Sticky sessions are recommended when enabling a clustered Entando Application. For example, see [Manage NGINX](../devops/manage-nginx.md) for related affinity settings. - -### Creating a Clustered App Instance -1. Create an Entando deployment via the operator config file or edit an existing deployment YAML file. -2. Scale your Entando server application: - -``` bash -kubectl scale deployment quickstart-deployment -n entando --replicas=2 -``` - - -3. Run `kubectl get pods -n YOUR-NAMESPACE` to view the pods in your deployment. -4. You should have two `quickstart-deployment` pods in your namespace. - -5. Look in the logs of the `quickstart-deployment` in either pod to see logging information related to different instances joining the cluster and balancing the data between the instances. See the screenshot for an example. Your actual logs will vary. - - -![Clustered Logs](./img/clustered-logs.png) - -### Validating Clustered Instances -This is an advanced exercise and not required or recommended for most deployment scenarios. The steps below validate that the clustered instances are working in your environment and that you have created a high availability deployment. - -1. Complete the [creating a clustered instance tutorial](#creating-a-clustered-app-instance) above or have an existing clustered Entando App instance available for testing. -2. Get the URL for your `entando-de-app` with `kubectl get ingress -n YOUR-NAMESPACE`. -3. Open the URL in the browser of your choice and ensure that the application is working. -4. Open a new browser window in incognito or private browsing mode to ensure that no data is cached and you're receiving a copy of the running application. **Do not navigate to the app.** -5. Delete one of the server deployment pods in your clustered instance with `kubectl delete YOUR-POD-NAME -n YOUR-NAMESPACE`. - - There are other ways to do this. You could also shell into the server-container and manually kill the running app process with `kill -9 357`. - - If you want to test at the hardware level, you could manually terminate a node in your cluster (ensuring that the pods are scheduled to different nodes). -6. In your private/incognito browser window, open the URL to your `entando-de-app`. -7. Check that the application continues to render while the pod you deleted is no longer present. -8. Wait for Kubernetes to restore your deleted pod. -9. Check that the application continues to render after the pod is restored. - -### Caching Validation -Validating the shared cache can be done in a similar process to the clustered instance validation. The high level steps are: - -1. Deploy a clustered instance (see [creating a clustered instance tutorial](#creating-a-clustered-app-instance)). -2. Create data with the App Builder (pages, page templates, content etc.), using the external route for the application. -3. Refer to the logs to note which instance processed the request. -4. Terminate that instance. -5. Fetch the recently created data and verify that the data are returned. - - -## Configuring and Deploying with Redis - -In this section, an Entando App Engine instance is deployed using Redis as a cache for data served by the App Engine. For more information on the cache configuration for the App Engine, see the [Caching and Clustering documentation](../../docs/consume/caching-and-clustering.md). - -### Deploy Redis to Kubernetes - -1. Create the Redis deployment and expose the endpoints: - -```sh -kubectl create deployment redis --image=redis:6 -``` -```sh - -kubectl expose deployment redis --port=6379 --target-port=6379 -n YOUR-NAMESPACE - -``` - -2. Install the Redis CLI for your environment per . -3. Get the IP for your Redis deployment: -```sh -kubectl get service -n YOUR-NAMESPACE -``` -4. Validate your deployment: - -```sh -redis-cli -h 10.43.99.198 -p 6379 ping -``` - * Should respond PONG. - - -```sh -redis-cli -h 10.43.99.198 -p 6379 incr mycounter -``` - * Should increment each time. - -### Configure implementation - -1. Use git to clone the `entando-de-app` repository: - -```sh -git clone https://github.com/entando/entando-de-app -``` - -2. Fetch the tags, checkout the release tag and create a branch for your customization: - -```sh -git fetch --tags -``` -```sh -git checkout tags/v7.1.0 -b YOUR-7.1.0-redis -``` - -3. Open the pom.xml file of the `entando-de-app`. - -4. Add the Redis caching plugin to the pom.xml: - -``` - - org.entando.entando.plugins - entando-plugin-jpredis - war - -``` - -5. Save the pom. -6. Build and push a custom image for the `entando-de-app` with [Building a Docker Image Tutorial](../devops/build-core-image.md). -7. Download the operator configuration deployment file: - -curl -L -C - -O https://raw.githubusercontent.com/entando/entando-releases/{{$site.themeConfig.entando.fixpack.v71}}/dist/ge-1-1-6/namespace-scoped-deployment/orig/namespace-resources.yaml > namespace-resources.yaml - -8. Update the image for `entando-de-app-wildfly` in the `namespace-resources.yaml` file to point to your custom `entando-de-app` image with Redis. The line to change is in the ConfigMap named `entando-docker-image-info`. - -9. Deploy your edited file with `kubectl`. - -```sh -kubectl apply -f namespace-resources.yaml -``` - -10. Download the `entando-app.yaml` template - -curl -sLO "https://raw.githubusercontent.com/entando/entando-releases/{{$site.themeConfig.entando.fixpack.v71}}/dist/ge-1-1-6/samples/entando-app.yaml" - -11. Add environment variables to the `EntandoApp` definition to match your Redis instance. The variables to create are REDIS_ACTIVE, REDIS_ADDRESS (e.g. _redis://localhost:6379_), and REDIS_PASSWORD. - ->NOTE: This example uses a Secret for the `REDIS_PASSWORD`, which is recommended. You can also hardcode the password in the YAML for testing purposes, but the use of clear text passwords in deployment files is not recommended. **Create and use a Secret for the password as a best practice.** - -```yaml -data: - environmentVariables: - - name: REDIS_ACTIVE - value: "true" - - name: REDIS_ADDRESS - value: YOUR-REDIS-URL - - name: REDIS_PASSWORD - valueFrom: - secretKeyRef: - key: password - name: YOUR-REDIS-SECRET-NAME - optional: false -``` - -12. Deploy your file -```sh -kubectl apply -f entando-app.yaml -``` diff --git a/vuepress/docs/v7.1/tutorials/consume/high-avail-tutorial.md b/vuepress/docs/v7.1/tutorials/consume/high-avail-tutorial.md new file mode 100644 index 0000000000..b45b11d480 --- /dev/null +++ b/vuepress/docs/v7.1/tutorials/consume/high-avail-tutorial.md @@ -0,0 +1,136 @@ +--- +sidebarDepth: 2 +--- + +# High Availability on Entando + +To build applications on Entando for high availability (HA), it is best practice to examine your goals, hardware, networking, and application-specific setup as well as optimize the App Engine deployment for that environment. The configurations and tests below can be used as building blocks to create a deployment architecture that promotes HA for your application in most situations. They include steps to set up and validate a clustered instance of the Entando App Engine, along with the configuration for Redis to support that instance. + +::: tip +To scale an Entando Application without the use of clustered storage assumes all instances are scheduled to a single node and requires a ReadWriteOnce (RWO) policy in conjunction with taints on other nodes. Be aware of the pros and cons of scheduling instances to the same node so you can maximize utilization of node resources and recover from an unreachable application instance. If the node terminates or is shutdown, your application will be down while Kubernetes reschedules the pods to a different node. +::: + +## Clustering +This section describes how to set up a clustered Entando App Engine in the `entando-de-app` image. The goal is to deploy a clustered instance of the App Engine and verify the scalable deployment and HA of the application. + +### Prerequisites +- An existing deployment of an Entando App or the ability to create one. + - If you haven't created a deployment or don't have a YAML file for an Entando deployment, follow the [Quickstart instructions](../../../docs/getting-started/). +- The Entando deployment must use a Relational Database Management System (RDBMS) to organize data in a table structure. Clustered instances will not work correctly with in-memory databases. +- Sticky sessions are recommended when enabling a clustered Entando Application. For example, see [Manage NGINX](../devops/manage-nginx.md) for related affinity settings. + +### Creating a Clustered App Instance +1. Create an Entando deployment via the operator config file or edit an existing deployment YAML file. +2. Scale your Entando server application: + +``` bash +kubectl scale deployment quickstart-deployment -n entando --replicas=2 +``` + +3. To view the pods in your deployment: +``` +`kubectl get pods -n YOUR-NAMESPACE` +``` +4. You should have two `quickstart-deployment` pods in your namespace. + +5. Look in the logs of the `quickstart-deployment` in either pod to see logging information related to different instances joining the cluster and balancing the data between the instances. See the screenshot for an example. Your actual logs will vary. + + +![Clustered Logs](./img/clustered-logs.png) + +### Validating Clustered Instances +This is an advanced exercise and not required or recommended for most deployment scenarios. The steps below validate that the clustered instances are working in your environment and that you have created a high availability deployment. + +1. Complete the [creating a clustered instance tutorial](#creating-a-clustered-app-instance) above or have an existing clustered Entando App instance available for testing. +2. Retrieve the URL for your `entando-de-app`: +``` +kubectl get ingress -n YOUR-NAMESPACE +``` +3. Open the URL in a browser and ensure that the application is working. +4. Open a new browser window in incognito or private browsing mode to ensure that no data is cached and you're receiving a copy of the running application. **Do not navigate to the app.** +5. Delete one of the server deployment pods in your clustered instance: +``` +kubectl delete YOUR-POD-NAME -n YOUR-NAMESPACE +``` + - There are other ways to do this. You could also shell into the server-container and manually kill the running app process with `kill -9 357`. + - If you want to test at the hardware level, you could manually terminate a node in your cluster (ensuring that the pods are scheduled to different nodes). +6. In your private/incognito browser window, open the URL to your `entando-de-app`. +7. Check that the application continues to render while the pod you deleted is no longer present. +8. Wait for Kubernetes to restore your deleted pod. +9. Check that the application continues to render after the pod is restored. + +### Caching Validation +Validating the shared cache can be done in a process similar to the clustered instance validation. The high-level steps are: + +1. Deploy a clustered instance (see [creating a clustered instance tutorial](#creating-a-clustered-app-instance)). +2. Create data with the App Builder (pages, page templates, content etc.), using the external route for the application. +3. Refer to the logs to note which instance processed the request. +4. Terminate that instance. +5. Fetch the recently created data and verify that the data are returned. + + +## Configuring and Deploying with Redis + +In this section, an Entando App Engine instance is deployed using Redis as a cache for data served by the App Engine. For more information on the cache configuration for the App Engine, see [high availability in an Entando Application](../../docs/consume/high-avail-application.md). + +### Deploy Redis to Kubernetes + +1. Create the Redis deployment and expose the endpoints: + +```sh +kubectl create deployment redis --image=redis:6 +``` +```sh +kubectl expose deployment redis --port=6379 --target-port=6379 -n YOUR-NAMESPACE +``` +2. Install the Redis CLI for your environment per . +3. Get the IP for your Redis deployment: +```sh +kubectl get service -n YOUR-NAMESPACE +``` +4. Validate your deployment: + +```sh +redis-cli -h 10.43.99.198 -p 6379 ping +``` + * Should respond PONG. + + +```sh +redis-cli -h 10.43.99.198 -p 6379 incr mycounter +``` + * Should increment each time. + + +## Configure the Implementation + +1. Download the `entando-app.yaml` template: + +curl -sLO "https://raw.githubusercontent.com/entando/entando-releases/{{$site.themeConfig.entando.fixpack.v71}}/dist/ge-1-1-6/samples/entando-app.yaml" + +2. Add these environment variables to the `EntandoApp` YAML to match your Redis instance. The variables to create are `REDIS_ACTIVE`, `REDIS_SESSION_ACTIVE`, `REDIS_ADDRESS` (e.g. _redis://localhost:6379_), and `REDIS_PASSWORD`. +```yaml +data: + environmentVariables: + - name: REDIS_ACTIVE + value: "true" + - name: REDIS_ADDRESS + value: YOUR-REDIS-URL + - name: REDIS_SESSION_ACTIVE + value: "true" + - name: REDIS_PASSWORD + valueFrom: + secretKeyRef: + key: password + name: YOUR-REDIS-SECRET-NAME + optional: false +``` +Both REDIS_ACTIVE and REDIS_SESSION_ACTIVE need to be set to "true" to enable the storage of HTTP sessions. If only REDIS_ACTIVE is set to "true", Redis is used just for the cache. + +>NOTE: This example uses a Secret for the `REDIS_PASSWORD`, which is recommended. You can also hardcode the password in the YAML for testing purposes, but the use of clear text passwords in deployment files is not recommended. **Create and use a Secret for the password as a best practice.** + +3. Deploy your file +```sh +kubectl apply -f entando-app.yaml +``` +You now have a high availability cluster of Entando with Redis implementation. \ No newline at end of file diff --git a/vuepress/docs/v7.1/tutorials/devops/manage-nginx.md b/vuepress/docs/v7.1/tutorials/devops/manage-nginx.md index ba86175afd..94588169bc 100644 --- a/vuepress/docs/v7.1/tutorials/devops/manage-nginx.md +++ b/vuepress/docs/v7.1/tutorials/devops/manage-nginx.md @@ -94,11 +94,13 @@ nginx.ingress.kubernetes.io/proxy-buffer-size: 64k # for the Keycloak auth-token nginx.ingress.kubernetes.io/proxy-read-timeout: "600" # to increase the timeout (in seconds) when uploading large files ``` -Sticky sessions may be useful for `entando-de-app` deployments with multiple replicas. If you [set up clustering](../consume/caching-and-clustering.md#clustering), the following options will enable sticky sessions in NGINX: +Sticky sessions may be useful for `entando-de-app` deployments with multiple replicas. If you [set up clustering](../consume/high-avail-tutorial.md#clustering), the following options enable sticky sessions in NGINX: ``` nginx.ingress.kubernetes.io/affinity: cookie -nginx.ingress.kubernetes.io/affinity-mode: balanced +nginx.ingress.kubernetes.io/affinity-mode: persistent +nginx.ingress.kubernetes.io/session-cookie-name: ROUTE +nginx.ingress.kubernetes.io/session-cookie-secure: "true" ``` ## Add the `cert-manager` for TLS Support