Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 597 сообщений
Cообщения с меткой

контейнеры - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

[Перевод] Привилегированные порты — причина глобального потепления

Вторник, 11 Июля 2017 г. 23:27 (ссылка)

Мне 37 лет, что по программистским меркам равняется 99 годам. Я достаточно стар, чтобы помнить первые дни публичного Интернета и первых интернет-провайдеров. Впервые я вышел в онлайн через провайдера, который назывался Internet Access Cincinnati (IAC). Он предоставлял доступ по диалапу к серверу Sun SparcStation 10, где пользователи могли запускать почтенные в своей древности терминальные приложения вроде elm (почтовый клиент), emacs, lynx (текстовый веб-браузер), и конечно IRC.



Позже добавили возможность звонить на терминальный сервер CSLIP (предшественник PPP) и подключаться напрямую к Интернету с собственного компьютера под Linux или Windows (при наличии Trumpet WinSock) с настоящим IP-адресом.



Но вернёмся к той SparcStation. Машина была оборудована двумя CPU, которые работали на чудовищной частоте 33 Мгц, и она могла вместить аж 512 МБ памяти, хотя я сомневаюсь, что слоты там были забиты по максимуму. Оперативная память очень дорого стоила в те времена. Сервер с такими скромными ресурсами обслуживал 50-100 активных пользователей одновременно, обрабатывал почту для десятков тысяч, держал IRC-чат, поддерживал ранний HTTP 1.0 через NCSA HTTPd и добровольно выполнял роль FTP-зеркала для Slackware Linux. В целом он неплохо справлялся с нагрузкой и часто показывал аптайм 1-2 месяца.



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



Я вспомнил SparcStation, потому что хотел бы начать с очень глупого вопроса: зачем нам виртуализация? Или контейнеры? Как мы пришли к этому взрыву сложности вложений ОС->VM->контейнеры->… вместо простоты многопользовательских операционных систем?



Виртуализация обходится дорого



Мой стартап ZeroTier (прошу прощения за рекламу) работает на облачной инфраструктуре, разбросанной по многим дата-центрам, провайдерам и континентам. Большинство узлов, которые составляют облачное присутствие, выступают стабильными опорными точками в Интернете и последними ретрансляторами. Они принимают и отправляют пакеты. Им нужна полоса и немного CPU, но очень мало памяти или места на диске. Взять к примеру один из резервных ретрансляторов TCP (TCP fallback relay): он обычно передаёт 5-10 Мбит/с трафика, но программному обеспечению требуется лишь 10 МБ памяти и менее одного мегабайта (!!!) места на диске. Он также использует менее 1% ресурсов CPU.



Однако его виртуальная машина занимает 8 ГБ места на диске и по крайней мере 768 МБ памяти. Всё это нужно для хранения полной базовой инсталляции CentOS Linux, полного комплекта стандартных приложений и инструментов, системных сервисов вроде systemd и cron, а также сервера OpenSSH для удалённого доступа. Большое потребление RAM — прямое следствие виртуализации, эдакого «хака, чтобы обмануть ядро, будто оно работает на собственном оборудовании». Вся эта память должна быть доступна VM, потому что ядра как будто работают на отдельных машинах со своей локальной памятью, так что гипервизор вынужден подчиниться. (Современные гипервизоры могут в некоторой степени резервировать память про запас, но излишнее резервирование повышает риск ухудшения производительности при резком повышении нагрузки).



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



Спросите кого угодно, зачем нам всё это нужно. Он скажет о безопасности, изоляции и масштабируемости — и будет прав.



В старые времена, до виртуализации и контейнеров, компаниям вроде ZeroTier приходилось размещать собственное оборудование в дата-центрах. Это неудобно и не очень выгодно. Виртуализация позволяет обслуживать сотни пользователей с одного очень мощного сервера (моя виртуальная машина на 768 МБ, вероятно, крутится на 16-24-ядерном монстре Xeon с 256+ ГБ памяти).



Сотни пользователей — это же как… хм… та старая SparcStation на 33 МГц...?



