Juju ubuntu что это

Обновлено: 06.07.2024

Juju is an open-source operator framework for application and infrastructure management.

Operators encapsulate code, intent, and automation of know-how. Operators are modelled on a human operator with deep knowledge of a complex system, and understanding of how it should operate.

Juju encapsulates operator functionality as Charms. Charms (also known as Charmed Operators) are small, shareable, reusable packages.

Juju enables model-driven operations. Rather than describing configuration in complicated recipes, model-driven operations allow you to describe what your software should actually do, expressed in a clean and portable account of intent.

Juju’s components

  • the Charmed Operator Lifecycle Manager, a hybrid cloud orchestration and management system
  • the Charmed Operator Software Development Kit, a set of tools to create operators and package them as Charms
  • Charmhub, a repository for reusable Charms
  • Juju-as-a-Service, managed solutions for enterprise-scale cloud computing infrastructures

Why Juju?

Juju helps you transition from mere configuration management to application lifecycle management, by transforming your ability to integrate fast-moving open source components into large, complex deployments.

  • deployment, configuration, scaling, integration, maintenance
  • reusable automated management and application domain knowledge
  • configuration discoverability
  • management of Kubernetes-native, container-native and VM-native applications

Juju provides the tools to turn your model description into a reality, repeatedly, across different clouds and in widely different settings.

Contribution and participation

Juju is an open-source project. We welcome all new community members and users.

For support, discussion and development, please join our forum or take part in the conversation in our chat.

Обрывочные сведения из интернета утверждают, что это инструмент управления конфигурацией наподобие Chef, Ansible или Puppet.

Я прочитал наискосок доки по нему, заглянул в репозитории с charms-модулями (аналог кукбуков или плейбуков) и утверждаю, что это не так.

Juju — это скорее VM-agnostic оркестратор (наподобие Nomad или Kubernetes). На нем можно декларативно описывать инфраструктурную конфигурацию приложения: какие приложения у нас запущены, на каких машинах, в скольки копиях, как они связаны с другими сервисами.
Но в отличие от того же Kubernetes он может работать не только с Docker, но и с любыми видами виртуальных машин.

Говорят, ядро, агент и клиент написаны на Golang — и я в них не заглядывал.

Часть же, относящаяся собственно к конфигурации обычно описывается на комбинации YAML и Python (в доках сказано, что кроме питона можно использовать и другие языки).

Как же это все работает?

Disclaimer: эта статья не претендует на полное и точное описание, я скорее рассматриваю ее как способ снизить порог входа для тех, кто захочет взглянуть на Juju и помочь сориентироваться в документации.

Как уже написал выше, в Juju есть несколько компонентов:

  • Контроллер — серверная часть, которая выделяет виртуалки. Для каждого [облачного] провайдера есть свой контроллер (в т.ч. и для не совсем облачных, таких как локальный LXD или Metal as a Service).
    Контроллер — это монолитное приложение из одного компонента. Должна быть запущена минимум одна копия контроллера в каждом провайдере. Есть какое-то HA, но я в это не вникал.
  • Агент — ставится на каждую виртуалку. Есть два вида агентов — для machine и для unit. Кажется, один из них ставится на хостовую машину, а один в виртуалку — подробно я в это тоже не вникал.
  • Клиент — CLI-инструмент для управления всем этим хозяйство.
  • GUI
  • Декларативное описание всех пользовательских компонентов (приложений, машин и т.д.)
  • Пользовательский код для настройки отдельной виртуалки, он называется Charms

(Реально там дерево компонентов больше, но для данного повествования сделаем упрощение, чтобы было проще понять что к чему)

image

На декларативном описании можно строить примерно такие структуры компонентов (графы отрисовываются автоматом через GUI):

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

А вот модули настройки виртуалок, называемые charms (ед.ч — charm) давайте рассмотрим подробнее.

