Skip to content

Tags ​

Et tag er en etiket i formen nøgle=værdi på en ressource, for eksempel env=prod eller cost-center=eu-42. Brug tags til at organisere og filtrere dine ressourcer — efter miljø, ejende team eller omkostningssted.

Denne side dækker:

Tag en ressource ​

Du kan tagge disse ressourcer:

  • VPC'er, subnets og sikkerhedsgrupper
  • VPC-gateways
  • Offentlige IP-adresser
  • Lastbalancere med deres lyttere, pools, poolmedlemmer og sundhedsovervågere
  • Instanser, skaleringsgrupper og startskabeloner
  • Volumener og snapshots af volumener
  • Buckets i objektlagring
  • DNS-zoner og DNS-poster
  • Hemmeligheder
  • Kubernetes-klynger og node pools
  • Databaser, cacher, meddelelsesmæglere, webservere og applikationsgateways, og de ressourcer, du opretter under dem (se nedenfor)

Containerregistre har ingen tags. Snapshots af instanser bruger simple etiketter i stedet for tags i formen nøgle=værdi.

Hver ressourcetype har sine egne regler for tagnøgler og tagværdier, og nogle har et maksimalt antal tags. Portalen kontrollerer dem, mens du skriver, og platformen afviser et tag, der bryder dem.

Portalen. Tilføj tags i afsnittet Tags i en formular til at oprette en ressource. For de fleste ressourcer kan du ændre dem senere fra ressourcens side.

fm CLI. Angiv --tag key=value (kan gentages), når du opretter en ressource (hemmeligheder bruger --tags i stedet; se nedenfor), og brug tags get og tags set til at læse og erstatte taggene senere:

bash
fm network security-group create --name web --vpc <vpc-id> --tag env=prod --tag team=web
fm network security-group tags get <security-group-id>
fm network security-group tags set <security-group-id> --tag env=prod --tag team=payments
fm network security-group tags set <security-group-id> --clear

tags set erstatter hele sættet: et tag, du udelader, fjernes. Angiv --clear for at fjerne alle tags. De samme kommandoer tags get og tags set findes for instanser, volumener, buckets, VPC'er, offentlige IP-adresser, lastbalancere og deres pools og sundhedsovervågere, skaleringsgrupper og startskabeloner. DNS-zoner og hemmeligheder har ingen tags get eller tags set: de får tags, når du opretter dem, og du ændrer dem med update. DNS-zoner bruger --tag (fm dns zone update --tag …, eller --clear-tags for at fjerne alle tags). Hemmeligheder bruger --tags, kommasepareret, både ved oprettelse og opdatering (fm secrets update --tags …, eller --clear-tags). Se DNS og Hemmeligheder.

Nogle ressourcer har også nøgler, som platformen administrerer, for eksempel nøgler, der begynder med frostmoln_. Du kan ikke angive dem. tags get viser dem separat som skrivebeskyttede, og platformen beholder dem, når du erstatter dine tags.

Terraform. Angiv argumentet tags:

hcl
resource "frostmoln_security_group" "web" {
  name   = "web"
  vpc_id = frostmoln_vpc.main.id

  tags = {
    env  = "prod"
    team = "web"
  }
}

Kubernetes-klynger og node pools ​

En administreret Kubernetes-klynge og hver af dens node pools har deres egne tags. Tags er dine metadata til søgning og filtrering, og platformen gemmer dem kun: de er ikke Kubernetes-labels, og de når aldrig klyngen eller dens nodes. En node pools labels — de Kubernetes-labels, der sættes på hver node i poolen — er en separat indstilling, og et tagfilter matcher dem aldrig.

RegelGrænse
Antal tagsHøjst 32 pr. klynge eller node pool, inklusive tenantens standardtags
Nøgle1 til 64 byte bogstaver, cifre og . _ : / -; skal starte og slutte med et bogstav eller et ciffer
VærdiHøjst 256 byte, uden kontroltegn. En værdi må være tom.
Reserverede nøglepræfikser, uanset store/små bogstaverfrostmoln_, frostmoln-

En ændring af tags påvirker aldrig den kørende klynge eller dens nodes.

