Es mācījos šīs 6 mācības darbā ar mākoņveidošanu visu atlikušo mūžu.

Es sāku strādāt ar mākoņu veidošanās pirms 4 gadiem. Kopš tā laika esmu salauzis daudzas infrastruktūras, pat tās, kas jau tika ražotas. Bet katru reizi, kad es kaut ko sajaucu, es uzzināju kaut ko jaunu. Izmantojot šo pieredzi, es dalīšos ar dažām svarīgākajām mācībām, ko esmu guvis.

1. nodarbība: pārbaudiet izmaiņas pirms to izvietošanas

Šo mācību iemācījos drīz pēc tam, kad sāku strādāt ar mākoņu veidošanās. Es neatceros, ko tieši toreiz salauzu, bet noteikti atceros, ka izmantoju komandu aws mākoņformācijas atjauninājums. Šī komanda vienkārši izlaiž veidni, nepārbaudot izmaiņas, kas tiks izvietotas. Es nedomāju, ka ir vajadzīgs paskaidrojums, kāpēc jums vajadzētu pārbaudīt visas izmaiņas pirms to izvietošanas.

Pēc šīs neveiksmes es uzreiz mainījos izvēršanas cauruļvads, aizstājot atjaunināšanas komandu ar komandu izveidot-mainīt-iestatīt

# 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"

Kad izmaiņu kopa ir izveidota, tai nav nekādas ietekmes uz esošo steku. Atšķirībā no atjaunināšanas komandas, izmaiņu kopas pieeja neaktivizē faktisko izvietošanu. Tā vietā tiek izveidots izmaiņu saraksts, kuras varat pārskatīt pirms izvietošanas. Izmaiņas varat skatīt aws konsoles saskarnē. Bet, ja vēlaties automatizēt visu iespējamo, pārbaudiet tos CLI:

# 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 table

Šai komandai vajadzētu radīt līdzīgu izvadi:

--------------------------------------------------------------------
|                         DescribeChangeSet                        |
+---------+--------------------+----------------------+------------+
| Action  | ReplacementNeeded  |      Resource        | ResourceId |
+---------+--------------------+----------------------+------------+
|  Modify | True               |  AWS::ECS::Cluster   |  MyCluster |
|  Replace| True               |  AWS::RDS::DBInstance|  MyDB      |
|  Add    | None               |  AWS::SNS::Topic     |  MyTopic   |
+---------+--------------------+----------------------+------------+

Pievērsiet īpašu uzmanību izmaiņām, kur ir darbība aizstāt, izdzēst vai kur Nepieciešama nomaiņa — taisnība. Šīs ir visbīstamākās izmaiņas un parasti izraisa informācijas zudumu.

Kad izmaiņas ir pārskatītas, tās var izvietot

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"

2. nodarbība. Izmantojiet steka politiku, lai novērstu statusa resursu aizstāšanu vai noņemšanu

Dažreiz nepietiek tikai ar izmaiņu apskati. Mēs visi esam cilvēki un visi pieļaujam kļūdas. Neilgi pēc tam, kad sākām izmantot izmaiņu kopas, mans komandas biedrs neapzināti veica izvietošanu, kā rezultātā tika atjaunināta datubāze. Nekas slikts nenotika, jo tā bija testēšanas vide.

Lai gan mūsu skriptos tika parādīts izmaiņu saraksts un tika lūgts apstiprinājums, Aizstāt izmaiņas tika izlaistas, jo izmaiņu saraksts bija tik liels, ka tas neietilpa ekrānā. Un tā kā šis bija parasts atjauninājums testēšanas vidē, izmaiņām netika pievērsta liela uzmanība.

Ir resursi, kurus nekad nevēlaties aizstāt vai noņemt. Tie ir pilnvērtīgi pakalpojumi, piemēram, RDS datu bāzes gadījums vai elasticsearch klasteris utt. Būtu jauki, ja aws automātiski atteiktu izvietošanu, ja veiktajai darbībai būtu nepieciešams dzēst šādu resursu. Par laimi, mākoņformēšanai ir iebūvēts veids, kā to izdarīt. To sauc par steka politiku, un vairāk par to varat lasīt šeit dokumentācija:

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"

3. nodarbība. Izmantojiet UsePreviousValue, atjauninot steku ar slepenajiem parametriem

Kad veidojat RDS mysql entītiju, AWS pieprasa norādīt MasterUsername un MasterUserPassword. Tā kā avota kodā noslēpumus labāk neglabāt un vēlējos pilnīgi visu automatizēt, ieviesu "viedo mehānismu", kur pirms izvietošanas akreditācijas dati tiks iegūti no s3, un, ja akreditācijas dati netiek atrasti, tiek ģenerēti jauni akreditācijas dati un saglabāts s3.

Pēc tam šie akreditācijas dati tiks nodoti kā parametri mākoņformācijas komandai izveidot-mainīt-iestatīt. Eksperimentējot ar skriptu, gadījās, ka pazuda savienojums ar s3, un mans “gudrais mehānisms” to uztvēra kā signālu jaunu akreditācijas datu ģenerēšanai.

Ja es sāku izmantot šo skriptu ražošanā un savienojuma problēma atkārtojas, tas atjauninātu steku ar jauniem akreditācijas datiem. Šajā konkrētajā gadījumā nekas slikts nenotiks. Tomēr es atteicos no šīs pieejas un sāku izmantot citu, sniedzot akreditācijas datus tikai vienu reizi - veidojot steku. Un vēlāk, kad kaudze ir jāatjaunina, tā vietā, lai norādītu parametra slepeno vērtību, es vienkārši izmantotu 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"

4. nodarbība. Izmantojiet atcelšanas konfigurāciju

Cita komanda, ar kuru es strādāju, izmantoja šo funkciju mākoņu veidošanās, zvanīja atcelšanas konfigurācija. Es iepriekš nebiju ar to saskāries un ātri sapratu, ka tas padarīs manu steku izvietošanu vēl foršāku. Tagad es to izmantoju katru reizi, kad izvietoju savu kodu lambda vai ECS, izmantojot mākoņformāciju.

Kā tas darbojas: jūs norādāt CloudWatch modinātājs parametrā --atcelšanas konfigurācijakad veidojat izmaiņu kopu. Vēlāk, kad veicat izmaiņu kopu, aws uzrauga modinātāju vismaz vienu minūti. Tas atgriež izvietošanu, ja šajā laikā trauksmes stāvoklis mainās uz ALARM.

Zemāk ir veidnes fragmenta piemērs mākoņu veidošanāskurā es radu mākoņpulksteņa modinātājs, kas izseko mākoņa lietotāja metriku kā kļūdu skaitu mākoņa žurnālos (metrika tiek ģenerēta, izmantojot 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: yes

Tagad signalizācija var izmantot kā atritināt aktivizētājs, izpildot rīklodziņu:

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"

5. nodarbība. Noteikti izvietojiet jaunāko veidnes versiju

Ir viegli izvietot mākoņformēšanas veidnes versiju, kas nav jaunāka, taču tas radīs lielu kaitējumu. Tas notika ar mums vienu reizi: izstrādātājs nespieda jaunākās Git izmaiņas un neapzināti izvietoja iepriekšējo steka versiju. Tas izraisīja dīkstāvi lietojumprogrammai, kas izmantoja šo steku.

Kaut kas tik vienkāršs kā pārbaudes pievienošana, lai noskaidrotu, vai filiāle ir atjaunināta pirms apņemšanās to izmantot (pieņemot, ka git ir jūsu versiju kontroles rīks):

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
fi

6. nodarbība. Neizgudrojiet riteni no jauna

Tas var likties kā izvietošana ar mākoņu veidošanās - tas ir viegli. Jums vienkārši nepieciešams virkne bash skriptu, kas izpilda aws cli komandas.

Pirms 4 gadiem es sāku ar vienkāršiem skriptiem, ko sauca par aws cloudformation create-stack komandu. Drīz vien scenārijs vairs nebija vienkāršs. Katra apgūtā stunda padarīja scenāriju arvien sarežģītāku. Tas bija ne tikai grūti, bet arī pilns ar kļūdām.

Šobrīd strādāju nelielā IT nodaļā. Pieredze rāda, ka katrai komandai ir savs veids, kā izvietot mākoņformācijas stekus. Un tas ir slikti. Būtu labāk, ja visi izvēlētos vienu un to pašu pieeju. Par laimi, ir pieejami daudzi rīki, kas palīdz izvietot un konfigurēt mākoņformācijas stekus.

Šīs nodarbības palīdzēs izvairīties no kļūdām.

Avots: www.habr.com