Казалось бы, я знаю Chef, Ansible и Puppet, наверное здесь ничего нового нет, однако это не так. Создатели Juju не стали создавать DSL для декларативного описания ресурсов в системе. Вместо этого они создали фреймворк, который позволит вполне обычный код на питоне или баше сделать идемпотентным и связать его с Juju контроллером.

Устройство Charm

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

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

В декларативной части описываются интерфейсы-зависимости чарма (например, чарм wordpress зависит от mysql, а чарм mysql предоставляет этот интерфейс), совместимости с системами, теги, параметры конфигурации (типа атрибутов кукбука) и программные слои-зависимости (layers) от других чармов (к примеру, большинство чармов включают слой layer:basic ).

В императивных хуках же описывается реакция на всякие внешние события. Например, на событие install устанавливаем нужный пакет, на событие configure его настраиваем, а на событие start запускаем сервис.

Это все пишется на обычном питоне с декораторами (где-то читал утверждение, что писать можно на чем угодно, хоть и на баше, но примеров не видел).

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

Резюме

У Juju очень интересный и необычный подход к описанию и настройке инфраструктуры.

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

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

Мне показалось, что Juju больше нацелен на инфраструктурных программистов (тех, кто написали множество CLI-инструментов на питоне в линуксах 5-7 летней давности), которым теперь надо настраивать сервера, в то время как Chef/Ansible — на админов, которым вместо одного-двух теперь нужно настраивать сотню-другую серверов.

Стоит ли использовать Juju в 2019г?
Не уверен:

  • Новые (cloud native) приложения вы завернете в докер в докер и запустите на кубере или ECS
  • Для "старых" приложений у вас уже наверняка написаны скрипты разворачивания на ансибле или шефе
  • Для новых проектов со "старой" архитектурой — может быть. НО:
  • Про Juju в рунете практически никто не знает, это первая статья на русском языке, которая немного описывает что это такое

Если вы работаете с Juju напишите в комментариях где я ошибся — ведь я всего лишь 2-3 часа почитал к ней доки.

Перед вами необъективный, несерьёзный и нетехнический обзор операционной системы Ubuntu Linux 20.04 и пяти её официальных разновидностей. Если вас интересуют версии ядра, glibc, snapd и наличие экспериментального сеанса wayland — вам не сюда. Если вы впервые слышите о Линуксе и вам интересно понять, как о ней думает человек, который сидит под Убунтой уже восемь лет, то вам сюда. Если вы просто хотите посмотреть что-то не очень сложное, слегка ироничное и с картинками, то вам тоже сюда. Если вам кажется, что под катом куча неточностей, упущений и передёргиваний и напрочь отсутствует логика — возможно, так и есть, но это же нетехнический и необъективный обзор.



Для начала небольшой «въезд» в тему. Есть операционные системы: Винда, МакОсь и Линукс. О Винде слышали все, и все ей пользовались. О МакОси слышали почти все, а пользовались ей не все. О Линуксе слышали не все, а пользовались им только самые смелые и отважные.

Линуксов много. Винда — это одна система, МакОсь — тоже одна. Конечно, у них есть версии: семёрка, восьмёрка, десятка или High Sierra, Mojave, Catalina. Но по сути это одна система, которую последовательно делает одна компания. Линуксов — сотни, и их делают разные люди и компании.

Почему Линуксов много? Сам Линукс — это не операционная система, а ядро, то есть самая важная часть. Без ядра ничего не работает, но ядро само по себе малопригодно для обычного пользователя. К ядру нужно добавить кучу других компонентов, а чтобы всё это было с красивыми окошками, значками и картинками на рабочем столе — ещё и натянуть поверх так называемую графическую оболочку. Ядро делают одни люди, дополнительные компоненты — другие люди, графическую оболочку — третьи. Компонентов и оболочек много, и их можно по-разному смешивать. В итоге появляются четвёртые люди, которые собирают всё вместе и готовят собственно операционную систему в привычном виде. Иначе говоря — дистрибутив Линукса. Сделать дистрибутив может один человек, поэтому дистрибутивов много. Кстати, «российские операционные системы» — это дистрибутивы Линукса, и из российского там — только нескучные обои для рабочего стола отдельные программы плюс сертифицированные средства для работы с гостайной и прочей конфиденциальной информацией.

