Статьи

Java API для Docker

Если вы используете Docker , вы должны знать, что он имеет архитектуру клиент-сервер. Существует инструмент командной строки docker , который отправляет все команды ( build , pull , run т. Д.) В API Docker Host; инструмент командной строки – просто элегантная оболочка, поэтому вам не нужно делать необработанные HTTP-вызовы самостоятельно.

Эта архитектура дает очень удобную развязку. Например, вы можете docker клиенту Docker отправлять команды удаленному Docker-демону, а не команде localhost. Более того, благодаря этой архитектуре все виды программного обеспечения могут интегрироваться с Docker, что и делает Comdor , один из моих проектов. Тем не менее, я остановился на шоу-шопе, и его разработка в настоящее время приостановлена, ожидая выхода первой версии docker-java-api .

Том и Джерри – Олд Рокин Стул Том, Уильям Ханна и Джозеф Барбера

Уже есть две реализации Java клиента docker : docker-java / docker-java и spotify / docker-client , так почему еще одна?

Первая причина в том, что ни один из них не является объектно-ориентированным. На самом деле они не API, а SDK. С моей точки зрения, разница между SDK и API заключается в следующем: SDK – это набор классов / инструментов, которые пользователь должен собрать для создания чего-либо; API, с другой стороны, должен представлять собой набор интерфейсов для уже построенной системы, который должен быть быстрым и интуитивно понятным – в идеале, я должен быть в состоянии изучить Docker, используя оболочку Java, так же легко, как и Docker. играя с клиентом командной строки.

Две вышеупомянутые библиотеки являются SDK, потому что они имеют практически нулевую инкапсуляцию, и пользователь должен знать, как соединить эти инструменты для реализации docker в Java. Например, в этих библиотеках я понятия не имею, куда должны идти объекты типа Port или ExposedPort или в чем разница между ними. Есть также классы, такие как HostConfig и PortBinding .

Позвольте мне задать вам вопрос: когда вы впервые начали использовать Docker (или какое-либо другое приложение), попросил ли он предоставить какие-либо порты, привязки или сервисные контексты? Нет, вы просто нажали кнопку или выполнили команду, вы использовали интерфейс . Конечно, в зависимости от сложности системы, у вас может быть возможность настроить ее, изменить некоторые настройки и т. Д., Но это должны быть расширенные опции, а не вещи, которые вы должны делать в большинстве случаев использования.

Суть в том, что они не очень удобны в использовании. Я хочу получить доступ к Docker из Java, а не собирать / собирать Docker в Java – надеюсь, вы почувствуете разницу.

Вторая причина (и на самом деле это была заторможенность шоу), из-за которой я решил написать новую, заключается в том, что оба они кажутся очень «толстыми». Они даже предупреждают вас о том, что могут вызвать проблемы с classpath (обе они содержат реализацию Jersey 2.x, которая, очевидно, несовместима с Jersey 1.x) – это вызвало проблемы в моем проекте, поскольку это Java EE, я даже не смог развернуть Приложение на Glassfish, оно вызвало некоторые очень странные исключения. Я перепробовал все виды обходных путей, включая затенение зависимостей , но ничего не получалось.

Итак, я решил создать свою собственную оболочку Java, которая должна быть:

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

Он все еще находится на ранней стадии, поэтому я могу лишь дать несколько советов о том, как это должно работать:

1
2
3
4
5
6
7
8
final Docker docker = new LocalDocker("unix:///var/run/docker.sock");
  docker.containers().create(
    Json.createObjectBuilder()//JSON payload for creating a Container.
        .add(..., ...)
        .build()
  );
  final Container container = docker.containers().get("containerId");
  //...

Выше описано, как вы будете общаться с местным Docker-демоном. Что интересно, мы должны реализовать HTTP-вызовы через сокет Unix. Для сокетов Unix в Java используется этот проект, и созданный Socket передается в Apache HttpClient.

Вот как вы могли бы сделать это с удаленным Docker Host:

01
02
03
04
05
06
07
08
09
10
11
final Docker docker = new RemoteDocker(
    "tcp://123.34.65.232:1234",
    "/path/to/ssl/certs"
  );
  final Container created = docker.containers().create(
    Json.createObjectBuilder()
        .add(..., ...)
        .build()
  );
  final Container existing = docker.containers().get("containerId");
  //...

За этим стоит простой HttpClient, нет Unix-сокетов, однако мы должны убедиться, что он использует эти сертификаты правильно, чтобы полностью зашифровать связь.

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

Кроме того, он должен быть максимально интегрирован с языком. Например, вот как я хотел бы перебрать все контейнеры:

1
2
3
4
5
6
7
8
9
final Docker docker = new RemoteDocker(
    "tcp://123.34.65.232:1234",
    "/path/to/ssl/certs"
  );
  final Containers containers = docker.containers();
  for(final Container container : containers) {
    //Containers is the entry point of the Containers API
    //and also implements Iterable<Container>
  }

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

Опубликовано на Java Code Geeks с разрешения MIhai Andronache, партнера нашей программы JCG. Смотрите оригинальную статью здесь: Java API для Docker

Мнения, высказанные участниками Java Code Geeks, являются их собственными.