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


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

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

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

Саммит к нам приходит…

Среда, 20 Апреля 2016 г. 23:14 (ссылка)

Автор: Илья Стечкин



Сегодня напомним вам о том, как устроена жизнь OpenStack-сообщества. Летом прошлого года мы уже рассказывали вам о таком явлении, как всемирный OpenStack-саммит. Точнее — показывали некоторые “картинки с выставки”. Но не объяснили, как эти картинки правильно смотреть. Пришло время исправить оплошность.



Итак, всемирный OpenStack-саммит — это главное событие нашей индустрии. Он проходит два раза в год: осенью и весной. Как правило, в календаре каждого истового “опенстекаря” под это мероприятие отводится неделя. Точнее было бы говорить не об одном, а о двух мероприятиях, которые пока что проходят в одно время и в одном месте: это OpenStack Summit и Design Summit. Наш Словарь контрибутора так определяет эти термины:



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



Злые техноязыки утверждают, что “саммит уже не тот” и что маркетинговая составляющая стала доминировать над технической. А я от себя скажу: может быть это и к лучшему. Ведь, в конце концов, чтобы повторить успех Linux, сообществу OpenStack необходимо перестать вариться в собственном соку и сделаться привлекательным для тех, кто может превращать инициативу технарей в деньги. А это, в большинстве случаев, люди не технические. И рассказывать о возможностях создаваемой технологии им нужно просто. Тоже самое касается интерфейсов: они должны становиться (и становятся, что радует!) более дружественными по отношению к пользователям. В противном случае, каким бы функциональным ни был открытый софт, он будет проигрывать проприетарным решениям за счет “упаковки”. Встречают, нравится это нам или нет, по одежке. А UI — это и есть “одежка” программного продукта.



Для любителей (и профессионалов) хардкора есть Design Summit. Дина Белова со товарищи так определяет, что такое дизайн-саммит:



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



Кому-то, наверное, станет удобнее. Но для работодателей, определенно, станет дороже, поскольку командировочные расходы основных инженеров вырастут вдвое. Вот радости будет у финансистов… Что-то мне подсказывает, что поэтому разделение двух саммитов вряд ли произойдет в обозримом будущем.



Теперь, когда мы разобрались с тем, какое значимое событие грядет на следующей неделе (весенний саммит в этом году пройдет в Остине, США, штат Техас, в период с 25 по 29 апреля), давайте бросим быстрый взгляд на программу.



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



Например, американский телеком-гигант AT&T использует для своих облачных решений MOS (Mirantis OpenStack) и будет рассказывать о своем опыте работы с OpenStack в понедельник, 25 апреля.



Чуть позже в тот же день о своем пути к OpenStack расскажет крупнейший европейский автопроизводитель Volkswagen Group. Вы ведь уже слышали об этом проекте, правда?



В четверг, 28 апреля, будет представлен кейс компании G-Core по переносу части инфраструктуры Wargaming c VMware на OpenStack. Эту историю мы тоже успели рассказать всем заинтересованным читателям на русском языке.



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



Если вы вдруг все-таки едете на саммит, то примите к сведению: оргкомитет, как всегда, выпустил мобильное приложение для планирования времени. Приложение доступно для устройств на iOS и Android. Душевно рекомендую воспользоваться. И не забудьте прогуляться по “ярмарке тщеславия” — выставочная зона с каждым полугодьем становится все зрелищнее, а сувениры, сюрпризы и подарки — дороже. Наш стенд — A41, и мы приготовили для своих гостей нечто исключительное! Заходите на огонек!



Что касается сугубо технической части программы, то все как обычно: контейнеры (куда ж без них?), big data, управление ИТ-инфраструктурой, разработка и менеджмент приложений, и даже чуть-чуть интернета вещей (IoT). Мы постараемся держать вас в курсе событий с помощью нашего русскоязычного аккаунта в Facebook и англоязычного Twitter-аккаунта, а по итогам саммита, наверное, запилим отдельный блог-пост.



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

https://habrahabr.ru/post/282073/

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

Хранение круп. Компактно, герметично и красиво.

Среда, 06 Апреля 2016 г. 23:19 (ссылка)


 



 










 




Использование коллекции компактусов Tupperware – самый короткий путь к порядку на полках Вашей кухни. Вы забудете что такое жучки и пищевая моль!



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



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


 


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


Описание



·                 Коллекция овальных компактусов посуды Tupperware представлена

моделями с пятью размерами. http://tuppersale.blogspot.com/2015/10/blog-post_13.html#more


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


·                 Крышки компактусов выпускаются двух видов. Первая модель - без клапанов. Это обычная крышка второго класса.


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


·                 Обе крышки клапанов фиксируются в открытом положении, поэтому при переворачивании контейнера клапан не закроется.




Применение и преимущества

· Любые сыпучие продукты, такие как крупы, бобовые, макаронные изделия, мука, песок, орехи и сухофрукты при герметичном хранении сохранят свое качество гораздо дольше.

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

· Если правильно скомбинировать изделия по высоте, то их можно выставить единым блоком.

· Благодаря своей овальной форме компактус свободно удерживается одной рукой.

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

· Размеры компактуса позволяют ставить емкость также на дверцу холодильника.

· Во время транспортировки готовых блюд в контейнере используйте крышку 2-го класса без клапанов.


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

Немного о контейнерах

Понедельник, 28 Марта 2016 г. 10:09 (ссылка)





Назовите любую технологическую компанию, и практически со 100% вероятностью окажется, что она заинтересована в продвижении контейнерных технологий. Google – конечно. IBM – да. Microsoft – разумеется. Вот и VMware не смогла пройти мимо.



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



«Теперь контейнеры станут полноправными элементами vSphere. Можно управлять как традиционными приложениями внутри виртуальных машин, так и приложениями следующего поколения на базе контейнеров. Обе технологии будут работать бок о бок на одной платформе», – говорит Кит Колберт (Kit Colbert), директор по облачным приложениям VMware.



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



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



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



Кажется, что контейнеры укладывают на лопатки ВМ по всем статьям. И это было бы правдой, если бы сравнение на этом заканчивалось. Однако вопрос все же несколько сложнее и шире, чем простое «куда поместится больше приложений».



Первая и самая серьезная проблема, которая часто упускается из виду – это безопасность, кто бы что ни говорил. Дэниэл Уолш (Daniel Walsh), инженер по безопасности Red Hat, опубликовал статью «Пустые контейнеры». В ней рассматривается Docker, который в качестве основы использует libcontainers. Libcontainers взаимодействует с пятью пространствами: Process, Network, Mount, Hostname, Shared Memory.



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



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



Вот три совета, которые дает Уолш по этому поводу:




  • Удалите привилегии;

  • Старайтесь не запускать службы с root-правами;

  • Всегда учитывайте, что root-права могут действовать и вне контейнера.



Но безопасность не является единственной проблемой. Еще существует проблема обеспечения качества. Допустим, что веб-сервер NGINX в состоянии поддерживать X контейнеров, но достаточно ли вам этого? Включен ли туда обновленный балансировщик TCP? Развернуть приложение в контейнере довольно легко, но если ошибиться с выбором компонентов, то вы просто потратите время впустую.



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



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



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



Здесь на помощь придут микроконтейнеры, которые содержат только библиотеки операционной системы и другие зависимости, требуемые для запуска приложения, и само приложение. Вы увидите, как приложение, которое занимало 643 МБ, будет занимать 29 МБ, что в 22 раза меньше.







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



На эту тему есть неплохое поясняющее видео:









Так как же создать эти микроконтейнеры? Лучше всего начать со scratch-образа, в котором нет абсолютно ничего. С его помощью вы можете создать самый маленький образ для своего приложения, если вам удастся скомпилировать проект в один бинарный файл без зависимостей, как это позволяет сделать Go. Например, этот образ содержит веб-приложение на Go и весит всего 5 МБ.



Однако не все пишут программы на Go, потому, вероятно, у вас будут несколько зависимостей, и scratch-образ вам не подойдет. Воспользуемся Alpine Linux. Образ Alpine весит всего 5 МБ. Поэтому для нашего простого приложения на Node Docker-файл примет следующий вид:



FROM alpine
RUN apk update && apk upgrade
RUN apk add nodejs


Теперь, чтобы добавить код к образу, нужно прописать еще пару дополнительных строк:



FROM alpine
RUN apk update && apk upgrade
RUN apk add nodejs

WORKDIR /app
ADD . /app
ENTRYPOINT [ "node", "server.js" ]


Код приложения и подробные инструкции можно найти здесь.



Такие образы Docker содержат только необходимые компоненты для работы приложения. Ничего лишнего. Таков мир микроконтейнеров.



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

https://habrahabr.ru/post/279229/

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

Контейнеры: Поиски «магического фреймворка» и почему им стал Kubernetes

Суббота, 12 Марта 2016 г. 15:07 (ссылка)





Мы в «Латере» занимаемся созданием биллинга для операторов связи. В блоге на Хабре мы не только рассказываем об особенностях нашей системы и деталях ее разработки (например, обеспечении отказоустойчивости), но и публикуем материалы о работе с инфраструктурой в целом. Инженер проекта Haleby.se написал в блоге материал, в котором рассказал о причинах выбора в качестве инструмента оркестрации Docker-контейнеров технологии Kubernetes. Мы представляем вашему вниманию основные мысли этой заметки.



Предыстория



Инженерная команда проекта изначально использовала методологию непрерывного развертывания (continuous delivery) Jenkins для каждого сервиса. Это позволяло запускать по каждому коммиту интеграционные тесты, генерировать артефакт и образ Docker, после чего разворачивать его на тестовом сервере. С помощью одного клика любой образ можно было развернуть на «боевом» сервере. Схема выглядела примерно так:







В ячейках под названием John и Doe содержатся наборы Docker-контейнеров, развернутых на конкретном узле. Кроме того для провижининга применяется Ansible. В итоге создать новый облачный сервер и установить на него корректную версию Docker/Docker-Compose, сконфигурировать правила межсетевого экрана и выполнить прочие настройки можно с помощью одной команды. Для каждого работающего в Docker-контейнере сервиса есть сторожевые скрипты, которые «поднимают» его в случае сбоя. Но в такой конфигурации возможны и проблемы.







Если сервер Doe «сгорит» однажды ночью (или просто на нем произойдет кратковременный серьезный сбой), технической команде проекта придется подниматься среди ночи, чтобы вернуть систему в работоспособное состояние. Сервисы, установленные на Doe, автоматически не перемещаются на другой сервер — например, John, поэтому на некоторое время работа системы была бы прекращена.



Есть и другие сложности — расположение на одном узле максимального количества контейнеров, обнаружение сети (service discovery), «заливка» обновлений, агрегирование лог-данных. Нужно было как-то со всем этим справиться.







Нужен был некий волшебный фреймворк оркестрации (orchestration framework), с помощью которого можно было бы распределять контейнеры по узлам кластера. Нужно было добиться того, чтобы работать с множеством узлов можно было бы, как с одним-единственным. Нужно было, чтобы этому волшебному фреймворку можно было сказать «разверни 3 экземпляра вот такого Docker-контейнера где-нибудь в кластере и проследи, чтобы все работало». Отличный план! Дело оставалось за малым — найти такой фреймворк.



Список пожеланий



Технологии развиваются очень быстро, так что даже для соответствия весьма умеренным стандартам, все равно необходимо выбирать инструменты таким образом, чтобы они были живы и поддерживались на протяжении какого-то времени. Инженеры Haleby хотели бы, чтобы их «фреймворк мечты» использовал что-то вроде уже применявшегося ими docker-compose — это позволило бы избавиться от необходимости проведения большого количества работ по реконфигурации и настройке.



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



