Final Project and Hands-On Exercises

Structure of the Final Project

The final project consolidates everything covered in the course into a realistic, end‑to‑end OpenShift workflow. You will:

1. Design and containerize a simple application.
2. Deploy it to OpenShift using best practices.
3. Add a basic CI/CD pipeline.
4. Secure and scale the application.
5. Set up monitoring and perform basic troubleshooting.
6. Produce a short report or demo summarizing what you built and learned.

The project and exercises are intentionally small in scope so you can complete them on a shared or lab cluster, but they mimic patterns used in production environments.

Typical deliverables:

• Application repository (source, Dockerfile or S2I configuration, manifests/pipelines).
• Deployed application running on an OpenShift cluster.
• CI/CD pipeline definition and run history.
• Screenshots or logs showing security, scaling, and monitoring.
• Final report or short presentation.

You are expected to reuse patterns and commands from previous chapters rather than re‑inventing them here.

Recommended Project Scenario

You may adapt the scenario to your interests, but a good baseline is:

• A simple web API (e.g., a guestbook, todo list, or message board) with:
• One backend service (any language you are comfortable with).
• Optional: a small database (e.g., PostgreSQL, MariaDB, or a key‑value store).
• Exposed via a Route and accessible from a browser.
• Built and deployed through OpenShift components only (no external orchestrators).

Functional complexity should be modest; the objective is to practice platform usage, not application design.

Staged Milestones

Milestone 1: Project Setup and Cluster Access

Goals:

• Confirm access to an OpenShift cluster.
• Set up a dedicated project/namespace.
• Prepare a source code repository.

Tasks:

1. Cluster access verification
• Log in using the web console.
• Log in using oc and confirm with:
• oc whoami
• oc status
2. Create your project/namespace
• Choose a unique project name (e.g., fp-<username>).
• Ensure quotas and limits (if enforced in your environment) are understood.
3. Initialize your repository
• Create a Git repository for your project.
• Add a minimal application (e.g., HTTP server returning “Hello from OpenShift”).
• Add initial documentation: README.md describing the planned architecture.

Checkpoint outputs:

• Project created and visible in the web console.
• oc get all shows an empty or nearly empty namespace.
• Application repo exists with initial code and readme.

Milestone 2: Containerization and Basic Deployment

Goals:

• Containerize the application.
• Deploy it to OpenShift using either S2I or a custom container image.
• Expose it externally.

Tasks:

1. Decide build strategy
• Option A: Use Source‑to‑Image (S2I).
• Option B: Use a prebuilt image from a registry and a Dockerfile.
2. Create build definitions
• For S2I: add necessary configuration (e.g., .s2i or language‑specific requirements).
• For custom image: write a Dockerfile that:
• Runs the application.
• Exposes the appropriate port.
• Keeps the image lean (avoid unnecessary packages).
3. Define OpenShift resources
• Create YAML manifests for:
• Deployment or DeploymentConfig.
• Service exposing the application internally.
• Route exposing the service externally.
4. First deployment
• Apply manifests (oc apply -f ...).
• Verify pods, services, and routes.
• Confirm external access from a browser or curl.

Checkpoint outputs:

• Running pod(s) with a healthy status.
• Accessible URL via Route.
• Config tracked in version control (no manual‑only console changes without matching manifests).

Milestone 3: Configuration, Storage, and Secrets

Goals:

• Externalize configuration from the application image.
• Use ConfigMaps and Secrets for environment‑specific data.
• Optionally add persistent storage if your app requires it.

Tasks:

1. Identify configuration
• Decide which values should be configurable (e.g., app mode, log level, API base URL).
• For database‑based apps: DB host, port, name, credentials.
2. Create ConfigMaps
• Define non‑sensitive parameters as ConfigMap.
• Inject them via environment variables or mounted files.
3. Create Secrets
• Define at least one Secret (e.g., DB password, API token, or dummy secret for learning).
• Reference secrets from the deployment without hard‑coding them.
4. Persistent storage (optional but recommended if applicable)
• Create a PersistentVolumeClaim using a StorageClass.
• Mount the PVC into the pod for data that must persist (e.g., database data, uploaded files).

Checkpoint outputs:

• Application functions correctly using values from ConfigMaps and Secrets.
• No sensitive values are committed in plaintext to the repo.
• If used, PVC is bound and mounted correctly.

Milestone 4: CI/CD Integration

Goals:

• Automate build and deployment steps.
• Introduce basic CI/CD flow within OpenShift.

Tasks:

1. Select pipeline approach
• Use OpenShift Pipelines (Tekton) if available, or
• Integrate with an external CI tool that triggers oc/kubectl or image builds.
2. Define pipeline stages
   A minimal pipeline might include:
• build: build the container image or S2I image.
• test: run basic automated tests (unit tests or smoke tests).
• deploy: apply manifests to a test or dev namespace.
• promote (optional): manual approval step to promote to a “prod‑like” namespace.
3. Create pipeline resources
• Pipeline definitions (e.g., Tekton Pipeline and PipelineRun YAML).
• Tasks for each stage (or reuse cluster‑provided tasks where appropriate).
4. Trigger a pipeline run
• Run pipeline on push or manual trigger.
• Confirm new image and deployment updates on success.

Checkpoint outputs:

• A functioning pipeline definition in version control.
• At least one successful pipeline run.
• Documented instructions for triggering and reviewing the pipeline.

Milestone 5: Security, Scaling, and Reliability

Goals:

• Apply basic security hardening.
• Configure application scaling.
• Validate self‑healing behavior.

Tasks:

