Manifest templates
Deployed and supported. The fields and commands described here are stable within version v1alpha1.
The template catalog provides, for each common kind, a commented example manifest, valid as is. It is the fastest way to start a resource and to discover its fields.
Browse
sng template list
apps Applications
App Application
secrets Secrets
SSMSecret …
iam Identité
IAMApplication Application IAM
IAMRole Rôle IAM
IAMGroup Groupe IAM
cdn CDN
CDNSite Site CDN
registry Registre
RegistryRepository Dépôt du registre
RegistryAccessKey Clé d'accès au registre
sng template search access
Generate
sng template gen App api
créé /home/jane/projet/api.yml (kind=App)
The file contains a complete manifest, with metadata.name: api, reasonable starting
values and comments. The name is also that of the file; -o chooses another
one.
Adapt
- Read the comments: they flag the fields to fill in and those to remove.
- Remove what you do not need rather than leaving example values.
- Check with
sng validate: it names the faulty field. - For each field, the kind reference gives type, bounds and cross-field rules.
What a template never contains: a tenant, a label, an annotation, or a secret value. Do not
add any: metadata only holds name, apply would reject the rest, and a secret value
belongs in a secret.
Kinds without a template
The kinds missing from the catalog (DNSZone, DNSRecord, Monitor, NotificationChannel,
StatusPage) are created:
- from the "Minimal example" on their reference page;
- or with the dedicated command, which writes the manifest for you:
sng dns record set …,sng monitor create … --dry-run; - or from an existing resource:
sng kind get DNSRecord api > dns-api.yml.
Keep your own templates
Nothing prevents you from versioning in your repository a templates/ folder adapted to your
organization (base image, default size, alert channel). sng template gen remains the
source for discovering a new kind or a new field.