Помимо этого члены команды Haleby хотели бы, чтобы в выбранном инструменте присутствовала поддержка работы с контейнерами в нескольких облаках одновременно, а также наличие функциональности сетевого обнаружения. Также инженерам не хотелось тратить много времени на настройку, поэтому предпочтительным был бы вариант использования модели «framework as service».



Выбор фреймворка



Анализ существующих на рынке вариантов позволил выделить несколько фреймворков-кандидатов. В их числе:





AWS ECS



AWS ECS Container Service — это высокомасштабируемый и быстрый инструмент управления контейнерами, с помощью которого их можно запускать, останавливать и работать с контейнерами Docker в кластере инстансов Amazon EC2. Если какой-либо проект уже работает в этом облаке, то не рассмотреть данный вариант просто странно. Однако Haleby не работал на Amazon, поэтому переезд показался инженерам компании не самым лучшим решением.



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



Docker Swarm



Docker Swarm — это нативный инструмент кластеризации для Docker. Поскольку Swarm использует Docker API, то любое средство, умеющее работать с демоном Docker, может быть масштабировано с его помощью. Поскольку Haleby использует docker-compose, последняя опция звучала очень заманчиво. Кроме того, использование нативного инструмента знакомой технологии означало, что команде не придется изучать что-то новое.



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



Более того, обновление контейнеров также невозможно было бы провести в автоматическом режиме. Для этого пришлось бы, к примеру, настраивать Nginx в качестве балансировщика нагрузки на различные группы контейнеров. Также многие инженеры в интернете выражали сомнения в работоспособности Swarm — среди них, к примеру, сотрудники Google.



Mesosphere DCOS







После настройки DCOS (операционной системы дата-центра) на AWS и старта работы, Mesosphere кажется неплохим вариантом. С помощью удобного интерфейса можно получить всю информацию о кластере, включая запущенные сервисы, загрузку процессора и потребление памяти. DCOS может работать в любом облаке и сразу с несколькими облаками. Mesos же — это инструмент, проверенный работой в крупных кластерах. Также DCOS позволяет запускать не только контейнеры, но и отдельные приложения, вроде Ruby, а устанавливать важные сервисы можно с помощью простой команды dcos install (это как apt-get для дата-центра).



Более того, с помощью этого инструмента можно работать с несколькими кластерами одновременно — можно запустить Marathon, Kubernetes, Docker и Swarm в рамках одной системы.



Однако наряду с плюсами, у этого варианта были и свои недостатки. К примеру, поддержка работы с несколькими облаками присутствует только в Enterprise-версии Mesosphere DCOS, однако цена этой версии не указана на сайте, а на запросы никто не ответил.



Также в документации на тот момент (октябрь/ноябрь 2015 года) не было информации о том, как переехать на новый кластер без необходимости прерывания работы системы — тут важно понимать, что это также не managed-сервис, так что во время переезда могут возникнуть проблемы.



Tutum



Команда проекта описывает его как «Docker-платформа для Dev и Ops», а слоган звучит как «стройте, разворачивайте и управляйте своими приложениями в любом облаке». Интерфейс выглядит вот так:







Кому-то он может показаться не столь эффектным, как у DCOS, но тем не менее система позволяет производить большинство нужных манипуляций с помощью простых кликов мышкой, хотя у Tutum есть и хорошая поддержка командной строки. Для начала работа с системой нужно установить Tutum-агент на каждом узле кластера, после чего узел начинает отображаться в административной панели. Интересный момент — Tutum использует формат объявления стэков из нескольких сервисов или контейнеров, который похож на docker-compose — поэтому специалистам, знакомым с Docker будет еще проще начать работу.



Кроме того, Tutum поддерживает тома с помощью интеграции в кластер Flocker. Тесты, в ходе которых определенные контейнеры «убивались» были пройдены успешно — они воссоздавались в том же состоянии (иногда на разных узлах). Еще одним плюсом стала функция создания ссылок между контейнерами — с ее помощью можно связывать определенные контейнеры в группе.



Для балансировки нагрузки используется HAProxy, который поддерживает виртуальные хосты, так что за одним экземпляром HAProxy можно размещать несколько сервисов. Развертывание сервисов также можно осуществлять разными способами, а для обновления Docker во всем кластере достаточно сделать пару кликов. В дальнейшем компания Docker купила сервис Tutum, так что в будущем он будет полностью интегрирован в экосистему.



Однако на момент поисков лучшего фреймворка Tutum находился в стадии бета-тестирования. И все же главным аргументом против этого варианта стал инцидент, когда в ходе теста инженеры специально добились полной недоступности узла — загрузка CPU 100% не позволяла даже подключиться к машине по SSH, контейнеры с него не были перенесены на другой узел. Техподдержка Tutum заявила о том, что знакома с этой проблемой, но она еще не устранена. Нужно было искать дальше.



Kubernetes







Команда Kubernetes описывает проект как инструмент для «управления кластером Linux-контейнеров в качестве единой системы для ускорения Dev и упрощения Ops». Это открытый проект, который поддерживает Google, также его развитием занимается ряд других компаний, в числе которых Red Hat, Microsoft, SaltStack, Docker, CoreOS, Mesosphere, IBM.



Что по-настоящему хорошо в Kubernetes, так это то, что в нем объединен десятилетний опыт Google по построению и работе с кластерами — и все это бесплатно! Запустить Kubernetes можно на своем железе или на мощностях облачных провайдеров вроде AWS для которого даже есть специальные шаблоны формаций.



Кроме того, Google предлагает managed-версию Kubernetes под названием Google Container Engine. Из-за недостатков интерфейса начать работать с ней не так легко, как к примеру с Tutum, однако после того, как пользователю удастся разобраться в системе, работать с ней становится просто.



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



