This repository demonstrates and showcases the solutions for a series of exercises for Info-Sec/DevSecOps/DevOps. It includes hands-on assessments that demonstrate containerization technologies (Docker- to be specific), setting up health checks, and troubleshooting issues that are related to web servers and Nginx Ingress configurations. It outlines my problem-solving approach and technical expertise in both Information Security, DevSecOps, DevOps, and the best practice, hence strengthening the security of the application delivery and infrastructure management. The scope of this task is focused on - Information Security (Info-Sec), DevSecOps, and DevOps.
The main goal of this exercise was to set up a simple web server inside a Docker container, running on port 8002. I chose Nginx as the web server for this project due to its lightweight and efficient nature.
- Creating the Dockerfile: I started by creating a
Dockerfileto configure the web server. The Dockerfile uses the official Nginx image, and it exposes the application on port8002. As demonstrated in Configuration# Nginx image in the Docker Hub FROM nginx:latest # Nginx configuration COPY nginx/nginx.conf /etc/nginx/nginx.conf # Exposing the port 8002 EXPOSE 8002 # Health Check HEALTHCHECK --interval=30s --timeout=5s --retries=3 \ CMD curl -f http://localhost:8002/ || exit 1 # default command to run Nginx CMD ["nginx", "-g", "daemon off;"] ```
- Building and Running the Container:
After writing the Dockerfile, I built the Docker image using the following command:
As demonstrated in Runninng
And ran the container:
docker build -t terra-simple-nginx-server .docker run -d -p 8002:80 terra-simple-nginx-server
The web server was live and accessible at http://localhost:8002. As shown in the Screenshort
A health check is important as it ensures that the container is up and running perfectly; as expected. To achieve this, I configured a health check in the Dockerfile that pings the root path of the web server every 30 seconds to ensure it is alive.
HEALTHCHECK --interval=30s --timeout=10s --retries=3 \
CMD curl --silent --fail http://localhost:8002/ || exit 1As shown in the screenshort Incase the web server does not respond successfully within the configured param, then Docker will consider the container "UNHEALTHY."
If I encounter issues with Docker health checks, I would take to troubleshoot the problem by:
- Checking the Logs:
First, I would check the container logs to gather any clues about errors or misconfigurations that might be affecting the health check. For example, I ran the following command for my container:docker logs 350df94ecfdc
The logs showed the server returning the expected **"Hey! This is hello from Terra Software Company. Welcome to your Nginx server" **message, which confirmed the web server was functioning correctly.
-
Examine the Health Check Status:
docker inspect --format='{{json .State.Health}}' 350df94ecfdc ---
When I executed the command, it showed that it is in healthy As shown in the screenshort ; hence confirming the container was in good health.
-
Teting in web server directly:
I access the container directly and test the web server inside using curl. This helps in fixing network issues.
-
Increasing the Timeout & Retry Configuration::
I would change the health params to fix the issue. For example; instead of 5 seconds in the timeout onfiguration, I would consider extending it to about 10 Seconds.
Health checks can fail because of misconfigurations or maybe because of network issues. In my case, the Docker health check was successful. Incase Docker fails, i would have considered:
-
Inspecting the Health Checks: The first thing I would do is utilize the docker inspect command to check the status and configuration of the container. This command provides detailed information about the container, including its health check status. This will give me insights into why the health check is failing, such as whether the server isn’t responding in time, or if it’s returning an error code. This gives me room to confirm whether the issue lies in the web server configuration, networking, or health check parameters themselves. I would utilize
docker inspectto get finer details about the health status. -
Checking the Web Server Logs: Once I have an idea of what might be going wrong, I would proceed to inspect the logs of the web server. Logs are very important because they contain error messages or warnings that can highlight what’s failing; and where specifically. If I’m using Nginx, I would use commands like docker logs and or access the container’s file system to navigate to log directories. For instance, with Nginx, I would check the error logs typically found in /var/log/nginx/error.log to identify issues such as misconfigurations, missing files, or other problems that might prevent the server from responding properly to the health check request.
-
Fine tuning the the Health Check Params: Health checks can sometimes fail if they are configured with too strict or too short parameters. For instance, if the --timeout param is set too low (e.g., 1 second), the health check may fail if the server needs a bit more time to respond, especially under load. In such cases, I would adjust these params. I might increase the --timeout value to 10 seconds, giving the server more time to respond. Additionally, I would adjust the --interval (the time between checks) and --retries (how many times Docker tries before marking the container as unhealthy) to more appropriate values. For example, increasing the --interval to 15 seconds might give the server enough breathing room between health checks, reducing false positives.
-
Rebuilding the Container: After fine-tuning the params or fixing any issues with the server logs, I would rebuild the Docker container to apply the changes. Rebuilding the container ensures that all the changes I made, whether to the Dockerfile, server configuration, or health check parameters, are properly implemented. I would use the docker build command to rebuild the image and then rerun the container with docker run. Once the container is running, I would retest the health checks to ensure that they pass. If the container’s health checks are now successful, I would know that the issue has been resolved.
In this scenario, this is how I would approach the troubleshooting:
-
Checking the Ingress Controller: First, I would verify that the Ingress Controller itself is operational, as it manages routing to the exposed service. Using kubectl get pods -n, I would check that the controller is up and running without errors. If there are issues here, I’d restart the controller and examine its logs to understand any potential setup issues.
-
Inspecting the Ingress Resource: Next, I’d review the Ingress resource configuration to ensure that it’s correctly linked to the intended service and has the correct hostname or IP address. Using kubectl describe ingress, I would confirm that all paths and host details are set up as expected, as any misalignment here could lead to accessibility issues. I would keenly verify the ingress Resource; to ensure that it is properly correctly with the correct service and host details.
-
DNS checking: I would then check DNS settings to confirm that they accurately point to the Ingress Controller’s IP. I’d validate DNS by performing commands such as dig or nslookup to ensure that the domain resolves to the correct IP since any misconfigured DNS records limits external access.
-
Firewall Rules: Next, I would inspect firewall rules or cloud security groups to ensure that ports 80 (HTTP) and 443 (HTTPS) are open and directed to the Ingress Controller. Many cloud providers have security settings that can unintentionally block external traffic, so I would confirm these ports are allowed.
-
Nginx Logs: Finally, I would review the Nginx logs (kubectl logs -n command) to identify any routing or configuration errors that may be affecting access. Logs often reveal issues like misrouted traffic or configuration warnings, which can guide any final adjustments.
- Docker: To build and run the terra-simple-nginx-server application.
- Nginx: Utilized as the web server to serve the content.
- Curl: For testing service health and availability.
- Yaml & Dockerfiles: For configuration management.
To get started with this project, you'll need:
- Docker installed on your local machine or VM.
- Access to a terminal to run the commands and build the containers.
I'm a Developer/Cybersecurity/DevSecOps/DevOps professional passionate about building secure, scalable, and efficient applications. I focus on bridging the gap between development and security to create seamless solutions that are both effective and safe.
If you want to connect or have any questions about this repository or the exercises, feel free to reach out!
- Email: Email Me
- LinkedIn: Tim Murkomen
License: This project is Licensed under a Custom License by Tim Murkomen - Here is the Link Custom Licence