Евгений Штольц - Из разработчика в архитекторы. Практический путь

Передача и распространение продукта

Для передачи проекта, например, заказчику, и распространения между разработчиками и серверами можно использовать установочные скрипты, архивы, образа и контейнера. Каждый из этих способов распространения проекта имеет свои особенности, недостатки и преимущества. Давайте о них поговорим и сравним.

строк, но главное, что у неё есть специальный режим, включаемый ключом – p, который выводит динамически нужно нам количество строк, при поступлении новых – обновляет вывод, например, docker logs name_container | tail – p.

Когда приложений становится слишком много, чтобы вручную мониторить их работу по отдельности целесообразно логи приложений централизовать. Для централизации могут быть использованы многочисленные программы, которые собирают логи от разных сервисов и направляют их в центрально хранилище, например, Fluentd. Для хранения логов удобно использовать ElasticSearch, просто записывая их в поисковик. Очень желательно, чтобы логи были в структурированном формате – json. Это позволит их сортировать, отбирать нужные, выявлять тенденции с помощью встроенных агрегатных функций, проводить анализ и прогнозирование, а не только поиск по тексту. Для анализа веб-интерфейс Kibana, в ходящий в состав стека Elastic.

Не только для долгоиграющих приложений важно логирование. Так для тестовых контейнеров, удобно получить вывод пройденных тесто. Так можно сделать, прописав в DockerFile в секции CMD: npm run, который прогонит тесты.

Хранилище образов:

* публичный и приватный docker hub (http://hub.docker.com)

* для закрытых и секретных проектов можно создать собственное хранилище образов. Образ называется reginstry

Docker для создания приложений и одноразовые работы

В отличии от виртуальных машин запуск которых сопряжён с значительными человеческими и вычислительными затратами Docker часто применяется для для выполнения одноразовых действий, когда программное обеспечение требуется запустить разово, и желательно не тратить усилии на установку и удаление его. Для этого запускается контейнер, который примонтирован к папке с нашим приложением, который выполняет над ним требуемые действия и после их выполнения удаляется. В качестве примера можно проект на JavaScript, для которого нужно провести сборку и выполнить тесты. При этом сам проект не использует NodeJS, а содержит только конфиги сборщика, например, WebPack-ка, и написанные тесты. Для этого запускаем контейнер сборки в итеративном режиме, в котором можно управлять процессом сборки, если потребуется и после выполнения сборки контейнер остановится и само удалится, например, можно запустить в корне приложение что-то подобное: docker run – it – rm – v $(pwd):app node-build. Аналогичным образом можно провести тесты. В результате приложение собрано и протестировано на тестовом сервере, но при этом программное обеспечение не требующееся для его работы на продакшн сервере не буде усыновлено и потреблять ресурсы, и может быть перенесено на продакшн сервер, наприер с помощью контейнера. Чтобы не писать документация на запуску сборки и тестированию можно положить два соотвующих конфига docker-compose-build.yml и docker-compose-test.yml и вызывать их docker-compose up – f./docker-compose-build.

Управление и доступ

По умолчанию, для безопасности, клиент общается с сервером через unix сокет (специльаный файл /var/run/socket.sock), а не через сетевой сокет. Дял работы через unix сокет можно использовать указать программе отправки запросов curl его использовать curl – unix-socket /var/run/docker.sock http:/v1.24/containers/json, но это возможность поддерживается с версии curl 1.40, которая пока не поддерживается в CentOS. Для решения этой проблемы и взаимодействия между удалёнными серверами используем сетевой сокет. Для активации его останавливаем сервер systemctl stop docker и запускаем его с настройками dockerd – H tcp://0.0.0.0:9002 & (слушать всех на порту 9002, что не допустимо для продакшна). После запуска команда docker ps не будет работать, а будет docker – H 5.23.52.111:9002 ps или docker – H tcp://geocode1.essch.ru:9202 ps. По умолчанию docker использует для http порт 2375, а для https – 2376. Чтобы не менять везде код и каждый раз не указывать сокет, пропишем его в переменных окружения:

export DOCKER_HOST=5.23.52.111:9002

docker ps

docker info

unser DOCKER_HOST

Важно прописать export для обеспечения доступности переменной всем программам: дочерним процессам. Также не должно стоять пробелов вокруг =. Теперь мы так можем обращаться из любого места находящимся в одной сети сервером dockerd. Для управления удалёнными и локальными Docker Engine (Docker на хостах) разработана программа Docker Mashine. Взаимодействие с ней осуществляется с помощью команды docker-machine. Для начала установим: