Існує дуже багато готових до використання образів Docker. Переглянути список офіційних образів можна на сайті https://hub.docker.com/explore/
Під час роботи Docker створюватиме багато різних тимчасових та постійних файлів. За замовчуванням він використовує для цього каталог /var/lib/docker, але якщо ви бажаєте змінити його на інший каталог, це можна зробити наступним чином1):
Створити каталог /etc/systemd/system/docker.service.d. Далі створити в цьому каталозі файл із назвою, наприклад, custom-graph.conf такого змісту:
[Service] ExecStart= ExecStart=/usr/bin/dockerd --graph="/home/dockerdata" -H fd://
Після цього потрібно оновити конфігурацію systemd:
sudo systemctl daemon-reload
та запустити службу Docker:
sudo systemctl restart docker
Якщо під час використання Docker з'являється повідомлення на кшталт
FATA[0000] Get http:///var/run/docker.sock/v1.16/version: dial unix /var/run/docker.sock: no such file or directory. Are you trying to connect to a TLS-enabled daemon without TLS?
часто це означає, що ваш користувач не входить до групи docker. Додамо його туди:
sudo usermod -a -G docker $USERNAME
В репозиторії Debian 8 “Jessie” міститься пакет Docker під назвою "docker.io". Але ця версія Docker не підтримує багаторівневу адресу репозиторію. Тому варто встановити цей пакет з офіційного сайту Docker. Згідно офіційного сайту, для цього потрібно зробити наступне:
sudo apt-get -y install apt-transport-https ca-certificates curl software-properties-common curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add - sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable" sudo apt-get update sudo apt-get install docker-ce
Якщо спробувати запустити графічну програму з образу Docker, можна побачити таке повідомлення:
cannot connect to X server :0.0
Це означає, що в контейнері немає інформації про запущений X-сервер. Для того, щоб ця інформація передавалася образу під час його запуску, його необхідно запускати із додатковими параметрами:
docker run -ti --rm -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix <назва_образу>
Але навіть у такому випадку при спробі запустити графічну програму нас чекає така помилка:
Invalid MIT-MAGIC-COOKIE-1 key : cannot connect to X server :0.0
Тепер контейнер має інформацію про запущений X-сервер основної системи, але не має прав доступу до нього. Для того, щоб додати таке право до свого сеансу в Docker, необхідно зробити такі кроки:
xauth list MyHost/unix:0 MIT-MAGIC-COOKIE-1 40a9e33971febb9ebc18f692772cfdad
40a9e33971febb9ebc18f692772cfdaddocker run -ti --rm -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix --name=GUIHost <назва_образу>
xauth add GUIHost/unix:0 MIT-MAGIC-COOKIE-1 40a9e33971febb9ebc18f692772cfdad
підставивши до неї обране ім'я комп'ютера (в даному випадку GUIHost) та число, скопійоване на попередніх кроках.
Після цього можна запускати графічні програми з командного рядка контейнера, і їхні вікна відображатимуться через X-сервер основної системи.
Графічні програми на Qt можуть видавати таку помилку:
X Error: BadAccess (attempt to access private resource denied)
Тоді можна спробувати запускати їх, встановивши змінну оточення:
QT_GRAPHICSSYSTEM=native <програма>
В межах технології "неперервної інтеграції" GitLab дозволяє перевіряти, чи програму в поточному стані можна успішно зібрати на певній тестовій системі. В якості тестових систем використовуються образи Docker.
Для того, щоб увімкнути режим неперервної інтеграції, потрібно додати у кореневий каталог свого git-репозиторію (тобто проекту на GitLab) файл .gitlab-ci.yml. В цьому файлі потрібно описати усі сценарії збирання та тестування вашого проекту. Наприклад, для того, щоб тестувати збирання вашої програми з бібліотеками Qt4 та Qt5 на базовій системі Debian 8, файл може бути таким:
image: debian:8 before_script: - echo "Preparing for the build..." - apt-get update && apt-get install -q -y build-essential qt4-qmake libqt4-dev qt5-qmake qtbase5-dev Qt5: stage: build script: - echo "Building against Qt5..." - cd src - qmake -qt=5 - make Qt4: stage: build script: - echo "Building against Qt4..." - cd src - qmake -qt=4 - make
Якщо такий файл присутній в вашому проекті, GitLab буде автоматично після кожного коміту завантажувати стандартний образ debian:8, встановлювати на нього вказані пакети для збирання програм на Qt4 і Qt5, після чого запускати збирання вашого проекту.
Якщо для неперервної інтеграції використовувати стандартні образи Docker, то для виконання кожного завдання Runner GitLab має виконувати усі підготовчі операції наново. Це займає певний додатковий час. Цього можна уникнути, якщо заздалегідь підготовити власний образ для Docker, який вже буде готовий до виконання завдання. Тоді не буде потреби витрачати час на підготовку образа до збирання проекту.
Для використання власних образів Docker в GitLab передбачено сервіс під назвою "Container Registry". Порядок дій може бути приблизно наступним:
1. Встановити Docker на власному комп'ютері.
2. Увійти до сервісу “Container Registry”:
docker login registry.gitlab.com
3. Створити файл “Dockerfile” на своєму комп'ютері. В цьому файлі буде сценарій збирання нашого образу для Docker.
FROM debian:8 RUN apt-get update -y RUN apt-get install -q -y build-essential qt4-qmake libqt4-dev qt5-qmake qtbase5-dev
У цьому файлі вказано, що потрібно зібрати образ на базі стандартного образу debian:8, встановивши на нього додатково пакети для збирання програм на Qt4 та Qt5.
4. Створити образ за вказаним сценарієм:
docker build -t registry.gitlab.com/user/repo/image .
Тут user – ім'я користувача на GitLab, repo – назва проекту на GitLab, image – назва нашого образу.
5. Завантажити створений образ до сервісу “Container Registry”:
docker push registry.gitlab.com/user/repo/image
Для використання цього образу в сценарії неперервної інтеграції на GitLab, у файлі .gitlab-ci.yml потрібно вказувати:
image: registry.gitlab.com/user/repo/image