Я начал работать с образование облаков 4 года назад. С тех пор я сломал множество инфраструктур, даже тех, которые уже находились в производстве.
Но каждый раз, когда я что-то испортил, я узнавал что-то новое.
Благодаря этому опыту я поделюсь некоторыми из наиболее важных уроков, которые я усвоил.
Урок 1. Тестируйте изменения перед их развертыванием
Я усвоил этот урок вскоре после того, как начал работать с образование облаков .Не помню, что именно я тогда сломал, но точно помню, что использовал команду обновление aws Cloudformation .
Эта команда просто развертывает шаблон без какой-либо проверки изменений, которые будут развернуты.
Я не думаю, что нужно какое-либо объяснение того, почему вам следует тестировать все изменения перед их развертыванием.
После этой неудачи я сразу поменял конвейер развертывания , заменив команду обновления на команду создать-изменить-установить
После создания набора изменений он не оказывает никакого влияния на существующий стек.# 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"
В отличие от команды обновления, подход с набором изменений не запускает фактическое развертывание.
Вместо этого он создает список изменений, который вы можете просмотреть перед развертыванием.
Вы можете просмотреть изменения в интерфейсе консоли aws. Но если вы предпочитаете автоматизировать все, что можете, то проверьте это в 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
Эта команда должна выдать вывод, аналогичный следующему: --------------------------------------------------------------------
| DescribeChangeSet |
+---------+--------------------+----------------------+------------+
| Action | ReplacementNeeded | Resource | ResourceId |
+---------+--------------------+----------------------+------------+
| Modify | True | AWS::ECS::Cluster | MyCluster |
| Replace| True | AWS::RDS::DBInstance| MyDB |
| Add | None | AWS::SNS::Topic | MyTopic |
+---------+--------------------+----------------------+------------+
Обратите особое внимание на изменения, где действие Заменять , Удалить или где Требуется замена — правда .
Это наиболее опасные изменения, которые обычно приводят к потере информации.
После проверки изменений их можно будет развернуть.
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. Используйте политику стека, чтобы предотвратить замену или удаление ресурсов с отслеживанием состояния
Иногда простого просмотра изменений недостаточно.Все мы люди и все совершаем ошибки.
Вскоре после того, как мы начали использовать наборы изменений, мой товарищ по команде по незнанию выполнил развертывание, в результате которого произошло обновление базы данных.
Ничего плохого не произошло, потому что это была тестовая среда.
Несмотря на то, что наши скрипты отображали список изменений и запрашивали подтверждение, изменение «Заменить» было пропущено, поскольку список изменений был настолько большим, что не помещался на экране.
А поскольку это было обычное обновление в среде тестирования, изменениям не было уделено особого внимания.
Есть ресурсы, которые вы никогда не захотите заменять или удалять.
Это сервисы с сохранением состояния, такие как экземпляр базы данных RDS или кластер elasticsearch и т. д. Было бы неплохо, если бы aws автоматически отказывался от развертывания, если выполняемая операция потребует удаления такого ресурса.
К счастью, в Cloudformation есть встроенный способ сделать это.
Это называется политикой стека, и вы можете прочитать больше об этом в документация : 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. Используйте UsePreviousValue при обновлении стека с секретными параметрами
Когда вы создаете объект mysql RDS, AWS требует, чтобы вы указали MasterUsername и MasterUserPassword. Так как секреты в исходном коде лучше не хранить и мне хотелось автоматизировать абсолютно все, я реализовал "умный механизм", где перед развертыванием учетные данные будут получены от s3, и если учетные данные не будут найдены, генерируются новые учетные данные и хранится в s3. Эти учетные данные затем будут переданы в качестве параметров команде Cloudformation create-change-set. Во время экспериментов со скриптом случилось так, что пропало соединение с s3, и мой «умный механизм» воспринял это как сигнал к генерации новых учетных данных.Если бы я начал использовать этот сценарий в рабочей среде и проблема с подключением возникла бы снова, стек обновился бы новыми учетными данными.
В данном конкретном случае ничего страшного не произойдет. Однако я отказался от этого подхода и начал использовать другой, предоставляя учетные данные только один раз — при создании стека.
А позже, когда стек потребует обновления, вместо указания секретного значения параметра я бы просто использовал UsePreviousValue=истина : 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. Используйте конфигурацию отката
Другая команда, с которой я работал, использовала функцию образование облаков , называется конфигурация отката .Я раньше с этим не сталкивался и быстро понял, что это сделает развертывание моих стеков еще круче.
Теперь я использую его каждый раз, когда развертываю свой код в лямбда-версии или ECS с помощью Cloudformation. Как это работает: уточняйте сами Тревога CloudWatch в параметре --rollback-конфигурация когда вы создаете набор изменений.
Позже, когда вы выполните набор изменений, aws будет отслеживать сигнал тревоги в течение как минимум одной минуты.
Он отменяет развертывание, если в течение этого времени сигнал тревоги меняет состояние на ТРЕВОГА.
Ниже приведен пример выдержки из шаблона образование облаков в котором я создаю сигнализация облачных часов , который отслеживает метрику пользователя облака как количество ошибок в журналах облака (метрика генерируется с помощью МетрическийФильтр ): 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
Сейчас тревога может использоваться как откат триггер при выполнении панели инструментов: 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. Убедитесь, что вы развернули последнюю версию шаблона.
Развернуть не самую последнюю версию шаблона Cloudformation несложно, но это нанесет большой ущерб.
Такое случилось с нами однажды: разработчик не загрузил последние изменения из Git и по незнанию развернул предыдущую версию стека.
Это привело к простою приложения, использовавшего этот стек.
Что-то простое, например, добавление проверки актуальности ветки перед ее фиксацией будет в порядке (при условии, что git — ваш инструмент контроля версий): 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: Не изобретайте велосипед
Это может показаться развертыванием с образование облаков - это просто.Вам просто нужна группа bash-скриптов, выполняющих команды aws cli. 4 года назад я начал с простых скриптов, называемых командой aws cloudformation create-stack. Вскоре сценарий уже не был простым.
Каждый извлеченный урок делал сценарий все более и более сложным.
Это было не только сложно, но и полно ошибок.
Сейчас я работаю в небольшом ИТ-отделе.
Опыт показал, что у каждой команды есть свой способ развертывания стеков облачных вычислений.
И это плохо.
Было бы лучше, если бы все придерживались одного и того же подхода.
К счастью, существует множество инструментов, которые помогут вам развернуть и настроить стеки Cloudformation. Эти уроки помогут вам избежать ошибок.
Теги: #программирование #облачные сервисы #aws #CLI #CloudFormation
-
Производитель Этикеток Для Компакт-Дисков
19 Oct, 24 -
Добавление Эффекта Клика В Xamarin.forms
19 Oct, 24 -
Вебпланета Вниз
19 Oct, 24 -
Msbuild — Открытый Исходный Код На Github
19 Oct, 24
