Hodei-formazioa lantzeko 6 ikasgai hauek bizitza osorako ikasi ditut.

lanean hasi nintzen hodeien eraketa Duela 4 urte. Harrezkero azpiegitura asko hautsi ditut, baita jada produkzioan zeudenak ere. Baina zerbait nahasten nuen bakoitzean zerbait berria ikasten nuen. Esperientzia honen bidez, ikasitako ikasgai garrantzitsuenetako batzuk partekatuko ditut.

1. ikasgaia: Probatu aldaketak zabaldu aurretik

Lanean hasi eta gutxira ikasi nuen ikasgai hau hodeien eraketa. Ez dut gogoratzen zehazki zer hautsi nuen orduan, baina behin betiko gogoratzen dut komandoa erabili nuela aws cloudformation eguneratzea. Komando honek txantiloia zabaltzen du inplementatuko diren aldaketen baliozkotzerik gabe. Ez dut uste inolako azalpenik behar denik zergatik probatu behar dituzun aldaketa guztiak zabaldu aurretik.

Porrot honen ondoren, berehala aldatu nintzen desplazamendu-kanalizazioa, eguneratzeko komandoa komandoarekin ordezkatuz sortu-aldaketa-multzoa

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

Aldaketa-multzo bat sortu ondoren, ez du eraginik lehendik dagoen pilan. Eguneratze komandoak ez bezala, aldaketa-multzoaren ikuspegiak ez du benetako inplementazioa abiarazten. Horren ordez, zabaldu aurretik berrikusi ditzakezun aldaketen zerrenda sortzen du. Aldaketak aws kontsolaren interfazean ikus ditzakezu. Baina ahal duzun guztia automatizatzea nahiago baduzu, egiaztatu CLI-n:

# 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

Komando honek hurrengoaren antzeko irteera sortu beharko luke:

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

Arreta berezia jarri Ekintza dagoen aldaketei Ordeztu, Ezabatu edo non Ordezpena Beharrezkoa - Egia. Hauek dira aldaketarik arriskutsuenak eta normalean informazioa galtzea eragiten dute.

Aldaketak berrikusi ondoren, zabaldu egin daitezke

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. ikasgaia: Erabili pila-politika egoera baliabideak ordezkatu edo kentzea saihesteko

Batzuetan aldaketak ikustea besterik ez da nahikoa. Denok gizakiak gara eta denok egiten ditugu akatsak. Aldaketa-multzoak erabiltzen hasi ginenetik gutxira, nire taldekideak jakin gabe inplementazio bat egin zuen eta horrek datu-basearen eguneratzea eragin zuen. Ez zen ezer txarrik gertatu proba-ingurune bat zelako.

Gure scriptek aldaketen zerrenda bistaratu eta berrespena eskatu bazuten ere, Ordezkatu aldaketa saltatu egin zen, aldaketen zerrenda hain handia zelako ez zelako pantailan kabitzen. Eta proba-ingurune batean eguneratze normala zenez, ez zitzaien arreta handirik jarri aldaketei.

Inoiz ordezkatu edo kendu nahi ez dituzun baliabideak daude. Egoera osoko zerbitzuak dira, hala nola RDS datu-basearen instantzia bat edo elasticsearch kluster bat, etab. Polita litzateke aws-ek inplementazioa automatikoki uko egitea, egiten ari den eragiketak baliabide hori ezabatzea eskatzen badu. Zorionez, cloudformation-ek modu integratua dauka horretarako. Horri pila-politika deitzen zaio eta horri buruz gehiago irakur dezakezu hemen dokumentazioa:

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. ikasgaia: Erabili UsePreviousValue parametro sekretuekin pila bat eguneratzean

RDS mysql entitate bat sortzen duzunean, AWS-k MasterUsername eta MasterUserPassword bat ematea eskatzen dizu. Iturburu-kodean sekretuak ez gordetzea hobe denez eta dena automatizatu nahi nuenez, "mekanismo adimendun" bat ezarri nuen, non zabaldu aurretik kredentzialak s3-tik lortuko diren, eta kredentzialak aurkitzen ez badira, kredentzial berriak sortzen dira eta s3-n gordeta.