Den første node pool får en kopi én gang. Den node pool, du opretter sammen med klyngen, kan ikke få sine egne tags i den anmodning, der opretter den. I stedet får den en kopi af klyngens tags — dem, du angiver, plus tenantens standardtags — én gang, når klyngen oprettes. Senere ændringer af klyngens tags når den ikke; rediger poolens egne tags i stedet. En node pool, du tilføjer senere, får ingen kopi af klyngens tags: giv den sine egne tags, når du tilføjer den. Tenantens standardtags tilføjes til den, som til enhver ny ressource.

Portalen. Angiv klyngens tags i afsnittet Tags i formularen til at oprette klyngen. På klyngens fane Oversigt viser kortet Tags dem, og Rediger ændrer dem. På fanen Node pools viser hver pool sine tags og har Rediger tags, og formularen Tilføj pool har sine egne tags. Filtrer klyngelisten efter tags med tagfilteret over listen.

fm CLI.

bash
fm kubernetes cluster create --name prod --vpc <vpc-id> --subnet <subnet-id> \
  --node-flavor k8s.gp1.medium --tag env=prod --tag team=platform
fm kubernetes cluster list --tag env=prod
fm kubernetes cluster tags get <cluster-id>
fm kubernetes cluster tags set <cluster-id> --tag env=prod --tag team=payments
fm kubernetes node-pool create <cluster-id> --flavor k8s.gp1.large --name gpu --tag team=ml
fm kubernetes node-pool list <cluster-id> --tag team=ml
fm kubernetes node-pool tags get <cluster-id> <node-pool-id>
fm kubernetes node-pool tags set <cluster-id> <node-pool-id> --clear

tags set erstatter hele sættet, og --clear fjerner alle tags. På list gentager du --tag for at filtrere: en klynge eller pool vises kun, når den har alle de tags, du angiver.

Terraform. frostmoln_kubernetes_cluster og frostmoln_kubernetes_node_pool tager tags og rapporterer tags_all, ligesom alle ressourcer med tags (se Terraform). En klynges tags styrer ikke tags på dens første node pool, og den pool kan ikke styres som en frostmoln_kubernetes_node_pool: ændr dens tags i portalen eller med fm kubernetes node-pool tags set.

Databaser, cacher, meddelelsesmæglere, webservere og applikationsgateways ​

Disse administrerede tjenester har tags på selve tjenesten og på de ressourcer, du opretter under den:

TjenesteRessourcer, der kan tagges
DatabaserInstanser, læsereplikaer, sikkerhedskopier og parametergrupper
CacherInstanser og sikkerhedskopier
MeddelelsesmæglereInstanser
WebservereInstanser, domæner og udrulninger af indhold
ApplikationsgatewayGateways, lyttere, ruter, backend-pools, backends, certifikater, tilladte veje, regelsæt til firewallen, publicerede versioner af dem og testkørsler til firewallen (dry runs)

De samme regler gælder som for Kubernetes-klynger: højst 32 tags pr. ressource, inklusive tenantens standardtags; nøgler på 1 til 64 byte af bogstaver, cifre og . _ : / -, der begynder og slutter med et bogstav eller et ciffer; værdier på højst 256 byte uden kontroltegn; og de reserverede præfikser frostmoln_ og frostmoln-, uanset store og små bogstaver.

Tags er dine metadata til søgning og filtrering, og platformen gemmer dem kun. En ændring genstarter, omkonfigurerer eller genudruller aldrig noget: på en applikationsgateway er et tag ikke konfiguration, så det kræver ingen anvendelse og ændrer ikke, hvad gatewayen leverer. Hver ressource har sine egne tags:

  • Læsereplikaer får de tags, du giver dem, plus tenantens standardtags. De kopierer ikke den primæres tags, og en senere ændring på den ene side når ikke den anden.
  • En gendannelse opretter en ny instans. Den får de tags, du angiver i gendannelsen, plus tenantens standardtags. Kildeinstansens tags kopieres ikke.
  • Sikkerhedskopier, du opretter, får de tags, du giver dem, plus tenantens standardtags. Planlagte sikkerhedskopier får kun tenantens standardtags. De læses fra en kopi, der kan være op til 30 sekunder gammel, og hvis platformen slet ikke kan læse dem, tages sikkerhedskopien alligevel, uden tags. Brug Anvend på eksisterende ressourcer på siden Standardtags, eller fm tenant default-tags apply, til at tilføje standardtags til sådan en sikkerhedskopi bagefter.
  • En udrulning af indhold på en webserver er en ressource for sig, og tenantens standardtags tilføjes til den. En udrulning kan derfor ikke starte, mens platformen ikke kan læse tenantens standardtags: den afvises med default_tags_unavailable (HTTP 503), og du kan prøve igen om lidt.
  • En tilladt vej på en applikationsgateway deles af alle backends i samme sikkerhedsgruppe, protokol og port. Dens tags sættes, når den oprettes første gang. Hvis du tillader den samme vej igen, genbruges den og beholder sine tags.