Поскольку дистрибутивов много, то выбрать сложно, и это становится ещё одной головной болью для любого, кто решил рискнуть и всё-таки попробовать уйти с Винды (или с МакОси). В дополнение, конечно, к более банальным проблемам вида: «ой, Линукс — это сложно», «он только для программистов», «у меня ничего не получится», «я командной строки боюсь». Плюс, как водится, разработчики и пользователи разных дистрибутивов постоянно спорят, чей же Линукс круче.

Дистрибутивы Линукса штурмуют крепость с Microsoft, Apple и Google, но борются между собой, а не с защитниками крепости


Дистрибутивы Линукса единым фронтом сражаются против гегемонии Майкрософта. Автор оригинальной картинки — С. Ёлкин, а недостающие элементы дорисованы автором статьи

Я решил обновить операционную систему на компьютере и стал выбирать. Когда-то я уже так развлекался — скачивал дистрибутивы Линукса и тестировал их. Но это было довольно давно. С тех пор Линуксы изменились, поэтому не помешает протестировать заново.

Из нескольких сотен я взял шесть. Все — разновидности Убунты. Убунта — это один из самых популярных дистрибутивов. На основе Убунты сделали ещё кучу дистрибутивов (да-да, они ещё и так размножаются: из одного Линукса собирается другой, на его базе — третий, потом четвёртый, и так пока новые обои для рабочего стола не закончатся). Я пользовался одним из таких производных дистрибутивов (кстати, российским — Рунту называется), так что и тестировать стал Убунту и её официальные разновидности. Официальных разновидностей семь. Из этих семи две можно не смотреть, потому что одна из них для китайцев, а другая — для тех, кто профессионально работает со звуком и видео. Смотрим оставшиеся пять плюс оригинал. Конечно, очень субъективно и с кучей попутных замечаний.

Убунта

Убунта — это оригинал. На сленге — «ванильная Убунта», от vanilla — стандартный, не имеющий каких-то особенностей. Остальные пять дистрибутивов основаны на ней и отличаются только графической оболочкой: рабочим столом, окошками, панелькой и кнопками. Сама Убунта смахивает на МакОсь, только что панелька не снизу, а слева (но можно переставить вниз). Что всё по-английски — это мне просто лень переключать было, на самом деле там и русский есть.

Рабочий стол Ubuntu 20.04 сразу после загрузки в live-режиме


Убунта сразу после загрузки

Котик, стреляющий глазами — это на самом деле фосса. Похожа на кошачьих, но на самом деле относится к другому семейству. Живёт на Мадагаскаре. У каждой версии Убунты есть своё кодовое название: животное и какое-то прилагательное. Версия 20.04 называется Focal Fossa. Focal — фокус в смысле «центральная точка», а Fossa ещё напоминает о FOSS — Free and Open Source Software, свободное программное обеспечение с открытым исходным кодом. Вот и на картинке фосса фокусируется на чём-то.

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

Activities в Ubuntu 20.04


Учимся переключаться между окнами в Убунте: тянем мышь в сторону Activities, нажимаем, наводим на окно, нажимаем ещё раз. Видите, как всё просто?

Выглядит эффектно, особенно с красивыми плавными анимациями, но в плане удобства — не очень. Ладно бы я только и делал, что музыку слушал и фильмы смотрел, не выходя из браузера — но мне же нужно постоянно переключаться между программами, и 10 одновременно открытых окон — не редкость. А теперь представляем: каждый раз нужно куда-то тащить мышь, что-то там нажимать, снова куда-то тащить (причём искать нужное окно не по заголовку, а по маленькой картинке), снова нажимать… В общем, через час сразу захочешь выкинуть эту систему и больше к ней не возвращаться. Можно, конечно, Альт-Табами переключать окна, но это тоже та ещё фишка.

