> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Templates and Catalog
> Explains OpenShift templates and Catalog for packaging, parameterizing, and instantiating multiresource application stacks via console or CLI.
Hello, and welcome to this lesson on [OpenShift 3 for the Absolute Beginners](https://learn.kodekloud.com/user/courses/openshift-3-for-the-absolute-beginners).
In this lesson we cover OpenShift templates and the Catalog — what they are, how they bundle multiple resources, and how to author and publish your own templates so users can provision complete application stacks in one step.
When you log in to the OpenShift web console, the interface that presents various deployment options is the Catalog.
Earlier lessons created individual BuildConfigs, DeploymentConfigs (or Deployments), Services, and ImageStreams. Catalog items in the console are pre-packaged combinations of those objects that deploy a complete application stack in one go.
Let's inspect the Django + PostgreSQL catalog item as an example. This catalog item packages together multiple OpenShift objects, including:
* A BuildConfig to build the application image.
* An ImageStream to tag and track the resulting image.
* A DeploymentConfig (or Deployment) to run the web application.
* A DeploymentConfig to run PostgreSQL.
* Services to expose the database to the application and the application internally.
* A Route to expose the application to external users.
* A Secret used to store and pass the database credentials securely.
* A set of template parameters shown in the web console wizard (application name, namespace, Git repository, etc.).
All of these components are packaged into a single Template so a user can provision a ready-to-run application stack from the catalog in one step.
You can author your own templates and add them to the Catalog so others can instantiate them via the web console or the CLI.
How a template is created
A Template is a YAML (or JSON) document that aggregates multiple resource manifests and declares parameters that users can supply when instantiating the template. When processed, OpenShift creates each object listed in the template's `objects` array and substitutes parameter values where specified.
Minimum structure of a Template YAML
```yaml theme={null}
apiVersion: v1
kind: Template
metadata:
name: custom-app
objects:
- apiVersion: v1
kind: Secret
# secret details (base64-encoded data or parameter references)
- apiVersion: v1
kind: Service
# service exposing the database
- apiVersion: v1
kind: Service
# service exposing the application internally
- apiVersion: v1
kind: Route
# route exposing the application externally
- apiVersion: v1
kind: BuildConfig
# build configuration for the application image
- apiVersion: v1
kind: DeploymentConfig
# deployment for the application
- apiVersion: v1
kind: DeploymentConfig
# deployment for PostgreSQL
- apiVersion: v1
kind: ImageStream
# image stream to track built images
parameters:
- displayName: "Application Name"
name: "APP_NAME"
description: "Name of the application"
value: "custom-app"
- displayName: "Namespace"
name: "NAMESPACE"
description: "Project/namespace to deploy into"
value: "my-project"
- displayName: "Git Repository"
name: "GIT_REPO"
description: "Git repository URL for source code"
value: "https://github.com/example/repo.git"
```
Key points
* The `objects` array contains the resource manifests that will be created when the template is processed.
* Use template parameters (e.g., `${APP_NAME}`) inside manifests to substitute user-provided values at instantiation time.
* Secrets remain OpenShift Secret objects; templates usually parameterize sensitive values or generate them during instantiation.
* Avoid including runtime-only fields (for example `status`, `metadata.resourceVersion`, `metadata.uid`) when converting exported resources into template objects.
Components commonly packaged in application templates
| Component | Purpose | Example / Notes |
| - | - | - |
| BuildConfig | Builds application images from source | Defines builder image, source `git` URL, and output ImageStream |
| ImageStream | Tracks image tags and triggers | Use to reference the image produced by the BuildConfig |
| DeploymentConfig / Deployment | Runs application pods | Use parameters to set image, replica count, and labels |
| Service | Internal service discovery | Exposes pods to other services in the namespace |
| Route | External HTTP(S) access | Creates public URL for web applications |
| Secret | Store credentials/config | Parameterize values or reference existing secrets |
| Parameters | Provide values at instantiation | e.g., `APP_NAME`, `GIT_REPO`, `DB_PASSWORD` |
Creating and registering a template
1. Save your Template YAML (for example `template-config.yml`).
2. Create the template in your project with:
```bash theme={null}
oc create -f template-config.yml
```
Example output:
```console theme={null}
$ oc create -f template-config.yml
template "custom-app" created
```
If you need to build a template from existing resources, export the resource manifests from your project, then clean them up and replace concrete values with parameters:
```bash theme={null}
oc export service db -o yaml > db-service.yaml
```
When adapting exported manifests:
* Remove runtime fields such as `status`, `metadata.resourceVersion`, `metadata.uid`, and `metadata.creationTimestamp`.
* Replace environment-specific values with template parameters (for example replace `my-app` with `${APP_NAME}`).
* Ensure any `${PARAM_NAME}` used in the template is declared in the `parameters` section.
When parameterizing manifests, use `\${PARAM_NAME}` (e.g., `${APP_NAME}`) inside the YAML so OpenShift will substitute those values at instantiation time. Also avoid including runtime-only fields such as `status` or `resourceVersion` when adding exported resources to a template.
Instantiate a template
Users can instantiate a template from the web console (Catalog wizard) or from the CLI. Example CLI instantiation:
```bash theme={null}
oc new-app --template=custom-app -p APP_NAME=myapp -p GIT_REPO=https://github.com/example/repo.git
```
Or process + create:
```bash theme={null}
oc process -f template-config.yml -p APP_NAME=myapp -p GIT_REPO=https://github.com/example/repo.git | oc create -f -
```
Links and references
* [OpenShift Documentation - Templates](https://docs.openshift.com/)
* [Kubernetes Concepts - Services and Deployments](https://kubernetes.io/docs/concepts/)
* [oc CLI reference](https://docs.openshift.com/container-platform/latest/cli_reference/openshift_cli/getting-started-cli.html)
That’s it for this lesson — you should now understand how Templates and the Catalog let you package, parameterize, and re-use full application stacks in OpenShift.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.