På applikationsgatewayens lyttere, ruter, backends, certifikater, tilladte veje, versioner af regelsæt og testkørsler er tags det eneste, du kan ændre, efter at ressourcen er oprettet. En ændring, der angiver et andet felt, afvises med field_not_updatable.

Portalen. Angiv tags i afsnittet Tags i tjenestens oprettelsesformular og i oprettelsesdialogerne for dens ressourcer (en replika, en sikkerhedskopi, en gendannelse, et domæne, en udrulning, en lytter, en rute, en pool, en backend, et certifikat, en tilladt vej eller et regelsæt). Tjenestens side har kortet Tags med Rediger, og hver ressource i dens faner og afsnit viser sine tags og har Rediger tags. Filtrer en tjenestes liste på tags med tagfilteret over listen.

fm CLI. Hver af disse ressourcer undtagen databasernes parametergrupper har tags get og tags set, og deres kommandoer create og list tager --tag. Brug fm v0.97.0 eller nyere. Parametergruppernes tags angives via API'et:

bash
fm database postgres instance create --name orders ... --tag env=prod
fm database postgres instance list --tag env=prod
fm database postgres instance tags set <instance-id> --tag env=prod --tag team=payments
fm database postgres replica tags get <instance-id> <replica-id>
fm database postgres backup tags set <instance-id> <backup-id> --clear
fm cache redis instance tags set <instance-id> --tag env=prod
fm messaging lavinmq instance tags get <instance-id>
fm webserver nginx domain tags set <instance-id> <domain-id> --tag site=shop
fm webserver nginx deploys tags get <instance-id> <deploy-id>
fm appgw tags set <gateway-id> --tag env=prod
fm appgw listener tags set <listener-id> --gateway <gateway-id> --tag team=web

tags set erstatter hele sættet, og --clear fjerner alle tags. Gentag --tag på list for at filtrere: en ressource vises kun, når den har alle de tags, du angiver.

Terraform. Disse ressourcer tager tags og rapporterer tags_all, som alle ressourcer, der kan tagges (se Terraform): frostmoln_postgres_instance, frostmoln_mysql_instance, frostmoln_postgres_read_replica, frostmoln_mysql_read_replica, frostmoln_postgres_backup, frostmoln_mysql_backup, frostmoln_redis_instance, frostmoln_valkey_instance, frostmoln_messaging_instance, frostmoln_apache_instance, frostmoln_nginx_instance, frostmoln_webserver_domain, frostmoln_webserver_deployment, frostmoln_application_gateway, frostmoln_appgw_listener, frostmoln_appgw_route, frostmoln_appgw_backend_pool, frostmoln_appgw_backend, frostmoln_appgw_certificate, frostmoln_appgw_backend_authorization og frostmoln_appgw_waf_policy. Se Providerversioner for, hvilken provider de kræver.

VPC-gateways og DNS-poster ​

En VPC's gateway og hver DNS-post har deres egne tags. De følger de samme regler som Kubernetes-klynger: højst 32 tags pr. ressource, inklusive tenantens standardtags; nøgler på 1 til 64 byte af bogstaver, cifre og . _ : /-, der starter og slutter med et bogstav eller et ciffer; værdier på højst 256 byte uden kontroltegn; og de reserverede præfikser frostmoln_ og frostmoln-, uanset store og små bogstaver.

