elkezdtem dolgozni felhőképződés 4 évvel ezelőtt. Azóta sok infrastruktúrát feltörtem, még azokat is, amelyek már gyártásban voltak. De valahányszor elrontottam valamit, tanultam valami újat. Ezen a tapasztalaton keresztül megosztom a legfontosabb leckéket, amelyeket megtanultam.
1. lecke: Tesztelje a változtatásokat a telepítés előtt
Nem sokkal azután tanultam meg ezt a leckét, hogy elkezdtem vele dolgozni felhőképződés. Nem emlékszem, hogy akkor pontosan mit rontottam el, de arra határozottan emlékszem, hogy használtam a parancsot aws cloudformation frissítés. Ez a parancs egyszerűen kiadja a sablont a telepítendő változtatások ellenőrzése nélkül. Nem hiszem, hogy szükség lenne magyarázatra arra, hogy miért kell minden változtatást tesztelni a telepítés előtt.
E kudarc után azonnal megváltoztam telepítési csővezeték, az update parancsot a paranccsal helyettesítve létrehozás-változtatás-készlet
# 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"
A módosításkészlet létrehozása után nincs hatással a meglévő veremre. A frissítési paranccsal ellentétben a Changeset megközelítés nem váltja ki a tényleges telepítést. Ehelyett létrehoz egy listát a módosításokról, amelyeket áttekinthet a telepítés előtt. A változásokat az aws konzol felületén tekintheti meg. De ha inkább mindent automatizál, amit csak lehet, akkor ellenőrizze őket a CLI-ben:
# 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 tableEnnek a parancsnak a következőhöz hasonló kimenetet kell produkálnia:
--------------------------------------------------------------------
| DescribeChangeSet |
+---------+--------------------+----------------------+------------+
| Action | ReplacementNeeded | Resource | ResourceId |
+---------+--------------------+----------------------+------------+
| Modify | True | AWS::ECS::Cluster | MyCluster |
| Replace| True | AWS::RDS::DBInstance| MyDB |
| Add | None | AWS::SNS::Topic | MyTopic |
+---------+--------------------+----------------------+------------+Fordítson különös figyelmet azokra a változásokra, ahol az Action van Cserélje, töröl vagy hol ReplacementNeeded – igaz. Ezek a legveszélyesebb változások, és általában információvesztéshez vezetnek.
A változtatások áttekintése után telepíthetők
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. lecke: Használjon veremházirendet, hogy megakadályozza az állapotalapú erőforrások lecserélését vagy eltávolítását
Néha nem elég csupán a változások megtekintése. Mindannyian emberek vagyunk, és mindannyian követünk el hibákat. Röviddel azután, hogy elkezdtük használni a changeseteket, csapattársam tudtán kívül hajtott végre egy központi telepítést, amely adatbázis frissítést eredményezett. Semmi rossz nem történt, mert ez egy tesztkörnyezet volt.
Annak ellenére, hogy szkriptjeink megjelenítették a módosítások listáját, és megerősítést kértek, a Csere módosítás kimaradt, mert a változtatások listája olyan nagy volt, hogy nem fért el a képernyőn. És mivel ez egy tesztkörnyezetben szokásos frissítés volt, nem sok figyelmet fordítottak a változtatásokra.
Vannak olyan források, amelyeket soha nem szeretne lecserélni vagy eltávolítani. Ezek állapotteljes szolgáltatások, például egy RDS-adatbázispéldány vagy egy elaszticsearch-fürt stb. Jó lenne, ha az aws automatikusan visszautasítaná a telepítést, ha a végrehajtott művelet egy ilyen erőforrás törlését igényelné. Szerencsére a felhőformálásnak beépített módja van ennek. Ezt veremházirendnek hívják, és bővebben itt olvashat :
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. lecke: Használja a UsePreviousValue értéket a verem titkos paraméterekkel történő frissítéséhez
Amikor létrehoz egy RDS mysql entitást, az AWS megköveteli a MasterUsername és a MasterUserPassword megadását. Mivel jobb nem titkolózni a forráskódban, és abszolút mindent automatizálni akartam, bevezettem egy "okos mechanizmust", ahol a telepítés előtt az s3-ból megkapják a hitelesítési adatokat, és ha nem találhatók meg a hitelesítő adatok, akkor új hitelesítő adatok generálódnak és s3-ban tárolva.
Ezek a hitelesítő adatok ezután paraméterként kerülnek átadásra a cloudformation create-change-set parancsnak. A szkripttel való kísérletezés során előfordult, hogy megszakadt a kapcsolat az s3-mal, és az „okos mechanizmusom” azt jelként kezelte, hogy új hitelesítő adatokat generáljon.
Ha elkezdem használni ezt a szkriptet éles környezetben, és a kapcsolódási probléma ismét megismétlődik, akkor az új hitelesítő adatokkal frissítené a veremet. Ebben a konkrét esetben semmi rossz nem fog történni. Azonban felhagytam ezzel a megközelítéssel, és egy másikat kezdtem használni, amely csak egyszer adtam meg a hitelesítő adatokat - a verem létrehozásakor. És később, amikor a verem frissítésre szorul, a paraméter titkos értékének megadása helyett egyszerűen a 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. lecke: Használja a visszaállítási konfigurációt
Egy másik csapat, akivel dolgoztam, használta a funkciót felhőképződéshívott visszaállítási konfiguráció. Korábban nem találkoztam vele, és hamar rájöttem, hogy így még menőbb lesz a veremek telepítése. Mostantól minden alkalommal használom, amikor a kódomat lambda- vagy ECS-rendszerbe helyezem felhőformálás segítségével.
Hogyan működik: megadod CloudWatch riasztás arn paraméterben --rollback-configurationváltozáskészlet létrehozásakor. Később, amikor végrehajtja a módosításokat, az aws legalább egy percig figyeli a riasztást. Visszaállítja a telepítést, ha ezalatt a riasztás állapota ALARM-ra változik.
Az alábbiakban egy példa egy sablonrészletre látható felhőképződésamelyben létrehozom cloudwatch riasztó, amely egy felhő-felhasználói metrikát követ nyomon a felhőnaplókban lévő hibák számaként (a mérőszámot 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: yesMost riasztás mint rollback trigger az eszköztár végrehajtásakor:
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. lecke: Ügyeljen arra, hogy telepítse a sablon legújabb verzióját
Könnyű telepíteni a felhőformálási sablon legfrissebb verzióját, de ez sok kárt okoz. Ez egyszer megtörtént velünk: egy fejlesztő nem nyomta le a Git legújabb módosításait, és tudtán kívül telepítette a verem egy korábbi verzióját. Ez leállást eredményezett az ezt a veremet használó alkalmazásban.
Valami olyan egyszerű, mint egy ellenőrzés hozzáadása, hogy megbizonyosodjon arról, hogy az ág naprakész-e, mielőtt elkötelezné magát (feltéve, hogy a git a verzióvezérlő eszköz):
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
fi6. lecke: Ne találd fel újra a kereket
Úgy tűnhet, mint a telepítés felhőképződés - könnyű. Csak egy csomó bash szkriptre van szüksége az aws cli parancsok végrehajtásához.
4 évvel ezelőtt az aws cloudformation create-stack parancsnak nevezett egyszerű szkriptekkel kezdtem. Hamarosan a forgatókönyv már nem volt egyszerű. Minden egyes tanulság egyre bonyolultabbá tette a forgatókönyvet. Nem csak nehéz volt, de tele is volt hibákkal.
Jelenleg egy kis informatikai osztályon dolgozom. A tapasztalat azt mutatja, hogy minden csapatnak megvan a maga módja a felhőformálási veremek telepítésére. És ez rossz. Jobb lenne, ha mindenki ugyanazt a megközelítést alkalmazná. Szerencsére számos eszköz áll rendelkezésre a felhőformálási veremek telepítéséhez és konfigurálásához.
Ezek a leckék segítenek elkerülni a hibákat.
Forrás: will.com