Ondoren, kredentzial hauek parametro gisa pasako dira cloudformation create-change-set komandoari. Scriptarekin esperimentatzen ari zela, s3-rako konexioa galdu zela gertatu zen, eta nire "mekanismo adimendunak" kredentzial berriak sortzeko seinale gisa tratatu zuen.

Produkzioan script hau erabiltzen hasi eta konexio-arazoa berriro gertatuko balitz, pila eguneratuko litzateke kredentzial berriekin. Kasu zehatz honetan, ez da ezer txarrik gertatuko. Hala ere, ikuspegi hau alde batera utzi eta beste bat erabiltzen hasi nintzen, kredentzialak behin bakarrik emanez - pila sortzean. Eta geroago, pila eguneratu behar denean, parametroaren balio sekretua zehaztu beharrean, besterik gabe, erabiliko nuke UsePreviousValue=egia:

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. ikasgaia: Erabili itzuleraratze konfigurazioa

Lan egin nuen beste talde batek funtzioa erabili zuen hodeien eraketa, deitua atzera botatzeko konfigurazioa. Aurretik ez nuen topatu eta azkar konturatu nintzen nire pilak zabaltzea are freskoagoa izango zela. Orain erabiltzen dut nire kodea lambda edo ECSra zabaltzen dudan bakoitzean hodei formazioa erabiliz.

Nola funtzionatzen duen: zehazten duzu CloudWatch alarma parametroan --rollback-konfigurazioaaldaketa-multzo bat sortzen duzunean. Geroago, aldaketa multzo bat exekutatzen duzunean, aws-ek alarma kontrolatzen du gutxienez minutu batez. Inplementazioa atzera egiten du denbora horretan alarma egoera ALARM bihurtzen bada.

Jarraian txantiloiaren zati baten adibidea dago hodeien eraketahorretan sortzen dudan cloudwatch alarma, hodeiko erabiltzaileen metrika baten jarraipena egiten duena hodeiko erregistroetako errore-kopuru gisa (neurria bidez sortzen da 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

Orain alarma gisa erabil daiteke desegin abiarazlea tresna-kutxa exekutatzen denean:

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. ikasgaia: Ziurtatu txantiloiaren azken bertsioa zabaltzen duzula

Erraza da hodeiaren formazio txantiloiaren azken bertsioa baino gutxiago zabaltzea, baina hori egiteak kalte handia eragingo du. Behin gertatu zitzaigun hau: garatzaile batek ez zituen Git-en azken aldaketak bultzatu eta pilaren aurreko bertsio bat zabaldu zuen jakin gabe. Horrek pila hau erabiltzen zuen aplikazioaren geldialdi-denbora eragin zuen.

Adarra eguneratuta dagoen ikusteko egiaztapen bat gehitzea bezain erraza den zerbait ondo legoke (suposatuz git zure bertsioa kontrolatzeko tresna dela):

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. ikasgaia: Ez berriro asmatu gurpila

Horrekin zabaltzea dela dirudi hodeien eraketa - erraza da. Aws cli komandoak exekutatzen dituzten bash script mordoa besterik ez duzu behar.

Duela 4 urte aws cloudformation create-stack komandoa izeneko script sinpleekin hasi nintzen. Laster gidoia ez zen erraza izan. Ikasitako ikasgai bakoitzak gidoia gero eta konplexuagoa egiten zuen. Zaila ez ezik, akatsez betea ere izan zen.

Gaur egun, informatika sail txiki batean lan egiten dut. Esperientziak erakutsi du talde bakoitzak bere modua duela hodei-formazio pilak zabaltzeko. Eta hori txarra da. Hobe litzateke denek planteamendu bera hartuko balute. Zorionez, tresna asko daude eskuragarri hodei-formazio pilak zabaltzen eta konfiguratzen laguntzeko.

Ikasgai hauek akatsak saihesten lagunduko dizute.

Iturria: www.habr.com