У меня есть система («хост»), которая запускает несколько контейнеров с использованием LXC (то есть «гостей»). Я установил Дженкинса внутри гостей, и они появиться работать по назначению, за исключением того, что они не отвечать на запросы. (Я уже выполнил несколько успешных установок Jenkins, включая LXC.) В этом случае наблюдаемая проблема заключается в том, что встроенный веб-сервер Jenkins (Jetty) не отвечает на HTTP-запросы, даже если эти запросы выполняются изнутри очень гостя LXC, в котором он работает, т.е. указывает на localhost.
Я работал над решением этой проблемы несколько дней, но безуспешно.
Это то, что вы получаете при попытке связаться с веб-сервером Jenkins из localhost:
root@base:~# curl -vI http://localhost:8080/jenkins/
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8080 (#0)
> HEAD /jenkins/ HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.58.0
> Accept: */*
>
При работающей настройке вы должны получить HTTP-403, потому что вы не прошли аутентификацию, и ответ не должен занять больше секунды или двух, но даже через несколько часов ответа нет. Файл журнала Jenkins также не сообщает об ошибках.
Мне нужна помощь в устранении основной причины и решении этой проблемы, чтобы установка Jenkins работала должным образом и стала доступной.
Есть какие-нибудь указатели на то, что / где искать, чтобы выяснить и исправить эту проблему?
Вот некоторые вещи, на которые я уже обращал внимание:
/etc/default/jenkins аналогичен другим моим рабочим настройкам и имеет минимальные изменения (например, привязка только к localhost и префиксу)./var/log/jenkins/jenkins.log не сообщает о каких-либо проблемах, которые обычно проявляются в виде трассировки стека Java из исключений.iptables -S): Все цепочки / правила (INPUT, FORWARD, и OUTPUT) установлены на ACCEPT. Тем не менее, поскольку здесь общение находится в localhost, Я бы не ожидал проблем, даже если бы были другие правила брандмауэра.netstat -tapon): Показывает, что Jenkins (процесс Java) прослушивает ожидаемый порт (по умолчанию 8080, но я пробовал другие); он также показывает соединение как ESTABLISHED (на обоих концах) после curl клиент отправляет запрос, подобный показанному выше. Это показывает успешное рукопожатие TCP.tcpdump -i lo): Показывает выполняемое трехстороннее рукопожатие; это объясняет почему netstat показывает соединения как ESTABLISHED.jetty-9.4.z-SNAPSHOT; built: 2018-06-05T18:24:03.829Z в журнале. Нет версии с этим .z-SNAPSHOT имя на Страница релизов Jetty, поэтому для этого теста я использовал ближайшее совпадение по дате сборки: 9.4.11.v20180605)update-alternatives --config java). Наблюдается такое же неотзывчивое поведение.Некоторые из вопросов, которые я уже рассмотрел, но не были связаны и не помогли:
Я читал гораздо больше; они всего лишь образец.
1 Это единственный способ быть уверенным ... в основном ...
Вот более подробное объяснение той же проблемы. https://issues.jenkins-ci.org/browse/JENKINS-33412
Предыдущие версии Jenkins ограничивают количество потоков, используемых базовым причалом, до 40 (опция handlerCountMax). И по умолчанию причал использует потоки Runtime.getRuntime (). AvailableProcessors () / 2 для селекторов. И если количество ядер процессора достаточно велико (например, 70) или также запущен коннектор ssl на причале, а количество ядер процессора больше 36, тогда потоки исчерпаны и HTTP-запрос просто застрял. Рассмотрите возможность перехода на последнюю версию jenkins и вручную определите количество потоков для причала - проверьте эти параметры причала - qtpMaxThreadsCount, jettyAcceptorsCount, jettySelectorsCount.
Если есть 70 или больше ЦП в системе, на которой размещен Jenkins, тогда Jenkins / Jetty застревает и не работает. Либо убедитесь, что в системе / контейнере, в котором будет работать Jenkins, есть менее 70 Доступных ЦП или обновите установленный Jenkins до версии не ниже 2.138.2, который был выпущен сегодня (2018-10-10).
Оказывается, Jenkins 2.138.1 в репозитории Ubuntu 18.04 LTS есть ошибка, из-за которой Jenkins / Jetty не отвечает в системе с 70 или более процессорами. Дженкинс 2.138.2 был выпущен сегодня, 10 октября 2018 г., и включает исправления для нескольких основных проблем, одна из которых вызвала проблему, с которой я столкнулся.
Журнал изменений Вот. Ключевое исправление для меня:
Я могу подтвердить, что это исправление действительно устраняет проблему, и проверил это на моем сервере с 72 процессорами.
Если вы не можете (пока) обновить установку Jenkins, прочтите возможное решение.
Если вы устанавливаете Jenkins внутри LXC, вы можете управлять этим с помощью следующих команд:
lxc config set <container> limits.cpu N, где N < 70; иlxc exec <container> -- systemctl restart jenkins.serviceВам также может потребоваться обновить конфигурацию профиля, что вы можете сделать следующим образом:
lxc profile set <container-profile> limits.cpu N
с теми же оговорками, которые уже были показаны выше. Если вы используете виртуальную машину (например, VirtualBox, VMware и т. Д.), Вы все равно сможете установить количество процессоров, доступных для виртуальной машины.
P.S .: Спасибо Павлу за его пост, что привело меня в правильное русло, чтобы поиграть с подсчетом CPU / Core.