- Documentation
- OpenShift Dedicated
- Images
- Using images
- Source-to-image history bug_report picture_as_pdf
- About
- What's new
- Introduction to OpenShift Dedicated
- Architecture
- Red Hat OpenShift Cluster Manager
- Planning your environment
- Getting started
- Installing, accessing, and deleting OpenShift Dedicated clusters
- Creating a cluster on AWS
- Creating a GCP Private Service Connect enabled private cluster
- Creating a cluster on GCP with Workload Identity Federation
- Creating a cluster on GCP
- Configuring your identity providers
- Revoking privileges and access to an OpenShift Dedicated cluster
- Deleting an OpenShift Dedicated cluster
- Support
- Web console
- CLI tools
- Cluster administration
- Security and compliance
- Authentication and authorization
- Authentication and authorization overview
- Understanding authentication
- Managing user-owned OAuth access tokens
- Configuring identity providers
- Managing administration roles and users
- Using RBAC to define and apply permissions
- Understanding and creating service accounts
- Using service accounts in applications
- Using a service account as an OAuth client
- Scoping tokens
- Using bound service account tokens
- Managing security context constraints
- Understanding and managing pod security admission
- Syncing LDAP groups
- Upgrading
- CI/CD
- Images
- Overview of images
- Overview of the Cluster Samples Operator
- Using the Cluster Samples Operator with an alternate registry
- Creating images
- Managing images
- Managing image streams
- Using image streams with Kubernetes resources
- Triggering updates on image stream changes
- Image configuration resources
- Using templates
- Using Ruby on Rails
- Using images
- Add-on services
- Storage
- Registry
- Operators
- Operators overview
- Understanding Operators
- User tasks
- Administrator tasks
- Developing Operators
- About the Operator SDK
- Installing the Operator SDK CLI
- Go-based Operators
- Ansible-based Operators
- Helm-based Operators
- Defining cluster service versions (CSVs)
- Working with bundle images
- Complying with pod security admission
- Validating Operators using the scorecard
- Validating Operator bundles
- High-availability or single-node cluster detection and support
- Configuring built-in monitoring with Prometheus
- Configuring leader election
- Object pruning utility
- Migrating package manifest projects to bundle format
- Operator SDK CLI reference
- Migrating to Operator SDK v0.1.0
- Networking
- Building applications
- Building applications overview
- Projects
- Creating applications
- Viewing application composition using the Topology view
- Working with Helm charts
- Deployments
- Quotas
- Using config maps with applications
- Monitoring project and application metrics using the Developer perspective
- Monitoring application health
- Editing applications
- Working with quotas
- Pruning objects to reclaim resources
- Idling applications
- Deleting applications
- Using the Red Hat Marketplace
- Nodes
- Overview of nodes
- Working with pods
- Automatically scaling pods with the Custom Metrics Autoscaler Operator
- Release notes
- Custom Metrics Autoscaler Operator overview
- Installing the custom metrics autoscaler
- Understanding the custom metrics autoscaler triggers
- Understanding the custom metrics autoscaler trigger authentications
- Pausing the custom metrics autoscaler
- Gathering audit logs
- Gathering debugging data
- Viewing Operator metrics
- Understanding how to add custom metrics autoscalers
- Removing the Custom Metrics Autoscaler Operator
- Controlling pod placement onto nodes (scheduling)
- About pod placement using the scheduler
- Placing pods relative to other pods using pod affinity and anti-affinity rules
- Controlling pod placement on nodes using node affinity rules
- Placing pods onto overcommited nodes
- Placing pods on specific nodes using node selectors
- Controlling pod placement using pod topology spread constraints
- Using jobs and daemon sets
- Working with nodes
- Working with containers
- Understanding containers
- Using Init Containers to perform tasks before a pod is deployed
- Using volumes to persist container data
- Mapping volumes using projected volumes
- Allowing containers to consume API objects
- Copying files to or from a container
- Executing remote commands in a container
- Using port forwarding to access applications in a container
- Working with clusters
- Observability
- Observability overview
- Monitoring
- Monitoring overview
- Accessing monitoring for user-defined projects
- Configuring the monitoring stack
- Disabling monitoring for user-defined projects
- Enabling alert routing for user-defined projects
- Managing metrics
- Managing alerts
- Reviewing monitoring dashboards
- Accessing third-party monitoring APIs
- Troubleshooting monitoring issues
- Config map reference for the Cluster Monitoring Operator
- Service Mesh
- Service Mesh 2.x
- About OpenShift Service Mesh
- Service Mesh 2.x release notes
- Service Mesh architecture
- Service Mesh deployment models
- Service Mesh and Istio differences
- Preparing to install Service Mesh
- Installing the Operators
- Creating the ServiceMeshControlPlane
- Adding workloads to a service mesh
- Enabling sidecar injection
- Upgrading Service Mesh
- Managing users and profiles
- Security
- Traffic management
- Metrics, logs, and traces
- Performance and scalability
- Deploying to production
- Federation
- Extensions
- 3scale WebAssembly for 2.1
- 3scale Istio adapter for 2.0
- Troubleshooting Service Mesh
- Control plane configuration reference
- Kiali configuration reference
- Jaeger configuration reference
- Uninstalling Service Mesh
- Service Mesh 2.x
- Serverless
Source-to-image
You can use the Red Hat Software Collections images as a foundation for applications that rely on specific runtime environments such as Node.js, Perl, or Python. You can use the Red Hat Java Source-to-Image for OpenShift documentation as a reference for runtime environments that use Java. Special versions of some of these runtime base images are referred to as Source-to-Image (s2i) images. With s2i images, you can insert your code into a base image environment that is ready to run that code.
s2i images include:
-
.NET
-
Java
-
Go
-
Node.js
-
Perl
-
PHP
-
Python
-
Ruby
s2i images are available for you to use directly from the OpenShift Dedicated web console by following procedure:
-
Log in to the OpenShift Dedicated web console using your login credentials. The default view for the OpenShift Dedicated web console is the Administrator perspective.
-
Use the perspective switcher to switch to the Developer perspective.
-
In the +Add view, use the Project drop-down list to select an existing project or create a new project.
-
Click All services in the Developer Catalog tile.
-
Click Builder Images under Type to see the available s2i images.
s2i images are also available though the Cluster Samples Operator.
Source-to-image build process overview
Source-to-image (s2i) produces ready-to-run images by injecting source code into a container that prepares that source code to be run. It performs the following steps:
-
Runs the
FROM <builder image>command -
Copies the source code to a defined location in the builder image
-
Runs the assemble script in the builder image
-
Sets the run script in the builder image as the default command
Buildah then creates the container image.