Author: admin

В этой статье хочу кратко рассказать о том, как захостить свою веб-аппликацию на CDN от Amazon. Это может быть интересно всем, кто хочет улучшить доступ к своему ресурсу, а именно ускорить загрузку статического контента пользователями.

Часто оптимальным решением является использование сети Распространения Контента (CDN). Статическим контентом здесь может быть как побеленная JavaScript Аппликация (React или Angular), так и изображение или статический HTML. В этой статье будем оперировать AWS S3 (для хранения и хостинга), CloudFront (как CDN) и функционалом DNS-провайдера (может быть любой), в нашем случае это CloudFlare. Будем использовать TLS/SSL сертификат от Cloudflare для того, чтобы ресурс работал на HTTPS (с поддержкой Cloudflare «Full Strict» режима).

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

Здесь не будем рассматривать создание и билд JS аппликации, создание S3 бакета (или «ведра» на украинском языке), заливку контента в бакет или регистрации DNS-домена.

HTTP на S3

Итак, создаем S3 бакет и заливаем сбилденный код туда, в корень. Однако здесь есть нюанс – ограничение от Amazon: бакет должен иметь имя такое же, как домен (поддомен). К примеру,
если планируется разместить билд на домене my . react-app . com, то и название бакета должно быть my . react-app . com.

Далее в свойствах бакета (вкладка Properties) следует включить Static website hosting. Ниже, в поле Index Document, необходимо указать index файл (index.html обычно).

Сохраняем настройки и переходим к вкладке доступа (Permissions).

Здесь нам нужно отключить блокировку доступов, если она активна (Block public access).

В Bucket Policy (Политика доступа) нам нужно предоставить доступ для CloudFront. Чтобы упростить задачу, предоставим доступ ко всем сервисам AWS (потом это можно перенастроить).

В поле для JSON нужно скопировать следующее:

 { 
    "Version" :  "2012-10-17" , 
    "Id" :  "Policy1638279142165" , 
    "Statement" :  [ 
        { 
            "Sid" :  "Statement1" , 
            "Effect" :  "Allow" , 
            "Principal" :  { 
                "AWS " :  "*" 
            } , 
            "Action" :  "s3:GetObject" , 
            "Resource" :  "arn:aws:s3:::my.react-app.com/*" 
        } 
    ] 
}

где в строке “Resource”: “arn:aws:s3:::my” . react-app . com/*»
« my . react-app . com» нужно заменить именем этого бакета.

Сохраняем настройки и стараемся получить доступ к аппликации через HTTP. Для этого на вкладке свойств бакета (Properties) в поле Static website hosting переходим по ссылке, указанной под пунктом «Bucket website endpoint».

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

SSL/TLS сертификат

Чтобы ресурс работал через HTTPS, нужно использовать сертификат, сгенерированный для требуемого домена. Если на AWS уже есть сертификат (например, если домен на Route 53), этот шаг можно пропустить.

Для менеджмента сертификатов в AWS есть сервис Certificate Manager (ACM). Заходим туда и выбираем опцию запроса сертификата (Request certificate). Далее выбираем опцию публичного сертификата (Request a public certificate).

Здесь есть первый нюанс: для того чтобы сертификат можно было использовать в Cloudfront, его нужно добавлять именно в зоне доступности «N.Virginia» (us-east-1), что совсем не интуитивно.

Там заполняем название домена:

И способ валидации:

Выбираем DNS-валидацию, ведь именно этот способ рекомендован. Нажмите Request, чтобы создать запрос на получение сертификата.

После этого сертификат появится в списке сертификатов со статусом «Ожидающий валидации» (Pending validation). Чтобы валидировать его, нужно создать DNS-запись согласно сгенерированным значениям:

Мы подтвердили принадлежность текущего ресурса к указанному домену (а значит и сертификату).

Итак, добавляем соответствующую CNAME запись в DNS (в нашем случае в Cloudflare):

Через некоторое время наш сертификат будет валидирован и получит статус «Issued».

Cloudfront

Cloudfront – это CDN сервис от Amazon, который с помощью глобально распределенных прокси-серверов кэширует контент, у нас – составляющие аппликации. Поэтому нам нужно настроить дистрибутив для распределения с источником данных в созданное S3 ведро (bucket).

В Distributions выбираем Create и заполняем Origin domain.

Здесь еще один совсем не интуитивный момент: когда мы будем вводить название бакета, нам подтянется наш S3 ресурс. Однако это не то, что нам нужно.
В это поле нужно вставить URL, по которому мы раньше через HTTP имели доступ к нашему бакету. Чтобы его получить, идем в «Свойства» нашего бакета (Bucket Properties) и копируем адрес с поля website endpoint. Вставляем его без http:// и без слеша в конце.

К примеру, в нашем случае, в поле Origin domain при создании дистрибутива у нас будет подсказка:

« my . react-app . com . s3 . amazonaws . com » (заканчивается «s3 . amazonaws . com»)

а нужно:
« my . react-app . com . s3-website-eu-west-1 . amazonaws . com»

Далее ищем поле Alternate domain name . Здесь нужно указать домен (название бакета), например my . react-app . com .

И выбрать созданный сертификат.

Все остальные поля оставляем без изменений и создаем дистрибутив.

Сначала дистрибутив получит статус deploying, и когда станет готовым к использованию, статус изменится на Enabled.

На этом этапе наш ресурс должен быть доступен через нужный HTTPS на CDN Amazon. Чтобы убедиться в этом, нужно перейти на URL, указанный в деталях нового дистрибутива:

Финальный штрих

Теперь, чтобы данная аппликация работала под нашим доменом, нужно создать соответствующую DNS запись, в которой мы впишем, что за контентом для указанного домена следует обратиться к настроенному выше дистрибутиву Cloudfront ( Distribution domain name ). Поскольку дистрибутив доступен по URL, используем ту же запись CNAME.

Чтобы DNS запись вступила в действие, нужно определенное время.

DNS-провайдер Cloudflare

Если все прошло хорошо, и все остальные DNS записи отвечают требованиям end-to-end HTTPS шифрования, можно включить режим «Full (strict)».

Index файл не найден

Если на каком-то этапе вместо приложения открывается XML с перечнем файлов в ведре, то вероятно, что cloudfront не знает, какой индекс файл использовать. Чтобы исправить это, можно настроить путь к индексу файла (Origin path) в Cloudfront дистрибутиве.

По прогнозам Gartner , в 2022 году расходы на корпоративные облака в мире составят $331,2 миллиарда. Облачные сервисы – один из наиболее динамичных мировых IT-рынков. Бизнес хочет быть гибким, мобильным и более эффективным, поэтому больше не хочет строить собственные дата-центры и заниматься их обслуживанием. Он выбирает облачные услуги.

Что такое облачные сервисы

Облачные сервисы – это платформы и программы, которые “живут” и работают на серверах специальных компаний – облачных провайдеров. Эти программы не нужно устанавливать на компьютер, а доступ к ним можно получить из любой точки мира. Dropbox, Google Drive, iCloud – все мы давно пользуемся этими и похожими продуктами, даже не осознавая, что они расположены в облаках. Нет смысла держать файлы на собственном компьютере, гораздо проще хранить данные и работать с ними на удобных и защищенных облачных платформах.

Та же ситуация и с бизнесом. 1С в облаке более удобно, чем 1С на собственном сервере, который может сломаться, подхватить вирус или просто устареть. Если держать интернет-магазин в облаке, а не на собственном сервере, в день “черной пятницы” можно просто забронировать у облачного провайдера дополнительное место и не беспокоиться о том, что все “ляжет”. Переход бизнеса в облако помогает решить массу проблем, связанных с управлением сложной ИТ-инфраструктурой.

Какими они бывают

Ключевые облачные услуги можно представить в виде пирамиды. На самом низком уровне находится IaaS (Infrastructure-as-a-Service) – это серверы, хранилища, сети, вычислительная инфраструктура, которую облачный провайдер предоставляет для использования. Условно говоря, это просто пустой склад в аренду. Примеры IaaS – IBM Softlayer, Hetzner Cloud, Amazon EC2.

На среднем уровне размещается PaaS (Platform-as-a-Service) — платформа для самостоятельной разработки и развертывания приложений. Это уже склад со стеллажами и техникой для погрузки его товаром. Примеры PaaS: Google App Engine, IBM Bluemix, Microsoft Azure, VMWare Cloud Foundry.

И на самом высоком – SaaS (Software-as-a-Service), которую составляют готовые облачные приложения с доступом через веб-интерфейс. Это товар на полке нашего облачного склада. Примеры SaaS: Google Drive, Microsoft Office 365, Dropbox.

Облака — прибыльный бизнес

Больше денег крутится в сегменте SaaS: в 2018 году он составил $80 млрд (из $182,4 млрд общемирового облачного рынка). Второе место занял сегмент IaaS, на последнем месте – PaaS.

Все началось в 2002 году с Amazon

В начале 2000-х компания Аmazon, которую тогда все знали как онлайн магазин книжек, предложила своим клиентам размещать данные на удаленных серверах, без привлечения собственной инфраструктуры и оборудования. Идею подхватили и начали развивать Google, IBM и другие технологические гиганты. Следующие 18 лет развития технологий прошли в постоянном усовершенствовании облачных продуктов. Разработчики соперничали в умении создавать наиболее эффективные программы для организации виртуальной IT-инфраструктуры. Расходы на облачные вычисления росли быстрее, чем ожидалось, и в ближайшие годы останавливаться не собираются.

Идея Аmazon оказалась более чем удачной. В 2012 году мировой рынок облачных услуг составил $26,4 млрд. В 2019 году он вырастет почти в 10 раз , к 2026 году – почти в 20 раз, до $521,8 млрд.

Украинский облачный рынок перевалил за отметку в $22 млн

В Украине облачные сервисы активно стали использоваться в 2014 году. После аннексии Крыма и Донбасса многие компании с востока переехали в Киев или другие города и решили не строить снова свои дата-центры (потому что это дорого), а арендовать место в облаках. Другого варианта сберечь бизнес у них не было.

Основными поставщиками облачных услуг в Украине являются иностранные провайдеры – Amazon Web Services, Microsoft Azure, Tet (ex-Lattelecom) . Их доля на рынке составляет более 60%. В 2017 году объем украинского рынка публичных инфраструктурных облаков впервые превысил размер рынка традиционных дата-центров.

Google, Amazon и Microsoft – мировые облачные лидеры

Мировой рынок облачных сервисов концентрируется вокруг трех IT-гигантов: Google, Amazon и Microsoft, занимающих 70% рынка IaaS. Услуги Amazon и Microsoft используют компании США и Европы. В Китае рынок почти полностью монополизировал местный провайдер Alibaba Cloud.

В Украине, помимо глобальных облачных провайдеров, также работают локальные операторы: De Novo , GigaCloud , UCloud , ” Парковый “, VoliaCloud , Tucha . По состоянию на 2020 год их общая рыночная доля составила $6,1 млн.

Больше денег на облака тратят американские компании

По итогам 2020 года американский бизнес потратил на облака $97 млрд – более 60% от общего мирового рынка. На втором месте – Великобритания с показателем $7,9 млрд, за ней следует Германия ($7,4 млрд). На рынке Азии лидируют Япония и Китай.

В Европе облачный рынок распределен очень неравномерно. Развитые экономики западной Европы тратят на облака в разы больше, чем их восточные коллеги. По данным аналитической компании Forrester Research , в 2019 году облачный рынок западной Европы составил $24,1 млрд, восточной — всего $1,15 млрд.

В Украине рынок облачных сервисов все еще находится на стадии активного роста. Его потенциал значительно больше, чем имеющиеся $22,2 млн. Украинские провайдеры по качеству услуг не уступают западному, к тому же готовы предлагать индивидуальные решения и оказывать техническую поддержку в максимально сжатые сроки. В принципе, никто не принуждает бизнес воспользоваться облачными сервисами. Он может и самостоятельно разворачивать и обслуживать сложные IT-системы, но в конце концов это может негативно отразиться на эффективности и конкурентоспособности компании.

Старший инженер Bolt, поделился возможностью использовать инфраструктуру как код с AWS CDK на примере веб игры.

Образец архитектуры

Архитектура, изображенная ниже, достаточно точно представляет ресурсы, использованные для проекта веб-версию хорошо знакомой игры Snake (изображение 1):

Ключевые особенности:

1. Это бессерверная архитектура: отсутствуют зарезервированные вычислительные мощности и отсутствуют расходы «вперед».
2. Amazon API Gateway служит единственной точкой входа в приложение.
3. Хранилище S3 используется для размещения статического веб-сайта и медиа-контента (в нашем случае самой игры).
4. AWS Lambda используется как среда выполнения API.
5. Dynamo DB сохраняет состояние системы (в данном случае это счет в игре).
6. Ради простоты примера я должен обойти интеграцию с Cognito, которая в реальном решении была использована для идентификации пользователей.

Согласно схеме выше, репозиторий содержит три проекта:

/aws-snake 
/snake-API # node/express API 
/snake-client # игра на обычном JavaScript 
/snake-iac # проект AWS CDK

Оригинальный коммерческий проект построен на .NET Core, но для текущего образца я использую TypeScript по трем причинам:

1. TypeScript выглядит чем-то средним между Java/C# и JavaScript.
2. JavaScript-подобный синтаксис понимают почти повсеместно.
3. Чтобы доказать, что CDK действительно работает независимо от выбранного языка программирования.

Начало работы с CDK

Старт работы с AWS CKD достаточно прост, вы можете либо следовать официальным инструкциям с начала работы, либо выполнить следующие шаги:

• • Создать аккаунт AWS .
  • Создать ключ доступа AWS .
  • Установить AWS CLI .

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /

• Конфигурировать AWS CLI, используя предварительно созданный ключ

  aws configure

• Установить Node LTS .

  brew  install  node  # mac  
  sudo apt- get  install  nodejs  # debian

• Установите AWS CDK toolkit.

  npm install -g aws-cdk

• Установите целевую среду выполнения (в нашем случае TypeScript) .

  npm install -g typescript

• Создать пустой CDK-проект.

  mkdir  test -iac  
  cd  test -iac 
  cdk init app --language typescript

• Познакомьтесь с CDK командами.

  cdk  list  # Список всех стеков программы  
  cdk synthesize  # Синтезирует и печатае CloudFormation для текущего стека  
  cdk bootstrap  # Разворачивание стека инструментов CDK в среде AWS  
  cdk diff  # Сравнивает локальный стек с развернутым стеком и печатает разницу
  cdk deploy  # Развертывание стека в аккаунте AWS
  cdk destroy  # Уничтожить развернутый стек

Вот и все! Теперь вы знаете все необходимые команды CDK. Хотя в основном вы будете использовать только две:

cdk diff

и

cdk deploy

Настройка стека

Стек CloudFormation  — это коллекция ресурсов AWS, управляемых как одно целое, настраиваемое как шаблон JSON или YAML
По сути, AWS CDK дает обертку над стеком CloudFormation, что позволяет создать его, используя язык программирования общего назначения.

cdk init app

создает пустой стек с соответствующим файлом программного кода, зависящий от целевого языка. В нашем случае это

lib/snake-iac-stack.ts

import  *  as  cdk  from  '@aws-cdk/core' ;
  export  class  SnakeIacStack  extends  cdk . Stack  {
       constructor (scope: cdk.Construct, id: string, props?: cdk.StackProps) {  
        super (scope, id, props);      
// The pre that defines your stack goes here     
 } 
 }

Добавление нового ресурса к стеку – это просто создание нового экземпляра класса, например, чтобы создать S3 хранилище для хостинга нашей JavaScript игры мы просто добавляем следующие строки :

// pre that defines your stack goes here  
// Snake Web Client  
const snakeClient =  new  s3. Bucket ( this , nameIt( "website-s3" ), { 
	bucketName: nameIt( "website-s3" ), 
	versioned:  false , 
	publicReadAccess:  true , 
	websiteIndexDocument:  "index.html" , 
	removalPolicy: cdk. RemovalPolicy . DESTROY  // remove on stack destruction 
});

Обратите внимание, что очень важно установить всеобщую конвенцию именования для всех ресурсов, например:

<environment>-<project>-<resource>

Для этого мы используем следующую вспомогательную функцию:

const  envName =  'test' ; 
const  nameIt =  ( name: string ) =>  ` ${envName} -snake- ${name} ` .toLowerCase(); 

Сочетание ресурсов

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

// API Gateway  
const snakeClientIntegration =  new  integration. HttpProxyIntegration ( { 
	method: gate. HttpMethod . ПОЛУЧИТЬ , 
    url: snakeClientBucket.bucketWebsiteUrl, 
}); 
const httpApi=  new  gate. HttpApi ( this , nameIt( "Api-GateWay" ), { 
    apiName: nameIt( "Api-GateWay" ), 
    defaultIntegration: snakeClientIntegration, 
});

Далее мы можем установить маршруты API таким же образом:

const apiGateway =  new  gate. HttpApi ( this , nameIt( "Api-GateWay" ), { 
   // ... // 
}); 
// Snake API  
const apiLambda =  new  lambda. Function ( this , nameIt( "api-lambda" ), { 
   // ... // 
}); 
const snakeApiIntegration =  новая  интеграция. LambdaProxyIntegration ({ 
	handler: apiLambda,  // api integration 
}); 
apiGateway.addRoutes({  // api route  
	path:  "/api/{proxy+}" , 
	methods: [gate. HttpMethod . ANY ], 
	integration: snakeApiIntegration 
}); 
apiGateway.addRoutes({  // swagger route  
	path:  "/swagger/{proxy+}" , 
	methods: [gate. HttpMethod . GET ], 
	integration: snakeApiIntegration 
});

То же касается управления контролем доступа, предоставления доступа к базе данных для компонента API:

// Persistence layer  
const table =  new  dynamodb. Table ( this , nameIt( 'DynamoDb - Table '), { 
	 // ... // 
}); 
 
table.grantReadWriteData(apiLambda); // give api access to dynamo DB table 

Для завершения образца конфигурации стека обратитесь в  репозиторий проекта

Просмотр стека

Во-первых, вы можете найти стеки CloudFormation в веб-консоли AWS (изображение 2):

Изображение 2. Стеки CloudFormation в консоли AWS
Во-вторых, тот же список стеков можно получить, выполнив следующую команду в терминале:

aws cloudformation list-stacks

Обработка дрейфа конфигурации

К сожалению, это слабое место как AWS CDK так и CloudFormation, поскольку обнаружение и обработка дрейфа конфигурации пока отсутствуют «out of the box» (см. открытый вопрос ).
Обработка дрейфа конфигурации возможна, но не тривиальна (см. статью ).
Поэтому я бы предложил начать с предотвращения возможности внесения несанкционированных изменений в конфигурацию.
В идеале все изменения в инфраструктуру должны вноситься программно, от имени отдельной учетной записи, используемой исключительно CDK приложением.
Этот подход также может быть автоматизирован (см. открытый вопрос ).

CI/CD

AWS CDK может быть легко интегрирован в процедуры непрерывной доставки (continuous delivery). Для этого образца используются GitHub Actions, тогда как для оригинального проекта мы использовали Azure DevOps, отличия не существенны.
Образец конфигурации CI/CD состоит из двух важных элементов:

1. Скрипт для компиляции развернутых пакетов (./build.sh)
2. Настройка GitHub Workflow в виде YAML файла, описывающего доставление в несколько сред (test, prod) с подтверждением администратора (/.github/workflows/ci-cd.yml)

Полученный результат доставки отображен ниже (изображение 3):
Изображение 3. Результат доставки GitHub Workflow
Обратитесь к руководству CI/CD в Readme.MD для настройки.

Вывод

AWS CDK создал прецедент для DevOps практики будущего, а текущая разработка Terraform CDK доказывает существование широкой заинтересованности в использовании языков общего назначения для реализации «инфраструктуры как кода».
Этот подход делает дисциплину непрерывного доставки доступнее, позволяет разработчикам быть вовлеченными в поддержку инфраструктуры, а также использовать существующие инструменты контроля качества как статический анализ, или даже модульные тесты.

Это часть серии статей, посвященных принципам сетевой автоматизации.

Каждый инженер задается целью построить «правильную систему» ​​с первого раза, но возможно ли это вообще? Вы вообще знаете свои требования? Вы действительно знаете свои требования? Нет, серьезно, вы действительно знаете, каковы ваши требования? Введите ЯГНИ и преждевременную оптимизацию.

ЯГНИ: «Вам это не понадобится» – это принцип экстремального программирования, который гласит, что программист не должен добавлять функциональные возможности до тех пор, пока он не будет сочтен необходимым, и «делать простейшие вещи, которые могут сработать». (DTSTTCPW) – Википедия

Настоящая проблема в том, что программисты потратили слишком много времени, беспокоясь об эффективности в неправильных местах и ​​в неподходящее время; Преждевременная оптимизация – это корень всего зла (или, по крайней мере, большей его части) в программировании. – Искусство программирования

Книга «Искусство программирования» была написана в 60-х годах и актуальна до сих пор.

Теория информатики

Год назад у меня был дизайнерский разговор с коллегой, где он напомнил мне, что нотация Big-O не учитывает константы.

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

Это хорошее правило, которое следует учитывать при предоставлении двух почти одинаково взвешенных вариантов, таких как сравнение поиска по хешу / словарю и поиска по списку, который сравнивает O (1) и O (n), и оба они хорошо понятны / легко выполняются. Однако введение оптимизаций, таких как многопоточность или многопроцессорность, до того, как вам понадобится, по сути, затрудняет поддержку кода. Это значительно увеличивает возможности проектирования, вероятность возникновения условий гонки и возможность устранения неполадок.

Понятно, почему константы не имеют значения в нотации Big-O, но в практическом применении это определенно имеет значение. Возьмите временную сложность Big-O с наихудшей скоростью O (n!) (O-факториал), где вы никогда не сможете достичь числа выше «2» в качестве значения «N». Кроме того, оптимизация процесса, который занимает всего 0,1% вашего реального времени, мало что дает. Однако трудно увидеть, где будет происходить оптимизация, пока вы не доберетесь до нее. Наконец, оптимизация вашего процесса может не привести к дополнительной экономии, например, когда фактическая неправильная оптимизация процесса ожидает одобрения со стороны человека.

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

Мое личное путешествие

Ошибки – я совершил несколько ошибок и, вероятно, буду делать еще несколько. Я попал в кроличью нору, слишком рано вводя нефункциональные требования (такие как аутентификация и ведение журнала), добавляя функции до того, как они понадобятся, и делая программное обеспечение «фреймворком». Я был счастлив, что смог использовать код оптимизации, но ни разу не увидел, что программа покидает фазу проверки концепции. Другими словами, я потратил много времени на код, который не использовался каким-либо значимым образом из-за добровольных требований и оптимизаций.

Пример использования сетевой автоматизации

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

• Небольшие инкрементальные изменения, подключаемые к 1-5 устройствам за раз в течение окна изменений.
• Ежедневные задачи, такие как резервное копирование конфигураций, соответствие конфигурации и сбор рабочих данных, не зависящие от времени.
• Редкие глобальные изменения, такие как обновление списков контроля доступа SNMP или обновление IP-адресов сервера NTP.

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

Пример из реальной жизни

Я работал с клиентом над ежедневным процессом резервного копирования и обеспечения соответствия конфигурации для 8000+ устройств. Некоторые участники сообщества явно задокументировали, что Ansible работает медленнее, чем, скажем, Nornir 1 2. Однако места, где оптимизация принесла наибольшую пользу, не были, вероятно, теми местами, которые вы ожидали, и решения также были неочевидными.

Требования

Требования, относящиеся к этому сообщению в блоге, включают:

• Выполните все задания менее чем за 24 часа, в том числе:
  • Резервное копирование конфигураций сетевых устройств.
  • Предполагаемая генерация конфигурации, интеграция с внешним Источником Истины (SoT).
  • Сравнение соответствия конфигурации по функциям (BGP, NTP, SNMP и т. Д.) На каждом устройстве.
  • Сверните отчеты о вышеперечисленном.
• Возможность запускать задания для отдельных устройств

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

Многопоточность

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

Широкое масштабирование

Хотя были очевидные проблемы со слишком широким масштабированием и слишком быстрым, это не значит, что мы не могли использовать масштабирование более широко. Использование ресурсов, связанное с управлением большим количеством устройств в Ansible, замедляло процесс. Причины неэффективности менее важны, поскольку решение было довольно простым. Решения включают создание нескольких рабочих процессов в Ansible AWX / Tower и распределение нагрузки по типам ОС для устройств NXOS и EOS и по регионам для устройств IOS. Эту оптимизацию было относительно легко произвести, и она практически не повлекла за собой изменений конструкции.

Генерация конфигурации

Мы заметили, что создание конфигурации занимает много времени. У нас было две основные гипотезы, почему:

• Неэффективность в том, как Ansible использует Jinja.
• Неэффективность в том, как Ansible идемпотентно проверяет изменения конфигурации файлов.

Заменить Jinja было бы сложно, однако, поменять способ реализации идемпотентности – простое изменение. Нам просто нужно было заменить модуль шаблона Ansible для поиска по шаблону Ansible и сохранить файл с настраиваемым фильтром.

Исходное задание:

- name: "GENERATE FILES FROM JINJA TEMPLATES"
  template:
    src: "{{ src_file }}"
    dest: "{{ dst_file }}"

- name: "GENERATE FILES FROM JINJA TEMPLATES"
  set_fact:
    save_to_file: "{{ lookup('template', src_file) | save_output_to_file(dst_file) }}"

def save_output_to_file(content, destination):
    """Save content to file."""
    with open(destination, "w") as fh:
        fh.write(content)
    return destination

class FilterModule(object):
    """Ansible filter class."""

    def filters(self):
        """List of filters."""
        return {
            "save_output_to_file": save_output_to_file,
        }

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

Человеческое и деловое взаимодействие

Инструменты и технологии, которые попадают в этот раздел, предназначены для непосредственного предоставления интерфейсов автоматизации, которую мы создаем для сети. Это такие вещи, как наши приложения для управления ИТ-услугами (ITSM), а также платформы для чата и общения. ChatOps – это термин, который часто используется в отрасли и продолжает набирать обороты в автоматизации сетей. Интеграция с чат-платформами позволяет бизнесу передавать сетевые данные и рабочие процессы в каналы, по которым уже ведутся разговоры. Возможно, что еще более важно, эти возможности позволяют сделать автоматизацию нашей сети доступной для заинтересованных сторон вне сетевых групп напрямую.

Управление данными

Если бы я выбрал один-единственный раздел в своем выступлении, чтобы назвать его наиболее важным, это был бы этот раздел. Что касается автоматизации сети, то в отрасли недостаточно говорится о данных. Как и в любой другой вертикали в технологическом пространстве, данные лежат в основе всего, что мы делаем, и автоматизация сети не исключение. По мере роста сообщества автоматизации сети появляется понимание концепции использования Источника истины (SoT), который является авторитетной системой записи для определенной области данных. Эта последняя часть является ключевой, потому что на самом деле мы можем (и реально имеем) иметь несколько источников истины, которые не пересекаются. Например, наши IPAM и DCIM могут быть разными системами, потому что они управляют разными доменами данных. Это действительно до тех пор, пока у нас не более одного инструмента IPAM или DCIM, поскольку именно отсюда происходит фраза «Единый источник истины»,

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

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

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

Мониторинг, оповещение и видимость

Может показаться немного странным говорить о мониторинге и предупреждениях в контексте автоматизации сети, но мы делаем больше, чем просто управление конфигурацией. Фактически, суть этой темы сосредоточена вокруг концепции «автоматизации с замкнутым циклом» или создания контура обратной связи в платформе автоматизации, которую мы создаем. В видео вы услышите, как я говорю о платформе автоматизации как о стеке, и с одной стороны мы перемещаемся вниз по стеку к реальной сетевой инфраструктуре, но с другой стороны, события выходят из сети и возвращаются вверх по стеку. . Действительно, эти события приходят в традиционных формах опроса SNMP, сообщений системного журнала и т. Д. Они также могут иметь новые формы, такие как показатели временных рядов и потоковая телеметрия. Мы также пересмотрели уровень хранения и обработки, чтобы реализовать более современные базы данных временных рядов, которые позволяют помечать точки данных метками метаданных, что открывает двери для более интеллектуальных запросов и визуализации. Говоря о визуализации, мы хотим предоставить заинтересованным сторонам бизнеса сетевые данные, и мы хотим делать это в режиме самообслуживания с помощью современных инструментов панели мониторинга. Опять же, это случай предоставления бизнесу сетевых данных и рабочих процессов.

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

Операционные модели

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

Облачные технологии – это технологии распределенной обработки цифровых данных, с помощью которых компьютерные ресурсы предоставляются интернет-пользователю как онлайн-сервис. Программы запускаются и выдают результаты работы в окне web-браузера на локальном ПК. При этом все необходимые для работы программы и их данные находятся на удаленном интернет-сервере и временно кэшируются на клиентской стороне: на ПК и др.

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

Виды облачных технологий

Имеются следующие категории облачных технологий:

• Публичное облако – одновременный доступ многих пользователей к IT-инфраструктуры. Но возможности управлять и обслуживать данную облако в пользователей нет, вся ответственность возложена на ее владельца. Абонентом предлагаемых сервисов может стать любая компания или частное лицо.
• Частное облако – IT-инфраструктура, которую контролирует и эксплуатирует только один абонент в собственных интересах. Инфраструктура для управления частнім облаком может размещаться либо в помещениях пользователя, или у внешнего оператора или частично у пользователя и оператора.
• Гибридное облако – это IT-инфраструктура, в которой объединены лучшие качества публичного и частного облака. Такая композиция уникальные объекты, связанные между собой стандартизированными или собственными технологиями, которые позволяют переносить данные или программы между компонентами.

Возможности облачных вычислений

Существует несколько уровней облачных вычислений:

• Низкий уровень «Инфраструктура как услуга» (IaaS, infrastructure as a service). Пользователи получают базовые вычислительные ресурсы: процессоры и устройства для хранения информации – и используют их для создания собственных операционных систем и приложений. Потребитель не управляет базовой инфраструктурой облака, но имеет контроль над операционными системами, системами хранения, развернутыми приложениями. Возможен ограниченный контроль выбора сетевых компонентов (например, хост с сетевыми экранами).
• Следующий уровень «Платформа как услуга» (PaaS, platform as a service). Пользователи имеют возможность устанавливать собственные приложения на платформе, предоставляемой провайдером услуги. Пользователь не управляет базовой инфраструктурой облака: сетями, серверами, операционными системами и системами хранения данных, но имеет контроль над развернутыми приложениями и некоторыми параметрами конфигурации среды хостинга.
• Высший уровень облачных вычислений «Программное обеспечение как услуга» (SaaS, software as a service). В «облаке» хранятся не только данные, но и связанные с ними программы, а пользователю для работы нужно только веб-браузер. Потребитель пользуется приложениями провайдера, который работает в облачной инфраструктуре. При этом пользователь не управляет базовой инфраструктурой облака – сетями, серверами, операционными системами, системами хранения, также индивидуальными настройками приложений за исключением некоторых настроек конфигурации программы.

Примеры облачных решений

На данный момент в мире правят три гиганта – AWS, Azure, Google Cloud. Эти компании занимают львиную долю рынка по всему миру (кроме Китая, там есть еще Alibaba Cloud), являются технологическими лидерами и задают тренды в развитии облачных IaaS сервисов. Например, сейчас AWS имеет в своем портфолио более 100 сервисов (IaaS, SaaS, PaaS).

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