1. Security basics
• Review and document the Security Context Constraints (SCC) applied to your pods.
• Ensure containers do not require unnecessary privileges.
• Restrict exposed ports and external access to only what’s necessary.
2. RBAC and access
• Create or use existing roles to limit access (e.g., read‑only role for a teammate).
• Demonstrate using role bindings in your project.
3. Scaling
• Configure the number of replicas in your Deployment/DeploymentConfig.
• Set up Horizontal Pod Autoscaler (HPA) if metrics are available.
• Generate load (lightly) and observe scaling behavior.
4. Self‑healing tests
• Manually delete a pod and observe automatic recreation.
• Intentionally deploy a failing version (e.g., bad image tag) and see failure behavior.

Checkpoint outputs:

• Documented security and RBAC configuration.
• Working scaling setup (replication and, if possible, HPA).
• Evidence of self‑healing (events, screenshots, or logs).

Milestone 6: Monitoring, Logging, and Troubleshooting

Goals:

• Use OpenShift’s observability features to understand the application’s behavior.
• Capture common debugging workflows.

Tasks:

1. Metrics and dashboards
• Identify key metrics (e.g., CPU, memory, request count if available).
• Use the web console or CLI to inspect pod and deployment metrics.
2. Logging
• View application logs from pods.
• If cluster logging is configured, explore centralized logs.
• Document how to filter logs for specific containers or errors.
3. Basic troubleshooting runbook
• Simulate a problem (e.g., misconfigured env var, failing readiness probe).
• Use:
• oc describe on pods/services/deployments.
• Events and logs.
• Write a brief checklist for future debugging in similar scenarios.

Checkpoint outputs:

• Screenshots or notes showing metrics and logging views.
• A short troubleshooting guide tailored to your project.

Hands-On Exercise Set

The following exercises are smaller, focused tasks designed to reinforce specific skills. They can be done independently or as steps toward the final project.

Exercise 1: From Local App to OpenShift

Objective: Take a working local application and run it on OpenShift.

Tasks:

• Start with a simple “hello world” HTTP server (any language).
• Containerize it or configure S2I.
• Deploy to an OpenShift project and expose a Route.
• Validate access from your browser.

Focus: End‑to‑end deployment basics.

Exercise 2: Blue‑Green or Rolling Update

Objective: Safely roll out a new version of your application.

Tasks:

• Tag your image or code as v1 and deploy.
• Create a v2 version (change response text or UI).
• Use either:
• Rolling updates with a Deployment, or
• A simple blue‑green approach using two deployments and switching the service/route selector.
• Observe the update and rollback if something goes wrong.

Focus: Safe rollouts and rollbacks.

Exercise 3: ConfigMap and Secret Refactor

Objective: Move configuration out of your container image.

Tasks:

• Identify hard‑coded configuration in your app.
• Replace it with values sourced from:
• ConfigMap for non‑sensitive config.
• Secret for sensitive data.
• Demonstrate changing a config value without redeploying a new image (only updating resources and restarting pods if needed).

Focus: Twelve‑factor style configuration management.

Exercise 4: Implement a Simple HPA

Objective: Practice horizontal scaling based on resource usage.

Tasks:

• Ensure your app responds to HTTP requests (e.g., /health or /).
• Set resource requests/limits for CPU.
• Configure an HPA based on CPU utilization.
• Generate mild load (looped curl or a simple load tool) and see if replicas increase.
• Remove load and observe scale‑down.

Focus: Autoscaling configuration and observation.

Exercise 5: Debugging a Broken Deployment

Objective: Use OpenShift’s tools to diagnose failures.

Tasks:

• Intentionally misconfigure something:
• Wrong image name, or
• Missing environment variable, or
• Invalid port.
• Deploy the broken manifest.
• Use:
• oc get / oc describe
• Pod logs
• Events in the web console
• Identify the root cause and fix it.

Focus: Practical troubleshooting.

Exercise 6: Create a Minimal CI Pipeline

Objective: Automate build and deploy for a simple app.

Tasks:

• Define a pipeline that:
• Checks out code from your repository.
• Builds the container image or triggers S2I.
• Deploys to your project.
• Add a simple test step (e.g., run curl against the service in‑cluster).
• Document how to run the pipeline and where to see results.

Focus: CI/CD basics integrated with OpenShift.

Evaluation and Self-Assessment Guidelines

Evaluation in this final part of the course focuses on:

• Completeness: Did you implement all core components (deployment, configuration, exposure, CI/CD, basic security, scaling, observability)?
• Correctness: Does the application actually run and behave as expected?
• Use of OpenShift features: Are you using platform‑native techniques and resources instead of manual workarounds?
• Reproducibility: Could someone else deploy your project using your repo and documentation?
• Clarity of documentation: Are your decisions and configurations explained at a high level?

For self‑assessment, ask:

• Can I redeploy the entire stack from scratch in a new namespace with only my repo and minimal manual steps?
• Can I introduce a change (code or config), run my pipeline, and see it in production?
• Do I know where to look when something breaks (pods, services, routes, logs, events, metrics)?

Suggested Final Report Outline

As a concluding artifact, prepare a concise report or slide deck covering:

1. Overview
• Application purpose and architecture diagram.
2. Deployment architecture
• Key OpenShift resources (Deployments, Services, Routes, PVCs).
3. Build and CI/CD
• How images are built and deployed.
4. Security and configuration
• Use of RBAC, SCC (at a high level), ConfigMaps, and Secrets.
5. Scaling and resilience
• Replica configuration, HPA (if used), and examples of self‑healing.
6. Monitoring and troubleshooting
• How you observe health and respond to failures.
7. Lessons learned
• Challenges encountered and how you resolved them.
• What you would improve next.

This final chapter is about practicing and integrating everything from the course. Treat it as your personal “mini‑production” environment on OpenShift, where making mistakes safely is part of the learning process.