-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix circular dependency double-deployment requirement #92
Fix circular dependency double-deployment requirement #92
Conversation
…steps anyhow" This reverts commit 5e1b629.
…udet-siten-etta-onnistuu-ensiasennus-kerralla-2
docs/README.af-mvp.deployment.md
Outdated
After the initial deployments, the following deployments can be done normally. | ||
|
||
## AWS Cognito credentials after initial deployment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Iha minor juttu ja ehkä mun luetun ymmärtämisessä piilee vika (tai jokin maanantaiaamun brainfart), mutta luin tämän kohdan ekaksi niin, että "the following deployments", jonka jälkeen AWS Cognito ---> ikään kuin "the following" viittaisi Congnitoon mikä olisi erillinen deployment steppi. Ehkä tässä muuttaisi lauseen jotenkin "After the initial deployments, any futute deployments can be done normally without any kikkailu", ettei aiheuta initial hämmings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Less hämmings less jännings!
if (domainConfig.domainName === domainConfig.domainRootName) { | ||
// If the domain name is the same as the zone name, we cant' create a CNAME record for as it would conflict with the zone apex record. | ||
// We create ALIAS record instead. | ||
new aws.route53.Record(nameResource('domainAliasRecord'), { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pitäisköhän tässä kommentissa implikoida, että tämä liittyy staging/prod subdomain hallintaan(?). Tai näin ainakin ymmärsin, piti vähän aikaa ihmetellä, että miksi tässä näin iffitellään, mutta ilmeisesti siis prod -tapauksessa domainName ja domainRootName on samat, staging käyttelee sit subdomainia.
edit: paitsi että olin vähän hakoteilla alkuperäisen ajatuksen kanssa, koska prod/staging eivät olekaan samassa domainissa (accessfinland.com vs. accessfinland.dev), eli staging tapauksessa on omaa subdomain kikkailua.. Oliko tämä staging.accessfinland.dev jokin sovittu juttu, että pitää käytellä?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Joo hyvä huomio! Selventelen tuota esimerkillä. Sinäänsä ei teknisesti liity eri live-ympäristöihin vaan pelkästään siihen minkälainen domain-nimi on kyseessä (eli prod voisi yhtä hyvin olla sellainen jossa domain-nimi on alidomain, tai vastaavasti staging vois olla juuridomain.).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oliko tämä staging.accessfinland.dev jokin sovittu juttu, että pitää käytellä?
Juu oli, ja tarkoitus taisi olla sellainen että voisi myöhemmin löytyä jotain vaikka demo.accessfinland.dev
-tyyppistä käyttöä.
.github/workflows/deploy-af-mvp.yml
Outdated
- name: Initial deployment domain check | ||
if: steps.pulumi.outputs.initialDomainCheckRequired | ||
uses: pulumi/actions@v4 | ||
with: | ||
work-dir: ./infra/af-mvp | ||
command: up | ||
stack-name: ${{ env.pulumi_stack_organization }}/${{ inputs.environment }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Olisko tässä hyvä oikein kädestä pitäen kertoa, että tämä viimeinen steppi tarkastelee edellistä (jolle voisi vielä vaikka antaa id:ksi pulumi
, niin vscode ei herjaa Context access might be invalid: pulumi
). Ehkä astetta luettavampi ja ei aiheuta IDE warningien kanssa hämmennystä, että mihin steps.pulumi
viittaa.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jahas, ei ollut vscodessa GHA-plugari päällä. Steppi saa jo valmiiksi ID:n "pulumi" koska kyseinen action antaa sille sellaisen tunnisteen, mutta eipä kieltämättä IDE tälläisestä tiedä.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jeps, näin laskin kanssa 1 + 1 että sieltä tulee, mutta IDE ei ole vielä tarpeeksi viisas.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tämän varoituksen varmaan voisi ehjätä siten että tekisi oman toteutuksen tuosta pulumi/actions@v4
-toimesta jonka kautta outputit ja vastaavat tulisi gha-vscoden näkyville, mutta vähän näyttää että kyseessä on ehkä virhe itse tuossa plugarissa.
Helppo ratkaisu olisi tässä kommentissa: github/vscode-github-actions#67 (comment) ,
ja sitten se valittu ratkaisu eli purkkafiksi: github/vscode-github-actions#222 (comment) (huom. gha:ssa ${{}}
-wrappailu muuttaa kaiken stringeiksi)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Nämä muna-kanaongelmat tuntuu olevan vähän sellaisia, mihin ei vielä mitään de-facto ratkaisuja ole pulumi tai IaC puolella ylipäätään, ja tuo samaan stäkkiin viittaaminen ja tupladeplailut tuntui olevan muuallakin ehdotettu vaihtoehto. Tietysti vielä se kolmas steppi missää pitää odotella, että AWS:n päässä on asiat valmiina.
Varmaan yksi vaihtoehto isommassa seteissä voisi olla resujen jaottelu jotenkin loogisesti omiin stäkkeihinsä, ja tehdä niistä jotenkin automaagisesti dependent toisistaan (jotain tän tyylistä, tulitko tutkineeksi: https://www.pulumi.com/blog/dependent-stack-updates/#expressing-stack-dependencies-with-pulumi-auto-deploy). Overkill varmasti tässä tapauksessa, ja en tiedä oisko vaikeampaa saada jotenkin läpinäkyväksi ci-pipelinessä, miten eri stäkit ja deplaukset on sidoksissa toisissaan. Tietysti hyvällä dokumentaatiolla ainakin helpottaa. Voi myös olla, että ei tämäkään lähestymistapa ratkaisisi asiaa, riippuen casesta.
docs/README.af-mvp.deployment.md
Outdated
- Initial deployment with custom domain name (should succeed): | ||
- Installs the SSL certificates and domain names to the resources that require them | ||
|
||
After the initial deployments, any futute deployments can be done normally. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
futute
Eipä tullut toi blogaisu vastaan tässä (varmaan ei ollut googlebing-hakuihin vielä indeksoitunut minun hakusanoilla). Tässä tutkimuksessa kävi prosessina sellainen luovutusvoitto, että kun tarpeeksi tutki esim. tuota pulumin automation-toiminnan dokumentaatiota (blogeja, koodiesimerkkejä) joissa vanhentuneet viitteet jotka ei nykyjään enää pelittele, niin luovutus siinä ettei enempää halunnut käyttää aikaa hakemiseen, mutta voitto siinä mielessä että alkuperäinen ratkaisu itseasiassa oli ihan toimiva kunhan sen korjasi ja dokumentoi. Tämän keissin riippuvuuskiisseliä kieltämättä myös vaikeuttaa se, ettei riippuvuudet ole ainoastaan komponenttien välisiä vaan myös ulkopuoliset prosessit, kuten SSL-sertin verifiointi AWS:n päädyssä, vaikuttaa. Näistä syistä tuntui, että joka tapauksessa kun käy niin ettei alkutilanteesta selviä helposti yksittäisellä deplauksella, niin sama se on sitten pitää se monen deplauksen malli ja kirjoittaa siitä avainasiat auki. |
Muokattu ensi-asennuksen ohjeet järkevämpään muotoon: aina vaaditaan 3 deplausta, CI/CD-tekee pari ekaa automaattisesti. |
👍 👏 |
When deploying the af-mvp app with a custom domain name the configurations of the different components depends on the others details in a circular manner. To solve the circular dependency issue it was previously handled so that the configurations rely initially on a "double" deployment: first deploy without the domain name, then deploy again with the domain. This was the idea, but the solution was untested in actual and had some issues. This PR fixes those issues and changes the deployment flow so that
there's no need for a double deployment (the flow still deploys twice internally, but only does actions when needed)the need for initial double deployment still persists but is handed with the github actions CI/CD pipeline:pulumi automation toolingidea from How to solve Chicken & Egg problem / cyclic dependencies / update resources? pulumi/pulumi#3021