Open shift deploy‐config.yaml with route ready : we need oc expose it - unix1998/technical_notes GitHub Wiki

when you use the oc new-app command in OpenShift with a source code repository, it automatically uses the Source-to-Image (S2I) build strategy if the repository contains a supported application type. You do not need to explicitly specify the build strategy in most cases.

Using `oc new-app`

Here's an example of how to use oc new-app with a source code repository:

oc new-app https://github.com/username/repository.git

When you run this command, OpenShift will:

Detect the language and framework used in the source code.
Select an appropriate S2I builder image for the detected language.
Create a build configuration that uses the S2I build strategy.
Build the application using the S2I builder image.
Deploy the resulting image to the OpenShift cluster.

Automatic S2I Detection

OpenShift uses the following steps to automatically detect and apply the S2I strategy:

Source Repository Analysis: OpenShift examines the source repository to determine the type of application. It looks for specific files and directory structures that indicate the programming language and framework (e.g., pom.xml for Maven/Java, requirements.txt for Python, etc.).
Builder Image Selection: Based on the detected application type, OpenShift selects a corresponding S2I builder image. Builder images are pre-configured with the necessary tools and libraries to build and run the application.
S2I Build Process: The S2I builder image clones the source code, compiles it (if necessary), and assembles a new Docker image containing the built application.

Specifying a Build Strategy (Optional)

While oc new-app defaults to using S2I for supported applications, you can explicitly specify a build strategy using the --strategy option if needed. This is rarely required for typical use cases but can be useful in certain scenarios.

For example, to explicitly use the S2I strategy:

oc new-app https://github.com/username/repository.git --strategy=source

Summary

Automatic S2I Usage: oc new-app automatically uses the S2I build strategy if the source repository contains a supported application type.
No Need for Explicit Strategy: In most cases, you do not need to explicitly specify the S2I strategy. OpenShift will detect and apply it automatically.
Optional Strategy Specification: You can specify the build strategy explicitly using the --strategy option if necessary, but this is generally not required.

By using oc new-app with a source code repository, you leverage the power of OpenShift's S2I to simplify the build and deployment process, allowing you to focus on developing your application.

############################################################### oc apply -f deploy-config.yaml , another way to deploy S21

also can use a manifest file, such as deploy-config.yaml, to define the necessary resources for deploying your application using the Source-to-Image (S2I) process in OpenShift. This file can include the source code URL and other configurations. By applying this manifest file with oc apply -f deploy-config.yaml, you can create and manage your OpenShift resources declaratively.

Example of a Deployment Configuration with S2I

Here’s an example deploy-config.yaml that includes a BuildConfig for the S2I process, a DeploymentConfig for deploying the application, and a Service for exposing the application:

apiVersion: v1
kind: BuildConfig
metadata:
  name: myapp-build
spec:
  source:
    type: Git
    git:
      uri: https://github.com/username/repository.git
  strategy:
    type: Source
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: 'nodejs:latest' # Replace with the appropriate builder image
  output:
    to:
      kind: ImageStreamTag
      name: 'myapp:latest'
---
apiVersion: v1
kind: ImageStream
metadata:
  name: myapp
---
apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  name: myapp
spec:
  replicas: 1
  selector:
    app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: 'myapp:latest'
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  ports:
  - port: 8080
    targetPort: 8080

Applying the Configuration

Save the above configuration to a file named deploy-config.yaml.
Run the following command to apply the configuration:

oc apply -f deploy-config.yaml

Key Components

BuildConfig: Defines the build process using S2I. It specifies the source code repository and the builder image.
ImageStream: Manages Docker images within OpenShift. The BuildConfig outputs the built image to an ImageStream.
DeploymentConfig: Manages the deployment of your application. It specifies the image to use, the number of replicas, and other deployment settings.
Service: Exposes your application internally within the OpenShift cluster, allowing other services and pods to communicate with it.

Summary

Using a manifest file like deploy-config.yaml allows you to declaratively define your OpenShift resources, including the S2I build process, deployment configuration, and service exposure. This approach offers several benefits:

Consistency: Ensures that your application is deployed consistently across different environments.
Version Control: Allows you to version control your configuration files, making it easier to track changes and collaborate with others.
Automation: Simplifies automation and CI/CD pipelines by using declarative configuration files.

By using oc apply -f deploy-config.yaml, you can efficiently manage your OpenShift resources and streamline the deployment process.

######################################## To make the application accessible from outside the OpenShift cluster, you can either manually expose the service using oc expose or include a Route definition in your deploy-config.yaml file.

########################################### after run oc apply -f deploy-config.yaml, application will be built, deployed, and have an internal service ready. To make the application accessible from outside the OpenShift cluster, we can either manually expose the service using oc expose or include a Route definition in deploy-config.yaml file.

Adding a Route in `deploy-config.yaml`

To automate the creation of a Route, you can add a Route resource to your deploy-config.yaml file. This will create an external route for your service, making it accessible from outside the cluster. Here’s an updated example:

apiVersion: v1
kind: BuildConfig
metadata:
  name: myapp-build
spec:
  source:
    type: Git
    git:
      uri: https://github.com/username/repository.git
  strategy:
    type: Source
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: 'nodejs:latest' # Replace with the appropriate builder image
  output:
    to:
      kind: ImageStreamTag
      name: 'myapp:latest'
---
apiVersion: v1
kind: ImageStream
metadata:
  name: myapp
---
apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  name: myapp
spec:
  replicas: 1
  selector:
    app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: 'myapp:latest'
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  ports:
  - port: 8080
    targetPort: 8080
---
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: myapp
spec:
  to:
    kind: Service
    name: myapp
  port:
    targetPort: 8080
  tls:
    termination: edge # Optional: Use this if you want to enable TLS termination

Explanation of the Route Configuration

apiVersion: route.openshift.io/v1: Specifies that this resource is a Route.
kind: Route: Defines the resource type as a Route.
metadata.name: The name of the Route.
spec.to: Specifies the service to route traffic to.
- kind: Service: Indicates that the target is a service.
- name: myapp: The name of the service to expose.
spec.port.targetPort: The port on the service to forward traffic to.
spec.tls: Optional. Specifies TLS settings for the route. termination: edge enables TLS termination at the edge.

Applying the Configuration

Save the updated configuration to deploy-config.yaml.
Apply the configuration:

oc apply -f deploy-config.yaml

This will build and deploy your application, create an internal service, and expose the service with an external route.

Verifying the Route

After applying the configuration, you can verify that the route has been created and check its URL:

oc get routes

This will display the route and its external URL, making your application accessible from outside the OpenShift cluster.

Summary

By including a Route definition in your deploy-config.yaml file, you can automate the process of making your application accessible from outside the OpenShift cluster. This eliminates the need to manually expose the service after deployment, streamlining your deployment process.

Open shift deploy‐config.yaml with route ready : we need oc expose it - unix1998/technical_notes GitHub Wiki

Using oc new-app

Automatic S2I Detection

Specifying a Build Strategy (Optional)

Summary

Example of a Deployment Configuration with S2I

Applying the Configuration

Key Components

Summary

Adding a Route in deploy-config.yaml

Explanation of the Route Configuration

Applying the Configuration

Verifying the Route

Summary

Using `oc new-app`

Adding a Route in `deploy-config.yaml`