Сегодняшний софт на порядки более громоздкий и сложный, чем программы, которые работали на старом сервере IAC, и хотя отчасти это стало результатом увеличения уровней абстракций и ненужного распухания, но при этом нельзя не отметить реальное увеличение функциональности и гигантский рост обрабатываемых данных. Я не говорю, что мы должны впихнуть нагрузку от сотни типичных современных пользователей в кофеварку. Но я считаю, что мы должны иметь возможность вместить хотя бы несколько сайтов Wordpress (это типичный пример задачи, которую принято размещать в виртуальной машине) на Raspberry Pi — на компьютере, который примерно в 100 раз превосходит старый сервер по мощности CPU, в несколько раз по RAM и в 10-20 раз по объёму постоянной памяти.



RPi стоит $30 и потребляет менее 15 Вт. Нужно ли говорить, сколько стоит одна монструозная VM и сколько она потребляет?



Время для Pi!



Проделаем маленький мысленный эксперимент, где попытаемся установить RPi в качестве терминального сервера для группы пользователей, которые хотят вести блоги Wordpress. Веб-сервер и небольшая база данных вместе займут примерно 10-20 МБ памяти, а у нашего RPi — 1024 МБ, так что он сможет хостить по крайней мере 50 сайтов маленького или среднего размера. (В реальности большая часть RAM избыточна или неактивна, так что со свопом или KSM наш RPi захостит несколько сотен сайтов, но будем консервативными).



Сначала установим Linux. Это наследник Unix, многопользовательская операционная система (верно?), так что создадим 50 аккаунтов. Каждый из этих пользователей теперь может залогиниться. Входящая сессия SSH и шелл занимают всего один-два мегабайта в памяти, а у нашего RPi больше тысячи, так что на данный момент всё должно идти гладко.



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



Шаг первый: установить базу данных MySQL.



А, так это просто! Набираем "sudo apt-get install..."



Погодите… sudo? Предоставление прав sudo означает, что вы с тем же успехом могли и не заводить отдельные аккаунты для пользователей.



Оказывается, что вы можете установить MySQL в собственную домашнюю директорию. Если хотите скомпилировать его или вручную распаковать пакет Debian и отредактировать какие-то конфигурационные файлы, то можете сделать это без специальных привилегий. Ему нужно будет использовать папки /home/yourname/… но в итоге вы получите собственный локальный сервер MySQL, работающий в вашем собственном локальном пространстве пользователя.



Шаг второй: сконфигурировать веб-сервер для работы PHP.



Не будем ворчать… снова используем "sudo apt-get install", чтобы загрузить все необходимые компоненты, собрать их вместе и запустить. Оказывается, это тоже можно сделать, и после бритья быка [бесполезные на первый взгляд действия, которые на самом деле необходимы: например, мы решаем проблему, которая решает другую проблему, которая через несколько уровней рекурсии решает реальную проблему, над которой мы работаем, слэнг Массачусетского технологического института — прим.пер.] наш собственный веб-сервер с PHP готов к работе.



Затем вы сталкиваетесь с чем-то вроде "bind: permission denied". Хм? Немного покопавшись, вы находите, что порт 80, то есть веб-порт по умолчанию, является привилегированным портом. Вам нужны права рута, чтобы привязаться к нему.



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



Яйца!



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



Яички — это жизненно важный орган. Размещение их в маленьком мешочке за пределами мужского тела было глупо, не говоря уже о странном внешнем виде. Самки нашего вида сконструированы более логично: их яичники спрятаны глубоко внутри живота, где они гораздо лучше защищены от ударов, пинков, мечей, заборов и старых тёток.



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



Мужские яички находятся за пределами тела, потому что определённые ферменты в мужской сперме лучше функционируют при температуре чуть ниже температуры тела. Это «решение» было принято очень давно, вероятно (если верить самой простой и поэтому наиболее вероятной гипотезе), когда мы либо не были теплокровными, либо имели меньшую температуру тела. Репродуктивные органы — это то, что биологи называют крайне консервативной системой, то есть они не склонны часто изменяться, потому что любые мутации репродуктивной системы с большой вероятностью вычеркнут особь из генетического пула. В результате, «легче» (в смысле пересечения эволюционного графа вероятностей) поместить мужские яички в пикантного вида мешочек между ног, чем вернуться назад и эффективно переработать сперму для работы при более высокой температуре.



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



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



