Skip to main content

Deploying a Custom HTTPD Application in Minikube: Step-by-Step Guide

Welcome to another hands-on tutorial! Today, we’re deploying a custom HTTPD application in a Kubernetes cluster using Minikube. Follow along as we walk through each step, from setting up prerequisites to deploying, scaling, and cleaning up our application. By the end, you’ll have an in-depth understanding of deploying Docker applications in Minikube with Kubernetes.

Prerequisites: Setting Up Your Environment

Before we start, make sure you have these tools installed and configured on your local machine:

  • Docker (to build and run container images)
  • kubectl (to manage Kubernetes clusters)
  • Minikube (to run a Kubernetes cluster locally)

To verify each tool, use the following commands:

docker --version
kubectl version --client
minikube version

Step 1: Run Docker Without Sudo

For convenience, we’ll configure Docker to run without sudo:


sudo usermod -aG docker $USER
newgrp docker

After running these commands, log out and back in or use newgrp docker to apply the changes.

Step 2: Start the Minikube Cluster and Set Docker Environment to Minikube

Next, configure your Docker environment to use Minikube’s Docker daemon:

minikube start --driver=docker
eval $(minikube docker-env)       ### to unset/reset docker use commad "eval $(minikube docker-env -u)"


This allows Minikube to directly access any images you build.

Step 3: Create a Custom HTTPD Docker Image

1. Set Up Project Directory and HTML File

First, create a project directory and an HTML file that will serve as our homepage.


mkdir my-httpd
cd my-httpd
echo "<h1>Welcome to My Custom HTTPD Page!</h1>" > index.html

2. Create a Dockerfile

Now, create a Dockerfile with the following content to build our HTTPD image:


FROM httpd:latest
COPY index.html /usr/local/apache2/htdocs/

This Dockerfile uses the HTTPD base image and copies our custom index.html file into the appropriate directory.

3. Build the Docker Image

Build and tag the custom Docker image:


docker build -t my-custom-httpd .

Step 4: Create a Kubernetes Deployment

Create a deployment.yaml file with the following configuration to deploy your application:


apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-httpd-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-httpd
  template:
    metadata:
      labels:
        app: my-httpd
    spec:
      containers:
      - name: my-httpd
        image: my-custom-httpd
        imagePullPolicy: Never

This file defines a deployment with one replica of our custom HTTPD application.

Apply the Deployment


kubectl apply -f deployment.yaml

Step 5: Expose the Deployment

To access the application externally, expose the deployment using a NodePort service:


kubectl expose deployment my-httpd-deployment --type=NodePort --port=80

Step 6: Get the Minikube Service URL

Retrieve the service URL to access your HTTPD application:


minikube service my-httpd-deployment --url

Open this URL in your browser to view the application.

Step 7: Check Pod Status

Verify that the pods are running as expected:


kubectl get pods

Step 8: Scaling the Deployment

Scale Up

Increase the number of replicas to 5:


kubectl scale deployment my-httpd-deployment --replicas=5
kubectl get pods

Scale Down

Decrease replicas to 2:


kubectl scale deployment my-httpd-deployment --replicas=2

Step 9: Simulate Pod Failure

Delete a pod to see Kubernetes automatically recreate it:


kubectl delete pod <pod-name>
kubectl get pods

Replace <pod-name> with the name of a running pod to observe Kubernetes’ self-healing capabilities.

Step 10: Clean Up

Finally, delete the service and deployment:


kubectl delete service my-httpd-deployment
kubectl delete deployment my-httpd-deployment

Conclusion

Congratulations! You've successfully deployed, scaled, and managed a custom HTTPD application in Minikube. This exercise provided a solid foundation in deploying applications on Kubernetes locally with Minikube.

If you found this tutorial helpful, stay tuned for more Kubernetes guides! Don’t forget to like, share, and subscribe for updates.

Labels:

Comments

Post a Comment

Popular posts from this blog

Example of Maven project that interacts with a MySQL database and includes testing

Example Maven project that interacts with a MySQL database and includes testing To install Java, MySQL, Maven, and write a Java program to fetch table data, execute, and create a JAR file using Maven on Ubuntu, you can follow these steps: Step 1: Install Java You can install Java using the following commands: sudo apt update sudo apt install default-jre sudo apt install default-jdk Verify the installation by running: java -version Step 2: Install MySQL You can install MySQL using the following commands: sudo apt update sudo apt install mysql-server During the installation, you'll be prompted to set a root password for MySQL or you can set password at latter stage using following steps.  sudo mysql ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password'; exit Step 3: Install Maven You can install Maven using the following commands: sudo apt update sudo apt install maven Verify the installation by running: mvn -version Step 4: Create
Post a Comment
Read more

Maven Create and Build Artifacts

In Maven, you can create and build artifacts using the package phase of the build lifecycle. The package phase is responsible for taking the compiled code and other project resources and packaging them into a distributable format, such as a JAR (Java Archive), WAR (Web Application Archive), or other custom formats. Here are the steps to create and build artifacts using Maven: Configure the Build Output: In your project's pom.xml file, you need to configure the output of the build. This includes specifying the type of artifact you want to create (e.g., JAR, WAR) and any additional resources to include. You do this in the <build> section of your pom.xml: <build>     <finalName>my-artifact</finalName> <!-- Name of the artifact without the extension -->     <plugins>         <!-- Plugin configurations for creating the artifact -->         <!-- For example, maven-jar-plugin or maven-war-plugin -->     </plugins> </build> Depend
Post a Comment
Read more

Maven Repositories (local, central, global)

Maven relies on repositories to manage dependencies, plugins, and other artifacts required for a project. There are typically three types of repositories in Maven: local, central, and remote/global repositories. Local Repository: Location: The local repository is located on your local development machine. By default, it's in the .m2 directory within your user home directory (e.g., C:\Users\<username>\.m2\repository on Windows or /Users/<username>/.m2/repository on macOS and Linux). Purpose: The local repository is used to store artifacts (JARs, POMs, and other files) that your machine has downloaded or built during previous Maven builds. These artifacts are specific to your local development environment. Benefits: Using a local repository improves build performance since it caches dependencies locally, reducing the need to download them repeatedly. It also ensures reproducibility by maintaining a local copy of dependencies. Central Repository: Location: The central repo
Post a Comment
Read more