Tags er dine metadata til søgning og filtrering, og platformen gemmer dem kun. En ændring af en gateways tags berører aldrig dens adresse eller VPC'ens forbindelse og kræver ingen bekræftelse. En DNS-posts tags publiceres aldrig i DNS, og en ændring af kun tags ændrer ikke zonen.

Portalen. På en VPC's side har kortet Gateway en tageditor, når du tilføjer en gateway, og kortet Gatewayens tags viser og redigerer tags på en eksisterende gateway. På en DNS-zones side har postdialogen et afsnit Tags, postlisten viser hver posts tags, og tagfilteret over listen indsnævrer den.

API. Forespørgslerne, der opretter ressourcerne, tager tags. Ved en opdatering (PATCH for en gateway, PUT for en DNS-post) erstatter tags hele sættet, og {} fjerner alle tags. En forespørgsel, der kun indeholder tags, ændrer intet andet. Listen over gateways, listen over DNS-poster og listen over routere tager filteret ?tag=key=value, som kan gentages: en ressource vises kun, når den har alle de tags, du angiver.

Terraform. frostmoln_gateway og frostmoln_dns_record tager tags og rapporterer tags_all som alle ressourcer med tags (se Terraform). Det gør lastbalancerens underressourcer frostmoln_lb_listener og frostmoln_lb_member også. Se Providerversioner for den provider, de kræver.

Eksisterende ressourcer. Når tenantens standardtags tilføjes til de ressourcer, tenanten allerede har (Anvend på eksisterende ressourcer på siden Standardtags, eller fm tenant default-tags apply), er VPC-gateways og DNS-poster med, når platformen har aktiveret de typer. Indtil da får de kun tenantens standardtags, når de oprettes.

Poolmedlemmer i lastbalancere. Et poolmedlem har sine egne tags med de samme regler som lastbalancerens øvrige ressourcer. Angiv dem, når du tilføjer medlemmet (i portalen afsnittet Tags i formularen til at tilføje et medlem); tenantens standardtags tilføjes. Ændr dem senere med Rediger tags på medlemmet, eller i API'et med PUT på medlemmet: tags erstatter hele sættet, og clearTags: true fjerner alle tags (send ikke begge). Poolmedlemmer er med, når tenantens standardtags tilføjes til eksisterende ressourcer.

Routere. En routers tags kan ændres, efter at den er oprettet, via API'et: PUT /v1/tenants/{tenant-id}/routers/{router-id} tager tags, som erstatter hele sættet, eller clearTags: true for at fjerne alle tags.

Tags i adgangspolitikker ​

Betingelser i adgangspolitikker på frn:resourceTag/<k> (se Betingelser) evalueres ikke for de administrerede tjenester: Kubernetes-klynger og node pools, databaser, cacher, meddelelsesmæglere, webservere og applikationsgateways, og ressourcerne under dem. En sådan betingelse regnes som ukendt, og en ukendt betingelse fejler lukket: en allow-regel, der er afgrænset af et ressourcetag, matcher aldrig, og en deny-regel, der er afgrænset af et ressourcetag, gælder altid. Brug ikke tagafgrænsede regler til at give adgang til disse ressourcer.

Tenantens standardtags ​

Tenantens standardtags er et sæt tags, som platformen tilføjer til hver ressource med tags, der oprettes i tenanten — uanset hvem der opretter den: portalen, fm CLI, API'et eller Terraform. Brug dem til tags, som hver ressource i en tenant skal have, for eksempel miljø eller omkostningssted.

