как отлаживать изображения контейнеров с помощью openshift

Предположим, у меня есть изображение докеров, созданное с использованием файла Docker. Во время написания файла Dockerfile мне пришлось неоднократно тестировать его, чтобы понять, что я сделал неправильно. Чтобы отладить изображение докера, я могу просто запустить тестовый контейнер и посмотреть его stdout/stderr, чтобы увидеть, что не так с изображением.как отлаживать изображения контейнеров с помощью openshift

IMAGE_NAME=authoritative-dns-bind 
IMAGE_OPTIONS=" 
    -v $(pwd)/config.yaml:/config.yaml:ro 
    -p 127.0.0.1:53:53 
    -p 127.0.0.1:53:53/udp" 

docker run -t -i $IMAGE_OPTIONS $IMAGE_NAME

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

Я в значительной степени осведомлен о том, что контейнер не готов к OpenShift. Мой план - запустить его и посмотреть его stdoud/stderr, как я сделал с Docker. Один из людей, которых я попросил о помощи, придумал команду, которая была похожа именно на то, что мне нужно.

oc run -i -t --image $IMAGE_NAME --command test-pod -- bash

И вышеприведенная команда, казалось, для меня fedora:24 и fedora:latest изображений из реестра Докер, и я получил рабочую оболочку. Но то же самое не получилось бы для моего производного изображения с контейнеризованным сервисом. Мое объяснение состоит в том, что он, вероятно, делает совсем другую вещь, и вместо того, чтобы запускать команду в интерактивном режиме, он запускает ее неинтерактивно, а затем пытается запустить bash внутри отказавшего контейнера.

Так что я ищу разумный способ отладки изображения контейнера в OpenShift. Я ожидал, что смогу, по крайней мере, захватить и посмотреть stdin/stdout контейнеров OpenShift.

Любые идеи?

Update

Согласно комментарию Грэм oc run действительно должен работать как docker run но это, кажется, не так. С оригинальными изображениями Fedora bash всегда появляется, по крайней мере, при попадании в enter.

# oc run -i -t --image authoritative-dns-bind --command test-auth13 -- bash 
Waiting for pod myproject/test-auth13-1-lyng3 to be running, status is Pending, pod ready: false 
Waiting for pod myproject/test-auth13-1-lyng3 to be running, status is Pending, pod ready: false 
Waiting for pod myproject/test-auth13-1-lyng3 to be running, status is Pending, pod ready: false 
... 
Waiting for pod myproject/test-auth13-1-lyng3 to be running, status is Pending, pod ready: false  
^C 
#

Я не смог опробовать предлагаемый oc debug еще, как это, кажется, требует больше конфигурации, чем только простое изображение. Есть еще одна проблема с oc run, поскольку эта команда создает новые и новые контейнеры, которые мне действительно не нужны. Я надеюсь, что есть способ легко начать отладку и впоследствии автоматически уничтожить контейнер.

источник

2017-01-20 Pavel Šimerda

Когда вы говорите, что «не произошло бы для моего производного изображения с помощью контейнерной службы», что вы на самом деле видели? При использовании '' oc run'' с командой, он ничего не должен запускать и должен просто запускать команду, которую вы ему даете. Поэтому ничто не могло провалиться уже. Кроме того, если вы пытаетесь развернуть приложение, содержащее изображение, вы также можете использовать '' oc debug dc mydcname''. Это запустит контейнер с той же конфигурацией, что и реальное приложение, за исключением присоединения к сеансу терминала и запуска оболочки вместо вашего приложения. –

Есть три основные команды для отладки стручков:

oc describe pod $pod-name - детальная информация о стручка
oc logs $pod-name - стандартный вывод и стандартный поток ошибок стручка
oc exec -ti $pod-name -- bash - получить оболочку в рабочем состоянии

К вашей конкретной проблеме: oc run политика по умолчанию по умолчанию установлена в Always. Это означает, что OpenShift попытается вытащить изображение до тех пор, пока оно не будет успешным, и откажется использовать локальный.

Как только this kuberenetes patch земли в OpenShift, политика pull будет легко конфигурироваться.

EDIT: переписано

источник

2017-01-23 09:19:34 SummerBreeze

, чтобы получить оболочку, вы также можете использовать 'oc rsh $ pod-name' –

Команда' oc logs' возвращает 'Unrecognized input header' (без символа новой строки). Это не похоже на ожидаемый результат. –

@ fer.marino Это не поможет, если контейнер не работает, что будет довольно распространено во время первых экспериментов, как в моем случае. –

Пожалуйста, не считаю, что это окончательный ответ на этот вопрос и замещают его своими лучшими ответами ...

Я теперь с помощью файла конфигурации стручка, как в следующем. ..

apiVersion: v1 
kind: Pod 
metadata: 
    name: "authoritative-dns-server" # pod name, your reference from command line 
    namespace: "myproject" # default namespace in `oc cluster up` 
spec: 
    containers: 
    - command: 
     - "bash" 
     image: "authoritative-dns-bind" # use your image! 
     name: "authoritative-dns-bind-container" # required 
     imagePullPolicy: "Never" # important! you want openshift to use your local image 
     stdin: true 
     tty: true 
    restartPolicy: "Never"

Примечание команда явно установлен в bash. Затем вы можете создать стручок, прикрепить к контейнеру и запустить команду docker самостоятельно.

oc create -f pod.yaml 
oc attach -t -i authoritative-dns-server 
/files/run-bind.py

Это выглядит далеко от идеала, и это не помогает отлаживать обычный OpenShift контейнер со стандартной конфигурацией стручка, но, по крайней мере, это можно отлаживать, теперь. Ждем лучших ответов.

источник

2017-01-23 12:08:56

как отлаживать изображения контейнеров с помощью openshift

ответ

Смежные вопросы