← Back to Blog

Testing OpenShift in a practical and efficient manner

Blog • December 8, 2024 • 6 min read

Testing OpenShift in a practical and efficient manner involves several steps that cover different aspects of its functionality. Here's a guide to help you set up a test environment and run relevant tests: 1.

Testing OpenShift in a practical and efficient manner

involves several steps that cover different aspects of its functionality. Here's a guide to help you set up a test environment and run relevant tests:

1. Set Up a Testing Environment

  • Local Development Setup:

Minishift/CRC: For a lightweight, local development environment, use Minishift (for older OpenShift versions) or CodeReady Containers (CRC) for OpenShift 4.x. This allows you to run a local instance of OpenShift on your machine.

Great for workstation Setup (2024)

  • OpenShift Developer Sandbox: Red Hat provides a free sandbox environment for testing purposes. It's hosted and managed by Red Hat, and you can use it for a limited time without setting up your infrastructure.

https://developers.redhat.com/developer-sandbox

30 days limit!

After 30 days in the Red Hat Developer Sandbox for OpenShift, your access to the sandbox environment typically expires. Here’s what happens:

  • Termination of the Environment:

  • The sandbox environment will be terminated, meaning all resources, applications, and data you have deployed in that sandbox will be deleted. You will lose access to the cluster and any projects or namespaces you created.

  • No Automatic Renewal:

  • The sandbox does not automatically renew after the 30-day period. If you want to continue using OpenShift, you will need to set up a new sandbox instance (if available) or transition to a different OpenShift environment, such as using Minishift/CRC locally or subscribing to a cloud-based OpenShift service.

  • Data Loss:

  • Any data stored within the sandbox (persistent volumes, application data, configurations, etc.) will be permanently lost once the sandbox is terminated. If you have important data, you should back it up before the 30-day period ends.

  • No Migration:

  • There is no built-in mechanism to migrate applications or data from the sandbox to another OpenShift environment. You will need to manually recreate your setup in another OpenShift cluster if you wish to continue your work.

  • Option to Transition to Paid Services:

  • If you find value in using OpenShift, you might consider transitioning to a paid OpenShift service provided by Red Hat, such as OpenShift Dedicated, OpenShift Online, or deploying OpenShift on your infrastructure. Red Hat offers various subscription options depending on your needs.

  • Re-registration:

  • Sometimes, you might be able to re-register for the sandbox after some time, but this is subject to Red Hat’s policies and availability. However, this would typically start you with a fresh sandbox environment, without any data or configurations from your previous one.

To avoid disruption, it’s advisable to plan ahead and ensure any important work or data is migrated or backed up before the sandbox period ends.

oauth ready

  • Cluster Setup:

If you're testing in a production-like environment, deploy OpenShift on a cloud platform (AWS, Azure, GCP) or on-premises using the OpenShift Installer. This setup is closer to real-world scenarios.

2. Test Cluster Installation

  • Automated Installation: Test the installation process using the OpenShift Installer (for OpenShift 4.x). Check if the cluster components (master nodes, worker nodes, etc.) are correctly set up and running.

  • Infrastructure Validation: Validate that the underlying infrastructure (networking, storage, etc.) integrates seamlessly with OpenShift.

  • HA Setup: If you have multiple masters and workers, test the high availability setup to ensure the cluster can handle node failures.

3. Basic Functionality Testing

  • Cluster Health: Check the overall health of the cluster using oc get nodes and oc get pods -n openshift-console.

  • Pod Deployment: Deploy a simple application (e.g., NGINX) and ensure that the pod is scheduled, started, and accessible.

  • Networking: Test network policies, routing, and service exposure. Deploy an app with a route and access it via the OpenShift web console or curl from the command line.

  • Storage: Attach persistent storage to a pod and verify that the data persists after pod restarts.

4. Security and RBAC Testing

  • User Roles: Create different users with various roles (admin, developer, etc.) and test their access levels.

  • Network Policies: Test network segmentation by applying network policies that restrict communication between namespaces or pods.

  • Pod Security: Ensure that security contexts are enforced correctly, such as running pods with specific user IDs or ensuring privileged access is denied.

5. CI/CD Pipeline Testing

  • Jenkins Pipeline: Set up a Jenkins pipeline in OpenShift, integrate it with a sample application repository, and test the build and deployment process.

  • Tekton Pipelines: If you’re using Tekton, test the creation and execution of pipelines for automated CI/CD workflows.

  • GitOps: Implement GitOps with ArgoCD or OpenShift GitOps, and test the deployment of applications from a Git repository.

6. Scaling and Performance Testing

  • Horizontal Scaling: Test horizontal scaling by increasing the number of pod replicas and ensuring they are distributed across the available nodes.

  • Vertical Scaling: Adjust the resources (CPU, memory) allocated to pods and observe the impact.

  • Load Testing: Use tools like Apache JMeter or Locust to simulate load on your applications running on OpenShift and monitor how the cluster handles the load.

7. Logging and Monitoring

  • Cluster Monitoring: Test the OpenShift monitoring stack (Prometheus, Grafana, Alertmanager) to ensure you have visibility into cluster and application metrics.

  • Logging: Verify that OpenShift’s logging stack (Elasticsearch, Fluentd, Kibana) is correctly capturing logs from the pods and that you can query them.

8. Disaster Recovery

  • Backup and Restore: Test the backup and restore process for your OpenShift cluster, focusing on both application and cluster-level data.

  • Failover: Simulate node failures and test the cluster's failover capabilities to ensure minimal downtime.

9. Upgrade Testing

  • Version Upgrade: Test the process of upgrading OpenShift to a newer version in a test environment before attempting it on production.

  • Component Upgrades: Test upgrading individual components (e.g., OpenShift CLI, operators) to ensure compatibility and stability.

10. End-to-End Application Testing

  • Deploy Complex Applications: Deploy a multi-tier application (e.g., a web app with a database backend) and test the end-to-end flow, including database connectivity, user interactions, and load handling.

  • Test Blue-Green Deployments: Implement and test blue-green or canary deployments to ensure your application updates are seamless and without downtime.

11. Documentation and Knowledge Transfer

  • Create Documentation: Document your testing process, findings, and any issues encountered. This will be valuable for future reference or for sharing with your team.

  • Training: If you’re working in a team, conduct training sessions based on your testing experience to ensure everyone is familiar with OpenShift.

By following these steps, you'll gain a comprehensive understanding of how OpenShift functions in various scenarios and be well-prepared for deploying and managing applications on it in production.

Moving the research to Github >

Practical issue >

https://github.com/rifaterdemsahin/openshift-redhat-sandbox/issues/2

Github should be the development part before we converge into wordpress

Imported from rifaterdemsahin.com · 2024

📚 Related Reading

Ai interviews are a thing 2024-12-31
A Wise Friend Said 2024-12-31
The Importance of Coming Back to Reality: Bridging the Gap Between Vision and Execution 2024-12-31