Sådan tilføjes standardtags ​

  • De kopieres, når en ressource oprettes. Derefter er de almindelige tags på ressourcen. Du kan ændre eller fjerne dem som ethvert andet tag, og intet knytter dem tilbage til tenantens standardtags.
  • Ressourcens egne tags vinder. Et standardtag tilføjes kun, når anmodningen om at oprette ressourcen ikke selv angiver den nøgle. En nøgle med en tom værdi tæller som angivet.
  • Kun nye ressourcer får dem. En ændring af standardtags ændrer aldrig en ressource, der allerede findes.
  • En ændring tager op til 30 sekunder. En ressource, der oprettes inden for 30 sekunder efter en ændring, kan stadig få det tidligere sæt.
  • De tæller med i ressourcens taggrænse. Hvis standardtags får en ressource til at have flere tags, end den tillader, afvises oprettelsen. Fejlen (tag_limit_exceeded_by_defaults) navngiver standardtaggenes nøgler. Fjern nogle tags fra anmodningen, eller bed en administrator i organisationen om at reducere tenantens standardtags. I formularen til at oprette en ressource viser portalen, hvilke standardtags der tilføjes, og hvor mange af dine egne tags du stadig kan tilføje.
  • En ressource oprettes aldrig uden dem. Hvis platformen ikke kan læse tenantens standardtags, afvises oprettelsen med en fejl, der kan prøves igen (default_tags_unavailable, HTTP 503). Prøv igen om lidt.

Instanser, som en skaleringsgruppe starter, får tenantens standardtags, som de er, når skaleringsgruppen skalerer ud. En nøgle i startskabelonens metadata (Terraform-argumentet metadata) vinder over et standardtag; skabelonens egne tags bliver på skabelonen og kopieres ikke til instanserne. Hvis platformen stadig ikke kan læse standardtags efter nye forsøg, startes instanserne uden dem, så skaleringen ikke stopper.

Standardtags tilføjes ikke til:

  • containerregistre, som ikke har tags (alle andre administrerede tjenester, og de ressourcer, du opretter under dem, får dem);
  • ressourcer, som platformen opretter til en administreret tjeneste;
  • snapshots af instanser, hvis tags er simple etiketter.

Regler for standardtags ​

Et standardtag havner på alle typer ressourcer, så det skal accepteres af dem alle. Derfor er reglerne strengere end for de tags, du angiver på en enkelt ressource.

RegelGrænse
Antal standardtagsHøjst 10 pr. tenant
Nøgle1 til 64 byte med bogstaver (a-z, A-Z), cifre og . _ : -; skal begynde og slutte med et bogstav eller et ciffer. Ingen /, ingen mellemrum.
Værdi0 til 255 byte med bogstaver, cifre, mellemrum og + - . _ : / @ =. Værdien må være tom.
Reserverede nøglepræfikser, uanset store og små bogstaverfrostmoln_, frostmoln-, os_, instance_, nova_
Reserverede nøgler, uanset store og små bogstaverrequest-id, customer-id, project-id, tenant-id, created-at, acl, storage-class, quota-bytes, cors-config

Hvem der kan ændre dem ​

Alle medlemmer af den organisation, der ejer tenanten, kan læse dens standardtags. For at ændre dem kræves rollen administrator eller ejer i den organisation. En API-nøgle skal have adgangen organizations:read for at læse dem og organizations:write for at ændre dem; se API-nøgleadgange.

Hver tenant har ét sæt standardtags, som er tomt, indtil nogen angiver det. Hver ændring erstatter hele sættet, og der er ingen låsning: den seneste skrivning vinder, så administrer sættet fra ét sted.

Angiv standardtags ​

Portalen. Åbn kontomenuen (øverst til højre), og vælg Standardtags. Siden viser standardtags for den tenant, du har valgt. Administratorer og ejere kan tilføje, ændre og fjerne tags og derefter vælge Gem; andre medlemmer ser en skrivebeskyttet liste.

fm CLI. Kommandoerne gælder den aktive tenant; angiv --tenant for en anden.

bash
fm tenant default-tags get
fm tenant default-tags set --tag env=prod --tag cost-center=eu-42
fm tenant default-tags set --tag owner=team-a --merge
fm tenant default-tags clear

set erstatter hele sættet. Med --merge tilføjer den i stedet dine tags til det nuværende sæt. clear beder om bekræftelse; angiv --yes, når fm ikke kører i en terminal.

Terraform. Ressourcen frostmoln_tenant_default_tags administrerer hele sættet for providerens tenant:

hcl
resource "frostmoln_tenant_default_tags" "this" {
  tags = {
    env         = "prod"
    cost-center = "eu-42"
  }
}

