Paucas foveas exaggeremus, in iis quae ad ansas pertinent, si enuntiationes et artes instruere, necnon quaestiones generaliores quae Terraform in genere afficiunt;
- comes et singula parametri limitationes habent;
- nulla downtime deployments limit;
- etiam consilium bonum deesse potest;
- reficiens foveas suas habere potest;
- differtur, cohaeret cum dilatione ... cohaeret.
Comes et for_singula ambitum habent limitationes
Exempla in hoc capite latissime utuntur parametri comitis et cuiusvis locutionis in loramenta et logica conditionalis. Bene praestant, sed duas praecipuas habent limitationes, quas scire debes.
- Numerare et singulatim non possunt aliquas variabiles resource output referre.
- numerare et for_each in moduli configuratione adhiberi non possunt.
numerare et for_each non referat aliqua resource output variables
Finge te necesse esse pluribus EC2 ministrantibus explicandi et quacumque de causa ASG uti non vis. Codicem tuum sic esse posse:
resource "aws_instance" "example_1" {
count = 3
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}
Singillatim inspiciamus.
Cum numerus parametri ad valorem static apponitur, hic codice sine problematibus laborabit: cum mandatum applicatum curris, tres ec2 ministrantes creabit. Sed quid si in unaquaque promptibilitate Zonae (AZ) in regione tua currenti AWS unum disponere voluisti? Potes habere codicem tuum onerare indicem zonarum ab aws_availability_zonum notitiarum fonte ac deinde ansa per unumquemque et ec2 ministratorem creare in eo utens parametro comiti et indice accessu ordinata:
resource "aws_instance" "example_2" {
count = length(data.aws_availability_zones.all.names)
availability_zone = data.aws_availability_zones.all.names[count.index]
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}
data "aws_availability_zones" "all" {}Hoc signum etiam bene laborabit, cum modulus narrationis notitias fontes sine ullis quaestionibus referat. Sed quid fit si numerus ministrorum creare debes ex copia alicuius subsidii pendeat? Ad hoc demonstrandum, via facillima est subsidii incerti uti, quod, ut nomen sonat, temere integrum reddit:
resource "random_integer" "num_instances" {
min = 1
max = 3
}Hoc signum temere numerum inter 1 et 3. generat, quid acciderit si conamur utendi copiae huius subsidii in computatione parametri aws_instantiae subsidii:
resource "aws_instance" "example_3" {
count = random_integer.num_instances.result
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}Si in hoc codice consilium terraforme curris, errorem hunc sequeris:
Error: Invalid count argument
on main.tf line 30, in resource "aws_instance" "example_3":
30: count = random_integer.num_instances.result
The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources that the count depends on.Terraforme requirit ut comitem et singula in ratione temporis calculetur, antequam aliquae facultates creentur vel modificantur. Hoc significat comitem et singulas litteras, variabiles, datas fontes, ac etiam indices subsidiorum (quandiu longitudo eorum in scheduling tempore determinari potest), non autem ad res varias computandas.
numerare et for_each non possunt in moduli configuratione
Aliquando tentari potes modulum addere modulo tuo moduli conformationis:
module "count_example" {
source = "../../../../modules/services/webserver-cluster"
count = 3
cluster_name = "terraform-up-and-running-example"
server_port = 8080
instance_type = "t2.micro"
}Hoc signum in modulo intra computationem uti conatur ut tria exemplaria efficiendi instrumenti webserver-botri. Vel vis ad libitum iungendi modulum secundum aliquam condicionem Boolean constituendo modulo suo ad 0. Hoc videre ut codicem rationabilem videres, sed hunc errorem habebis cum consilium terraforme currentem:
Error: Reserved argument name in module block
on main.tf line 13, in module "count_example":
13: count = 3
The name "count" is reserved for use in a future version of Terraform.Infeliciter, ut Terraform 0.12.6, comite vel for_singula ope moduli subsidii non continetur. Secundum Terraform 0.12 notas emissio (http://bit.ly/3257bv4), HashiCorp cogitat ut facultatem hanc in futurum addat, ut fretus cum hunc librum legas, iam praesto sit. Invenire pro certo; .
Nulla limitationes Downtime deployments
Utens impedimentum creatum in compositione cum ASG, magna est solutio ad creandos nullas curas temporis, praeter unam cautionem: regulae autoscaling non praebentur. Vel ut magis accuratum, haec magnitudo ASG reponit ad minuendam omnem instituti rationem, quae posset esse quaestio si autoscaling praecepta uteres ad augendum numerum currentium ministrantium.
Exempli gratia, servitor-botrus modulus binas facultates schedularum schedularum continet, quae ad 9 am numerum ministrantium in botro a duobus ad decem augetur. Si explicaveris, dic 11 a.m., novus ASG tabernus cum duobus tantum servientibus quam decem et remanebit eo modo usque ad diem 9 a.m.
Haec limitatio multipliciter circumveniri potest.
- Mutare recursum parametri in aws_autoscaling_schedulae ab 0 9 * * (" ad 9 am currendum") ad aliquid simile 0-59 9-17 * * * (" currunt minutatim ab 9 am ad 5 pm"). Si ASG iam decem ministros habet, iterum regulae huius autoscenicae currentes nihil mutabunt, quod volumus. Quod si ASG modo nuper explicatum est, haec regula faciet ut in maximo minuti numero servientium ad decem perveniatur. Is accessus plane elegans non est, et magnae salit a decem ad duos servientes et retro possunt etiam quaestiones pro utentibus causare.
- Facere scripturam consuetudinem quae AWS API adhibet ut numerum ministrorum activorum in ASG determinet, utens fonte data externa (vide "Externa Data Source" pag 249), et parametri ASG optatam_capacitatem ad valorem redditum pone. scriptum. Hoc modo, quaelibet nova instantia ASG semper ad eandem facultatem ac codicem Terraform existens existens, difficiliorem conservationem efficit.
Utique, Terraform in auxilio nulla-downtime inceptorum, sed sicut mensis Maii 2019, optime construxit, turmas HashiCorp non habuit consilia ad hanc functionem addere ().
Recta ratio potest male implemented
Interdum mandatum consilium perfecte recte instruere consilium producit, sed mandatum applicatio errorem reddit. Conare, exempli gratia, auxilium aws_iam_usoris additis eodem nomine quo usus est IAM usuario, quem antea creasti in Capite 2:
resource "aws_iam_user" "existing_user" {
# ΠΠΎΠ΄ΡΡΠ°Π²ΡΡΠ΅ ΡΡΠ΄Π° ΠΈΠΌΡ ΡΠΆΠ΅ ΡΡΡΠ΅ΡΡΠ²ΡΡΡΠ΅Π³ΠΎ ΠΏΠΎΠ»ΡΠ·ΠΎΠ²Π°ΡΠ΅Π»Ρ IAM,
# ΡΡΠΎΠ±Ρ ΠΏΠΎΠΏΡΠ°ΠΊΡΠΈΠΊΠΎΠ²Π°ΡΡΡΡ Π² ΠΈΡΠΏΠΎΠ»ΡΠ·ΠΎΠ²Π°Π½ΠΈΠΈ ΠΊΠΎΠΌΠ°Π½Π΄Ρ terraform import
name = "yevgeniy.brikman"
}Nunc, si consilium curritis mandatum, Terraforme ratiocinandi ratio videtur rationabilis instruere;
Terraform will perform the following actions:
# aws_iam_user.existing_user will be created
+ resource "aws_iam_user" "existing_user" {
+ arn = (known after apply)
+ force_destroy = false
+ id = (known after apply)
+ name = "yevgeniy.brikman"
+ path = "/"
+ unique_id = (known after apply)
}
Plan: 1 to add, 0 to change, 0 to destroy.Si mandatum applicatum curris, errorem sequens habebis:
Error: Error creating IAM User yevgeniy.brikman: EntityAlreadyExists:
User with name yevgeniy.brikman already exists.
on main.tf line 10, in resource "aws_iam_user" "existing_user":
10: resource "aws_iam_user" "existing_user" {Problema sane est IAM user cum hoc nomine iam existere. Idque fieri potest non solum utentibus IAM, sed omnibus fere subsidiis. Fieri potest ut aliquis hanc subsidio manually creaverit vel linea mandatorum utens, sed alterutro modo ids adaptans ad pugnas ducit. Multae variationes huius erroris sunt quae advenas ad Terraformam improviso saepe capiunt.
Praecipuum illud est quod consilium terraforme mandatum tantum rationem accipit facultates illas quae in tabella publica Terraformi certae sunt. Si facultates alio modo creantur (exempli gratia, manually strepitando in AWS console), in tabella civitatis non desinent et ideo Terraform eas in rationem non habebunt cum consilium mandatum exsequens. Quam ob rem consilium, quod primo intuitu recte videtur, evenit parum prospere.
Duae lectiones ex hoc discendae sunt.
- Si iam cum Terraforma laborare coepisti, nihil alio utere. Si pars infrastructurae tuae Terraform utens tractatur, iam manually mutare non potes. Alioquin non solum infandum errores Terraformes periclitaris, sed etiam multa negas beneficiorum Iac cum codice iam accurate repraesentatio infrastructurae tuae non erit.
- Si iam habes aliquid infrastructuram, utere praecepto import. Si Terraformi cum infrastructura existente uti incipias, eam ad tabulam publicam utens mandatum importare terraformi potes addere. Hoc modo Terraform cognoscet quid infrastructura tractanda sit. In summa imperil duas rationes sumit. Prima est inscriptio subsidii in lima configuratione tua. Syntaxis hic idem est ac nexus resource: _. (Sicut aws_iam_user.existing_user). Secunda ratio est ID copiae importandae. Dicamus resource ID aws_iam_usoris nomen usoris (exempli gratia yevgeniy.brikman), et subsidium ID aws_instantia est ec2 servo ID (sicut i-190e22e5). Facultatem importare consuevit in documentis in fundo paginae eius.
Infra mandatum importabile est quod resource aws_iam_usoris synchronizet quod adiecisti conformationem Terraformi tuae una cum IAM usuario in Capitulo 2 (substituendo nomen tuum pro yevgeniy.brikman, sane);
$ terraform import aws_iam_user.existing_user yevgeniy.brikmanTerraform AWS API vocabit ut tuum IAM usum invenias et statum fasciculi connexionis inter illam et aws_iam_user.existing_usorem in tua Terraform configuratione invenias. Posthac, cum consilium mandatum curris, Terraform cognoscet IAM usorem iam esse et iterum creare non conabitur.
Notatu dignum est, si iam multum habes opes quas in Terraform importare vis, manually codicem scribens et unumquemque ad tempus importans hassle esse potest. Itaque dignum est inspicere instrumentum sicut Terraforming (http://terraforming.dtan4.net/), quod statim codicem et statum ex ratione tua AWS importare potest.
Refactoring potest habere foveas
Refactoring praxis communis est in programmando ubi structuram internam codicis mutas, dum mores externos non mutas. Hoc est, ut codicem dilucidiorem, subtiliorem, faciliorem reddere possit. Refectio est necessaria ars quae regulariter adhiberi debet. Sed cum Terraforme vel quovis alio instrumento Iac pervenerit, diligenter debebis quid per "mores externos" particulae codicis significas, alioquin inopinatae quaestiones orientur.
Exempli causa, genus commune refactorum substituit nomina variabilium vel functionum cum facilioribus. Multae IDEs aedificaverunt-in subsidio reficiens et automatice variabilium et functionum in communi nomine nominare possunt. In linguis programmandis generaliter, haec ratio levis est ut non cogites, sed in Terraformi diligentissime caveas, alioquin outages experiaris.
Exempli gratia: glomerula telaris variabilis botri nomen habet:
variable "cluster_name" { description = "The name to use for all the cluster resources" type = string }Finge te hoc modulo uti coepi ad explicandam microservitia quae foo vocatur. Postea renominare munus tuum vis intercludere. Haec mutatio levis videri potest, sed re vera perturbationes muneris causare potest.
Re vera est quod botrus servulus moduli utitur cluster_name variabili in numero opum, incluso nomine parametri duorum circulorum securitatis et ALB:
resource "aws_lb" "example" { name = var.cluster_name load_balancer_type = "application" subnets = data.aws_subnet_ids.default.ids security_groups = [aws_security_group.alb.id] }Si nomen moduli in auxilio mutaveris, Terraform veterem versionem illius subsidii delebit et novam in suo loco creabit. Si autem illud auxilium est ALB, inter delendo et novam versionem deprimendo, mechanismum non habebitis ad mercaturam redirectam servo tuo interretiali. Item, si caterva securitatis deleta est, servitores tui mercaturam retis ullam rejicere incipient donec novus coetus creetur.
Alterum genus refactoris quod interest in mutando Terraform ID. Aws_security_group subsidia sumamus in moduli webservatorii moduli exemplum:
resource "aws_security_group" "instance" { # (...) }Identifier huius subsidii instantia vocatur. Finge hoc in refactoria quam decrevistis eam mutare ad notiorem (in tua sententia) nomen botri;
resource "aws_security_group" "cluster_instance" { # (...) }Quid tandem fiet? SIC: discidium.
Terraformi coniungit singula subsidia ID cum provisore nubilo ID. Exempli gratia, iam_usor coniungitur cum AWS IAM usore ID, et aws_instantia coniungitur cum servo EC2 AWS ID. Si resource ID mutaveris (ab instantia ad uvam_instanciam, sicut in aws_security_group), in Terraform mutabis, quasi vetus subsidium delevisti et novam adiecisti. Si has mutationes applicaveris, Terraform vetus coetus securitatis delebit et novum creabit, cum servitores tui mercaturam retis ullam rejicere incipiunt.
Quattuor hic sunt lectiones praecipui, quas ab hac disputatione adimere debes.
- Consilio semper utere imperio. Haec omnia snags revelare potest. Eius output diligenter recense et condiciones observa ubi Terraform consilia ad facultates delendas quae maxime deleri non debent.
- Crea prius delere. Si subsidium reponere vis, diligenter cogita num debeas repositum creare antequam originale delendo. Si respondendum est, creare_before_destroy adiuvare potest. Idem effectus manually duobus gradibus praestari potest: primum novum auxilium ad configuratione adde et ad applicatum mandatum currite, deinde vetus auxilium a configuratione remove et denuo mandatum adhibere.
- Mutans identificatores requirit statum mutandum. Si vis mutare ID consociata cum subsidio (exempli gratia, renominationum aws_security_group ab instantia ad cluster_instance) sine deleta opum et novam versionem eius creans, Terraform statum fasciculum renovare debes. Numquam hoc manually - utere imperio civitatis terraformi loco. Cum identificatores renaminges, iubes imperium terraforme currere, quod sequens syntaxin habet:
terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>ORIGINAL_REFERENCE expressio est quae ad auxilium spectat in forma praesenti, et NEW_REFERENCE est quo eam movere vis. Exempli gratia, cum renamingis catervam aws_security_ coetus ab instantia ad botrum instantiae, debes currere hoc mandatum:
$ terraform state mv aws_security_group.instance aws_security_group.cluster_instanceHoc Terraform narrat statum, qui antea cum aws_security_groupi sociatus erat, nunc cum aws_security_group.cluster_instantia sociandus est. Si post renominatam ac currendam mandatum terraformis consilium mutationes nullas ostendit, tunc omnia recte fecistis.
- Quidam occasus mutari non potest. Parametri multarum opum immutabiles sunt. Si eas mutare coneris, Terraform vetus subsidia delebit et novam in suo loco creabit. Quaelibet pagina resource indicabit quid acciderit cum certo mutaveris occasum, ut certa documenta inspicias. Semper consilio utere imperio et considera utendo consilio creo_before_destroy.
Constantia differtur stat ... cum dilatione
Quaedam nubes provisores 'APIs, ut AWS, asynchronae sunt et constantiam retardaverunt. Asynchrony significat interface responsionem statim reddere posse sine exspectatione actionis petitae ad perficiendum. Constantiam differri significat mutationes temporis spatium propagandi per systema; dum hoc agitur, responsiones tuae inconstantes possunt et dependentes, quibus data origo replicatur quod API vocati tuo respondeat.
Finge, exempli gratia, te API vocari ad AWS rogantem ut ec2 servo creet. API responsio "prosperum" reddet (201 Partum) paene statim, non expectans ipsum servitorem creandum. Si coneris coniungere cum ea ilicet, fere certe deficiet quia in illo puncto AWS adhuc facultates initialisandi sunt vel, e servo nondum profuerit. Praeterea, si aliam vocationem ad informationem de hoc servo facias, errorem recipere potes (404 Not Found). Res est ut informationes de hac EC2 servo per AWS propagari adhuc possint priusquam ubique praesto sit, brevi tempore expectare debebis.
Quoties asynchronum API cum ignava constantia uteris, postulatio tua intervenit, donec actio per systema compleat et propaget. Infeliciter, AWS SDK nullum bonum instrumenta ad hoc praebet, et Terraformia inceptis a multis cimicibus ut 6813 laborant (https://github.com/hashicorp/terraform/issues/6813);
$ terraform apply aws_subnet.private-persistence.2: InvalidSubnetID.NotFound: The subnet ID 'subnet-xxxxxxx' does not existAliis verbis, auxilium creas (sicut subnet) et tunc explorare aliquid de eo (sicut ID subnet novi creati), et Terraform illud invenire non potest. Plerique ex his cimices (including 6813) fixi sunt, sed tamen subinde carpunt, praesertim cum Terraform subsidium novum genus subsidii addit. Hoc est molestum, sed in pluribus non nocet. Cum terraformes iterum curris, omnia operare debent, cum iam notitiae per systema diffundantur.
Hoc excerptum exhibetur e libro ab Evgeniy Brikman .
Source: www.habr.com