Bitnami's Apache Helm chart makes it easy to deploy a scalable Apache server cluster on Kubernetes. With this chart, website administrators can quickly set up a horizontally scalable, fault-tolerant and reliable environment for static Web applications or websites. Bitnami's Apache Helm chart also follows current best practices for security and scalability, thereby ensuring that your Apache cluster is ready for immediate production use.
Bitnami's Apache Helm chart offers maximum flexibility, as it supports three different approaches for static content deployment. Web applications or websites can be deployed directly from Git source code repositories, from shared volumes or from Kubernetes ConfigMaps. This tutorial walks you through each of these approaches.
Assumptions and prerequisites
This guide makes the following assumptions:
- You have a multi-node Kubernetes cluster running with Helm installed.
- You have the kubectl command line (kubectl CLI) installed and configured to work with your cluster.
- You have a static website or application that can be served with Apache.
Approach 1: Deploy from a Git repository
The quickest and easiest way to deploy a static website or application on Kubernetes with Bitnami's Apache Helm chart is to clone the website or application's Git repository. Enable this Helm chart feature with the cloneHtdocsFromGit.enabled parameter, and pass the source Git repository URL and repository branch to the Helm chart using the cloneHtdocsFromGit.repository and cloneHtdocsFromGit.branch deployment parameters respectively.
Here's an example. Replace the GIT-REPOSITORY-URL and GIT-REPOSITORY-BRANCH placeholders with the source Git repository's HTTP(S) URL and branch respectively.
helm repo add bitnami https://charts.bitnami.com/bitnami helm install apache bitnami/apache --set service.type=LoadBalancer --set cloneHtdocsFromGit.enabled=true --set cloneHtdocsFromGit.repository=GIT-REPOSITORY-URL --set cloneHtdocsFromGit.branch=GIT-REPOSITORY-BRANCH
The Helm chart deploys Apache, cloning the content of the Git repository branch to the Apache server's document root.
Approach 2: Deploy using a shared volume
When the static content to be served cannot be made available through a Git repository, it's also possible to deploy it used a shared Kubernetes PersistentVolumeClaim (PVC). Under this approach, it is first necessary to create a PVC and copy the required files into it. Once the PVC contains the static content, the Bitnami Apache Helm chart can be deployed and configured to read the static content from the PVC via its htdocsPVC parameter.
Begin by installing the NFS Server Provisioner. The easiest way to get this running on any platform is with the stable Helm chart. Use the command below, remembering to adjust the storage size to reflect your cluster's settings:
helm repo add stable https://charts.helm.sh/stable helm install nfs stable/nfs-server-provisioner \ --set persistence.enabled=true,persistence.size=5Gi
Create a Kubernetes manifest file named apache-pvc.yml to configure an NFS-backed PVC and a pod that uses it, as below:
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: apache-data-pvc spec: accessModes: - ReadWriteMany resources: requests: storage: 2Gi storageClassName: nfs apiVersion: v1 kind: Pod metadata: name: apache-data-pod spec: volumes: - name: apache-data-pv persistentVolumeClaim: claimName: apache-data-pvc containers: - name: inspector image: bitnami/minideb command: - sleep - infinity volumeMounts: - mountPath: "/data" name: apache-data-pv
Apply the manifest to the Kubernetes cluster:
kubectl apply -f apache-pvc.yml
This will create a pod named apache-data-pod with an attached PVC named apache-data-pvc. The PVC will be mounted at the /data mount point of the pod.
Copy the static application or website to the PVC using the mount point. For example, if the static content is in the /myapp directory of the kubectl host, use the command below:
kubectl cp /myapp/* apache-data-pod:/data/
Verify that the data exists in the PVC, by connecting to the pod command-line shell and inspecting the /data directory:
kubectl exec -it apache-data-pod -- ls -al /data
The command output should display a directory listing containing the static content
Delete the pod, as it is not longer required:
kubectl delete pod apache-data-pod
Deploy the Bitnami Apache Helm chart with the htdocsPVC parameter:
helm repo add bitnami https://charts.bitnami.com/bitnami helm install apache bitnami/apache --set service.type=LoadBalancer --set htdocsPVC=apache-data-pvc
The Helm chart deploys Apache on the cluster, copying the content of the PVC to the Apache server's document root.
Approach 3: Deploy using a ConfigMap
The Bitnami Apache Helm chart can also be used to deploy static content from a Kubernetes ConfigMap. However, as Kubernetes ConfigMaps do not support large amounts of data, this option should only be used for quick tests or for very small websites.
Under this approach, it is first necessary to create a Kubernetes ConfigMap and copy the required files into it. Once the ConfigMap contains the static content, the Bitnami Apache Helm chart can be deployed with the htdocsConfigMap parameter referencing the ConfigMap holding the static content.
Create a ConfigMap containing the required file(s). Replace the FILEX parameters with file names, adding more as needed.
kubectl create configmap required-files --from-file=FILE1 --from-file=FILE2
Deploy the Bitnami Apache Helm chart with the htdocsConfigMap parameter:
helm repo add bitnami https://charts.bitnami.com/bitnami helm install apache bitnami/apache --set service.type=LoadBalancer --set htdocsConfigMap=required-files
The Helm chart deploys Apache on the cluster and the static content from the ConfigMap becomes available at the Apache server's document root.
Use the httpdConfConfigMap parameter to deploy Apache with a custom httpd.conf configuration file. This parameter can be used with all the approaches described in this article. See a complete list of available chart parameters.
To learn more about the topics discussed in this article, use the links below: