Технологии

Этот раздел довольно самоуверенный и направлен на то, чтобы познакомить вас с основными инструментами, оставив позади многие другие для краткости. Я настоятельно рекомендую позже взглянуть на список Awesome Network Automation.

Python

Python – популярный язык программирования, когда речь идет об автоматизации сети. Все популярные инструменты и библиотеки для автоматизации сети написаны на Python.

Благодаря плавной кривой обучения и огромной популярности (второй по популярности язык на GitHub после JavaScript на момент написания) Python является отличным выбором для начала программирования.

Основы Python выходят за рамки этого руководства. Я предоставил несколько онлайн-ресурсов, которые могут помочь в изучении Python, в разделе «Ссылки и дополнительная литература», которая будет в других частях сетевой автоматизации.

Чтобы эффективно использовать Python для решения базовых задач автоматизации сети, вам необходимо изучить этот набор навыков:

• Настройка Python в вашей системе
• Использование виртуальных сред и установка пакетов с помощью Pip
• Понимание основных концепций Python, таких, как:
  • Переменные
  • Структуры данных
  • Функции
  • Импорт

Как видите, это не так уж сложно, и я рекомендую вам потратить на это немного времени, потому что это значительно упростит вам путь к автоматизации.

Способы программного взаимодействия с сетевыми устройствами

Существует два основных способа программного доступа к сетевым устройствам: интерфейс командной строки и API.

CLI

Долгое время единственным API сетевых устройств был интерфейс командной строки, предназначенный для использования людьми, а не сценариями автоматизации. Вот основные недостатки использования CLI в качестве API:

• Несогласованные выходные данные. Одни и те же выходные данные команд могут отличаться от одной версии NOS (сетевой операционной системы) к другой.
• Неструктурированные данные. Данные, возвращаемые при выполнении команды в CLI, представляют собой обычный текст, что означает, что вам необходимо вручную проанализировать их (т.е. очистить CLI)
• Ненадежное выполнение команды. Вы не получаете код состояния выполненной команды и должны анализировать вывод, чтобы определить, успешно ли выполнена команда или нет.

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

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

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

Цитаты самых облачных команд DevOps в Интернете

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

API

Если вам повезло, и устройства в вашей сети имеют API или, возможно, даже управляются контроллером SDN, этот раздел для вас. Сетевые API делятся на две основные категории: на основе HTTP и NETCONF.

RESTful API

REST означает передачу репрезентативного состояния и определяет набор свойств и ограничений, которым должен соответствовать API, чтобы называться RESTful.

ПРИМЕЧАНИЕ. API на основе HTTP могут быть RESTful и не RESTful. API на основе HTTP, не относящиеся к RESTful, не рассматриваются, поскольку они менее распространены.

API RESTful довольно просты в использовании и понимании, поскольку они основаны на протоколе HTTP. По сути, RESTful API – это просто набор URL-адресов HTTP, по которым вы можете выполнять запросы GET и / или POST, за исключением того, что возвращаемые данные кодируются в JSON или XML, а не в HTML. Поскольку RESTful API основаны на HTTP, они по своей природе не имеют состояния. Это означает, что каждый запрос не зависит от другого и должен содержать всю необходимую информацию для правильной обработки.

Чтобы изучить RESTful API, вы можете использовать такие инструменты, как cURL или Postman, но когда вы будете готовы написать некоторый код с использованием RESTful API, вы можете использовать библиотеку Python, называемую запросами.

В Интернете есть несколько макетов REST API, которые вы можете использовать на практике. Например, kanye.rest и JSONPlaceholder.

NETCONF и RESTCONF

NETCONF – это протокол, специально разработанный для управления сетевыми устройствами. В отличие от REST, он использует SSH в качестве транспорта и в результате сохраняет состояние. Другими ключевыми отличиями NETCONF являются четкое разграничение между конфигурационными и рабочими данными и концепция хранилищ данных конфигурации. NETCONF определяет три хранилища данных: текущая конфигурация, конфигурация запуска и конфигурация кандидата. Возможно, вы знакомы со всеми тремя из них в контексте сетевых устройств. Концепция конфигурации кандидата позволяет доставлять изменение конфигурации, состоящее из множества команд, как одну транзакцию. Это означает, что если только одна команда в транзакции терпит неудачу, транзакция не завершается успешно, что позволяет избежать ситуации, когда применяется частичная конфигурация.

Изучение API-интерфейсов NETCONF не так просто и понятно, как с API-интерфейсами RESTful. Для этого вам необходимо установить интерактивный сеанс SSH с устройством и отправлять длинные команды в кодировке XML. Для программного доступа к API NETCONF существует библиотека Python ncclient.

RESTCONF – это еще один стандартный протокол, который реализует подмножество функций NETCONF (например, транзакции не поддерживаются) и использует HTTP в качестве транспорта и является RESTful.

При выборе между NETCONF и RESTCONF это рекомендуется использовать бывший для прямого взаимодействия с сетевыми устройствами, а последним для взаимодействия с SDN-контроллерами и / или дирижерами.

gRPC и gNMI

gNMI – это новое дополнение к протоколам управления сетью, основанное на gRPC Google и разработанное рабочей группой OpenConfig. Он считается более надежным преемником NETCONF и поддерживает потоковую телеметрию.

Поскольку gNMI еще не настолько развит, как NETCONF, он не очень хорошо поддерживается в Python. Хотя есть несколько библиотек, в которые вы можете заглянуть: cisco-gnmi и pygnmi.

Резюме

Вот сводная таблица, представляющая ключевые свойства типов сетевых API.

	REST	NETCONF	RESTCONF	gNMI
RFC	–	RFC 6241	RFC 8040	Черновой вариант
Транспорт	HTTP	SSH	HTTP	gRPC (HTTP / 2.0)
Кодирование данных	XML, JSON	XML	XML, JSON	ProtoBuf (двоичный)
Сопровождение сделки	❌	✅	❌	✅
Библиотеки Python	Запросы	ncclient	Запросы	cisco-gnmi , pygnmi

Сегодня мы разберемся как с помощью kconfig hardened check вы можете проверить настройку механизмов защиты ядра ОС Linux, которые используются для противодействия эксплойтам. В данный момент, это один из опаснейших инструментов нарушения разграничения доступа и функционирования операционной системы. Разберемся какие модули безопасности и основные параметры компиляции ядра есть в официальном репозитории, и какие наборы механизмов применяются в различных дистрибутивах.

2 слова об инструментах и источниках данных

Исследовать ОС Linux традиционно будем на базе исходного кода из официального репозитория. В качестве инструментов используем:

• Visual Studio Code;
• Python 3;

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

Защитные подсистемы

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

В Linux для защиты от атак на разграничение доступа и эксплуатацию уязвимостей используются следующие механизмы:

• LSM фреймворк — механизм перехвата системных функций для обработки расширениями ядра Linux;
• KASLR — рандомизация адресного пространства ядра;
• HW-Vuln — митигации и патчи, которые используются против Hardware уязвимостей (Meltdown, Spectre, и т.д.);
• Параметризация сборки и запуска ядра. Большое количество работающих алгоритмов в ядре — это потенциальный вектор для атаки, поэтому здесь исходят из минимально необходимого функционала, который можно оставить и при этом максимально уменьшить возможности проведения атак.

Большинство этих механизмов противодействия атакам на разграничение доступа и эксплуатации уязвимостей находятся в разделе linux/security:

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

К примеру, модуль tomoyo невозможно использовать с другими модулями.

Директория «security» содержит инструкции по защите от различных техник, позволяющих использовать уязвимости системы. К примеру, min_addr— это защитный механизм, резервирующий адреса в оперативной памяти, находящиеся рядом с нулевым адресом. Он актуален для предотвращения использования начальных страниц в оперативной памяти для хранения данных эксплойта. Некоторым другим защитным механизмам для запуска требуется использование дополнительных опций запуска ядра и компиляции. Найти эти данные вы можете в hardening конфиге. Информация там представлена исключительно в виде описания отдельных параметров.

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

Механизмы защиты Ubuntu

Ubuntu довольно популярен и как серверный дистрибутив, и как десктопный. Проверку проведем с помощью инструмента — kconfig hardened check. Он тестирует безопасность текущей настройки ядра показывает, параметры установленные при установке системы. Репозиторий регулярно обновляется, так что список подсистем защит и параметров компиляции ядра гораздо обширнее, чем при простом исследовании исходного кода. Для проверки опций в собранном дистрибутиве, в репозитории предоставлен скрипт на Python. Также обращаем ваше внимание, что если эталонный конфиг не использовать, то kconfig hardened check покажет информацию по дистрибутиву, не указывая, что есть. Он показывает, что желательные установленные параметры. Запуск проверки выглядит так:

kconfig-hardened-check -p X86_64 -c kspp-recommendations-x86-64.config

В репозитории содержатся 2 вида конфигов — обычный, созданный для конкретного дистрибутива, и рекомендуемый с точки зрения наибольшего количества безопасных опций. Ресурс kernsec описывает KSSP-конфиг как наиболее параноидальный с точки зрения количества применяемых параметров. Результат для Ubuntu Server 20.04:

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

Механизмы защиты Debian

В случае с Debian, мы выбрали модификацию Kali Linux, неофициальный дистрибутив. Это дистрибутив, часто используемый для тестирования на проникновение. Давайте оценим как у него у самого с параметрами безопасности:

Kali Linux несмотря на узкий спектр задач, для которых используется, все таки содержит в себе достаточное количество опций и параметров ядра для противодействия атакам.

Мы продемонстрировали как можно выяснять, как настроен тот или иной дистрибутив, которым вы пользуетесь на базе ядра ОС Linux. Если у вас возникли вопросы или необходима консультация по данной тематике – обращайтесь! Наши специалисты помогут вам разобраться в механизмах защиты и противодействия атакам.

 +38 (050) 470-29-17

+38 (094) 710-16-18

 vkarabedyants

 Telegram

office@itfb.com.ua

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

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

Небольшой «спойлер» — по результатам сравнения, облачные решения все-таки являются более оптимальными.

Сложности выбора

На вопрос «где лучше запустить веб-приложение», нет единого ответа. Вариантов тут масса. Вы можете использовать собственные серверы вашей компании, а можете разместиться на Shared Hosting провайдеров, можете приобрести VPS/VDS хостинг, а можете воспользоваться сервисами облачной инфраструктуры от интернет гигантов – Amazon Web Services (AWS), Google Cloud, Microsoft Azure. А также не стоит забывать, что существуют и ориентированные исключительно на хостинг веб-приложений решения вроде Pantheon или WP Engine.

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

«Какой выбор будет правильным в моем случае?», «Что бюджетнее в перспективе?», «Как определить надежность этих вариантов?», «Где лучше техническая поддержка?», «Что если я захочу расшириться?»

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

Dedicated server

Самым привлекательным с точки зрения свободы действий, выглядит конечно собственный сервер. У вас будет полное управление конфигурацией, root-доступ и полный контроль для обеспечения максимального уровня безопасности системы. С другой стороны стоит рентабельность такого выбора. Высокая стоимость Dedicated server является главным отрицательным фактором такого решения.

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

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

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

Shared Hosting

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

Из минусов тут можно назвать ограниченность в плане добавления и конфигурирования дополнительных возможностей. Да и производительность со стабильностью в этом случае сильно может пострадать от непрогнозируемых и больших потоков трафика, а также от задействования ресурсов сервера соседними приложениями и веб-сайтами. И таких соседей у вас может быть довольно много — от нескольких десятков до нескольких сотен. На сильную оперативность поддержки в таком случае рассчитывать также не стоит. Да и в вопросах безопасности выбор shared hosting не лучший — если будет взломан один веб-сайт или веб-приложение на сервере, то с большой вероятностью злоумышленники смогут получить доступ и к другим проектам, в том числе к вашему.

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

VPS Hosting

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

Теперь к сложностям. При работе с VPS вам точно потребуется довольно высокая квалификация и глубокие технические знания в управлении серверами, примерно сравнимые с необходимым уровнем подготовки при работе с физическими серверами. Только опыт работы с hardware не пригодится, в случае с VPS вам не нужен план замен, закупок, монтажа оборудования и тому подобное. Но инфраструктурно всё то же самое. Таким образом вам для работы с VPS hosting точно понадобятся квалифицированные администраторы. А если решите заниматься конфигурированием окружения вашего веб-приложения без опыта работы с VPS, вам потребуется довольно много времени.

Managed Hosting

В этом варианте непосредственное управление сервером вам недоступно — для вас запускают ваше веб-приложение и дают административный доступ к нему. То есть в возможностях управления вы ограничены исключительно своим приложением. Ну и поскольку с вами на физическом сервере присутствуют соседи, то в случае с Managed Hosting вас ожидают те же риски, что и с Shared hosting — нестабильность объема фактически доступных ресурсов, медленный ответ техподдержки и так далее.

Clouds

Этот вариант хостинга предлагаем разобрать подробнее. Рынок Clouds-решений стремительно растет и с каждым годом набирает все большую популярность. Команда аналитиков из компании Gartner оценила этот рынок в в $242,7 млрд по итогам 2019 года. И, по их же прогнозам, в 2021 году мировой рынок публичных облачных сервисов превысит $306 млрд.

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

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

Есть, конечно, и сложности, с которыми сталкиваются при выборе Clouds. Основная — это сложность выбора облачной архитектуры. Бывает непросто подобрать AWS stack, подходящий для вашего проекта, чтоб и закрывал все потребности и по стоимости укладывался в бюджет.

В целом, AWS stack очень схож с конструктором — при определенных навыках и знаниях из него можно создавать разные вещи. Часто даже организацию хостинга с его помощью сравнивают с самостоятельной сборкой компьютера. Как продолжение этого сравнения, заказ хостинга у провайдера сравним с покупкой готового ПК. EC2 – сравним с материнской платой и памятью, с его помощью можно запускать instance на базе образа операционной системы. EBS – схож с логическим диском, накопителем. Вы можете создать диск определенного размера и подключить его к определенному instance (созданный «диск» будет называться volume). В итоге в вашем распоряжении будет устройство, которое вы сможете монтировать, форматировать и работать с ним. При этом все данные, которые были записаны на него, будут сохранены  независимо от жизни instance. S3 – сравнимо с внешним хранилищем. Вы можете использовать его для сохранения файлов большого размера и хранить их вечно. Также вам доступны сервисы логирования, баз данных, мониторинга, DNS и многие другие.

Как видите, может быть довольно сложно из имеющихся комплектующих собрать машину, которая бы обеспечивала оптимальную работу вашего приложения и при этом не выйти за рамки бюджета. Без опыта работы с облачными хостингам довольно сложно определить верную схему AWS stack для использования, правильно подобрать компоненты и сервисы и настроить их интеграции. Эта схема дает возможность оценить сложность выбора — CNCF Cloud Native Landscape.

Конечно же, для использования AWS Cost Forecast (калькулятора для расчета расходов) от вас потребуются профильные навыки и знания. Также сложность могут представлять создание описание структуры, процессов и необходимых скриптов. Для этого нужны квалифицированные специалисты с экспертизой в облачных технологиях Amazon, Google или Microsoft.

В общем, главный минус хостинга в облаках – он сложный.

App-specific providers

Самыми популярными услугами App-specific providers, рассчитанными на разработчиков, являются сервисы Google AppEngine, VMWare Pivotal Cloud Foundry, Heroku, Pantheon и другие. Эти сервисы предлагают целые наборы готовых компонентов для создания приложений, плюс фреймворки для управления платформой. Компонентами тут являются сервисы баз данных, репозитории, инструменты автоматизированного деплоя, мониторинга, среды тестирования и тому подобные.

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

Что касается недостатков, то ситуация сравнима с Managed hosting — вы имеете только то, что вам дают. При этом часто бывают случаи, когда отсутствует нужная конкретная версия какого-то компонента. Также к минусам относятся и довольно негибкие тарифные планы — в большинстве случает вы или не помещаетесь в свой план или вынуждены платить гораздо больше, чем можете задействовать своим проектом. В итоге, это может привести к тому, что рост вашего приложения начинает обходиться вам довольно дорого, но так как оно у вас уже адаптировано под конкретный PaaS, переход на другое решение будет вызывать дополнительные вложения и сложности. При этом у App-specific providers нет проблемы выбора и соединения множества компонентов, как у AWS или других облачных провайдеров.

Summary

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

Обращайтесь, подберем решение идеально подходящее именно для вас!

Проект Debian GNU / Linux выпустил обновленную версию своего стабильного дистрибутива Linux Debian 10 («buster»). Вы должны выполнить обновление, чтобы устранить проблемы безопасности, поскольку в этой версии внесены некоторые изменения в серьезную проблему, обнаруженную в Debian версии 10.8. Debian – это Unix-подобная (дистрибутив Linux) операционная система и дистрибутив бесплатного программного обеспечения. Он в основном поддерживается и обновляется благодаря работе многих пользователей, которые добровольно жертвуют своим временем и усилиями. Впервые о проекте Debian объявил в 1993 году Ян Мердок.

 

Подробнее о выпущенном Debian Linux 10.9

Из примечания к выпуску :

Проект Debian рад объявить о втором обновлении своего стабильного дистрибутива Debian 10 (кодовое имя «buster»). В этом релизе в основном добавлены исправления проблем безопасности, а также несколько поправок для серьезных проблем. Рекомендации по безопасности уже опубликованы отдельно, и на них есть ссылки.

Обратите внимание, что этот точечный выпуск не является новой версией Debian 10, а только обновляет некоторые из включенных пакетов. Нет необходимости выбрасывать старые «buster» носители. После установки пакеты можно обновить до текущих версий с помощью актуального зеркала Debian.

Тем, кто часто устанавливает обновления с security.debian.org, не придется обновлять множество пакетов, и большинство таких обновлений включено в этот выпуск.

Новые установочные образы скоро будут доступны в обычных местах.

Как обновить Debian 10 с версии 10.8 до 10.9

Перед этим вы должны сделать резервную копию вашей системы Linux. Любое обновление связано с риском потери приложений и данных. Поэтому храните проверенные резервные копии.

Порядок действий следующий. Сначала запишите текущую версию: запишите результаты для проверки. Например:

$ lsb_release -a 
$ cat /etc/debian_version 
$ uname -mrs

 

No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

Версия Linux

10,8

Версия ядра Linux :

Linux 4.19.0-14-amd64 x86_64

Обновите систему Debian Linux до 10.9 с 10.8

Введите следующую команду apt-get / apt для обновления вашей системы:

$ sudo apt-get update

ИЛИ

$ sudo apt update

Получение: 1 http://security.debian.org/debian-security buster / updates InRelease [ 65,4 кБ ] 
Получение: 2 http://deb.debian.org/debian buster-backports InRelease [ 46,7 кБ ]                           
Получение: 3 http : //cdn-aws.deb.debian.org/debian buster InRelease [ 121 kB ]                              
Get: 4 http://cdn-aws.deb.debian.org/debian buster-updates InRelease [ 51.9 kB ] 
Get: 5 http : //security.debian.org/debian-security buster / updates / main пакеты amd64 [ 269 ​​kB ] 
Получение:6 http://security.debian.org/debian-security buster / updates / main Translation-en [ 143 kB ] 
Получение: 7 http://cdn-aws.deb.debian.org/debian buster / main amd64 Packages [ 7 907 кБ ] 
Get: 8 http://cdn-aws.deb.debian.org/debian buster / main Translation-en [ 5,969 кБ ] 
Получено 14,6 МБ за 3 секунды ( 4 , 436 кБ / с )                                 
Чтение списков пакетов ... Готово
N: Repository 'http://cdn-aws.deb.debian.org/debian попойка InRelease' изменил 'Version' значение из '10 .8' до '10 .9'

Обратите внимание, что номер версии изменился в последней строке. Затем примените обновления, запустите:

$ sudo apt-get dist-upgrade

ИЛИ

$ sudo apt dist-upgrade

Перезагрузите Debian Linux.

Если обнаружен файл /var/run/reboot-required то перезагрузите компьютер. Для проверки выполните следующее:

[ -f /var/run/reboot-required ] && echo "System reboot needed"

Если нужна перезагрузка

$ sudo shutdown -r now

Проверка

Убедитесь, что обновление прошло гладко, с помощью команды cat / grep command / egrep :

$ uname -mrs 
$ lsb_release -a 
$ dmesg | egrep -i 'err|warn|critical' 
$ sudo tail -f /var/log/nginx/access_log

Заключение

Ваша ОС обновлена до последней стабильной версии. Вы также можете скачать обновленный ISO для полной установки. Это стабильное обновление внесло в систему важные исправления пакетов и улучшения безопасности. Удачных обновлений!

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

Почему же время загрузки страницы так важно?

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

Скорость загрузки влияет на 3 основополагающие, которые приносят вам доход: видимость, конверсия, комфорт использования.

• Видимость сайта. При ранжировании сайта, Google всегда учитывает время загрузки страницы. Соответственно, это напрямую влияет на поиске его в Интернете.
• Конверсия. Чем быстрее ваша загрузка сайта, тем больше взаимодействий между посетителями и сайтом. Если страница сайта будет загружаться долго, ваши клиенты будут разочарованы и покинут его еще до загрузки, так и не совершив покупку товара или не воспользовавшись услугой. Медленный сайт убивает конверсию.
• Комфорт использования. Удовлетворенность пользователя напрямую зависит от быстроты загрузки страниц. В результате удержание клиентов будет намного выше.

А теперь немного  цифр:

Посмотрите на пару результатов исследований от  HubSpot в 2020 году:

• Если Yahoo снизит время загрузки страницы на 0,4 секунды, трафик может увеличиться на 9%.
• Замедление загрузки страницы на 1 секунду может стоить Amazon 1,6 миллиарда долларов продаж каждый год.
• Замедление поиска Bing на  2 секунды приведет к потере дохода на 4,3% на каждого посетителя, уменьшению кликов на 3,75% и снижению количества запросов на 1,8%.

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

Какие же факторы могут влиять на время загрузки страницы, и почему вы теряете своих клиентов?

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

1. Обилие  HTTP-запросов

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

Преимущественно браузер ограничивает количество одновременных запросов от 4 – 8.

Следственно, делать много запросов одномоментно – нельзя.

Исследования от  Yahoo, говорят, что  80% времени загрузки приложения зависит именно от HTTP-запросов, соответственно их уменьшение приведет к быстрой загрузке. Тут все понятно. 

Что можно сделать, чтобы уменьшить количество запросов HTTP?

• Совместите ваши файлы CSS/JS. Вы можете объединить файлы CSS / JS – файлы CSS, а также файлы JS объединить  в один, и не получать несколько файлов с сервера. Также для увеличения скорости загрузки можно уменьшить CSS-файлы. 
• Загружайте только то, что необходимо – загружайте все изображения только тогда, когда это действительно нужно. Эта техника имеет название отложенная загрузка или загрузка по требованию. К примеру, когда пользователь заходит на ваш сайт, изображения не загружаются все сразу, а подгружаются в тот  момент, когда клиент скролит до этого конкретного места.
• Включите кэширование браузера. Разрешите кэширование статических изображений или материалов, которые вы не будете часто менять. При повторном посещении клиентом сайта, необходимости в новом НТТР-запросе не будет и загрузка контента ускорится.
• Предоставьте поддержку HTTP/2 на сервере. Используя для загрузки веб-сайта HTTP/2 вы будете  выполнять только одно соединение с сервером, и одновременно разрешается несколько запросов. Это намного эффективнее, чем создавать новое соединения для каждого ресурса.

2. Отсутствие CDN

Часто пользователь  находится слишком далеко от сервера и это увеличивает время загрузки, поскольку влияет на  НТТР- запросы к серверу.

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

К примеру, если ваш исходный сервер находится в Калифорнии, ваша CDN будет выглядеть следующим образом.

Важно правильно настроить CDN для кэширования ресурса с правильными значениями TTL (Time To Live) для ее результативного использования. Применение CDN существенно сокращает время загрузки страницы.

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

Обратите внимание, что большинство служб CDN имеют свою сетевую магистраль, где они могут обеспечить высокое качество обслуживания по сравнению с Интернетом. Это сократит потерю пакетов, и сократит время загрузки.

Рекомендация: вы можете обмениваться уже используемыми компонентами между проектами, используя Bit (Github).

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

Bit поддерживает Node, TypeScript, React, Vue, Angular и др.

3. Очень большие размеры файлов и страницы

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

Несколько советов:

• Чтобы уменьшить размеры файлов, и время загрузки страницы используйте сжатие (например, с помощью программы Gzip).
• Так же есть и другой метод сжатия, сжатие Brotli, используется в зависимости от типов файлов.
• Для того чтобы уменьшить пропускную способность и время загрузки, можно воспользоваться сжатие файлов HTML или CSS, как показывает практика, это экономит около 50% или 70% размера файла.
• А чтобы сократить еще больше времени загрузки страницы, уменьшите размер изображений, которые используются в приложении.

4. Одновременная загрузка всех ресурсов 

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

Если произвести загрузку файлов JS после других компонентов, тогда это  ускорит время загрузки страницы.

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

У вас есть HTML, вам нужно сделать вызов внешнего JS-файла (defer.js) перед тегом </body>.

Расшифровка  приведенного выше кода: «Подождите, пока загрузится весь документ, затем загрузите файл defer.js».

Обратите внимание, необходимо проверять, все ли в порядке со скриптами

 

5. Много переадресаций

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

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

Чтобы проверить все переадресации, можно воспользоваться инструментом Screaming Frog. Так вы сможете анализировать результат и выявить ненужные вам переадресации. 

На самом деле существует два типа переадресаций:

• переадресации со стороны сервера – быстрые и кэшируемые
• переадресации со стороны  клиента – медленные и не кэшируемые

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

Итоги

Я думаю, что большинство людей экономят свое время для более важных и прибыльных дел, поэтому сайт, который занимает большое количество времени для открытия –  как минимум раздражает и напоминает о старых добрых временах Internet Explorer, как максимум не вызывает доверия  к такому сервису.

Чтобы оценить производительность сайта, вы можете воспользоваться множеством инструментов, таких как Google Pagespeed Insights, Pingdom, YSlow и т.д.  По крайней мере вы будете иметь представление о том, где им в каком месте может тормозить сайт.

Главное  – это устранение основных проблем, а не поиск решений всех  предлагаемых инструментами оценки.

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

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

Связаться с нами вы можете любым удобным для вас способом:

+38 (050) 470-29-17

+38 (094) 710-16-18

  vkarabedyants

   Telegram

 office@itfb.com.ua 

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

Он написал, что люди, работающие на объекте, были в безопасности.

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

Пожар уничтожил дата-центр SBG2 OVH и часть SBG1.

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

Непонятно, как начался пожар.

Среди облачных провайдеров, которые не входят в большую тройку (AWS, Azure и Google Cloud), OVH является одним из самых популярных. Большинство из 27 центров обработки данных расположены в Европе, а некоторые – в Северной Америке и Азиатско-Тихоокеанском регионе.

В 2017 году, когда VMware ушла из бизнеса поставщиков услуг и OVH расширились в Америке, французская компания приобрела бизнес VMware vCloud Air.

Последний крупный кризис, связанный с простоями в OVH, также произошел в кампусе в Страсбурге. В результате отключения электроэнергии в 2017 году весь университетский городок был отключен. На сорок минут кампус в Рубе потерял связь из-за несвязанной ошибки программного обеспечения в сетевом оборудовании.

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

• Строить отказоустойчивую ИТ инфраструктуру в разных дата – центрах
• Обеспечивать отказоустойчивостью сайта, размещать на нескольких серверах
• Локальный бэкап – это не надежное резервное копирование
• Иметь аварийный DRP план на любой случай

Зачастую клиент хочет сэкономить и как результат, может потерять все вот в такой непредвиденной ситуации.

Обращайтесь office@itfb.com.ua мы реализуем наиболее подходящее решение для безопасности вашего бизнеса

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

ТЗ для разработки приложения:

Возможность входа через google и facebook
Поддержка загрузки и воспроизведения медиа
В реальном времени получать события с сервера

Дальше рассмотрим сервисы, которые я буду использовать для проекта

Архитектура веб приложения

WEB сервис

Для реализации логики приложения мы использовали вeб сервис, который размещен в docker контейнере. В AWS существует несколько сервисов для работы с контейнерами, рассмотрим Fargate и Elastic Beanstalk.

Fargate

Современный PaaS на основе ECS (EKS-Elastic Kubernetes Service) или EKS (EKS-Elastic Kubernetes Service) – альтернатива kubernetes. Конфигурируется с использованием task – задачи с указанием необходимых ресурсов для контейнера.

Elastic Beanstalk

Появилась раньше Fargate. C помощью этого средства можно запускать приложение на виртуальных машинах EC2. Так же можно запускать и докер контейнер. Минусы: конфигурация достаточно сложная, а так же длительное время создание машин. Плюсы: Elastic Beanstalk намного дешевле для средних нагрузок.

EC2	Базовая утилизация процессора	Цена за час	Fargate	Цена за час	Отношение цен
t2.micro	10%	$0.0134	1vCPU,1GB	$0.05167	3.85
t2.medium	20%	$0.0536	2vCPU,4GB	$0.11356	2.12
t2.xlarge	22.5%	$0.2144	4vCPU,16GB	$0.268	1.25

В Elastic Beanstalk – очень просо отслеживать сетевой трафик в отличии от fargate.

Application Load Balancer

Elastic Beanstalk и Fargate позволяют выполнять горизонтальное масштабирование. Для обоих систем конфигурация балансировщика производится автоматически. Для настройки маштабирования в Elastic Beanstalk используется раздел Auto Scaling Group, для Fargate в разделе Task Definition.

Application Load Balancer может обрабатывать как HTTP так и HTTPS, но мы используем CloudFront, поэтому нам https не нужен и на инстансы от ALB идет только HTTP.
Для сохранения состояния есть три сервиса

DynamoDB

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

S3

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

Parameters Store

Хранилище для настроек. Есть возможность шифровать хранимые ключи.

Фронтенд

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

В других случаях, клиент работает с бэкендом через сервисы:

Route 53

Это dns от компании AWS.

CloudFront

Это SDN от Amazon. CloudFront на основании заданных правил перенаправляет запросы к контенту к S3 и API-вызова на сервер. Редирект http на https так же настраивается здесь.

AppSync

Используется для быстрой разработки мобильных приложения serverless бэкендом и no-code бэкендом. В данном случае мы его не будем использовать, но хотелось упомянуть о такой возможности. Также он позволяет публиковать и подписываться на сообщения.

Cognito

Выполняет функцию авторизации и регистрации пользователей. Дает возможность создавать User Pool и привязать к аккаунтам Facebook, Amazon, Google.

DevOPS сервисы

Базовые операции для разработки и доставки кода, будут использовать такие сервисы:

IAM-Identity и Access Management используются для управления доступом.

CloudFormation используется для автоматизации деплоя из шаблонов и из програмного кода  через SDK. Стек – единица управления ресурсом.

Обработка кода включает в такие сервисы:

• CodeCommit  – git репозиторий, можно использовать github.
• CodeBuild  – используется для сборки и публикации артифактов. ECR-Elastic Container Repository – хранит образы для докера.
• CodeDeploy – доставка, тут мы используем Fargate или Elastic Beanstalk.
• CodePipeline – оркестрация для конвейера.
• CloudWatch – хранит все логи, а также настаиваются алерты и мониторинг.

ИТОГО

Что бы запустить web приложение, мы задействовали 9 сервисов от AWS, для разработки и доставки кода еще 8 сервисов.

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

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

Хотите перейти в облако не не знаете с чего начать, обращайтесь office@itfb.com.ua, наши специалисты всегда готовы помочь.