Docker: containerd, runC, runV и в общем про архитектуру

Сначала Docker был монолитом. И это преподносилось как преимущество. Например, в знаменитом «Introduction to Docker» на 20-й минуте Соломон Хайкс рассказывает как здорово, что Docker — это один файл. Кладешь его в систему, и готово! Позже, однако, монолитность была названа одной из причин размолвки между Docker и CoreOS и последовавшего за этим бурления на Hacker News:

Docker process model — where everything runs through a central daemon — is fundamentally flawed. To «fix» Docker would essentially mean a rewrite of the project…

Но всё, что ни делается — к лучшему. Резонанс утих, а сообщество разработчиков договорилось о необходимости разрабатывать открытые стандарты и делать декомпозицию. Появился проект ​Open Container Initiative (OCI) и разные интересные названия: containerd, runC, runV, runZ

Читать далее ▸

Tuples в C# 7

Сегодня я поковырял детали реализации кортежей (tuples), которые будут доступны в седьмой версии языка C#.

Совсем скоро мы сможем писать:

public (int x, int y, string comment) GetSomething() {
    return (42, 123, "tuples!");
}

и затем:

var tuple = GetSomething();
var sum = tuple.x + tuple.y;

Наконец-то, наконец-то появится красивый способ вернуть из функции несколько значений!

Воспользовавшись советами отсюда и отсюда, я смог запустить Visual Studio 2015 с компилятором C#, собранным прямо из master-ветки.

Читать далее ▸

Docker: user namespaces

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

В Docker 1.10 добавили поддержку так называемых user namespaces, которые призваны исправить эту ситуацию.

Нужно ли скорее бежать и включать их у себя?

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

Читать далее ▸

Docker: user defined networks — правильная работа с сетью

И раньше, и сейчас, если не указать дополнительных опций, контейнеры попадают в «дефолтную» виртуальную сеть, параметры которой можно узнать командой:

ip addr show docker0

В Docker 1.10 появилась возможность создавать дополнительные (user-defined) виртуальные сети. Делается это так:

docker network create my-net-1

Читать далее ▸

Docker: named volumes — правильная работа с томами

В терминологии Докера, тома (volumes) — это места для длительного хранения важных файлов (баз данных, логов и тд).

Принцип работы прост: определённые директории внутри контейнера (например, /var/lib/mysql или /var/log/nginx) монтируются извне. Можно уничтожить контейнер и создать на его месте новый — например, из обновленного Dockerfile или более свежего базового образа — и при этом драгоценные данные, размещенные на томах, останутся в целости и сохранности.

До версии Docker 1.10 было два способа работы с томами:

  • Bind-mounts — монтирование внешних папок параметром -v /host:/container (как в статье про MySQL внутри Докера).

  • Data-only containers — создание специального контейнера-спутника и использование его файловой системы для хранения данных (параметр --volumes-from).

Читать далее ▸