Ressourcen ejer sættet. Hver apply skriver præcis tags, så et standardtag, der er tilføjet i portalen, fjernes ved næste apply. Når ressourcen oprettes, erstattes det sæt, tenanten allerede har, og når den destrueres, tømmes sættet. Importér et eksisterende sæt med tenantens id: terraform import frostmoln_tenant_default_tags.this <tenant-id>. Datakilden frostmoln_tenant_default_tags læser sættet uden at administrere det.

Tagfarver ​

En regel for tagfarve viser et tag i en farve, du vælger, i portalen og i fm. Farver angives pr. organisation og gælder i alle dens tenants, så env=prod ser ens ud overalt. De påvirker kun visningen: de ændrer intet ved ressourcerne.

  • En regel matcher en nøgle og én præcis værdi (env=prod) eller en nøgle med alle værdier (env).
  • For et tag nøgle=værdi vinder reglen for præcis den værdi over nøglens regel for alle værdier.
  • En regel for den tomme værdi er en anden regel end reglen for alle værdier: den matcher kun tags, hvis værdi er tom.
  • Nøgler og værdier sammenlignes med forskel på store og små bogstaver.
  • Farven er taggets baggrund, som #RRGGBB. Teksten er sort eller hvid, afhængigt af hvad der giver bedst kontrast. Taggets tekst vises altid, så farven er aldrig det eneste signal.
RegelGrænse
ReglerHøjst 200 pr. organisation og én pr. nøgle og værdi
Nøgle1 til 255 tegn, uden kontrol- eller formateringstegn
VærdiHøjst 256 tegn, uden kontrol- eller formateringstegn; eller ingen, for at matche alle værdier
Reserverede nøglepræfikserfrostmoln_ og frostmoln-, kun med små bogstaver: en nøgle som Frostmoln_Team kan farvelægges
Farve#RRGGBB, for eksempel #1f6feb

Alle medlemmer af organisationen kan læse dens farveregler. For at tilføje, ændre og slette dem kræves rollen administrator eller ejer. En API-nøgle skal have adgangen organizations:read for at læse dem og organizations:write for at ændre dem.

Portalen. Gå til Organisationer, åbn din organisation, og vælg fanen Indstillinger. I kortet Tagfarver vælger du Tilføj farve, angiver tagnøglen, sætter derefter enten flueben i Alle værdier eller angiver en værdi, og vælger en farve med farvevælgeren eller skriver den som hex. Medlemmer, der ikke er administratorer eller ejere, ser listen skrivebeskyttet.

fm CLI. fm organization tag-colors arbejder på den organisation, der ejer din aktive tenant; angiv --organization for en anden. Præcis én af --value og --any-value er påkrævet. Sæt farven i anførselstegn, fordi et # uden anførselstegn starter en kommentar i skallen, eller udelad #.

bash
fm organization tag-colors list
fm organization tag-colors set --key env --value prod --color '#d73a49'
fm organization tag-colors set --key team --any-value --color 1f6feb
fm organization tag-colors delete --key env --value prod

Hvis du kører set igen for samme nøgle og værdi, ændres reglens farve. I en terminal med 24-bit farver udskriver fm også tags i deres farver. Den udskriver tags uden farve med --no-color eller NO_COLOR, og når output ikke går til en terminal.

Terraform. Hver ressource frostmoln_tag_color administrerer én regel. Udelad value for en regel, der gælder alle værdier. Uden organization_id havner reglen i den organisation, der ejer providerens tenant.

hcl
resource "frostmoln_tag_color" "prod" {
  key   = "env"
  value = "prod"
  color = "#d73a49"
}

resource "frostmoln_tag_color" "team" {
  key   = "team"
  color = "#1f6feb"
}

Datakilden frostmoln_tag_colors viser organisationens regler med de id'er, du skal bruge for at importere en regel, der er oprettet i portalen.

Terraform: default_tags og tags_all ​

Blokken default_tags i provideren tilføjer tags til hver ressource med tags, som denne providerkonfiguration administrerer:

hcl
provider "frostmoln" {
  default_tags {
    tags = {
      managed-by = "terraform"
      env        = "prod"
    }
  }
}

