能否在本地Linux主机/虚拟机中实现OpenShift式Docker工作流？

Absolutely! You can replicate that core OpenShift deployment workflow on a local Linux machine or virtual machine—there are two solid approaches, depending on whether you want an exact OpenShift-like experience or just need to implement the core "Git → Build → Deploy → Access" logic. Let’s break it down:

Option 1: Use Red Hat CodeReady Containers (Exact OpenShift Experience) #

If you want to mirror the OpenShift workflow perfectly (since it’s a local single-node OpenShift cluster), this is your best bet:

• Prerequisites: Your local Linux host/VM needs at least 4 CPU cores and 16GB of RAM (check the official requirements for your CRC version).
• Install & Start CRC:
  1. Download the CRC package for your Linux distro, extract it, and run crc setup to configure dependencies.
  2. Launch the cluster with crc start—this will pull the OpenShift single-node image and set everything up.
• Access the OpenShift Console:
  Run crc console to open the web UI, then log in with the default developer account (get credentials with crc credentials).
• Deploy from GitHub (Just Like Cloud OpenShift):
  1. Click Add → From Git in the console.
  2. Paste your GitHub repository URL, then select the built-in JBoss/Wildfly builder image (OpenShift has these pre-configured).
  3. Follow the prompts to configure deployment settings—OpenShift will automatically clone your repo, build the application image, deploy a Pod, and create a Route (the web URL) pointing to port 8080.
• Test Access:
  Grab the Route URL from the console and open it in your browser—your app should be live, just like in a cloud OpenShift cluster.

Option 2: Simulate the Workflow with Kubernetes (Minikube/Kind) #

If you don’t want to run a full OpenShift cluster, you can use a standard local Kubernetes setup with tools to mimic the build/deploy pipeline:

Step 1: Set Up Local Kubernetes #

• Install Minikube (or Kind for a containerized cluster) and start it with enough resources:

  minikube start --cpus 4 --memory 8192
  minikube addons enable ingress  # To expose your app via a web URL
  minikube addons enable registry  # For local image storage
  

Step 2: Implement the Git → Build → Deploy Pipeline #

You can use Tekton (Kubernetes-native CI/CD) to automate the workflow:

1. Install Tekton Pipelines and the Tekton Dashboard using kubectl with the official manifest resources.
2. Create a PipelineResource pointing to your GitHub repo and the local Minikube registry.
3. Define a Task sequence:
   • Clone the GitHub repository using a pre-built Git clone task.
   • Build a custom image using Buildah (based on the jboss/wildfly base image) and push it to the local registry.
   • Deploy the image as a Kubernetes Deployment and expose it via a Service.
4. Trigger a PipelineRun to kick off the entire workflow.

Step 3: Expose the App via Ingress #

Create an Ingress YAML file (e.g., app-ingress.yaml) to map a web URL to your Service’s 8080 port:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wildfly-app-ingress
spec:
  rules:
  - host: wildfly-app.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: wildfly-app-service
            port:
              number: 8080

Apply it with kubectl apply -f app-ingress.yaml, then add wildfly-app.local to your /etc/hosts file pointing to the Minikube IP (get it with minikube ip). Now you can access your app at http://wildfly-app.local.

Simplified Alternative: Use Skaffold #

For a quicker setup, Skaffold automates the build/deploy loop:

• Install Skaffold, then create a skaffold.yaml file defining your GitHub repo path, image build config, and Kubernetes resources (Deployment, Service, Ingress).
• Run skaffold dev—it will clone your code, build the image, deploy it, and even auto-update when you make code changes.

Wrap-Up #

If you want an exact OpenShift experience, go with CodeReady Containers. If you just need the core workflow, a Kubernetes cluster with Tekton or Skaffold will get you there. Either way, you’ll have a local setup that mirrors the "Git → Build → Deploy → Access" flow you described.

内容的提问来源于stack exchange，提问作者Tlink