На Андроид, кстати, смахивает неспроста. В 2011-м какие-то умные люди, делавшие графическую оболочку Убунты, увидели Айпад и подумали: «Это будущее. Давайте сделаем такой интерфейс, чтобы он был как у Эппла и чтобы его можно было использовать на планшете. Тогда на всех планшетах будет стоять наша графическую оболочка, мы в шоколаде, а Винде — капец». В итоге на планшетах Андроид с Ай-Осью, и даже Майкрософт оттуда ушла. Винда живёт и здравствует, а капец пришёл нормальному интерфейсу Убунты. И, конечно, Убунту на планшетах используют только экстремальные энтузиасты (сразу скажу — я даже не пытался). Может быть, и надо откатить всё назад, но за десять лет столько усилий и бабла вложено в этот интерфейс, что его продолжают развивать. Ну, что могу сказать… Как минимум он всё же красивый. А что до удобства использования — вроде можно поставить какие-то дополнения, которые вернут нормальную панель с окошками. Но мне не очень хочется с ними экспериментировать.

Плюс ещё залез посмотреть расход ресурсов — Убунта ест гигабайт оперативной памяти сразу после загрузки. Это почти как Винда. Нет уж, спасибо. В остальном-то вроде нормальная система.

Кубунта

Если Убунта смахивает на МакОсь, то Кубунта — на Винду. Сами посмотрите.

Рабочий стол Kubuntu 20.04 сразу после загрузки в live-режиме


Кубунта сразу после загрузки. Кодовое название — тоже Focal Fossa, но картинка другая

Рабочий стол KDE с несколькими открытыми окнами


Правда напоминает Винду?

Цветовая схема похожа на «десятку», и даже «дзинь» при появлении уведомления — точь-в-точь… Честное слово, не Кубунта, а какая-то Виндубунта. Попытка «косить» под Винду доходит до того, что можно даже настроить кнопки как в Винде — правда, почему-то как в Винде 95-й (посмотрите на скриншоте в настройках слева снизу). Конечно, систему можно «переодеть», потому что всё в Линуксе настраивается, и тогда она перестанет быть похожей на Винду, но это ещё покопаться в настройках нужно. Да, на всякий случай: если включите окошки и кнопки из 95-го, то жрать ресурсов система все равно будет как в 2020-м. Правда, она в этом плане довольно скромная: каких-то 400 Мб памяти после загрузки — это почти ни о чём. Даже не ожидал. Ходили упорные слухи, что «кеды» тормозные и прожорливые. Но вроде нет. В остальном та же Убунта, потому что технически это одна и та же система. Разве что некоторые программы другие, но Файрфокс и Либра-офис тоже на месте.

Убунта-Матэ

Убунта-Матэ — это попытка воссоздать Убунту в том виде, в котором она была до 2011-го. То есть до того самого, когда в оригинале решили делать систему под планшеты и сделали то, что я показывал выше. Тогда какие-то другие умные люди, которые не захотели сдаваться, взяли код старой графической оболочки и стали его дорабатывать и поддерживать. Хорошо помню, что я тогда смотрел на их работу как на попытки создать зомби и думал: «Ну ладно, проект заведомо нежизнеспособный, пару лет покрутится и закроется». А вот оно как — уже почти десять лет живёт и здравствует, даже в число официальных разновидностей Убунты попал. Ну, бывает. Всё же тяга к классике у людей неистребима.

Рабочий стол Ubuntu MATE 20.04 сразу после загрузки в live-режиме


Да-да, тут две панельки! Если что, панели — это вот эти две серые полоски сверху и снизу