resource "frostmoln_vpc" "app" {
  name = "app"
  cidr = "10.1.0.0/16"

  tags = {
    env = "staging" # et ressourcetag vinder over et standardtag med samme nøgle
  }

  # Opret VPC'en, efter at tenantens standardtags er angivet.
  depends_on = [frostmoln_tenant_default_tags.this]
}

output "app_vpc_tags" {
  value = frostmoln_vpc.app.tags_all
}

Hver ressource med tags har to tagattributter:

  • tags indeholder præcis det, som ressourcens konfiguration angiver.
  • tags_all er skrivebeskyttet og indeholder alle tags på ressourcen: providerens default_tags, ressourcens egne tags, tenantens standardtags og alt, der er angivet uden for Terraform. Referér til tags_all, når du har brug for hele sættet.

Nøgler, der er angivet uden for Terraform — i portalen, med fm eller via tenantens standardtags — vises kun i tags_all, og provideren beholder dem ved hver apply. Den fjerner kun de nøgler, den administrerer: dem i en ressources tags og dem, den tilføjede fra default_tags.

Når den samme nøgle kommer fra flere steder, vinder den mest specifikke:

KildeForrang
Ressourcens tagsHøjest
Providerens default_tagsMellem
Tenantens standardtagsLavest

Providerens default_tags og tenantens standardtags adskiller sig i omfang og tidspunkt:

Tenantens standardtagsProviderens default_tags
GælderHver ressource, der oprettes i tenanten, af enhver klientDe ressourcer, én providerkonfiguration administrerer
HvornårÉn gang, når en ressource oprettesVed hver oprettelse og opdatering
Når de ændresPåvirker kun ressourcer, der oprettes bagefterPlanlægger en opdatering på stedet af hver ressource med tags i konfigurationen
Vises i TerraformKun i tags_allI tags_all
ReglerReglerne for standardtagsDe samme regler, kontrolleret når provideren konfigureres

En ændring af default_tags opdaterer hver ressource med tags, som provideren administrerer. Intet erstattes, men gennemgå planens størrelse, før du anvender den på en stor konfiguration.

Snapshots opdateres også på stedet, men platformen afviser en opdatering af et snapshots tags (HTTP 409), mens snapshottet ikke er available (det tages stadig, eller det gendannes; kør apply igen, når det er), og på visse ældre snapshots, der ikke har et ejertag. Administrer et sådant snapshot med en ekstra providerkonfiguration med alias og uden default_tags, og lad dets tags være uændret, eller tag et nyt snapshot, der erstatter det.

Providerversioner ​

For at brugeSkal du have provider
Terraform i en tenant, der har standardtagsv0.62.0 eller nyere
default_tags og tags_allv0.62.0 eller nyere
frostmoln_tag_color og datakilden frostmoln_tag_colorsv0.63.0 eller nyere
frostmoln_tenant_default_tags (ressource og datakilde)v0.65.0 eller nyere
tags på frostmoln_kubernetes_cluster og frostmoln_kubernetes_node_poolv0.81.0 eller nyere
tags på ressourcerne til databaser, cacher, meddelelsesmæglere, webservere og applikationsgatewaysv0.82.0 eller nyere
tags på frostmoln_gateway, frostmoln_dns_record, frostmoln_lb_listener og frostmoln_lb_memberv0.83.0 eller nyere

Når en tenant har standardtags, fejler ældre providerversioner, når de opretter en ressource med tags i den, med "Provider produced inconsistent result after apply": ressourcen kommer tilbage med tags, de ikke forventede. Opgradér provideren, før du angiver standardtags for en tenant, som Terraform administrerer.

En opgradering fra en version uden tags_all ændrer én adfærd: en nøgle, der var angivet uden for konfigurationen, blev tidligere vist som en forskel i tags, som næste apply fjernede. Nu bliver den, i tags_all.

Migrering fra en anden cloud ​

Når du konverterer en konfiguration med fm terraform convert, bliver AWS-providerens default_tags og Google-providerens default_labels til Frostmoln-providerens default_tags. Azure-provideren har ingen standardtags på providerniveau. Intet konverteres til tenantens standardtags, og ingen kildecloud har tagfarver. Se matricerne for AWS, Azure og Google Cloud for detaljer.