Application Platform Folder Anatomy
The application repository's .platform structure is important, because the .platform repository references the environmental overlays when deploying with ArgoCD.
.platform
└── kubernetes
├── base # Base configuration for all environments
│ ├── application_customizations.yaml
│ ├── application.yaml
│ └── kustomization.yaml
├── dev # Development environment
│ ├── application_patch.yaml
│ └── kustomization.yaml
├── stg # Staging environment
│ ├── application_patch.yaml
│ └── kustomization.yaml
└── prd # Production environment
├── application_patch.yaml
└── kustomization.yaml
The application repository's .platform structure is important, because the .platform repository references the environmental overlays when deploying with ArgoCD.
Base Folder Structure
When organizing your Platform Application manifests, it's essential to maintain a clear and consistent folder structure. This helps manage different environments and keeps your configurations organized.
kustomization.yaml
This Kustomization file acts as the orchestrator for the base configuration. It references the application.yaml and application_customizations.yaml files to build the base manifest.
# .platform/kubernetes/base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- application.yaml
configurations:
- application_customizations.yaml
For more information on how to use Kustomize, check out the official Kustomize documentation and the more specific Resources section.
application_customizations.yaml
This file specifies which fields in the PlatformApplication Custom Resource Definition (CRD) Kustomize should update with new image digests or tags, when image settings are used.
# .platform/kubernetes/base/application_customizations.yaml
images:
- path: spec/deployment/image
kind: PlatformApplication
- For a more complete example check out this official example.
- Check out the .platform repository section of the ArgoCD deployments, in the 'Kustomization Details' on Ybor Hosted Images for an example of how this is used.
application.yaml
This is your main PlatformApplication manifest file. It defines the desired state of your application, including deployment specifications, environment variables, secrets, and other configurations.
You are able to use environmental specific patches to modify this base configuration for different environments, so this base version should contain the common configurations shared across all environments.
# .platform/kubernetes/base/application.yaml
apiVersion: meta.p6m.dev/v1alpha1
kind: PlatformApplication
metadata:
name: web-application
spec:
deployment:
replicas: 3
image: my-app
config:
LOG_LEVEL: "info"
secrets:
- name: "api-keys"
Environment Specific Folders
To manage different deployment environments, create separate folders for each environment. Each folder contains a kustomization.yaml file and any necessary patch files to modify the base configuration.
kustomization.yaml
Each environment folder has its own kustomization.yaml file that references the base configuration and applies any environment-specific patches.
# .platform/kubernetes/dev/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../base
patches:
- path: application_patch.yaml
application_patch.yaml
Each environment folder contains an application_patch.yaml file that specifies the changes to be applied to the base PlatformApplication manifest for that specific environment.
# .platform/kubernetes/dev/application_patch.yaml
apiVersion: meta.p6m.dev/v1alpha1
kind: PlatformApplication
metadata:
name: web-application
spec:
config:
LOG_LEVEL: "debug" # Override log level for dev
ENABLE_FEATURE_X: "true" # Enable feature X in dev