Еще одним существенным плюсом Kubernetes стала возможность обновления всего кластера без прерывания работы. Также тесты подтвердили работоспособность сетевого обнаружения — нужно лишь вбить в адресную строку имя нужного сервиса (http://my-service), и Kubernetes создать подключение к нужному контейнеру. Kubernetes представляет собой модульную систему, компоненты которой можно комбинировать.



Есть у фреймворка и свои минусы — при работе с Google Container Engine система ограничивается одним дата-центром. Если с ним что-нибудь случится, ничего хорошего не будет. Из любой ситуации можно выйти, например, организовав несколько кластеров с помощью балансировщика нагрузки, но «из коробки» решения нет. Однако поддержка работы с несколькими ЦОД планируется в новых версиях более легкой версии фреймворка Ubernetes. Кроме того, Kubernetes использует свой yaml-формат, что приводит к необходимости конвертации файлов docker-compose. Помимо этого, проект еще не настолько развит, как тот же Mesos, который позволяет работать с большим количеством узлов.



Заключение



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



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

https://habrahabr.ru/post/279105/

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

[Перевод] Ошибка в ядре Linux отправляет поврежденные TCP/IP-пакеты в контейнеры Mesos, Kubernetes и Docker

Среда, 09 Марта 2016 г. 17:16 (ссылка)

image

А обнаружена она была на серверах Twitter



Ядро Linux имеет ошибку, причиной которой являются контейнеры. Чтобы не проверять контрольные суммы TCP, для сетевой маршрутизации контейнеры используют veth-устройства (такие как Docker на IPv6, Kubernetes, Google Container Engine и Mesos). Это приводит к тому, что в ряде случаев приложения ошибочно получают поврежденные данные, как это происходит при неисправном сетевом оборудовании. Мы проверили, что эта ошибка появилась, по крайней мере, три года назад и до сих пор «сидит» в ядрах. Наш патч был проверен и введен в ядро, и в настоящее время обеспечивает ретроподдержку стабильного релиза 3.14 в различных дистрибутивах (таких как Suse и Canonical). Если Вы в своей системе используете контейнеры, я рекомендую Вам воспользоваться этим патчем или установить ядро вместе с ним, когда это станет доступным.



Примечание: это не относится к сетям с NAT, по умолчанию используемых для Docker, так как Google Container Engine практически защищен от ошибок «железа» своей виртуализированной сетью. Еще Джейк Бауэр (Jake Bower) считает, что эта ошибка очень похожа на ошибку Pager Duty, обнаруженную ранее.



Как это все началось



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



После суток непрерывной работы по поиску неисправности на уровне приложений, команде удалось локализовать проблему до отдельных рэковых стоек. Инженеры определили, что значительное увеличение числа выявленных ошибок контрольной суммы TCP произошло непосредственно перед тем, как они дошли до адресата. Казалось, что этот результат «освобождал от вины» софт: приложение может вызвать перегрузку сети, а не повреждение пакета!



Примечание:
упоминание эфемерной «команды» может скрыть от читателя, сколько людей работало над этой проблемой. Над диагностикой этих странных неисправностей работала масса инженеров из всей компании. Трудно перечислить всех, но основной вклад внесли: Брайан Мартин (Brian Martin), Дэвид Робинсон (David Robinson), Кен Коэмото (Ken Kawamoto), Махак Пайтидар (Mahak Patidar), Мануэль Кэбэлкуинто (Manuel Cabalquinto), Сэнди Стронг (Sandy Strong), Зак Киль (Zach Kiehl), Уилл Кэмпбелл (Will Campbell), Рэмин Хатиби (Ramin Khatibi), Яо Юэ (Yao Yue), Берк Демир (Berk Demir), Дэвид Барр (David Barr), Гопал Рейпуроухит (Gopal Rajpurohit), Джозеф Смит (Joseph Smith), Рохис Менон (Rohith Menon), Алекс Ламберт (Alex Lambert) и Иэн Доунес (Ian Downes), Цун Ван (Cong Wang).)



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



После изоляции определенных коммутаторов, были сделаны попытки воспроизвести эти ошибки (главным образом благодаря колоссальной работе старшего инженера по надежности Брайана Мартина). Оказалось, что относительно просто воспроизвести поврежденные данные, отослав на эти стойки некоторое количество пакетов данных. На некоторых коммутаторах оказались поврежденными до 10% отправленных пакетов. Однако, повреждения всегда выявлялись ядром с помощью контрольных сумм TCP (сообщения типа TcpInCsumErrors netstat-a), и никогда не доходили до приложений. (В Linux с помощью недокументированной опции SO_NO_CHECK можно отсылать пакеты IPv4 UDP с отключенными контрольными суммами – в таком случае мы сможем увидеть, что пакет поврежден.)



Эван Джонс (Evan Jones) предположил, что поврежденные данные имеют правильную контрольную сумму TCP. Если в том же самом 16-битном слове два бита зеркально «перевернуть» (например, 0->1 и 1->0), их влияния на контрольную сумму TCP уравновесят друг друга (контрольная сумма TCP – простое сложение битов). Хотя повреждение данных в сообщении (32 байта по модулю) всегда заключалось в изменении одной и той же битовой позиции, факт, что был «залипающий бит» (0->1), исключающий такую возможность. С другой стороны, поскольку сама контрольная сумма перед сохранением инвертируется, «переворот» бита в контрольной сумме вместе с «переворотом» бита в данных могут уравновесить друг друга. Однако, битовая позиция, которую мы наблюдали измененной, не могла касаться контрольной суммы TCP, и поэтому это оказалось невозможным.