Возьмите эти странные круглые 12-вольтовые штекеры в автомобилях. Изначально они предназначались для прикуривателей сигарет. Когда стали популярными различные портативные электронные устройства, инженеры задумались, как подключить их к автомобилю. Договориться с автопроизводителями на установку розетки не удалось, так же как уговорить пользователей установить розетки самостоятельно механическим способом, но поскольку во всех автомобилях есть прикуриватели… ну тогда… ответ очевиден. Сделаем розетку, которая помещается в разъём прикуривателя. Теперь автомобили часто даже не выпускают с прикуривателями, но в них есть эта розетка в разъёме прикуривателя, потому что куда же человеку подключить свой смартфон?



(USB постепенно заменяет прикуриватели, но в большинстве машин они по-прежнему установлены).



Не выбранный путь



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



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



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



Виртуализация ОС полезна для других целей: для тестирования и отладки кода, для поддержки древнего ПО, которое должно работать на старых (или иных) операционных системах или версиях ядра, и это подливает масла в огонь. В конце концов, вместо адаптации сетевого стека Unix к нуждам мультиаренды мы просто закинули коробки внутрь коробок и пошли дальше.



Всё это сделано за счёт лишнего расхода железа и энергии. Рискну предположить, что тот же 16-24-ядерный Xeon с примерно 256 ГБ RAM, на котором размещается, наверное, меньше сотни 768-мегабайтных VM, мог бы хостить тысячи задач пользователей, если бы они работали напрямую на том же ядре, а не были обвешаны гипервизорами и пухлыми контейнерами. Насколько меньше CO2 попадёт в атмосферу, если каждый дата-центр уменьшить в десять раз?



Контейнеры вроде Docker частично решают проблему. Вы можете сказать, что контейнеризация — это именно та мультиарендность, к которой я стремлюсь, разве что она частично придерживается наследия виртуализации, воспринимая системные образы как гигантские статично связанные бинарники. Это также шаг назад в удобстве пользования. Мне по-прежнему нужны рутовые права, чтобы запустить контейнер. Я не могу (легко) залогиниться в один контейнер и запустить другой, как я делаю с процессами на простой мультиарендной машине Unix. Вместо этого приходится выстраивать массивные консоли центрального управления и инструменты «оркестровки».



Так что можно сделать? Как мог выглядеть путь, по которому мы не пошли?



Мультиарендная работа в сети



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



Шаг первый: убрать привилегированные порты. Думаю, это изменение на 1-2 строчки. Вероятно, достаточно просто удалить оператор if. Сломается всё, что полагалось на не-криптографическую защиту вроде номера порта для безопасности, поскольку такие вещи легко подделать.



Шаг второй: расширить пользовательские и групповые разрешения, а также права владения на сетевые ресурсы, введя маски разрешений UID/GID на чтение/запись/привязку (привязка вместо выполнения) для устройств и IP-адресов. По умолчанию вызов bind() не указывает, что адрес (0.0.0.0 или ::0) будет прослушивать пакеты или соединения на всех интерфейсах, для которых текущий пользователь имеет соответствующее разрешение на привязку, а исходящие соединения по умолчанию будут направляться на первый интерфейс, принадлежащий пользователю.



Шаг третий: вероятно, хорошей идеей будет разрешить в пространстве пользователя создание виртуальных сетевых устройств (tun/tap) по той же причине, по которой пользователи могут создавать свои процессы и файлы. Это не критично, но было бы хорошо. Разрешения для программ вроде tcpdump/pcap тоже придётся изменить в соответствии с новой моделью разрешений для сетевых ресурсов.



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



Не выбранная дорога уже заросла



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