Матэ — это MATE, название вот этой зелёнькой графической оболочки. Mate — это матэ, такое южноамериканское растение, поэтому и зелёное. А ещё mate — приятель, так что на «дружелюбность» намекают. Матэ вообще ни на что не похожа — ни на Винду, ни на МакОсь. Похожа она на саму себя, а точнее, на оригинальную придумку из Линуксов 90-х и нулевых: сделать не одну панель с окошками и значками, а две: одну с окошками, другую со значками. Ну и ничего так, получилось. Кстати, можете ещё четыре прямоугольника в правом нижнем углу увидеть — это переключатель рабочих столов. В Винде такая штука недавно появилась, в Линуксе существует с незапамятных времён. Типа можно на одном рабочем столе открыть что-то по делам, потом переключиться на соседний рабочий стол и там ВКонтакте сидеть. Правда, я больше одного рабочего стола почти никогда не использовал.

Ubuntu MATE 20.04 с несколькими открытыми окнами на рабочем столе


Если открыть много окошек, то выглядеть будет вот так

В остальном та же Убунта, и в плане потребления ресурсов и скорости работы — как оригинал. Тоже спокойно отъедает гигабайт памяти после загрузки. Мне вроде и не жалко, но все равно обидно как-то.

Убунта-Баджи

Убунта-Баджи сделала невозможное: стать ещё более похожей на МакОсь, чем Убунта. Баджи — это название ещё одной графической оболочки, если что. Хотя вы, наверное, сами догадались.

РАбочий стол Ubuntu Budgie 20.04 сразу после загрузки в live-режиме


Бесплатная МакОсь Убунту-Баджи сразу после загрузки

Объясняю, как это чудо появилось. Когда в 2011-м какие-то умные люди решили делать Убунту под планшет… да-да, всё тоже тогда и началось :) Так вот, пока одни несогласные экспериментировали с созданием зомби (как оказалось, весьма успешно), другие решили создать вместо зомби Принципиально Нового Человека новую графическую оболочку, которая будет в плане удобства работы примерно как старая и без заточки под планшеты, но зато будет вся такая крутая, модная, технологичная. Делали-делали и получили что-то похожее на МакОсь. Одновременно создатели оригинальной Убунты тоже делали-делали и получили что-то похожее на МакОсь. Но Баджи, по-моему, похожа чуть-чуть больше: всё же панелька со значками сразу снизу, а не сбоку. От этого, правда, она ничуть не удобнее: точно так же не пойми как приходится переключаться между окнами, я даже не сразу понял, куда нажимать.

Ubuntu Budgie 20.04 с запущенным системным монитором сразу после загрузки


Может быть, видите под правым значком такую маленькую-маленькую искорку? Это значит, что программа запущена

Лубунта

Лубунта — это Убунта для бедных компьютеров с небольшой мощностью. «Л» — значит lightweight, то есть легковесный. Ну, я 400 Мб оперативной памяти после загрузки не назову совсем уж «легковесным», но ладно, верим на слово.

Рабочий стол Lubuntu 20.04 сразу после загрузки в live-режиме


Загрузились, сделали селфи…

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

Рабочий стол Lubuntu 20.04 с несколькими открытыми окнами


Олдскульные окошки в виде Винды-95. На самом деле можно сделать более красивые, но это нужно немного повозиться

Зубунта

Зубунта — это ещё одна относительно «легковесная» разновидность Убунты, но с ещё одной графической оболочкой. Графическая оболочка называется Xfce (экс-эф-си-и!), и порой пишут, что это одно из самых некрасивых названий в Линуксе. На жаргоне — «крыска», потому что логотип у неё такой.

Рабочий стол Xubuntu 20.04 сразу после загрузки в live-режиме


В левом верхнем углу можно увидеть значок с мордочкой крысы — это логотип графической оболочки. Да и звёздочками справа, похоже, тоже мордочку нарисовали

Выводы

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

  1. Кубунта
  2. Зубунта
  3. Убунта
  4. Убунта-Матэ
  5. Убунта-Баджи
  6. Лубунта

А так-то не забываем, что дистрибутивов Линукса — сотни. Так что, возможно, вывод — «вообще не Убунта, только суровый российский Альт-Линукс».