Вскоре команда поняла, что наши тесты проводились на стандартной системе Linux, а большинство сервисов на Твиттере работает на Mesos, который для изолирования различных приложений использует контейнеры Linux. В частности, в конфигурации Твиттера созданы виртуальные Ethernet-устройства (veth-устройства) и все пакеты для приложений передаются через них. Конечно же, после запуска нашего тестового приложения в контейнере Mesos немедленно появились поврежденные данные, поступающие через подключение по TCP, не смотря на то, что контрольные суммы TCP были ошибочными (и определялись как неправильные: число TcpInCsumErrors увеличивалось). Кто-то предложил изменение настроек «checksum offloading» на виртуальном Ethernet-устройстве, что решило проблему, приведя к соответствующему удалению поврежденных данных.



Теперь перед нами встала серьезная задача. Команда Твиттера по Mesos быстро передала информацию open source-проекту «Mesos» и изменила настройки на всех рабочих контейнерах Твиттера.



Копаем дальше



Когда мы с Эваном обсуждали эту ошибку, мы решили, что, поскольку протокол TCP/IP нарушался ОС, возможно, что она была не результатом неправильного конфигурирования Mesos, а, скорее всего, – результатом ранее необнаруженной ошибки в сетевом стеке ядра.



Чтобы продолжить это наше расследование, мы создали как можно более простую тестовую систему:




  1. простой клиент, который открывает сокет и раз в секунду посылает очень простое, длинное сообщение.

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

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

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



Мы управляли клиентом с одной машины, а сервером – с другой. Компьютеры подключили через коммутатор. Когда мы запускали тестовую систему без контейнеров, она вела себя точно так, как и ожидалось. Никаких оповещений о поврежденных пакетах не поступали. Фактически, те десять секунд, что передавались поврежденные данные, мы вообще не получали никаких сообщений. После того, как клиент прекратил повреждать пакеты, все 10 сообщений (которые не были доставлены), сразу пришли. Это подтвердило, что TCP на Linux без контейнеров работает так, как и положено: плохие пакеты TCP задерживаются и постоянно повторно передаются до тех пор, пока не смогут быть приняты без ошибок.



image

Так это должно работать в теории: поврежденные данные не доставляются; TCP повторно передает их.



Linux и контейнеры



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



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



Чтобы создать контейнер с виртуальным Ethernet-устройством, надо (первое) создать контейнер, (второе) создать veth, (третье) привязать один конец veth к контейнеру, (четвертое) назначить для veth IP-адрес и (пятое) настроить маршрутизацию, как правило, с помощью Linux Traffic Control, для того, чтобы контейнер мог получать и отсылать пакеты.



Почему все это виртуальное хозяйство «падает»



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



image

Поврежденные данные доставляются приложению: посмотрите на окно слева!



Мы также смогли воспроизвести эту тестовую систему на облачных платформах. Конфигурация Kubernetes по умолчанию показывает такую же картину (например, при использовании Google Container Engine). Конфигурация Docker’а по умолчанию (с NAT) – безопасна, а конфигурация Docker’а на IPv6 – нет.



Устраняем ошибку



После изучения сетевого кода ядра стало ясно, что эта ошибка в veth-модуле ядра. В ядре в пакетах, которые приходят от реальных устройств сети, параметрам ip_summed присваивается значение CHECKSUM_UNNECESSARY, если «железо» проверило контрольные суммы, или CHECKSUM_NONE, если пакет плохой или не было возможности проверить его.



Код в veth.c заменял CHECKSUM_NONE на CHECKSUM_UNNECESSARY. Это приводило к тому, что контрольные суммы, которые должны были быть проверены и отклонены программным обеспечением, просто молча игнорировались. После удаления этого кода пакеты стали передаваться от одного стека к другому неизмененными (как и ожидалось, tcpdump показывал неверные контрольные суммы на обеих сторонах), и корректно доставлялись (или задерживались) приложениям. Мы не проверили все возможные конфигурации сети, только несколько общих, таких как Bridge-соединение контейнеров, использующее NAT между хостом и контейнером, и маршрутизация от реальных устройств к контейнерам. Мы эффективно внедрили это в работу Твиттера (отключив вычисление контрольной суммы при приеме и разгрузив veth-устройства).



Мы точно не знаем, почему код был написан именно так, но мы полагаем, что это попытка оптимизации. Часто veth-устройства используются для подключения контейнеров на той же физической машине. Логично, что пакеты, передаваемые между контейнерами (или виртуальными машинами) внутри одного физического хоста, не должны вычислять или проверять контрольные суммы: единственный возможный источник повреждений – это собственная RAM хоста, поскольку пакеты никогда не передаются по проводу. К сожалению, эта оптимизация не работает даже так, как было задумано: у локально передаваемых пакетов параметр ip_summed задан как CHECKSUM_PARTIAL, а не как CHECKSUM_NONE.



Этот код был написан для первого релиза драйвера (commit e314dbdc1c0dc6a548ecf [NET]: Virtual ethernet device driver). Релиз Commit 0b7967503dc97864f283a net/veth: Fix packet checksumming (от декабря 2010 года) установил это для пакетов, создаваемых локально и передаваемых на реальные устройства, не изменив CHECKSUM_PARTIAL. Тем не менее, эта проблема все еще не решена для пакетов, передаваемых от реальных устройств.



Ниже приведен патч для ядра:



diff — git a/drivers/net/veth.c b/drivers/net/veth.c

index 0ef4a5a..ba21d07 100644

— — a/drivers/net/veth.c

+++ b/drivers/net/veth.c

@@ -117,12 +117,6 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)

kfree_skb(skb);

goto drop;

}

- /* don’t change ip_summed == CHECKSUM_PARTIAL, as that

- * will cause bad checksum on forwarded packets

- */

- if (skb->ip_summed == CHECKSUM_NONE &&

- rcv->features & NETIF_F_RXCSUM)

- skb->ip_summed = CHECKSUM_UNNECESSARY;



if (likely(dev_forward_skb(rcv, skb) == NET_RX_SUCCESS)) {

struct pcpu_vstats *stats = this_cpu_ptr(dev->vstats);



Выводы



В целом, я действительно впечатлен netdev-группой и специалистами по ядру Linux. Инспекция кода прошла достаточно быстро, наш патч был подключен в течение нескольких недель, а через месяц обеспечил ретроподдержку старой, стабильной версии (3.14 +) с различными дистрибутивами ядра (Canonical, Suse). При всех преимуществах контейнерной среды, для нас действительно стало большой неожиданностью, что эта ошибка просуществовала много лет незамеченной. Интересно, какое количество отказов и другого непредсказуемого поведения прикладных программ могло быть ею вызвано!

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

https://habrahabr.ru/post/278885/

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

Лунный посевной календарь на 8 февраля 2016 года

Воскресенье, 07 Февраля 2016 г. 07:37 (ссылка)
green-color.ru/1573-lunnyy-...?_utl_t=li


30/1 лунный день, Новолуние, Луна в Водолее.  День не подходит для посевов и посадок.

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

Контейнерное садоводство.

Понедельник, 01 Февраля 2016 г. 13:51 (ссылка)


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

[Перевод] 350+ полезных ресурсов, книг и инструментов для работы с Docker

Среда, 13 Января 2016 г. 12:55 (ссылка)






В нашем блоге мы пишем о развитии облачного сервиса 1cloud, но и о перспективных технологиях. Одной из наиболее активно обсуждаемых тем ушедшего года стала «революция контейнеров», одним из главных действующих лиц которой, безусловно, является Docker. Поэтому сегодня мы представляем вашему вниманию перевод подборки из более чем 350 полезных ресурсов, книг и инструментов для работы с этой технологией, которые собраны в этом репозитории на GitHub. Читать дальше →

http://habrahabr.ru/post/275015/

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

Следующие 30  »

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

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

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