Процесс развертывания и управления облачной инфраструктурой может осуществляться в одном из двух режимов. Инфраструктура может быть развернута либо с помощью интерактивных опций, называемых на слэнге ClickOps, либо с помощью какой-либо формы автоматизации. ClickOps — это способ ручной подготовки ресурсов на основе пользовательского интерфейса. Это означает, что у всего есть графический пользовательский интерфейс, через который вы можете изучить доступные сервисы и вручную кликнуть по консоли для предоставления инфраструктуры.

Но зачем развертывать ресурсы в облаке с помощью ClickOps?

Для начала, это самый простой способ начать работу в облаке. Кроме того, по большей части это процесс без участия кода. То есть вам не нужно писать код для развертывания ваших сервисов.

Несмотря на эти преимущества, у ClickOps есть серьёзные недостатки, и вот некоторые из них:

• Это ручной процесс.
• Он уязвим к ошибкам, потому что вручную выполнить ряд задач без ошибок сложнее.
• Вы не можете отследить, что сделали другие — нет контроля версий, нет процесса аудита.
• Если вам нужно повторно выделить ресурс, выполнение аварийного восстановления займёт много времени. Например, если у вас есть 50 узлов и что-то пойдёт не так, вам придётся исправлять их по одному.

DevOps спешит на помощь!

Давным-давно в далекой галактике традиционная разработка программного обеспечения велась между двумя разными командами — командой разработчиков и операционной командой. Обе команды держались особняком и преследовали разные, а иногда и противоположные цели. Разработчики были заинтересованы в создании контента, в то время как операционная группа больше беспокоилась о стабильности и надёжности. Гибкая методология привела к появлению DevOps. DevOps объединяет когда-то разделенные, а иногда и конфликтующие группы, тем самым устраняя эту проблему путаницы между ними. Существует старый спор о том, является ли DevOps культурой или функцией, но для целей этой статьи я ограничусь тем, как DevOps видит AWS.

DevOps — это сочетание культурных принципов, практик и инструментов, которые повышают способность организации предоставлять приложения и услуги с высокой скоростью: разработка и улучшение продуктов происходит быстрее, чем в организациях, использующих традиционные процессы разработки программного обеспечения и управления инфраструктурой.

Каковы некоторые преимущества DevOps?

• Это более быстрая стратегия развертывания — DevOps увеличивает частоту и скорость выпуска продуктов.
• Улучшается качество продукта — более тесная совместная работа между командами разработки и эксплуатации, а также обратная связь от конечных пользователей приводит к созданию более качественных продуктов.
• Масштабирование — с помощью DevOps вы можете управлять своей инфраструктурой и процессом разработки в любом масштабе.
• Снижение затрат — поскольку техническое обслуживание и новые обновления объединяются, снижаются затраты на управление и производство.
• Надежность — DevOps обеспечивает качество обновлений приложений и изменений инфраструктуры, поэтому вы можете стабильно удерживать более быстрые темпы, сохраняя при этом положительный опыт для клиентов.

Ответы на общие вопросы

По мере того, как все больше компаний используют гибкую методологию, DevOps (и другие позиции) будут по-прежнему играть ключевую роль в облачном пространстве и технологиях в целом.

За что именно отвечают инженеры DevOps?

Инженеры DevOps отвечают за инфраструктуру. Инфраструктура здесь означает не традиционный офис, а аппаратное и программное обеспечение, на котором работают продукты и приложения. Инженеры DevOps несут ответственность за упреждающую автоматизацию и обслуживание инфраструктуры, что помогает сократить затраты времени и средств на ClickOps, о которых мы говорили ранее.

Еще один вопрос, который часто задают, — нужно ли программировать DevOps инженерам?

Классический ответ инженера — по ситуации. Здесь случаются жаркие отраслевые дебаты, и все зависит от среды и структуры команды. Часто встречаются рабочие процессы, включающие и ClickOps, и сценарии или создание целой платформы.

Автоматизация скучных задач

Большая часть DevOps связана с автоматизацией, а не с ручным предоставлением облачной инфраструктуры. Поэтому возникает вопрос: «Почему важна автоматизация?».

• Автоматизация исключает человеческие ошибки. Это означает, что существует низкий риск неправильной настройки.
• Вы можете создавать новые среды буквально по запросу.
• Легче проводить коллегиальную проверку с новыми членами команды. Гораздо проще просмотреть чей-то общий код, чем наблюдать через плечо, когда он вносит изменения в пользовательский интерфейс.
• Это позволяет организациям быстро масштабироваться без лишней ручной работы. Например, разница между подготовкой 1 экземпляра и 1000 экземпляров заключается лишь в изменении значения счётчика.

Жизненный цикл разработки программного обеспечения (SDLC) и жизненный цикл инфраструктуры (ILC)

Жизненный цикл разработки программного обеспечения — это сквозной жизненный цикл программного обеспечения. Он разбит на шесть этапов анализа, проектирования, разработки, тестирования, развертывания и обслуживания. Распространёнными инструментами, используемыми в SDLC, являются Git, CI/CD, Linters и Jira.

ILC почти такой же, как SDLC, за исключением того, что ориентирована на вашу инфраструктуру. В жизненном цикле инфраструктуры мы видим бесконечный цикл непрерывного совершенствования. Распространёнными инструментами для жизненного цикла инфраструктуры являются инфраструктура как код, управление конфигурацией, GitOps и CI/CD.

Инфраструктура как код (IaC)

IaC — это метод, который мы могли бы использовать для автоматизации подготовки и развёртывания облачной инфраструктуры с помощью сценариев. Инструменты IaC обычно настраиваются с использованием YAML, JSON, языка конфигурации HarshiCorp. Для AWS три важных инструмента инфраструктуры как кода — это CloudFormation, Cloud Development Kit (CDK) и Terraform.

Вот код YAML, с помощью которого вы можете развернуть инстанс Amazon EC2 с помощью CloudFormation.

AWSTemplateFormatVersion: 2010-09-09
Resources:
  myInstance:
    Type: AWS::EC2::Instance
    Properties:
      # You'll have to grab the image ID for the EC2 intsance for your preferred region
      #This image ID is for Canada central-1 for Amazon Linux 2
      ImageId: ami-01d29fca5bdf8f4b4
      #You'll need to grab the default security group ID in your AWS account
      SecurityGroupIds: ["sg-0c8ba2b706e2581e0"]
      #You'll need to grab a subnetID in the default security group's associated VPC
      SubnetId: subnet-0a6311ab0cdf8fa1b
      InstanceType: t2.micro

Советы и рекомендации CloudFormation для YAML

• Отступ должен быть точно правильным.
• Проверьте синтаксис YAML перед развёртыванием — это можно сделать в конструкторе шаблонов CloudFormation.
• Ссылка на документацию AWS.
• Определите, какие свойства необходимы.
• Идентификаторы и значения ссылок на ресурсы AWS в вашей консоли AWS.
• Проверьте зону доступности, из которой вы собираетесь развертывать ресурсы (AMI различается в зависимости от зоны доступности. Например, чтобы развернуть экземпляр EC2 в us-east-1, вы должны использовать AMI из us-east-1. Вы гарантированно получите откат, если вы используете AMI из другой зоны доступности).
• Если вы получаете откат/ошибку, посмотрите на вкладку «События» в CloudFormation, чтобы узнать, что пошло не так.
• Если справка об ошибке в CloudFormation недостаточно информативна, вы можете открыть CloudTrail, чтобы получить дополнительные подсказки.