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



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

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

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



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

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

Продолжаем изучать 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 неплохо справляется с распределением системных ресурсов в таких ситуациях, но по умолчанию ведет себя как добрая бабушка, угощающая внуков домашним пирогом и приговаривающая: «Всем поровну, всем поровну».



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

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

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

Выход нашелся довольно быстро — это использование технологии виртуальных частных сетей Virtual Private Network (VPN) и ее свободной реализации OpenVPN. Эта реализация доступна практически для всех распространенных платформ, в том числе для планшетов и смартфонов. История развития OpenVPN насчитывает уже 12 лет (компания OpenVPN Technologies, Inc. была создана Francis Dinha и James Yona в 2002 году), так что это надежное и проверенное временем решение.

В нашей компании сеть VPN позволила предоставить защищенный доступ сотрудников к VDS, играющей роль сервера OpenVPN. И уже для фиксированного IP этого сервера был разрешен доступ к другим ресурсам компании. Попутно на сервере OpenVPN был установлен прокси Squid, что решило все проблемы доступа сотрудников с динамическими IP к защищенным ресурсам компании.

Теме OpenVPN посвящены многочисленные статьи и сообщения на форумах. Тем не менее, нужную информацию мне пришлось собирать по частям из разных мест. Попутно приходилось разбираться с многочисленными терминами и технологиями. В качестве серверов OpenVPN были использованы VDS на базе FreeBSD и Debian Linux, в качестве клиентов — рабочие станции FreeBSD, Debian Linux, Ubuntu и Microsoft Windows.

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

Представляем вашему вниманию очень эмоциональный рассказ Льва Николаева (@maniaque) о том, как надо настраивать DNS и особенно, как делать не надо. Вот прямо после каждого пункта можете мысленно добавлять: «Пожалуйста, не делайте этого!» В своем докладе Лев так и говорит.

Статья будет состоять из трех частей:

1. Как сделать резольвер (unbound, bind)

Резольвер — это та штука, которую вы прописываете в настройках своей операционной системы, чтобы можно было превращать понятные человеку адреса типа ya.ru в непонятное 87.250.250.242.

2. Как держать зоны (PowerDNS)

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

3. Как взболтать, но не смешивать (PowerDNS + unbound)

Bash-скрипты: начало
Bash-скрипты, часть 2: циклы
Bash-скрипты, часть 3: параметры и ключи командной строки
Bash-скрипты, часть 4: ввод и вывод
Bash-скрипты, часть 5: сигналы, фоновые задачи, управление сценариями
Bash-скрипты, часть 6: функции и разработка библиотек
Bash-скрипты, часть 7: sed и обработка текстов
Bash-скрипты, часть 8: язык обработки данных awk
Bash-скрипты, часть 9: регулярные выражения
Bash-скрипты, часть 10: практические примеры
Bash-скрипты, часть 11: expect и автоматизация интерактивных утилит

Сегодня поговорим о bash-скриптах. Это — сценарии командной строки, написанные для оболочки bash. Существуют и другие оболочки, например — zsh, tcsh, ksh, но мы сосредоточимся на bash. Этот материал предназначен для всех желающих, единственное условие — умение работать в командной строке Linux.