Нам нужно вернуться назад и усилить защиту режима пользователя. Не думаю, что это слишком тяжело. Виртуализация не обеспечивает такую защиту, как многие думают, и атаки вроде Rowhammer доказали, что VM — не панацея. Мы потратили невероятное количество человеко-часов на разработку крепкой и безопасной виртуализации и на разработку цепочки инструментов для этого, не говоря уже о том, сколько потрачено на создание экосистемы контейнеров. Думаю, что части этих усилий было бы достаточно, чтобы защитить user-space на минимальном хосте Linux от атак с повышением привилегий и утечек.



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



Конечный результат будет немного похож на контейнеризацию, но без неуклюжести, раздутости, изобретения велосипеда и неудобства. Вы можете развёртывать приложения в git, запускать git checkout и git pull по ssh, а оркестровка будет выполняться либо локально, либо на манер P2P, и вы сможете просто залогиниться на машину и запустить что-то, без необходимости продираться через сложную инфраструктуру управления контейнерами. Приложения станут легче, потому что большинству программ достаточно общих стандартных библиотек (libc, stdc++ и др.) и стандартных инструментов в системе, если нет каких-либо непреодолимых ограничений, вроде проблем с с совместимостью библиотек.



Заключение



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



Цель этой статьи — показать, как маленькие решения, о которых никто не думал, могут повлечь драматические последствия для будущей эволюции технологии (и общества). Решение 1970-х годов использовать номера портов как встроенный сигнальный механизм для проверки безопасности между системами может оказаться ошибкой на триллион долларов, которая направила эволюцию платформы Unix по пути гораздо большей сложности, стоимости и большего потребления ресурсов.



Но погодите, может, не всё ещё решено. Существует более десятка дистрибутивов Linux, и большинство из них работает примерно одинаково. Переход на новую парадигму станет интересным способом выделиться для одного из этих дистрибутивов. Первым делом нужно реализовать сетевые разрешения вроде описанных выше — и предложить патч для ядра. Для обратной совместимости можно сделать так, например, что разрешения активируются через настройку sysctl, или можно выпустить модуль (если модули способны производить такие глубокие изменения).
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/332896/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как Яндекс создавал курс по C++, или Почему нам всё пришлось переписать

Четверг, 06 Июля 2017 г. 16:09 (ссылка)

В Яндексе C++ — один из основных языков, на нём написан наш поиск. Его развитие нам настолько важно, что больше года назад по инициативе Яндекса была создана российская рабочая группа по стандартизации «плюсов». Через неё у всех разработчиков русскоязычного пространства есть возможность влиять на развитие языка.







Недавно Физтех, Яндекс и ШАД запустили ещё один курс на платформе Coursera — «Основы разработки на C++: белый пояс». Он посвящён знакомству с С++. Я расскажу, для кого этот курс, как мы его готовили, что получилось в итоге и каковы наши дальнейшие планы.



Как всё началось, было выброшено и началось снова



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



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

