Дело было в феврале 2019 года, когда некто сэр Нова Альтэс из Манчестера, его величества Соединенного Королевства, в одно воскресное и, непременно, дождливое британское утро, обзавелся новеньким SSL-сертификатом на имеющийся в его распоряжении домен localhost.direct. Однако приобретенный набор криптографических последовательностей сэр Альтэс намеревался использовать отнюдь не в целях безопасности личной коллекции Интернет-ресурсов, а в целях весьма благородных — пожертвовать приватный ключ мировому сообществу веб-разработчиков. И вот уже три года подряд сэр Альтэс исправно вносит весьма приличную для обычного программиста из северной Англии сумму фунтов стерлингов на счет центра сертификации Google Trust Services LLC, который, в свою очередь, с большой охотой продлевает срок действия сертификата еще на 12 месяцев, после чего мистер Нова загружает свежий приватный ключ в открытый доступ.

Что же такого особенного заключается в этом самом сертификате, и чем он может быть полезен сообществу IT? Для ответа на этот вопрос давайте обратим внимание на домен, для которого искомый сертификат, предназначается, а именно — localhost.direct:

$ nslookup localhost.direct
...
Non-authoritative answer:
Name:	localhost.direct
Address: 127.0.0.1

Аналогичный ответ от DNS мы получаем при проверке любого сабдомена следующего уровня:

$ nslookup whatever.localhost.direct
...
Non-authoritative answer:
Name:	whatever.localhost.direct
Address: 127.0.0.1

Нетрудно догадаться, что сэр Альтэс позаботился о том, чтобы домен localhost.direct, ровно как и любой домен, подходящий под маску *.localhost.direct , вели на 127.0.0.1, то есть на сетевой интерфейс внутренней петли, он же localhost. Поскольку соответствующие DNS-записи внесены в публичную базу DNS, а ключ SSL-сертификата находится в свободном доступе, — любой желающий имеет возможность защитить свой собственный localhost сертификатом, выданным авторитетным центром.

Демо

Скачаем с ресурса сэра Альтэса подписанный сертификат вместе с ключом и положим их в директорию ~/localhost.direct:

$ mkdir -p ~/localhost.direct
$ curl -o certs.zip -LOs https://aka.re/localhost
$ unzip -P localhost certs.zip
$ rm certs.zip
$ ls
localhost.direct.crt localhost.direct.key

Создадим простой nginx.conf:

Запустим контейнер nginx:alpine, подложив внутрь nginx.conf, подписанный сертификат и его ключ:

$ docker run --rm \
-v $PWD/nginx.conf:/etc/nginx/conf.d/default.conf \
-v $PWD/localhost.direct.crt:/etc/nginx/certs/localhost.direct.crt \
-v $PWD/localhost.direct.key:/etc/nginx/certs/localhost.direct.key \
-p 80:80 \
-p 443:443 \
nginx:alpine

Откроем https://localhost.direct в браузере. Сертификат работает.

— Вы уже скучаете по боли от самоподписанных сертификатов и паническим надписям «Connection is not secure»?

Пример роутинга по сабдоменам:

Результат:

Идея проекта localhost.direct максимально проста и изящна. Kudos, сэр Альтэс!

Официальная страница проекта: https://get.localhost.direct.

Рассмотрим пример maven-проекта из sping guides. Он имеет следующую структуру:

├── mvnw
├── mvnw.cmd
├── pom.xml
├── src
├── main
│   └── java
│       └── hello
│           ├── Greeter.java
│           └── HelloWorld.java
├── test
├── java
├── hello
└── GreeterTest.java

Самый банальный Dockerfile «на скорую руку» может выглядеть следующим образом:

Рассмотрим способы оптимизации.

1. Шаг перый: Кешируем зависимости

Как правило, в процессе активной разработки, список зависимостей меняется реже чем бизнес-логика и тесты. Воспользуемся этим знанием: вынесем dependencies в отдельной слой и расположим его до слоя COPY src src. Согласно идеологии docker layers, изменение слоя инвалидирует только те слои, которые расположены после данного, поэтому изменение содержимого директории src не будет инвалидировать слой зависимостей.

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

Согласно maven build lifecycle, mvn verify выполнит фазы validate, compile, test, package и сам verify. Поскольку на данном этапе в директории /build есть только pom.xml — сам исходный код скомпилирован не будет, но все зависимости из pom.xml будут установлены в локальный репозиторий ~/.m2.

Следующими двумя слоями мы копируем директорию src и компилируем jar-файл командой mvn package. Большинство зависимостей будет зачитано мавеном из локального репозитория.

Исследуем слои промежуточного stage образа командой dive:

       0 B  WORKDIR /build
    1.6 kB  COPY pom.xml .
     18 MB  RUN /bin/sh -c mvn --fail-never verify
     715 B  COPY src src
    682 kB  RUN /bin/sh -c mvn package

Итого, на данном этапе мы добились следующего поведения:

• изменение директории src (частое действие) приводит к инвалидации только двух последних двух слоев, «тяжелые» слои, расположенные ДО — остаются в кеше
• изменение файла pom.xml (редкое действие) приводит к инвалидации последних четырех слоев

2. Шаг второй: Исключаем тесты

Если выполнение тестов при сборке не является частью вашего CI/CD, их можно пропустить, используя флаг -DskipTests. Наличие этого флага позволяет пропустить выполнение тестов, однако не исключает тесты из компиляции. Полный отказ от тестов реализуется при помощи двух флагов -Dmaven.test.skip -DskipTests.

