По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В инфраструктуре любого предприятия есть очень много требующих внимания деталей. Например, места для серверов, среды разработки, безопасность, стеки программного обеспечения, обновления программного обеспечения, обслуживание оборудования, что все затраты на обслуживание платформы, как правило, огромны. Компаниям, которые разрабатывают и развертывают приложения, необходимо выделить много ресурсов для поддержания работы платформы - ресурсов, которые в противном случае можно было бы использовать для разработки программного обеспечения.
Поэтому возникла необходимость в облачных платформах. Эти решения используют модель облачных вычислений, чтобы предоставить разработчикам все необходимое для выполнения их работы - от сред разработки на хостах и инструментов баз данных до полных возможностей управления приложениями. Разработчики, работающие в облачной платформе, имеют доступ ко всем ресурсам, необходимым для создания, развертывания и запуска программных приложений. Для больших компаний облачная платформа может обеспечить масштабируемую базу для новых приложений, которые необходимо предоставлять в короткие сроки. При использовании модели "плати по мере роста" нет необходимости в долгосрочных инвестициях в локальные платформы.
Почему "опенсорс"?
Теперь, когда мы заявили о преимуществах облачных вычислений перед традиционными платформами, следующий вопрос заключается в том, почему облачная платформа с открытым исходным кодом является лучшим вариантом, чем запатентованная облачные решения. Самый очевидный ответ - стоимость: лицензии на проприетарные решения всегда предполагают более затратные вложения. Еще одним важным преимуществом является гибкость и свобода выбора из самых разнообразных структур, облаков и услуг.
Платные платформы, с другой стороны, могут привязать вас к инструментам и услугам, которыми они владеют. В обмен они предлагают определенные преимущества, такие как соблюдение соглашения об уровне обслуживания (SLA) и освобождение от препятствий, таких как тестирование и интеграция, но эти преимущества едва ли перевешивают преимущества открытости.
Ниже представлен список облачных платформ с открытым исходным кодом для предприятий, которые сегодня пользуются популярностью на рынке.
Cloud Foundry
Созданный компанией VMWare затем приобретённый компанией Pivotal Software, Cloud Foundry отличается тем, что он доступен как автономное приложение с открытым исходным кодом, что делает его независимым от поставщика. Его можно развернуть в VMware vSphere или других облачных инфраструктурах, таких как HP Helion, Azure или AWS. Или даже можно самостоятельно разместить его на сервере OpenStack.
Благодаря использованию пакетов сборки Cloud Foundry упрощает поддержку среды выполнения и инфраструктуры. При каждой компиляции приложения Cloud Foundry Application Runtime выбирает наиболее удобный для него пакет сборки. Затем buildpack занимается компиляцией приложения и подготовкой его к запуску.
Cloud Foundry разработана для быстрой разработки и развертывания приложений с помощью высокомасштабируемой архитектуры и удобных для DevOps рабочих процессов. Эта технология наряду с другим языками так же, поддерживает языки, как Python, Ruby, PHP, Java и Go. Тем не менее, чтобы правильно вписаться в Cloud Foundry, рекомендуется, чтобы ваш проект соответствовал 12-факторному стандарту приложений - методологии, специально разработанной для разработки оптимальных приложений SaaS.
WSO2
Если часто работаете над сервис-ориентированной архитектурой (SOA), то скорее всего у вас есть большое количество внутренних и внешних API. Это тот сценарий, когда WSO2 в большей степени проявляет себя благодаря своему API-менеджеру, способному обрабатывать весь цикл API от начала до конца. WSO2 обеспечивает соответствие большинству требований, которые могут быть выдвинуты клиентами, включая управление версиями, документацию API и разгрузку SSL.
WSO2 использует концепцию магазина, в которой разработчики могут находить, пробовать и оценивать API. Развертывание является простым и простым, предоставляя множество опций для управления потоком API. Он также предоставляет функцию автоматического восстановления в случае приостановки работы конечной точки. Все эти качества направлены на сокращение времени вывода на рынок, упрощение управления затратами и, в целом, повышение гибкости бизнес-процессов.
Большим плюсом WSO2 API Manager является его простая интеграция с WSO2 Identity Server - решением IAM (Identity and access manager), управляемым API. Эта интеграция предлагает удобную платформу для аутентификации в облачных средах.
Cloudify
Cloudify - это фреймворк оркестрации, предназначенная для моделирования приложений и услуг при автоматизации их жизненных циклов. Фреймворк включает в себя возможность развертывания в любой облачной среде или центре обработки данных. Он также предлагает инструменты для мониторинга всех аспектов развернутых приложений, определения условий отказа и их решения вручную или автоматически.
Одной из наиболее заметных особенностей Cloudify является моделирование проекта на основе TOSCA. Это нововведение позволяет разработчикам использовать YAML для создания чертежей топологий приложения. YAML - считываемый человеком язык сериализации данных, используемый для написания определений на основе спецификации TOSCA, что даёт разработчикам стандартизированный способ описания взаимосвязей между приложениями, системами и компонентами облачной инфраструктуры.
Облачная оркестрация Cloudify обеспечивает прочную базу для управления ИТ и обеспечения безопасности, позволяя пользователям применять ограничения доступа с различными ролями и уровнями разрешений. Для общения с внешними сервисами, такими как контейнеры Kubernetes, облачные сервисы (AWS, Azure, vSphere, OpenStack) и инструменты управления конфигурацией (Pucket, Anulable, Chef), Cloudify использует свой набор официальных плагинов, в то время как многие другие сервисы работают с существующими плагинами.
OpenShift
OpenShift - платформа на базе Kubernetes, с гибким и очень быстрым установщиком и поддержкой большого числа API, что позволяет разработчикам расширять платформу, исходя из своих потребностей. Он построен с учетом безопасности, что иллюстрируется примером: контейнеры должны запускаться от имени обычных пользователей, и когда это не так, OpenShift требует явного переопределения для запуска контейнера.
Использование Kubernetes требует значительного количества серверов, и для его освоения требуется определенное обучение. Именно поэтому эта платформа не подходит для небольших проектов, если в ближайшем будущем она не превратится в более масштабный проект.
Пользователи OpenShift подчеркивают возможность его быстрой установки и настройки, а также простоту обслуживания модулей и надстроек. Еще один плюс - факт наличия собственного Git репозитория. В противовес этому имеется некая сложность в чтении и интерпретации логов. В частности, когда происходит сбой при загрузке проекта, трудно понять, где проблема.
Tsuru
Rede Globo, вторая по величине коммерческая телесеть во всем мире, запустила Tsuru как продукт на базе Docker PaaS (платформа как сервис), способный организовывать и запускать приложения в производственной среде. Это платформа с открытым исходным кодом, поддерживающая сайты с миллионами пользователей, разработанная компанией Globo.com.
Пользователи Tsuru утверждают, что это существенно улучшает время вывода на рынок, не отказываясь от простоты, высокой доступности, безопасности или стабильности. Его можно запускать на различных облачных инфраструктурах, будь то публичная или частная, при условии, что они поддерживаются Docker-машинами. Также он поддерживает практически все известные язык программирования, что даёт разработчикам свободу выбора в соответствии с их предпочтениями.
С помощью Tsuru можно использовать различные хранилища данных, включая базы данных SQL или NoSQL, или альтернативы в памяти, такие как Memcached или Redis. Чтобы управлять приложением, вы можете выбрать один из своих предпочтений и подключить его к приложению. Чтобы управлять приложением, вы можете выбрать между использованием командной строки или веб-интерфейсом, а затем развернуть через Git. Инфраструктура Tsuru займется всеми рутинными делами.
Stackato
Stackato - это полиглотный продукт PaaS, основанный на Cloud Foundry и Docker, который работает поверх облачной инфраструктуры и служит платформой для запуска приложений. Пользователи Stackato говорят, что он предоставляет гибкую и надежную платформу приложений, которая помогает повысить производительность как администраторов облачных вычислений, так и разработчиков. Он хорошо подходит для развертывания корпоративных облачных сред, сочетая гибкость непосредственного доступа к виртуальной машине в облачной инфраструктуре с автоматизированной конфигурацией, обеспечиваемой полнофункциональной системой PaaS. Среди поддерживаемых облачных инфраструктур можно показать HP Cloud Services, Citrix XenServer, AWS, OpenStack, VMware.
В Stackato у каждого приложения есть свой контейнер Linux (LXC), который гарантирует эффективное и безопасное совместное использование ресурсов. Его спектр услуг состоит из Helion Control Plane, который Stackato использует для связи с основным облаком и управления всем циклом услуг; Helion Service Manager - хранилище дополнительных служб, доступных для приложений; Helion Cloud Foundry - гибкая среда выполнения, предназначенная для упрощения хостинга и разработки приложений; Helion Code Engine, сервис непрерывной доставки, интегрированный с репозиториями Git, частными или публичными, и Helion Stackato Console, веб-интерфейс для управления всеми функциями Helion Cloud.
Alibaba
Хотя и сложно представить компанию Alibaba в числе облачных платформах с открытым исходным кодом и PaaS, бизнес Alibaba Cloud Computing растет быстрыми темпами. Она уже завоевала 50% китайского рынка облачных технологий, а также удачно обслуживает рынки за пределами Китая. Например, они начинают оказывать биллинговую поддержку в долларах США по 168 странам и разрабатывать услуги, специально предназначенные для зарубежных рынков.
Сервисы облачных платформ, включенные в предложение Alibaba, включают множество бесплатных функций, включая контейнерные сервисы для Docker и Kubernetes, Container Registry, Auto Scaling и DataWorks, защищенную среду для разработки данных в автономном режиме. Его службы хорошо задокументированы и предоставляют все необходимое, чтобы сразу начать перенос приложений в облако, в том числе много обучающих видеороликов. Следуя нескольким простым шагам и не инвестируя ни цента, Alibaba обеспечивает развертывание приложения в кратчайшие сроки.
Заключение
К счастью для всех разработчиков, облачные технологии становятся более доступными. Пару лет назад, конкурируя за контейнерные технологии (Docker, Kubernetes, Mesos, Nomad, ECS, назовем несколько) угрожали разделить рынок на изолированные отсеки, создавая значительные риски всякий раз, когда нужно было выбрать платформу. Но, несмотря на то, что в наши дни на выбор предоставляются все больше платформ, различия между сегодняшними вариантами с открытым исходным кодом заключаются только в деталях: разных схемах затрат, разных инструментах управления, разных подходах к безопасности. Другими словами, если выбирали одну облачную платформу с открытым исходным кодом и вас она не устраивает, легко можете перейти к другой, не обременяя себя расходами.
В зависимости от технической задачи вы можете выбрать платформу, которая лучше отвечает вашим потребностям и позволяет забыть о таких проблемах, как емкость сервера, промежуточное программное обеспечение, платформы, виртуальные машины, хранилища данных и т.д. После того, как вы освободитесь от всего этого, вы сможете вложить все свои ресурсы и все свое внимание в одно, что действительно важно для вас: как можно быстрее сделать доступным приложение пользователям.
Почитайте первую часть статьи.
Первая проблема. Два роутера работают с одной областью OSPF, и каждый роутер имеет loopback интерфейс, объявленный в OSPF. Вот вывод таблиц маршрутизации:
Как мы можем наблюдать, что роутер R1 узнал о сети 10.2.2.0/24 от роутера R2, но в таблице маршрутизации роутера R2 пусто. Что не так?
Видно, что OSPF не включен на интерфейсе loopback0 роутера R1, так что же мы тогда объявляем в сетях?
Похоже, мы объявляем сеть 10.10.1.0/24, но эта сеть не настроена ни на одном интерфейсе... Сеть 10.1.1.0/24 настроена на интерфейсе loopback0 роутера R1.
Здесь вы видите неправильно введенную команду network. Удалим ее.
R1(config)#router ospf 1
R1(config-router)#no network 10.10.1.1 0.0.0.0 area 0
R1(config-router)#network 10.1.1.0 0.0.0.255 area 0
Давайте удостоверимся, что команда network настроена правильно.
Проблема устранена! Эта проблема может показаться не серьезной, но использование неправильных сетевых операторов - это то, что происходит постоянно. Особенно если мы используем меньшие подсети (например, /27 или /28 или аналогичные), люди склонны делать ошибки с обратными маскам.
Итог урока: убедитесь, что вы настроили правильный сетевой адрес, обратную маску и область.
Видео: протокол OSPF (Open Shortest Path First) за 8 минут
Урок №2
Очередная возможная ситуация. Опять два роутера, но другая проблема. Вот таблицы маршрутизации:
В очередной раз роутер R2 не увидел сеть 10.1.1.0/24. Что интересно, что роутер R1 не имеет сети 10.1.1.0/24 в своей таблице маршрутизации как непосредственно подключенной.
Мы можем проверить, что роутер R1 использует правильную настройку команды network. Поскольку R1 даже не имеет сети в своей таблице маршрутизации, предположим, что проблема с интерфейсом.
Кажется, кто-то забыл применить команду "no shutdown" на интерфейсе.
R1(config)#interface loopback 0
R1(config-if)#no shutdown
Давайте включим интерфейс.
И теперь он появляется в таблице маршрутизации роутера R2. Итог урока: нельзя объявлять то, чего у тебя нет!
Урок №3
Новый урок! Одна область, опять два роутера... мы хотели бы иметь "full connectivity", но не работает OSPF ... вот вывод таблиц маршрутизации:
Роутер R1 не показывает никаких маршрутов OSPF, R2 показывает ... Необходимо выяснить, что не так:
Быстро взглянем на роутер R2, чтобы убедиться, что он действительно объявляет правильную сеть(и). Да это так и есть.
Вывод роутера R1 более интересен ... видно, что у него настроен distribute-list.
В этом заключается наша проблема. Давайте удалим distribute-list.
R1(config)#router ospf 1
R1(config-router)#no distribute-list 1 in
Эта команда отключит его.
Задача решена! Итог урока: знать о distribute-list, запрещающий объявление и / или установку префиксов в таблице маршрутизации.
Урок №4
Взглянем на более сложные проблемы OSPF. На изображении выше мы имеем роутер R1 и роутер R2, но на этот раз мы имеем конфигурацию OSPF с несколькими областями. Вот конфигурация OSPF этих роутеров:
Видно, что все сети были объявлены. Область 2 не связана напрямую с областью 0, поэтому была создана виртуальная связь.
Роутер R1, однако, не увидел сеть 2.2.2.0/24 от роутера R2, но роутер R2 увидел сеть 1.1.1.0/24. Лучше всего начать с виртуальной линии здесь:
Хм, это выглядит не очень хорошо. Виртуальная связь отключена. Обратите внимание на IP-адреса, которые мы видим здесь, это IP-адреса, настроенные на интерфейсах FastEthernet обоих маршрутизаторов.
Всякий раз, когда мы настраиваем виртуальное соединение, нам нужно настроить идентификатор маршрутизатора OSPF другой стороны, а не IP-адрес другой стороны!
Вот ошибка, так что давайте исправим ее.
R1(config)#router ospf 1
R1(config-router)#no area 12 virtual-link 192.168.12.2
R1(config-router)#area 12 virtual-link 2.2.2.2
R2(config)#router ospf 1
R2(config-router)#no area 12 virtual-link 192.168.12.1
R2(config-router)#area 12 virtual-link 1.1.1.1
Вот так должна выглядеть virtual-link, настроенная между идентификаторами маршрутизаторов OSPF.
Сразу после ввода правильных команд появятся данные сообщения в консоли.
Запись OSPF для сети 2.2.2.0/24 появилась.
Урок №5
Другая проблема. Те же роутеры, но появился "домен внешней маршрутизации". Это может быть другой протокол маршрутизации, такой как RIP или EIGRP, который мы будем распространять в OSPF. R2 перераспределяет сеть 2.2.2.0 / 24 в OSPF, но по какой-то причине она не отображается на R1. Чтобы было интересно, мы не будем просматривать конфигурацию OSPF на роутерах.
Нет сети 2.2.2.0/24 на роутере R1, поэтому давайте изучим роутер R2.
Как мы можем видеть, сеть находится в таблице маршрутизации роутера R2 как directly connected.
Как мы можем видеть роутер R2 был настроен для перераспределения напрямую подключенных сетей. Это должно включать сеть 2.2.2.0/24 на интерфейса loopback0.
Однако в базе данных OSPF пусто? Что может быть причиной этого? Возможно, вы помните правила различных типов областей OSPF. Давайте выясним, что это за область!
Вот и объяснение, это stub area! Stub area не допускают LSA type 5 (внешние маршруты). Мы можем либо превратить эту область в normal area или NSSA. Давайте переведем в NSSA.
R1(config)#router ospf 1
R1(config-router)#no area 12 stub
R1(config-router)#area 12 nssa
R2(config)#router ospf 1
R2(config-router)#no area 12 stub
R2(config-router)#area 12 nssa
Изменим тип области на обоих маршрутизаторах. Область NSSA допускает внешние маршруты с помощью LSA type 7.
Наша сеть 2.2.2.0 / 24 теперь в базе данных OSPF маршрутизатора R2.
Итог урока: Stub area не допускают внешних префиксов (LSA Type 5). Либо измените область на NSSA, либо прекратите перераспределение.
Урок №6
Очередная проблема. Проблема default route OSPF. На рисунке имеются роутер R1 и роутер R2, и сеть 192.168.12.0 /24 объявленная в OSPF. Loopback интерфейсы роутера R2 не объявляется в OSPF, но мы используем default route, чтобы роутер R1 мог добраться до них. Здесь представлены конфигурации OSPF:
Видно, что в выводе роутера R2 присутствует команда default-information originate для объявления default route.
Увы, но мы не видим default route на роутере R1. Будем искать неполадки в настройке. Давайте проверим роутер R2:
В таблице маршрутизации роутера R2 не виден default route. Чтобы OSPF объявлял default route, можно использовать два варианта:
Убедитесь, что у вас есть default route в routing table (невозможно объявлять то, чего нет);
Примените команду default-information originate always. Она объявит default route, даже если он не прописан.
R2(config)#ip route 0.0.0.0 0.0.0.0 null 0
Выше первый метод решения проблемы. Мы создадим default route на роутере R2. Обычно указывается default route на ISP роутере, но сейчас другого роутера нет. Мы укажем default route для интерфейса null0, и он будет внесен в routing table.
Правило работает!
R2(config)#no ip route 0.0.0.0 0.0.0.0 null 0
R2(config)#router ospf 1
R2(config-router)#default-information originate always
Итог урока: что бы объявить default route с помощью OSPF, вам нужно иметь default route в таблице маршрутизации или использовать ключевое слово "always".
Урок №7
Немного сложнее проблема... те же два роутера , все в зоне 0. Вот настройки OSPF:
Ничего особенного, все сети объявлены, и мы используем одну область.
Увы ... таблицы маршрутизации пусты! По крайней мере, никакой отсутствует информация о OSPF ... Настройки network выглядят хорошо, так что это хороший момент вникнуть поглубже в OSPF LSDB. Давайте сначала проверим идентификаторы маршрутизатора OSPF:
Здесь мы видим OSPF router ID. Если вы внимательно посмотрите на информацию выше, вы заметите что-то необычное. State full, но роутер R1 не выбрал DR / BDR, а роутер R2 выбрал роутер R1 в качестве BDR.
Мы можем использовать команду show ip ospf database router для поиска информации от определенного соседа OSPF. Роутер R1 говорит нам, adv router is not-reachable. Это плохо.
Роутер R2 также сообщает нам, что роутер R1 недоступен, и если вы посмотрите внимательно, то увидите, что он видит связь как point-to-point. Мы не видим этого в выводе на роутере R1. Это, вероятно, означает, что роутер R1 и роутер R2 используют другой тип сети OSPF, что приводит к разнице в LSDB. Это не позволит нашим роутерам устанавливать маршруты в таблицу маршрутизации!
Теперь мы кое-что выяснили. Тип сети отличается ... широковещательная передача на роутере R2 и точка-точка на роутере R1. Нам действительно удалось установить соседство OSPF с этим, но возникает разница в LSDB.
Произведем исправления.
R1(config)#interface fa0/0
R1(config-if)#ip ospf network broadcast
Изменение типа сети на роутере R1 сделает свое дело.
Наконец "О" появляется в наших таблицах маршрутизации...проблема решена!
Итог урока: убедитесь, что вы используете правильный тип сети OSPF на обоих роутерах.
Урок №8
Очередная внештатная ситуация. OSPF настроено между роутерами R1 и R2, но не все сети объявлены. Loopback интерфейсы роутера R2 перераспределяются в OSPF. Вот настройки обоих роутеров:
Мы наблюдаем команду redistribute connected на роутере R2, которая должна перераспределить сети на интерфейсах обратной связи в OSPF.
Однако здесь ничего нет ...
Обычно было бы неплохо проверить, есть ли distribute list или нет.
Ключ к решению этой проблемы - эта команда. Если вы наберете redistribute connected OSPF будет распространять только classful networks.
R2(config)#router ospf 1
R2(config-router)#redistribute connected subnets
Нам нужно добавить параметр "subnets", позволяющий заставить его выполнять redistribute subnet основных сетей.
Ну вот, наша маршрутная таблица заполнена.
Итог урока: добавьте параметр " subnets " при использовании перераспределения или перераспределяются только classful networks.
Нет времени на приветствия, конфиги горят! Для создания стандартного листа контроля доступа на оборудовании Cisco, нужно зайти в глобальный режим конфигурации и набрать команду:
R1(config)# access-list ACL_NUMBER permit|deny IP_ADDRESS WILDCARD_MASK
Где:
ACL_NUMBER - номер листа, стандартные листы именуются в промежутке 1-99 и 1300-1999;
permit/deny - разрешаем или запрещаем;
IP_ADDRESS/HOST - сетевой адрес;
WILDCARD_MASK - обратная маска;
Не нужно напрягаться и считать wildcard (обратную) маску в голове. Воспользуйся нашим калькулятором подсетей:
Калькулятор подсетей
Как только мы создали лист контроля доступа, его нужно применить к интерфейсу. Пуляем команду:
ip access-group ACL_NUMBER in|out interdace
Синтаксис команды описан ниже:
ACL_NUMBER - номер листа контроля доступа;
in|out - покидает трафик (out) или входит на интерфейс (in);
interface - номер и тип интерфейса;
Пример настройки
В топологии указанной ниже, нам нужно разрешить трафик из управляющей подсети на сервер S1.
Для начала, напишем ACL и разрешим трафик из подсети 10.0.0.0/24 к серверу S1. Сделаем это мы следующей командой:
access-list 1 permit 10.0.0.0 0.0.0.255
Данная команда разрешает весь трафик из подсети 10.0.0, также мы можем указать конкретный хост – тогда трафик будет разрешен только с него:
access-list 1 permit host 10.0.0.1
В конце каждого листа есть скрытая команда deny all – это означает, что трафик из других подсетей будет по умолчанию блокироваться. Если подобный эффект вам не нужен – можно создать лист:
access list 2 permit any any