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



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

Пятнадцать лет назад Red Hat стояла перед судьбоносным выбором: прекратить или продолжать выпуск операционной системы Red Hat Linux, подарившей название всей компании. В компании возникло понимание того, что сам по себе открытый код не может создать бизнес-модель, способную конкурировать с корпорациями уровня Oracle и Microsoft. Требовались решительные действия.

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



Раскрыть горячую тему нам поможет пример с мороженым.

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



Мы поговорили с Алексеем Усовым, сертифицированным специалистом RHCA Level XIII – о том, как выбрать программу обучения, зачем нужна сертификация, как проходят экзамены, как к ним подготовиться и что все это дает на выходе.

Предположим, что заказчик попросил вас помочь с переносом скрипта для развертывания централизованного файла sudoers на серверах RHEL и AIX.



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

Открываем Red Hat Enterprise Linux 8 Beta – одновременно со всем миром!



И прежде, чем мы перейдем к представлению важных изменений и новых возможностей, скажем главное – разработчики могут начать тестировать наше новое чудо при помощи Red Hat Developer Program.

Во время разговоров о cgroups пользователи Red Hat довольно часто задают один и тот же вопрос: «У меня есть одно приложение, очень чувствительное в смысле задержек. Можно ли с помощью cgroups изолировать это приложение от остальных, привязав его к определенным процессорным ядрам?»



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

Вы, наконец, сдались на милость контейнеров и обнаружили, что они решают массу проблем и имеет массу преимуществ:

1. Контейнеры незыблемы: ОС, библиотеки, папки и приложения – поскольку все это хранится прямо в контейнере, вы на 100 % уверены, что в продакшн всегда пойдет именно тот образ, который тестировался в QA. И работать он при этом будет абсолютно аналогично.
2. Контейнеры легковесны: Контейнер не ест память впустую. Вместо сотен мегабайт и гигабайт контейнеру нужна память лишь под основной процесс.
3. Контейнеры быстрые: Контейнер запускается так же быстро, как и обычный Linux-процесс. Не минуты, а буквально считанные секунд.

Однако, многие до сих пор считают, что контейнеры – это виртуальные машины, и забывают про важнейшее их свойство…

Интеграционное тестирование остается важной частью производственного цикла CI/CD, в том числе при разработке контейнерных приложений. Интеграционные тесты, как правило, представляют собой не очень продолжительные, но очень ресурсоемкие рабочие нагрузки. Посмотрим, как можно объединить технологии и инструменты интеграционного тестирования со средствами оркестрации контейнеров (в частности, с Red Hat OpenShift), чтобы ускорить тестирование, повысить его динамичность, и более эффективно использовать ресурсы.



Создадим интеграционные BDD-тесты (behavior-driven development – разработка через поведение) с помощью Cucumber, Protractor и Selenium и выполним их на платформе OpenShift, используя Zalenium.

Есть много шаблонов построения контейнеров. Контейнер – это всего лишь выполняемая версия своего же образа. Поэтому способ построения контейнера тесно связан с тем, как он запускается.

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



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

(Введение в терминологию контейнеров см. в первой части)

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



Так что, не владея терминологией, будет сложно понять, чем docker отличается от CRI-O, rkt или lxc/lxd; либо оценить роль Open Container Initiative в деле стандартизации контейнерных технологий.

Продолжаем изучать cgroups. В Red Hat Enterprise Linux 7 они задействуется по умолчанию, поскольку здесь используется systemd, а он, в свою очередь, имеет уже встроенные cgroups. С Red Hat Red Hat Enterprise Linux 6 все немного иначе. На самом деле контроллеры cgroups изначально были и там, а вышла эта версия, напомним, в январе 2010 года, то есть пару столетий назад в пересчете на компьютерные годы.



Однако cgroups в Red Hat Enterprise Linux 6 и сегодня на многое способны, что мы сегодня и проиллюстрируем.

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



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

Продолжаем изучать Control Groups (Cgroups) в Red Hat Enterprise Linux 7. Займемся памятью. Вы помните, что для распределения процессорного времени есть две регулировки: CPUShares для настройки относительных долей и CPUQuota для того, чтобы ограничивать пользователя, службу или виртуальную машину (ВМ) в абсолютных величинах (процентах) процессорного времени. Причем, обе эти регулировки можно использовать одновременно. Например, если для пользователя задана CPU-квота в 50 %, то его CPU-шара тоже будет приниматься во внимание до тех пор, пока он полностью не выберет свою квоту в 50 % процессорного времени.



Что касается оперативной памяти, то systemd предлагает только один способ регулировки, а именно…

Мы начали изучать Control Groups (Cgroups) в Red Hat Enterprise Linux 7 – механизм уровня ядра, позволяющий управлять использованием системных ресурсов, кратко рассмотрели теоретические основы и теперь переходим к практике управления ресурсами CPU, памяти и ввода-вывода.


Однако, прежде чем что-то менять, всегда полезно узнать, как все устроено сейчас.

Компьютеры – это «железо». И сегодня мы вернулись в исходную точку, в том смысле, что сейчас редко найдешь физический хост, на котором выполняется одна единственная задача. Даже если на сервере крутится только одно приложение, оно, скорее всего, состоит из нескольких процессов, контейнеров или даже виртуальных машин (ВМ), и все они работают на одном сервере. Red Hat Enterprise Linux 7 неплохо справляется с распределением системных ресурсов в таких ситуациях, но по умолчанию ведет себя как добрая бабушка, угощающая внуков домашним пирогом и приговаривающая: «Всем поровну, всем поровну».



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

18-ое ноября 2010-го года, Москва, 6 утра. На улице промозглый холодный ветер с мелким моросящими дождиком, заставляющий ёжиться в ожидании машины до Шереметьево. Регистрация, осмотр, паспортный контроль, небольшое ожидание, и вот уже в 8.20 самолет отрывается от полосы и несёт нас вдаль, в Софию. Два с половиной часа полёта, пустой встречающий аэропорт, небольшая очередь на паспортном контроле… И вот мы уже за дверьми аэропорта. Нас встречает яркое болгарское солнышко, ласково обогревающими своими лучами, и теплый легкий ветерок приятно пахнет свежестью и переменами…

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

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

Всем привет! Немного затянул с написанием третьей части (почти полгода аж прошло), но на то были свои причины. И сегодня пришло время завершить мой обзор про жизнь и работу в Болгарии с освещением самых свежих данных про рынок IT, оформление рабочей визы, собеседований и многое другое.

Навеяно недавним постом «Как я переехал в Израиль после блокировки Telegram».

Из этой статьи Вы можете узнать о мобильной связи и интернете в Израиле, о местных гос.услугах, особенностях работы израильских банков и почты, о некоторых «чисто местных» проблемах, а также соображения о возможных причинах их появления.