Aloin työskennellä kanssa pilvimuodostus 4 vuotta sitten. Sen jälkeen olen rikkonut monia infrastruktuureja, jopa sellaisia, jotka olivat jo tuotannossa. Mutta aina kun sotsin jotain, opin jotain uutta. Tämän kokemuksen kautta kerron tärkeimmistä opetuksistani.
Oppitunti 1: Testaa muutokset ennen niiden käyttöönottoa
Opin tämän läksyn pian sen jälkeen, kun aloin työskennellä pilvimuodostus. En muista mitä tarkalleen rikoin silloin, mutta muistan ehdottomasti käyttäneeni komentoa aws-pilvimuodostuspäivitys. Tämä komento yksinkertaisesti vie mallin käyttöön ilman käyttöönotettavien muutosten vahvistusta. En usko, että tarvitaan selitystä sille, miksi sinun pitäisi testata kaikkia muutoksia ennen niiden käyttöönottoa.
Tämän epäonnistumisen jälkeen muutin heti käyttöönottoputki, korvaa päivityskomennon komennolla luo-muuta-sarja
# OPERATION is either "UPDATE" or "CREATE"
changeset_id=$(aws cloudformation create-change-set
--change-set-name "$CHANGE_SET_NAME"
--stack-name "$STACK_NAME"
--template-body "$TPL_PATH"
--change-set-type "$OPERATION"
--parameters "$PARAMETERS"
--output text
--query Id)
aws cloudformation wait
change-set-create-complete --change-set-name "$changeset_id"
Kun muutosjoukko on luotu, sillä ei ole vaikutusta olemassa olevaan pinoon. Toisin kuin päivityskomento, Changeset-lähestymistapa ei käynnistä varsinaista käyttöönottoa. Sen sijaan se luo luettelon muutoksista, jotka voit tarkistaa ennen käyttöönottoa. Voit tarkastella muutoksia aws-konsolin käyttöliittymässä. Mutta jos haluat automatisoida kaiken, mitä voit, tarkista ne CLI:stä:
# this command is presented only for demonstrational purposes.
# the real command should take pagination into account
aws cloudformation describe-change-set
--change-set-name "$changeset_id"
--query 'Changes[*].ResourceChange.{Action:Action,Resource:ResourceType,ResourceId:LogicalResourceId,ReplacementNeeded:Replacement}'
--output tableTämän komennon pitäisi tuottaa seuraavanlainen tulos:
--------------------------------------------------------------------
| DescribeChangeSet |
+---------+--------------------+----------------------+------------+
| Action | ReplacementNeeded | Resource | ResourceId |
+---------+--------------------+----------------------+------------+
| Modify | True | AWS::ECS::Cluster | MyCluster |
| Replace| True | AWS::RDS::DBInstance| MyDB |
| Add | None | AWS::SNS::Topic | MyTopic |
+---------+--------------------+----------------------+------------+Kiinnitä erityistä huomiota muutoksiin, joissa Action on korvata, Poista tai missä ReplacementNeeded – totta. Nämä ovat vaarallisimpia muutoksia ja johtavat yleensä tiedon menettämiseen.
Kun muutokset on tarkistettu, ne voidaan ottaa käyttöön
aws cloudformation execute-change-set --change-set-name "$changeset_id"
operation_lowercase=$(echo "$OPERATION" | tr '[:upper:]' '[:lower:]')
aws cloudformation wait "stack-${operation_lowercase}-complete"
--stack-name "$STACK_NAME"Oppitunti 2: Käytä pinokäytäntöä estääksesi tilallisten resurssien korvaamisen tai poistamisen
Joskus pelkkä muutosten katsominen ei riitä. Olemme kaikki ihmisiä ja teemme kaikki virheitä. Pian sen jälkeen, kun aloitimme muutosjoukkojen käytön, tiimitoverini suoritti tietämättään käyttöönoton, joka johti tietokantapäivitykseen. Mitään pahaa ei tapahtunut, koska se oli testausympäristö.
Vaikka skriptimme näyttivät luettelon muutoksista ja pyysivät vahvistusta, Korvaa muutos ohitettiin, koska muutosluettelo oli niin suuri, että se ei mahtunut näytölle. Ja koska tämä oli normaali päivitys testausympäristössä, muutoksiin ei kiinnitetty paljon huomiota.
On resursseja, joita et koskaan halua korvata tai poistaa. Nämä ovat tilan täyttäviä palveluita, kuten RDS-tietokanta-ilmentymä tai elasticsearch-klusteri jne. Olisi mukavaa, jos aws kieltäytyisi automaattisesti käyttöönotosta, jos suoritettava toiminto vaatisi tällaisen resurssin poistamista. Onneksi pilvenmuodostuksessa on sisäänrakennettu tapa tehdä tämä. Tätä kutsutaan pinokäytännöksi, ja voit lukea siitä lisää kohdasta :
STACK_NAME=$1
RESOURCE_ID=$2
POLICY_JSON=$(cat <<EOF
{
"Statement" : [{
"Effect" : "Deny",
"Action" : [
"Update:Replace",
"Update:Delete"
],
"Principal": "*",
"Resource" : "LogicalResourceId/$RESOURCE_ID"
}]
}
EOF
)
aws cloudformation set-stack-policy --stack-name "$STACK_NAME"
--stack-policy-body "$POLICY_JSON"Oppitunti 3: Käytä UsePreviousValuetta, kun päivität pinon salaisilla parametreilla
Kun luot RDS mysql -kokonaisuuden, AWS edellyttää MasterUsernamen ja MasterUserPasswordin antamista. Koska on parempi olla pitämättä salaisuuksia lähdekoodissa ja halusin automatisoida aivan kaiken, otin käyttöön "älykäs mekanismin", jossa ennen käyttöönottoa tunnistetiedot saadaan s3:sta ja jos tunnisteita ei löydy, luodaan uudet tunnistetiedot ja tallennettu s3:een.
Nämä valtuustiedot välitetään sitten parametreina cloudformationin create-change-set -komennolle. Skriptiä kokeileessa sattui, että yhteys s3:een katkesi, ja "älykäs mekanismini" käsitteli sitä signaalina luoda uusia valtuustietoja.
Jos aloin käyttämään tätä komentosarjaa tuotannossa ja yhteysongelma toistuisi, se päivittäisi pinon uusilla tunnistetiedoilla. Tässä nimenomaisessa tapauksessa ei tapahdu mitään pahaa. Hylkäsin kuitenkin tästä lähestymistavasta ja aloin käyttää toista, joka antoi valtuustiedot vain kerran - pinon luomisen yhteydessä. Ja myöhemmin, kun pino on päivitettävä, sen sijaan, että määrittäisin parametrin salaisen arvon, käytän yksinkertaisesti UsePreviousValue=true:
aws cloudformation create-change-set
--change-set-name "$CHANGE_SET_NAME"
--stack-name "$STACK_NAME"
--template-body "$TPL_PATH"
--change-set-type "UPDATE"
--parameters "ParameterKey=MasterUserPassword,UsePreviousValue=true"Oppitunti 4: Käytä palautusasetuksia
Toinen tiimi, jonka kanssa työskentelin, käytti toimintoa pilvimuodostus, nimeltään palautuskokoonpano. En ollut törmännyt siihen aiemmin ja tajusin nopeasti, että se tekisi pinojeni käyttöönotosta vieläkin siistimpää. Nyt käytän sitä aina, kun otan koodini käyttöön lambdaan tai ECS:ään pilvimuodostuksen avulla.
Kuinka se toimii: määrittelet itse CloudWatch-hälytys parametrissa --rollback-konfiguraatiokun luot muutosjoukon. Myöhemmin, kun teet joukon muutoksia, aws tarkkailee hälytystä vähintään minuutin ajan. Se peruuttaa käyttöönoton, jos hälytys muuttaa tilaksi HÄLYTYS tänä aikana.
Alla on esimerkki malliotteesta pilvimuodostusjossa luon cloudwatch hälytys, joka seuraa pilven käyttäjämittaria pilvilokeissa olevien virheiden lukumääränä (mittari luodaan MetricFilter):
Resources:
# this metric tracks number of errors in the cloudwatch logs. In this
# particular case it's assumed logs are in json format and the error logs are
# identified by level "error". See FilterPattern
ErrorMetricFilter:
Type: AWS::Logs::MetricFilter
Properties:
LogGroupName: !Ref LogGroup
FilterPattern: !Sub '{$.level = "error"}'
MetricTransformations:
- MetricNamespace: !Sub "${AWS::StackName}-log-errors"
MetricName: Errors
MetricValue: 1
DefaultValue: 0
ErrorAlarm:
Type: AWS::CloudWatch::Alarm
Properties:
AlarmName: !Sub "${AWS::StackName}-errors"
Namespace: !Sub "${AWS::StackName}-log-errors"
MetricName: Errors
Statistic: Maximum
ComparisonOperator: GreaterThanThreshold
Period: 1 # 1 minute
EvaluationPeriods: 1
Threshold: 0
TreatMissingData: notBreaching
ActionsEnabled: yesNyt hälytys voidaan käyttää mm palautus liipaisin työkalupakkia suoritettaessa:
ALARM_ARN=$1
ROLLBACK_TRIGGER=$(cat <<EOF
{
"RollbackTriggers": [
{
"Arn": "$ALARM_ARN",
"Type": "AWS::CloudWatch::Alarm"
}
],
"MonitoringTimeInMinutes": 1
}
EOF
)
aws cloudformation create-change-set
--change-set-name "$CHANGE_SET_NAME"
--stack-name "$STACK_NAME"
--template-body "$TPL_PATH"
--change-set-type "UPDATE"
--rollback-configuration "$ROLLBACK_TRIGGER"Oppitunti 5: Varmista, että otat käyttöön mallin uusimman version
Pilvenmuodostusmallin vähemmän kuin uusimman version käyttöönotto on helppoa, mutta sen tekeminen aiheuttaa paljon vahinkoa. Tämä tapahtui meille kerran: kehittäjä ei ajanut uusimpia muutoksia Gitistä ja otti tietämättään käyttöön pinon aiemman version. Tämä johti tätä pinoa käyttäneen sovelluksen seisokkiin.
Jotain niin yksinkertaista kuin tarkistuksen lisääminen nähdäksesi, onko haara ajan tasalla ennen sitoutumista, olisi hyvä (olettaen, että git on versionhallintatyökalusi):
git fetch
HEADHASH=$(git rev-parse HEAD)
UPSTREAMHASH=$(git rev-parse master@{upstream})
if [[ "$HEADHASH" != "$UPSTREAMHASH" ]] ; then
echo "Branch is not up to date with origin. Aborting"
exit 1
fiOppitunti 6: Älä keksi pyörää uudelleen
Se voi tuntua käyttöönoton kanssa pilvimuodostus - se on helppoa. Tarvitset vain joukon bash-skriptejä, jotka suorittavat aws cli -komentoja.
4 vuotta sitten aloitin yksinkertaisilla skripteillä nimeltä aws cloudformation create-stack -komento. Pian käsikirjoitus ei ollut enää yksinkertainen. Jokainen oppitunti teki käsikirjoituksesta entistä monimutkaisemman. Se ei ollut vain vaikeaa, vaan myös täynnä bugeja.
Työskentelen tällä hetkellä pienellä IT-osastolla. Kokemus on osoittanut, että jokaisella tiimillä on oma tapansa ottaa käyttöön pilvenmuodostuspinoja. Ja se on huono. Olisi parempi, jos kaikki noudattaisivat samaa lähestymistapaa. Onneksi käytettävissä on monia työkaluja, joiden avulla voit ottaa käyttöön ja määrittää pilvenmuodostuspinoja.
Nämä oppitunnit auttavat sinua välttämään virheitä.
Lähde: will.com