Juju is a Charmed Operator Framework, composed of a Charmed Operator Lifecycle Manager and the Charmed Operator SDK. Deploy, integrate, and manage Kubernetes, container and VM-native applications seamlessly across hybrid clouds. Juju drives Day 0 through Day 2 operations in your complex environment.

When you need to.

Deploy, Integrate, & Manage applications across multiple K8s or VM environments

Build complex environments frequently

Manage apps and services across multi-or-hybrid clouds

Manage Day 0 - Day 2 operations at scale

. Juju helps you take control

What is Juju?

When your team is deploying and managing applications across VMs, K8s, Hybrid Clouds, and Multi-clouds — it's easy to get lost in the sprawl of YAML, Charts, Recipes, Playbooks, Plans, scripts, etc.

Juju is software that drives your software. It helps you to take control of all your applications, infrastructure, and environments. You use it to

  • Save your team endless hours of script management
  • Minimize costs
  • Ensure redundancy and resiliency
  • Monitor all activity across substrates
  • Maximise your hybrid cloud architecture

You'll move from configuration management to application management.

A simple example:

You have a hybrid cloud, running workloads from applications, databases, monitoring and more — on Kubernetes and VMs.

  • deploy
  • remove-application
  • upgrade
  • refresh
  • config
  • trust
  • migrate
  • debug-log
  • create-backup
  • add-k8s
  • add-machine
  • add-cloud

Your entire estate

Juju uses Charmed Operators ("Charms") and a Charmed Operator Lifecycle Manager to take control of the deployment, upgrades, integrations, management, and operations of those workloads across your hybrid cloud.

Charms are small applications which package common maintenance functions, to turn Day 0 to Day 2 operations into repeatable and reliable code.

This enables your ops team to manage applications and scenarios rather than fixating on configurations (although they can dive into YAML whenever they like).

With Charmed Operators, you not only deploy or manage individual applications, but you relate them to one another in "models", to handle scaling, management, and cross-service dependencies. Your application model defines which applications provide a service and how they interrelate.

Models, cross-model relations, and model driven operations give you the control to handle deployments and operations at scale, across hybrid clouds, via CLI, or in a visual tool such as the Juju GUI or JAAS.


With software driving your software, your team can take control of all your applications, infrastructure, and environments — in less time — without the headaches of YAML sprawl.

Juju supports

Public Clouds

Private Cloud

Kubernetes

Localhost

Operators

Juju acts as a thin layer on top of your infrastructure that allows all your operational code to talk to each other. And because of this communication layer, a lot of the problems that conventional configuration management systems have just don’t exist anymore.

Konstantin Boudnik, EPAM Systems

Using the modelling ethos brought by Juju allows me to quickly run big data applications in a multitude of places. Be it locally on my laptop, on bare metal or in the Cloud, Juju lets me reuse the same models and code without changing any aspects of my deployment.

Tom Barber, Spicule LTD

Juju enables you to encapsulate each different part of your infrastructure and lets everything talk to each other. So if you have a web server that's managed by Chef and a database that's deployed by a Docker container, you can have the web server talk to the database and the relations between these two very easily.

Merlijn Sebrechts, Ghent University

Juju seamlessly integrates with our current ATS system.

Sara V

I like how easy Juju makes deploying services on most any cloud configuration. It also simplifies the relational setup between said services. I'm quite impressed with how simple it is to work with. I'm still in awe of how simple it was to set up MaaS and Juju.

Abraham S

Easy but powerful cloud provisioning and configuration with one tool. Juju is available on the command line as well as with an easy to install web user interface. The ecosystem provides a large number of charms (packages defining the services and their configuration as well as runtime hooks) and can be used from testing with local LXC containers up to Amazon, OpenStack, Azure, and more.

User in Computer & Network Security

It's so easy and powerful to implement and maintain. I implemented some private charms on my private cloud on MAAS, it works perfect.

User in Biotechnology

Читайте также: