[Перевод] Знакомьтесь: 97 вещей которые должен знать каждый Cloud-инженер01.11.2023 07:45

От переводчика

97 Things Every Cloud Engineer Should Know — это книга, которая объединяет 97 различных статей о облачных вычислениях от IT специалистов. Книга очень хорошо структурирована, и я уверен, что каждый человек найдет в ней что-то полезное для себя. Каждая статья содержит информацию об авторе, его имя, фамилию, должность, фотографию, и обычно занимает около двух или трех страниц книги. Поскольку книгу можно бесплатно и легально установить по ссылке, я перевел несколько статей, которые я считаю наиболее интересными для вас, на русский. Это мой первый опыт перевода технической литературы и поэтому любая критика и указания на ошибки приветствуются!

Оглавление

Раздел 1. Фундаментальные основы

Статья 1. Что такое облако?

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

В Википедии сказано, что облачные вычисления — доступность по требованию к системным компьютерным ресурсам, в частности к хранилищам данных и вычислительным мощностям, без прямого участия в управлении со стороны пользователя. Этот термин в целом используется, чтобы описать центры обработки данных, доступные каждому в интернете.

Если говорить простым языком, облако, по сути, является датацентром, к которому вы имеете доступ в интернете. Однако, рассматривая облако в качестве «чужого датацентра», оно не позволит вам или вашей команде воспользоваться всеми преимуществами, которые оно может вам предложить.

Национальный институт стандартов и технологии (НИСТ) даёт определение облачной модели в публикации «SP 800–145: The NIST Definition of Cloud Computing». Она покрывает основные характеристики облачных вычислений, читается на одном дыхании и потраченное на чтение время обязательно окупится.

НИСТ определяет пять основных характеристик облачной модели:

• Доступность по требованию

  Облачные ресурсы всех видов: вычислительные, хранилища, базы данных, системы оркестрации контейнеризированных приложений, машинное обучение и т.д — доступны нажатием на кнопку или через вызов API. Как Cloud-инженер, вам нет необходимости звать кого-то, открывать тикет или отправлять email, чтобы выделять, получать доступ и конфигурировать ресурсы в облаке.

• Широкий доступ к сети

  Как Cloud-инженер, вы должны быть готовы использовать возможности самообслуживания в облаке, где бы вы не находились. Облако предоставляет авторизированным пользователям доступ к ресурсам по сети, к которой вы можете подключиться, воспользовавшись разными устройствами и интерфейсами. Вы можете иметь возможность перезапустить сервис со своего мобильного телефона, попросить вашего виртуального ассистента развернуть новое тестовое окружение или посмотреть потребление ресурсов и логов сервиса на своём ноутбуке.

• Пул ресурсов

  Облачные провайдеры делают доступными ресурсы множеству клиентам, конечно же с обеспечением безопасности и другими методами защиты! С практической точки зрения, Cloud-инженеру не нужно знать физическую локацию процессора в датацентре. Пуллинг также предоставляет более высокие уровни абстракции. Cloud-инженер может указать требования по вычислительным мощностям и памяти для сервиса, но не может указать какую физическую машину использовать для предоставления ресурсов. Аналогичным образом, Cloud-инженер может указать регион, где должны храниться данные, но это не будет имееть никакого влияния на то, в какой стойке датацентра будет находиться основная база данных.

• Оперативное масштабирование

  Cloud-инженер не должен волноваться по поводу физических возможностей конкретного датацентра. Ресурсы в облаке сконструированы таким образом, чтобы иметь возможность масштабирования для удовлетворения потребностей клиента. Аналогично, когда потребности по ресурсам снижаются, облачные ресурсы сокращаются. Помните, «эластичность» работает в две стороны: как в сторону увеличения, так и в сторону уменьшения. Причиной масштабирования может служить запрос инженера, сделанный в интерфейсе или через вызов API, хотя во многих случаях это происходит автоматический, без человеческого вмешательства.

• Модель Pay-as-you-go

  Одной из концепции облака является то, что вы платите только за то, что используете. Наличие информации о том, сколько ресурсов каждого сервиса вы используете, даёт вам возможность контроллировать расходы, что обычно невозможно в традиционных датацентрах.

Определение НИСТ об облачных вычислениях выходит за рамки вышеописанных характеристик и также определяет способы предоставления облачных ресурсов, такие как инфраструктура как услуга (IaaS), платформа как услуга (PaaS) и программное обеспечение как услуга (SaaS). В публикации института также описываются различные модели развёртывания, включая приватные и публичные.

Не забывайте об этих пяти характеристиках при дальнейшем изучении облаков. Используйте их для того, чтобы понять, используете ли вы все преимущества облаков.

Раздел 2. Архитектура

Статья 17. Узнай в какую сторону масштабироваться

В большинстве случаев, если всё идёт по плану, приложение достигает точки, когда ему необходимо расти. Определение допустимого уровня производительности может быть субъективным. Кто-то, чьи клиенты находятся в Канаде, может не обращать внимания на время ответа в Японии.

Как правило, мы можем улучшить наши системы, воспользовавшись двумя типами масштабирования: вертикальным и горизонтальным. Вертикальное масштабирование предполагает увеличение мощностей уже существующих ресурсов, тогда как горизонтальное подразумевает добавление новых инстансов. Но какой тип масштабирования выбрать?

Вертикальное масштабирование

Вы достигли 100% нагрузки на процессор при 8 ядрах, следом вы увеличиваете количество ядер до 16. Или возможно у вас есть облачное хранилище размером 100Гб и вы его полностью заполнили и теперь увеличиваете его до 500Гб. С этим самым простым способом масштабирования вы запускаете одно и то же приложение, но только на более мощных ресурсах.

Большая часть реляционных баз данных использует вертикальное масштабирование, таким образом гарантируя сохранность данных (атомарность, согласованность, изолированность и долговечность) и поддержку транкзации. Таким образом, для приложении, нуждающихся в согласованном представлении данных, например банковских, обычно используются именно вертикальное масштабирование.

К сожалению, этот тип масштабирования часто приводит к задержкам. Если вам некуда перенаправить запросы пользователей во время обновления мощностей, им придётся ждать, пока обновление не завершится. Имейте в виду, что такое масштабирование не «резиновое» и с каждым увеличением становится дороже.

Горизонтальное масштабирование

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

Если ваше приложение полагается на данные, то вам, скорее всего, стоит задуматься над тем, чтобы изменить этот подход для использования горизонтального масштабирования. NoSQL базы данных могут масштабироваться путём добавления новых инстансов, потому что они предлагают меньшую согласованность; в течение обновления, не валидные данные могут быть восстановлены. Также вам понадобится воспользоваться одним из способов распределения трафика между вашими инстансами. Приложение может принимать трафик напрямую или же может быть использован балансировщик нагрузки, который служит для распределения всего трафика между запущенными инстансами.

Продуманная балансировка нагрузки также должна приносить надёжность и позволять вносить изменения без задержек, так как при распределениях нагрузки балансировщик должен избегать недоступных инстансов. Множество политик может быть применено, чтобы сделать распределение трафика более продуманным. Например, если вы пытаетесь принимать запросы от людей из разных концов земли, вы можете столкнуться с тем, что время ответа сервера для некоторых пользователей может занимать очень много времени. Чтобы решить данную проблему, вы можете добавить больше инстансов в разных регионах, а также не забыть про балансировщика нагрузки, который будет перенаправлять запросы пользователей к ближайшему доступному серверу.

Если вы хотите улучшить время ответа статического контента (например, HTML страниц), воспользуйтесь специализированным сервисом, который называется CDN (Content Delivery Network). CDN распределяет ваш контент по глобальной сети серверов и направляет каждого конечного пользователя к оптимальному серверу. Использовать готовое решение в виде CDN гораздо проще, чем пытаться создать такую сеть самостоятельно.

Заключение

Подводя всё вышеописанное, выбор стратегии масштабирования зависит от ваших системных требований. Как правило, вертикальное масштабирование проще для управления и отлично подходит для приложения, требующего атомарность и согласованность данных. С другой стороны, увеличение мощностей сервера может быть дорогим и также приводить к задержкам. Горизонтальное масштабирование не ограничено ничем (кроме как ресурсами датацентра) и обеспечивает надёжность, но настраивать и управлять этим типом масштабирования намного сложнее.

Раздел 4. Безопасность и соблюдение требований

Статья 34. Относитесь к облачному окружению также, как если бы вы использовали On-premise решение

В нашей отрасли существует поговорка: «Облако — это просто чей-то компьютер.»

Однако если вы храните приватную информацию и пользовательские данные в облачных окружениях, должны ли обращаться с ним так же, как если бы это был компьютер постороннего человека? Cloud-инженеры управляют данными в облаке, но что может произойти, если эти данные не защищены?

Исследование 2019 года, проведенное компанией Proofpoint, выяснило, что 92% из 500 облачных аккаунтов компании Fortune 500 (топ 500 крупнейших компаний США по размеру выручки) были атакованы. Этих атаки могло было бы и не быть, если бы эти самые компании нашли время для защиты своих облачных окружений, как если бы они использовали собственные ресурсы (On-premise).

Ниже приведен список мер предосторожности, которые необходимо предпринять для того, чтобы обеспечить безопасное управление в облачных окружениях:

• Когда вы конфигурируете облачную инфраструктуру, первым о чем стоит задуматься для защиты это шифрование данных. Чтобы сделать доступным передачу трафика через HTTPS и SSH, необходимо получить SSL/TLS сертификат и учетные данные пользователя. Помимо этого, убедитесь, что firewall сконфигурирован с входящими правилами для такого трафика и каждый сервер в облаке имеет свои собственные данные для входа.

• Проверьте, что данные для входа от облачных аккаунтов нигде не указаны в открытом виде, включая публичные и приватные Git репозиторий. Также не забывайте, что пользовательские данные должны меняться часто. Возможно, что ваш облачный провайдер имеет сервис для управления криптографическими ключами (KMS), который централизованно хранит и занимается ротацией учетных данных для ваших серверов.

• Каждый сервис, доступный по сети (веб-сервер, СУБД, email сервер) должен быть запущен на своём собственном сервере. Это затруднит злоумышленникам доступ ко всем ресурсам.

• Как бы это не было утомительным, используйте двухфакторную аутентификацию (2FA) при входе с любого устройства. Это может помочь предотвратить проникновение третьих лиц в ваш облачный аккаунт, только если злоумышленник не заполучит доступ над вашим мобильным устройством.

• Измените стандартные конфигурационные файлы и порты для ваших сервисов. Если вы используете стандартную конфигурацию, ваше окружение в опасности, потому что злоумышленники будут знать в какую сторону смотреть, как только им удастся заполучить доступ к облачному аккаунту. Сделайте их жизнь немного сложнее и оставьте директорию /var/www/html пустой.

• Используйте облачные сервисы для мониторинга и логирования, чтобы они уведомляли вас в случае обнаружения подозрительной активности. Постарайтесь покрыть ими как можно больше компонентов: сервера, облачный VPN, файловые облачные хранилища и так далее. Если атака всё же была совершена на ваше окружение, логирование поможет вам определить какие компоненты были целью.

• Хотя это и не кажется таковым, но поддержание доступности ресурсов является одной из практик обеспечения безопасности. Злоумышленник может не стремиться проникнуть в вашу облачную среду, но вполне возможно, что его цель — помешать вашему приложению обрабатывать запросы от пользователей, путём DDoS атаки. Конфигурация балансировщика нагрузки и Firewall-а для веб-приложении (WAF) может помочь вашему окружению в борьбе с DDoS-атаками.

• Напоследок, часто используйте резервное копирование. В том случае, если злоумышленник проникнет в ваш аккаунт и удалит все данные (или, что ещё хуже, если вы или кто-то из сотрудников нажмёт «не туда»), вам понадобится копия, чтобы всё восстановить. Не важно, храните ли вы резервные копии на съемных носителях или используете решение от облачного провайдера. Этот шаг является важнейшей частью защиты ваших данных.

Конечно, вы не обязаны следовать всем вышеперечисленным советам. Вместо этого вы можете продолжать облегчать работу облачных тестировщиков на проникновение, например мне. :)

Раздел 6. Разработка программного обеспечения

Статья 67. Управление исходным кодом для разработки ПО

Управление исходным кодом (SCM), также известное как контроль версии, позволяет разработчикам управлять собственным кодом. SCM имеет ряд преимуществ для разработчиков, так как они работают в разных частях кода, взаимодействуют между собой и выпускают новые версии продукта. При правильном подходе, SCM позволяет командам разработчиков создавать приложения, избегая при этом необратимых последствии при работе с кодом.

Про контроль версиями простым языком

SCM инструменты обеспечивают контроль версии для отката, отслеживания и исправления программного кода. Рассматривайте контроль версиями как временную шкалу изменений в коде. В самом примитивном варианте работы системы контроля версиями, у вас есть ветка main. Эту ветку называют основной.

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

Ключевой концепцией является использование веток, которые отходят от основной (main) ветки. Обычно для каждого нового функционала создается отдельная ветка.

Например, представим разработчика, работающего над функционалом продукта для версии 1.0 своего продукта. Он хочет разрабатывать и вносить изменения в кодовую базу, не затрагивая main ветку. Другие разработчики зависят от main ветки, так как она является самой актуальной. Разработчик делает коммит и вносит свои изменения в другую ветку. Эта ветка берёт своё начало от основной. Когда функционал будет готов, разработчик может слить (сделать merge) свою ветку с изменениями обратно в ветку main.

Самая главная практика использования систем управления версиями заключается в том, чтобы всегда поддерживать основную ветку в чистоте. Ветка main является веткой по умолчанию. Кто бы не клонировал ваш репозиторий, он не должен переключаться на другие ветки, чтобы запустить приложение на своём устройстве.

Также распространённая практика помечать версии кода тегами в основной ветке. Эти теги указывают на конкретные релизы продукта, например «stable 1.0» или «beta». Любой человек, имеющий доступ к вашему репозиторию, может соотнести метку с версией кодовой базы.

Система управления исходным кодом хранит информацию о том, кто, где и когда внёс изменения в код. Помимо этого, она также позволяет разработчикам сравнивать код из разных коммитов или веток.

Что такое Git?

Git — это популярный инструмент для управления исходным кодом. Стратегии использования Git, такие, как git-flow, возникшие для контроля версиями, стали практикой для разработки ПО. Однако, Git стратегии не являются универсальным решением для каждого.

Поддерживать и адаптировать определенные методы работы может быть весьма непростым. Например, git-flow может не подойти высокопроизводительным командам, новые версии которых должны выходить быстро и часто. Это связано с тем, что модель Pull Requst-ов добавляет требование для одобрения сливания изменении в main ветку. Это добавляет дополнительное требование для выпуска новых релизов. Однако, как видно на примере открытого исходного кода, git-flow является отличной стратегией разветвления для управления крупными проектами с большим количеством участников.

Но системы управления исходным кодом не ограничиваются использованием ветвления. Они не отрицают лучшие практики для разработки ПО. Вот некоторые рекомендации при работе с SCM:

• Определите основные нюансы при использовании SCM в работе с командой.

  Как часто нужно выпускать новые версии продукта? Разрабатываете ли вы продукт с нуля? Высок ли процент неудачных изменений?

• Имейте определённые правила для SCM.

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

• Определите, что будет храниться в репозиториях.

  Где вам следует хранить конфигурацию для рабочего окружения? А файлы для IaC (инфраструктуры как код)? Найдите такую структуру, которая будет отлично работать в вашей экосистеме.

• Рассмотрите возможность интеграции SCM инструмента с процессом доставки (CD) программного обеспечения

  Коммиты в репозитории могут быть отличным способом для запуска CI/CD пайплайна, который также может помечать релизы тегами для версионирования.

Основным компонентом повышения эффективности является работа с другими людьми в команде. SCM обеспечивает эффективное редактирование и версионирование кода.

Раздел 8. Автоматизация

Статья 78. Относитесь к своей инфраструктуре как к ПО

Инфраструктура имеет большое значение. Инфраструктура и код приложения одинаково важны для успешной работы Cloud-инженера. Большинство инженеров либо сразу выбирают подходящую среду выполнения (runtime), либо перебирают несколько, пока не найдут то, что нужно для их приложения. Очень важно выбрать подходящую среду выполнения, исходя из того как вы выделяете и развёртываете в вашей инфраструктуре. Большинство Cloud-инженеров обожают проектировать, разрабатывать и разворачивать приложения. Отчеты об ошибках, отладка, логирование и алертинг, как правило, легко настраиваются при работе в популярных облачных платформах или при использовании распространённых наборов инструментов.

Одним из главных преимуществ работы в облаке является наличие множества управляемых сервисов (Managed Services) и инструментов для решения вышеописанных задач. Облако это здорово! Однако у этой медали есть две стороны. Управляемые сервисы легко запустить, при этом они также могут быть случайно удалены. Управляемую базу данных или функцию, запущенную на бессерверных (Serverless) вычислениях, можно случайно отключить. А если разворачивать эти ресурсы вручную или с помощью shell скриптов, то это может негативно сказаться на работе этих самых сервисов, добавляя сложность и простой. А простой никому не нужен.

Использование управляемых сервисов является отличным решением. Отношение к таким сервисам как к инфраструктуре и их определение с использованием декларативных инструментов является более удачной стратегией. Используйте подход IaC (инфраструктура как код) для управления инфраструктурой путем использования конфигурационных файлов, храните их в системе управления версиями и проверяйте содержимое этих файлов перед внесением реальных изменений в инфраструктуру. Это спасёт вас от длительных простоев и лишней головной боли.

Существует множество различных IaC паттернов и инструментов. Самой простой формой использования IaC является использование shell скриптов для создания вашей инфраструктуры. Этот метод не является оптимальным. Использование скриптов для создания инфраструктуры является императивным и сводит на нет параллельное выполнение сразу несколькими людьми и управление зависимостями. Это просто скриптовая версия ручного развёртывания. Поддержка и отладка таких скриптов приводят к большому количеству проблем. Чтобы избежать потенциальных сложностей, мы может использовать более гибкие, декларативные IaC инструменты и подходы.

Как правило, у каждого популярного публичного облака есть собственные инструменты для IaC. Amazon предоставляет AWS CloudFormation, у Google есть Cloud Deployment Manager, а Microsoft открывает доступ к Azure Resource Manager. Эти инструменты обладают различной степенью декларативности, но все они работают только в соответствующих им публичных облаках. В настоящее время в нашей индустрии отмечается широкое применение мультиоблачных и гибридных подходов при работе с облаками, что делает применение вышеперечисленных инструментов, связанных с IaC, совсем не тем направлением, которое мы, SRE-инженеры, хотели бы развивать.

Хорошая инфраструктура как код использует возможность для сравнения вашего кода (желаемого состояния) с текущим состоянием. Такие инструменты, как Terraform, дают такую возможность сравнения, а затем также предоставляют готовый план исправления текущего состояния в соответствие с желаемым. Автоматизация устранения проблем при помощи инструментов IaC — это суперспособность в руках Cloud-инженеров. Они эффективно проектируют и развёртывают инфраструктуру, а также устраняют возникающие неполадки. Таких инженеров можно считать надёжными и способными выполнить поставленные задачи.

© Habrahabr.ru