Ребята! У меня плохие новости. Я осознал, что наш первый курс — ***** :(


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



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



Наверное, всем понятно, в чём тут проблема. Чтобы пользоваться std::vector, совершенно не обязательно знать, как устроены шаблоны и даже что это такое.



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



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



Что получилось



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



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



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



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



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



Что именно рассказываем



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



Доступ к обязательным заданиям стоит около 1600 рублей, но студенты могут подать в Coursera заявку на финансовую помощь и получить доступ бесплатно. Все видео и необязательные задания — бесплатные по умолчанию.



Программа курса выглядит так:



Неделя 1



Обзор возможностей С++
Hello, world

Обзор типов

Операции с простыми типами

Операции с контейнерами

Языковые конструкции
Компиляция, запуск, отладка
Установка Eclipse

Создание проекта в Eclipse

Отладка в Eclipse
Операции
Присваивание

Арифметические

Логические
Условные операторы и циклы



Неделя 2



Функции
Синтаксис

Передача параметров по значению

ссылки как способ изменить переданный объект

const-ссылки как способ сэкономить на копировании

const защищает от случайного изменения переменной
Контейнеры
std::vector

Std::map

Std::set

Взгляд в будущее: обход словаря с помощью structured bindings


Неделя 3



Алгоритмы и лямбды

min, max, sort

count, count_if, лямбды

современный аналог std::transform — for (auto& x: container)
Видимость и инициализация переменных

ООП

Введение в структуры и классы


Неделя 4



ООП: примеры

Работа с текстовыми файлами и потоками

Перегрузка операторов

Встраивание пользовательских типов в контейнеры

Исключения



Неделя 5 — курсовой проект



antoshkka, который участвует в работе группы по стандартизации, помогал нам и с курсом: «Язык C++ красив, быстр, используется большинством крупных IT компаний, а специалисты по этому языку ценятся во всём мире. К несчастью, многие курсы и учебники по C++ на самом деле учебники по «С», а с такими знаниями вам придётся несладко. Поэтому мы подготовили курс по правильному C++, с классами и без утечек памяти. Если ты знаешь любой другой язык программирования и хочешь открыть для себя мир правильного C++, то наш курс для тебя».
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/332556/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Сравнение производительности сетевых решений для Kubernetes

Четверг, 06 Июля 2017 г. 08:45 (ссылка)

https://habrahabr.ru/post/332432/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Docker 17.06 и Kubernetes 1.7: ключевые новшества

Понедельник, 03 Июля 2017 г. 08:30 (ссылка)



Прошлая неделя подарила два «вкусных» релиза из Open Source-мира контейнеров: практически одновременно обновились Docker (версия 17.06) и Kubernetes (версия 1.7). Какие возможности они принесли? В статье представлена информация из анонсов и release notes этих релизов с небольшими уточнениями по некоторым из ключевых изменений.



Docker CE 17.06



28 июня был представлен Docker CE (Community Edition) 17.06 — первый выпуск контейнерной системы, собранный с помощью проекта Moby, анонсированного в апреле. Подробнее о Moby мы уже писали.



Сборка в несколько этапов



Главной фичей релиза стала поддержка многоэтапных сборок (multi-stage builds), суть которой заключается в возможности описывать в одном Dockerfile несколько этапов сборки образа для того, чтобы в конечный образ не попадали промежуточные данные, которые не требуются. Очевидный пример, который приводят в Docker: Java-разработчики обычно используют Apache Maven для компиляции своих приложений, однако Maven не нужен в конечном контейнере (образе) для запуска этих приложений. Теперь можно оформить Dockerfile таким образом, что сам Maven будет использоваться в промежуточном образе (для сборки), но не попадёт в конечный (для запуска).



Вот вариант Dockerfile для простого приложения на Java Spring Boot:



FROM node:latest AS storefront

WORKDIR /usr/src/atsea/app/react-app

COPY react-app/package.json .

RUN npm install

COPY . /usr/src/atsea/app

RUN npm run build



FROM maven:latest AS appserver

WORKDIR /usr/src/atsea

COPY pom.xml .

RUN mvn -B -f pom.xml -s /usr/share/maven/ref/settings-docker.xml dependency:resolve

COPY . .

RUN mvn -B -s /usr/share/maven/ref/settings-docker.xml package -DskipTests



FROM java:8-jdk-alpine

WORKDIR /static

COPY --from=storefront /usr/src/atsea/app/react-app/build/ .

WORKDIR /app

COPY --from=appserver /usr/src/atsea/target/AtSea-0.0.1-SNAPSHOT.jar .

ENTRYPOINT ["java", "-jar", "/app/AtSea-0.0.1-SNAPSHOT.jar"]

CMD ["--spring.profiles.active=postgres"]




Как видно, две подготовительные стадии здесь используют Node.js и Apache Maven для сборки приложения, однако результирующий образ будем компактным, не имея в своём составе ни Node.js, ни Maven.



Примечание: До настоящего времени у себя в компании мы для этих целей использовали фичу под названием артефакты в собственной Open Source-утилите dapp (её обзор см. здесь).



Логи и метрики



Метрики Docker теперь могут использоваться в плагинах. Для демонстрации приводится пример плагина, который проксирует запросы на метрику, доступную в нём:

$ docker plugin install --grant-all-permissions cpuguy83/docker-metrics-plugin-test:latest
$ curl http://127.0.0.1:19393/metrics


Но это лишь демонстрация, а реальное предназначение этого новшества — отправлять с помощью плагинов собранные метрики в какой-либо внешний сервис или делать их доступными для сборки другим сервисом (например, Prometheus).



Плагины теперь также могут использоваться и для логов (т.е. для реализации logging drivers), а вывод списка всех драйверов журналирования добавлен в docker info. Кроме того, реализацию docker service logs, которая с прошлого релиза (17.05) может показывать и логи индивидуальных заданий (/task/{id}/logs в REST), перенесли из ветки Edge в Stable, поэтому теперь легко получить обобщённые логи для всего сервиса, запущенного в Swarm.



Сеть



Стала возможной привязка сервисов к сетям внутри узла (node-local): Host, Macvlan, IPVlan, Bridge, local-scope. Приводимый для Macvlan пример — это создание специфичных для узла сетевых конфигураций на рабочих узлах и сети на управляющем узле, которая будет их применять:

[Wrk-node1]$ docker network create --config-only --subnet=10.1.0.0/16 local-config
[Wrk-node2]$ docker network create --config-only --subnet=10.2.0.0/16 local-config
[Mgr-node2]$ docker network create --scope=swarm --config-from=local-config -d macvlan
mynet
[Mgr-node2]$ docker service create --network=mynet my_new_service


Кроме того, во внутренние алгоритмы Service Discovery привнесены изменения, которые призваны улучшить логику её работы.



Swarm



Ряд новшеств получил режим Swarm, а в частности:


  • объекты конфигурации (Configuration Objects), позволяющие безопасно передавать информацию о конфигурации по аналогии с тем, как это делалось для секретов:

    $ echo "This is a config" | docker config create test_config -
    $ docker service create --name=my-srv --config=test_config …
    $ docker exec -it 37d7cfdff6d5 cat test_config
    This is a config



  • функция ротации CA-сертификатов в системе public key infrastructure (PKI), применяемой для безопасного деплоя системы оркестровки контейнеров (docker swarm ca --rotate);

  • поддержка событий (ранее были доступны вне Swarm) для получения в реальном времени данных о сервисах, узлах, сетях, секретах;

  • новый флаг --datapath-addr для docker swarm init, указывающий сетевой интерфейс для изоляции заданий управления (control traffic) от данных приложений (data traffic) — полезно в случае приложений, производящих большую нагрузку на ввод/вывод;

  • возможность указывать место хранения секрета в контейнере (вместо традиционного /var/run).



Более подробный лог изменений в Docker 17.06 вместе с ссылками на коммиты можно найти в Docker CE release notes. А для любителей смотреть и слушать есть 8-минутное видео с рассказом и демонстрацией основных новшеств.



Kubernetes 1.7



29 июня был представлен Kubernetes 1.7, главными нововведениями которого названы улучшения в безопасности, поддержке stateful-приложений, расширяемости платформы. Что за этим стоит?



Безопасность




  • Объявлен стабильным Network Policy API, позволяющий настраивать правила, определяющие (и ограничивающие) взаимодействие между подами.

  • Node authorizer, позволяющий ограничивать API-запросы kubelet (к секретам, подам и другим объектам узла).

  • Альфа-версия шифрования секретов и других ресурсов, хранимых в etcd.

  • В kubelet TLS bootstrapping добавлена поддержка ротации сертификата клиента и сервера

  • Логи Audit, хранимые сервером API, стали более настраиваемыми и расширяемыми с поддержкой фильтрации событий и webbooks, а также стали предоставлять больше данных для аудита системы.



Поддержка stateful-приложений




  • Бета-версия функции автоматических обновлений StatefulSet, используемых для деплоя stateful-приложений. Стратегия обновлений определяется полем spec.updateStrategy, поддерживающим сейчас два значения: OnDelete и RollingUpdate.

  • Поддержка в StatefulSets более быстрого масштабирования и запуска приложений, не требующих строгой очередности, настраиваемой теперь через Pod Management Policy. Такие приложения теперь могут запускаться параллельно и без ожидания получения подом определённых статусов (Running, Ready).

  • Альфа-версия локального хранилища (Local Storage): в StorageClasses внутри StatefulSets теперь можно получить доступ к локальному хранилищу через стандартный интерфейс PVC/PV.

  • Умный откат (и история изменений) при обновлениях DaemonSets.

  • Новый плагин StorageOS Volume, реализующий постоянные томы хранения высокой доступности во всём кластере (из локального или подключённого к узлу хранилища).



Расширяемость




  • Агрегация API позволяет расширять возможности Kubernetes собственными API. Прослойка агрегации работает вместе с kube-apiserver и ничего не делает, пока не зарегистрирован ни один ресурс для расширения API. Регистрация API выполняется через объект APIService, который реализуется через extension-apiserver внутри пода, работающего в кластере Kubernetes.

  • В Container Runtime Interface (CRI) добавлены новые RPC-вызовы для получения метрик контейнера. Добавлена альфа-версия интеграции с containerd, поддерживающая базовый жизненный цикл пода и управления образами.



Другое




  • Альфа-версия поддержки внешних контроллеров Dynamic Admission, позволяющих добавлять API-серверу бизнес-логику при модификации объектов.

  • Альфа-версия Policy-based Federated Resource Placement, что позволяет определять основанные на политиках решения по федеративным ресурсам (с использованием внешнего движка политик, например, основываясь на требованиях к цене или производительности).

  • На смену Third Party Resource (TPR) пришли Custom Resource Definitions (CRD), которые предлагают «более ясный API» и решают ряд проблем, зафиксированных во время бета-тестирования TPR. Полностью TPR будут убраны в Kubernetes 1.8 (доступно руководство по миграции).


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/332160/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Зачем нужен Kubernetes и почему он больше, чем PaaS?

Понедельник, 26 Июня 2017 г. 08:52 (ссылка)





В большой production пришёл не только Docker, но и Kubernetes. И если даже с контейнерами далеко не всегда всё достаточно просто, то уж «кормчий» и подавно остаётся за гранью правильного понимания среди многих системных администраторов, DevOps-инженеров, разработчиков. В этой небольшой статье предпринята попытка ответить на один из вечных вопросов (в контексте Kubernetes) с помощью наглядного объяснения идеи и особенностей данного проекта. Возможно, именно этого вам не хватало для того, чтобы начать плотное знакомство с Kubernetes или даже его эксплуатацию?



Соучредитель и архитектор крупного онлайн-сервиса Box (около 1400 сотрудников) Sam Ghods в своём прошлогоднем выступлении на KubeCon указал на типовую ошибку восприятия Kubernetes. Многие рассматривают этот продукт как очередной фреймворк для оркестровки контейнеров. Но если бы всё действительно было так, то зачем его разработчики неустанно напоминают про «корни Kubernetes API, уходящие в архитектуру*, создаваемую более 10 лет в рамках проекта Google Borg»?..



Google Borg — это менеджер кластеров, предназначенный для параллельного запуска тысяч задач, распределённых по тысячам приложений, запускаемых на многочисленных кластерах. Именно эту архитектуру и унаследовал Kubernetes, перенося кластерные идеи на современную почву контейнеров. Чем же это отличается от многочисленных облачных платформ, существующих сегодня? Начнём с самого понятия платформы.



* Архитектура Kubernetes создана таким образом, что позволяет расширять эту платформу, но разработчиков при этом просят следовать основополагающим принципам.



Kubernetes как платформа



Архитектор Box даёт такой вариант определения: «Платформа предоставляет уровень абстракции, забирающий у вас какую-либо проблему, чтобы вы могли творить поверх неё [не думая о ней]». Примеры: платформа Linux даёт возможность исполнять системные вызовы вне зависимости от аппаратного обеспечения компьютера, а платформа Java — исполнять приложения вне зависимости от операционной системы. Какова же должна быть платформа для запуска приложений, созданных по принципам микросервисной архитектуры?



Ключевые характеристики такой платформы — портируемость и расширяемость. Каждая облачная платформа предлагает свои варианты для достижения этих целей. Например, для автоматического масштабирования у AWS имеются Auto Scaling Groups, у Google Cloud Platform — Autoscaler, у Microsoft Azure — Scale Set, у OpenStack — autoscaling API в Heat. Всё это само по себе неплохо, т.к. потребности выполняются, однако у конечного пользователя начинаются сложности. Чтобы разместить приложение, для каждого сервисного провайдера необходимо поддерживать его механизмы: добавлять поддержку API, учитывать специфику работы используемой реализации и т.п. Вдобавок, всем этим решениям не хватает системы обнаружения сервисов для по-настоящему удобного и автоматизированного развёртывания микросервисов. А если вам нужно быть гибким и иметь возможность размещать приложения в разных окружениях (в публичном облаке, в своём дата-центре, на серверах клиента…)?







В этом заключается первый плюс и суть Kubernetes как платформы, то есть по-настоящему универсальной системы для развёртывания приложений, физическое размещение которых может производиться где и как угодно: на голом железе, в публичных или частных облаках вне зависимости от их разработчиков и специфичных API. Но здорово в Kubernetes не только то, где запускать, но и что: ведь это могут приложения на разных языках и под разные ОС, они могут быть stateless и stateful. Поддерживается принцип «если приложение может запускаться в контейнере, оно должно отлично запускаться в Kubernetes».



Предназначение Kubernetes как платформы — предоставить базовую, абстрактную платформу как услугу (Platform as a Service, PaaS), сохранив гибкость в выборе конкретных компонентов этой PaaS.



Kubernetes и PaaS



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


  • Kubernetes не предлагает никаких встроенных служб для обмена сообщениями, обработки данных, СУБД и т.п.

  • Kubernetes не имеет своего магазина с готовыми сервисами для деплоя в один клик.

  • Kubernetes не деплоит исходный код и не собирает приложения. Процессы непрерывной интеграции (CI) поддерживаются, но их реализация оставлена для других инструментов.

  • Аналогично для систем журналирования и мониторинга.



Таким образом, если в PaaS обычно делается акцент на предоставление функциональных возможностей, то в Kubernetes первичен универсальный, абстрактный подход. Несмотря на то, что Kubernetes предлагает ряд функций, которые традиционно присущи PaaS: развёртывание приложений, масштабирование, балансировка нагрузок, журналирование и т.п., — платформа является модульной и предлагает пользователям самим выбирать конкретные решения для тех или иных задач. Такой подход сделал Kubernetes базой для таких PaaS, как OpenShift от Red Hat и Deis.



Заключение



Kubernetes следует принципу, к которому обычно (впрочем, не всегда) стремятся в стандартах. Его хорошо проиллюстрировал Бьёрн Страуструп в своей классической книге «The C++ Programming Language»:

Что должно быть в стандартной библиотеке C++? Идеалом для программиста является возможность найти каждый интересный, значимый и разумно обобщённый класс, функцию, шаблон и т.п. в библиотеке. Однако вопрос не в том, «что должно быть в какой-то библиотеке», а в том, «что должно быть в стандартной библиотеке». И ответ «Всё!» — первое разумное приближение к ответу на первый вопрос, но не последний. Стандартная библиотека — то, что должен предоставлять каждый автор и делать это так, чтобы каждый программист мог на это положиться [т.е. действительно нуждался в этом — прим. перев.].


Применительно к Kubernetes можно сказать, что эта система — фундамент, та самая «стандартная библиотека» для построения PaaS и других подобных решений.







P.S. Если хотите разобраться в техническом устройстве и практике применения Kubernetes — смотрите видео из моего недавнего доклада «Наш опыт с Kubernetes в небольших проектах». Для более подробного и глубокого погружения мы готовим цикл статей по Kubernetes — подписывайтесь на хаб и ожидайте их уже в ближайшее время.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/327338/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<контейнеры - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda