Если вы используете 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, являются их собственными. |