Skip to main content

Manifest templates

Available

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​

  1. Read the comments: they flag the fields to fill in and those to remove.
  2. Remove what you do not need rather than leaving example values.
  3. Check with sng validate: it names the faulty field.
  4. 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.

See also​