Теперь, когда тесты исключены, maven больше не нуждается в плагине Maven Surefire Plugin, который используется на этапе mvn test. Поскольку, это единственный артифакт, который добавлялся в локальный репозиторий в слое RUN mvn package (легко проверить командой dive), теперь мы можем использовать флаг -o, который запрещает обращение к remote репозиториям и вынуждает мавен читать локальный репозиторий:

Сборка стала заметно быстрее, а размер последнего слоя stage=build снизился с 682 до 634kB (проверьте ваши слои самостоятельно командой dive или docker history). Благодаря флагу -o, все зависимости зачитаны мавеном из локального репозитория.

3. Шаг третий: Используем параллельную сборку

Maven версии 3+ позволяет использовать parallel builds:

mvn -T 4 clean install # Builds with 4 threads
mvn -T 1C clean install # 1 thread per cpu core
mvn -T 1.5C clean install # 1.5 thread per cpu core

Распараллелим сборку по 10 потоков на каждое ядро, доступное докеру:

Мы рассмотрели несколько способов оптимизации maven-сборки в экосистеме докера. В промышленных масштабах, подобная оптимизация экономит уйму времени ожидания, как ускоряя CI/CD pipeline, так и уменьшая биллинг за процессорное время.

Часто бывает, что документация по запуску того или иного контейнера либо отсутствует, либо ее качество оставляет желать лучшего. На своей практике я наблюдал множество случаев, когда docker run приводил к многозначительному молчанию консоли, после чего процесс завершался без какого-либо видимого эффекта:

Давайте рассмотрим несколько  техник, которые помогут вам разобраться с запуском любого контейнера.

1. Найдите Dockerfile

Dockerfile представляет собой набор инструкций для сборки образа и последующего запуска контейнера. Лучшим рецептом исследования проблемы «молчаливого» старта является изучение непосредственно самого docker-файла. При запуске контейнера выполняется команда, указанная в инструкции ENTRYPOINT:

Dockerfile в исходном виде не является частью собранного образа, поэтому проще всего отыскать оригинал. Если автор образа — не вы, то попробуйте найти репозиторий исходного кода, откуда образ был собран. Как правило, помогает гугление запросов из разряда «some-image docker github». Используйте поиск по гитхаб-репозиторию, чтобы найти искомый Dockerfile.

Если в docker-файле отсутствует инструкция ENTRYPOINT, найдите самую последнюю инструкцию FROM, и далее изучите родительский образ аналогичным способом.

Если вам не удалось найти ENTRYPOINT, или у вас нет уверенности, что найденный Dockerfile соответствует искомому контейнеру, переходите к следующим техникам.

2. Зачитайте Entrypoint из конфигурации образа

$ docker inspect some-image -f "{{.Config.Entrypoint}}"

Эта команда дешево и сердито выведет искомый ENTRYPOINT. Зачем же тогда искать Docker-файл, если есть такая простая и понятная команда? Дело в том, что Dockerfile является наиболее полным представлением о содержимом образа, в то время как docker inspect просто выдает параметры конфигурации, одним из которых, в том числе, является ENTRYPOINT:

$ docker inspect nginx -f "{{.Config.Entrypoint}}"
[/docker-entrypoint.sh]

Образ Nginx выполняет команду /docker-entrypoint.sh при запуске контейнера.

3. Скопируйте Entrypoint-скрипт из контейнера на вашу машину

$ docker run \
-v /path/on/host:/mount-dir \
--entypoint cp \
some-image /path/in/container /mount-dir

Скопирует /path/in/container из образа some-image на хост в директорию /path/on/host (на Windows вместо обратного слеша «\» использовать «^» — здесь и далее).

$ docker run \
-v $PWD:/mount --entypoint cp \
nginx /docker-entrypoint.sh /mount

Теперь в вашей рабочей директории есть файл /docker-entrypoint.sh из образа Nginx (на Windows вместо $PWD использовать %cmd%)

Кстати, я использую эту команду для копирования любого файла из образа. Разберем подробнее, как она работает:

• -v /path/on/host:/mount-dir замаунтить директорию хоста /path/on/host в контейнер на путь /mount-dir
• --entypoint cp при старте контейра использовать команду cp (сокращение от copy, то есть скопировать)
• /path/in/container /mount-dir параметры запуска контейнера, в данном случае - параметры команды cp - скопировать откуда и скопировать куда

Как итог, файл /path/in/container копируется в директорию /path/on/host.

Работает гораздо быстрее чем docker save и не требует запущенного контейнера, как docker copy.

4. Запустите контейнер в режиме линукс-терминала

$ docker run -it --entrypoint=sh some-image

В большинство docker-образов предуставновлен Bourne shell (/bin/sh), что позволяет вам использовать его в качестве терминала (не забудьте флаги -it, которые инициируют интерактивную консоль контейнера):

Запускаем контейнер nginx, используя sh в качестве entrypoint:

$ docker run -it --entrypoint=sh nginx

Изучаем оригинальный entrypoint, выявленный предыдущими методами:

$ less /docker-entrypoint.sh

Используем другие возможности линукса, находясь внутри контейнера:

$ bash
$ ls -la /etc/nginx/conf.d

Домашнее задание

Объясните, почему $ docker run alpine завершается сразу после старта.