Deploying an Application

This guide walks you through the two primary ways to deploy a containerized application using Infrastream.

The key difference lies in where your container image comes from:

• Application: Use this when your application's source code is managed by the platform. Infrastream will be responsible for building the container image from a BuildDefinition and then deploying it.
• ExternalApplication: Use this when your container image is already built and stored in a container registry. Infrastream is only responsible for deploying the existing image.

Both workflows require you to define the release lifecycle and environment-specific runtime configuration.

---

Prerequisites

• The Identity of Your OU and Project: You need to know the names of the organization, organizational-unit, and the project where you will be deploying.
• For ExternalApplication: You will need the URI of your pre-built container image.

---

Deploying an External Application

This is the most common and straightforward scenario. It involves creating four related manifests:

1. ReleaseTrack: Defines the approved path to production (e.g., dev -> staging -> prod).
2. ApplicationSet: A logical grouping for one or more applications that are released together.
3. ExternalApplication: Defines your specific application, linking to its pre-built container image.
4. DeploymentConfig: Provides environment-specific settings for your application (e.g., environment variables, scaling).

Step 1: Create the ReleaseTrack Manifest

A ReleaseTrack defines the stages your application must pass through.

• Convention: You might place this in a release-track subdirectory within your OrganizationalUnit folder.
• File: Create a new YAML file (e.g., my-product-releasetrack.yaml).

apiVersion: lowops.manifests.v1
kind: ReleaseTrack
metadata:
  name: my-product-releasetrack
  organizational-unit: your-ou
  organization: your-org
spec:
  releaseStages:
    - environments:
        - development
    - environments:
        - staging
    - environments:
        - production

Step 2: Create the ApplicationSet Manifest

This manifest groups your application with any others that should be released with it.

• Convention: You might place this in an application-set subdirectory.
• File: Create a new YAML file (e.g., my-app-set.yaml).

apiVersion: lowops.manifests.v1
kind: ApplicationSet
metadata:
  name: my-app-set
  release-track: my-product-releasetrack
  organizational-unit: your-ou
  organization: your-org
spec: {} # This manifest is purely for grouping

Step 3: Create the ExternalApplication Manifest

Now, define your application, pointing to your pre-built container image.

• Convention: You might place this in an external-application subdirectory.
• File: Create a new YAML file for your app (e.g., my-new-app.yaml).

apiVersion: lowops.manifests.v1
kind: ExternalApplication
metadata:
  name: my-new-app
  application-set: my-app-set
  release-track: my-product-releasetrack
  organizational-unit: your-ou
  organization: your-org
spec:
  source: my-external-registry # Reference to an ExternalRegistry manifest
  container: default
  project: your-project
  target: CLOUDRUN # Or GKE, or COMPUTE

Step 4: Create the DeploymentConfig Manifest

Finally, provide the environment-specific configuration for your application.

• Convention: You might group DeploymentConfigs by project or environment (e.g., in a deployment-config subdirectory).
• File: Create a YAML file. Crucially, the metadata.name inside this file must match the name of the Application manifest (e.g., my-new-app). The file name itself can be anything.

apiVersion: lowops.manifests.v1
kind: DeploymentConfig
metadata:
  name: my-new-app # MUST match the Application name
  project: your-project
  environment: development
  organizational-unit: your-ou
  organization: your-org
spec:
  version: "1.0.0"
  container:
    env:
      - name: GREETING
        value: "Hello from the Development Environment!"
  scaling:
    min: 1
    max: 2

To learn more about the target field and the benefits of this approach, see the Architectural Overview guide.

Deploying an Internal Application

This scenario is for applications whose source code is managed by the platform. The platform will use a BuildDefinition to build the container image before deploying it.

This process involves five related manifests:

1. GithubRepository: Defines the source code repository for your application.
2. BuildDefinition: Defines how to build your application's container image.
3. ReleaseTrack: Defines the approved path to production.
4. ApplicationSet: A logical grouping for your application.
5. Application: Defines your specific application, linking it to the BuildDefinition.
6. DeploymentConfig: Provides environment-specific settings.

The process for creating ReleaseTrack, ApplicationSet, and DeploymentConfig is identical to the ExternalApplication workflow. The key differences are the creation of the GithubRepository and BuildDefinition, and the use of an Application manifest instead of an ExternalApplication.

An Application manifest's spec does not point to a pre-built image. Instead, it references the BuildDefinition that will produce the image.

# Example Application Manifest (compare to ExternalApplication)
# File: ../application-set/my-app-set/application/my-new-app.yaml
apiVersion: lowops.manifests.v1
kind: Application
metadata:
  name: my-new-app
  application-set: my-app-set
  release-track: my-product-releasetrack
  organizational-unit: your-ou
  organization: your-org
spec:
  # 'source' is the name of the BuildDefinition, not a container image URI.
  source: my-app-build-definition
  container: default
  project: your-project
  target: CLOUDRUN # Or GKE, or COMPUTE

To learn more about the target field and the benefits of this approach, see the Architectural Overview guide.

For a complete walkthrough of this more advanced scenario, please see the specific guides for GithubRepository and BuildDefinition.

Step 5: Commit, Review, and Merge

Commit all your new manifest files in a single pull request. This action proposes the new application and its full configuration to the Infrastream platform.

The system will automatically run a "plan," showing you the exact GCP resources that will be created. Once your pull request is reviewed and approved, merge it. The platform will then automatically deploy your container to the development environment with the settings from your DeploymentConfig.