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:
- tags på en ressource, herunder Kubernetes-klynger og node pools og databaser, cacher, meddelelsesmæglere, webservere og applikationsgateways, samt VPC-gateways og DNS-poster;
- tenantens standardtags, som platformen tilføjer til hver ressource, der oprettes i en tenant;
- tagfarver, som får et tag til at se ens ud i alle tenants i din organisation;
- Terraform: providerens
default_tagsog attributtentags_all.
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:
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> --cleartags 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:
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.
| Regel | Grænse |
|---|---|
| Antal tags | Højst 32 pr. klynge eller node pool, inklusive tenantens standardtags |
| Nøgle | 1 til 64 byte bogstaver, cifre og . _ : / -; skal starte og slutte med et bogstav eller et ciffer |
| Værdi | Højst 256 byte, uden kontroltegn. En værdi må være tom. |
| Reserverede nøglepræfikser, uanset store/små bogstaver | frostmoln_, 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.
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> --cleartags 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:
| Tjeneste | Ressourcer, der kan tagges |
|---|---|
| Databaser | Instanser, læsereplikaer, sikkerhedskopier og parametergrupper |
| Cacher | Instanser og sikkerhedskopier |
| Meddelelsesmæglere | Instanser |
| Webservere | Instanser, domæner og udrulninger af indhold |
| Applikationsgateway | Gateways, 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:
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=webtags 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.
| Regel | Grænse |
|---|---|
| Antal standardtags | Højst 10 pr. tenant |
| Nøgle | 1 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ærdi | 0 til 255 byte med bogstaver, cifre, mellemrum og + - . _ : / @ =. Værdien må være tom. |
| Reserverede nøglepræfikser, uanset store og små bogstaver | frostmoln_, frostmoln-, os_, instance_, nova_ |
| Reserverede nøgler, uanset store og små bogstaver | request-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.
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 clearset 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:
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ærdivinder 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.
| Regel | Grænse |
|---|---|
| Regler | Højst 200 pr. organisation og én pr. nøgle og værdi |
| Nøgle | 1 til 255 tegn, uden kontrol- eller formateringstegn |
| Værdi | Højst 256 tegn, uden kontrol- eller formateringstegn; eller ingen, for at matche alle værdier |
| Reserverede nøglepræfikser | frostmoln_ 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 #.
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 prodHvis 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.
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:
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:
tagsindeholder præcis det, som ressourcens konfiguration angiver.tags_aller skrivebeskyttet og indeholder alle tags på ressourcen: providerensdefault_tags, ressourcens egnetags, tenantens standardtags og alt, der er angivet uden for Terraform. Referér tiltags_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:
| Kilde | Forrang |
|---|---|
Ressourcens tags | Højest |
Providerens default_tags | Mellem |
| Tenantens standardtags | Lavest |
Providerens default_tags og tenantens standardtags adskiller sig i omfang og tidspunkt:
| Tenantens standardtags | Providerens default_tags | |
|---|---|---|
| Gælder | Hver ressource, der oprettes i tenanten, af enhver klient | De ressourcer, én providerkonfiguration administrerer |
| Hvornår | Én gang, når en ressource oprettes | Ved hver oprettelse og opdatering |
| Når de ændres | Påvirker kun ressourcer, der oprettes bagefter | Planlægger en opdatering på stedet af hver ressource med tags i konfigurationen |
| Vises i Terraform | Kun i tags_all | I tags_all |
| Regler | Reglerne for standardtags | De 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 bruge | Skal du have provider |
|---|---|
| Terraform i en tenant, der har standardtags | v0.62.0 eller nyere |
default_tags og tags_all | v0.62.0 eller nyere |
frostmoln_tag_color og datakilden frostmoln_tag_colors | v0.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_pool | v0.81.0 eller nyere |
tags på ressourcerne til databaser, cacher, meddelelsesmæglere, webservere og applikationsgateways | v0.82.0 eller nyere |
tags på frostmoln_gateway, frostmoln_dns_record, frostmoln_lb_listener og frostmoln_lb_member | v0.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.
Relateret
- API-nøgleadgange · Cloud-migrering
- fm CLI-reference:
fm organization·fm tenant - Terraform:
frostmoln_tag_color· datakildenfrostmoln_tag_colors