7 ting at vide om rum på Oracle Cloud Infrastructure

Afdelinger er en af ​​differentiatorerne på Oracle Cloud Infrastructure, personligt synes jeg ikke at være en lignende tjeneste hos andre cloud-udbydere. Der er andre lignende koncepter som tagging eller projekter, men med andet fokus.

Et rum er en samling af relaterede ressourcer, specifikt en logisk samling af relaterede ressourcer (såsom VCN, blokvolumener, instanser, undernet). Denne samling kan kun tilgås af visse gruppebrugere, der har fået tilladelse af en administrator.

Her har vi 10 ting at vide om rum, der kan være nyttige, før du begynder at arbejde på Oracle Cloud Infrastructure:

1.-Når du tilmelder dig Oracle Cloud Infrastructure, opretter Oracle dit lejemål , som er rodrummet, der rummer alle dine cloud-ressourcer

Rodafdelingen er opkaldt efter selve lejemålet (mere om lejemål på en anden post), dette er grunden til, at lejemålsadministratoren (Del af administratorgruppen) også er rodafdelingsadministratoren.

Bemærk det er en god praksis at holde antallet af medlemmer fra administratorgrupper så lavt som muligt og oprette administratorgrupper for at kontrollere specifikke rum (i praksis er dette underafdelinger fra rodrum)

Bemærk :Dette er kun en af ​​mulighederne for at designe rumfordeling, men det er op til den arkitektur, der passer bedst til kunden

I øjeblikket oprettes alle brugere og grupper inde i rodrummet, og du kan oprette politikker, der giver disse brugere adgang til ressourcer i andre rum.

2.-En OCI-ressource kan kun tilhøre ét rum

OCI-ressourcer kan ikke være en del af to rum, du skal oprette enten inde i et specifikt rum eller inde i rodrummet.

Husk, at vi nævnte, at kompartment er logisk samling, hvilket betyder, at det er logisk struktur, så du for eksempel kan have to forekomster på forskellige rum, der tilhører samme VCN og samme undernet.

Bemærk det er nyttigt at tænke på rum som ansvarsområde, hvor du definerer tilladelser frem for en fysisk beholder.

3.-rum kan have underrum eller underrum indlejret 6 niveauer dybe

På datoen for første offentliggørelse af dette indlæg er der en grænse på maksimalt 6 indlejrede rum.

For eksempel kan du have følgende rum:
nosomoscavernicolas> prod> compute_Services> app1> db_app1> no_sql_dbs1> free_users

Det er en god praksis at designe rumhierarki, før du begynder at oprette ressourcer, selvom du kan flytte et helt rumtræ mellem forældreafdelingen, og du kan også flytte ressourcer mellem rum.

Du kan gennemgå det opdaterede nummer inde i:Ofte stillede spørgsmål om identitets- og adgangsstyring

4.-Du kan slette rum

Du kan slette rum, men du skal opfylde disse krav:

1. Du skal have administratoradgang eller den påkrævede politik for at slette rummet.
2. For at slette et rum, bør der ikke være nogen ressourcer inde i det, inklusive enhver politik knyttet til rummet.

Bemærk nogle ressourcetyper kan ikke slettes, derfor kan rum til disse ressourcer heller ikke slettes. På dette etui kan du omdøbe rummet for at genbruge navnet.

Når du har slettet rummet, starter det et slettejob, hvad Oracle gør, er at ændre navnet på rummet til noget som f.eks. rum A.qR5hP2BD, og ​​status for disse rum er sat til slettet, men du kan stadig se det slettede rum på rumside i 365 dage.

Du kan se, om alle ressourcer for et rum er slettet ved hjælp af Tenancy Explorer

5.-Lejemål og rum er globale ressourcer

Dette betyder, at afdelinger spænder over regioner og tilgængelighedsdomæner, hvilket lader os gruppere ressourcer, der er på forskellige regioner, hvilket repræsenterer en god måde at implementere omkostningsstyring på.

Bemærk Husk, at rum er en logisk gruppering af ressourcer, der ikke er bundet til fysiske begrænsninger.

6.-Du kan anvende sikkerhedspolitikker på sektionsbasis

Når du har oprettet et rum, skal du oprette mindst én politik, så brugere eller grupper kan få adgang til ressourcer inde i det nye rum, ellers vil kun administratorer have adgang til afdelingens ressourcer.

Bemærk rumtilladelser kan nedarves, så hvis du f.eks. har en gruppe kaldet db-operators med adgang til alle ressourcer på Compartment-A , og derefter opretter du en Compartment-B inde i rum-A , brugere fra db-operatører vil have adgang til ressourcer på Kompartment-B også, medmindre du angiver andet.

Hvis du for eksempel vil tillade, at OS-administrationsagenttjenesten kan læse oplysninger fra forekomster i et bestemt rum, skal du oprette denne politik:
Allow dynamic-group OSManagementAgent to read instance-family in compartment PROD-A

For at give administratoradgang til et rum
Allow group A-Admins to manage all-resources in compartment Project-A

Et andet eksempel, du vil give tilladelser, så HR-administratorer kan administrere objektlagring (OCI Service) inde i HR-rummet
Allow group hr-admins to manage object-family in compartment PROD-A

Bemærk En individuel ressourcetype er den mest detaljerede måde at deklarere ressourcer på, disse er vcn, instans osv. Også ressource-type er grupperet i familier, for eksempel instans-familie, volumen-familie osv.

Du kan finde flere detaljer om vedhæftning af politikker fra:Vedhæftet politik

7.-Du kan indstille kvoter på et rum

Rumkvoter svarer til servicegrænser.

Kvoter er fastsat af administratorer for at begrænse mængden af ​​ressourcer, der kan oprettes inde i et rum, på denne måde kan du kontrollere omkostningerne og undgå at skabe ressourcer, der ikke er nødvendige.

Til dette kan administratorer indstille politikker.

Der er 3 typer kvoter:

• sæt - indstil maks. antal ressourcer
• frakoblet - nulstiller kvoten til standardservicegrænsen
• nul - fjerner adgang til en skyressource for et rum. for eksempel, hvis du vil undgå oprettelsen af ​​blokvolumener i et rum, kan du oprette denne nulkvote for den service.